‫では､
‫このアーキテクチャに基づいて､ 各サービスを順を追って説明し､
‫その場でこのアプリを作成します｡ 実は､ このreadmeにコマンドを入力するのは､ 論理的な場所だと思うので､
‫ここに入力しようと思っているんです｡ そして､ それをカットして自分のノードに貼り付ける｡
‫思い起こせば､ こちらには3ノードのSwarmがあります｡ docker node lsを実行すると､
‫ここに3つのノードがあることがわかります｡ すべてマネージャーノードです｡
‫コンテナも動かしていないし､ サービスも当然ない｡ まず､ 一番上にネットワークが必要だとか､
‫ボリュームが必要だとか書いてありますよね｡
‫だから､ おそらくネットワークは邪魔にならないし､ それを利用することもできるだろう｡ docker network create
‫d overlay と入力できる｡ オーバーレイネットワークは､ Swarmで使える唯一のネットワークであることを忘れないでください｡
‫オーバーレイでは､ あたかもすべてのノードがローカルネットワーク上にあるかのように､ ノードをまたぐことができるからです｡
‫そして､ backendと呼びたい｡
‫そして､ まったく同じことを､ フロントエンドと呼ぶだけにしたい｡
‫さて､ この2つのネットワークは､ 本質的には何も特別なものではありません｡
‫異なるサービスを1つまたは2つにセグメント化することで､ 小さなファイアウォールのような役割を果たし､
‫保護のための分離を実現するのです｡
‫この投票1では､ docker
‫service createをする必要があることは分かっていますし､ 名前を付けなければならないので､ 名前投票をした方が良いかもしれません｡ そして､ コンテナの中で80番から80番ポートを公開し､ 特定のネットワーク上にあることを確認しなければなりません｡
‫そこで､
‫ネットワーク・フロントエンド｡ レプリカが2つ必要なんです｡
‫そこで､ レプリカ2｡ それから､ この名前をコピーして貼り付けるのもいいかもしれませんね｡
‫さて､ 実際にデプロイする前に､ これらすべてを作成しておこうと思います｡
‫実際にこの下にコピーしてみます｡ この作品は... は､ voteと呼ばれるのではなく､ redisと呼ばれるようになる予定です｡
‫その上でポートの公開を気にする必要はない｡
‫フロントエンドのネットワークに搭載されることになります｡
‫レプリカが2つ欲しい､ そして､ redis three twoがイメージとします｡
‫この下にある､ docker service create name workerは､ 2つのネットワークに入ることになります｡ ネットワーク・フロントエンドと...
‫おっと
‫言っていることをタイプしている...｡ ネットワークバックエンドで､ レプリカは1つだけです｡
‫...デフォルトでレプリカが1つなので､
‫実際にはレプリカを指定する必要はなく､ ポートも指定しない｡
‫私は､ そこに必要なのはそれだけだ､ と思っています｡ 画像の上にコピーすればいいんだ｡
‫では､ docker service create name db network backendです｡
‫ほら､ レプリカが1つ｡
‫あ､ この巻はやらなきゃ｡
‫ここで､ 音量についてです｡ v コマンドは docker サービスと互換性がありません｡ なぜなら､ さまざまな理由から､ サービスは典型的なDockerの実行よりも複雑になりそうだからです｡
‫それに､ 昔は-vの問題や制限もあったんですよ｡
‫そこで､ Dockerはそこから学び､ フォーマットを改善しました｡ しかし､ たまたま少し冗長で､ 最初にフォーマットを覚えるのが少し難しいかもしれません｡
‫また､ Dockerのドキュメントにもまだあまり記載されていません｡ これは､ コマンドとして登場してから1年も経っていないためです｡
‫そこで､ これをコピー＆ペーストするだけです｡ 基本的には､
‫1つのマウントコマンドに含まれる値のリストで､ 最小値はタイプ､ ソース､ ターゲットです｡
‫他にも追加できるものはありますが､ このシナリオで必要なのはこの3つだけです｡
‫そして､ 私のソースは､ スラッシュが入っていないので､ ただの名前付きボリュームであることがわかります｡
‫また､ スラッシュがあるとバインドマウントになってしまうので､ 別のタイプを指定する必要がありました｡
‫この下に､ -mount type volume, source db data, targetとあります｡
‫その通りだと思います｡
‫そして､ postgres 9だけでいいんです｡ 4.
‫そして､ 最後が結果アプリです｡
‫そこで､ docker service create name result network backend.
‫ポートをパブリッシュする｡ コンテナ内の80番ポートに5001を使用することにします｡
‫どちらか一方しか実行できない｡ ところで､ このアプリの問題であまり知られていないことですが､
‫このアプリはWebSocketを使用しています｡
‫ルーティングメッシュでは､ コンテナ間を行ったり来たりして､
‫WebSocketをうまく扱えません｡
‫このアプリでは､ 本当はプロキシを前面に出すべきなのですが､ まだこのアプリにはないので､ おそらく後のバージョンでアップデートして､
‫プロキシが出るように修正されるでしょう｡
‫そうすることで､ 冗長性を確保し､ 正しい容器にたどり着いたことを確認することができるのです｡
‫これをコピーして､
‫最後に貼り付けるのです｡ これの最後の値を見逃していることに今気づきました｡
‫では､ 一番上からコピー＆ペーストで｡ すでにネットワークが出来上がっているのです｡
‫そう､ これはレプリカが必要なんです｡ こちらで更新させてください｡
‫レプリカです｡ さて､ redisを作成します｡ これでよしとしよう｡
‫よし､ あれを作ったんだ｡ さて､ ところで､ サービスIDが返ってきましたが､ これはサービスが実際に正しくデプロイされたことを意味するものではないことにお気づきでしょう｡
‫すぐにでも見てみたい｡
‫残りを入れさせてください｡
‫わかりました｡
‫これで､ 残りのコマンドをこちらで実行できるはずです｡ そこで､ docker service lsで5つ全部を表示しています｡
‫そして､ レプリカの番号が一致していることにお気づきでしょう｡
‫それはいい兆候だ｡
‫つまり､ 1つは正常に作成されたことになります｡
‫さらに深く掘り下げようと思えば､ それぞれについてdocker service psを行うことができます｡
‫よし､ これで28秒走ったぞ｡
‫redisが1分ほど稼働しています｡ dbは53秒稼働しています｡ の票を投じる｡
‫ワーカーになります｡
‫このワーカーには､ シャットダウンに失敗したタスクと､ 実行中のタスクがあるのがわかると思います｡
‫それが47秒間も続いている｡
‫さて､ ではなぜこうなったのか､ 実は私は知っているのですが､ あなたは知らないかもしれないので､ 過去ログを作る必要があるかもしれませんね｡
‫今度は､ これがnode2上にあります｡
‫Dockerのオプションのconfigで有効にできる実験的な機能で､ 実は新しい実験的な機能であるdocker
‫service logsを行うことです｡ これは､ 実際には多くの異なるノードからログを取得します｡
‫うまくいけば､ 今年末のDockerの次期バージョンでリリースされるかもしれませんね｡
‫でも､ 今は実験的なものです｡ だから､ etc docker daemonのログ､ つまりdaemonの中で有効にする必要がありました｡
‫jsonファイルです｡ そして､ 念のためお伝えしておきますが､ これが実験を可能にする方法です｡
‫それは関係ないですね｡
‫これは､ ただ単に早く見せようと思ってやったことなんです｡
‫このエラーが表示され､ なぜそうなるのかわからないと思うかもしれません｡
‫そのログを見ることができる｡ そこで､ docker service log workerを...｡ 然うは ログワーカー
‫そして､ これは､ この特定の､ えーと､ これらは2つの異なる......
‫これは1つで､ その後数字が変わるのがわかりますね｡ 実は､ そうなんです｡
‫ここにあるのは､ すべて1つです｡
‫そのようなデバイスやアドレスはないと書かれています｡
‫つまり､ これは基本的に､ 他のサービスをまだ作っていなかったので､ 存在しないDNSレコードを探すサービスを作ったということです｡
‫そして「Dockerland」で想定されていることを実行しました｡
‫このようなエラーが発生した場合､ Dockerは実際にアプリがクラッシュしないようになるまで､ 適切に再起動や再デプロイを行うことができるため､ アプリはクラッシュするはずです｡
‫そして､
‫すべてのサービスを立ち上げるとすぐに､ すべてがクラッシュしなくなり､ 今ではすべてが機能するようになりました｡
‫そして､ それはpsワーカーをさかのぼって見るだけでわかることなのです｡ 3分間､ 正常に動作していることがわかります｡
‫では､ アプリを見てみましょう｡
‫IPアドレスだけ引き出せば､ 犬も猫も出てくるはずなんだけどな｡ 私は猫に投票するつもりです｡
‫そして､ その同じIPに5001番ポートでアクセスすると､ 結果アプリが表示されるはずです｡ それがこのアプリです｡
‫というのも､ redisでキャッチアップされ､ workerで処理され､ データベースに格納されるときに､
‫これがずっと続く場合のみ変更可能だからです｡
‫そのため､ それぞれのアプリサービスが互いに会話できることが分かっています｡ その気になればログを見ることもできますしね｡
‫でも､ それがデモなんです｡