0
0
Read Time:1 Minute, 9 Second
Docker Composeには、複数のコンテナを一括して管理する際に便利な機能があります。
具体的には、YMLファイルの内容と、それに従って実行されるDocker Composeというコマンドになりますが、それについて、以下にまとめてみました。
（この記事の前提になりますが、前記事「[比較] ～どれがいいのか？Dockerコンテナ作成！～３つの方法を比較してみた～」からお読みになる事をお勧めします。）
１．複数コンテナ一括管理について
Docker Composeは、複数のコンテナを一括して管理する際に便利です。
以下に具体的な例を挙げながら解説します。
例として、
Webアプリケーションを構成する2つのコンテナ（ウェブサーバとデータベース）
を考えましょう。
それぞれのコンテナは独立して動作する必要がありますが、互いに依存関係があります。
（１）Docker Composeを使用しない場合：
まず、ウェブサーバのコンテナをビルドし、ポートマッピングや環境変数の設定を行います。
次に、データベースのコンテナをビルドし、同様の設定を行います。
最後に、2つのコンテナを個別に起動します。
この場合、各コンテナのビルドと起動を個別に行う必要があり、依存関係の管理や一括起動が煩雑になります。
（２）Docker Composeを使用する場合：
Docker Composeを使用すると、依存関係を含む複数のコンテナの構成をシンプルに管理できます。
まず、プロジェクトのルートにdocker-compose.ymlという名前のファイルを作成します。
（ＹＭＬファイル）
上記の例では、2つのサービス
・webserver
・database
を定義しています。
webserverサービスは、./webserverディレクトリにあるDockerfileを使用してビルドされます。
ポート8080をホストマシンのポート80にマッピングし、databaseサービスに依存しています。
databaseサービスは、公式のPostgreSQLイメージを使用し、環境変数を設定しています。
次に、プロジェクトのルートに移動し、
docker-compose up -d
コマンドを実行します。
これにより、docker-compose.ymlの定義に基づいて２つのコンテナが一括して起動されます。
この場合、依存関係の管理や一括起動が簡単であり、
docker-compose.yml
ファイルの設定を変更することでコンテナの構成が容易に調整できます。
以上の例から分かるように、Docker Composeを使用することで、複数のコンテナを一括して管理する際のメリットが明確になります。
２．概要
上記の内容を、具体的に、項目の説明を交えて説明すると、次の様になります。
（１）依存関係の管理:
Docker Composeでは、依存関係を明示的に定義することができます。
例えば、上記の例ではwebserverサービスがdatabaseサービスに依存しており、depends_onでその関係を表現しています。
これにより、コンテナの起動順序や相互の通信がスムーズに行われます。
（２）一括起動:
docker-compose upコマンドを実行するだけで、複数のコンテナが一括して起動します。
複数のコンテナを個別に起動する手間や順序の管理を省くことができます。
また、-dオプションを付けることで、バックグラウンドでコンテナが起動されます。
（３）シンプルな構成管理:
docker-compose.ymlファイルにコンテナの構成や設定を記述することで、プロジェクトの構成管理が容易になります。
複数のコンテナに関連する設定を1つのファイルにまとめることで、可読性や保守性が向上します。
（４）ポータビリティ:
docker-compose.ymlファイルによって、コンテナの構成や依存関係を定義します。
このファイルを共有することで、他の開発者や環境でも同じ構成でコンテナを起動できます。
開発環境から本番環境まで、一貫性のあるデプロイが可能です。
これらの特徴により、Docker Composeは複数のコンテナを一括して管理する際に非常に便利でし、
依存関係の管理や一括起動、シンプルな構成管理、ポータビリティの向上など、開発およびデプロイプロセスを効率化することができそうです。
３．補足（「複数コンテナの依存性」について）
どの文献にも、Docker Composeの良い点として、複数コンテナの一括管理や、依存関係が、挙げられていますが、このうち、依存関係について、思ったことを、書き留めておきます。
この依存関係の根拠になっているのは、上記ＹＭＬファイル中の、「depends_on」になりまして、これは、どういうものかといいますと、例えば、ＭｙＳＱＬ depends_on ＴＯＭＣＡＴ という設定にした場合、Dockerが起動時に、ＴＯＭＣＡＴから起動をしようと試みてくれる、というものです。
（ちょっと冗長な書き方をしてしまいましたが）「試みてくれる」ということは、裏を返せば、「試みるけど、最終的な起動順番までは、確認もしないし保証もしないよ」ということになります。
つまり・・・、このことを、より詳しく言及すると、次の様になります。
depends_onキーワードは、サービス間の起動順序を制御するために使用されますが、Docker Composeではdepends_onだけでは完全な依存関係の制御ができません！
depends_onはコンテナの起動順序を制御するために使用されますが、実際のサービスの健全性や利用可能性を保証するものではありません！（つまり、依存しているコンテナが起動したからといって、必ずしも完全に利用可能な状態であるとは限りません！！）
（さっきも言いましたが）具体的には、depends_onによって指定された依存関係は、指定された順序で起動を試みますが、コンテナの起動が完了したかどうかやサービスが利用可能になったかどうかを待つわけではありません！ ですから、webserverとdatabaseのどちらが最初に起動されるかは保証されません！
４．（上記２までに書いた）依存関係というメリットを確実に享受するためにはどうすればいいのか？
結局、メリットとして挙げられている依存関係ですが、そのままデフォルトで使っても、なんだかなぁ、という動きだ、ということがいえそうです。
ではどうすればいいのか？
実際の環境でコンテナを起動する場合、依存関係を制御するために追加の手段が必要になることがある、ということになります。
例えば、ウェブサーバがデータベースに接続できるようになるまで待つために、ウェブサーバ側でリトライメカニズムを実装する、などです。
５．Kubernatesの利用について
（上記に挙げた様な）依存関係の完全な制御が必要な場合は、Docker Composeではなく、オーケストレーションツール（例：Kubernetes）を検討するのが有力だそうです。
オーケストレーションツールを使用すると、より高度な依存関係の管理やサービスの起動制御が可能になります。
こちらについては、次回に、動作確認・レビューしたいと思います。
Happy
0 %
Sad
0 %
Excited
0 %
Sleepy
0 %
Angry
0 %
Surprise
0 %