‫ドライランとデフについて､ 新しいことを教えてあげよう｡
‫Kubernetesの1.0からはじまる過去数バージョンでは､ Kubernetesを使用することはできません｡ 13は､ 変更する前に変更内容を確認できる､
‫この新しいオプションがあります｡
‫以前にも見たことがあります｡
‫コースの前半で､ いくつかの例を紹介しました｡
‫でも､ このapplyコマンドで使う方法は､
‫新しくて良いですね｡
‫過去にあったのは､
‫ドライランはありましたが､ それはクライアントだけでした｡
‫クライアントがサーバーに「このリソースはすでにあるのか」と問い合わせることはない｡
‫作り直さないといけないのか､ アップデートされるのか､ どうなっているのか｡
‫そうですね｡
‫以前はそんなことはなかったんですけどね｡
‫サーバドライランというオプションがあり､ YAMLをサーバに送信して比較し､
‫実際に何が必要かを判断して､ 何が変更されるかをコマンドラインに報告することができます｡
‫それを実際に見てみましょう｡
‫私は以前講義で説明したようにK8sのYAMLディレクトリにいますが､
‫もしDocker Masteryのレポでこのディレクトリがない場合は､
‫git-pullして最新のアップデートを取得する必要があります｡
‫これは､ 以前の講義で見たファイル､
‫app. ymlを使用します｡ これは､ サービスとデプロイメントを1つのファイルにまとめたものです｡
‫技術的には1つのapplyコマンドで2つのリソースが作成され､
‫それらが関連しているのです｡
‫このサービスでは､ まだ話していないセレクタを使用しています｡
‫セレクタは､
‫あるオブジェクトが対話したり､ 何かをしたりしたいリソースを見つける方法です｡
‫サービスはポッドと会話する必要があるので､ ポッドにアクセスする方法を見つける必要があります｡
‫セレクタを本質的なパターンマッチングとして使用し､
‫そこにあるキーと値のラベルをマッチングさせる｡
‫ここで従来のドライランを行うと､
‫クライアントがアプリケーションを見て､ ああ､ こういうオブジェクトを作るんだと言うだけになってしまう｡
‫わかりました｡ 必ずと言っていいほど､ 作成されたものが戻ってきます｡
‫それは､ アプリがあまり具体的でないからです｡
‫更新､
‫作成､ 削除のコマンドを使用していた場合､ これはとてもDevOpsベースのワークフローとは思えませんね｡
‫これらのコマンドは試運転をするだけで､ アップデートのほうは「ああ､ 両方ともアップデートされるんだな」とわかるはずです｡
‫でも､
‫クラスタではよくわからないんですよね｡ それを把握するために､ サーバーと会話していないのです｡
‫何でも1ではデフォルトで有効になっているサーバーのドライランを試してみたいのです｡
‫13歳以上
‫そうすると､ サーバーと会話して､ 適切なレスポンスを返してくれるんです｡
‫さっそく作ってみましょう｡
‫サーバーの乾電池をはずすと
‫これにより､ デプロイメントとサービスという2つのリソースが作成されます｡
‫ここで､ 上矢印を押してサーバーのドライランに戻ると､ 両方とも未変更と表示されているのがわかると思います｡
‫何が変わったのか､ 何か変わるものがあったとしてもそれが何なのかは教えてくれません｡
‫リソースが変更されるか､
‫変更されないかを教えてくれているだけなのです｡ イエスかノーかのトグルのようなものです｡
‫サーバーに与えたいものと､ リソースの現状との実際の差分を取得するのはどうでしょう｡
‫それが､ kubectlのdiffコマンドです｡
‫applyの代わりにdiffを与えるだけで､ 私の持っているYAMLと現在稼働中のサーバーにあるspecを比較することができます｡
‫というステータスが返ってきて､
‫その上で差分を取ることになります｡ そうしよう｡
‫違いがないので､ 何も言わないでしょう｡
‫しかし､ YAMLを変更しに行く場合はどうでしょうか？
‫レプリカを2つに変更した場合はどうなりますか？
‫そして､ メタデータにラベルを追加して､ 次のようなものをつけます｡
‫のようなものです｡
‫サーバーdmz.
‫私が作ったものです｡ どうでもいいことですが｡
‫そして､ 2つのレプリカを用意しました｡
‫それと同じように差分を取ると､ プラスとマイナスで返ってきます｡
‫diffを読み慣れた方なら､ これで納得していただけると思います｡
‫diffに慣れていないと､
‫マイナスはその線が消えてしまうことを意味します｡
‫そうすると､ こんなセリフが追加されます｡
‫そして､ この下に､ どの行のどの文字が削除されるのかが表示されます｡
‫追加されることになりました｡
‫YAMLの書式が維持されているのはいいことだ｡
‫複数の変化が起きていることを知らせてくれているのです｡
‫素晴らしい｡ もちろん､ これは本当にカナリアみたいなことをやっているわけでも､
‫テストデプロイメントをしているわけでもなんでもありません｡
‫やってみて､ その結果がどうなるかということではないのです｡
‫本当に､
‫記録されている仕様と､ 私たちのディスクにある仕様を見るだけなんです｡
‫詳しくは､
‫資料のリンク先で確認してください｡
‫Kubernetesチームのブログ記事で､ これらがベータ版として出てきて､
‫今後どのように展開していくかについて書かれています｡
‫今現在のこれらの機能は､
‫少なくとも1ではベータ版であることを忘れないでください｡ 15である｡
‫これで､ ゼロからYAMLを作成し､ そのYAMLで仕様を管理し､
‫applyコマンドを何度も使って変更を加えるという自分なりのワークフローを作ることができるようになれば幸いです｡
‫これは､ よりDevOpsに近いインフラストラクチャー・アズ・コードのようなやり方です｡
‫あなたがすることはすべて文書化され､ できればGitで｡
‫つまり､ サーバーにデプロイする前に YAML を変更するたびに
‫git-commit していればよいわけです｡
‫そして､ Gitの素敵なドキュメントがあります｡ また､ diffのようなものを使って､
‫今あるものと実際に動いているものとを確認するときのドキュメントもあります｡