‫以前､ Docker ComposeのYAMLファイルについてお話しましたが､ 今回の講義では､ composeのコマンドラインについてお話します｡
‫この講義の要件はこのセクションの他の部分と同様で､
‫イメージとコンテナ､ そしてそれらの使用方法と以前のセクションで扱った概念について知っている必要があります｡
‫Docker
‫Composeのコマンドラインツールは､ 実はDockerツールとは別物です｡
‫実際は別のバイナリなんですけどね｡ Docker for WindowsやDocker for Macをお使いの方は､
‫実はそちらにバンドルされているんですよ｡
‫Windows 7でツールボックスも使っている場合は､ そちらにバンドルされています｡
‫しかし､ Linuxの場合は別途ダウンロードする必要があり､ それはGitHubで入手できます｡ com/docker/composeで検索してもいいですが､
‫Googleで検索すれば､ このセクションのリファレンスにリンクがあります｡
‫ただ､ 先に断っておきますが､ これはプロダクショングレードのツールとしては設計されていません｡
‫ローカルでの開発や､ コマンドラインからたくさんのコマンドを入力するのが面倒なものを素早くテストするのに､
‫とても理想的です｡ よく使うコマンドはdocker compose
‫upの2つで､ おそらく90%はこのコマンドを入力することになると思います｡
‫ワンストップショップなのです｡
‫基本的には1つのコマンドで､ ボリュームの作成､ ネットワークの作成､ すべてのコンテナの起動､ すべての設定オプションなど､ composeファイルに書かれているすべてのことを行うことができるのです｡
‫多くの人が忘れていることですが､
‫Docker Compose Downが後始末をしてくれるのです｡
‫コンテナを処分し､ 不要になったネットワークやボリュームを削除することができるのです｡
‫この2つのコマンドで､ 異なる開発環境に素早く出入りできるようになります｡
‫このあたりは､ vagrant upなどを使って､ 開発に必要な複雑な環境を局所的にカスタマイズすることに慣れている開発者の方々に､
‫本当に注目されているところですね｡
‫Docker Composeとcomposeファイル､ そしてDockerfileの使い勝手を紹介すると､
‫環境をセットアップするためのより良い方法､ より信頼性の高い方法であることが理解され始めます｡
‫また､ さまざまなVMをセットアップする時間や､ 仮想マシン環境を管理する複雑な作業も必要ありません｡
‫例えば､ 典型的な新規開発者のオンボーディングプロセスでは､ システムに適したツールや仮想マシンのダウンロード､
‫アドオンなど､ 通常は複製環境を構築する必要がありますが､ Docker
‫ComposeではComposeファイルを含む環境をどこかのリポジトリからクローンして､ docker
‫compose upコマンドを実行するだけで簡単に利用できます｡
‫本当に簡単なことなんです｡
‫飛び入りで遊んでみよう｡ compose sample 2 ディレクトリにいます｡ compose sample 1 ディレクトリは､
‫前回の講義で示したいくつかの視覚的な例を示しただけです｡
‫しかし､ 今回は実際にこれを実行して､ 簡単な出力を得ることができるようにします｡
‫とりあえずdocker compose upしてみる｡
‫さて､ 実はその前に､ どんなものかをご紹介しましょう｡
‫これは2つのサービス､ つまり2つのコンテナを持っていて､ 最初のものはNginxサーバーで､ 今回はプロキシとして構成されています｡
‫そしてそれは､ 私のローカル・マシンの80番ポートをリッスンすることになるのです｡
‫ボリュームコマンドで､ このディレクトリにある nginx config ファイルと呼ばれるファイルにバインドマウントしているのがわかると思います｡
‫そのファイルがどのように機能するかは､ まだ必ずしも重要ではありません｡ これは､ この場合､ 実際に自分のローカル環境にあるファイルを取っていることを示すだけです｡
‫このディレクトリは､
‫これらの設定ファイルを保存してくれる Git リポジトリだとしましょう｡ 最後に「ro」と表示されていますが､ これは読み取り専用という意味で､
‫コンテナ内でファイルを変更することはできません｡
‫ここでは必ずしもそれが必要なわけではありません｡ この場合はこうするんだよ､ というのを示したかったんです｡
‫この設定ファイルは実際にNginxに､
‫「ウェブサーバになる代わりに､ リバースプロキシになって他のサーバの前に座って欲しい」と伝えています｡
‫この場合､ ウェブサーバをサービス名で呼び､ Docker Hubの公式画像リポジトリからhttpdという画像で､ Apache 2サーバを実行しています｡
‫また､ 一番上に､ ここにバージョンを指定したのがわかります｡ 私ならそうします｡
‫画像線の内側｡
‫つまり､ docker compose upと入力すると､ 両方のコンテナが起動するはずなのです｡ 2人のプライベートなネットワークを作ることができるはずです｡
‫そのファイルを自動的にバインドマウントします｡
‫ポートを開くと､ 画面にログが出力されるようになるんだ｡
‫そこには､ 「この2つのコンテナを作成する」と書いてありましたね｡ '実際にネットワークを作っているのです｡
‫このファイルでは､ ネットワーク領域やボリューム領域を指定していないことにお気づきでしょう｡
‫デフォルトのIPアドレスを変更したり､ 使用するネットワークドライバを変更したりと､ ネットワークでカスタマイズする必要がある場合にのみ必要なのです｡
‫ボリュームの場合は､ 名前付きボリュームを作成したり､ 別のボリュームドライバを使用したりすることができますが､
‫これらについては後の上級編で説明します｡
‫それくらい､ シンプルなファイルです｡
‫普通､ そんなものは必要ないでしょう｡
‫必要であればそれらの機能もありますが､ 通常はこのような非常にシンプルで小さなコマンドで用が足せます｡
‫私は何をしたのだろう？ これが今の私のApacheサーバーとNginxサーバーです｡
‫ここで実際に丸太に色がついているのがわかると思います｡
‫DockerにはないComposeの優れた機能として､ 実行中のコンテナをすべてフォアグラウンドで画面に記録することができます｡
‫Dockerと同じように､ docker compose up -dを実行すれば､ いつでもバックグラウンドで実行できますね｡
‫でも､
‫ローカルで開発やテストをしているときに､ ログがちゃんと画面に表示されるのはうれしいですね｡
‫ブラウザでlocalhostに飛ぶと､ 「It works」と表示されているのがわかると思います｡ ' これは実際にはNginxサーバーではなくApacheサーバーが返信しているのです｡
‫実際にトラフィックはNginxのリバースプロキシーを経由しています｡
‫Apacheサーバーにトラフィックを繰り返しているのです｡ Apacheサーバーは､ 何も変更していないため､ デフォルトの基本的なHTMLファイルで応答しています｡
‫そして､ Nginxがそれを繰り返しているのです｡
‫つまり､ 基本的なWebサーバー､ Webプロキシの設定です｡
‫トラフィックが2人を襲ったことがわかる｡ 実際にはプロキシを通して動作します｡
‫プロキシはここでは別の色になっているからです｡
‫ログは､
‫私のセットアップのコンテナごとにランダムな色でここに汲み出され､ 何が起こっているのかが簡単にわかるようになっています｡
‫何度も更新を押していたら､ トラフィックが表示されるようになりましたね｡ そして､ 最初にプロキシ､ 次にバックエンドのウェブサーバーに当たっています｡
‫ここで止めようと思ったら､ コントロールcを押して､ 画面内のコンポーズを止める｡
‫実際にバックグラウンドで実行する-dで再度実行することができました｡
‫ここで､ 更新してもまだ残っているのがわかると思います｡ docker compose logsをすると､ さっきと同じログの出力が見られる｡
‫Dockerで使い慣れたコマンドの多くは､ Docker Composeにもあります｡ Composeは､ Docker
‫CLIに代わってバックグラウンドでDocker
‫APIと会話しているのです｡ Docker CLIの代わりに､ バックエンドでDockerサーバーのAPIと通信するようなものです｡
‫もちろん､ ここの素晴らしいヘルプであるdocker compose helpには､ 実行できるすべてのコマンドが表示されています｡
‫これらの多くは､ composeファイルの設定のコンテキストを使用したdockerコマンドに相当するため､
‫非常に見覚えがあると思います｡
‫まだ動いているから､ 全部きれいにしたい｡ ここでdocker compose psを実行すると､ 両方のコンテナが実行されていることがわかります｡
‫docker compose topを実行すれば､ その中で動作しているすべてのサービスを､ きれいなフォーマットで出力することができますね｡
‫かっこいいですね｡
‫そして最後に､ docker compose downを実行して､ 先ほど起動したものを停止し､ クリーンアップすることができます｡
‫そこで何をしたかを教えてくれているのがわかると思います｡ 全部きれいにした｡
‫だから､ 素晴らしい｡
‫これはほんの少しの味です｡
‫このコースの残りの部分では､ ローカルでの開発やテストにDocker
‫Composeを多用する予定です｡ そして､ シンプルなYAMLファイルで複雑な環境をどのようにデプロイするか､
‫本番環境への懸念に移行しながらDocker Composeファイルを使い続けていきます｡