Docker Linux

この記事のポイント

・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ファイル）
・curl・nc・独自スクリプトで用途に合わせたヘルスチェックを設計できる
・docker inspect でヘルスチェックのログとExitCodeを確認してデバッグできる

この記事のポイント

・ENTRYPOINT は「コンテナが必ず実行するプログラム」を固定する命令
・CMD は「ENTRYPOINT へのデフォルト引数」または単独のデフォルトコマンド
・exec形式（JSON配列）を使わないとシグナルが届かず docker stop が10秒かかる
・両方を組み合わせると「固定コマンド＋上書き可能な引数」の柔軟な設計が実現できる

この記事のポイント

・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オプションでコンテナに接続する
・バインドマウントはホストのディレクトリを直接マウントし、開発環境のソース共有に向く
・Docker ComposeではvolumesセクションでDB・アプリのデータを永続化して管理する

この記事のポイント

・マルチステージビルド＋distrolessで本番イメージを1/10以下に軽量化できる
・Dockerfile設計の鉄則はCOPY --from でビルド成果物だけを本番に持ち込むこと
・GoはCGO_ENABLED=0＋distroless/staticでバイナリ1本分のイメージを作れる
・コンテナをroot以外のユーザーで動かすことがセキュリティの最低ライン
・.envファイルは自動読み込みされるがGitに含めてはいけない——認証情報はファイルで分離する
・Composeのoverride構成とprofilesで開発・本番・CI環境を1ファイル体系で管理できる

この記事のポイント

・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）を理解することがトラブル対応の第一歩になる