インフラストラクチャーをコード化する（IAC）DevOpsパイプライン – techsyncer

このブログ投稿は、電子書籍「管理者からDevOpsへ：Microsoft Azureで成功するためのDevOpsのNo-BS方法」の一部です。インフラストラクチャをコードとして学ぶことで、Microsoft AzureにおけるDevOpsの成功のためにどのような取り組みが必要かを深く探求したい場合は、ぜひご覧ください。

クラウドまたは仮想インフラストラクチャを手動で作成したことがある場合、たくさんのクリックあるいは入力が必要であることをご存知かもしれません。インフラストラクチャのコード化（IaC）がそれを処理します。

何かをプロビジョニングするには、どの画面に移動するか、またはどのコマンドを実行するかを覚えておく必要があります。Azureを学ぼうとして遊んでいるだけなら問題ありませんが、それが時間がお金になるビジネスクリティカルなプロセスに発展すると、何かが変わる必要があります。

組織がインフラストラクチャのプロビジョニングと管理に真剣に取り組み始めると、さまざまな新しい課題に直面することになります。

作業の不必要な重複、指を誤って入力することによる問題、変更管理の問題、構成のずれなどが発生するでしょう。組織やチームが大きいほど、問題も大きくなります。これらの問題は、インフラストラクチャをコードとして扱うという概念で解消または軽減することができます。

インフラストラクチャをコードとして扱う（IaC）：例を通じて

IaCは、インフラストラクチャコンポーネントを構築するために必要なすべてのものをコードとして保存する業界用語です。そのコードは、通常、JSONまたはYAMLファイルに定義され、インフラストラクチャがどのようになるべきかを表します。

すべてのコンポーネントが構造化されたファイルで定義されたら、別のプロセスがやってきて、コードを理解し、そのドキュメントをインフラストラクチャを構築するための指示書として即座に使用します。

一般的な疑似コードの例を提供するために、仮想マシン(VM)を作成することを考えてみましょう。そのVMにはコンピューティング、ストレージ、ネットワーキングなどの必要があります。IaCの大まかなアプローチは、VMとそのすべてのコンポーネントをテンプレートで記述することです。

テンプレート

以下のコードスニペットでは、各コンポーネントが階層別に分解され、各コンポーネントに関する属性が定義されているのがわかります。この架空の例は、多くのサービスがテンプレートと呼ぶJSONファイルで作成されました。

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.1"
        }
    }
}

このテンプレートは、VMとそれに関連するすべての属性を定義しています。テンプレート作成者が従うための特定のスキーマがあります。このテンプレートが、例えばmyvm.jsonという名前のファイルに保存されるとしましょう。

ソースコントロール

これで、VMを構成するすべての要素が1つのファイルに保存されました。優れたDevOpsプロフェッショナルとして、そのファイルをソースコントロールにチェックインします。これで、ファイルの変更を追跡する手段が得られました。

ツール

ファイルが作成されたので、そのファイルを読み込んで構築しようとしているものを理解するツールやサービスが必要です。そのツールは、テンプレートを入力として使用し、他の操作なしでその仕様に完全に準拠したVMを構築します。

> [some command line tool] -File myvm.json

素晴らしいですね。それだけではありません。

設定のずれに対抗する

さて、そのVMのNICに割り当てられた静的IPアドレスを変更する必要があるとしましょう。VMにRDPしてIPを変更することもできますが、それはしたくありません。

手動で変更することは時間の浪費であり、人為的なエラーのリスクがあります。
誰がいつIPを変更したかの監査トレイルがありません。
IPアドレスを間違えた場合に変更を元に戻す自動化された方法がありません。

インフラストラクチャコード（IaC）は、上記のすべての課題を解決できます。文字通り数回のキーストロークで、マネージャーや監査人に喜んでもらえる方法で変更できます。

myvm.jsonを開き、IPAddress属性を変更し、変更をソースコントロールにコミットして、ツールを再実行します。完了です。

{
	"VM": {
        "Name": "MYVM",
        "Disk": {
            "Size": "100GB"
        },
        "Networking": {
            "IPAddress" : "10.0.0.2"
        }
    }
}

> [some command line tool] -File myvm.json

ツールは、変更が必要な箇所を知ることができます。NICを切り離したり、VM全体を再構築したりはしません。すべてのIaCツールとサービスは、変更方法を理解するのに十分なスマートさを持っています。魔法のようですね！

しかし、今気づいたのですが、間違ったIPを使用しましたので、戻す必要があります。問題ありません。ソースコントロールで変更を元に戻し、コミットして、ツールを実行すれば元に戻ります。

でも、もっとあります。

継続的デリバリーの始まり

インフラストラクチャがソースコントロールのテンプレートに保存されている場合、自動化されたリリースまたは継続的デリバリーパイプラインの開始に必要な要素があります。

テンプレートを変更するたびにそのツールを実行する必要があることを思い出してください。自動化されたパイプライン/ワークフローでは、そのツールは自動的に実行されます。環境の作成や変更のプロセスが自動化されたら、テンプレートへの変更をコミットすると、インフラストラクチャが一致します。

十分な数のテンプレートを構築すれば、最終的にはインフラストラクチャ全体をコードまたはコードとして表現できるようになります。

結論

IaCは、オペレーションがソフトウェア開発者の手法を取り入れることができるDevOpsの方法論です。IaCは、ソフトウェア開発者が何年も活用している多くの利点をもたらし、それをシステム管理者の手にも与えます。