Infrastructure as Code とは何ですか?

IaC でのすべてのコード化

すべてのインフラストラクチャー仕様は、構成ファイルで明示的にコーディングする必要があります。例えば、Terraform 構成や Ansible プレイブックなどです。 構成ファイルは、インフラストラクチャー仕様の信頼できる唯一の情報源であり、構成でどのインフラストラクチャー・コンポーネントが使用されているかを記述しています。

資料の最小化

IaC は資料です。 IaC を配置すると、構成ファイルは文書を表し、常に最新の状態になるため、手間が軽減されます。 残りの資料は、このプロセスに関するものです。 バージョン管理システムでコードを保守します。

IaC 構成ファイルは、 GitHub や GitLabなどのバージョン管理システム (VCS) に保持する必要があります。 これにより、コード変更の監査証跡が提供されますが、変更が稼働する前にコラボレーションしたり、ピア・レビューやテストを行ったりする機会も提供されます。

このプラクティスを使用すると、トレーサビリティーと可視性の向上により、システムに対する潜在的な変更を容易に追跡、管理、および元に戻すことができます。

テスト

IaC がソフトウェア開発から借用する手法の 1 つに、テストがあります。 デプロイメント後の問題を削減する上で、インフラストラクチャー構成の厳密なテストが役割を果たします。 バージョン管理システムと組み合わせると、コードが変更されるたびにテストを自動的に起動できます。

継続的統合 (CI) を使用すると、テンプレート・インフラストラクチャー構成を、最小限の変更を効果的に適用して、 development、 UAT、 QA、または production 環境などの複数の環境に実装することができます。

モジュラー・インフラストラクチャー

インフラストラクチャーを モジュール に分割すると、再利用が可能になり、信頼性が向上し、導入パスが容易になります。 プログラミング言語でのモジュールおよびパッケージの使用に類似しています。 以下に、このプラクティスの利点を示します。

• 頻繁に使用される構成は、モジュールとしてコーディングでき、複数の環境で複数回再利用できます。
• モジュールのテストが可能になり、使用により時間の経過とともにモジュールが強化されると、信頼性が向上します。
• 再使用可能モジュールからの構成により、 IaC の採用に対するスキル・バリアが低減されます。
• 変更は、モジュール・レベルで簡単に行い、テストすることができます。
• 変更のリスクは、構成変更がローカライズされるにつれて減少します。

IaC に対する宣言的アプローチと命令的アプローチ

IaCを採用することで、ツールが取るアプローチを検討することができます。 宣言または命令という 2 つの異なるスタイルがあり、場合によってはプロシージャーと呼ばれることもあります。

宣言的アプローチは、必要なリソースおよび必要なプロパティーを含む、システムの望ましい状態を定義し、ツールによって自動的に構成されます。 ツール自体が、任意の開始点から目的の状態に到達するための操作を決定します。

命令的アプローチでは、代わりに、目的の構成を実現するために必要な特定のコマンドを定義します。これらのコマンドは、正しい順序で実行する必要があります。

Chef は、命令的なツールと考えられています。 Terraform は宣言型として分類されます。 Ansible は宣言型ですが、命令コマンドで使用することもできます。

宣言型 Terraform とライフサイクル管理

Schematics は、 Schematics のワークスペースとアクションを使用して、Terraform と Ansible の両方を IaC ツールとしてサポートします。 定期的に立ち上がって切断される環境でライフサイクル管理が重要な場合は、 Schematics ワークスペースで Terraform を使用することをお勧めします。 Terraform は、デプロイされたクラウド・インフラストラクチャーの現在の状態を記録します。 Schematics は、手操作による介入なしに、逆の依存関係の順序でインフラストラクチャーを削除できます。

Idempotence

Terraform および Ansible によって使用される宣言の利点は、 idempotence です。 べき等のタスクは、同じ最終結果で複数回実行することができます。 障害後の再始動時の以前の状態や開始場所に関係なく、プロビジョンされたインフラストラクチャーと構成は常に同じです。 この側面は、 Schematicsを使用してデプロイされた環境の一貫性と再現性を確保する上で重要です。

ツールとその両方を使用するモジュールをどのように使用するかは、 idempotency に影響を与えます。 通常、Terraform モジュールと Ansible モジュールは、べき等として記述されています。 どちらのツールでも、べき等の結果をもたらさないコードを作成することができます。 その場合、構成は目的のターゲット状態からドリフトする可能性があります。 Terraform では、べき等ではないカスタム・スクリプトを使用してプロバイダー機能を拡張するために null-resources が使用される場合に、この形式のドリフトが使用される可能性が最も高くなります。

不変性は、ターゲット状態からのドリフトのリスクを最小化する IaC プラクティスです。

イミュータブル (不変)

不変インフラストラクチャーとは、(スクリプトを使用して) 変更されるのではなく、コンテナーや仮想マシンなどのリソースが置き換えられるサービスおよびソフトウェア・デプロイメントの管理を指します。 ここでの不変性の主な目的は、構成のドリフトを回避することです。 ローカルまたは手動の変更、または自動化操作の順序の違いによって生じる不整合。 変更により、問題のデバッグと解決が困難になり、サポート・コストが増加します。

不変性を確保し、ドリフトをなくすために、すべての変更は Schematics IaC 構成を介して行う必要があり、VSI などのリソースは更新が必要なときに再デプロイする必要があります。