Guias praticos e perenes para programadores. Cada um parte de comandos reais e exemplos que funcionam, e diz com clareza quando nao usar a ferramenta que explica.
Abaixo esta tudo, do mais recente ao mais antigo.
Guias praticos e perenes para programadores. Cada um parte de comandos reais e exemplos que funcionam, e diz com clareza quando nao usar a ferramenta que explica.
Abaixo esta tudo, do mais recente ao mais antigo.
Pergunte a um LLM genérico qual é a política de reembolso da sua empresa ou o que diziam os tickets de suporte da semana passada, e ele vai dizer que não sabe ou vai inventar algo plausível. O conhecimento dele para no que estava nos dados de treinamento. Ele nunca viu os seus documentos e não pode ir consultá-los no meio da conversa. A retrieval-augmented generation (RAG) resolve exatamente isso: antes de o modelo responder, uma etapa separada encontra o texto relevante nos seus próprios dados e o entrega ao modelo como parte do prompt. ...
docker build && docker push a partir do seu computador funciona até outra pessoa precisar publicar a mesma imagem, ou até isso precisar acontecer a cada merge sem você estar no teclado. O GitHub Actions executa essa build nos runners do GitHub, marca a tag da imagem de acordo com o que disparou o workflow e a publica em um registry de onde a sua etapa de deploy pode fazer pull. Nada roda localmente. ...
Execute kubectl run nginx --image=nginx:1.27 e o Kubernetes cria exatamente um Pod chamado nginx. Apague-o com kubectl delete pod nginx e ele some de vez — ninguém percebe, ninguém o substitui. Um Pod é a menor unidade implantável no Kubernetes: um ou mais containers que compartilham um namespace de rede e um conjunto de volumes, agendados juntos em um único Node. Esse Pod isolado é um beco sem saída em produção. Se o container dentro dele travar, o kubelet o reinicia no mesmo lugar. Se o Node reiniciar, ou alguém apagar o Pod, nada o recria. Nada guarda a memória de que ele deveria existir. ...
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. ...