
通常、個々のDockerコンテナは1つのプログラムを実行します。しかし、マイクロサービスアーキテクチャでは、アプリケーションは複数のコンテナを組み合わせて構成されるのが一般的です。各コンテナが特定の機能を担い、それらが集まってアプリケーション全体を構成します。これらのコンテナの作成や維持を調整するのが、コンテナオーケストレーションツールの役割です。
Docker ComposeとPodman Composeは、マルチコンテナアプリケーションを定義・実行するために広く採用されているツールです。これらを使うと、アプリケーション全体の構成を1つのYAMLファイルに記述でき、1つのコマンドで複雑な環境を立ち上げることができます。それぞれの仕組みと違いを理解することは、現代のLinuxシステム管理およびDevOps実践において不可欠です。
Docker Composeはクライアント・サーバーモデルに基づいています。docker compose コマンド(または従来の docker-compose バイナリ)は、ホスト上で動作するDockerデーモン(dockerd)と通信します。デーモンはComposeファイルに定義された内容に基づき、コンテナ、ネットワーク、ボリュームを作成します。
Docker Composeは「プロジェクト」という単位でリソースを管理します。デフォルトでは、プロジェクト名はComposeファイルが存在するディレクトリ名から決定されます。同一プロジェクトに属するコンテナ、ネットワーク、ボリュームには共通のプレフィックスが付与され、まとめて管理しやすくなっています。
Podman Composeは根本的に異なるアプローチを採用しています。Dockerと違い、Podmanはデーモンレスです。常駐バックグラウンドサービスに依存しません。
各コンテナは、コマンドを実行したユーザーの直接の子プロセスとして起動されます。そのため、特権昇格なしに非rootユーザーでコンテナを実行できます。
Composeファイルは、アプリケーションのサービス、ネットワーク、ボリュームを記述するYAMLドキュメントです。バージョン3以降、フォーマットはDocker ComposeとDocker Swarmで統一されています。最新版仕様では version キーは必須ではありませんが、明示的に記載することがベストプラクティスとされています。
最小構成の例:
services:
web:
image: nginx:latest
ports:
– “8080:80”
この設定は、web というサービスを定義しています。
services
アプリケーションを構成するすべてのコンテナを列挙します。
web
サービス名。内部ネットワーク上でのホスト名としても使われます。
image: nginx:latest
公式Nginxイメージの latest タグを使用してコンテナを作成します。
ports
コンテナのポートをホストに公開します。
“8080:80”
ホストの8080番ポートを、コンテナ内の80番ポートにマッピングします。
Docker ComposeやPodman Composeは、宣言的な設定を読み取り、必要なネットワーク、ボリューム、サービスコンテナを正しい順序で自動作成します。これにより、一貫性、再現性、ライフサイクル管理の簡素化が実現し、マルチコンテナアプリケーションのデプロイや保守が容易になります。
主なDocker Composeコマンド:
# 実行中サービスの確認
$ docker compose ps
# ログの表示
$ docker compose logs -f
# 停止して削除
$ docker compose down
サービスは、どのイメージを使い、どのポートを公開し、どのボリュームやネットワークに接続するかなど、コンテナの実行方法を定義します。Webサーバー、データベース、キャッシュ、APIなど、それぞれの役割を表します。
通常は1インスタンスですが、複数レプリカにスケール可能です。リポジトリの既存イメージを使うことも、ローカルDockerfileからビルドすることもできます。
ネットワークはサービス間および外部との通信方法を定義します。デフォルトでは分離されたブリッジネットワークが作成され、サービス名で名前解決できます。
カスタムネットワークによりトラフィック分離やセキュリティ強化が可能です。例えば、フロントエンドは公開ネットワークとバックエンドの両方に接続し、データベースはバックエンドのみに接続するといった構成が可能です。
コンテナは本質的に一時的(エフェメラル)です。削除すると内部データは消えます。ボリュームはコンテナ外にデータを保存し、再起動や再作成後も保持します。
名前付きボリュームやバインドマウントを利用できます。アプリケーションロジックと永続データを分離することで、安全で持続可能な管理が可能になります。
(※原文のComposeファイルは省略せずそのまま保持することが前提ですが、ここでは構造説明を含め日本語で解説しています。)
この例では以下を構成します:
proxy(nginx:1.25-alpine)
app(Node.jsアプリ)
db(postgres:15)
ホスト80番を公開
読み取り専用でNginx設定をマウント
appに依存
frontendネットワークのみ接続
unless-stopped 再起動ポリシー
ローカルDockerfileからビルド
NODE_ENV=production
DATABASE_URL にdbサービスを指定
dbが正常になるまで待機
frontendおよびbackend両方に接続
postgres:15を使用
ユーザー・パスワード・DB名を環境変数で設定
db_dataボリュームを使用
pg_isreadyによるヘルスチェック
backendのみ接続
frontend
backend(internal: true で外部遮断)
db_data(永続データ保存)
この構成は、責務の明確な分離、安全なネットワーク分離、ヘルスチェック連動の依存関係、永続ストレージ管理を実現しています。
Docker Composeの利点の一つは、宣言的に更新できることです。
まず最新イメージを取得:
次に再作成:
Composeは変更を検出すると古いコンテナを停止し、新しいイメージで再作成します。ボリュームとネットワークは保持されます。
これは「イミュータブルインフラストラクチャ」アプローチであり、信頼性向上と設定ドリフト防止に貢献します。
これらの概念の習得は、DevOps Tools認定およびコンテナ基盤を管理するLinux管理者にとって不可欠です。
DevOpsスキルをさらに強化するために、DevOps Tools Engineer(701-200)の公式ラーニングマテリアルを無料でダウンロードすることを忘れないでください。試験目標に沿って理解を深める優れた教材です。
You are currently viewing a placeholder content from Vimeo. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou are currently viewing a placeholder content from YouTube. To access the actual content, click the button below. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More InformationYou need to load content from reCAPTCHA to submit the form. Please note that doing so will share data with third-party providers.
More Information