‫わかりました｡
‫どこからDockerを起動していても､ 実は自分たちのテスト用に1ノードのswarmを作成することができます｡
‫Swarmがオンになっているかどうかを知る方法は､ docker infoを実行すれば､ Swarmが非アクティブになっていることが分かるんだ｡
‫つまり､ ここではSwarmが有効になっていないことがわかるのです｡ 繰り返しになりますが､ デフォルトでは､ DockerはSwarmの機能を一切有効にしていません｡
‫初期化のためのdocker swarm initは実行できるのですが｡ 約0.5秒で完了しましたよ｡
‫今あるのは､ 箱から出してすぐに使えるすべての機能と特徴を備えた1ノードのスウォームです｡
‫だから､ このコース全体の中で一番短いデモだったんじゃないでしょうか｡
‫つまり､ 今何が起こったのか？ 1つのコマンドを打ち込んで魔法をかける｡ 実は魔法ではなかったんです｡
‫DockerのGoプログラミングでは､ 非常に迅速かつ効率的なことがたくさんありましたが､ 基本的に､ 箱から出してすぐに､ PKIやセキュリティに関するたくさんのことができるのです｡
‫これは､
‫すべてのノードとすべてのマネージャの信頼を確立し､ 証明書に署名するために使用する､ スウォームのルート証明書を作成します｡ この最初のマネージャー・ノードは､ ワーカーではなくマネージャーであるため､
‫特別な証明書が作成されます｡
‫そして､ 他のノードで実際に使用できるトークンを作成し､ このスウォームに参加させるのです｡
‫それから､ バックグラウンドでスウォームAPIを有効にして､ Raft Consensus
‫Databaseというものを作っています｡
‫Raftは､ 複数のノードで一貫性を保つためのプロトコルであり､ あるものがある瞬間に利用できることを保証できないクラウドでの利用に最適です｡
‫そのデータベースをディスク上に作成するのです｡ 群れの構成や最初のマネージャーを保存し､
‫それを実際に暗号化するのです｡
‫バージョン1を前提とした場合｡ 13 以降の機種 その後､ 他のノードを待って､ 実際にデータベースの複製を開始します｡
‫繰り返しますが､ 他のノードを作成したときに発生するトラフィックは､ すべて暗号化されます｡
‫Swarmが登場したときに差別化できた重要な要素の1つは､ Swarmのバックエンドの構成管理に､
‫追加のキーバリューストレージシステムや何らかのデータベースアーキテクチャを必要としないことでした｡
‫何年も､ あるいは何十年もこの業界にいると､ 一般的にコンフィグDBという概念があります｡ これは､ オーケストレーションとオートメーションのシステムに関するすべての情報を保存する､
‫通常は冗長化する必要のある別のデータベース・システムです｡
‫Swarmは､
‫それをそのままDockerのデーモンに組み込んで､ 処理してくれています｡
‫私たちは決して何もする必要がないのです｡ パスワードの心配もありません｡ 特別なサービスを立ち上げるとか､
‫そういうことはありません｡
‫そこで､ コマンドラインに戻る｡
‫ここで気づくのは､ 「...」について書かれていることです｡ ワーカーをスウォームに追加したい場合､
‫これをカットアンドペーストして他のサーバーに追加するだけでよいのです｡
‫後ほど､ 実際に複数ノードのスウォームを構築する予定ですが､ 今はシングルノードのままにしておきます｡
‫それでは､ そこから得られるコマンドのいくつかを見てみましょう｡
‫まず最初に､ docker node lsを行います｡ この場合､ 作成した1つのマネージャーノードが表示されるだけです｡
‫リーダーとしてマークされていることがわかりますが､ リーダーは全マネージャーの中で一度に一人しか存在できません｡
‫今回も､ 1つしかないのだから､ 当然､ リーダーでしょう｡ 他にどのような選択肢があるか､
‫検討することも可能です｡ ノードコマンドは､ サーバーをスウォームに出し入れしたり､
‫ワーカーからマネージャーに昇格させたり､ マネージャーからワーカーに降格させたりするために使います｡
‫dockersのswarmコマンドを少し遡ると､ 実はコマンドの範囲が非常に狭いことに気がつきます｡
‫本当に初期化するだけで､ 参加も退会もできるのです｡
‫新しいロック解除コマンドについては､ 後の講義で説明します｡
‫とりあえず､ エキサイティングな新しいDockerサービスコマンドに焦点を当てましょう｡
‫ここでも､ swarm内のサービスはDockerの実行を置き換えます｡
‫事実はわかりませんが､ これは既存のDocker runの機能を壊したくないという考えが中心だったと思います｡
‫しかし､ Docker runは常にシングルホストのソリューションとしてゼロから構築されています｡
‫これは､ 通信先のシステムのローカルコンテナに焦点を当てるというものです｡ 一方､ クラスタの話になると､
‫個々のノードはあまり気にならなくなります｡
‫実際に名前をつけることはおそらくありません｡ ペットと家畜の例えを聞いたことがあると思いますが､
‫家畜は単なる数字に過ぎません｡
‫各ノードに個別に行き､ 個別のコンテナを立ち上げるということは､ 実際にはありません｡
‫私たちは､ サービスという形でスウォームに要件を投げかけるだけで､ スウォームがそれをどのように配置するか､
‫どのノードに置くべきかをオーケストレーションしてくれます｡
‫docker
‫service createは､ 新しい命令を与える方法です｡ 本当に簡単なことをやってみましょう｡
‫実際にアルパインの画像を起動してもらいましょう｡ そして､ アルパインのイメージは､ ちょうどpingを使って8を打つようにします｡
‫8. 8. 8は､
‫実際にはGoogleのDNSサーバーですが､ 何が起こるかを調査する間､ 本当に何かを与えたいだけなのです｡
‫すると､ docker runと同じように､ IDが吐き出されますが､ それはコンテナIDではありません｡ 実はこれ､ サービスIDなんです｡
‫現在､ 1つのサービスがリストアップされていることがわかります｡ docker runコマンドと同じように､ 名前を付けなかったので､
‫ランダムな名前が付けられました｡ 実はすでにスピンアップしていることがわかります｡
‫1の1｡ サービスを見ていると､ 必ずこの真ん中に「/」がついた数字が目に入ります｡
‫それは､ 左側のものが実際に走っている数であることを表しています｡
‫そして右側は､ 実行するためにあなたが指定した数です｡
‫オーケストレーターの目標は､ 何が何でもこの数字を一致させることだ｡
‫しかし､ これでも実は､ 本当の容器を示しているわけではないのです｡
‫これはサービスのリストを表示しているだけなので､ もう少し掘り下げてみることができます｡
‫docker service psを実行して､ サービスの名前かIDを与えると､ 実際にこのサービスのタスクやコンテナが表示されます｡
‫これはdocker
‫containerのlsコマンドに似ていますが､ 実はnodeというコンポーネントがあります｡ 複数のサーバーを扱うシナリオでは､ どのサーバーで実際に動作しているのかを知る必要があるからです｡
‫実際にサービス名をインクリメントした名前をつけていることに気がつくだろう｡
‫ドッカーコンテナのlsコマンドに戻っても､ それはそれで有効です｡
‫この場合､ Swarmのオーケストレーションは､ 実際に名前と､ 実際に動いているイメージに何らかの情報を付加していることになります｡
‫その微妙な違いについても､ 後ほどご紹介します｡
‫とりあえず､ そのサービスを実際に使ってみて､ スケールアップしてみましょう｡ そのために､ docker service updateを使い､
‫サービス名､ この場合はIDをやります｡ そして､ サービスに関する属性を変更したいのです｡
‫今回は､ レプリカの数を変更したいのです｡
‫そこで､ もう一度docker service lsを行うと､ 今度は3人分の3が表示されます｡ docker service psを実行すると､ 実際には3つのタスクが表示されます｡
‫2つは数秒前に作成されたばかりであることに気づくだろう｡
‫十分に速く､ 十分に大きなものをデプロイしていれば､ 実際にlsというサービスを実行して､ 3つのうちの0を表示させることができます｡
‫3つのうちの1つ｡
‫実際に起動すると増えますよ｡ たまたまこのマシンには､ イメージ的にアルパインがすでに入っていて､
‫pingコマンドを立ち上げるのにそれほど時間がかからなかった｡
‫ただ､ あそこまで速くすることはできなかった｡
‫このupdateコマンドで興味深いのは､ 単一の開発サーバーやテストサーバー､ あるいはローカルマシンで使うようなDocker
‫runコマンドと､ 常に可能な限り何かを利用可能にしておくというプロダクションでの懸念の違いを想像できることです｡
‫それがSwarmのデザインゴールのひとつです｡ そのコマンドの中で､ 実はまだ使っていないのが､
‫Docker updateコマンドです｡ これはDockerの実行コンテナ用のコマンドで､ 実行中のコンテナを強制終了して再起動することなく､
‫特定の変数を更新することができるのです｡
‫これらのオプションのほぼすべてが､ そのコンテナのリソース使用量の制限と制御に関連している｡
‫というのも､ 長期間のアプリケーションを運用していると､ データベースが大きくなってRAMが必要になったりして､
‫リソースを変更する必要が生じることがよくあるからです｡
‫あるいは､ 制御不能なプロセスがあり､ CPUを大量に消費しているため､ それを制限する必要があるのかもしれません｡
‫docker service updateコマンドのヘルプを見ると､ もっとたくさんのオプションがあることがわかります｡
‫というのも､ Swarmサービスの目標は､ 全体をダウンさせることなくコンテナを交換し､ サービスの変更を更新できることだからです｡
‫3つのコンテナがあるサービスがあったとして､ 技術的には一度に1つずつダウンして変更を加え､ ローリングアップデートのようなことをすることができます｡
‫このようにオプションがたくさんあるのは､
‫コンテナの再起動が必要なオプションを変更しても､ Swarmがインテリジェントに､
‫一貫した可用性を確保するパターンで更新するようにするからです｡
‫それでは､ ドッカーコンテナのリストに戻りましょう｡ この3つがあることにお気づきでしょう｡ もし私がこの中に入って､
‫ある意味不正に､ docker container rmを実行し､ これらのコンテナの1つを指定して､ 強制的に...したらどうでしょう｡
‫を倒したとして､ それをそのまま持ち出す｡
‫わかりました｡
‫ここでdocker service lsを実行すると､ 3つのうち2つが表示されるのがわかりますか？
‫Swarmの背後から侵入して､ 実際に稼働中のコンテナを取り上げてしまったので､ それを識別して､
‫ダウンしたコンテナの代わりに数秒以内に新しいコンテナを立ち上げることになるのです｡
‫frostyのdocker service psを実行すると､ このリストの最初のタスクの履歴が表示され､ 1つは失敗し､
‫24秒前に新しいタスクが開始されたことがわかります｡
‫これは､ コンテナ・オーケストレーション・システムの責任の1つは､ 指定したサービスが常に稼働していることを確認し､ そのサービスに障害が発生した場合は､
‫その障害から回復させることです｡
‫docker runとは全然違いますよね？ docker
‫run は決してコンテナを再作成しない｡
‫そのため､ Dockerサービスのコマンドを実行するときは､ コンテナの作成などのアクションを直接指示しているわけではありません｡
‫オーケストレーションシステムに対して､ 「このジョブをキューに入れろ」と指示しているのです｡
‫行けるようになったら､ ここでお願いした群に対するアクションを実行してください｡ それは大きな違いです｡
‫コマンドラインでは微妙ですが､ ロールバックの可能性があることを意味するので､ 大きな違いです｡
‫そこには､ 故障の軽減や多くのインテリジェンスが組み込まれています｡
‫この場合､ 実際にこれらのコンテナをすべて削除しようと思ったら､
‫サービスを削除しなければならない｡ docker service rmをする必要がありますね｡
‫そして､ フロスティ｡
‫docker service lsを実行しても何も表示されません｡ docker container lsを実行すると､
‫3つのコンテナが表示されます｡
‫ああ､ そうきたか｡
‫これは､ バックエンドで行われている自動化を示しています｡
‫サービスを削除したことはすぐに示せたのですが､ オーケストレーションシステムがサービスとその背後にあるタスクをクリーンアップするプロセスをすべて行っていなかったのです｡
‫これらの概念は､
‫このコースの前半で学習したDocker Runの概念を拡張したものなので､ かなり簡単に理解できるはずです｡
‫次に､ 実際にマルチノードスウォームを構築して､ コンテナのスケーリングを始めてみましょう｡