‫この講義では､ Composeファイルに画像ビルドを追加し､ Composeコマンドを実行する際に自動的に画像を用意できるようにする方法について説明します｡
‫このセクションの他の講師と同様に､
‫DockerコンテナとDockerイメージのコマンドライン機能についてのセンスが本当に必要です｡
‫もうひとつ､ Composeができることは､ 実行時に画像を構築することです｡ 実際にキャッシュの中から画像を探し､ その中にビルドオプションがあれば､
‫upコマンドを使った時にその画像をビルドします｡
‫毎回毎回､ 画像を構築するわけではありません｡
‫見つからなければ作るだけです｡
‫イメージを変更した場合は docker compose build で再構築するか､ docker
‫compose up --build で再構築する必要があります｡
‫実際に見てみましょう｡
‫これは､ ローカルでComposeを使用していて､ ビルドしたい画像がある場合にとても便利です｡ もしかしたら､ ボリュームマウントを使いたくないのかもしれません｡
‫実際には､ 画像にファイルをコピーして入れたいとか､ そういうことですよね｡
‫ビルドコマンドがかなり複雑になっているかもしれません｡ 環境変数やビルドの引数をカスタマイズしている可能性があります｡
‫ところで､ ビルドの引数ですが､ まだ話していませんね｡ それはまさに､ ビルド時にのみ利用可能な環境変数なのです｡
‫ドキュメントを見ることができます｡ ドッカーです｡ comのDockerfilesに関するドキュメントで､
‫ビルドの引数について詳しく説明されているはずです｡
‫ここでは､ そのローカルでの使い方の一例を見てみましょう｡
‫compose sample 3 ディレクトリにいます｡ ここで､ あらかじめDocker Composeのファイルを作ってあるのがわかると思います｡
‫実はnginxというDockerfileがあるんです｡ Dockerfileです｡ 次に､ 先ほどと同じように､
‫Nginxをリバースプロキシとして使用する設定にします｡
‫Docker Composeに入ると､ このソリューションをどのようにアーキテクトしたかがわかります｡
‫実は2つのサービスを持っているんです｡
‫ひとつは前回と同じNginxのプロキシ､ もうひとつは前回と同じApacheのWebサーバです｡
‫しかし､ 2つほど違うことがあります｡
‫Nginxのデフォルトイメージを指定するのではなく､ 実際にカスタムイメージを構築しています｡
‫ここでは､ 実際にいくつかの引数を与えて､ 使用する必要があるDockerfileが特別な名前のDockerfileであることを伝えていることがわかります｡
‫そのDockerfileを､ 今あるこのカレントディレクトリにビルドしてほしいのです｡ ビルドするときにそのイメージにnginx -customという名前をつけてほしいのです｡
‫それをローカルキャッシュに保存してくれるんです｡ そして､
‫その下の方にあるのが､ Apacheが動作するWebサーバーです｡
‫ここでやったことは､ 実際にいくつかのHTMLソースファイルをApacheサーバーにマウントしたことです｡
‫例えば､ 私がウェブ開発者だとすると､ 静的なウェブサイトをこのHTMLディレクトリの下に置いて､
‫あまり気にする必要のないようにしています｡
‫ちょっとしたブートストラップ・テンプレートを使っているだけなのです｡
‫ローカルではエディタで編集していますが､ 本番ではNginxのプロキシを経由して編集することになります｡
‫そこで､ 本番環境をできるだけローカルで再現し､ バグや問題を排除しておきたいと考えています｡
‫この場合､
‫Nginxが必要で､ このNginxの設定は本番サーバーで使用されるものであることが分かっているので､
‫ここではそれを使用することにしています｡
‫実はこれ､ 以前と同じNginxの設定なんです｡
‫docker compose upコマンドを実行すると､ まずこのイメージの名前がキャッシュにあるかどうかが確認されます｡
‫もし見つからなかったら､
‫このビルドコマンドを使ってDockerfileを検索し､ 私のイメージをビルドすることになります｡ このDockerfileを見ればわかるように､ 実はとてもシンプルなものなのです｡
‫特定のバージョンのNginxを使用して､ ファイルをコピーするだけです｡
‫Docker HubからNginxの設定情報を取得し､ 私のNginxの設定情報をコピーしています｡
‫前の例で､ composeファイルを通してNginxの設定を取り込むためにバインドマウントを行ったのを覚えていますか？
‫この場合は､ 画像全体を構築してほしいだけです｡
‫このプロキシ設定を変更する必要はあまりないので､ 常に変更できるようにマウントしておく必要はないですね｡
‫ただ､ 走らせたいだけなんです｡ そうだろ？ だから､ 作るんです｡ 画像キャッシュに置いておく｡ 最初に作ってしまえば､
‫本当に何度も作り直す必要はないでしょう｡
‫だから､ そこそこでいいんです｡
‫それから､ ホームページで編集や開発をするときは､ この設定をしておくとライブ編集ができるようになりますね｡
‫ここに戻って､
‫docker compose upを実行すると､ 何が起こったかを順を追って見ていきましょう｡
‫最初にネットワークを作ったのは､ この会社です｡
‫それは当たり前のことなんです｡ それができるのです｡
‫すると､ 実はプロキシサービスが探している画像を持っていないことがわかるのです｡ だから､ それを構築することになるのです｡
‫つまり､ Dockerfileを取り出し､ 通常のdocker buildコマンドを実行するのと同じようにビルドしているのです｡
‫そして､ 「今回は画像が見つからなかったのでビルドしました」と､ 親切に教えてくれるのです｡
‫しかし､ 将来的にそのイメージを変更する必要がある場合は､ docker compose buildやdocker compose
‫up -buildコマンドを使う必要がありますね｡ イメージを手に入れたら､ 次は実際にコンテナを作ってみましょう｡
‫その後､ Webサーバーとプロキシサーバーを起動しています｡
‫すべてが正しく動作していれば､ 私はlocalhostを取得できるはずです｡ デフォルトのテンプレートが表示されましたが､ これはブートストラップ・テンプレートです｡
‫すべてうまくいっているように見えます｡
‫実際､ ここに行ってみると､ すべてのログが表示され､ 明らかにたくさんのアセットがあることがわかるんです｡ それぞれのログエントリーがあり､ プロキシを経由してウェブサーバーを経由することになるのです｡
‫そのディレクトリを編集用にバインドしているので､ 実際にエディタに戻ることができるのです｡ ウェブデベロッパーとして､ ウェブサイトの何かを編集することもできます｡
‫ブートストラップ開始のタイトルに入るかもしれません｡
‫そのファイルを保存しておくと そして更新すると､ そのバインドマウントのためにウェブサイトが再び更新されます｡
‫これは､ ローカルにカスタム画像を構築する必要がある､ 非常に一般的な開発者のセットアップの好例です｡
‫また､ 実行時に編集できるように､ いくつかのファイルをアプリケーションにマウントする必要があります｡
‫もちろん､ データベースをバックアップするアプリケーションが必要な場合は､ ここにデータベースサーバー用の3番目のサービスを追加するだけです｡
‫そして､ 戻って後片付けをする｡
‫デフォルトでは､ その画像は実際には削除されないことに注意してください｡
‫この一番上に､ 構築されたnginxのカスタムがあることにお気づきでしょう｡ しかし､ docker compose down コマンドがあります｡
‫ヘルプを見ると､ rmiオプションがあり､ 実際にビルドしたイメージや使用しているイメージを削除することができることがわかると思います｡
‫このオプションには､ 「画像フィールドにカスタムタグが設定されていない画像のみを削除する」という項目があります｡
‫もし､
‫この作業をもう少し自動化したいのであれば､ この画像コマンドを削除することができます｡
‫それを削除しよう｡ それなら早く片付けたい｡ 自分の画像を消すだけです｡
‫docker image rm custom. ご覧の通り､ そこそこ消えました｡
‫わかりました｡ docker compose upをもう一度やりたい｡
‫そして､ 今回は-dを行います｡
‫Composeのこれらの例では､ ディレクトリの名前をプロジェクト名として､ コンテナ､ ボリューム､ ネットワークの名前を実際に付けていることにお気づきでしょう｡
‫Composeでは､ 名前の衝突を防ぐために､ すべてのアセットの先頭にディレクトリ名を追加して､
‫他のアセットと衝突しないようにしています｡
‫実はこのプロキシ名､ コマンドラインから変更することができます｡
‫Composeのドキュメントをチェックしに行くと｡
‫しかし､ 私がここで言いたかったのは､ ここでdocker image lsを実行すると､ 実際に私のイメージに名前を付けてくれていることがわかるということです｡
‫だから､ 技術的にはその画像オプションを使う必要はないんだ｡
‫しかし､ 後で特定できるように､ 具体的な名前が欲しい場合は､ そうすることができます｡
‫というのも､ docker composeを実行すると､ rmiタイプを使用できるとヘルプに書かれていたからです｡
‫だから､
‫掃除するとき､ 私はDockerの環境をきれいに保ちたいので､ am rmi localをすることができます｡
‫これは､ 実際にそれらの画像も削除することになります｡
‫この下の方に､ 画像を削除したことが表示されます｡
‫いつもすることではありませんが､ 大きなプロジェクトでカスタム画像をたくさん使っていて､ そのプロジェクトで開発していないときにシステムを爆発させたくない場合､
‫rmi ローカルを使うと､ 作成しなければならなかったカスタム画像を常に追跡することができるのです｡
‫もちろん､ ここでallを使うと､ このプロジェクトで使われたすべての画像を削除してしまいます｡ この場合､ httpd Apacheウェブサーバを削除してしまうかもしれませんし､
‫その画像をしばらく残しておきたいかもしれませんから｡
‫OKです｡
‫このセクションでは､ Composeについて多くを学びました｡
‫この講座の残りの期間中､ Composeを使用する予定です｡
‫このスキルをどんどん高めていきましょう｡