‫さて､ ここまででオーバーレイネットワークとルーティングメッシュによるSwarmのスケーリングについて学んできましたが､ 実際にSwarmシナリオに展開するために必要なアセット､
‫つまりオブジェクトを作成するプロセスを見ていきたいと思います｡
‫そのため､ docker runコマンドは使わなくなりましたが､ ネットワークやボリュームは同じようでいて､
‫少し違っています｡
‫多層アプリの実際のシナリオを紹介したいと思います｡ 今回はDockerのDistributed Voting Appを使用します｡
‫実はこれ､ 「例の投票アプリ」と呼ばれているんです｡
‫Dockerの基調講演や､ 他のラボやチュートリアルで見たことがあるかもしれませんね｡
‫これはかなり一般的で､ 素晴らしいアプリだと思います｡ なぜなら､ 少なくとも5つのロールや､ デプロイする必要のある異なるコンテナを持っているからです｡
‫そして､ それらはすべて特別な機能を果たし､ 実際に機能するもの､ 実際にやるべきことをやっているのです｡
‫それで遊んでみると､ Webフロントエンドやワーカーバックエンドといった非常に典型的な分散アーキテクチャのコンポーネントがあり､
‫データベースにはキーバリューがあります｡ やっていて本当に助かると思います｡ 今回は､ swarm-app-1 というディレクトリを使用します｡
‫実は､ 私たちの講座のレポにあるんです｡ その中には､
‫Readmeと画像しかありません｡ そのReadmeから､ このアプリが完全に機能するために必要なボリュームといくつかのネットワークと5つのサービスを作成する必要があることがわかります｡
‫これらのコマンドをローカルで試してみたり､ 実際にテキストエディタで書いてみたり､ ちょっと複雑になりそうなので､ まとめてみたりするといいかもしれませんね｡
‫docker
‫service createを行う際には､ 特定のネットワークに接続し､ ポートを開放し､ 特定の名前で呼び､
‫特定のイメージを使用する必要があります｡ そのため､ ローカルで編集し､ Swarmがある場所のシェルにカット＆ペーストする方が簡単かもしれません｡
‫でも､ それは私だけのこと｡
‫本番のSwarmではビルドをしたくないので､ すべてDocker Hubのイメージを使うことにしています｡
‫これは､ 通常､ 本番のSwarmに望む処理ではありません｡
‫通常､ Docker HubやDocker Cloudのような自動化されたオンラインサービス､ あるいはCI/CDパイプラインのどこかで構築を行いたいところですが､
‫本番環境のSwarmのリソースを食ってしまうようなことはありません｡
‫このシナリオでは､ イメージは別の場所でビルドされてDocker Hubに保存されており､
‫それらを最新バージョンであろうとSwarmに引き込むだけでよいと想像できる｡
‫これは､ コンピュータサイエンスにおける多くの事柄と同様､ 半分が科学で半分が芸術であると言えるでしょう｡
‫あなたのコマンドは､ 私のとは全く違う順番だったり､ 全く違うオプションの順番だったりするかもしれません｡
‫ネットワークの呼び方は様々でしょう｡
‫それでいいんです｡
‫最終的には､ アプリケーションが動作し､ 適切な方法で互いに通信でき､ すべてのポートが公開され､
‫データがボリュームで保護されていることを確認することになります｡
‫早速､ その内容を見てみましょう｡
‫そのためのコマンドやアーキテクチャを設計しなければならないと想像してください｡
‫そして､ このアプリを書いた開発者があなたに贈るのは､ これです｡
‫まあ､ この場合､ このアプリを書いたのはたくさんの開発者でしょうね｡
‫なぜなら､ 実際にはPythonで動くWebフロントエンドがあり､ Nodeで動くWebバックエンドがあるからです｡
‫.NETで動作しているワーカープロセスがあります｡ .NETを使用し､ RedisのキーバリューストアとPostgreSQLのデータベースを使用しています｡
‫これは私がよく目にすることですが､ 異なるチームがソリューションの異なる部分を書いていて､
‫そのシナリオに最適と思われる言語を選択することができるのです｡
‫そして､ コンテナの世界では､ このようなアプリケーションは本当に輝きます｡ アプリケーションはすべて分割されているので､
‫技術的には同じマシン上で動作させることができますが､
‫NodeとPythonの依存関係が衝突してしまわないように､ すべて互いに保護されています｡
‫投票アプリにはありませんが､ 小さな矢印が表示され､ 投票アプリの部分からユーザーが入ってくるはずです｡
‫そして､ 投票アプリが実際にこのアプリケーションへの投票をプッシュしなければならないことがわかります｡ ちなみに､ あなたは猫や犬に投票することになります｡
‫それをRedisにプッシュして､ ワーカーが実際にRedisシステムのキューに何かないかチェックして､
‫その結果をPostgresにプッシュして､ WebSocketバックエンドに表示するんですが､ これは実際に投票中にライブアップデートされます｡
‫ディレクトリを開くと､ これまでと少し違うことがいくつかあります｡
‫しかし､ サービスエリアは､ アプリケーションのことは知っていても､ 実際にDockerでどのように実装すればいいのか分からない人が書いたようなものです｡
‫そして､ それはかなり一般的なシナリオです｡
‫サービスには､ デプロイする画像と､ それに付ける実際の名前が記載されています｡
‫これらは､ 残念ながら､ ネットワーク上でどのような名前を探すのかがハードコーディングされている画像なのです｡
‫理想的には､ 名前に対して必要なことをその場で設定できるアプリケーションが望ましいのですが､ この場合､
‫voteは特にredisというDNSレコードを探そうとしています｡ 実はここに2つのネットワークがあることがわかります｡
‫私たちは､ フロントエンドとバックエンドのネットワークを持っています｡ また､
‫大規模なアプリケーションでは､ バックエンドのネットワークにあるデータベースを保護し､ フロントエンドのユーザーアプリが直接アクセスできないようにするのが一般的です｡
‫そして､ このワーカーが実際には2つのネットワークに接続されていることがおわかりいただけると思います｡
‫そのため､ createコマンドを使用する際には､ docker runではなく､ docker service createを使用することを忘れないでください｡
‫そのため､ docker service createコマンドを使用する際には､
‫--networkを2回指定する必要があります｡
‫もちろん､ 最初にネットワークを作ることは知っているはずです｡
‫だから､ その一部がここに明記されているのです｡ また､ もしイメージが必要であれば､
‫アーキテクチャ図もこの中にあります｡
‫もちろん､ Dockerのドキュメントもありますよ｡ service createコマンドの--helpを使用すると､
‫必要なすべてのオプションが表示される場合があります｡
‫3～4本でいいんです｡ もし､ コマンド自体に行き詰まったら､
‫このセクションのリソースにある実際のドキュメントを見直すとよいでしょう｡
‫しかし､ Swarmに関するこの特定のドキュメントでは､ 実際にサービスの作成とサービスの設定について説明しています｡
‫というわけで､ ちょっと文字数が多いのですが､ ここでつまづいたときに役立ちそうな情報がたくさん詰まっています｡
‫次のビデオでは､ 実際に私があなたであるかのように､ この一連の流れを自分で実行してみます｡
‫がんばって､ 楽しんでください｡