‫さて､ 複数ノードのswarmを作成し､ オーバーレイネットワークとDockerサービスを作成する基本を理解したところで､
‫Swarmの次の本当にクールなもの､ つまりスタックについて説明します｡ パンケーキの積み重ねではなく､
‫サービスの積み重ね｡ 1にある｡ 13､ Dockerは､ スタックの上に抽象化の別のレイヤーを追加する､
‫本当に素晴らしい機能を追加しました｡ 基本的にはSwarmの制作用ファイルをComposeしています｡ スタックにコンポジットファイルが入るようになりました｡
‫その中には､ 宣言的な定義と呼ばれるものがあり､ 最終的な結果をこうしたいということを表明しています｡
‫そして､ それをすべて把握するのがスウォームの仕事です｡ 今はサービスだけでなく､ ネットワークやボリュームも重要です｡
‫そして､ ちょっとだけスニークピーク｡
‫実は秘密も含まれているのですが､ それはこれから何回かの講義でお話しします｡
‫docker stack deployという新しいコマンドを使って､ このComposeファイルをインポートし､ その中に入れたコマンドを実行することができるようになりました｡
‫これをすべて管理するのがスタックです｡
‫ネットワークを作ったり､ ボリュームを作ったりする必要はありませんが､ それは可能です｡
‫ComposeファイルでExternalというものを使って､ 「これはすでに私のswarmに存在するものです」と言うことができます｡
‫わざわざ作らなくても､ そういうのを使えばいいじゃん｡
‫でも､ 普通はスタックに全部やってもらうことになるんです｡ その方が楽だから｡
‫Compose ファイルに新しい機能が追加されるので､ まずはこれまでとよく似た機能から見ていきましょう｡
‫しかし､
‫この新しいデプロイされたキー､ つまり辞書を取得することで､ Swarmに特有のものを指定することができるようになるのです｡
‫レプリカはいくつ必要ですか？
‫フェイルオーバー時に何をしたいのか？ ローリングアップデートをどうするかとか､ ローカルの開発マシンでは気にしないようなことも､
‫どうすればいいのか｡
‫しかし､ その代償として､ まだビルドコマンドを実行することができないのです｡ これは､ Swarmでは決して起こらないことかもしれません｡ なぜなら､
‫ここでの考え方は､ 本番のSwarmではビルドを起こすべきではないということだからです｡
‫構築はCIシステムが行うべきことです｡
‫Jenkinsとか､ Codeshipとかもいいかもしれませんね｡
‫イメージをビルドしてリポジトリに置くと､ このスタックは実際にそれらのイメージをプルダウンして､
‫デプロイオプションでデプロイするものになります｡
‫しかし､ そこで朗報なのは､ 実はこの2人､ 仲がいいということです｡
‫ローカルマシンでは､ Composeはdocker-composeコマンドを実行すると､ 実際には無視されます｡
‫実際には､
‫展開された情報は一切無視されます｡ 実際に「おい､ ここに情報が展開されているじゃないか」と言われそうです｡
‫本当に使えないので､ 無視することにしています｡ 同様に､ Swarmで新しいスタックやスタックのアップデートをデプロイする際にも､
‫「ちょっと､ ここにビルドコマンドがありますよ」と表示されるようになります｡
‫私はビルドはやらないので無視して進みます｡ ' いいところは､ ファイルを変更する必要がないことです｡
‫後ほど､
‫開発側と実運用側で必要なことを1つのComposeファイルで実現する方法について説明します｡
‫かなりイケてますね｡
‫最後に､ 実はDocker Compose CLIというバイナリは必要ありません｡ それはあなたのスウォームである必要はありません｡
‫なぜなら､ 実際のコマンドであるcomposeは､ プロダクションツールではないからです｡
‫生産用として設計されたものではありません｡
‫開発者やシスアドのヘルパーツールとして設計されました｡
‫私たちのマシンのローカル作業には､ 本当に最適なんです｡
‫swarmというのは､ 基本的にDocker Engineのことです｡ Docker Engineは､ そのスタックコマンドを使用してComposeファイルを受け入れることができるようになりました｡
‫Docker Composeをサーバ上のどこにも必要とせず､ Composeファイルを読み込むことができます｡
‫サービスを振り返るときに､ 本当に簡単におさらいしておきましょう｡
‫私たちのサービスはこのようなものです｡
‫私たちがサービスを作ると...
‫は､ 仮にNginxとします｡ そして､ そのレプリカを3つ指定したとします｡
‫そして､ オーケストレーターに3つのタスクを作成し､ それらのタスクが特定のサーバーやノードを見つけ､
‫コンテナを作成するのです｡
‫新しいスタックでは､ 複数のサービス､ 1つ以上のサービスということになりますね｡ そこに何十ものサービスを入れることができるのです｡
‫その1つのYAMLファイルの中で
‫これらのサービスは､ 以前のサービスと同じように動作しますが､ Composeファイルでボリュームやオーバーレイネットワークができるようになりました｡
‫そして､
‫その結果､ スタックと呼ばれるものができあがるのです｡ スタックはそれらすべてをコントロールするものです｡
‫そして､ 実際にすべてのオブジェクトにきちんと名前をつけてくれるので､ どのオブジェクトがどのスタックに関係しているのかが簡単にわかります｡
‫後ほど説明しますが､
‫これは､ この特定のものがどのスタックから来たのかを判断できるようにするためのメタデータです｡
‫だから､ これは本当にすごいことなんです｡
‫YAMLファイルを使って､ サービスコマンドに入力する必要がないようなことを実際に行うことができるようになりました｡
‫サービスコマンドはすでに扱いにくく､ 長くなっていましたから｡ そして､
‫そのコマンドを実行するためにBashスクリプトを作ることになるのですが､ これがまた面倒くさいんですよ､ これが｡
‫そこで､ Swarmを導入して8ヶ月が経過した今､ それらのサービスを管理するこのスタック機能を手に入れたのです｡
‫スタックは1群分しかないことに注意してください｡
‫そうだろ？ 多くの群れができない｡
‫1つのswarmで動作させることで､ すべてのノードを制御し､ すべてのサービス､ ネットワーク､ ボリュームをデプロイすることができるのです｡
‫この図には､ 実はもう一つ､ 秘密というものがあって､ スタックはそれらも制御することができるのです｡
‫それは､ この後の講義で確認することにしましょう｡ OKです｡
‫スタックとその仕組みについて見ていきましょう｡
‫先ほど構築した3ノードのswarmに戻りました｡ 他の2つのノードは特に必要ないので､ node1のウィンドウを最大化することにします｡
‫少なくとも､ 私は彼らのsshコマンドラインを必要としません｡
‫このセクションでは､ 以前の講義で行った投票アプリの例を使用します｡
‫その時の設計を思い出してみると､ 5つの異なるサービスがあり､ それらはすべて互いに依存し合っていました｡
‫そして､ 最終的に2つの異なるウェブサイトが出来上がりました｡
‫必要な価値観やオプションをすべて盛り込んだ最高のサービスリストを作り上げ､ 完璧なものに仕上げたのでしょう？
‫今､ それはもう必要ないとお伝えしたいのです｡
‫私たちにとって､ それらを使うことは本当に重要なことでしたし､ すべてがスタックファイルを必要とするわけではありません｡
‫でも､ 今はスタックファイルがあるんです｡
‫このファイルはComposeファイルのように見えると思いますので､
‫ちょっと見てみましょう｡ 少なくともバージョン3以上である必要があるため､ 変更しなければならない唯一の本当のキーポイントです｡
‫今現在の最新バージョンはバージョン3です｡ 1ですが､ これから変化・成熟していく中で､ 変わっていくと思います｡
‫ただし､ スタックを使用するためにはバージョン3が必要です｡
‫redis､ db､ voteなど､ おそらく皆さんと同じようなものを使っていることに気がつくと思います｡
‫皆さんは､
‫それらの画像や必要なポートなどを熟知していることでしょう｡
‫しかし､ この場合､ デプロイに気づくはずです｡
‫Deploy hereは新しいオプションです｡ ここで､ レプリカの数を指定しているのがわかると思いますが､
‫これは､ そのイメージを一度に何枚実行する必要があるかということです｡
‫そして､ アップデートを行うとどうなるのか｡
‫そのため､ 実際にスタックアップデートを行うと､ サービスアップデートが行われることになります｡
‫それをどう展開させるか｡
‫そうだろ？
‫すべて同時にダウンさせるか？ 一度に1つだけでいいのですか？
‫その間の遅延はどのくらいですか？
‫ここにはいろいろなオプションがあります｡
‫まだほんの一部ですが､ 再起動ポリシーを設定し､ コンテナに障害が発生した場合は自動的に再起動するようにしています｡
‫このデータベースの下に､
‫特定のノードにあることを確認するための制約があるのがわかると思います｡
‫制約についてはまだあまり話していませんが､ オブジェクト､ つまりコンテナやイメージなど､
‫SwarmやDocker自体で作成したり破棄したりできるものにはラベルを付ける方法があります｡
‫実際には､ ノードも含めてラベルを割り当てることができますし､ マネージャーとなるノードには独自のラベルが付与されます｡
‫このコンテナは､ このロールを持つノードで実行する必要があります」と言うだけで､ 非常に簡単に実行できます｡
‫素晴らしい例ですね｡ 下にスクロールしていくと､ 以前にも見たことがあるような並列処理のオプションがあります｡
‫このディレイオプションはかなりクールです｡ 回転するコンテナがある場合､ ウォームアップのような時間を設けるとよいでしょう｡
‫もしかしたら始まっているかもしれませんが､ 実際にライブになるのは60秒後とかかもしれません｡
‫そこでディレイを入れることができます｡ 実際にブルーグリーンデプロイメントを行う際には､
‫後でそれらを確認することになります｡ とりあえず､ それらはすべてごく標準的なものであることがおわかりいただけると思います｡
‫実は､ ここにはもっと多くの選択肢があるんです｡ 実際に､ 私がこれに特定のラベルを付与しているのがわかると思います｡
‫再起動ポリシーのウィンドウと最大試行回数を設定しています｡
‫だから､ 再起動を試みても失敗が続けば､ 3回以上試すことはないでしょう｡
‫調べてみよう｡
‫あとはcomposeのためにdocker stack deploy -cを実行するだけです｡ そこで､ Composeファイルを使用することにします｡
‫今はvoteappと呼んでいます｡ そして､ そこに行く｡ 実際にすべてを作って､ そんなに早く回転させたわけではありません｡
‫スケジューラーにオブジェクトを作成し､ サービスを作成し､ タスクを作成し､ コンテナを作成するというプロセスを経て､
‫オブジェクトが作成されるだけです｡
‫また､ ここにあるようなネットワークを作る必要もあります｡ フロントエンドとバックエンドがあったので､
‫それらを作成し､ デフォルトのネットワークも作成しました｡
‫そして､ このビジュアライザーのオプションが表示されますが､ これは以前は使用していなかった新しいものです｡
‫それはすぐにわかります｡
‫では､ docker stackコマンドをもう少し見てみましょう｡
‫デプロイできることがわかると思います｡ それはもうやりましたよ｡
‫それから､
‫ls､ ps､ rm､ servicesです｡
‫だから､ このコマンドにはあまり特徴がないんだ｡
‫すべての機能はComposeファイルや作成するオブジェクトの中にあるので､ とてもシンプルです｡
‫すでにすべての作業を終えているので､ lsのようなことをすれば､ すべてのスタックを表示することができます｡
‫かなり基本的なコマンドです｡ 1しかないんです｡ そして､ psを実行すると､ 実際に表示されるのは......｡ おっと名前を指定しないと｡
‫の票を投じる｡
‫その名も「voteapp」｡
‫それを正しく理解しなければならない｡
‫OKです｡
‫もう少しよく見えるように､ 話を戻しますね｡ すぐそこです｡
‫これが実際の作業です｡ そうすれば､ どのノードで動作しているかがわかります｡
‫実は容器ではないんです｡ 実はここに出てくるのは､ このタスクなんです｡ なぜなら､ 実際の容器であれば､
‫大きく長い名前が見えるはずだからです｡ というのも､ 先ほど作成したサービスは､ 実際にdocker psを実行すると､
‫とても長い名前になっていたんです｡
‫そうだろ？ ドッカーコンテナのlsやドッカーpsを実行すると､
‫このように本当に長い名前が表示されます｡ すべてのコンテナに一意な名前を付ける必要があるため､ すべてのコンテナにGUIDを付けるからです｡
‫そうやって､ 常にユニークで､ 決してぶつからないことを保証しているわけです｡
‫そして､ 最後がこちらのdocker stack
‫services voteappです｡
‫実はこれが一番好きなんです｡ 自分のレプリカが表示されるから｡
‫サービスのlsをするようなものです｡
‫自分が起動したレプリカの数が表示されるので､
‫適切な数のコンテナがすでに起動されているかどうかがわかります｡ それから､ もっと深く掘り下げるなら､ Docker
‫Stackのpsを行うことができます｡ 実際にタスク名が表示され､ どのノードで実行されているかがわかります｡
‫この2つを合わせると､ 実際にこのアプリケーション全体がどのように動いているのか､ 全体像が見えてきます｡
‫ネットワークに飛び込みたい場合は､ 通常行うのと同じように､ docker network
‫lsを実行すればいいのです｡
‫そして､ このアプリのために作られた3つの新しいオーバーレイネットワークが見えます｡ そして､ アプリ名が常に先頭にあることに注目してください｡
‫スタックは常にサービス名の前に置かれる｡
‫だから､ 各スタックは自分の名前が先頭に来るようにする｡
‫そして､ それを確認しに行こう｡
‫ブラウザを立ち上げてみる｡
‫わかりました｡
‫5000番ポートで見ることができる｡
‫投票サイトを稼働させました｡
‫5001に行く｡
‫結果サイトがあるので､ これを叩いてから結果を見ればいいんです｡
‫それから､ この新しいのはビジュアライザーと呼ばれるものです｡
‫8080でやってます｡ ビジュアライザーは､ 実はデモ用としてかなり使えるツールなんです｡
‫それは実際に作られて... ちなみに､ これらはすべてDocker社製で､
‫このセクションのリソースセクションにあるオープンソースのレポを参照してください｡
‫だから､ サービスごとに色を変えているんです｡
‫voteappの結果は､ 緑です｡
‫そして､ レディスはマスタードのようなもので､ ボートはピンクです｡ 2つの投票があり､ 2つのレディーズがあるのがわかると思います｡
‫群れの中で何が起こっているのかがわかるのは､ とてもいいことだと思います｡
‫実際に自分のファイルに入って変更をしたら
‫投票アプリで､ レプリカを5個に変更するとしましょう｡
‫サービスを更新して行くことができました｡ でも､ それはアンチパターンのようなものです｡ もし､ docker service update
‫のようなコマンドを手動で入力したら､ 次にこの
‫YAML ファイルを再適用するときに､ その変更を上書きしてしまうことになります｡
‫AWSでクラウド構築やその他の構成管理をしたことがある人なら､ このような設定ファイルを使ってインフラを管理したら､
‫常にこのファイルを使いたい､ それが真実の源になる､ ということを知っているでしょう｡
‫ですから､ おそらく本番環境では､ バージョン管理されたGitリポジトリに保管されたファイルのようなもので､
‫変更を管理し､ 変更をロールバックできるようにするのでしょう｡
‫この場合､ このファイルをすぐに変更して､ 同じコマンド､ docker stack deployを実行します｡
‫アップデートがないことに気づく｡ なぜなら､ 同じスタックにデプロイして､ それが既存のものであることを認識し､
‫この変更に基づいて更新するつもりだからです｡
‫更新するためには､ 正しい名称を使うようにしなければならないのです｡
‫だから､ voteappなんです｡ そして､ サービスを更新中と言いながら､ サービスを変更する必要があることを認識していることに気づきます｡
‫次に､ ビジュアライザーに移動すると､ すでにそれがあることがわかります｡
‫今日は遅すぎたね｡
‫大群についていけない｡ 現在､ すでに5つの投票アプリが稼働しています｡
‫稼働や起動に時間がかかると､ 実際にここで状態が変化していくのを見ることになるのです｡
‫でも､ シンプルなWebアプリなので､ すぐに立ち上がりそうですね｡
‫なるほど｡
‫それがスタックです｡
‫それでは､ スタックに秘密を追加してみましょう｡