Docker Linux

この記事のポイント

・initdb.d以下のSQLは「初回起動時のみ」自動実行される
・named volumeを使えばコンテナ削除後もデータが保持される
・DockerfileのENV・COPY順序がDB初期化の動作に影響する
・healthcheck付きdepends_onでDBの準備完了を待機できる

この記事のポイント

・diveコマンドはDockerイメージのレイヤーをファイル単位で可視化するツール
・対話型UIで各レイヤーのファイル追加・削除・変更を確認できる
・効率スコアで「無駄なスペース」を数値化しDockerfile改善の優先度を把握できる
・--ciフラグでCIパイプラインへの組み込みが可能

この記事のポイント

・docker swarm initとswarm joinだけで最小クラスターが構成できる
・SwarmはKubernetesより習得コストが低く小規模オンプレに向く
・Kubernetesは本番スケールの運用機能が豊富だが学習・維持コストが高い
・3ノード以下なら撤退容易性の観点でもSwarmが合理的な選択肢になる

この記事のポイント

・localドライバはノードごとに別の実体を持ち、ノードをまたいだデータ共有はできない
・タスクが別ノードへ再配置されると直前のデータは参照できなくなる
・placement constraintで縛る回避策は再配置時の可用性とのトレードオフがある
・NFSをvolume driverオプションで指定すると全ノードが同一データを共有できる

この記事のポイント

・docker stack deployはdeployブロック（replicas・placement・restart_policy）を読み取りSwarmサービスを構成する
・build・depends_on・restartキーはdocker stack deployでは完全に無視される
・buildを使っているサービスは「ビルド→レジストリpush→image:書き換え」の3ステップで対応する
・depends_onの代替はhealthcheck + deploy.restart_policy.condition: on-failureで吸収できる

この記事のポイント

・docker compose buildのbuildセクションでコンテキスト・Dockerfile・引数を一元管理できる
・argsとDockerfileのARGを対応させることでビルド時にcompose.ymlから値を注入できる
・cache_from/cache_toでCI/CDのビルドキャッシュをレジストリに保存・再利用し高速化できる
・--no-cacheフラグとtargetでビルドの再実行と対象ステージを明示的に制御できる

この記事のポイント

・bind mountはホストのパスをコンテナに直接共有する（ホストに残るが可搬性は低い）
・tmpfsはメモリ上の一時領域でコンテナ停止と同時にデータは消える（機密データ向き）
・バックアップが必要なデータはnamed volume、ホスト連携はbind mount、機密一時データはtmpfs
・選定基準は「永続性・ホスト依存・バックアップ・セキュリティ」の4軸で決める

この記事のポイント

・docker composeのnamedボリュームでコンテナ削除後もDBデータが残る永続化を実現できる
・/docker-entrypoint-initdb.dにSQLファイルを置くと初回起動時だけ自動実行される
・pg_dumpはdocker compose exec経由で稼働中コンテナから直接取得できる
・ボリュームが既に存在すると初期化スクリプトが再実行されない点が最大のはまりどころ

この記事のポイント

・ docker compose down はコンテナとデフォルトネットワークを削除するが、ボリュームは残る
・ 匿名ボリュームもデフォルトでは削除されず `docker volume ls` で確認できる
・ `--volumes` フラグを付けると名前付き・匿名ボリュームが両方削除されるため本番では要注意
・ 本番は `down` のみ、開発は `down --volumes --remove-orphans` で使い分けるのが基本設計

この記事のポイント

・DinDはコンテナ内に独立したDockerデーモンを起動する方式で --privileged が必須になる
・docker.sockマウントはホストのデーモンを共有する方式で、実質rootと同等の権限になる
・セルフホスト型RunnerではDinD推奨、Kubernetes上ではKanikoへの移行を検討すること
・どちらも権限は広く、本番Kubernetesクラスターへの直接適用は避けること

この記事のポイント

・DockerはdockerD・containerd・runcの3層でコンテナを起動している
・OCI仕様により、DockerとKubernetesで同じruncランタイムを共用できる
・containerdはKubernetes環境ではDockerなしで直接使われる
・ctr・nerdctlコマンドでcontainerdを実機から直接操作して確認できる

この記事のポイント

・cosign sign --keyでイメージに署名し、改ざん・なりすましを検知できるようにする
・cosign verify --keyで署名を検証し、未署名や改ざんイメージのデプロイを防ぐ
・GitHub Actions上ではKeyless署名（OIDC連携）で秘密鍵の管理自体を不要にできる
・レガシーなDocker Content Trust（Notary）との違いを理解し、現在はcosignを標準とする

この記事のポイント

・Dockerのイメージタグは上書き可能で、同じタグでも中身が変わることがある
・FROM イメージ名@sha256:ハッシュ でダイジェスト固定すると常に同一イメージを取得できる
・docker buildx imagetools inspectでマルチアーキ対応のダイジェストを確認できる
・Renovate等でダイジェストを自動更新すれば安全性と再現性を両立できる

この記事のポイント

・Permission deniedの正体は、ホストとコンテナでUID・GIDの数値が一致しないこと
・DockerfileのARG+USER命令で、ビルド時にホストのUIDへ合わせられる
・docker-compose.ymlのuser: "1000:1000"で実行時にも指定できる
・配布イメージにはPUID/PGID環境変数＋entrypointでの動的chown設計が定番

この記事のポイント

・docker run --rm -i hadolint/hadolint < Dockerfile でインストール不要のまま即座に解析できる
・DLxxxxのルール番号ごとにバージョン固定漏れやapt-getキャッシュ残存を検出できる
・.hadolint.yamlでプロジェクトの事情に合わせたルール除外・重要度変更ができる
・GitHub Actionsに組み込めばDockerfile変更のたびに自動でレビューされる

この記事のポイント

・userns-remapはコンテナ内rootをホストの非特権UIDへ丸ごとマッピングし直すdockerd機能
・非rootユーザー実行やrootlessモードとは別レイヤーの防御で、両者は併用できる
・daemon.jsonに1行追加してdockerd再起動するだけで、既存コンテナすべてに一律適用される
・有効化後はbind mountや既存volumeのPermission deniedが起きやすく、chownでの権限調整が必須

この記事のポイント

・extendsは共通のサービス定義を別ファイルに切り出し、複数サービス・複数プロジェクトから再利用する仕組み
・override（docker-compose.override.yml）は同一プロジェクト内の環境差分、extendsは共通化そのものが目的で役割が違う
・Composeのマージ規則では、ports・volumesなどのリスト項目は結合ではなく丸ごと置き換えになる点が事故の原因になりやすい
・docker compose configで結合後の設定を出力し、意図した内容にマージされているかを毎回確認するのが鉄則

この記事のポイント

・docker compose watch は v2.22+ で正式化された自動反映機能
・compose.yml の develop.watch ブロックに path・action・target を設定する
・sync（即時同期）・rebuild（再ビルド）・sync+restart（同期後再起動）を用途で使い分ける
・docker compose up --watch の一発起動でも同じ効果が得られる

この記事のポイント

・daemon.jsonは/etc/docker/daemon.jsonに置き、JSON形式でDockerデーモン全体の挙動を制御する
・"log-driver"と"log-opts"でコンテナのデフォルトログサイズ・ファイル数を一括制限できる
・insecure-registriesでHTTP接続のプライベートレジストリを許可する
・dockerd --validateで構文エラーを事前確認してからsystemctl restart dockerで反映する

この記事のポイント

・YAMLアンカー（&）でブロックに名前を付け、*（エイリアス）で複数サービスから参照できる
・<<（マージキー）でアンカーをマージしつつ、個別サービス側で一部だけ上書きできる
・Extension fields（x-プレフィックス）でアンカーをファイル先頭に集約して管理できる
・アンカーはファイル内DRY化、extendsはサービス継承、includeはファイル分割と役割が異なる
・docker compose configで展開後の設定を確認してから本番へ適用するのが安全な手順

この記事のポイント

・RUN --mount=type=cacheでpip/npm/aptのキャッシュを再利用できる
・RUN --mount=type=secretでAPIキーをイメージに含めずビルドに使える
・DOCKER_BUILDKIT=1（または compose build）で自動的に有効になる
・docker build --secret id=...,src=...でsecretをビルドに渡す

この記事のポイント

・named volumeのバックアップは docker run --rm -v で一時コンテナを使うのが定石
・本番DBは必ず停止バックアップ。停止できない場合は pg_dump / mysqldump を使う
・別サーバーへの移行は tar + rsync/scp の2ステップで完結する
・cronで夜間に自動バックアップすれば、誤削除・障害時に数分で復元できる

この記事のポイント

・docker stopはSIGTERM→10秒待機→SIGKILLの順で終了させる
・PID 1問題でSIGTERMが届かないことが最多の原因
・STOPSIGNALとstop_grace_periodで終了挙動を制御する
・tiniとinit: trueでPID 1問題を根本解消できる

この記事のポイント

・docker compose secretsはパスワードを /run/secrets/ にtmpfsでマウントする
・docker inspectで機密情報が見えない安全な設計になっている
・compose.ymlのsecretsセクションにfile:でパスを指定するだけで使い始められる
・POSTGRES_PASSWORD_FILE等の_FILE変数対応イメージとそのまま連携できる

この記事のポイント

・ docker context createでSSH contextを作成し、複数Dockerホストを名前で切り替えられる
・ docker context useで対象ホストに切り替えると、以降のdockerコマンドが全てリモートに向く
・ ~/.ssh/configとの組み合わせで接続先の管理をシンプルに一元化できる
・ DOCKER_CONTEXT環境変数でスクリプト・CI/CDにも安全に組み込める

この記事のポイント

・Composeはdocker compose up時に専用ブリッジネットワークを自動作成しサービス名をDNSホスト名にする
・networks:ブロックでカスタムネットワークを定義しサービスに複数割り当てると通信経路を分離できる
・external: trueでComposeの外側に存在する既存Dockerネットワークに接続できる
・docker network inspectとdocker compose execで通信障害を迅速に切り分けられる

この記事のポイント

・minikube start 1コマンドでKubernetesクラスターが手元のPCで起動できる
・kubectl apply でPodやDeploymentをYAMLファイルから作成・管理できる
・kindはDockerだけで動く軽量クラスターでCI環境のテストに適している
・minikubeとkindの違いを理解して用途に合わせて使い分けられる

この記事のポイント

・docker/build-push-actionでビルド～プッシュをワンステップで自動化できる
・ghcr.ioはGITHUB_TOKENだけで認証できるため外部シークレット不要
・cache-type=ghaを使うとGitHub Actionsのキャッシュでビルド時間を大幅短縮できる
・タグはgit sha・semverタグ・latestを組み合わせて再現性と利便性を両立する

この記事のポイント

・docker save -o image.tar イメージ名 でイメージをtarファイルに保存できる
・docker load -i image.tar でtarファイルからイメージを復元する
・gzipと組み合わせると転送ファイルサイズを50～70%削減できる
・docker images --digests で転送前後のダイジェスト一致を確認して整合性を保証する

この記事のポイント

・ENVは実行時の変数、ARGはビルド時限定でイメージに残らない
・ARGにシークレットを渡すとdocker historyで漏洩する危険がある
・env_fileで.envを外部化し必ず.gitignoreに追加する
・BuildKit --mount=type=secretならレイヤーにシークレットが残らない

この記事のポイント

・docker buildx build --platform linux/amd64,linux/arm64 で両アーキに対応できる
・QEMUを使うとx86マシン上でもARMイメージをクロスビルドできる
・ARG TARGETARCHをDockerfileに組み込むとアーキ別バイナリ配置を自動化できる
・--push オプションでビルドと同時にDocker Hubへマルチプラットフォームpushできる

この記事のポイント

・docker run registry:2 で5分以内にプライベートレジストリを起動できる
・push/pullはイメージに「ホスト:ポート/」タグを付けるだけでよい
・TLS + htpasswd認証でセキュアな社内専用レジストリを構築できる
・pull through cache設定でDocker Hub rate limitを実質回避できる

この記事のポイント

・docker restart policy の unless-stopped がサーバー再起動後の自動起動に本番推奨
・4種類（no / on-failure / always / unless-stopped）を用途に応じて使い分ける
・docker-compose.yml の restart フィールドで複数コンテナに一括設定できる
・起動順序や依存関係の詳細制御が必要な場合は systemd ユニットファイルが有効

この記事のポイント

・overlay2肥大の原因は停止コンテナ・dangling image・未使用volumeの3つ
・docker system dfで種別ごとの使用量を確認してから削除する
・docker system prune --all --volumesで一括削除できるが本番では段階的に実行する
・--filterで「until=168h」と指定して直近7日以上のリソースのみ削除できる

この記事のポイント

・trivy image <イメージ名> でDockerイメージの脆弱性を数十秒でスキャンできる
・--severity CRITICAL,HIGH フィルタで優先対応すべきCVEだけ絞り込める
・GitHub Actions の aquasecurity/trivy-action でCI段階に自動スキャンを組み込める
・ベースイメージをalpine/distrolessに変え、定期cronスキャンで継続管理が基本戦略

この記事のポイント

・Dockerコンテナはデフォルトでrootユーザーとして動作しリスクがある
・USER命令で非rootユーザーに切り替えるのがDockerfile設計の基本
・Rootless DockerはDocker daemon自体を一般ユーザーで動かす強力な防御策
・両方を組み合わせることで本番環境のコンテナセキュリティが大幅に向上する

この記事のポイント

・max-size/max-fileでログローテーションを設定できる
・daemon.jsonで全コンテナに一括設定を適用できる
・docker-compose.ymlのloggingセクションで個別設定できる
・本番環境ではjournaldやsyslogへの転送も検討する

この記事のポイント

・--memory でコンテナのメモリ上限を設定し、OOM Killerでホストを守る
・--cpus=1.5 でCPU使用量を、--cpu-shares で優先度を制御する
・docker stats --no-stream でリソース使用量をスナップショット確認できる
・Composeではdeploy.resources.limitsでまとめて制限を宣言する

この記事のポイント

・Dockerのキャッシュは命令が変わった行以降すべて無効化される
・変更頻度の低い命令（apt install）を上に、ソースのCOPYを最後に書く
・.dockerignoreでビルドコンテキストを削減し、転送時間と機密情報漏洩を同時に防ぐ
・BuildKitの--mount=type=cacheでパッケージキャッシュを永続化できる

この記事のポイント

・depends_on の condition: service_healthy でDBの準備完了を待ってからアプリを起動できる
・HEALTHCHECK 命令でコンテナの「準備完了」基準を定義する（Dockerfile / Composeファイル両方に書ける）
・MySQLは -h 127.0.0.1・start_period: 30s が必須の設定ポイント
・docker inspect と docker events でヘルスチェックのログと進捗をリアルタイム確認できる
・profiles: [dev] でサービスを環境別に選択起動し、開発ツールを本番に混入させない（Compose v2.2以降）
・adminerのポートを 127.0.0.1:8081:8080 にバインドするとdevプロファイルが誤起動されても外部アクセスを防げる
・Mailhog等のSMTPモックを devプロファイルに隔離し、SMTP接続先を環境変数デフォルト値で切り替えられる
・--profile オプションは docker compose の直後・サブコマンドの前に指定する
・initプロファイルを使えばシードデータ投入などの一回限り処理を分離できる
・COMPOSE_PROFILES 環境変数や .env ファイルで起動プロファイルを環境ごとに自動切り替えできる
・docker compose config --profiles で定義済みプロファイル一覧を確認できる（Compose v2.15以降）
・profiles付きサービスをdepends_onで参照するときは依存関係の設計に注意が必要
・docker compose run --rm でマイグレーション・テスト・シードを1回きり実行できる（終了後コンテナ自動削除）
・GitHub Actions から docker compose --profile ci run --rm migrate でCIマイグレーションを一時起動できる
・docker compose run と docker compose exec の使い分けは「サービスが停止中か起動中か」で判断する
・deploy.replicas でスケールした各レプリカには独立してヘルスチェックが実行される（Compose v2.x は Swarm なしでも有効）
・deploy.resources.limits でコンテナごとのCPU・メモリ上限を設定し、レプリカ増加時のリソース過消費を防ぐ
・debug プロファイルで netshoot コンテナを app コンテナのネットワーク名前空間に接続し、本番コンテナへの影響ゼロで ss / tcpdump / curl によるネットワーク診断ができる
・.env.dev / .env.production のように環境別 .env ファイルを用意し、cp .env.dev .env だけでプロファイルを自動切り替えできる

この記事のポイント

・ENTRYPOINT は「コンテナが必ず実行するプログラム」を固定する命令
・CMD は「ENTRYPOINT へのデフォルト引数」または単独のデフォルトコマンド
・exec形式（JSON配列）を使わないとシグナルが届かず docker stop が10秒かかる
・Compose では entrypoint: / command: キーで Dockerfile の設定を上書きできる

この記事のポイント

・docker exec -it でコンテナ内のシェルにインタラクティブに接続できる
・docker logs -f でリアルタイムのコンテナログをtail感覚で追える
・docker inspect --format でIPアドレスや設定値を1行で取り出せる
・起動に失敗したコンテナはdocker startしてからexecでデバッグする

この記事のポイント

・Dockerデフォルトのbridgeではコンテナ名での名前解決ができない
・コンテナ間を名前で繋ぐには「ユーザー定義bridgeネットワーク」が必須
・Docker Composeは自動でユーザー定義ネットワークを作成しサービス名で通信できる
・本番環境ではfrontend/backendを別ネットワークに分離するのが基本設計

この記事のポイント

・コンテナのデータはデフォルトで揮発性。永続化にはvolumeかバインドマウントを使う
・docker volume createで名前付きボリュームを作り、-vまたは--mountオプションでコンテナに接続する
・バインドマウントはホストのディレクトリを直接マウントし、開発環境のソース共有に向く
・Docker ComposeではvolumesセクションでDB・アプリのデータを永続化して管理する

この記事のポイント

・マルチステージビルド＋distrolessで本番イメージを1/10以下に軽量化できる
・Dockerfile設計の鉄則はCOPY --from でビルド成果物だけを本番に持ち込むこと
・GoはCGO_ENABLED=0＋distroless/staticでバイナリ1本分のイメージを作れる（約22MB）
・Node.jsはnpm ci --omit=devで本番依存のみに絞り、devDependenciesをイメージから排除できる
・コンテナをroot以外のユーザーで動かすことがセキュリティの最低ライン
・.envファイルは自動読み込みされるがGitに含めてはいけない——認証情報はファイルで分離する
・Composeのoverride構成とprofilesで開発・本番・CI環境を1ファイル体系で管理できる
・COPY --fromは自分のステージだけでなく外部イメージからも直接コピーでき、CA証明書や設定ファイルの取り込みに応用できる

この記事のポイント

・docker-compose.ymlとNVIDIA Container Toolkitで再現性のある運用環境を構築できる
・GPUパススルー・ヘルスチェック・環境変数の外部化で本番品質の構成に仕上げる手順を解説
・profilesキーで特定サービスを選択起動し、COMPOSE_PROFILES変数で環境ごとに制御できる
・docker-compose.override.ymlで開発・本番設定を分離し、本番への誤設定混入を防ぐ方法も紹介
・--env-fileオプションで本番用の.envを明示指定し環境変数を切り替える手順を解説
・compose.ci.ymlと--abort-on-container-exitでCIテスト実行を自動化する手順も解説
・マージルールの落とし穴（配列は追加マージ・マッピングはキー単位上書き）を理解して設定混入を防ぐ
・deploy.resources.limitsでCPU／メモリを制限し、ホスト全体の安定性を守る方法も紹介
・docker statsで実消費量を把握してから制限値を設定する手順を解説
・Open WebUIをcomposeに同梱することでチーム共有UIをワンコマンドで起動できる

この記事のポイント

・コンテナはOSカーネルを共有する軽量な実行環境で、VMより数十倍速く起動する
・Dockerはコンテナを手軽に使うためのツール群（CLI・デーモン・イメージ管理）
・Dockerfileで環境を「コード化」すれば、誰でも同じ環境を再現できる
・Docker Composeを使えば複数コンテナをyaml1ファイルで一括管理できる

この記事のポイント

・docker run でコンテナを起動、docker stop/rm で停止・削除できる
・docker ps -a で起動中・停止中の全コンテナを一覧表示できる
・docker exec -it でコンテナ内部に入りコマンド実行が可能
・Docker Composeを使えば複数コンテナをymlファイル1つで一括管理できる

この記事のポイント

・NetBIOSはWindowsネットワークの基盤。SMB/CIFSによるファイル共有で今も現役で動いている
・NetBIOS名前解決にはブロードキャスト・WINSサーバー・lmhostsの3方式がある
・LinuxからはnmblookupコマンドでNetBIOSホスト名の照会・名前解決ができる
・ポート137/138（UDP）と139（TCP）を理解することがトラブル対応の第一歩になる