DevOps

Onde acabam as variáveis de ambiente de um container Suba um container com -e DB_PASSWORD=hunter2 e rode docker inspect nele: 1 2 docker run -d --name api -e DB_PASSWORD=hunter2 nginx:alpine docker inspect --format '{{json .Config.Env}}' api 1 ["DB_PASSWORD=hunter2","PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"] A senha fica ali em texto plano, legível por qualquer um com acesso ao socket do Docker, por docker exec api env e por qualquer processo rodando dentro do container. Isso não é um bug — é exatamente para isso que as variáveis de ambiente existem. O problema é usá-las para valores que nunca deveriam ficar tão visíveis. ...

Por que uma imagem Docker pesa dez vezes mais que o app Um serviço Node com poucas centenas de kilobytes de código-fonte vira uma imagem com mais de 1 GB. Esse é o resultado normal de um build que funciona, não um erro em uma linha específica. O peso vem de uma imagem base que carrega um sistema operacional completo, uma toolchain de build que o app em execução nunca chama, e um cache do gerenciador de pacotes que ninguém mandou o build apagar. ...

O que um Dockerfile mal escrito custa 1 2 3 4 5 6 FROM node:latest COPY . . RUN npm install CMD ["node", "server.js"] Quatro linhas, e cada uma custa alguma coisa. O docker build roda npm install de novo a cada mudança no código, porque COPY . . quebra o cache de camadas antes que o passo de instalação tenha chance de ser reaproveitado. A imagem final carrega toda a base Debian, a árvore inteira de node_modules incluindo as dependências de desenvolvimento, e qualquer ferramenta de build que o npm install tenha baixado para compilar módulos nativos. Nada é descartado. O container roda como root, porque nada diz o contrário, e node:latest significa que a imagem base pode mudar de uma build para outra sem deixar registro do que você realmente publicou. ...

O problema que o Compose resolve Uma aplicação real quase nunca é um container só. Uma API web precisa de um banco de dados, o banco precisa de um volume para os dados sobreviverem a um reinício, e depois você adiciona um cache Redis e um worker em segundo plano. São quatro comandos docker run, cada um com suas flags de portas, volumes, variáveis de ambiente e uma rede compartilhada. Na ordem certa. Toda vez que você senta para trabalhar. ...

Por que dois containers no mesmo host não se enxergam por padrão Suba o Postgres e sua API com um docker run simples, e a API não consegue alcançar o banco de dados, mesmo com os dois containers rodando na mesma máquina. 1 2 docker run -d --name db postgres:16 docker run -d --name api myapp Os dois caem na bridge padrão do Docker, aquela em que todo container Docker entra a menos que você diga o contrário. Eles recebem um endereço IP. O que não recebem é uma forma de se encontrarem pelo nome — a API teria que ter o IP interno do banco fixado no código, um endereço que muda a cada reinício do container. ...

O Docker e o Podman executam as mesmas imagens com os mesmos comandos. O que os separa é a arquitetura: o Podman não tem daemon em segundo plano e roda rootless por padrão, enquanto o Docker traz o ferramental maduro, o Docker Desktop e o Compose de primeira classe. Abaixo, as diferenças que de fato afetam o seu trabalho: daemon, root, Compose e pods. O Que é Podman? Podman (Pod Manager) é uma ferramenta para gerenciar containers e pods, desenvolvida pela Red Hat como alternativa open source ao Docker. Sua característica principal? Não precisa de um daemon em execução. ...

O que o Docker faz de verdade O Docker é uma plataforma open source que empacota uma aplicação com tudo o que ela precisa para rodar — código, bibliotecas, runtime, configuração — em um container que se comporta igual em qualquer máquina. Uma mudança de casa ilustra bem o trade-off. Você tem duas opções: Levar todos os seus objetos soltos, esperando que cheguem intactos Colocar tudo em caixas organizadas, etiquetadas e fáceis de transportar O Docker faz exatamente isso com as aplicações de software: as “empacota” em containers que contêm tudo o necessário para funcionar. ...

O que o Kubernetes faz Rodar um container Docker em uma máquina, na mão, é fácil. Rodar cinquenta containers em dez máquinas — reiniciando cada um quando cai, movendo-os quando uma máquina morre, dividindo o tráfego entre eles, atualizando sem downtime — não é. O Kubernetes (abreviado como K8s) é o sistema que faz esse gerenciamento por você. O Que é Kubernetes? Kubernetes é uma plataforma de código aberto para orquestração de containers. Foi criada pelo Google em 2014, baseada em 15 anos de experiência gerenciando containers em larga escala, e agora é mantida pela Cloud Native Computing Foundation (CNCF). ...

Por que um container perde os dados quando reinicia Escreva uma linha em um banco de dados rodando em um container Docker, pare o container, suba de novo: a linha sumiu. Todo container recebe o sistema de arquivos novo, a partir da imagem, cada vez que inicia. Tudo o que o próprio container escreve — arquivos do banco, uploads, logs — vai para uma camada gravável que é descartada quando o container é removido. Um volume Docker é como você mantém esses dados fora do container, onde eles sobrevivem. ...