Dock Stay
コンテナトピック一覧
Dock Stay

コンテナトピック一覧

カテゴリ別にコンテナ関連の重要トピックを解説

基礎

linux namespaces Linux Namespaces はプロセスごとに「見える世界」を分離する仕組み。PID・Mount・Network・UTS・IPC・User・cgroup の 7 種があり、コンテナのプロセス隔離の中核を担う。
cgroups cgroups（Control Groups）はプロセス群の CPU・メモリ・IO などのリソース使用量を制限・計測する Linux カーネルの仕組み。namespace と対になってコンテナの基盤を成す。
OCI spec OCI はコンテナのイメージ・実行・配布形式を標準化する業界団体。Image Spec / Runtime Spec / Distribution Spec の 3 本柱で、Docker・Podman・containerd などが同じ成果物を扱える。

VM との比較

container vs VM コンテナと VM はどちらもワークロードを隔離する技術だが、カーネル共有の有無で性能・密度・隔離強度が大きく変わる。用途ごとに使い分ける。
Firecracker / gVisor / Kata Firecracker・gVisor・Kata Containers はコンテナの軽さと VM の強い隔離を両立させるための技術。AWS Lambda など、信頼できないコードを大量に安全に動かす場面で使われる。

Docker

docker run イメージから新しいコンテナを起動するコマンド。`-d` でバックグラウンド化、`-p` でポート公開、`-v` でボリュームマウント、`--name` で名前付けなど、日常的に使うオプションを押さえておく。
docker build Dockerfile からイメージをビルドするコマンド。ビルドコンテキスト、`-f` の Dockerfile 指定、`-t` のタグ付け、BuildKit のキャッシュ最適化、`--target` によるマルチステージ制御を押さえる。
docker ps / docker logs 実行中コンテナの一覧表示とログ確認のコマンド。`docker ps -a` で停止済みも含めて表示、`docker logs -f` で追跡、`--since` / `--tail` で範囲を絞る。
docker exec 実行中のコンテナに追加プロセスを起動するコマンド。多くは `-it` でシェルに入り、ログやファイルシステム、プロセス状態を調査するために使う。
docker images / docker system prune ローカルのイメージ一覧と、使われていないリソースの一括削除。ビルドを繰り返していると数十 GB に膨らむので、定期的に掃除する。
docker network コンテナのネットワーク管理。bridge / host / none / user-defined の 4 種類を理解し、user-defined bridge でコンテナ名による名前解決を使うのが基本。
docker volume / bind mount データ永続化の基本。Docker が管理する volume と、ホスト側の任意パスを使う bind mount の違い、`:ro` / `:z` / `:Z` オプション、パーミッション問題の対処を整理する。

Podman

podman Docker 互換の CLI を持ちながら、常駐デーモンを必要としない（daemonless）コンテナエンジン。rootless 実行がデフォルトで、セキュリティ面で Docker と差別化される。
podman pod Kubernetes の Pod と同名の概念で、ネットワーク名前空間を共有する複数コンテナを 1 つの単位として扱う。Podman 固有の強みのひとつ。
buildah Dockerfile を書かずにシェルスクリプトでイメージを組み立てられるビルドツール。OCI 準拠のイメージを daemonless で生成する。
skopeo ローカルに pull せずにレジストリ間でイメージをコピーしたり、マニフェストを検査したりできるツール。イメージの移送や署名検証に使われる。

ランタイム内部

containerd Docker Engine の内部で使われ、Kubernetes でも主流となった中レイヤのコンテナランタイム。イメージ管理・実行・スナップショットなどを担う。
runc / CRI-O runc は OCI Runtime Spec の参照実装、CRI-O は Kubernetes 向けに CRI を最小実装したランタイム。コンテナスタックの最下層と Kubernetes 向け層を担う。

イメージ・Dockerfile

Dockerfile Dockerfile はイメージを組み立てる手順書。ベースの選択から依存インストール、アプリ配置、起動コマンドまでをテキストで宣言し、`docker build` で一発でイメージ化する。
Dockerfile instructions Dockerfile の命令リファレンス。FROM でベースを決め、RUN・COPY・WORKDIR・ENV・CMD・ENTRYPOINT を順番に並べる。
multi-stage ビルド用ステージと実行用ステージを分け、成果物だけを最終イメージに残す手法。イメージサイズとセキュリティの両方に効果がある。
layer cache Dockerfile の命令順序と BuildKit のマウント機能を使い、再ビルドを最短化する。
image size 軽量ベースイメージの選定、不要ファイルの削除、マルチステージの活用でイメージサイズを抑える。
.dockerignore ビルドコンテキストから不要ファイルを除外する設定ファイル。ビルド時間・イメージサイズ・秘密情報漏洩対策の 3 点で重要。

レジストリ

docker push / pull ローカルのイメージをレジストリに送る `docker push` と、レジストリから取得する `docker pull`。認証とタグ運用が要点。
registry Docker Hub・GHCR・ECR・GCR・Harbor などの主要レジストリを、公開／プライベート・認証方式・コスト観点で比較する。

Compose

docker compose 複数コンテナをまとめて起動・停止するための compose.yml。services / networks / volumes の 3 ブロックで構成され、`docker compose up -d` と `docker compose down` が中心操作になる。
depends_on / profiles `depends_on` でサービスの起動順を制御し、`profiles` で dev / prod など環境ごとの有効化を切り替える。ただし起動順だけではアプリの準備完了を保証できないので healthcheck との組み合わせが必要になる。
compose.override.yml compose.override.yml は同じディレクトリにあれば自動でマージされ、`-f base.yml -f prod.yml` で任意の差分ファイルを重ねられる。env_file と environment の優先順位も把握しておく。

ネットワーク・ストレージ

bridge / host / overlay Docker のネットワークドライバは bridge・host・overlay などに分かれ、用途が違う。user-defined bridge では DNS 解決が働き、`--network host` は Linux と Docker Desktop で挙動が大きく異なる。
volume / bind mount volume は Docker が管理する永続領域、bind mount はホストの任意パスをそのまま見せる機能。UID/GID ズレや SELinux ラベルが原因で「書き込めない」エラーが起きがちなので、対処パターンを押さえる。
host.docker.internal コンテナから「ホスト側の localhost」に繋ぎたいときに使う特殊名。Docker Desktop では最初から解決できるが、Linux では `--add-host=host.docker.internal:host-gateway` を付ける必要がある。

セキュリティ

rootless コンテナランタイムとコンテナ内プロセスを非特権ユーザーで動かす方式。万一コンテナから脱出されてもホスト側で root を奪われない構成にできる。Podman はデフォルト、Docker もオプションで対応。
capabilities Linux の root 権限を約 40 の細かい能力に分割した仕組み。コンテナランタイムはデフォルトで一部だけを付与し、`--cap-drop` / `--cap-add` で絞り込む。最小権限の原則を徹底するための最重要機能。
secrets API キー・DB パスワード・証明書などの機密情報をイメージや環境変数に平文で埋め込まず、専用の仕組みで注入する運用。Docker secrets・Compose secrets・Vault・クラウド KMS などを使い分ける。
trivy / grype コンテナイメージに含まれる OS パッケージや言語ライブラリの既知脆弱性（CVE）を検出するツール。Trivy と Grype が代表格で、CI に組み込んでビルド時やプル時に自動実行するのが標準運用。
user namespace コンテナ内の UID/GID をホスト側の別 UID/GID にマッピングする Linux の機能。これにより「コンテナ内では root、ホストから見ると非 root」を実現し、bind mount のパーミッション問題の根本原因にもなる。
--read-only コンテナのルートファイルシステムを読み取り専用で起動し、書き込みが必要な部分だけ tmpfs や volume に分離する構成。マルウェアの書き込みや改ざんを防ぎ、Immutable Infrastructure を強化する。

WSL2

WSL2 Windows Subsystem for Linux の第 2 世代。Hyper-V 技術を基盤にした軽量 VM 上で本物の Linux カーネルを動かす方式で、WSL1 のエミュレーションとは根本的に別物。Docker Desktop の標準バックエンドでもある。
Docker Desktop Docker Desktop for Windows は WSL2 をバックエンドとしてコンテナを動かす構成。`docker-desktop` 専用ディストリに dockerd を常駐させ、ユーザーのディストリからは統合機能で透過的に使える。
/mnt/c vs ~ WSL2 では `~/`（Linux 側 ext4）と `/mnt/c/`（Windows 側 NTFS）で IO 性能が 10 倍以上違うことがある。`9p` プロトコルを介した Windows FS アクセスが遅いため、作業ファイルの置き場所で体感が大きく変わる。
netsh portproxy WSL2 は独自 IP を持つ VM なので、Windows の `localhost` からアクセスするには自動転送、同一 LAN の別端末からアクセスするには `netsh portproxy` 等の追加設定が必要になる。
hwclock Windows のスリープや休止から復帰した後に、WSL2 内の時計が数秒〜数分遅れる現象。TLS 証明書検証や JWT の有効期限判定が失敗する原因になる。
systemd かつて WSL2 は独自 init を使っており systemd が動かなかったが、2022 年以降の WSL でネイティブサポートされた。`/etc/wsl.conf` に `systemd=true` を書き、`wsl --shutdown` で再起動するだけで有効になる。

devcontainer

devcontainer Dev Containers は、開発環境そのものをコンテナとして記述・配布する仕組み。VS Code Dev Containers 拡張や GitHub Codespaces と組み合わせ、「誰の手元でも同じ環境」を即座に立ち上げられる。
devcontainer.json `devcontainer.json` は Dev Container の設定を記述する中心ファイル。ベースイメージ、ポート転送、VS Code 拡張、起動後コマンドなどをまとめて指定する。
features features は devcontainer.json から追加のツール（Node、Python、AWS CLI、Docker-in-Docker など）を宣言的に入れる仕組み。OCI アーティファクトとして配布され、Dockerfile を書かずに環境を拡張できる。
dockerComposeFile Dev Container は単一コンテナだけでなく、`docker-compose.yml` と組み合わせて DB や Redis などを含む複数サービス構成にできる。アプリ側のコンテナを `service` として指定する。
Codespaces GitHub Codespaces は `devcontainer.json` を GitHub のクラウド VM 上で起動するサービス。ブラウザや VS Code から接続して、ローカル環境を整えずに開発できる。
JetBrains Gateway JetBrains Gateway は IntelliJ / WebStorm / PyCharm などの IDE をリモートのコンテナや SSH 先に接続するランチャ。`devcontainer.json` を読み込み、VS Code 以外の開発者も同じ定義を使える。

CI/CD

GitHub Actions GitHub Actions はリポジトリのイベントに応じてワークフローを実行する CI/CD サービス。`docker/build-push-action` を組み合わせれば、数十行の YAML でビルドとプッシュまで自動化できる。
buildx cache BuildKit のキャッシュを CI で再利用すると、ビルド時間を大幅に短縮できる。GitHub Actions の `gha` キャッシュやレジストリ型キャッシュを使い分ける。
GitLab CI GitLab CI はリポジトリ内蔵の CI/CD 機能で、`.gitlab-ci.yml` で定義する。Kaniko や BuildKit の Runner と組み合わせれば DinD なしで安全にコンテナをビルドできる。
multi-arch 1 つのイメージタグに amd64 と arm64 の両方を含めると、Apple Silicon や Graviton でも同じ pull で動く。Buildx のマニフェストリストで実現する。
registry push ビルドしたイメージはレジストリに push して初めて本番で使える。GHCR・ECR・GAR・Docker Hub など目的地ごとに認証・命名・保管ポリシーが異なる。
scan in CI Trivy・Grype・Snyk などのスキャナを CI に組み込み、既知脆弱性のあるイメージをレジストリに上げない／本番に出さない、というゲートを作る。