Docker no dia a dia

Saindo um pouco da ideia de tutoriais, gostaria de escrever um pouco sobre a minha experiência, como comecei e como é a minha rotina de desenvolvimento utilizando docker, incluindo algumas dicas que foram muito importantes pra tornar esse caminho mais agradável.

Assim como muitos, eu tinha muito receio de usar o docker e na verdade era bem contra a ideia toda. Afinal basta eu subir um serviço do apache na minha máquina, configurar o PHP e pronto… estou com a minha máquina de desenvolvimento funcionando perfeitamente.

Em um segundo momento, enquanto estudava para a prova de certificação PHP, descobri que o PHP tinha um servidor web embutido (link documentação)! Isso me deixou muito feliz, pois não era mais necessário utilizar o apache.

Nessa etapa, não teria porque eu utilizar o docker para nada, eu já tinha o meu ambiente pronto. Bastava digitar:

$ php -S localhost:8080

A necessidade de usar o docker surgiu quando entrei na Kinghost: a equipe já utilizava para desenvolvimento e eu tinha que me manter atualizado com o time. Ou seja, a necessidade não surgiu diretamente do meu dia à dia mas sim, da necessidade de atualização constante. Não devemos ficar muito tempo na zona de conforto caso contrário podemos perder coisas ótimas que estão bem debaixo do nosso nariz.

Primeiro comecei a tentar entender o conceito geral: containers. É complicado no começo entender que o container é basicamente um “linux empacotado”, e que funciona! Bem louco. Um vez entendido isso, podemos seguir para a próxima fase.
Docker é executado via linha de comando, então eu precisava aprender aquela porrada de parâmetros que eu precisava passar para que tudo funcionasse corretamente.

O primeiro desafio era subir o meu já conhecido ambiente de dev “apache + php” no docker. Encontrei, então, o DockerHub, que é o repositório das imagens oficiais. Justo. Bora procurar uma imagem que atenda ao meu ambiente citado!
E não é que no repositório oficial do PHP tinha uma imagem pronta?!

Nesse caso foi só copiar o comando que eles mesmos descrevem:

$ docker run -d \
-p 80:80 \
--name my-apache-php-app \
-v "$PWD":/var/www/html \
php:7.0-apache

O que eu estou fazendo aqui? Explico:

• -d – rodar em modo “deamon” para que o terminal não fique preso;
• -p 80:80 – mapeie a minha porta localhost:80 para a porta 0.0.0.0:80 do container;
• –name – é apenas o nome do container;
• -v “$PWD”:/var/www/html – é para mapear a minha pasta atual, para a pasta /var/www/html do container.

Rodando apenas esse comando, ele vai fazer download da imagem e subir o container. A partir desse ponto, bastava acessar o endereço localhost:80 e a minha aplicação estava funcionando de boas. Fiquei maravilhado, pois isso significava que eu não precisava mais instalar apache na minha máquina.

Pois então que surgiu o primeiro problema…

Eu precisava de uma extensão específica, exemplo: bcmath. Como faz? A minha aplicação necessitava que n extensões estivessem lá… que o meu php estivesse totalmente configurado.

Felizmente a minha pergunta foi respondida já na documentação oficial novamente. Basta criar um dockerfile e criar a máquina com a nova config. Nesse momento o cara grita ao fundo “começou a ficar complicado esse troço, olha que mão pra instalar uma extensão!”

Calma! Segura a emoção! Olha só o que eu precisei escrever no arquivo Dockerfile:

FROM php:7.0-apache
RUN docker-php-ext-install bcmath

Após criado o arquivo na pasta, eu vou para o terminal e faço o “build” dessa máquina (atenção para o “ponto” no final do script, é necessário).

$ docker build -t my_php_docker_app .

Funciona! Agora basta trocar a chamada abaixo:

$ docker run -d \
-p 80:80 \
--name my-apache-php-app \
-v "$PWD":/var/www/html \
my_php_docker_app

Agora a máquina está configurada e sempre estará.

Nesse momento, eu ainda tava preocupado em ter que armazenar toda essa info, em gerar um Dockerfile pra cada aplicação… etc. Porque além de tudo, ainda tem o banco de dados: ficar configurando banco de dados para todas as aplicações é chato demais.

Quem nunca teve problemas com o serviço do mysql rodando local? E quando dá problema de versão do banco de dados. Aí impacta em todos os projetos que eu estou testando localmente. Diversas variáveis eram motivos de preocupação.

Descobri o querido docker-compose e, isso sim, abriu muito o meu mundo de desenvolvimento para novas possibilidades.

Olha um exemplo de docker compose que eu utilizo hoje em dia:

version: '2'

services:
  web:
    build: ./
    image: meuaplicativo
    container_name: meuaplicativo-web
    hostname: dev.meuaplicativo.com.br
    volumes:
      - ./:/var/www
    depends_on:
      - mysql
      - rabbit

  mysql:
    image: mysql:5.6
    container_name: meuaplicativo-mysql
    hostname: mysql.meuaplicativo.com.br

  rabbit:
    image: rabbitmq:3-management
    container_name: meuaplicativo-rabbit
    hostname: rabbit.meuaplicativo.com.br
    environment:
      - RABBITMQ_DEFAULT_USER=myapp
      - RABBITMQ_DEFAULT_PASS=myapp
      - RABBITMQ_DEFAULT_VHOST=myapp

Com isso eu não preciso lembrar da configuração de NENHUM cliente. Basta rodar o comando abaixo:

$ docker-compose up -d web

E a minha aplicação já está rodando com mysql, rabbit, apache, php… tudo configurado.

O que eu tenho rodando na minha máquina, instalado, é apenas o docker. Não preciso NEM do phpMyAdmin, sabe por quê? Tem imagem do docker para o phpMyAdmin também. Então…. muito barbada.

Hoje eu acredito que cada segundo aplicado entendendo o conceito, utilizando e indo a fundo dentro da tecnologia do Docker, me auxiliou na simplicidade de diversos problemas. Foi algo que me animou novamente, tanto com os ambientes de desenvolvimento dos meus clientes “freelas” quanto no meu desenvolvimento dentro da empresa.

Qualquer novo membro da nossa equipe de desenvolvimento não precisa se preocupar com a configuração da sua estação de trabalho. Ele deve ter apenas o seu Editor/IDE funcionando e o serviço do Docker rodando. Todo o resto do trabalho pode ser feito com isso, sem esforço e sem complicação.

Deu trabalho migrar todo ambiente de dev para Docker? Deu… Criar o Dockerfile correto para cada projeto foi tenso? Foi…

Valeu a pena? Cada minuto.

Obs: Esse artigo não é meu! Esse artigo é do Daniel Archer.

Link para o original:
https://medium.com/@danielarcher/docker-no-dia-a-dia-f585fad44cf8