ここ最近、Infrastructure as Codeとインフラ運用の自動化が同じことのように語られているなと感じました。また、「Infrastructure as Codeとはインフラ運用をコードで管理することで、コードで管理すれば自動化し易いから、Infrastructure as Codeは重要なんだ」という間違った理解を私がしていたことに気づいたので、Infrastructure as Codeについて調べた内容をメモとしてまとめます。
Infrastructure as Codeとは
まず、Infrastructure as Codeの定義は以下の通り。
1. （主にSoftware Definedな）ITインフラを管理する際の考え方・概念
2. ITインフラをソフトウェアとして捉え、宣言的なコードを使って管理する。
1と2について詳細に解決します。
まず1.については、Software DefinedなITインフラとはSoftware Defined Networkとか、Software Defined Strageとか言われる通り、単一のソフトウェアで機器を集中的に制御することで構成や設定を柔軟に変更出来るようにしたITインフラのことで、これは既に浸透してきてますね。
また、「ITインフラを管理する際の考え方・概念」とはどういうことかというと、
“ソフトウェア開発で実施されてきたテクニック、プロセス、そしてツールセットをシステムやミドルウェアのデプロイやコンフィグレーションの管理に役立てるための戦略のこと”
itproguy.com ‐ DevOps practices
とのことです。これは次の章で具体的に説明します。
次に2.に記載している、「宣言的なコード」とは何かというと「ある要件を一言で実現させること」です。例えば、コーヒーの作り方は言わないで「コーヒー頂戴」と一言で言えばコーヒーが手に入るようにすることを指します。
通常はコードを使って何かを実現する時、コーヒーを作るためには、どんな豆を使うのかとか、どういう手順でコーヒーを作るのかといった細かい作業を記述しないと実現出来ませんでした。
ただ、細かい作業の記述は難易度高いので、プログラミングを専門としていない人が記述するのは現実的ではないです。
そこで、細かい作業の記述はプログラミングの天才集団が作っておいて、素人は宣言的なコードだけを覚えれば使えるようにしたのがオープンソースのフレームワークAnsibleとかCHEFという訳です。
AnsibleとかCHEFを使うと、管理者は「コーヒー頂戴」くらいの一言で要件実現できるようにすること。これの最大のメリットとしては、「プログラミングを専門としない人でも高度なプログラムを扱えるようになる」ということですね。
Infrastructure as Codeがインフラ運用にもたらす変化とは
Infrastructure as Codeがもらたす変化、具体的には前章の1.「ITインフラを管理する際の考え方・概念」、を適用することで以下の変化がもたらされます。
| 運用の流れ | 従来 | Infrastructure as Codeの場合 |
| 1.作業手順の作成 | WordとかExcelで作成 | 宣言的なコードで作成 |
|---|---|---|
| 2.作業手順の確認 | 手順書レビュー | コードレビュー |
| 3.作業の実施 | 手動で実施 | ツールで自動実施 |
| 4.作業結果の確認 | 手動で実施 | ツールで自動実施 |
| 5.履歴管理 | 変更管理システム | バージョン管理システム |
ソフトウェア開発をやっている方は気づくかもしれませんが、上記はソフトウェア開発のプラクティスを持ち込むことによって実現します。
つまり、Infrastructure as Codeとは、インフラ管理に以下のソフトウェア開発のプラクティスを持ち込めることなんですね。
・バージョン管理 →Git /Github・Gitlabでソースコード・各種ファイルの変更履
歴をきちんと管理する
・コードレビュー →他の人にコードの確認（仕様の確認、コーディング規約の統一、車輪の再発明の防止を目的として）をしてもらう
・テスト駆動開発 →先にテストを書いて、テストをPass出来るコードを書く工程を繰り返す開発手法
・CI：継続的インテグレーション →不具合の早期発見と手戻り削減を目的として、テストを短いスパンで頻繁に行う開発手法
・CD：継続的デプロイメント →GithubでReleaseBrunchへのPull Requestが承認さ
れたら本番環境に自動リリース
Infrastructure as Codeのソフトウェア開発のプラクティスを持ち込むメリット
では、ソフトウェア開発のプラクティスを持ち込むことによる大きなメリットは以下3点があげられます。
・再現性：同じコードを使えば複数の同じ環境を再現可能
・再利用性：一度作成したコードは別の環境で再利用可能
・迅速性：インフラ構築時のリードタイムが手動に比べて短縮
特に重要なのが再現性と再利用性。
インフラ運用で最も大事なのが、構成管理資料や設計書、手順書、アーキテクチャドキュメントといった文書管理をルールを作ってきちんと管理することだと筆者は思っています。
そしてインフラ屋さんというのは文書管理がずさんな人が多い。また、同じ会社でもプロジェクト間で優れた再利用可能な構成情報の共有がされてないという課題もある。
その理由として、OSの種類が多いし、アーキテクチャが異なると再利用が難しいし、プロジェクト間で共有しても自分にメリットないし、ナレッジが自分の中にあれば属人化出来るし、そもそも面倒だし、とか色々あるとは思うが、ソフトウェア開発のプラクティスを持ち込むことで再現性・再利用性といった仕組みを強制的にインフラの現場にも適用することが出来れば、インフラ運用は更に効率的なものになるでしょう。
