‫KubernetesやSwarm｡
‫これは､ オーケストレーションについて十分に学んだ人が､
‫どれを使うべきか決断する際に受ける最も多い質問の1つです｡
‫まずはSwarmの動画､ 特にその一番最初の動画をご覧になることをお勧めします｡
‫それがSwarm
‫Mode Built-in Orchestrationです｡ なぜオーケストレーションがある問題を解決するのに必要なのか､ その背景をもう一度説明します｡
‫そして､
‫このセクションで以前に紹介したKubernetesに関する動画も見て､ 両ツールの背景を理解してから続きをご覧ください｡
‫ここでのベースラインとして､
‫これらはどちらも似たような問題を解決するツールである｡ どちらもコンテナランタイムの上で動作するコンテナオーケストレーターです｡
‫このビデオシリーズでは､ Dockerコンテナランタイムについて学習しました｡
‫今は他にもcontainerdやCRI-Oがありますね｡
‫本当に､ DockerはNo.1ですね｡
‫ほぼすべてのケースで使われています｡
‫どちらも､ ベンダーと製品に携わるチームによって支えられています｡
‫一般的に､ 両者を比較するツイートをするとすれば､
‫単純にSwarmは作り込みが簡単で､ ノードを追加しやすく､ 始めやすく､
‫管理しやすいということでしょう｡
‫だから､
‫Swarmの魅力は「簡単」という一言に尽きますね｡
‫しかし､ Kubernetesがより多くの機能性､ 柔軟性､ カスタマイズ性を持っているすべてのユースケースを解決できるわけではありません｡
‫より多くの問題を､
‫より多くの方法で解決することができ､ また一般的に広く採用され､ 支持されています｡
‫そんなあなたのために､ どれを使うか決めるために､
‫それぞれのメリットを箇条書きで紹介します｡
‫DevOpsコミュニティに参加し､
‫これらのツールを使ってビジネス上の問題を解決しようとするならば､ 私たち全員にとって､
‫この2つを知っておくことが重要だと思います｡
‫両方をインストールし､ 両方にアプリをデプロイし､ アプリのデプロイ､
‫流入するトラフィックに対するIngressオプションの作成､
‫およびそれらのアプリの更新に関する基本機能のいくつかを知ることができるはずです｡
‫それだけでも､
‫どのツールを使えばどの問題が解決できるのかがわかるくらいにはなれると思うんです｡
‫それぞれに多くの利点があります｡
‫早速､ 分解してみましょう｡ Swarm側では､ このコースで学んできたように､
‫Dockerが付属しています｡
‫つまり､ ベンダーがサポートする単一のソリューションなのです｡
‫つまり､ コンテナランタイムとオーケストレーターが同じ会社で作られているということです｡
‫その結果､ 複雑さが軽減され､ 実行するためのリソース使用量も少なくなるなど､
‫多くの報酬を得ることができました｡
‫Swarmを実行すると､
‫Dockerの上でほとんどリソースを使用しません｡
‫開発者のワークフローを考えて設計されています｡
‫ですから､
‫Opsやデベロッパーが使うにはとても良いですね｡ 先ほども言いましたが､ このタイプのオーケストレーターは導入も管理も簡単です｡
‫数千台とは言わないまでも､ 何百台ものノードに簡単に成長させることができ､
‫それを管理するために必ずしも大規模なチームを必要としないでしょう｡
‫Kubernetesの20%の機能を持ち､
‫それがコンテナやオーケストレーションの実行に関する80%のユースケースを解決するという､ 80/20の法則に従っていると言えるかもしれません｡
‫今のは､ 科学的な比較ではありません｡
‫正確な機能数値はよくわからないのですが｡ 本当にどうしたらいいのかさえ分からない｡
‫しかし､ それは､ Swarmがクラウドやデータセンター､ あるいは小型デバイスなど､
‫サーバー上でWebアプリを長時間稼働させるソリューションのユースケースの大半を解決してくれることを実感している両者を実行したときの感触のようです｡
‫箱から出しても問題なく使えるようです｡
‫必要なものを備えている｡ ネットワークも備えている｡
‫イングレスを搭載しています｡ 暗号を搭載しています｡
‫そんなものばかり｡ データベースを搭載しています｡
‫だから､ すぐにでも多くの問題を解決することができるのです｡
‫しかし､ マシン上でアプリを実行するために､ すべてのユースケース､ すべてのシナリオを解決できるわけではありません｡
‫そこで､ Kubernetesがそのギャップを埋めることができるのです｡
‫また､ Dockerが動作する場所であればどこでも動作することも大きなメリットです｡
‫Docker
‫Engineは､ 6年前にコンテナ革命を起こしたもので､ 他のどのツールよりも多くの場所で稼働しています｡
‫Linuxだけでなく､ Windowsでも動きます｡
‫Mainframe上で動作します｡
‫ARMデバイス､ つまりEmbedded､ IoT､
‫Raspberry Pisで動作する｡
‫古いARM､ 新しいARM､ 32ビット､ 64ビットで動作します｡
‫先ほども言いましたが､ とにかく盛りだくさんなんです｡
‫Server 2016からもう何年もWindows Server上でネイティブに動作しています｡
‫そのため､ 多様なマルチアーキテクチャ環境に対応するオーケストレーターとしては､
‫間違いなく最も長く支持されています｡
‫Swarmを作成してノードを追加する際に､
‫Telusの相互認証が確保されるようになっています｡
‫コントロールプレーンを暗号化し､
‫データベースを暗号化することで､ 万が一､ 機密情報を保存したい場合にも保護することができます｡
‫納期に追われていたり､ 複雑さに圧倒されていたりすると､ Kubernetesのような他のツールが要求するセキュリティ要件を忘れてしまったり､
‫飛ばしてしまったりするチームが少なくないからです｡
‫最後に､
‫可動部が少ないので､ トラブルシューティングがしやすいと思います｡
‫管理するものが少なくなった｡
‫Dockerにデフォルトで組み込まれているので､ Dockerのトラブルシューティングの方法を知っていれば､
‫おそらくSwarmのトラブルシューティングの方法も知っているはずです｡
‫同じデーモンのログを使用します｡ アプリと同じDocker logsコマンドを使用します｡
‫ノードやSwarm自体のイベントを見るには､
‫同じDocker eventsコマンドを使用します｡
‫今､
‫Swarmの利点はたくさんあるように聞こえますが､ それが常に自分にとって正しいことだとは思わないでほしいのです｡
‫一般的に､ Swarmはこれから始める人､ 小さく始める人にお勧めのツールです｡
‫一人で､ あるいはチームの中で1人､ 2人､ 3人で､ 小規模でシンプルなオーケストレーターが自分たちに合うかどうかを確認する必要があるかもしれません｡
‫Kubernetesを絶対に使わなければいけないということでなければ､
‫私はいつも最初にSwarmをお勧めしています｡
‫Swarmで限界に達し､
‫必要なものが得られないと思ったら､ その時がKubernetesを検討する時です｡
‫では､ そのメリットのいくつかをお話ししましょう｡
‫まず､ クラウドやベンダーがKubernetesのサポートにとても好意的であること｡
‫Kubernetesは非常に人気があり､
‫特にニュースやメディアで時代がかった人気があるため､ 今ではどのベンダーもKubernetesをサポートしているというリストにチェックを入れようとしています｡
‫だから､ クラウドやベンダーのサポートが最も充実していると言えるでしょう｡
‫どのクラウドベンダーもKubernetesを提供しているので､
‫自分で運用したくない場合は､ クラウドベンダーにすべてのシステムを立ち上げてもらい､ Kubernetesのデプロイメントファイルを使って､
‫そこでアプリを実行するだけでよいのです｡
‫VMwareやRed
‫Hatなど､ インフラベンダーも独自のKubernetesディストリビューションを持っています｡
‫Netflixのように､
‫従来は単なるストレージベンダーであった企業でさえ､ Kubernetesの独自の承認版､
‫つまりディストリビューションを持っているのです｡
‫ですから､ ここでは､ 最も広く採用され､ 支持されているというのが当然のことのように思えますが､
‫それは間違いなく事実なのです｡
‫しかし､ それ以上に､ サポートされるユースケースの幅が最も広いことも特徴です｡
‫Swarmの方が､
‫より多くのトグルスイッチやサードパーティオプションがあり､ より多くのエッジケースをカバーしています｡
‫つまり､
‫ベンダーはDockerのSwarm製品をわざわざ見に行く前に､
‫自社の製品でKubernetesをどのようにサポートできるかを確認するようになる､ ということです｡
‫特に､ この業界ではあらゆるものがKubernetesをサポートする必要があるという姿勢なので､ すでに持っているベンダーが､ 自社のツールをKubernetes上で実行するためのディストリビューションやソリューションをすでに持っている可能性があるからです｡
‫例えば､
‫CloudBees社のJenkinsを使った場合｡
‫Enterpriseソリューションを購入すると､ Kubernetesのツールや実行方法のサンプルが提供されます｡
‫Swarm上でJenkinsを動かせないということではありません｡
‫そこそこよく走ります｡
‫ただ､ その分ベンダーからのサポートが充実するということです｡
‫ここで最後に挙げるのは､ ある意味､ 変なアドバンテージです｡
‫IBMを買ってクビになった人はいない､
‫という言葉を掲げてみる｡
‫この言葉は､ 数十年前､ IBMがコンピュータの最大手ベンダーで､
‫ハードウェアやメインフレーム､ PCのアウトソーシングを行い､ 市場を席巻していた頃に流行った言葉です｡
‫本来なら､ どのベンダーにするか決めかねていたら
‫無難に行くだけなら､
‫IBMと一緒でしょう｡
‫当時の信頼できるベンダーだから､ それで本当にクビになることはないだろう｡
‫Kubernetesプラットフォーム全体としては､
‫今はそうなってきていると言えるでしょう｡
‫CIOやCTOのチェック項目になっているとさえ言えるでしょう｡
‫それは､ まだ技術的な要件がないのに「Kubernetesを動かせ」と言われることになりかねないので､
‫ちょっといい意味でも悪い意味でもありますね｡
‫経営陣から「Kubernetesを走らせろ」と言われただけなんですね｡
‫それは､
‫技術的な要件や利点､ 異なるプラットフォームとの比較に関係なく､
‫ただ実行したいものなのかもしれません｡
‫これは明らかに､ ITの決定が必ずしも技術的なメリットや要件だけではなされない､
‫この政治的世界の一部です｡
‫買うときの使い勝手で決まることも多い｡
‫つまり､
‫すでに持っているベンダーがあれば､ その方が楽だから他のベンダーではなくその製品を使うだけかもしれないのです｡
‫あなたのチームのバックグラウンドの経験は､ 過去の仕事やプロジェクトからより良い経験を持っているかもしれません｡
‫つまり､ すでに知っている人がいるから､ そちらを展開するだけなんですね｡
‫あるいは､
‫残念ながら経営陣が雑誌を読んだり､ インターネットを読んだりして､ Kubernetesのような特定の製品を選ぶ必要があるとインターネットに書かれていたから､
‫それを買おうとしているのかもしれませんね｡
‫だから､ それを使えということなんです｡
‫実際､ 私がライブでワークショップを行う際､ 「なぜ今使っているオーケストレーターを選んだのですか」と尋ねると､
‫残念ながら一番多い答えは､ やはり「上司に言われたから」なのです｡
‫そのため､ 人々はいつも何を動かすかについて発言権を持つわけではありません｡
‫そこで､ 両者のツールや機能をバランスよく紹介することで､
‫あなたがチームの中で最も教養のある人物となり､ 真の技術要件を理解して最善の決断を下す手助けができるようにしようと考えています｡