Promovendo um WordPress de domínio temporário para produção de forma automatizada

Trocar um WordPress de domínio temporário para o domínio definitivo parece uma tarefa pequena até listar tudo que pode ficar apontando para o endereço antigo.

Em um toolkit próprio de provisionamento, o fluxo foi desenhado para validar primeiro e promover depois.

A instalação nasce em um domínio temporário. Só depois de DNS, container e aplicação estarem funcionando é executada uma promoção que atualiza, no mesmo fluxo:

1
2
3
4
router do Traefik
home do WordPress
siteurl do WordPress
search-replace no banco

O objetivo é reduzir uma mudança manual cheia de pequenos pontos de divergência.

Por que usar domínio temporário #

O domínio temporário cria uma fase intermediária em que dá para verificar:

container subiu;
banco responde;
WordPress abre;
Traefik conhece a rota;
DNS temporário resolveu;
conteúdo e administração estão utilizáveis.

Sem isso, provisionamento e cutover acontecem ao mesmo tempo.

Quando alguma coisa falha, fica mais difícil responder se o problema está na aplicação nova ou na troca do domínio.

O fluxo do `wpctl` #

A ferramenta que serviu de fonte para este artigo padroniza operações de WordPress em Docker.

A promoção conceitualmente é:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
site temporário validado
        ↓
validar credenciais/DNS
        ↓
criar/ajustar DNS definitivo
        ↓
esperar propagação
        ↓
atualizar router Traefik
        ↓
atualizar WordPress home/siteurl
        ↓
search-replace no banco
        ↓
validar domínio definitivo

Não é necessário que todas essas etapas estejam dentro do mesmo comando em qualquer ambiente. O importante é que a promoção seja repetível e verificável.

`home` e `siteurl` são só parte do problema #

WordPress mantém URLs em mais lugares que as duas opções principais.

É comum encontrar o domínio antigo em:

conteúdo de posts e páginas;
metadados;
widgets;
opções de plugins;
configurações de tema;
URLs de mídia.

Por isso a promoção usa também search-replace.

Com WP-CLI, um padrão seguro é começar com dry-run:

1
2
3
4
5
wp search-replace \
  'https://preview.example' \
  'https://www.example.com' \
  --all-tables-with-prefix \
  --dry-run

Depois de revisar o resultado:

1
2
3
4
wp search-replace \
  'https://preview.example' \
  'https://www.example.com' \
  --all-tables-with-prefix

WP-CLI entende dados serializados do WordPress, o que é preferível a um sed ou UPDATE genérico no dump.

DNS entra antes do certificado #

O fluxo do toolkit também espera propagação de DNS antes de seguir para a ativação definitiva.

Isso evita pedir certificado enquanto o hostname ainda resolve para outro destino.

Uma validação simples:

1
dig +short www.example.com

ou:

1
getent ahosts www.example.com

Só depois da resolução esperada faz sentido avançar para emissão/validação TLS.

Credenciais Cloudflare não pertencem ao Git #

Na implementação recuperada, credenciais por conta ficam em arquivo próprio, fora do versionamento, com permissão restrita.

Conceitualmente:

1
chmod 600 credencial-cloudflare.env

A automação usa a credencial no momento da operação; o repositório contém somente lógica e referências, nunca o token real.

A promoção também precisa de lock #

Se duas operações de promoção forem executadas ao mesmo tempo para o mesmo site, uma pode alterar DNS ou configuração enquanto a outra ainda valida o estado anterior.

O toolkit usa controle de concorrência para evitar esse tipo de corrida.

Em shell, flock é uma opção simples:

1
2
flock -n /run/lock/wpctl-site.lock \
  wpctl promote site-exemplo

O mecanismo específico pode variar, mas a regra continua válida: promoção é operação de estado e não deve correr duas vezes em paralelo sem intenção explícita.

Validar antes e depois #

Eu separaria as validações em quatro camadas.

DNS #

1
dig +short www.example.com

TLS #

1
curl -vkI https://www.example.com/

HTTP #

1
2
3
curl -sS -o /dev/null \
  -w '%{http_code} %{url_effective}\n' \
  https://www.example.com/

WordPress #

1
2
wp option get home
wp option get siteurl

E, quando aplicável, uma busca pelo domínio antigo:

1
2
3
4
5
wp search-replace \
  'https://preview.example' \
  'https://www.example.com' \
  --all-tables-with-prefix \
  --dry-run

O dry-run final deveria retornar zero substituições relevantes.

Rollback precisa existir antes da promoção #

Uma promoção automatizada não elimina a necessidade de rollback.

Antes da mudança eu preservaria:

1
2
3
4
configuração/router anterior
valores home/siteurl
backup ou snapshot do banco
estado DNS anterior quando controlado pela automação

Se a validação final falhar, o processo precisa saber qual estado restaurar.

O que foi automatizado de verdade neste projeto #

A fonte recuperada do wpctl comprova:

uso de domínio temporário para validação;
DNS multi-conta via Cloudflare;
espera de propagação DNS;
credenciais fora do Git;
promoção que troca router Traefik;
atualização de home e siteurl;
search-replace no banco;
controle contra operações concorrentes.

Isso é suficiente para tratar promoção como um runbook executável, e não como uma lista de passos lembrada pelo operador.

Checklist #

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
[ ] site temporário validado
[ ] backup/snapshot disponível
[ ] DNS definitivo criado
[ ] propagação confirmada
[ ] router/proxy atualizado
[ ] TLS válido
[ ] home atualizado
[ ] siteurl atualizado
[ ] search-replace executado
[ ] domínio antigo não aparece onde não deveria
[ ] front validado
[ ] wp-admin validado
[ ] rollback documentado

O principal aprendizado #

Automatizar uma promoção de domínio não é apenas automatizar DNS.

É tratar DNS, proxy, TLS, estado do WordPress e banco como uma única mudança que precisa terminar em estado conhecido.

O domínio temporário deixa de ser gambiarra e vira uma etapa controlada do deploy.