‫前回のビデオでは､ ImperativeとImperativeの違いを説明しました｡
‫宣言的である｡ Kubernetesでは､ どちらか一方の仕様について話をしました｡
‫Kubernetessのドキュメントを見ると､ 3つの異なるスタイルに分かれています｡
‫微妙な違いはありますが､ 片方は命令型､ もう片方は宣言型というように､
‫本当にスペクトラムがあります｡
‫そして､ 真ん中にあるこの素敵な小さなオプションは､ お好みで使ってください｡
‫この講座では､
‫これまで､ 厳密で命令的なCLIコマンドをお教えしてきました｡
‫その中には､ ラン､ エクスポーズも含まれます｡
‫スケール感があるのかもしれませんね｡
‫編集は対象外ですが､ 思ったとおりのことができるんです｡
‫リアルタイムにリソースを編集することができます｡
‫あるいはデプロイメントを作成する､ これが新しいランの方法です｡
‫仕組みを知るには最適です｡
‫リソースの種類とその役割を学び､
‫個人的なプロジェクトや､ 自分だけが担当するような本当に小さなセットアップを行います｡
‫自動化を目指しているわけではないんですね｡
‫フルプロダクションのワークフローを構築しようとしているわけではなく､
‫CICD､ ですね｡
‫それはそれで素晴らしいことです｡
‫Kubernetesが提供するcreateコマンドは､
‫createコマンドそのものを使うこともできますが､ YAMLファイルと一緒に使うこともできるという､ いいとこ取りのコマンドです｡
‫create -f を使って､ 先ほど見たような仕様の一つを与えることができます｡
‫スペックを与えれば､ そこにあるオブジェクトのどれでも作ってくれる｡
‫そのファイルには､
‫複数のオブジェクトが含まれている可能性があります｡ デプロイメントに加え､ サービスも入っているかもしれませんね｡
‫ストレージの必要性､ ネットワークのセットアップなど､ さまざまなニーズがあるでしょう｡
‫そのすべてを1つの素敵なファイルとして持つことができるのです｡
‫そして､ その中の何かを置き換える必要があれば､ そのファイルを編集して､
‫まだ説明していないreplaceコマンドを使えばいいのですが､
‫これは思ったとおりに動いてくれます｡
‫それから､
‫私たちが使っているdeleteコマンドも､ あなたが考えているようなことをやってくれます｡
‫ここがいいのは､ 中間的なところですね｡
‫YAMLを使うことで､ 何をしているのかを文書化し､ gitなどを使っている場合はこの変更記録を残すことを強制します｡
‫git を使っているといいのですが｡
‫そこのメリットは､ 私たち人間にとっては､ 作成とか置換とか削除とかを使っているわけですが｡
‫つまり､
‫createコマンドを使用する際に誤って何かを削除してしまわないように､
‫この動詞を明示的に使用するのです｡
‫また､ replaceコマンドを使うと､ 誤って何かを削除することがないことがわかります｡
‫それは助かるわけですね｡
‫これは､ 完全な宣言型オブジェクトモデルに到達したときに必要となるYAML仕様に足を踏み入れるための､
‫良い中間地点と言えるでしょう｡
‫それが､ 先ほどの話です｡
‫そこで､ YAMLだけを使って､ applyコマンドだけを使っているのです｡
‫他にもdiffなど､ applyを助けるコマンドがあり､
‫これから行う変更を表示してくれます｡
‫しかし､ applyは単にYAMLを編集し､ applyを実行するだけです｡
‫さらにYAMLを編集して､ applyを実行します｡
‫これは､ Swarmに似ていて､ Swarmスタックがあったんです｡
‫思い起こせば､ docker stackのdeployコマンドがあって､
‫それらを更新するためには､ 何度も何度も同じコマンドを使うわけです｡
‫それは､ ここでも宣言型オブジェクトを全面に押し出したスタイルと同じです｡
‫ドキュメントがあるのはありがたいことで､
‫この講義のリソースリンクにもありますが､ この3種類のタイプについて非常に詳しいページがあります｡
‫ぜひ､ チェックしてみてください｡
‫このことについて資料ページを読みに行っても､
‫私が与える本当のルールは､ ただ3つのアプローチを混ぜないことです｡
‫この3つを混在させないことが､ 本当の意味でのプロダクション依存の場合､
‫より重要です｡
‫本番環境では､ できるだけ早い段階で､
‫YAMLファイルとapplyコマンドを使用した完全な宣言型モデルにこだわることをお勧めします｡
‫早くそれに慣れて､ それをYAMLで文書化し､
‫変更するたびにgit-commitで保存するようになれば､
‫そのプロセスは後々本当に役に立ちます｡
‫あなたが行った変更を見たい人は､ git-logを見に行けばいいのです｡
‫私たちの多くは今日もgitで何かをしているでしょうから､
‫このYAMLを保存するためだけに別のgitレポを作成することは､ あなたにとって大した労力にはならないでしょう？
‫自分のマシンで
‫git をローカルに実行している場合でも､ git
‫を使えば YAML に加えた変更の履歴を確認することができ､
‫3 ヶ月前に変更した内容を 6 ヶ月後に忘れてしまった場合でも､
‫過去に遡ってその内容を確認することができます｡
‫これは本当に時間の節約になりますよ｡
‫最も重要なルールは､ アプローチを混ぜないことです｡
‫runで何かを作ると､ そのリソースを管理するためにapplyを使うのが後で大変になるんです｡
‫これらのコマンドにはちょっとしたコツがあり､ 後でオブジェクトを編集するときに､
‫台無しにすることなく編集することができます｡
‫でも､ 本当に本番運用をするのであれば､ 本番サーバーでこれらの実行コマンドを使うのはやめた方がいいでしょうね｡
‫長期的に考えて､
‫YAMLにこだわるべきでしょう｡ 私の4つのコツは､ あなたがやっているように､
‫コマンドラインを学ぶことです｡
‫その不完全なコマンドラインを覚えて､ ローカルで操作できるようにする｡
‫また､
‫トラブルシューティングやテスト､ サーバーなどでも､ これらのコマンドが必要になることがあります｡
‫それから､ 最初の本番用Kubernetesの準備として､
‫applyコマンド､ diffコマンド､ 使用するすべてのリソースタイプのYAML仕様をできるだけ早く習得することです｡
‫そして､ 私が言っているようにgitに格納すること｡
‫たとえそれが､ ローカルのgitや､ チームが使えるどこかのgitレポであっても｡
‫YAMLを編集し､ gitに変更を保存し､
‫kubectl applyで適用し､ 再度保存し､
‫gitに変更を保存するこの方法を覚えておいてください｡
‫このプロセスによって､ DevOpsの自動化､ そして先ほど述べたgit-opsへの道が開かれるでしょうし､
‫これらのツールのいくつかはその方向に進み始めていると思います｡
‫git中心でやっているところ｡
‫私たちは､ ソフトウェアのコーダーが行うように､ git リポジトリで変更を行っています｡
‫このDevOpsのワークフローと同じことをやっているのです｡
‫彼らがチームで行う変更作業の方法を､ 私たち自身のオペレーションやツールに取り入れているようなものです｡