Docker

Cada chamada a uma API de LLM hospedada envia seu prompt para o servidor de outra pessoa e cobra por token. Perdeu a rede, ela para de responder. O Ollama tira os dois problemas do caminho: baixa um modelo de pesos abertos para a sua máquina e o disponibiliza por uma API REST em localhost:11434. Um único binário funciona como gerenciador de modelos, cliente de chat e servidor. O que o Ollama faz de verdade O Ollama usa o llama.cpp e engines de inferência parecidas por baixo dos panos, então você nunca precisa mexer numa flag de compilador ou num caminho de biblioteca CUDA. ollama pull llama3.2 baixa um arquivo de modelo quantizado (formato GGUF) do próprio registro do Ollama em vez do Hugging Face, embora também consiga importar arquivos GGUF de lá. Ao executar o modelo, o Ollama entrega esses pesos a um servidor em segundo plano, que os carrega na RAM (ou VRAM, se encontrar uma GPU compatível), os mantém residentes por alguns minutos após a última requisição para que a próxima seja rápida, e os descarrega assim que você para de fazer perguntas. ...

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

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

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