‫わかりました｡ ここ数回の講義で､ Kubernetesのさまざまな領域が広がっていることがお分かりいただけたと思います｡
‫Kubernetesのバイナリと基本インフラを中心にした小さな地球を考えてみると､
‫輪がどんどん大きくなっていきますよね｡
‫Ingressと､
‫Operatorパターンと､ カスタムリソース定義で｡
‫どんどん大きくなっていくんです｡
‫さて､ 今回は､ それがさらに大きくなっていることについてお話したいと思います｡
‫実際､
‫この辺がちょっとおかしいかもしれません｡
‫それは､ このリソースのYAMLをどう展開するかというあたりの意見ですね｡
‫ここまでで､ kubectlのapplyが見えてきましたね｡
‫これで､ コンテナ・オーケストレーターの最初のデプロイは完了です｡
‫あなたは... SwarmでもKubernetesでも､
‫YAMLを取得してレポを作成し､ そこに保存することで意味を成すようになります｡
‫これを広げていくと､ チームができ､ 権限ができ､
‫さまざまな種類の権限ができ､
‫物事を管理・承認しなければならない人が出てきて､
‫すべてが複雑になっていきます｡
‫Kubernetesにアプリをどうデプロイするか､
‫この世界で何が起こったのか､ 基本的にはそういうことです｡
‫今､
‫60以上､ いや､ 本当は80くらいあるのですが､ その多くはもう現実のプロジェクトではなくなっているか､
‫死んでいるか､ アーカイブされているということをお話ししたいと思います｡
‫しかし､ Kubernetes上にアプリケーションをデプロイするためだけに､
‫Kubernetesの上にツールを追加する方法が少なくとも60種類はあります｡
‫いろいろな意見があるんですね｡
‫ここで､ 「こうしたらいいんじゃないか」という意見が出始める｡
‫Jenkins
‫XからHelmまで､ そしてそれ以上のすべてのもの｡ いろいろなものや意見がありますが､
‫Kubernetesは意見を言えるインフラではないので､
‫アプリのデプロイやアップデートのプロセスをガイドするための意見が必要なのです｡
‫だから､ みんな持っているんです｡ Kubernetesでこれをどうするかという記事を読んだことがある人なら､
‫Helmという名前を聞いたことがあるのではないでしょうか｡
‫Helm
‫to Kubernetesは､ 基本的にKubernetes to containersです｡ Helm は､ サードパーティアプリや独自のカスタム
‫Helm チャートをデプロイするためのテンプレートを作成し､
‫テンプレート標準を使用するための事実上の方法として､ 誰もが注目しています｡
‫それがチャートと呼ばれるものです｡
‫これは基本的にテンプレート化されたYAMLですが､ Helmがあなたの代わりにKubernetesクラスタに入るYAMLを作成したり吐き出したりすることができるのです｡
‫でも､ それだけが意見ではないんですよね｡
‫少なくとも前回見たときは60以上あると言ったんだ｡
‫実は参考リンクに入れたGoogleシートがあるんです｡
‫少し古いですが､
‫これらのさまざまな展開方法を見つけることができる､
‫最後の既知のリストです｡ Docker自身は､ 特にDockerのエコシステムにしっかりと入りたいと考えているのであれば､
‫非常に興味深い独自の意見を持っています｡
‫それがCompose
‫on Kubernetesです｡
‫Docker Desktopをお持ちの方は､ 今日からKubernetesを有効にすることができますので､
‫おそらくこのパートのために既に実行されていると思います｡
‫docker
‫stack deployを使って､ Swarmに送るのではなく､ Kubernetesに送ることができます｡
‫docker stackのdeployコマンドのヘルプを見ると､
‫使用するオーケストレータを指定するオプションがあるのがわかります｡
‫実際､
‫Docker Desktopの設定で､ スタックのデプロイコマンドをKubernetesを優先またはデフォルトにするよう指示することができます｡
‫Compose YAMLとKubernetes YAMLは違うと思っていたので､
‫なかなか興味深いですね｡
‫Compose on Kubernetesは､ それを実現するものです｡
‫本来はサードパーティーのツールなんですけどね｡
‫Dockerから､ ComposeのYAML､ ComposeのフォーマットをKubernetesのYAMLにデプロイ､
‫あるいは解釈､ 技術的に変換する方法について､ 意見を述べたものです｡
‫Kubernetes､ Swarm､ Docker全般のエンタープライズ・ツールとしてDocker
‫Enterpriseを検討されている方は､ ここにリンクを貼っておきますので､ ご確認ください｡
‫それなら､ ぜひこれをチェックしてみてください｡
‫この機能の良いところは､
‫ワークフローが超シンプルなままであることです｡
‫基本的に､
‫パイプライン全体でCompose YAMLを使用し､ OpsとDevで使用することができます｡
‫開発者向けにはCompose用のYAMLを､
‫本番環境やサーバー向けにはこのKubernetes用のYAMLを用意しなければならず､
‫両者に互換性がない､ などと強制されることはありません｡
‫Dockerのアイデアは､ これがあまりにも複雑だと考えたからです｡
‫簡略化しよう｡
‫コントロールパイプライン全体に対して､ 1つのYAML標準を使うことにしましょう｡
‫そして､ 気に入っています｡ 問題は､ Kubernetesができることをすべてサポートしているわけではない､
‫ということですね｡ Docker Docsには､ Composeファイルの全機能を一覧できるページが用意されています｡
‫でも､
‫KubernetesのYAMLは複雑なので､ 複数のコマンドやAPIリファレンスなどを掘り下げないといけないんですよね｡
‫だから､ はっきり言って､ 全部は無理なんです｡
‫Compose for Kubernetesのウェブサイトでは､
‫サポートするさまざまな機能についてGitHubで説明しているのが良い点です｡
‫そこは80/20の法則ですね｡
‫言い換えれば､ 80％の人がおそらく必要としている20％のKubernetesの機能をサポートしているのです｡
‫そのため､ そのワークフローが自分に合うかどうか､ すぐに始めることができます｡
‫もう一つ良いことは､
‫2018年末にそのCompose on Kubernetesをオープンソース化したので､
‫今持っているKubernetesインフラにデプロイして､ 一種のインタプリタとして動作させることができるようになったことです｡
‫DockerからComposeファイルを使ってDockerコマンドを使えば､
‫いつでもKubernetesクラスタに接続して､ それを自動的にKubernetes
‫YAMLに翻訳してくれます｡
‫実はこの時点で､
‫アプリケーションのKubernetes YAMLの多くを無視することができるのです｡
‫毎日デプロイするわけでもないインフラにKubernetesのYAMLを使うこともあるでしょう｡
‫しかし､
‫開発者がCompose YAMLを書きやすくするため､ また､ より早く本番環境に投入するために､
‫ワークフローとしてCompose on Kubernetesを選択することがあるのではないでしょうか？
‫それから､ 主要なインフラには競合する規格のようなHelmチャートを使っているかもしれません｡
‫Helmは､
‫PrometheusやELKを使ったElasticsearchのロギングなどを導入できるように､
‫たくさんのチャートテンプレートがすぐに使えるようになっているんです｡
‫テンプレートが付属しているので､ すぐに使い始めることができます｡
‫また､ これらはすべてオプションであることをお忘れなく､ ですね｡
‫これまで遊んできた標準的なYAMLでKubernetesをやってもいいし､
‫それでいいんです｡
‫これ以外のものは必要ないのです｡
‫あくまでオプションのサードパーティツールです｡
‫従来は､ チームが大きくなるにつれて､ 複数の本番用Kubernetesクラスタができ､
‫複数のチームが関わるようになると､ すべてが難しくなり､ おそらく複数のソリューションに行き着くことになるでしょう｡
‫特定のクラスタにHelmを搭載することになるかもしれません｡
‫開発者向けにCompose on Kubernetesを導入するとか､ そういうことになるかもしれませんね｡
‫あるいは､ エコシステムに含まれる60以上のツールのうちの1つです｡
‫最後のポイントは､ Helmがこの分野のリーダーであるため､ ほとんどすべてのディストリビューションがこれを使用し､
‫サポートし､ さらには最初から付属しているということです｡
‫ただ､
‫これらのツールを検討する際､ 大規模な環境ではHelmを避けて通ることはできないだろうと考えてください｡
‫使うしかないでしょう｡
‫今のいいところは､ 3にある｡ 3.0では､ よりシンプルな展開オプションが用意されているとのことです｡
‫0対1である｡ 0と2です｡
‫0. だから､ それでどんどん楽になっていくんです｡
‫これらのデプロイツールの多くは､
‫実際には､ さまざまな方法でYAMLをテンプレート化するのを助けるだけです｡
‫Kubernetes自体は､
‫長い間何もなかったんです｡
‫最近のリリースでは､ Kustomize with
‫a Kというのが出てきました｡
‫その言葉にKが付き始めたら､ それが特別な機能であることがわかる｡
‫Helmや他のデプロイメント・ソリューションと似たようなことができるのですが､
‫Helmほど強力ではありませんね｡
‫つまり､ ヘルムはまだリーダーなんだ｡
‫Kustomizeはある意味新参者ですが､ Kubernetesで行うすべてのことにアウトオブボックスで提供されます｡
‫kubectlコマンドで対応しています｡
‫テンプレート化されたYAMLの代わりに､
‫Kubernetesの標準的なYAMLを使用し､
‫そのファイルの上で別のものを実行し､ オーバーライドのようなもので変更することができます｡
‫Swarmでやっていることと似ていますね｡
‫実際にSwarmやComposeでは､ オーバーライドファイルなどが用意されています｡
‫現在では､ これをすぐに使えるようにしています｡
‫いろいろな機能がついていますね｡
‫多かれ少なかれ､ Helmが持っているような機能セットには及ばないが､
‫少なくとも箱から出してくるということだと思うのです｡
‫Dockerをお持ちの方は､ 最新のリリースである19.Dockerを覚えておいてください｡
‫Dockerの03以降では､
‫docker appサブコマンドがあり､ Compose YAMLを独自にテンプレート化し､
‫Kubernetes用にカスタマイズしたオプションと非常によく似ています｡
‫繰り返しますが､
‫もしあなたがDockerトラックに固執し､ Docker
‫Enterpriseを検討するつもりなら､ あるいはDockerが開発者のワークフローに焦点を当てているのが本当に好きなら､ docker appサブコマンドとdocker appレポを調べてみてください（リソースはここにあります）｡
‫なぜなら､ Compose YAMLの取り方､ 環境変数などの抽出方法についてドキュメントがあるからです｡
‫すべてを1つの画像にパッケージングして､
‫YAMLを画像として出荷します｡
‫つまり､ YAML をプルダウンして長いコマンドを入力するようなことをしなくても､
‫YAML をバージョン管理して一行でデプロイできるようになったのです｡
‫なかなか面白いやり方ですね｡
‫CNAB規格という新しいものを使っています｡
‫ここでは触れませんが､ これはC N
‫A Bのことです｡
‫2018年にDockerとMicrosoftが行った発表です｡
‫Dockerアプリのサイトのリソースですべて確認することができます｡
‫繰り返しますが､
‫これらの内容はすべて､ デフォルトの YAML をカスタマイズして拡張するサードパーティのオプションの方法に関するもので､
‫チームが成長するにつれて､ より簡単に使えるようになります｡