Docker

Projeto autoral para estudar Protheus em Docker com configuração versionada, automação operacional e práticas iniciais de DevOps.

No Lab 04 do PostgreSQL Reliability Lab , construí uma réplica física por streaming e validei que ela recebia as alterações do servidor principal. Ainda faltava responder à pergunta mais importante diante de uma falha: Quem decide que a réplica deve assumir, como os clientes encontram o novo servidor de escrita e o que acontece quando o antigo servidor retorna? O Lab 05 já está disponível no GitHub . Ele evolui o cenário anterior para um cluster local com PostgreSQL 16, Patroni, etcd e HAProxy. O roteiro interrompe abruptamente o líder, aguarda a promoção automática, volta a escrever pelo mesmo endereço e reintegra o antigo líder como réplica. ...

Depois de organizar o ambiente, automatizar sua preparação e exercitar o backup e a restauração do PostgreSQL, faltava responder a uma pergunta: o que pode ser validado continuamente sem distribuir os artefatos do Protheus nem iniciar o ERP? A quinta parte do Protheus Docker Lab encerra esta série com um workflow de integração contínua para a configuração versionada e os scripts do projeto. Ela também registra os limites dessa automação, porque um pipeline aprovado não significa, sozinho, que o ambiente Protheus está funcional. ...

Depois de automatizar a configuração local , precisamos saber o que acontece com os dados quando o ambiente para, volta ou tem seus contêineres recriados. A Parte 4 do Protheus Docker Lab já está publicada. Ela reúne o inventário de persistência, o backup do PostgreSQL, um ensaio de restauração em banco separado e a rotina de manutenção. Este artigo acompanha a versão 4310980 do repositório . As evidências citadas são as documentadas na execução de 12/09/2026. ...

O Lab 04 já está disponível no GitHub . Ele mantém uma réplica física do PostgreSQL atualizada por streaming e permite observar o que acontece quando ela fica temporariamente indisponível. Depois de exercitar backup, restore e PITR no Lab 03 , o próximo passo é acompanhar alterações continuamente. A replicação envia registros de WAL (Write-Ahead Log, o registro de alterações do PostgreSQL) do servidor principal, ou primary, à réplica, que os reproduz sobre uma cópia física do cluster. ...

Ao estruturar os primeiros labs do PostgreSQL Reliability Lab, a pergunta que orientava cada etapa foi ficando mais exigente. Na fundação, eu precisava preparar um ambiente que pudesse ser iniciado e validado. Na inicialização, precisava entregar uma base com estrutura, permissões e dados coerentes. Em backup e recuperação, precisava demonstrar que o estado recuperado correspondia ao que o teste esperava. Essa evolução mudou o que considero uma entrega concluída em um laboratório. ...

Versão de referência: este artigo foi revisado com base no commit 3dfe986 , que registra a automação e a validação local da terceira parte do Protheus Docker Lab. Um ambiente reproduzível não deveria depender de uma lista de comandos lembrada apenas por quem o criou. Depois de organizar os serviços e arquivos do Protheus Docker Lab , a etapa seguinte foi transformar o procedimento documentado em um fluxo operacional pequeno, previsível e seguro para os arquivos locais. ...

Um container pode estar em execução sem que o PostgreSQL aceite conexões. O PostgreSQL pode aceitar conexões sem que o banco esperado, as roles, os schemas ou as tabelas estejam disponíveis. E todos esses objetos podem existir sem que os dados necessários tenham sido carregados corretamente. Ainda assim, é comum resumir essas situações a uma única informação: healthy O problema não está no healthcheck. O problema está em interpretar uma verificação específica como prova de que todo o sistema está pronto. ...

Versão de referência: este artigo foi revisado com base no commit 77562cd , que registra o estado validado da segunda parte do Protheus Docker Lab. No primeiro artigo da série, Construindo um laboratório Protheus com Docker , montei um ambiente de desenvolvimento composto por PostgreSQL, DBAccess, License Server e AppServer. Colocar os serviços em execução foi a primeira etapa. A seguinte foi transformar um arquivo Compose funcional em um projeto que eu pudesse entender, validar, recriar e evoluir. ...

No Lab 02 do PostgreSQL Reliability Lab , criamos uma base reproduzível com roles, schemas, extensões, tabelas relacionadas e dados suficientes para exercitar cenários operacionais. Essa base tornou possível fazer uma pergunta mais importante do que “temos backup?”: Conseguimos restaurar o banco e recuperar os dados até o ponto necessário depois de uma falha? Um arquivo de backup que nunca foi restaurado é apenas uma expectativa. Confiabilidade exige procedimento, evidência e conhecimento dos limites de recuperação. ...