Docker

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. ...

Ao iniciar um projeto com determinadas tecnologias, é comum encontrarmos uma ferramenta capaz de criar automaticamente uma estrutura básica de aplicação. No ecossistema Node.js, por exemplo, o NestJS permite iniciar um novo projeto com um único comando: npx @nestjs/cli@latest new minha-api Esse comando cria a estrutura inicial, instala as dependências e entrega uma aplicação pronta para execução. Durante um curso de Docker e Docker Compose, percebi que os exemplos práticos utilizavam justamente essa abordagem. A aplicação em si não era o foco principal da aula. Ela servia apenas como base para estudar imagens, containers, volumes, redes e orquestração com Docker Compose. ...

No Lab 01, construímos a fundação: uma instância PostgreSQL reproduzível, persistente e validada com Docker. Mas subir um banco saudável é apenas o primeiro passo. Para testar backup, replicação, observabilidade ou performance, precisamos de uma base que se aproxime de um cenário real: usuários com responsabilidades diferentes, schemas bem definidos, extensões operacionais, relacionamentos, índices e dados suficientes para exercitar o ambiente. Esse é o objetivo do Lab 02 do PostgreSQL Reliability Lab. ...

Durante muitos anos, desenvolver para o ERP Protheus significava preparar manualmente todo o ambiente de desenvolvimento. Instalar banco de dados, configurar DBAccess, ajustar License Server, preparar AppServer, copiar arquivos de configuração e validar dependências costumava fazer parte do processo. Cada máquina acabava se tornando um ambiente único, com pequenas diferenças difíceis de rastrear. Embora esse modelo ainda seja comum em muitos projetos, ele fica distante de práticas que hoje considero essenciais em Engenharia de Software: ambientes descritos como código, configuração versionada, automação operacional e capacidade de recriar o laboratório de forma previsível. ...

Durante muito tempo, enxerguei DevOps como algo distante da minha realidade. Parecia um assunto sempre associado a Kubernetes, pipelines complexos e uma infinidade de ferramentas que, sinceramente, não faziam muito sentido no meu dia a dia com ERP Protheus e banco de dados. Mas essa percepção começou a mudar quando retomei meus estudos e passei a olhar para DevOps de uma forma mais prática. DevOps não é apenas sobre ferramentas. É, principalmente, sobre criar ambientes mais previsíveis, automatizados e confiáveis. ...

Um dos problemas mais comuns ao trabalhar com banco de dados é a falta de consistência entre ambientes. Quantas vezes já vimos situações como: “Na minha máquina funciona” Diferenças entre desenvolvimento, homologação e produção Dados que não persistem após reiniciar o ambiente Dificuldade em reproduzir bugs Esses problemas geralmente não estão relacionados ao código da aplicação, mas sim à forma como o ambiente de banco de dados é configurado. Neste post, vou mostrar como construir um ambiente PostgreSQL utilizando Docker com foco em reprodutibilidade, persistência e confiabilidade, servindo como base para cenários mais avançados. ...