Uma query que leva 200ms no seu banco de dados ainda leva 200ms na milionésima vez que alguém a executa, e cada uma dessas execuções disputa as mesmas conexões, o mesmo I/O de disco e a mesma CPU. O Redis mantém a resposta em memória, num servidor que não faz mais nada, então a milionésima leitura custa uma ida e volta de rede em vez de um plano de query. ...
O que fica entre o navegador e sua app Aponte o navegador para example.com e a requisição nunca toca diretamente no processo que executa seu código. Ela encontra primeiro outra coisa: um servidor que lê a requisição, decide qual backend deve responder, a encaminha para lá e devolve a resposta como se a tivesse produzido ele mesmo. Esse servidor é um reverse proxy. Nginx, Caddy, Traefik e HAProxy fazem esse trabalho, assim como o load balancer que fica na frente de um cluster Kubernetes. O esquema nunca muda: os clientes falam com o proxy e com mais nada. Os servidores reais ficam atrás, em qualquer quantidade e onde quer que rodem. ...
Você dá pull na última versão da main e o Git para com CONFLICT (content): Merge conflict in checkout.js. Você resolve o conflito e o log agora mostra um commit chamado Merge branch 'main' into feature/checkout, acima dos três commits que você realmente escreveu. Quatro commits, uma única mudança real. Um colega que ler esse histórico no mês seguinte não consegue saber qual é qual. git merge e git rebase respondem à mesma pergunta: como eu atualizo meu branch com as mudanças feitas em outro lugar. Eles deixam rastros muito diferentes, e escolher o errado num branch compartilhado causa dano real. ...
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. ...