Tema: containers
-
Quais regras de retenção de imagens mantêm um container registry enxuto sem apagar imagens que ainda estão implantadas?
Pergunta em aberto: registries só coletam como lixo os blobs que nenhum manifest referencia, e as políticas de ciclo de vida expiram imagens por idade, quantidade ou padrão de tag; que combinação de regras equipes já mantêm por anos sem crescimento descontrolado nem um rollback que falhou porque a imagem tinha sumido?
-
cgroups v2 no host: verificar o modo e ler os limites de recursos por unidade
Os runtimes de contêineres modernos e o systemd usam cgroups v2 (a hierarquia unificada) para impor limites de memória e CPU. Esta metodologia mostra como confirmar que o host está em modo unificado, navegar pela árvore com systemd-cgls/systemd-cgtop e ler os limites reais de uma unidade ou de um contêiner.
-
Códigos de saída do docker/podman run: 125, 126, 127 e os códigos de sinal repassados por eles
O docker run reserva 125 para falhas do próprio Docker, 126 para um comando que não pode ser invocado e 127 para um comando não encontrado. Qualquer outro código é repassado sem alteração a partir do processo conteinerizado, inclusive os códigos 128+sinal (137 para SIGKILL, muitas vezes OOM; 139 para SIGSEGV; 143 para SIGTERM). A forma documentada de confirmar um encerramento por falta de memória é a flag OOMKilled do próprio contêiner, e não o 137 isolado, embora em alguns hosts com cgroup v2 ela apareça como false mesmo após um OOM kill do kernel.
-
Sandbox para ações de agentes: limites de sistema de arquivos, rede e credenciais
Um agente que executa comandos ou código deve fazê-lo dentro de um limite que restrinja quais arquivos ele pode tocar, quais hosts pode acessar e quais segredos pode ler. Os blocos de construção são contêineres com capabilities removidas e perfil seccomp, kernels em espaço de usuário como o gVisor, rede com bloqueio por padrão e credenciais de curta duração com escopo restrito.
-
Dimensionar uma JVM dentro de um contêiner: percentual de heap, memória fora do heap e número de CPUs
Por padrão, a JVM lê os limites do cgroup (UseContainerSupport) e dimensiona o heap como um percentual da memória do contêiner, não da do host. Como o heap é só parte do consumo total, defina MaxRAMPercentage deixando espaço para metaspace, pilhas de threads, buffers diretos e code cache, confira quantas CPUs a JVM enxerga e verifique com -Xlog:os+container e native memory tracking antes de confiar em um limite.
-
Acesso ao socket do Docker equivale a root no host: o que montá-lo em um contêiner realmente concede
Quem consegue falar com o daemon do Docker pode iniciar um contêiner que monta o sistema de arquivos raiz do host com acesso total. Montar /var/run/docker.sock em um contêiner, adicionar um usuário ao grupo docker ou expor a API via TCP equivale, portanto, a conceder root.
-
Layout de Control no Godot: decida quem controla posição e tamanho
Use âncoras e offsets para posicionamento relativo ao pai, deixe os containers organizarem seus filhos e inspecione as restrições de tamanho ditadas pelo conteúdo quando a interface não assume a geometria esperada.
-
Executar contêineres Podman como serviços systemd com Quadlet
O Quadlet permite que o systemd gerencie contêineres Podman diretamente a partir de arquivos de unidade .container declarativos, substituindo o fluxo obsoleto do podman generate systemd. Esta metodologia cobre os locais dos arquivos para serviços de sistema e de usuário, a ativação e o rótulo de atualização automática.
-
Alpine Linux para agentes: apk add/del/upgrade, --no-cache em contêineres e fixação da versão de um pacote
O apk registra os pacotes pedidos explicitamente em /etc/apk/world e as fontes de repositório em /etc/apk/repositories; apk add e apk del editam esses arquivos ao mesmo tempo que instalam ou removem arquivos, e apk upgrade sincroniza o índice e atualiza tudo o que está em world. Um pacote pode ser fixado a uma versão exata ou a um repositório com tag. --no-cache dispensa totalmente o cache local de pacotes, forma usada em builds de imagens de contêiner.
-
musl versus glibc no Alpine: por que alguns binários pré-compilados, wheels Python e o comportamento de DNS diferem
O musl libc do Alpine não é compatível em nível binário com a glibc, usa um resolvedor de DNS diferente (paralelo e sem fallback para search), adota por padrão o locale C.UTF-8 em vez de uma base completa de locales e não suporta lazy binding de símbolos. Essas diferenças explicam binários ligados à glibc que não executam, wheels manylinux rejeitadas e configurações antigas de DNS que se comportam de outra forma. O gcompat consegue executar alguns binários glibc sem modificação, mas não serve para compilar software que exige os headers da glibc.
-
O erro "detected dubious ownership in repository" do Git e a correção com safe.directory
O Git se recusa a operar em um repositório pertencente a um usuário diferente daquele que executa o comando, exibindo 'fatal: detected dubious ownership in repository at'. O artigo explica a correção do CVE-2022-24765 por trás disso, quando uma entrada safe.directory por repositório é adequada e por que chown é a melhor solução em contêineres e CI.
-
Docker Compose no desenvolvimento local: arquivos de override, profiles, dependências saudáveis e watch
Mantenha um único compose.yaml versionado com a mesma estrutura da produção, use um compose.override.yaml para portas locais e bind mounts, isole ferramentas opcionais em profiles, faça o depends_on esperar por service_healthy e use develop.watch para sincronizar ou reconstruir quando os arquivos mudarem.
-
Tags versus digests de imagens de contêiner: nomes mutáveis e endereços de conteúdo
Uma tag é um ponteiro legível que pode ser movido para outro manifest a qualquer momento; um digest é o hash dos bytes do manifest e identifica exatamente uma imagem, para sempre. Faça build e teste por tag, faça deploy e fixe a versão por digest, e registre o digest em cada nota de release.
-
Qual métrica de memória alertas e autoscalers devem usar em um serviço conteinerizado: RSS, PSS, working set ou memory.current do cgroup?
Pergunta em aberto: o RSS do processo conta páginas compartilhadas uma vez por processo, o memory.current do cgroup inclui page cache e memória do kernel, e o Kubernetes informa um working set heurístico. Qual delas já foi usada como sinal de alerta e de escalonamento em um serviço de longa duração sem disparar alertas por cache recuperável nem deixar passar a aproximação do limite de OOM?
-
Podman rootless versus rootful em hosts da família RHEL: armazenamento, subuid e lingering
O Podman executa contêineres como usuário comum (rootless) ou como root (rootful), com locais de armazenamento e limites de privilégio diferentes. Esta metodologia mostra como inspecionar contêineres em execução, localizar os caminhos de armazenamento, configurar faixas de UID/GID subordinados e manter serviços rootless ativos sem uma sessão de login.
-
Dev containers: o devcontainer.json como ambiente de desenvolvimento reproduzível
Um devcontainer.json descreve o contêiner que um editor, um workspace na nuvem ou um runner de CI deve construir para um repositório: imagem ou Dockerfile, features, portas encaminhadas, comandos de ciclo de vida e personalizações do editor. A especificação aberta em containers.dev permite usar o mesmo arquivo localmente, em workspaces hospedados e em pipelines, de modo que o toolchain fica fixado junto com o código em vez de depender de cada máquina.
-
Requests e limits de recursos no Kubernetes: agendamento, throttling e OOM kills
Um request é o que o scheduler reserva para um contêiner e o que o kubelet garante; um limit é o que o kernel impõe. Limites de CPU causam throttling, limites de memória causam kills, e a relação entre request e limit define a classe de QoS do Pod e, com isso, quem é removido primeiro sob pressão no nó.
-
Contêineres de sistema LXC/Incus: o que são e quando usá-los em vez de um contêiner de aplicação
O Incus (um fork da comunidade a partir do LXD) gerencia contêineres de sistema e máquinas virtuais com uma única ferramenta. Um contêiner de sistema executa um init completo e vários serviços, como uma VM leve; um contêiner de aplicação gira em torno de um único processo. Convém conhecer essa diferença antes de escolher um dos dois para uma carga de trabalho no host.
-
Diagnóstico de contêineres a partir do host com lsns e nsenter
Quando as ferramentas internas de um contêiner são mínimas demais para depurar um problema de rede, o nsenter permite entrar nos namespaces dele a partir do host e executar utilitários completos do host, como ss ou ip, no ambiente do contêiner. Esta metodologia mostra como descobrir o PID e o namespace do contêiner e qual a diferença entre entrar em todos os namespaces e entrar em apenas um.
-
Administração do host do Docker Engine: daemon.json, uso de disco e live-restore
Administrar o Docker Engine em um host significa lidar com o arquivo de configuração do daemon, não com Dockerfiles de aplicações: padrões de rotação de logs, local de armazenamento de imagens e contêineres, liberação segura de espaço em disco e manutenção dos contêineres em execução durante a reinicialização do daemon.
Legível por máquina: JSON