‫コンテナの大きな特徴の1つは､ Herokuなどのプラットフォーム・サービスのように､ 簡単にアプリをデプロイできることです｡
‫私たちのハードウェアでも､
‫クラウドプロバイダーでも､ 仮想でも物理でも､ 誰のハードウェアでもできるのです｡ Dockerを使えば､ Amazon､ Azure､ DigitalOcean､ Linode､
‫Rackspace､ Google Cloudなど､ どんな場所でも同じようにアプリを動かすことができます｡ このようなプラットフォーム機能がなければ､ 多数のサーバーやインスタンスにまたがる何十､
‫何百､ あるいは何千ものコンテナを､ どのようにして簡単にデプロイし､ 維持すればいいのでしょうか｡
‫ノードでもドロップレットでも何でもいいんです｡
‫その結果､ これまで小規模な組織では問題にならなかったような､ 実に新しい問題が発生するようになったのです｡
‫Netflixやそのような大企業は､ 何千､ 何万というノードにスケールアップし､ 多くのエンジニアを抱えていることは周知のとおりです｡
‫しかし､ チーム内に数人しかいない場合､ あるいは単独の開発者である場合､ どのようにしてコンテナを手に入れ､ それを拡張し､
‫そのライフサイクル全体に対処すればいいのでしょうか｡ デプロイから､ 起動､ 再起動､
‫再作成､ 削除､ アップデートまで､ すべてです｡
‫Dockerは一体どのようにそれを行うのか､ あるいは全く行わないのか､ といった疑問が湧いてきます｡
‫私たちが自問自答するのは､ どのようにスケールアウトするか､ といったことです｡ どのようにスケールアップするか？ コンテナに障害が発生した場合､
‫どのように再起動させるか？
‫実際にアップデートがあったときに､ そのコンテナをどのように入れ替えるのか｡ 最近ではブルーグリーンデプロイと呼ばれる､ ダウンタイムがゼロで､
‫新しいサーバーを導入するためにプールからサーバーを取り出すというものです｡
‫結局､
‫常に何か使える状態にしておくことで､ アップデートしても落ち込むことはないのです｡ コンテナを起動したノードが何十台もあるのか､ あるいはたった3台なのか､
‫どうやって知ることができるのでしょうか｡ コンテナはどのノードにあるのか？ コンテナ内のネットワークを使って､
‫異なるノードやサーバー間でどのように話をするのか｡
‫セキュリティに関して言えば､ コンテナが意図したマシン上でのみ動作していることを､ どのように確認すればよいのでしょうか｡
‫コンテナをその場でダイナミックに動かし､ デプロイするようになった今､ 秘密やパスワードなど､
‫コンテナに必要なプライベートな情報をどのように保存すればよいのでしょうか｡
‫そこで､ Dockerが解決しようとする範囲に大きな進化がもたらされます｡
‫Dockerは単なるコンテナランタイムだと思っている人がいますが､
‫これは2016年の新機能で､ コンテナのニーズと実運用での運用方法を長年にわたって理解してきたことを結集したものです｡
‫つまり､ Swarmの核心は､ 異なるOSやホスト､ ノードなどを､ 管理可能な単一のユニットにまとめ､ コンテナのライフサイクルをオーケストレーションできるようにするサーバ・クラスティング・ソリューションなのです｡
‫念のため言っておきますが､
‫実はSwarmの話ではなく､ 1以前のDockerのアドオンコンポーネントであったSwarm Classicと呼ぶことにしています｡ 12が出てきた｡ Dockerの中で動作するコンテナで､
‫Dockerの実行コマンドを複数のサーバーに繰り返し送信するだけです｡
‫いくつかの問題は解決できましたが､ コンテナの運用方法の80％を本当に解決するのに必要な規模ではありませんでした｡
‫2016年の夏､ dockercon
‫2016で､ 実はDockerはSwarm Kitを発表しました｡ これは､ Swarmの新機能を中心にしたライブラリやツールキットの集合体でした｡
‫そして､ それをそのままDockerサーバーに貼り付けたのです｡ このコースではずっと､ CLIとサーバーで実際に機能を利用できるようにしてきました｡
‫今､ 私たちはようやくその中に飛び込むことができるようになりました｡
‫2017年1月､ 1． 13が出たのはもちろんですが､ 2016年にスウォームモードが新しくなったので､
‫これから先もどんどん良くしていくんでしょうね｡
‫1月には､ 「スタック」「シークレット」と呼ばれる追加機能や､ 後述するボーナスも追加されました｡
‫ここで重要なのは､ 実はSwarmは箱から出しても有効にならないことです｡
‫実際､ あなたのマシンでは､ ここに挙げたコマンドは今すぐには使えません｡ Swarmが有効になっている必要があるため､
‫実際にはエラーになります｡
‫Swarmのコードが既存のDockerデーモンに影響を与えないことが設計目標の1つでした｡
‫すでにDockerに依存しているツールやシステム､ あるいはDockerの上に独自のオーケストレーションを持っていたとしても､
‫SwarmがDockerの一部となることで干渉されず､ 機能を継続させることができます｡
‫まず､
‫基本的なコンセプトですが､ 上にある青い箱はマネージャーノードと呼ばれるもので､ Raftデータベースと呼ばれるデータベースをローカルに保持しています｡
‫その設定を保存し､ スウォーム内の権威となるために必要なすべての情報を提供します｡
‫つまり､ ここにあるのは､ スウォームに追加された3種類のマネージャーで､
‫全員がデータベースのコピーを保持し､ トラフィックを暗号化して､ 完全性を確保し､ このスウォームを安全に管理できるという信頼を保証しているのです｡
‫グリーンの下には､ 実はワーカーノートがあるんです｡ さて､ Swarmのコンセプトは､ マネージャーとワーカーがいることです｡
‫これらはそれぞれ､ LinuxやWindowsサーバーのディストリビューションを実行している仮想マシン､ または物理的なホストとなる｡
‫これは､ 「コントロールプレーン」と呼ばれる部分で､ 群れの中でどのように命令を出し､ 行動を起こしているかということを､
‫実際に通信している様子を示しています｡ もう少し複雑な見方をすると､ 先ほど説明したRaftのコンセンサスデータベースは､
‫全ノード間で複製されています｡
‫作業員にまで指示を出す｡
‫また､ 経営者自身が労働者になることもあります｡ もちろん､ 作業者と管理者の2つの役割に降格・昇格させることも可能です｡
‫マネージャーというと､ 一般的にはスワームを制御する権限を持ったワーカーを思い浮かべると思います｡
‫繰り返しになりますが､ これらのサーバーの要件は､ 今使っているものと同じDockerが動作していることだけです｡
‫このスウォームという概念と､
‫このマネージャーによって､ 私たちのコンテナはどのようなものかという新しい概念を持つことができました｡
‫そのため､ Dockerのrunコマンドでは､ 実際には1つのコンテナしかデプロイできなかったのです｡
‫コンテナを作るだけになってしまう｡
‫Docker CLIが接続しているどのマシン上にも､ 常にありました｡
‫それは通常､ あなたのローカルマシンか､ あるいは彼らがログインしているサーバーです｡ そのDockerの実行コマンドには､ スケールアウトやスケールアップの方法に関するコンセプトがありませんでした｡
‫そのため､ それに対応する新しいコマンドが必要だったのです｡
‫そこで登場するのがDockerのサービスコマンドです｡ swarmでは､ Dockerのrunコマンドの代わりに､
‫コンテナを実行する際に､ レプリカを何個走らせるかといった追加機能を追加することができるのです｡
‫それらをタスクと呼びます｡
‫1つのサービスに複数のタスクを持たせることができ､ そのタスクごとにコンテナを起動する｡
‫この例では､ これまで何度か行ってきたように､ Nginx イメージを使用して Nginx サービスをスピンアップするために､ docker service
‫create を使用してサービスを作成しました｡
‫でも､ 「レプリカが3台欲しい」と伝えてあるんです｡
‫そこで､ 群れのどこにそれらを配置するかを決めるために､ マネージャノードを使うことになる｡ デフォルトでは､ それらを広げようとします｡
‫各ノードには､ 必要だと伝えた3つのレプリカまで､ Nginxコンテナのコピーが作成されます｡
‫これは､ マネージャーがどのように働き､ バックグラウンドで何をしているのか､ 簡単かつ基本的に理解するためのものです｡
‫これらの機能はすべて新機能です｡
‫Dockerのrunコマンドで経験するような､ 単純にコマンドを受け取ってAPI上で実行するのではありません｡
‫スケジューラやディスパッチャ､ アロケータ､ オーケストレータなど､ ワーカーがその時々で実行すべきことを決定するためのバックグラウンド・サービスが多数用意されています｡
‫だから､ 労働者は常に上司に報告し､ 新しい仕事を求めている｡
‫マネージャーは常に新しい仕事を与え､ 指示したことと実際にやっていることを照らし合わせて評価します｡
‫例えば､ そのサービスでさらに3つのレプリケート・タスクをスピンアップするように指示した場合などです｡
‫だから､ オーケストレーターはそれを理解した上で､ ワーカーに指示を出したりするわけです｡
‫このSwarmモードでは､ 既存のDockerのスキルを活かしてコンテナをインターネットに確実にデプロイし､
‫本番運用時に発生するさまざまな問題を解決するための機能が､ そのまま使えるようになっています｡