‫このセクションでは､ Swarmについていろいろと説明してきました｡ Swarm､ Stacks､ Secretsの3つの機能は､
‫私たちの制作をより簡単にするための素晴らしい機能です｡
‫Composeのファイルを実際に使って､ いくつかの方法で整理してみると､
‫どんな感じになるかをお見せしたいと思います｡
‫実際には1つのファイルでいろいろなことができるのですが､ 複雑になってくると複数のComposeファイルが必要になることがあるんです｡
‫簡単に説明します｡
‫嫌なら実際に自分でやる必要はない｡ ここでは､ これらのComposeファイルがどのように連携し､
‫環境を構築していくかの一例を紹介します｡
‫今回のシナリオでは､ ローカルの開発環境として､ docker compose upを使用します｡
‫今回はCI環境にdocker compose upのconfigとfileを使用して統合テストを行うことにします｡
‫そして､ 本番環境では､ これらのファイルを docker stack deploy に使用して､ 実際に本番環境をスタックでデプロイすることになります｡
‫では､
‫私のローカルマシンで､ 先ほどのDrupalのシナリオの例で､ データベースサーバーとWebフロントエンドを使います｡
‫これまでの課題で使用したDockerfileを用意しました｡ カスタムで､ しかもシンプルなdrupalのコンフィグをテンプレートで再構築しています｡
‫そして､ このデフォルトのcomposeファイルを用意します｡
‫これをオーバーライドと呼びます､
‫これからやることです｡ オーバーライドとは､ 標準のDocker Composeファイルを持っていて､
‫すべての環境に共通するデフォルトを設定することです｡
‫そして､ このオーバーライドファイルは､ デフォルトでDocker Composeが､ この正確な名前､ docker composeと命名されている場合､ このオーバーライドファイルを持っています｡
‫をオーバーライドします｡ ymlを使えば､ docker compose upをするたびに､ 自動的にこれを取り込んでくれます｡
‫このシナリオでは､ ローカルでの開発を想定しています｡ なぜなら､ これから入力する手打ちのコマンドは､
‫ローカルで最も簡単に入力したいからです｡
‫通常､ CI環境ではすべて自動化されているので､ これらのコマンドが多少長くても気になりません｡
‫しかし､ 私たちが本当に現地で欲しいのは､ 簡単なdocker compose upなのです｡
‫Docker Composeはこのファイルを自動的に読み込み､ Docker
‫Composeのymlファイル内の設定に上書きして適用します｡
‫ここで､ 画像名を指定していないことに注意してください｡
‫このオーバーライドファイルでは､
‫このカレントディレクトリにあるDockerfileを使ってローカルにイメージをビルドしたい､ ということでオーバーライドしています｡
‫8080にローカル開発用のポートを作りたいのですが｡ そして､ いくつかのボリュームをセットアップしています｡ ここでバインドマウントの例を挙げたので､
‫カスタムテーマを行うかもしれないことにお気づきでしょう｡ そして､ 前のセクションでやったように､ ホスト上のテーマをコンテナにマウントして､
‫ローカルでテーマを変更して､ サーバー上ですぐに確認できるようにしたいのです｡
‫ちなみに､ この例では､ 実はDrupalでテーマを開発する方法を知りません｡
‫そこにあるファイルを変更すれば自動的に反映されるというわけではないのですが｡
‫Webで開発を行う場合､ 通常､ Composeをいちいち停止して起動することなく､ このような方法で行うことができるという例を示したかったのです｡
‫この下のpostgresのところには､
‫先ほどと同じように環境変数とSecretの設定をしています｡ 定義されたボリュームがあり､ 下の方にファイルベースの秘密があるのがわかると思いますが､
‫ローカルで開発する場合はファイルベースの秘密を使用しなければならないからです｡
‫このprod､ つまりテストファイルを見ていると､ ちょっと面白いことになるんです｡ この方法は､
‫. をオーバーライドします｡ ymlは自動的にDocker Composeのコマンドラインに拾われます｡
‫prodやtestでは､
‫手動で指定することになりますね｡
‫そこで､ テスト用に､ -fコマンドを使用することになります｡
‫以前のセクションで覚えているのであれば､ -fはカスタムファイルを指定したいdocker composeをするときです｡
‫すぐにでもお見せしますよ｡
‫次に本番環境では､ Docker Composeのコマンドラインを本番サーバで実際に使用することはないので､
‫ここでは実際にDocker Composeのconfigコマンドを使用することにします｡
‫configコマンドは､ 実際には､ 複数のconfigファイルから出力されたものをスクイーズ（結合）して出力することになります｡
‫だから､ とてもクールでしょう｡
‫早速ですが､ テストファイルには､ drupalとpostgresがあるだけです｡
‫もしこれがJenkins CIやCodeship CIソリューションで､ コードをコミットするたびにイメージをビルドし､ それをこう呼んで､
‫テスト用にこのポートに置きたい場合を想像してみてください｡
‫それなら､ 偽のパスワードを使ってみる｡ しかし､
‫ボリュームを定義する必要はありません｡ なぜなら､ 実際に名前の付いたボリュームデータを保持しようとするつもりはないからです｡ 繰り返しますが､ これは単なるCIプラットフォームです｡
‫テストに合格したり､ 不合格になったりすると､ すぐにすべてを処分してしまうのです｡
‫このシナリオでは､ サンプルデータのシナリオを用意しました｡ CIソリューションでは､ カスタムのGitリポジトリやFTPでダウンロードしたデータベースを置いておくことができます｡
‫あるいは､
‫CIの初期化時に､ 実際にデータベースファイルをダウンロードするようなことが起こるかもしれません｡ CIテストのたびにデータベースを作成する必要はなく､
‫サンプルデータのディレクトリをpostgresのデータがあるべき場所にマウントするだけです｡
‫そうすることで､ CIテストのたびに同じサンプルデータを持っていることが保証されます｡
‫これ以上､ 突っ込むのはやめよう｡ このCI用のファイルは､ そういう違いがあるのかもしれない､
‫ということを示したかっただけです｡
‫そして､ プロダクションでは､ 通常のプロダクションの懸念事項がすべてあります｡ 特定のデータに対してボリュームを指定しているのです｡
‫私たちの秘密を明記しています｡ そして､ 一番下にあるのが「社外秘」であることに注目してください｡
‫なぜなら､ 先の課題でやったように､ コマンドライン経由ですでにシークレットを入れているからです｡
‫ここで重要なのは､ これら3つのコンフィグはすべて何らかの形で異なっているということです｡ しかし､ これらはすべて､
‫2つのサービスとそのイメージを定義するだけのコアコンフィグ､ つまり基本コンフィグに関連しているということなのです｡
‫こちらでご覧いただけます｡ ここで､ その様子を思い出してみてください｡
‫これを終了して､ いくつかのコマンドを実行してみましょう｡
‫このディレクトリを見ると､ 基本ファイルと3つのオーバーライドファイルがあるのがわかると思います｡
‫繰り返しになりますが､ オーバーライドのことを思い出してください｡ ymlがデフォルトです｡
‫docker compose upを行うと､ ここで実際に行われるのは､ docker-composeを使うことです｡ ymlを先に実行し､ その後にオーバーライドを行います｡
‫ymlの方を上にします｡ 起動してからすぐに見られるように､
‫-dを入れたいと思います｡ drupalのイメージでdocker inspectしてみる｡
‫そして､ ここでお見せしたいのは､ すべてのマウントがリストアップされていることです｡
‫オーバーライドファイルは､ これらのマウントをすべて定義した場所であるため､ オーバーライドファイルが使用されたことがわかります｡
‫だから､ それを拾ったことがわかるのです｡
‫当然､ ベースとなるものを拾わなければ､ どんな画像を使えばいいのかすら分からないので､ 実際には「Composeファイルが不完全だ」と私たちに文句を言うことになるのです｡
‫あれは効きましたね｡
‫早速ですが､ ダウンをしてみましょう｡
‫CIソリューションで必要なコマンドを実際に実行する場合､ CIソリューション上で行うべきことは､ Docker Composeが存在し､
‫インストールされ､ docker composeコマンドを実行できることを確認することです｡
‫それから､
‫-fを指定すると､ fの順番はベースファイルが常に最初になる必要があります｡
‫そこで､ docker compose yml､ そしてdocker compose testとしました｡
‫これを最後にupと-dでやって､ 同じdrupalを調べてみると､ バインドマウントがないことに気がつくと思うんです｡
‫テストファイルでは､ それらを指定しなかったので､ 完全に欠落しています｡
‫Drupalの情報保存は､ CI実行の最後に捨てられるので､ 実は必要なかったのです｡
‫そして3つ目が､ プロダクションコンフィグです｡
‫生産コンフィグが少し変わってきますね｡
‫上矢印を押して､ ここでプロッドをするんです｡ upコマンドの代わりに､ ここでやりたいのはconfigです｡
‫コンフィグのヘルプを見ると､ 2つのオプションがあるだけで､ どちらもこの状況にはあまり関係ありません｡
‫ここでやりたいことは､ configを単体で実行することです｡ 実際に行われるのは､ 両方のファイルを見て､
‫それらを1つのComposeファイルに相当するものにまとめることです｡
‫そこで､ CIソリューションのどこかでこのコマンドを実行することができます｡ そして､ それをファイルに出力します｡
‫この出力ファイルは､
‫スタックを作成または更新するために､ 本番で公式に使用されるものになります｡
‫ただし､ ここで少し注意点を投げかけておきたい｡
‫これは､ 比較的新しいものばかりです｡
‫シークレットとスウォームスタックは比較的新しいものであることが分かっています｡
‫まだ2ヶ月しか経っていないんですよ｡
‫この収録時点では
‫だから､ 荒削りなところがあるんです｡
‫このconfigコマンドを実行したところ､ secretがリストアップされていないことにお気づきでしょう｡
‫現状ではバグですね｡
‫実は､ そのバグを潰せないか､ Dockerチームと一緒に考えているところなんです｡
‫ですから､ あなたがこれを読むころには､ すでに修正されているかもしれません｡
‫本番にデプロイする前に､ その設定行の出力を確認してください｡
‫次に､ Compose Extendsオプションは､ ここでは説明しませんでしたが､ Composeファイルを上書きする別の方法で､
‫実際にoverrideファイルを使用して､ その中にextendsセクションを定義します｡
‫少し宣言的なので､ 理解しやすいと思います｡ この項の参考文献にリンクを貼っておきます｡
‫ただ､ そのExtendsオプションはまだSwarmsのスタックでは使えません｡
‫私たちが期待していたような完全なアプリのライフサイクルが得られないので､ ここでは触れませんでしたが､
‫ある時点でそれについて何かをしてくれることを期待しています｡
‫Swarmに追加するか､ より良いワークフローを作るか､ といった感じです｡ なぜなら､ これらのツールで実現しようとしているのは､
‫開発からテスト､ 本番までのライフサイクルを､ 同じ設定と同じイメージで完全かつ簡単に行えるようにすることだからです｡
‫このような方法でアプリを作ったり､ 複雑なシナリオのために独自のComposeファイルを拡張する方法について考えていただけたらと思います｡
‫なぜなら､ 以前は複数のスクリプトを実行する必要があったことを､ 1行のコマンドで実行する人を見たときほど､
‫Dockerで早く笑顔になれることはないからです｡