メソッド屋のブログ

米マイクロソフト Software Development Engineer 牛尾の日記です。ソフトウェア開発の上手なやり方を追求するのがライフワーク。本ブログは、個人の意見であり、所属会社とは関係がありません。

私は Infrastructure as Code をわかっていなかった

私はここ1週間ほど、同僚の David の一言で Infrastructure as Code について頭が大混乱状態でした。

それは次の一言です。

Chef や Puppet は大体の部分は Infrastructure as Code じゃないよね。ARM (Azure Resource Manager) はそうだけど。 ただ、Chef-Provisioning は Infrastructure as Code だよね。

もう頭が大混乱です。なんとなく言わんとしていることはわかりますが、私は今まで Chef とか、Puppet とか、Ansible とかで やっているようなことが、Infrastructure as Code と思い込んでいましたが、何か間違っていたのでしょうか?そういえば、 Chef はConfiguration Management Toolと紹介されていたなとか頭によぎります。

Chef (software) - Wikipedia, the free encyclopedia

ここ数日様々な記事やビデオを見て Infrastructure as Code について再考してみたのでここに共有したいと思います。

f:id:simplearchitect:20160218121546j:plain

Infrastructure as Code 再考

まず定義から行きましょう。David 本人が定義している Infrastructure as Code は次の通り

Infrastructure as Code とはソフトウェア開発で実施されてきたテクニック、プロセス、そしてツールセットをシステムやアプリケーションやミドルウェアのデプロイやコンフィグレーションの管理に役立てるための戦略のことである

itproguy.com – DevOps practices

DevOps Practices | IT Pro Guy & Tesar.info

他も見てみましょう Thoughtworks の人の定義

Infrastructure as Code とは、インフラの構成を管理したり、プロビジョニングを自動化するためにハイレベル、もしくは宣言的な言語でコードを書くことである。これは単にスクリプトを書くのではなく、ソフトウェア開発で実証されているプラクティスを使う。例えば、バージョン管理、テスト、小さなデプロイメント、デザインパターンの使用などだ。

www.thoughtworks.com

どちらの定義にも書いてあることは、Infrastructure as Code は、インフラやプロビジョニングを自動化するための、ハイレベル / 宣言的なコードを書くプラクティスであり、それらがコード化されることで、単に自動化できるとかではなく、ソフトウェア開発で培われてきたプラクティスがインフラ構築にも使えるようになることが大きなイノベーションです。具体的には、バージョン管理ツールを使うことだったり、テスト駆動開発やCIだったり、リファクタリングだったり、今までソフトウェア開発でしか使われてこなかったことが、インフラの構築にも使えるようになるわけです。

ここまでは私が理解していたことです。この「ソフトウェア開発のプラクティスをインフラ構築に使える」というイメージはChef のチュートリアルを実施するととても分かりやすいです。このチュートリアルでは、Test Kitchen や、Serverspec というツールを使って、インフラストラクチャをテスト駆動開発で実施します。

Learn to develop your Ubuntu infrastructure code locally - | Learn Chef

3種類の Infrastructure as Code の領域

実際に私のイメージするインフラをコード化したものとしては3種類の対象があります。1つは「VMや、PaaS、Network」などの 生成の自動化、そして、もう一つは起動したVMに対して、各種のツールやライブラリをインストールして設定していくことを自動化するものです。前者は、ARM(Azure Resource Manager), Azure / AWS SDK, Chef-Provision などでできる領域であり、後者は、Chef や Puppet や Ansible、Windows 系なら PowerShell DSC が実施してくれる領域です。様々なインターネットの定義を確認しましたが、前者と後者がまとめて Infrastructure as Code と呼ばれることが大半のようです。ちなみに3つめはコンテナですが、今回の記事では割愛します。

私も頭が混乱して、David 本人に聞いてみましたすると、彼は、「このビデオを見てみてよ。それでまだ質問があったらいつでも聞いてくれよ」とのことでした。

Configuration as Code

そのビデオでは、私は知らなかったのですが、先ほど述べた前者と後者を Infrastructure as Code と、Configuration as Codeとして明確に使い分けていました。David 本人もこのビデオでちらと言っていますが、Configuration as Code とみんながみんなそう呼んでいるわけではないけど、自分はこの考えがメリットがあり好きだから使っていると言っています。

channel9.msdn.com

 実際にインターネットで検索すると、いくつかの Configuration as Code のアーティクルが見つかりました。

www.slideshare.net

dzone.com

www.slideshare.net

 Wikipedia の Infrastructure as Code もよく見たら、Configuration as Code の部分は「extension」と書いてあります。

Infrastructure as Code - Wikipedia, the free encyclopedia

本当の歴史はわかりませんが、きっと 一般的な用語の Infrastrucure as Code は、きっと AWS SDKぐらいから始まっているのでしょう。それが、だんだん拡張されて、Configration の領域もそういわれるようになったという感じでしょうか?

Infrastructure as Code と Configuration as Code

このビデオやアーティクルで Configuration as Code を明確に分けるメリットについて述べられています。

  • Dev と Ops の役割が明確に分かれること

  • 混乱がなくなること (Infrastructure as Code と Configuration Management)

  • ライフサイクルの違い

最初のポイントに関しては、「DevOps と逆方向じゃね?」とお思いになる方もおられるかもしれません。ただ、私の意見としては、DevとOps はフィーチャーチームとして同じチームになるほうがいいと思いますが、フルスタックエンジニア的なものになる必要はないと思っています。これは意見がわかれるところでどちらでもいいと思います。個人的には、Dev と Ops というのは萌えポイントが違うことが多いと思うのです。

 例えば、私と一緒に働いている小塚さんという非常に優秀なITProのクールガイがいるのですが、彼はたまに私のやっていることが「全然興味ない」と言っています。一方、Dev出身の私は、彼がたまに、OSのパラメータをいじってパフォーマンスがちょっと向上したとかいってほくそ笑んでいる姿をみて「まったく興味ないわ」と思っていますw。やっぱり人は自分が楽しいことをやって、それで周りと協力するほうがずっと仕事も楽しいと思うので Dev と Ops はあったほうがいいと思うのです。お互いのキャリアは一瞬で簡単に身につくものでもありません。 そういう全然違う人が同じチームで助け合う姿のほうが私は DevOps として楽しいんじゃないかと思っています。

自分的な結論

 また、ビデオでも、David が多くの人が、Infrastructure as Code と Configuration Management の混乱を感じていると 言っています。私も思いっきりそうでした。Chef は Configuration Management Tool であるが、Infrastructure as Code でもあるという風にすると、確かにどこに「インフラ」はいっちゃったのかな?という感じになります。

 きっとこのInfrastructure as Code のムーヴメントは、元Develper の人に主導されてきたのではないか?と仮説を立てています。 私のようなDevの人からすると、コードを書くのに集中したいので、デプロイする先のは、まるっと「インフラ」という感じなので、その 細かい違いに無頓着です。  一方 David は ITPro guy と名乗るぐらいなので、ITPro の人です。彼にとっては、インフラ構築と、コンフィグレーションは まったく別物で、使うタイミングも違うものという考えをしていました。例えば、「コンフィグレーション」は何回か実施します。

 というわけで、私も David の考えに大変共感しましたので、今後は Infrastructure as Code と Configuration as Code という2つの用語を使って明確に分ける派になろうと思っています。

おまけ: Donovan Brown の姿勢

このビデオのDonovan Brown の姿勢がとても好きです。彼は、Visual Studio Team Services の Product Manager で、DevOps を広める立場にあります。その人が「私は Infrastructure as Codeがわかってないんだ」と言って、David にビデオという人前できいてそれをなおかつ共有するとか、日本人ではありえない展開です。でも彼は演技ではなくて素直にそれを人前で聞いています。そしてそれをシェアして、同じように思っている人と学びを共有しました。私もそうありたいと思います。