テーマ： containers
-
デプロイ済みのイメージを削除することなくコンテナレジストリを小さく保つには、どのイメージ保持ルールがよいか
未解決の問い: レジストリは、どのマニフェストからも参照されなくなったblobだけをガベージコレクションし、ライフサイクルポリシーは経過時間・件数・タグパターンによってイメージを期限切れにする。無制限な増大も、イメージが消えていたことによるロールバックの失敗も起こさずに、チームが何年も運用してきたルールの組み合わせはどのようなものか。
-
ホストのcgroups v2：モードを確認し、ユニットごとのリソース上限を読む
現在のコンテナーランタイムとsystemdは、メモリーとCPUの上限を適用するためにcgroups v2（統一階層）を使います。この手順では、ホストが統一モードであることの確認、systemd-cgls/systemd-cgtopによるツリーの閲覧、ユニットやコンテナーの実際の上限の読み取りを扱います。
-
docker/podman run exit codes: 125, 126, 127, and the signal codes that reach through them
docker run reserves 125, 126 and 127 for failures of Docker itself, an uninvokable command, and a not-found command respectively; any other code is passed through unchanged from the containerized process, including the 128+signal codes (137 for SIGKILL, often OOM; 139 for SIGSEGV; 143 for SIGTERM). The container's own OOMKilled flag, not the bare 137, is the documented way to confirm an out-of-memory kill, though on some cgroup-v2 hosts it reads false even after a kernel OOM kill.
-
エージェントの操作をサンドボックス化する：ファイル、ネットワーク、認証情報の境界
コマンドやコードを実行するエージェントは、触れられるファイル、到達できるホスト、読める秘密情報を制限する境界内で動かすべきである。capabilities の削除と seccomp プロファイルを備えたコンテナ、gVisor などのユーザー空間カーネル、既定で拒否するネットワーク、範囲を絞った短寿命の認証情報が構成要素になる。
-
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ソケットへのアクセスはホストのroot権限：コンテナへのマウントが実際に与えるもの
Dockerデーモンと通信できる人は、ホストのルートファイルシステムを完全なアクセス権でマウントするコンテナを起動できます。そのため、/var/run/docker.sockのコンテナへのマウント、ユーザーのdockerグループへの追加、TCP経由でのAPI公開は、root権限の付与に相当します。
-
Godot Control Layout: Decide Who Owns Position and Size
Use anchors and offsets for parent-relative placement, let containers arrange their children, and inspect content-driven size constraints when an interface refuses the expected geometry.
-
Running Podman containers as systemd services with Quadlet
Quadlet lets systemd manage Podman containers directly from declarative .container unit files, replacing the deprecated podman generate systemd workflow. This methodology covers file locations for system and user services, activation, and the auto-update label.
-
Alpine Linux for agents: apk add/del/upgrade, --no-cache in containers, and pinning a package version
apk tracks explicitly requested packages in /etc/apk/world and repository sources in /etc/apk/repositories; apk add/apk del edit both files together with installing or removing files, apk upgrade re-syncs the index and updates everything in world, and a package can be pinned to an exact version or to a tagged repository. --no-cache skips the local package cache entirely, which is the form used in container image builds.
-
musl versus glibc on Alpine: why some prebuilt binaries, Python wheels and DNS behaviour differ
Alpine's musl libc is not binary-compatible with glibc, has a different (parallel, non-search-falling-back) DNS resolver, defaults to the C.UTF-8 locale rather than a full locale database, and does not support lazy symbol binding — differences that explain glibc-linked binaries failing to run, manylinux Python wheels being rejected, and some legacy DNS configurations behaving differently. gcompat can run some unmodified glibc binaries but cannot be used to build software that itself requires glibc headers.
-
Git's "detected dubious ownership in repository" error and the safe.directory fix
Git refuses to operate in a repository owned by a different user than the one running the command, quoting 'fatal: detected dubious ownership in repository at'. The article explains the CVE-2022-24765 fix behind it, when a per-repo safe.directory entry is right, and why chown is the better fix in containers and CI.
-
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.
-
コンテナイメージのタグとダイジェスト：可変の名前と内容アドレス
タグは人が読めるポインターで、いつでも別のマニフェストへ移せる。ダイジェストはマニフェストのバイト列のハッシュであり、永久に正確に1つのイメージを識別する。ビルドとテストにはタグ、デプロイと固定にはダイジェストを使い、すべてのリリースノートにダイジェストを記録する。
-
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?
-
Podman rootless versus rootful on RHEL-family hosts: storage, subuid, and lingering
Podman runs containers as an ordinary user (rootless) or as root (rootful), with different storage locations and privilege boundaries. This methodology covers inspecting running containers, finding storage paths, setting up subordinate UID/GID ranges, and keeping rootless services alive without a login session.
-
開発コンテナ：devcontainer.json で再現可能な開発環境を定義する
devcontainer.json は、エディター、クラウドワークスペース、CI ランナーがリポジトリ用に構築すべきコンテナを記述する。イメージまたは Dockerfile、features、転送ポート、ライフサイクルコマンド、エディター設定を含む。containers.dev の公開仕様により、同じファイルをローカル、ホスト型ワークスペース、パイプラインで使い、各ホストではなくコードとともにツールチェーンを固定できる。
-
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.
-
LXC/Incus system containers: what they are and when to reach for one instead of an application container
Incus (a community fork of LXD) manages system containers and virtual machines with one tool. A system container runs a full init system and multiple services like a lightweight VM, unlike an application container built around one process — a distinction worth knowing before picking either for a host workload.
-
Troubleshooting containers from the host with lsns and nsenter
When a container's own tools are too minimal to debug a networking problem, entering its namespaces from the host with nsenter lets you run full host utilities such as ss or ip against the container's environment. This methodology covers finding the container's PID and namespace, and the difference between entering all namespaces and just one.
-
Docker Engine host administration: daemon.json, disk usage, and live-restore
Administering the Docker Engine on a host means the daemon's configuration file, not application Dockerfiles: log rotation defaults, where images and containers are stored, safely reclaiming disk space, and keeping containers running across a daemon restart.
機械可読： JSON