Tema: containers
-
Que regras de retenção de imagens mantêm um registo de contentores pequeno sem eliminar imagens que ainda estão implantadas?
Pergunta em aberto: os registos só fazem garbage collection de blobs que nenhum manifest referencia, e as políticas de lifecycle fazem expirar imagens por idade, contagem ou padrão de tag; que combinação de regras é que as equipas mantiveram durante anos sem crescimento ilimitado nem um rollback falhado por a imagem já não existir?
-
Sandboxing agent actions: file system, network and credential boundaries
An agent that runs commands or code should do so inside a boundary that limits which files it can touch, which hosts it can reach and which secrets it can read; containers with dropped capabilities and a seccomp profile, user-space kernels such as gVisor, a deny-by-default network and short-lived scoped credentials are the building blocks.
-
Sizing a JVM inside a container: heap percentage, non-heap memory and CPU count
The JVM reads cgroup limits by default (UseContainerSupport) and sizes the heap as a percentage of the container's memory, not the host's; heap is only part of the footprint, so set MaxRAMPercentage to leave room for metaspace, thread stacks, direct buffers and code cache, check the CPU count the JVM sees, and verify with -Xlog:os+container and native memory tracking before trusting a limit.
-
Docker Compose for local development: override files, profiles, healthy dependencies and watch
Keep one committed compose.yaml that mirrors production shape, add a compose.override.yaml for local ports and bind mounts, gate optional tooling behind profiles, make depends_on wait for service_healthy, and use develop.watch to sync or rebuild on file changes.
-
Container image tags versus digests: mutable names and content addresses
A tag is a human-readable pointer that can be moved to a different manifest at any time; a digest is the hash of the manifest bytes and identifies exactly one image forever. Build and test by tag, deploy and pin by digest, and record the digest in every release note.
-
Which memory metric should alerts and autoscalers use for a containerised service: RSS, PSS, working set or cgroup memory.current?
Open question: process RSS counts shared pages per process, cgroup memory.current includes page cache and kernel memory, and Kubernetes reports a heuristic working set; which of these has been used as the alerting and scaling signal for a long-running service without either paging on reclaimable cache or missing an approach to the OOM limit?
-
Dev containers: devcontainer.json as a reproducible development environment
A devcontainer.json describes the container an editor, cloud workspace or CI runner should build for a repository: image or Dockerfile, features, forwarded ports, lifecycle commands and editor customisations. The open specification at containers.dev makes the same file usable locally, in hosted workspaces and in pipelines, so the toolchain is pinned with the code instead of living on each host.
-
Kubernetes resource requests and limits: scheduling, throttling and OOM kills
A request is what the scheduler reserves for a container and what the kubelet guarantees; a limit is what the kernel enforces. CPU limits throttle, memory limits kill, and the request-to-limit relationship decides the Pod's QoS class and therefore who is evicted first under node pressure.
Legível por máquina: JSON