すべてのものを構成する

写し

このプレゼンテーションは Docker Compose です。 このプレゼンテーションでは、次のトピックについて説明します。

• Docker エンジンとその API
• Docker Compose の基本
• Docker Compose ファイル
• Docker Compose での変数の使用
• Compose の高度な使用法

目次

• エンジンとそのAPI (0:24)
• 例 (3:14)
• Composeの基本 (8:18)
• 作成ファイル(11:38)
• コンポーズと変数 (16:38)
• アドバンスドコンポーズ (17:48)
• マージ作成 (22:06)
• デバッグの作成 (24:53)
• 詳細情報

エンジンとそのAPI (0:24)

最初のセクションであるエンジンとその API では、Docker Compose と Docker エンジンがどのように連携するかについて学習します。 Docker Composeは、複雑なアプリケーションスタックをスピンアップするのに役立つツールです。 Compose ベースのアプリケーションを複数のサービスで開き、Docker Desktop から簡単に実行して、Compose の動作例を見てみましょう。 Docker Desktopから、Docker Composeファイルを含むプロジェクトを簡単に選択できます。 簡単に開いて新しいプロジェクトを作成し、Docker Composeスタック全体を実行できることがわかります。 ここでは、Compose ファイルが MySQL、PHP MyAdmin、およびまだ実行されていない Python サービスによって表されていることがわかります。 「Run project」を押すと、それらのサービスがスピンアップするはずです。 このウィンドウでは、アプリケーションのログを確認できます。 これらのサービスが正しく実行されている場合、現在のように、それらのコンテナをすばやくクリックできます。 前面とPythonアプリをヒットしたい場合は、DockerDesktop内からDockerComposeを使用して簡単に実行できます。

これは素晴らしいことですが、Docker Composeは実際にはどのように機能するのでしょうか? それに答えるために、Docker Engine 自体を見てみましょう。 Docker エンジン (一般に Docker デーモンと呼ばれる) は、コンテナ オーケストレーションの中核です。 イメージ、コンテナ、ボリューム、ネットワークなど、すべてを管理する責任があります。 エンジンは REST API エンドポイントを公開し、イメージの一覧表示、コンテナの起動、ボリュームのアタッチなどを行うことができます。 これは、Docker CLIが簡単に言えば、そのAPIのRESTクライアントであることを意味します。 Docker PS を実行すると、API エンドポイントに対してクエリが実行され、JSON 応答が人間にわかりやすいテキスト インターフェイスで表示されます。 この分離されたアーキテクチャは非常に柔軟性があり、CLI がさまざまな Docker コンテキストを介してリモート Docker エンジンを指すこともできます。 エンジン API はバージョン管理されており、Docker の Web サイトで完全に文書化されています。 つまり、必要に応じて、独自のスクリプトとツールを構築して、機能を拡張および追加できます。

例 (3:14)

以下は、docs.docker.com の Docker Engine API リファレンスガイドの例です。 ここでは、実行したいほぼすべてのアクションのエンドポイントを提供していることがわかります。 コンテナの一覧表示、新しいコンテナの作成、コンテナの検査。 このガイドは、エンジン API について理解を深めるのに役立ちます。 API と直接対話する例を見るために、Curl を使用して /var/run/docker.sock で実行されているローカル API エンドポイントをヒットできます。 ターミナルを起動して直接クエリを実行すると、他のAPIエンドポイントと同じように動作することがわかります。 ソケットの位置とエンドポイントを入力します。 また、JQツールを使用してJSONレスポンスをフォーマットします。 ここでは、エンドポイントが実行中のエンジンに関する多くの情報を返していることがわかります。

より詳細な例を示しましょう。 API エンドポイントをクエリして、実行中のコンテナのすべての名前を確認できます。 私もほぼ同じことをします。 私はカールを使用します。 unix-socketをクエリしたいと伝えてください。 ソケットの位置を指定します。 次に、クエリを実行するRESTエンドポイントを指定します。 この場合は、バージョン管理されたエンドポイントになります。 エンジンのバージョン 1.46。 私はそれにJSON形式ですべてのコンテナを与えるように頼むつもりです。 次に、JQを使用してそれらの名前を返します。 これにより、実行中のすべてのコンテナ名が返されます。 ここでは、エンジンがコンテナとそのリソースの基盤となるオーケストレーションと管理にとって非常に重要であることがわかります。 このエンジンがネットワーク ポートで公開される場合は、必ず認証を追加してください。 エンジンを固定するための手順は、ドキュメントWebサイトに掲載されています。

なぜこれが重要なのか、と自問しているかもしれません。 なぜAPIとエンジンについて話しているのですか? これは、Docker Compose が、エンジン API を介して基盤となる Docker エンジンにクエリを実行する REST クライアントにすぎないためです。 Docker バイナリは、プラグイン アーキテクチャを利用して、エンジン API をクエリするための一般的なフレームワークを提供します。 したがって、技術的には、Docker Compose は Docker CLI のプラグインです。 これは、Docker Compose がプラグイン フレームワークを使用して、基になる Docker Engine API を呼び出し、コンテナをオーケストレーションしていることを意味します。 システム上の他のプラグインをいくつか見てみましょう。 すべての外部 CLI プラグインを一覧表示するには、 Docker プラグイン ls と入力します。

さっそくやってみましょう。 したがって、 Dockerプラグインls は、Dockerへのすべての外部またはサードパーティのプラグインを表示する必要がありますが、何もありません。 ただし、Docker に付属しているすべてのプラグインは、CLI の plugins ディレクトリに含まれているプラグインをリストするだけで確認できます。 上部のDockerComposeを含め、かなりの数があることがわかります。 つまり、ドキュメントで説明されている Docker プラグインのガイドラインに従って、独自のバージョンの Docker Compose を作成できます。 しかし、それは少し手間がかかりすぎるかもしれません。

Composeの基本 (8:18)

Compose についてもう少し詳しく見ていきましょう。 このセクションでは、Composeの基本では、Dockerエンジンの仕組みを理解し、Composeの基本を確認します。 各コンテナをマシン上で実行される分離されたワークロードと考えると、レゴブロックを想像できます。 ほとんどのアプリケーションには複数のレンガがあります。 1 つはデータベース、もう 1 つはフロントエンド、もう 1 つは REST API などです。 素晴らしいのは、必要なさまざまなサービスやブリックの数にもかかわらず、Docker Composeは使いやすいコマンドでそれらすべてを管理できることです。 「docker compose up」と入力すると、アプリケーションスタック全体と関連するすべてのリソースが表示されます。docker compose downと入力すると、スタック全体がきれいに停止します。また、 docker compose logs は、個々のコンテナーからの情報ログを提供します。 これは開発時に非常に便利です。

実際、Docker Compose は、開発者が複雑なコンテナ化されたアプリケーションをローカルで実行するための標準的な方法です。 高速でシンプルで、標準のYAML構文を使用し、Docker Desktopにデフォルトで含まれています。 Docker Compose の構文についてもっと詳しく見ていきましょう。 Docker Runを使用して単一のコンテナを実行する方法を知っています。 Docker Runは、さまざまな構成オプションを使用してコンテナを実行するために、さまざまなフラグを受け入れることを私たちは知っています。 この例では、Docker Run コマンドは次のことを行います。 MySQL 8を使用してコンテナを起動します。2。0。 コンテナからのポート 3306 をホストに公開します。 また、環境変数を使用して、実行中のコンテナのデフォルトのデータベース名に root パスワードを設定します。 最後に、ボリュームを構成します。 したがって、データベースに書き込まれたすべてのデータは、MySQL-data という名前のボリュームに格納されます。 このようなボリュームを使用すると、データをローカルに保持できるため、次にこの例を実行するときに、同じデータをアプリケーションで使用できるようになります。 さて、これはコンテナを実行するための標準的なコマンドであり、Dockerデスクトップがインストールされている人なら誰でも実行でき、MySQLデータベースが実行されます。

しかし、複数のコンテナの実行と管理は困難です。 コンテナの設定、仮想ネットワーク、オープンポート、コンテナの監視など、追跡すべき要素はたくさんあります。 これの一部を行うスクリプトを書くこともできますが、保守が難しく、新しいコンテナに対してうまくスケーリングできません。 たとえば、さらにサービスを追加する必要がある場合や、カスタムネットワークを構成する場合、カスタムスクリプトを標準的な方法で維持するのは困難です。 したがって、このユースケースでは、このDockerコマンドをComposeファイルに変換するのが理にかなっています。 同様のコマンドを実行するためのDocker作成ファイルを作成する方法を見てみましょう。

作成ファイル(11:38)

このセクションでは、Compose ファイルについて、Compose ファイルの作成方法を示します。 それでは、コンテナを実行するためのDocker作成ファイルを作成しましょう。 左側には元のDockerrunコマンドが表示され、右側には新しい作成ファイルが表示されます。 Docker Compose ファイルは、アプリケーション スタックを記述する YAML ドキュメントにすぎません。 各アプリケーションはサービスとして定義され、各サービスは実行するコンテナを指定します。 この場合、サービスに mySQL service database という名前を付けましたが、任意の名前を選択できます。 サービス名データベースは、後で触れるネットワーキングなど、作成ファイル内の他のものの参照として使用できる任意のラベルにすぎません。 データベースサービスでは、実行したいコンテナイメージも提供しています。 この場合、mySQL と、後で説明するローカル イメージをビルドして使用する方法を指定することもできます。 次に、ポートを run コマンドから compose ファイルに移行します。 ポートはサービスに関連付けられているため、データベースエントリの下にポートをリストします。 ポートには、長い形式の構文と短い形式の構文の 2 つの異なる方法があり、ここでは両方を確認できます。 どちらがホストポートで、どちらがコンテナポートかを覚えるのに苦労している場合は、長い形式の構文の方が理にかなっているかもしれません。 どちらもサポートされていますが、このプレゼンテーションでは、引き続き短い形式の構文を使用します。

次に、環境変数をプルオーバーします。 環境変数を定義するには、2 つの方法があります。 1 つ目はキー値マッピングを使用し、2 つ目は文字列の配列です。 デモでは最初のアプローチを使用しますが、繰り返しになりますが、それらをどのように定義するかはあなた次第です。 最後に、ボリュームを定義します。 ここで確認できる違いの 1 つは、キーワードとしてトップレベルのボリュームもあることです。 これは、ボリュームには個別のライフサイクルがあり、さまざまな方法で構成できるためです。 この例では、デフォルトのみを使用しています。 また、高度なヒントの 1 つは、ボリュームをコンテナ間で共有することもできることです。 したがって、あるコンテナが別のコンテナが読み取る必要のあるデータを書き込むユースケースがある場合は、ボリュームを使用してそれらのファイルを共有できます。 複数のコンテナを実行している場合、コンテナが相互にどのように接続されるかを考える必要があります。 コンテナの分離メカニズムに関することの 1 つは、各コンテナが独自の IP アドレスを取得することです。 実際、Docker Inspect とデータベースを実行すると、ネットワーク構成でコンテナの IP アドレスが x.y.a.b であることを確認できます。 ただし、コンテナを再起動すると、そのIPアドレスは異なる可能性があります。 そのため、これを解決するために、Dockerは独自のDNSリゾルバーを実行して、サービスディスカバリーをサポートします。 各コンテナには、最終的にDNSエントリになるネットワークエイリアスのセットがあります。 DNS 解決のスコープもネットワークに設定されます。 そのため、Compose では、各コンテナにサービスの名前のエイリアスが自動的に付与されます。 したがって、この例では、phpmyadmin は、この例では database または db という名前を使用するだけでデータベースに接続できます。 コンテナがホスト名を検索すると、Docker DNS リゾルバーはそれをコンテナの IP アドレスに解決します。 これにより、コンテナを非常に簡単に接続できます。

ここでの最後のステップは、実際のアプリケーションに使用するサービスを追加することです。 まず、Python という名前のサービスを定義します。 このサービスでは、既製のイメージを使用せず、イメージを構築します。 Composeを使用すると、ローカルのDockerファイルを使用してイメージをビルドするように指示できます。 その後、イメージを自動ビルドし、そのイメージを新しいコンテナに使用します。 マルチステージイメージも使用している場合は、Dockerファイル内の特定のステージをターゲットにするようにComposeを構成することもできますが、これはまさにこの例で行います。 そこから、アプリのポートを公開し、最終的にソースコードをコンテナにマウントできるため、コードをすぐにテストできます。

コンポーズと変数 (16:38)

Docker Compose と変数のセクションでは、Compose で変数を使用する方法について説明します。 コンテナイメージにパラメータと値をハードコーディングするのは悪い考えです。 これにより、コンテナの柔軟性が低下し、セキュリティリスクも生じます。 ただし、環境変数を使用すると、実行時にコンテナに値を渡すことができます。 設定されているシェル変数からそれらを取得できます。 ENVファイルから読み取ることも、Dockerの実行コマンドから直接渡すこともできます。 環境変数を使用すると、ハードコーディングされた値を削除することでコンテナの柔軟性が向上しますが、これらの変数に機密情報が含まれている場合、他の実行中のコンテナで使用でき、ログに表示される可能性があります。 シークレットを使用することで、コンテナ内の機密性の高い値を安全に使用できます。 これを行うには、Secrets ファイルを作成し、Docker ファイルで参照します。 シークレットの詳細については、公式の Compose ドキュメントを参照してください。

アドバンスドコンポーズ (17:48)

Advanced Compose セクションでは、Compose の高度な機能の一部について詳しく説明します。 ウォッチを作成します。 通常、Compose の実行時に、アプリケーションに変更を加えた場合は再起動する必要があります。 Compose Watchは、重要なファイルが変更されたことをComposeに通知し、Docker Composeを停止せずに自動的に再読み込みしたり、再構築したりできるようにします。 これは、ほとんどのNodeまたはPHPプロジェクトのように多くのファイルを持つアプリケーションにとっては朗報です。 標準バインド マウントでは、バインド マウントを通じてファイルを読み取る必要があるため、パフォーマンスが低下します。 Compose Sync アプローチでは、コンテナはファイルをネイティブに読み取り、変更が発生したときに同期します。 この方法では、ファイルが複数の場所にあるため、ストレージ領域が少し多く使用されますが、パフォーマンスははるかに高速です。

この例では、リモート Git リポジトリをクローンします。 保存するフォルダを選択し、Compose Watch を使用してファイル システムの変更を監視します。 私はすでにこれを実行していると思います。 別のフォルダを選択し、プロジェクトのクローンを作成し、それをアバターと呼び、これを開きます。 Compose ファイルを見ると、API の requirements.text を監視する Watch が有効になっていることがわかります。 要件が変更された場合は、イメージが再構築され、アプリの API エンドポイントのいずれかが変更された場合は、それらのファイルが実行中のアプリケーションに直接同期されます。 これを実際に見てみましょう。

今、画像を引っ張ってきて、実行しています。 実行中のコンテナから、ローカルで実行されているはずです。 これを開くと、ここでWebが利用可能であることがわかります。 顔の特徴、髪の毛、完全に機能するアプリがあります。 ここでも、Docker Compose は、API パスで何かが変更された場合、これを実行中のアプリケーションに再同期するように指定しています。 さあ、app.py を取り上げ、ここで変更を加えましょう。 これにアクセサリーを追加して保存します。 これで、これが実行中のアプリケーションに反映されていることを確認できるはずです。 これを元に戻すと、更新すると、アクセサリアイテムがWebページに表示されます。 ここでのポイントは、git clone と Docker を簡単に作成でき、事前設定を必要とせずにプロジェクトの作業をすぐに開始できることです。

マージ作成 (22:06)

Compose Merge は、一連の Docker Compose ファイルをマージして 1 つの複合ファイルを作成する方法です。 Compose は任意の数のファイルを読み取ることができ、指定された順序でファイルをマージします。 ファイル内のすべてのパスが基本の compose ファイルに対して相対的であることを確認するために、次の詳細に注意することが重要です。 これは、 -f フラグで指定された最初の作成ファイルです。 これは、オーバーライド ファイルが有効な Compose ファイルである必要はないため、必要です。 これらは、構成または値のオーバーライドの小さなフラグメントにすぎません。 サービスのどのフラグメントがどのパスに対して相対的であるかを追跡することは困難で混乱を招きます。 パスを理解しやすくするには、すべてのパスをこのベース ファイルに対して相対的に定義する必要があります。 ただし、この相対パスの欠点に対処するために、Compose は、ローカルまたはリモートに存在する他の完全な Compose ファイルを含めることもサポートしています。 つまり、Compose ファイルをコンポーザブルにすることができます。 リモート ファイル機能を使用すると、Compose ファイルのライブラリを作成し、必要なものだけを含めることができます。 ただし、信頼できるソースからの他のComposeファイルへの変更は潜在的なセキュリティリスクをもたらす可能性があるため、それらを含める必要があることに注意してください。

実際の Docker Compose のインクルード機能をいくつか見てみましょう。 ここにサンプルリポジトリがあります。 私は自分のディレクトリにWebアプリを含んでおり、それはDocker Composeファイルを持っています。 この Docker Compose ファイルは、データベースディレクトリからファイルを含めるように指定しています。 これらは別々のリポジトリと考えることができます。 このファイルをスピンアップすると、自動的にそれが含まれ、2つのリソースがスピンアップされます。 1つ目はWebアプリ、2つ目はデータベースです。 さっそく試してみましょう。 ターミナルで開く場合は、正しいディレクトリにいること、Webアプリのディレクトリにいること、 およびdocker compose upの場合は、これらの両方が実行されていることを確認してください。 データベースとWebアプリが現在ロードされていることがわかります。 実行中のコンテナに戻ると、これらの両方がDockerComposeのそのincludeステートメントから実行されていることがわかります。

デバッグの作成 (24:53)

Docker Compose のデバッグ。 高度な作成機能のデバッグは難しい場合があります。 config オプションを使用して、最終的な compose ファイルを解析、解決、およびレンダリングできます。 たとえば、複数のファイルがあり、その最後に config ディレクティブを追加すると、ターミナル出力に完全にレンダリングされたテキストが表示されます。 それを試してみましょう。 前の例と同様に、Web アプリにデータベースがあることがわかります。 私はWebアプリに入り、Docker compose configを使用します。 最終的にレンダリングされた compose ファイルはデータベースと Web アプリで構成されていることがわかりますが、ローカルにある compose ファイル compose.yaml は include ステートメントと Web アプリのみで構成されています。

これで、Docker Compose のプレゼンテーションは終わりです。 ご視聴いただき、誠にありがとうございました。

さらに詳しく

• Docker Build のドキュメントを確認してください。
• ドッカーは初めてですか? 始めましょう。
• 無料のラーニングパスでDocker製品を深く掘り下げます。
• Docker Newsletter を購読してください。
• Docker デスクトップの最新リリースを入手します。
• 質問がありますか? Docker コミュニティがお手伝いします。