Infrastructure as Code、インフラストラクチャーアズコード。
インフラの仕事は全部コードで書いて実装するようにすれば、誰が構築しても同じものができるよねーという哲学ですね。下記の記事が良くまとまっていると思います。
確かに、誰かが構築したシステムを突然面倒見なはれと言われ、構成図ひっぺがえしても更新されていなかったり欠損していたり、二つバージョンがあってどっちが正かわからなかったり。
それより、全部コード化して構築し、改変するときはそのコードを編集して反映すればバージョン管理できる。まるでプログラミングのようにインフラを管理するという概念です。
お気持ちはわかります。
否定的だった私
とは言え。そんなん無理だろうと常々思っていました。
実際、Infrastructure as Codeを実践されているGunosyの記事を見ながら。
こんなにツールをたくさん使わなければいけないなら、ツールを使うことそのものに学習努力がいるし使える人だけで構築するようになって、結局それって俗人化そのものなんじゃないか？。
それより、GUIでシンプルに構築し、構築した手順書とパラメータシートを残した方がいいんじゃないかーー。
基本的には私は、Infrastructure as Codeは否定していて、旧来のインフラ構築方法、つまりパラメータシートと手順書のセットを管理していく方法を実践しています。
が。
Kubernetesに見事に否定される
Kubernetesってヤツは、見事にInfrastructure as Codeを実践しないと構築ができないようになっています。
そのうちGUIが整備されてコーディングなどいらないんでしょうけど。
全部の手順で、YAMLファイルという設定ファイルを書かされます。これをマスターノードに読み込ませ、構文エラーが無ければ実行してくれます。
また、既存の読み込ませたYAMLファイルの一部を変更し、マスターノードに読み込ませたら、差分だけ変更してくれます。
つまり、何のツールも使わずに、Infrastructure as Codeを実践させられるわけです。
ふと気づくと、構築用ディレクトリーにはYAMLファイルが整理され、それらを順番に読み込ませると構築が完了します。
だから、大きな構成変更があっても、一度Kubernetesの構成自体を削除し、再作成。その後修正したYAMLファイルを読み込ませれば、素早く環境構築ができてしまいます。
ってこれ、Infrastructure as Codeじゃん・・。やられた・・。
Kubernetesの優れているところって、ネイティブでInfrastructure as Codeに対応していて何のツールもいらないことなんですね。Kubernetesが更新されればその機能も拡張されていきます。
つまり、Kubernetesのルールで構築していうと、知らない間にコーディングが終わっているという親切設計です。むう。
Infrastructure as CodeはGUIに勝てるか
Kubernetesは、Google CloudはもちろんことAWSでもAzureでもIBM Cloudでも、VMwareでもサポートされます。だんだん方言も取れていって、最後は複数のIaaSで同じコンテナを動かすようなデプロイもできるようになるんでしょう。
一方GUIも進化し、きっとGUIで行った一連の活動が最後にYAMLになって保管できるようになるんでしょう。
そのとき、GUIしか信じない群がYAMLを無視して、Infrastructure as Codeってなんだっけ的な技術者がマジョリティーとなりごくごく普通のインフラ基盤になるのかもしれません。そのときは、YAMLも使えるぜ勢は、ハイレベルKubernetes勢となるんでしょうね。今までのクラウドの世界はそんな感じでした。逆にGUIを作る勢がInfrastructure as Codeを徹底させるようにGUIを作りこむかもしれません、Kubernetesを今取り仕切っているひとは、絶対そうしたいだろうなあ・・。
最後はどうなるかわかりませんが、今Kubernetesを触ると、もれなく、Infrastructure as Codeが付いてきます。ぜひどうぞ！。
しくみがわかるKubernetes Azureで動かしながら学ぶコンセプトと実践知識
