Se tem uma coisa que me irritou por anos foi depender do XAMPP, WAMP, MAMP, ou até mesmo o server do próprio PHP (confesso que gostava mais desse) pra rodar qualquer sistema PHP localmente. Toda vez era a mesma novela: porta ocupada, Apache que resolve morrer sem motivo, MySQL que quebra do nada… aí você fecha tudo, abre de novo, muda porta, tenta rezar, não funciona. E lá se foi meia hora só pra abrir um projetinho. Hoje em dia isso simplesmente não faz sentido, ainda mais com Docker tão acessível. Sério, eu levei tempo demais pra largar essa vida. E quando finalmente troquei pro Docker, a primeira reação foi: “como eu aguentei tanto tempo sem isso?”. Hoje em dia eu não tenho nada demais instalado em minha máquina, posso colocar tudo para rodar no Docker.

Então vamos direto: dá pra subir um WordPress local em 5 minutos com Docker. E o melhor: limpo, organizado e sem dor.

Tem diferença entre docker-compose.yaml e compose.yaml?

Sim, tem duas formas de nomear o arquivo do Docker Compose, e muita gente ainda fica na dúvida. Antes, o padrão era sempre docker-compose.yaml. Só que isso era da época do docker-compose (binário separado). Hoje o Docker usa o Compose V2, que já vem embutido no próprio Docker CLI (docker compose …, sem hífen). E com essa mudança, o nome oficial passou a ser:

compose.yaml

Por quê? Porque o Docker tá padronizando tudo pra um esquema mais simples. E o Compose V2 procura automaticamente por:

  • compose.yaml
  • compose.yml
  • docker-compose.yaml
  • docker-compose.yml

Na prática? Funciona igual. A diferença é mais questão de “seguir o padrão novo”.

Meu compose.yaml pra rodar WordPress local

Esse é exatamente o arquivo que eu uso quando quero subir um WordPress local rapidinho, com PHP 8.1, MySQL 8 e WP-CLI já dentro do ambiente:

YAML
services:
  wordpress:
    image: wordpress:6.8.2-php8.1-apache
    container_name: wp_container
    restart: unless-stopped
    ports:
      - "8080:80" 
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_USER: WP_USER
      WORDPRESS_DB_PASSWORD: "WP_PASSWORD"
      WORDPRESS_DB_NAME: WP_DATABASE
    volumes:
      - ./:/var/www/html
    depends_on:
      - mysql
    networks:
      - blog-network

  wpcli:
    image: wordpress:cli-2.11-php8.1
    container_name: wpcli_container
    entrypoint: wp
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_USER: WP_USER
      WORDPRESS_DB_PASSWORD: "WP_PASSWORD"
      WORDPRESS_DB_NAME: WP_DATABASE
    volumes:
      - ./:/var/www/html
    networks:
      - blog-network
    depends_on:
      - mysql
      - wordpress

  mysql:
    image: mysql:8.0
    container_name: mysql_container
    restart: unless-stopped
    ports:
      - "3307:3306" 
    environment:
      MYSQL_DATABASE: WP_DATABASE
      MYSQL_USER: WP_USER
      MYSQL_PASSWORD: "WP_PASSWORD"
      MYSQL_ROOT_PASSWORD: "ROOT_PASSWORD"
    volumes:
      - mysql_data:/var/lib/mysql
    networks:
      - blog-network

  phpmyadmin:
    image: phpmyadmin/phpmyadmin:latest
    container_name: pma_container
    restart: unless-stopped
    ports:
      - "8081:80" 
    environment:
      PMA_HOST: mysql
      PMA_PORT: 3306
      PMA_USER: root
      PMA_PASSWORD: "ROOT_PASSWORD"
      MYSQL_ROOT_PASSWORD: "ROOT_PASSWORD"
    depends_on:
      - mysql
    networks:
      - blog-network

volumes:
  mysql_data:

networks:
  blog-network:
    driver: bridge

wordpress

Esse é o container principal. É basicamente o Apache + PHP + WordPress já prontos.
Olhando as configs:

  • image: wordpress:6.8.2-php8.1-apache
    Estou fixando a versão. É a versão mais estável no momento que fiz esse arquivo.
  • ports: "8080:80"
    8080 é a porta da sua máquina. 80 é a porta interna do container. Você abre o navegador e entra em: http://localhost:8080
  • environment
    Aqui é onde o WordPress descobre o banco. Tudo conversa pelo nome do serviço (mysql). Não precisa de IP, não precisa de mágica.
  • volumes: ./:/var/www/html
    Isso aqui é o ouro: WordPress inteiro fica na sua máquina, mas o Apache lê de dentro do container. Salvou o arquivo? Dá refresh e pronto.

mysql

Banco MySQL padrão, sem firula.

  • Ele pega o nome do banco, usuário e senha via envs.
  • volumes salva tudo no disco, então você pode derrubar o container e não perde nada.

phpmyadmin

Só pra quando você quer fuçar no banco.

Abre em: http://localhost:8081

wpcli

Esse é o comando mágico. Você consegue rodar WP-CLI mesmo no Windows, sem instalar nada. Ele usa o mesmo volume e o mesmo banco do WordPress, então tudo funciona.

Comandos úteis pra rodar tudo

Com o arquivo salvo como compose.yaml, você roda:

Subir tudo

Zsh
docker compose up -d

O -d é só pra rodar em segundo plano. Ou ele trava seu terminal.

Ver se está tudo rodando

Zsh
docker compose ps

Ver os logs (do WordPress, por exemplo)

Zsh
docker compose logs -f wordpress

Derrubar os containers

Zsh
docker compose down

Derrubar tudo + volumes (cuidado)

Zsh
docker compose down -v

Isso apaga banco, dados, tudo. Use só quando você quer resetar o ambiente.

Se der ruim, você derruba e sobe de novo. Se quiser testar PHP 8.2, troca a imagem e pronto. Se quiser resetar o banco, down -v. Nada de reinstalar servidor, mexer em porta maldita, editar arquivo no C:\xampp\apache\conf às 2h da manhã.

No fim das contas…

A real é que qualquer projeto com Docker deixa seu workflow mais limpo, mais previsível e com menos chances de perder horas debugando bug que nem era seu.