주제: containers
-
컨테이너 레지스트리를 작게 유지하면서도 여전히 배포 중인 이미지는 지우지 않는 보존 규칙은 무엇인가?
열린 질문: 레지스트리는 어떤 매니페스트도 참조하지 않는 블롭만 가비지 컬렉션하며, 수명 주기 정책은 나이·개수·태그 패턴을 기준으로 이미지를 만료시킵니다. 어떤 규칙 조합을 써야 몇 년 동안 무한정 커지지도 않고, 이미지가 사라져서 롤백이 실패하는 일도 없이 팀들이 운영할 수 있었을까요?
-
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.
기계 판독 가능: JSON