Docker para WordPress - Parte 2

Nesta parte do nosso conteúdo sobre Docker, vamos dar uma olhada em um ambiente realmente voltado para o desenvolvimento. Eu usei este ambiente durante alguns anos, tanto enquanto trabalhava na duo.me quanto depois, quando estava na Codeable.

Parte 1: Ambiente básico de Docker para WordPress
Parte 2: Ambiente com phpMyAdmin, MailHog e outras ferramentas
Parte 3: O que é Docker e suas vantagens sobre o XAMPP
Parte 4: WP Local Docker da 10up

Ambiente Docker voltado para desenvolvimento

Diferente daquela estrutura de pastas supersimples da parte 1, este ambiente tem algumas pastas e arquivos a mais. São utilitários que ajudam tanto a sincronizar os ambientes entre os desenvolvedores quanto a configurar o Apache e o MySQL da forma necessária para o projeto. O repositório com a estrutura de pastas está no neste repositório do GitHub. Você pode baixá-lo clicando em Clone or download e depois em Download ZIP ou simplesmente ir na pasta onde você vai criar o projeto (antes de criar a pasta do projeto propriamente dita) e executar:

svn export https://github.com/felipeelia/docker-base-env/trunk pasta-do-projeto

Sim, é um comando svn. Infelizmente, o GitHub não tem suporte ao comando git archive. Você também pode clonar o repositório e apagar a pasta .git se achar mais fácil.

Subindo o ambiente

Com as pastas e arquivos no lugar, basta você entrar na pasta docker e executar o mesmo docker-compose up, que nós vimos na parte 1. Diferente daquele primeiro ambiente, este aqui não vai instalar o WordPress automaticamente. Isso é proposital, para que você possa instalar a versão que desejar (e assim subir um ambiente o mais parecido possível com o do seu cliente).

Estrutura de pastas

Vamos entender um pouco melhor a função de cada pasta e arquivo deste novo ambiente:

bd: Diferente do que você pode imaginar, esta não é a pasta onde ficarão aqueles arquivos do banco de dados. Aqui nós manteremos alguns dumps, ou exportações em formato zip, do nosso banco de dados. Vamos falar mais sobre isso daqui a pouco.
dev: A pasta onde estarão os arquivos do WordPress. Esta pasta é mapeada com a pasta /var/www/html do Apache, da mesma forma que o ambiente da parte 1.
docker: Esta é a pasta onde nós mantemos as especificidades do nosso ambiente:
- dev.ini: Arquivo ini onde você pode alterar ou acrescentar configurações do PHP. O Apache do nosso contêiner vai usar este arquivo como uma extensão do php.ini.
- docker-compose.yml: Arquivo de configuração do Docker Compose. Vamos falar dos contêineres em outra seção mais adiante.
- htaccess_dev: O arquivo .htaccess que será usado no ambiente de desenvolvimento. Como este arquivo pode ser diferente do arquivo de produção, fazemos o mapeamento do /var/www/html/.htaccess do contêiner do Apache para este arquivo.
.gitignore: Evita que o git versione alguns arquivos do ambiente. A pasta /db_data/, que será criada pelo ambiente e usada para manter os arquivos do MySQL é um exemplo de algo que nós não queremos versionar, afinal cada acesso ou edição de conteúdo vai alterar o conteúdo dessas pastas, aumentando muito o tamanho do seu repositório.
.htaccess: Só uma medida de segurança para o caso de você usar esta estrutura em um ambiente de homologação, por exemplo. Este arquivo evita que as pessoas vejam o conteúdo de algumas pastas acessando diretamente pelo navegador.
dump-db.sh, update-db.sh e update-local-from-live.sh: Arquivos utilitários para o versionamento do banco de dados.

Containers (contêineres)

O arquivo docker/docker-compose.yml tem cinco contêineres, três deles comentados. Para usá-los basta retirar os caracteres # no começo das linhas e executar o comando docker-compose up.

Contêiner wordpress

O primeiro contêiner usa esta imagem, cujo conteúdo está disponível neste repositório do GitHub. É uma imagem que eu fiz há bastante tempo, mas que tem algumas diferenças da imagem oficial do WordPress que eu julguei importantes na época. Além de corrigir um erro bem chatinho no mapeamento de usuários entre o contêiner e o seu computador, ela também inclui WP-CLI, XDebug, possibilidade de uso do MailHog e ainda conexão HTTPS. Não é nenhuma oitava maravilha do mundo, mas me serviu bem durante muito tempo.

Para usar o XDebug no VS Code, por exemplo, você precisa retirar os comentários no docker-compose.yml e inserir estas linhas no settings.json do VS Code:

"launch": {
	"version": "0.2.0",
	"configurations": [
		{
			"name": "XDebug (docker)",
			"type": "php",
			"request": "launch",
			"port": 9000,
			"pathMappings": {
				"/var/www/html/": "${workspaceRoot}/dev",
			},
			"xdebugSettings": {
				"max_children": 999,
			}
		},
	],
	"compounds": []
}

Contêiner mysql

Embora o nome do contêiner seja esse, na verdade ele usa a imagem do MariaDB. É bem similar ao contêiner que usamos na parte 1.

Contêiner mailhog

Este contêiner receberá todos os e-mails disparados pelo WordPress. Para vê-los basta acessar localhost:8025.

Contêiner phpmyadmin

Esta era uma das principais ferramentas que faltavam no nosso outro ambiente. Para acessá-la basta acessar localhost:8080.

Contêiner node

Este contêiner pode ser útil caso o seu tema (ou algum plugin) precise de algo mais complexo com node. Se você estiver com uma equipe de programadores mais voltados para o back-end e não quer que eles percam tempo configurando node, este contêiner pode ser uma opção para ganhar tempo. Não se esqueça de ajustar o endereço do volume.

Gerenciamento do banco de dados

Como eu disse lá em cima, versionar a pasta com os arquivos do MySQL não é uma opção. Eles mudam demais e isso gera um aumento absurdo no tamanho do seu repositório. Você está versionando seus projetos, certo?

A ideia aqui é ter sempre no repositório um arquivo bd/prod.sql.gz e outro bd/dev.sql.gz. O primeiro contém os dados do site em produção e o segundo é a versão mais recente (e mais útil) do ambiente de desenvolvimento. Supondo, por exemplo, que você instalou e configurou um plugin no seu ambiente local, você pode compartilhar isso com os colegas atualizando o arquivo bd/dev.sql.gz.

Arquivos para o gerenciamento do bd

dump-db.sh: Executar este arquivo vai substituir (ou criar) o arquivo bd/dev.sql.gz com os dados da sua máquina. É só fazer um commit e um push com o arquivo novo, que ele estará disponível para as outras pessoas.
update-db.sh: Este arquivo vai atualizar os dados da sua máquina com o que estiver no bd/dev.sql.gz. ATENÇÃO: Este arquivo irá sobrescrever o seu banco de dados. Cuidado.
update-local-from-live.sh: Atualiza os dados da sua máquina com uma cópia do banco de dados de produção. O arquivo bd/prod.sql.gz será criado ou atualizado e os dados na sua máquina sobrescritos. Este arquivo também faz um search and replace mudando os endereços de produção para o seu localhost, então não se esqueça de alterar seu conteúdo conforme o necessário.

Mas esse ambiente não resolve todos os meus problemas!

É, eu sei. Esse ambiente ainda tem um problema fundamental: não é possível subir mais de um site ao mesmo tempo. O ambiente que eu uso hoje, o WP Local Docker, resolve estes e vários outros problemas. Vamos falar dele em uma próxima parte. Para não perder, não esqueça de assinar a newsletter e o canal no YouTube!

Docker para WordPress – Parte 2