Como instalar o WordPress com Docker Compose no Ubuntu – techsyncer
Tutoriais

Como instalar o WordPress com Docker Compose no Ubuntu

TechTranslator
TechTranslator
maio 18, 2024 24 Mins Read
1 Views
0 Comments

Introdução

O WordPress é um sistema de gerenciamento de conteúdo (CMS) gratuito e de código aberto construído em um banco de dados MySQL com processamento PHP. Graças à sua arquitetura de plugin extensível e sistema de templates, grande parte de sua administração pode ser feita através da interface web. Esta é uma razão pela qual o WordPress é uma escolha popular ao criar diferentes tipos de sites, desde blogs até páginas de produtos e sites de comércio eletrônico.

Executar o WordPress normalmente envolve instalar uma pilha LAMP (Linux, Apache, MySQL e PHP) ou LEMP (Linux, Nginx, MySQL e PHP), o que pode ser demorado. No entanto, ao usar ferramentas como Docker e Docker Compose, você pode agilizar o processo de configuração da sua pilha preferida e instalar o WordPress. Em vez de instalar componentes individuais manualmente, você pode usar imagens, que padronizam coisas como bibliotecas, arquivos de configuração e variáveis de ambiente. Em seguida, execute essas imagens em contêineres, processos isolados que são executados em um sistema operacional compartilhado. Além disso, ao usar o Compose, você pode coordenar vários contêineres — por exemplo, um aplicativo e um banco de dados — para se comunicarem entre si.

Neste tutorial, você criará uma instalação WordPress multi-contêiner. Seus contêineres incluirão um banco de dados MySQL, um servidor web Nginx e o próprio WordPress. Você também protegerá sua instalação obtendo certificados TLS/SSL com o Let’s Encrypt para o domínio que deseja associar ao seu site. Por fim, você configurará um cron job para renovar seus certificados para que seu domínio permaneça seguro.

Pré-requisitos

Se você estiver usando o Ubuntu versão 16.04 ou abaixo, recomendamos que você faça a atualização para uma versão mais recente, pois o Ubuntu não oferece mais suporte para essas versões. Esta coleção de guias irá ajudá-lo a atualizar sua versão do Ubuntu.

Para seguir este tutorial, você precisará de:

  • Um servidor executando Ubuntu, juntamente com um usuário não-root com privilégios de sudo e um firewall ativo. Para orientações sobre como configurar esses itens, escolha sua distribuição nesta lista e siga nosso Guia de Configuração Inicial do Servidor.

  • O Docker instalado em seu servidor, seguindo os Passos 1 e 2 de “Como Instalar e Usar o Docker no Ubuntu” 22.04 / 20.04 / 18.04.

  • O Docker Compose está instalado no seu servidor, seguindo Passo 1 de “Como Instalar o Docker Compose no Ubuntu” 22.04 / 20.04 / 18.04.

  • Um nome de domínio registrado. Este tutorial usará seu_domínio ao longo. Você pode obter um gratuitamente no Freenom, ou usar o registrador de domínios de sua escolha.

  • Ambos os seguintes registros DNS configurados para o seu servidor. Você pode seguir esta introdução ao DNS da DigitalOcean para detalhes sobre como adicioná-los a uma conta da DigitalOcean:

    • Um registro A com seu_domínio apontando para o endereço IP público do seu servidor.
    • Um registro A com www.seu_domínio apontando para o endereço IP público do seu servidor.

Assim que tudo estiver configurado, você estará pronto para começar o primeiro passo.

Passo 1 — Definindo a Configuração do Servidor Web

Antes de executar quaisquer containers, seu primeiro passo é definir a configuração para seu servidor web Nginx. Seu arquivo de configuração incluirá alguns blocos de localização específicos do WordPress, juntamente com um bloco de localização para direcionar as solicitações de verificação do Let’s Encrypt para o cliente Certbot para renovações automáticas de certificados.

Primeiro, crie um diretório de projeto para sua configuração do WordPress. Neste exemplo, ele é chamado de wordpress. Você pode nomear este diretório de forma diferente se desejar:

  1. mkdir wordpress

Em seguida, navegue até o diretório:

  1. cd wordpress

Depois, crie um diretório para o arquivo de configuração:

  1. mkdir nginx-conf

Abra o arquivo com o nano ou o seu editor favorito:

  1. nano nginx-conf/nginx.conf

Neste arquivo, adicione um bloco de servidor com diretivas para o nome do seu servidor e o diretório raiz do documento, e blocos de localização para direcionar as solicitações do cliente Certbot por certificados, processamento PHP e solicitações de ativos estáticos:

Adicione o seguinte código ao arquivo. Certifique-se de substituir seu_domínio pelo seu próprio nome de domínio:

~/wordpress/nginx-conf/nginx.conf
server {
        listen 80;
        listen [::]:80;

        server_name your_domain www.your_domain;

        index index.php index.html index.htm;

        root /var/www/html;

        location ~ /.well-known/acme-challenge {
                allow all;
                root /var/www/html;
        }

        location / {
                try_files $uri $uri/ /index.php$is_args$args;
        }

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass wordpress:9000;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
        }

        location ~ /\.ht {
                deny all;
        }

        location = /favicon.ico {
                log_not_found off; access_log off;
        }
        location = /robots.txt {
                log_not_found off; access_log off; allow all;
        }
        location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
                expires max;
                log_not_found off;
        }
}

Nosso bloco de servidor inclui as seguintes informações:

Diretivas:

  • listen: Isso diz ao Nginx para ouvir na porta 80, o que permitirá que você use o plugin webroot do Certbot para suas solicitações de certificado. Observe que você ainda não está incluindo a porta 443 ainda – você irá atualizar sua configuração para incluir SSL assim que obtiver seus certificados com sucesso.

  • server_name: Isso define o nome do seu servidor e o bloco do servidor que deve ser usado para solicitações ao seu servidor. Certifique-se de substituir seu_domínio nesta linha pelo seu próprio nome de domínio.

  • index: Esta diretiva define os arquivos que serão usados como índices ao processar solicitações para o seu servidor. Você modificou a ordem padrão de prioridade aqui, movendo index.php na frente de index.html para que o Nginx priorize arquivos chamados index.php quando possível.

  • root: Esta diretiva nomeia o diretório raiz para solicitações ao seu servidor. Este diretório, /var/www/html, é criado como um ponto de montagem no momento da construção pelas instruções em seu WordPress Dockerfile. Essas instruções do Dockerfile também garantem que os arquivos do lançamento do WordPress sejam montados neste volume.

Blocos de Localização:

  • location ~ /.well-known/acme-challenge: Este bloco de localização irá lidar com solicitações para o diretório .well-known, onde o Certbot irá colocar um arquivo temporário para validar que o DNS para seu domínio resolve para seu servidor. Com esta configuração em vigor, você poderá usar o plugin webroot do Certbot para obter certificados para seu domínio.

  • location /: Neste bloco de localização, uma diretiva try_files é usada para verificar arquivos que correspondem a solicitações de URI individuais. Em vez de retornar um status 404 Not Found como padrão, no entanto, você passará o controle para o arquivo index.php do WordPress com os argumentos da solicitação.

  • location ~ \.php$: Este bloco de localização irá lidar com o processamento PHP e encaminhar essas solicitações para o seu contêiner wordpress. Como sua imagem Docker do WordPress será baseada na imagem php:fpm, você também incluirá opções de configuração específicas para o protocolo FastCGI neste bloco. O Nginx requer um processador PHP independente para solicitações PHP. Neste caso, essas solicitações serão tratadas pelo processador php-fpm incluído na imagem php:fpm.
    Além disso, este bloco de localização inclui diretivas, variáveis e opções específicas do FastCGI que irão encaminhar solicitações para a aplicação WordPress em execução no seu contêiner wordpress, definir o índice preferido para o URI da solicitação analisada e analisar solicitações de URI.

  • location ~ /\.ht: Este bloco irá lidar com arquivos .htaccess, já que o Nginx não os serve. A diretiva deny_all garante que os arquivos .htaccess nunca serão servidos aos usuários.

  • location = /favicon.ico, location = /robots.txt: Estes blocos garantem que solicitações para /favicon.ico e /robots.txt não serão registradas.

  • location ~* \.(css|gif|ico|jpeg|jpg|js|png)$: Este bloco desativa o registro para solicitações de ativos estáticos e garante que esses ativos sejam altamente cacheáveis, pois geralmente são caros de servir.

Para obter mais informações sobre a proxyagem FastCGI, leia Compreendendo e Implementando a Proxyagem FastCGI no Nginx. Para informações sobre blocos de servidor e localização, confira Compreendendo os Algoritmos de Seleção de Blocos de Servidor e Localização do Nginx.

Salve e feche o arquivo quando terminar de editar. Se você estiver usando nano, faça isso pressionando CTRL+X, Y, depois ENTER.

Com sua configuração do Nginx em vigor, você pode prosseguir para criar variáveis de ambiente para passar para seus contêineres de aplicativo e banco de dados durante a execução.

Passo 2 — Definindo Variáveis de Ambiente

Seus contêineres de banco de dados e aplicativo WordPress precisarão de acesso a determinadas variáveis de ambiente durante a execução para que os dados do seu aplicativo persistam e sejam acessíveis ao seu aplicativo. Essas variáveis incluem informações sensíveis e não sensíveis: valores sensíveis para a senha do root do MySQL e usuário e senha do banco de dados do aplicativo, e informações não sensíveis para o nome e host do banco de dados do aplicativo.

Em vez de definir todos esses valores em seu arquivo Docker Compose — o arquivo principal que contém informações sobre como seus contêineres serão executados —, defina os valores sensíveis em um arquivo .env e restrinja sua circulação. Isso evitará que esses valores sejam copiados para seus repositórios de projeto e expostos publicamente.

No diretório principal do seu projeto, ~/wordpress, abra um arquivo chamado .env:

  1. nano .env

Os valores confidenciais que você define neste arquivo incluem uma senha para o usuário root do MySQL e um nome de usuário e senha que o WordPress usará para acessar o banco de dados.

Adicione os seguintes nomes de variáveis e valores ao arquivo. Lembre-se de fornecer seus próprios valores aqui para cada variável:

~/wordpress/.env
MYSQL_ROOT_PASSWORD=your_root_password
MYSQL_USER=your_wordpress_database_user
MYSQL_PASSWORD=your_wordpress_database_password

Incluída está uma senha para a conta administrativa root, assim como seu nome de usuário preferido e senha para o banco de dados da sua aplicação.

Salve e feche o arquivo quando terminar de editar.

Porque seu arquivo .env contém informações sensíveis, você quer garantir que ele seja incluído nos arquivos .gitignore e .dockerignore do seu projeto. Isso informa ao Git e ao Docker quais arquivos não copiar para seus repositórios Git e imagens Docker, respectivamente.

Se você planeja trabalhar com o Git para controle de versão, inicialize seu diretório de trabalho atual como um repositório com git init:

  1. git init

Em seguida, crie e abra um arquivo .gitignore:

  1. nano .gitignore

Adicione .env ao arquivo:

~/wordpress/.gitignore
.env

Salve e feche o arquivo quando terminar de editar.

Da mesma forma, é uma boa precaução adicionar .env a um arquivo .dockerignore, para que ele não acabe em seus containers quando estiver usando este diretório como contexto de construção.

Abra o arquivo:

  1. nano .dockerignore

Adicione .env ao arquivo:

~/wordpress/.dockerignore
.env

Abaixo disso, você pode opcionalmente adicionar arquivos e diretórios associados ao desenvolvimento da sua aplicação:

~/wordpress/.dockerignore
.env
.git
docker-compose.yml
.dockerignore

Salve e feche o arquivo quando terminar.

Com suas informações confidenciais no lugar, você pode prosseguir para definir seus serviços em um arquivo docker-compose.yml.

Passo 3 — Definindo Serviços com Docker Compose

Seu arquivo docker-compose.yml conterá as definições de serviço para sua configuração. Um serviço no Compose é um contêiner em execução, e as definições de serviço especificam informações sobre como cada contêiner será executado.

Usando o Compose, você pode definir diferentes serviços para executar aplicativos multi-contêiner, já que o Compose permite vincular esses serviços com redes e volumes compartilhados. Isso será útil para sua configuração atual, já que você criará diferentes contêineres para seu banco de dados, aplicativo WordPress e servidor web. Você também criará um contêiner para executar o cliente Certbot para obter certificados para seu servidor web.

Para começar, crie e abra o arquivo docker-compose.yml:

  1. nano docker-compose.yml

Adicione o seguinte código para definir a versão do seu arquivo Compose e o serviço db do banco de dados:

~/wordpress/docker-compose.yml
version: '3'

services:
  db:
    image: mysql:8.0
    container_name: db
    restart: unless-stopped
    env_file: .env
    environment:
      - MYSQL_DATABASE=wordpress
    volumes:
      - dbdata:/var/lib/mysql
    command: '--default-authentication-plugin=mysql_native_password'
    networks:
      - app-network

A definição de serviço db contém as seguintes opções:

  • imagem: Isso diz ao Compose qual imagem puxar para criar o contêiner. Você está fixando a mysql:8.0 imagem aqui para evitar conflitos futuros, já que a imagem mysql:latest continua sendo atualizada. Para obter mais informações sobre fixação de versão e evitar conflitos de dependência, leia a documentação do Docker sobre melhores práticas de Dockerfile.

  • nome_do_contêiner: Isso especifica um nome para o contêiner.

  • reiniciar: Isso define a política de reinicialização do contêiner. O padrão é não, mas você definiu o contêiner para reiniciar a menos que seja parado manualmente.

  • env_file: Esta opção informa ao Compose que você gostaria de adicionar variáveis de ambiente de um arquivo chamado .env, localizado no contexto de construção. Neste caso, o contexto de construção é o seu diretório atual.

  • environment: Esta opção permite adicionar variáveis de ambiente adicionais, além das definidas no seu arquivo .env. Você irá definir a variável MYSQL_DATABASE como wordpress para fornecer um nome para o banco de dados da sua aplicação. Como esta é uma informação não sensível, você pode incluí-la diretamente no arquivo docker-compose.yml.

  • volumes: Aqui, você está montando um volume nomeado chamado dbdata no diretório /var/lib/mysql do contêiner. Este é o diretório de dados padrão para o MySQL na maioria das distribuições.

  • command: Esta opção especifica um comando para substituir a instrução padrão CMD da imagem. Neste caso específico, você adicionará uma opção ao comando mysqld padrão da imagem Docker, que inicia o servidor MySQL no contêiner. Esta opção, --default-authentication-plugin=mysql_native_password, define a variável de sistema --default-authentication-plugin para mysql_native_password, especificando qual mecanismo de autenticação deve governar novas solicitações de autenticação para o servidor. Como o PHP e, portanto, sua imagem do WordPress não suportarão o padrão de autenticação mais recente do MySQL, você deve fazer este ajuste para autenticar o usuário do banco de dados de sua aplicação.

  • networks: Isso especifica que o serviço de sua aplicação se juntará à rede app-network, que você definirá na parte inferior do arquivo.

Em seguida, abaixo da definição de serviço do seu db, adicione a definição para o seu serviço de aplicativo wordpress:

~/wordpress/docker-compose.yml
...
  wordpress:
    depends_on:
      - db
    image: wordpress:5.1.1-fpm-alpine
    container_name: wordpress
    restart: unless-stopped
    env_file: .env
    environment:
      - WORDPRESS_DB_HOST=db:3306
      - WORDPRESS_DB_USER=$MYSQL_USER
      - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
      - WORDPRESS_DB_NAME=wordpress
    volumes:
      - wordpress:/var/www/html
    networks:
      - app-network

Nesta definição de serviço, você está nomeando seu contêiner e definindo uma política de reinicialização, assim como fez com o serviço db. Você também está adicionando algumas opções específicas para este contêiner:

  • depends_on: Esta opção garante que seus contêineres iniciarão na ordem de dependência, com o contêiner wordpress iniciando após o contêiner db. Sua aplicação WordPress depende da existência do banco de dados e usuário da sua aplicação, então expressar essa ordem de dependência permitirá que sua aplicação inicie corretamente.

  • imagem: Para esta configuração, você está utilizando a imagem do WordPress 5.1.1-fpm-alpine. Como discutido na Etapa 1, o uso desta imagem garante que sua aplicação terá o processador php-fpm que o Nginx requer para lidar com o processamento PHP. Esta também é uma imagem alpine, derivada do projeto Alpine Linux, o que ajudará a manter o tamanho geral da sua imagem reduzido. Para obter mais informações sobre os benefícios e desvantagens do uso de imagens alpine e se isso faz sentido para sua aplicação, revise a discussão completa na seção de Variantes de Imagem na página da imagem do WordPress no Docker Hub.

  • env_file: Novamente, você especifica que deseja extrair valores do seu arquivo .env, pois é onde você definiu o usuário e senha do banco de dados da sua aplicação.

  • ambiente: Aqui, você está usando os valores que definiu no seu arquivo .env, mas está atribuindo-os aos nomes de variáveis que a imagem do WordPress espera: WORDPRESS_DB_USER e WORDPRESS_DB_PASSWORD. Você também está definindo um WORDPRESS_DB_HOST, que será o servidor MySQL em execução no contêiner db acessível na porta padrão do MySQL, 3306. Seu WORDPRESS_DB_NAME será o mesmo valor que você especificou na definição do serviço MySQL para o seu MYSQL_DATABASE: wordpress.

  • volumes: Você está montando um volume nomeado chamado wordpress no ponto de montagem /var/www/html criado pela imagem do WordPress. Usar um volume nomeado dessa forma permitirá compartilhar o código da sua aplicação com outros contêineres.

  • networks: Você também está adicionando o contêiner wordpress à rede app-network.

Em seguida, abaixo da definição do serviço de aplicativo wordpress, adicione a seguinte definição para o seu serviço Nginx webserver:

~/wordpress/docker-compose.yml
...
  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-alpine
    container_name: webserver
    restart: unless-stopped
    ports:
      - "80:80"
    volumes:
      - wordpress:/var/www/html
      - ./nginx-conf:/etc/nginx/conf.d
      - certbot-etc:/etc/letsencrypt
    networks:
      - app-network

Aqui, você está nomeando seu contêiner e tornando-o dependente do contêiner wordpress na ordem de inicialização. Você também está usando uma imagem alpine – a imagem 1.15.12-alpine do Nginx.

Esta definição de serviço também inclui as seguintes opções:

  • ports: Isso expõe a porta 80 para habilitar as opções de configuração definidas em seu arquivo nginx.conf em Passo 1.

  • volumes: Aqui, você está definindo uma combinação de volumes nomeados e bind mounts:

    • wordpress:/var/www/html: Isso irá montar o código de sua aplicação WordPress no diretório /var/www/html, o diretório que você definiu como root em seu bloco de servidor Nginx.
    • ./nginx-conf:/etc/nginx/conf.d: Isso irá fazer um bind mount do diretório de configuração do Nginx no host para o diretório relevante no contêiner, garantindo que quaisquer alterações feitas nos arquivos no host sejam refletidas no contêiner.
    • certbot-etc:/etc/letsencrypt: Isso irá montar os certificados e chaves relevantes do Let’s Encrypt para seu domínio no diretório apropriado no contêiner.

Você também adicionou este contêiner à rede app-network.

Finalmente, abaixo da definição do seu webserver, adicione a definição do último serviço para o serviço certbot. Certifique-se de substituir o endereço de e-mail e os nomes de domínio listados aqui com suas próprias informações:

~/wordpress/docker-compose.yml
  certbot:
    depends_on:
      - webserver
    image: certbot/certbot
    container_name: certbot
    volumes:
      - certbot-etc:/etc/letsencrypt
      - wordpress:/var/www/html
    command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain

Esta definição diz ao Compose para baixar a imagem certbot/certbot do Docker Hub. Também utiliza volumes nomeados para compartilhar recursos com o contêiner Nginx, incluindo os certificados de domínio e chave em certbot-etc e o código da aplicação em wordpress.

Novamente, você utilizou depends_on para especificar que o contêiner certbot deve ser iniciado assim que o serviço webserver estiver em execução.

Você também incluiu uma opção command que especifica um subcomando a ser executado com o comando certbot padrão do contêiner. O subcomando certonly obterá um certificado com as opções a seguir:

  • --webroot: Isso diz ao Certbot para usar o plugin webroot para colocar arquivos na pasta webroot para autenticação. Este plugin depende do método de validação HTTP-01, que usa uma solicitação HTTP para provar que o Certbot pode acessar recursos de um servidor que responde a um determinado nome de domínio.

  • --webroot-path: Isso especifica o caminho do diretório webroot.

  • --email: Seu e-mail preferido para registro e recuperação.

  • --agree-tos: Isso especifica que você concorda com o Contrato do Assinante da ACME.

  • --no-eff-email: Isso indica ao Certbot que você não deseja compartilhar seu e-mail com a Electronic Frontier Foundation (EFF). Sinta-se à vontade para omitir isso se preferir.

  • --staging: Isso informa ao Certbot que você gostaria de usar o ambiente de teste do Let’s Encrypt para obter certificados de teste. Usar essa opção permite testar suas opções de configuração e evitar possíveis limites de solicitação de domínio. Para obter mais informações sobre esses limites, leia a documentação de limites de taxa do Let’s Encrypt.

  • -d: Isso permite que você especifique os nomes de domínio que deseja aplicar à sua solicitação. Neste caso, você incluiu seu_domínio e www.seu_domínio. Certifique-se de substituir esses valores pelos de seu próprio domínio.

Abaixo da definição de serviço certbot, adicione suas definições de rede e volume:

~/wordpress/docker-compose.yml
...
volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

A chave de volumes de nível superior define os volumes certbot-etc, wordpress e dbdata. Quando o Docker cria volumes, o conteúdo do volume é armazenado em um diretório no sistema de arquivos do host, /var/lib/docker/volumes/, que é gerenciado pelo Docker. O conteúdo de cada volume é então montado deste diretório para qualquer contêiner que utilize o volume. Dessa forma, é possível compartilhar código e dados entre contêineres.

A rede de bridge definida pelo usuário app-network permite a comunicação entre seus contêineres, uma vez que eles estão no mesmo host do daemon Docker. Isso simplifica o tráfego e a comunicação dentro da aplicação, pois abre todas as portas entre os contêineres na mesma rede de bridge sem expor nenhuma porta para o mundo exterior. Assim, seus contêineres db, wordpress e webserver podem se comunicar entre si, e você só precisa expor a porta 80 para acesso front-end à aplicação.

O seguinte é o arquivo docker-compose.yml na íntegra:

~/wordpress/docker-compose.yml
version: '3'

services:
  db:
    image: mysql:8.0
    container_name: db
    restart: unless-stopped
    env_file: .env
    environment:
      - MYSQL_DATABASE=wordpress
    volumes:
      - dbdata:/var/lib/mysql
    command: '--default-authentication-plugin=mysql_native_password'
    networks:
      - app-network

  wordpress:
    depends_on:
      - db
    image: wordpress:5.1.1-fpm-alpine
    container_name: wordpress
    restart: unless-stopped
    env_file: .env
    environment:
      - WORDPRESS_DB_HOST=db:3306
      - WORDPRESS_DB_USER=$MYSQL_USER
      - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
      - WORDPRESS_DB_NAME=wordpress
    volumes:
      - wordpress:/var/www/html
    networks:
      - app-network

  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-alpine
    container_name: webserver
    restart: unless-stopped
    ports:
      - "80:80"
    volumes:
      - wordpress:/var/www/html
      - ./nginx-conf:/etc/nginx/conf.d
      - certbot-etc:/etc/letsencrypt
    networks:
      - app-network

  certbot:
    depends_on:
      - webserver
    image: certbot/certbot
    container_name: certbot
    volumes:
      - certbot-etc:/etc/letsencrypt
      - wordpress:/var/www/html
    command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --staging -d your_domain -d www.your_domain

volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

Salve e feche o arquivo quando terminar de editar.

Com suas definições de serviço no lugar, você está pronto para iniciar os contêineres e testar suas solicitações de certificado.

Passo 4 — Obtenção de Certificados SSL e Credenciais

Inicie seus contêineres com o comando docker-compose up, que irá criar e executar seus contêineres na ordem especificada. Ao adicionar a flag -d, o comando executará os contêineres db, wordpress e webserver em segundo plano:

  1. docker-compose up -d

A saída a seguir confirma que seus serviços foram criados:

Output
Creating db ... done
Creating wordpress ... done
Creating webserver ... done
Creating certbot   ... done

Usando docker-compose ps, verifique o status de seus serviços:

  1. docker-compose ps

Após a conclusão, seus serviços db, wordpress e webserver estarão Ativos e o contêiner certbot terá saído com uma mensagem de status 0:

Output
  Name                 Command               State           Ports
-------------------------------------------------------------------------
certbot     certbot certonly --webroot ...   Exit 0
db          docker-entrypoint.sh --def ...   Up       3306/tcp, 33060/tcp
webserver   nginx -g daemon off;             Up       0.0.0.0:80->80/tcp
wordpress   docker-entrypoint.sh php-fpm     Up       9000/tcp

Qualquer coisa diferente de Ativo na coluna Estado para os serviços db, wordpress ou webserver, ou um status de saída diferente de 0 para o contêiner certbot significa que você pode precisar verificar os logs de serviço com o comando docker-compose logs:

  1. docker-compose logs service_name

Agora você pode verificar que seus certificados foram montados no contêiner webserver com docker-compose exec:

  1. docker-compose exec webserver ls -la /etc/letsencrypt/live

Uma vez que suas solicitações de certificado tenham sucesso, o seguinte será o resultado:

Output
total 16
drwx------    3 root     root          4096 May 10 15:45 .
drwxr-xr-x    9 root     root          4096 May 10 15:45 ..
-rw-r--r--    1 root     root           740 May 10 15:45 README
drwxr-xr-x    2 root     root          4096 May 10 15:45 your_domain

Agora que você sabe que sua solicitação será bem-sucedida, você pode editar a definição do serviço certbot para remover a sinalização --staging.

Abra o arquivo docker-compose.yml:

  1. nano docker-compose.yml

Encontre a seção do arquivo com a definição do serviço certbot, e substitua a sinalização --staging na opção command pela sinalização --force-renewal, que indicará ao Certbot que você deseja solicitar um novo certificado com os mesmos domínios de um certificado existente. A seguir está a definição do serviço certbot com a sinalização atualizada:

~/wordpress/docker-compose.yml
...
  certbot:
    depends_on:
      - webserver
    image: certbot/certbot
    container_name: certbot
    volumes:
      - certbot-etc:/etc/letsencrypt
      - certbot-var:/var/lib/letsencrypt
      - wordpress:/var/www/html
    command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain
...

Agora você pode executar docker-compose up para recriar o contêiner certbot. Você também incluirá a opção --no-deps para informar ao Compose que ele pode pular a inicialização do serviço webserver, pois ele já está em execução:

  1. docker-compose up --force-recreate --no-deps certbot

O seguinte resultado indica que sua solicitação de certificado foi bem-sucedida:

Output
Recreating certbot ... done
Attaching to certbot
certbot      | Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot      | Plugins selected: Authenticator webroot, Installer None
certbot      | Renewing an existing certificate
certbot      | Performing the following challenges:
certbot      | http-01 challenge for your_domain
certbot      | http-01 challenge for www.your_domain
certbot      | Using the webroot path /var/www/html for all unmatched domains.
certbot      | Waiting for verification...
certbot      | Cleaning up challenges
certbot      | IMPORTANT NOTES:
certbot      |  - Congratulations! Your certificate and chain have been saved at:
certbot      |    /etc/letsencrypt/live/your_domain/fullchain.pem
certbot      |    Your key file has been saved at:
certbot      |    /etc/letsencrypt/live/your_domain/privkey.pem
certbot      |    Your cert will expire on 2019-08-08. To obtain a new or tweaked
certbot      |    version of this certificate in the future, simply run certbot
certbot      |    again. To non-interactively renew *all* of your certificates, run
certbot      |    "certbot renew"
certbot      |  - Your account credentials have been saved in your Certbot
certbot      |    configuration directory at /etc/letsencrypt. You should make a
certbot      |    secure backup of this folder now. This configuration directory will
certbot      |    also contain certificates and private keys obtained by Certbot so
certbot      |    making regular backups of this folder is ideal.
certbot      |  - If you like Certbot, please consider supporting our work by:
certbot      |
certbot      |    Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
certbot      |    Donating to EFF:                    https://eff.org/donate-le
certbot      |
certbot exited with code 0

Com seus certificados no lugar, você pode prosseguir para modificar sua configuração do Nginx para incluir SSL.

Passo 5 — Modificando a Configuração do Servidor Web e Definição de Serviço

Habilitar SSL na sua configuração do Nginx envolverá adicionar um redirecionamento HTTP para HTTPS, especificar os locais do seu certificado SSL e chave, e adicionar parâmetros de segurança e cabeçalhos.

Como você vai recriar o serviço webserver para incluir essas adições, você pode pará-lo agora:

  1. docker-compose stop webserver

Antes de modificar o arquivo de configuração, obtenha o parâmetro de segurança do Nginx recomendado pelo Certbot usando curl:

  1. curl -sSLo nginx-conf/options-ssl-nginx.conf https://raw.githubusercontent.com/certbot/certbot/master/certbot-nginx/certbot_nginx/_internal/tls_configs/options-ssl-nginx.conf

Este comando irá salvar esses parâmetros em um arquivo chamado options-ssl-nginx.conf, localizado no diretório nginx-conf.

Em seguida, remova o arquivo de configuração do Nginx que você criou anteriormente:

  1. rm nginx-conf/nginx.conf

Crie e abra outra versão do arquivo:

  1. nano nginx-conf/nginx.conf

Adicione o seguinte código ao arquivo para redirecionar HTTP para HTTPS e adicionar credenciais SSL, protocolos e cabeçalhos de segurança. Lembre-se de substituir seu_domínio pelo seu próprio domínio:

~/wordpress/nginx-conf/nginx.conf
server {
        listen 80;
        listen [::]:80;

        server_name your_domain www.your_domain;

        location ~ /.well-known/acme-challenge {
                allow all;
                root /var/www/html;
        }

        location / {
                rewrite ^ https://$host$request_uri? permanent;
        }
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name your_domain www.your_domain;

        index index.php index.html index.htm;

        root /var/www/html;

        server_tokens off;

        ssl_certificate /etc/letsencrypt/live/your_domain/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/your_domain/privkey.pem;

        include /etc/nginx/conf.d/options-ssl-nginx.conf;

        add_header X-Frame-Options "SAMEORIGIN" always;
        add_header X-XSS-Protection "1; mode=block" always;
        add_header X-Content-Type-Options "nosniff" always;
        add_header Referrer-Policy "no-referrer-when-downgrade" always;
        add_header Content-Security-Policy "default-src * data: 'unsafe-eval' 'unsafe-inline'" always;
        # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
        # enable strict transport security only if you understand the implications

        location / {
                try_files $uri $uri/ /index.php$is_args$args;
        }

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass wordpress:9000;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
        }

        location ~ /\.ht {
                deny all;
        }

        location = /favicon.ico {
                log_not_found off; access_log off;
        }
        location = /robots.txt {
                log_not_found off; access_log off; allow all;
        }
        location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
                expires max;
                log_not_found off;
        }
}

O bloco do servidor HTTP especifica o diretório raiz para solicitações de renovação do Certbot para o diretório .well-known/acme-challenge. Também inclui uma diretiva de reescrita que direciona solicitações HTTP para o diretório raiz para HTTPS.

O bloco do servidor HTTPS habilita ssl e http2. Para saber mais sobre como o HTTP/2 itera nos protocolos HTTP e os benefícios que pode trazer para o desempenho do site, leia a introdução de Como Configurar o Nginx com Suporte a HTTP/2 no Ubuntu 18.04.

Este bloco também inclui as localizações do seu certificado SSL e chave, juntamente com os parâmetros de segurança recomendados do Certbot que você salvou em nginx-conf/options-ssl-nginx.conf.

Além disso, estão incluídos alguns cabeçalhos de segurança que permitirão que você obtenha classificações A em coisas como os sites de teste de servidor SSL Labs e Security Headers. Esses cabeçalhos incluem X-Frame-Options, X-Content-Type-Options, Política de Referência, Política de Segurança de Conteúdo e Proteção contra XSS. O cabeçalho HTTP Strict Transport Security (HSTS) está comentado – habilite isso apenas se você entender as implicações e tiver avaliado sua funcionalidade “preload”.

As diretrizes root e index também estão localizadas neste bloco, assim como o restante dos blocos de localização específicos do WordPress discutidos no Passo 1.

Depois de terminar a edição, salve e feche o arquivo.

Antes de recriar o serviço webserver, você precisará adicionar um mapeamento de porta 443 à definição do seu serviço webserver.

Abra seu arquivo docker-compose.yml:

  1. nano docker-compose.yml

Na definição do serviço webserver, adicione o seguinte mapeamento de porta:

~/wordpress/docker-compose.yml
...
  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-alpine
    container_name: webserver
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - wordpress:/var/www/html
      - ./nginx-conf:/etc/nginx/conf.d
      - certbot-etc:/etc/letsencrypt
    networks:
      - app-network

Aqui está o arquivo docker-compose.yml completo após as edições:

~/wordpress/docker-compose.yml
version: '3'

services:
  db:
    image: mysql:8.0
    container_name: db
    restart: unless-stopped
    env_file: .env
    environment:
      - MYSQL_DATABASE=wordpress
    volumes:
      - dbdata:/var/lib/mysql
    command: '--default-authentication-plugin=mysql_native_password'
    networks:
      - app-network

  wordpress:
    depends_on:
      - db
    image: wordpress:5.1.1-fpm-alpine
    container_name: wordpress
    restart: unless-stopped
    env_file: .env
    environment:
      - WORDPRESS_DB_HOST=db:3306
      - WORDPRESS_DB_USER=$MYSQL_USER
      - WORDPRESS_DB_PASSWORD=$MYSQL_PASSWORD
      - WORDPRESS_DB_NAME=wordpress
    volumes:
      - wordpress:/var/www/html
    networks:
      - app-network

  webserver:
    depends_on:
      - wordpress
    image: nginx:1.15.12-alpine
    container_name: webserver
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - wordpress:/var/www/html
      - ./nginx-conf:/etc/nginx/conf.d
      - certbot-etc:/etc/letsencrypt
    networks:
      - app-network

  certbot:
    depends_on:
      - webserver
    image: certbot/certbot
    container_name: certbot
    volumes:
      - certbot-etc:/etc/letsencrypt
      - wordpress:/var/www/html
    command: certonly --webroot --webroot-path=/var/www/html --email sammy@your_domain --agree-tos --no-eff-email --force-renewal -d your_domain -d www.your_domain

volumes:
  certbot-etc:
  wordpress:
  dbdata:

networks:
  app-network:
    driver: bridge

Salve e feche o arquivo quando terminar de editar.

Recrie o serviço webserver:

  1. docker-compose up -d --force-recreate --no-deps webserver

Verifique seus serviços com docker-compose ps:

  1. docker-compose ps

A saída deve indicar que seus serviços db, wordpress e webserver estão em execução:

Output
  Name                 Command               State                     Ports
----------------------------------------------------------------------------------------------
certbot     certbot certonly --webroot ...   Exit 0
db          docker-entrypoint.sh --def ...   Up       3306/tcp, 33060/tcp
webserver   nginx -g daemon off;             Up       0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp
wordpress   docker-entrypoint.sh php-fpm     Up       9000/tcp

Com seus contêineres em execução, você pode concluir a instalação do WordPress por meio da interface web.

Passo 6 — Concluindo a Instalação pela Interface Web

Com seus contêineres em execução, conclua a instalação por meio da interface web do WordPress.

No seu navegador da web, acesse o domínio do seu servidor. Lembre-se de substituir seu_domínio pelo seu próprio nome de domínio:

https://your_domain

Selecione o idioma que você gostaria de usar:

Depois de clicar em Continuar, você será redirecionado para a página principal de configuração, onde precisará escolher um nome para o seu site e um nome de usuário. É uma boa ideia escolher um nome de usuário memorável aqui (em vez de “admin”) e uma senha forte. Você pode usar a senha que o WordPress gera automaticamente ou criar a sua própria.

Por fim, você precisará inserir seu endereço de e-mail e decidir se deseja ou não desencorajar os motores de busca de indexar seu site:

Clicar em Instalar WordPress na parte inferior da página o levará a uma tela de login:

Depois de fazer login, você terá acesso ao painel de administração do WordPress:

Com a sua instalação do WordPress concluída, você pode tomar medidas para garantir que seus certificados SSL sejam renovados automaticamente.

Passo 7 — Renovando Certificados

Os certificados Let’s Encrypt são válidos por 90 dias. Você pode configurar um processo de renovação automatizado para garantir que eles não expirem. Uma maneira de fazer isso é criar um trabalho com o utilitário de agendamento cron. No exemplo a seguir, você criará um trabalho cron para executar periodicamente um script que renovará seus certificados e recarregará sua configuração do Nginx.

Primeiro, abra um script chamado ssl_renew.sh:

  1. nano ssl_renew.sh

Adicione o seguinte código ao script para renovar seus certificados e recarregar a configuração do servidor web. Lembre-se de substituir o nome de usuário de exemplo aqui pelo seu próprio nome de usuário que não seja root:

~/wordpress/ssl_renew.sh
#!/bin/bash

COMPOSE="/usr/local/bin/docker-compose --no-ansi"
DOCKER="/usr/bin/docker"

cd /home/sammy/wordpress/
$COMPOSE run certbot renew --dry-run && $COMPOSE kill -s SIGHUP webserver
$DOCKER system prune -af

Este script primeiro atribui o binário docker-compose a uma variável chamada COMPOSE, e especifica a opção --no-ansi, que executará os comandos docker-compose sem caracteres de controle ANSI. Em seguida, ele faz o mesmo com o binário docker. Por fim, ele muda para o diretório do projeto ~/wordpress e executa os seguintes comandos docker-compose:

  • docker-compose run: Isso iniciará um contêiner certbot e substituirá o comando fornecido na definição de serviço do seu certbot. Em vez de usar o subcomando certonly, o subcomando renew é usado, que renovará certificados que estão próximos da expiração. Também está incluída a opção --dry-run para testar o seu script.
  • docker-compose kill: Isso enviará um SIGHUP sinal para o contêiner webserver para recarregar a configuração do Nginx.

Em seguida, ele executa docker system prune para remover todos os contêineres e imagens não utilizados.

Feche o arquivo quando terminar de editá-lo. Torne-o executável com o seguinte comando:

  1. chmod +x ssl_renew.sh

Em seguida, abra o seu arquivo root crontab para executar o script de renovação em um intervalo especificado:

  1. sudo crontab -e

Se esta for a primeira vez que você está editando este arquivo, será solicitado que escolha um editor:

Output
no crontab for root - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/nano        <---- easiest
  2. /usr/bin/vim.basic
  3. /usr/bin/vim.tiny
  4. /bin/ed

Choose 1-4 [1]:
...

No final deste arquivo, adicione a seguinte linha:

crontab
...
*/5 * * * * /home/sammy/wordpress/ssl_renew.sh >> /var/log/cron.log 2>&1

Isso definirá o intervalo de execução para cada cinco minutos, para que você possa testar se o seu pedido de renovação funcionou conforme o esperado. Um arquivo de log, cron.log, é criado para registrar a saída relevante do trabalho.

Após cinco minutos, verifique cron.log para confirmar se o pedido de renovação foi bem-sucedido:

  1. tail -f /var/log/cron.log

A seguinte saída confirma uma renovação bem-sucedida:

Output
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/your_domain/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Saia digitando CTRL+C no seu terminal.

Você pode modificar o arquivo crontab para definir um intervalo diário. Para executar o script todos os dias ao meio-dia, por exemplo, você modificaria a última linha do arquivo da seguinte maneira:

crontab
...
0 12 * * * /home/sammy/wordpress/ssl_renew.sh >> /var/log/cron.log 2>&1

Você também vai querer remover a opção --dry-run do seu script ssl_renew.sh:

~/wordpress/ssl_renew.sh
#!/bin/bash

COMPOSE="/usr/local/bin/docker-compose --no-ansi"
DOCKER="/usr/bin/docker"

cd /home/sammy/wordpress/
$COMPOSE run certbot renew && $COMPOSE kill -s SIGHUP webserver
$DOCKER system prune -af

O seu trabalho cron garantirá que seus certificados Let’s Encrypt não expirem, renovando-os quando estiverem elegíveis. Você também pode configurar a rotação de logs com a utilidade Logrotate no Ubuntu 22.04 / 20.04 para girar e compactar seus arquivos de log.

Conclusão

Neste tutorial, você utilizou o Docker Compose para criar uma instalação do WordPress com um servidor web Nginx. Como parte deste fluxo de trabalho, você obteve certificados TLS/SSL para o domínio que deseja associar ao seu site WordPress. Além disso, você criou um trabalho cron para renovar esses certificados quando necessário.

Como passos adicionais para melhorar o desempenho e a redundância do site, você pode consultar os seguintes artigos sobre entrega e backup de ativos do WordPress:

Se você estiver interessado em explorar um fluxo de trabalho em contêiner com Kubernetes, também pode conferir Como Configurar o WordPress com MySQL no Kubernetes Usando o Helm.

Source:
https://www.digitalocean.com/community/tutorials/how-to-install-wordpress-with-docker-compose-on-ubuntu

Tags:

Share Article

TechTranslator
Follow Me Written By

TechTranslator

Other Articles

Related Posts

Translated excellent articles, this site adopts the CC BY-NC-ND 4.0 Deed | Attribution-NonCommercial-NoDerivs 4.0 International protocol.
Categories

Category Not Found!

Latest Posts

TechSyncer © 2024. All Rights Reserved.