Infrastructure as Code とは何ですか?

IaC でのすべてのコード化

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

資料の最小化

IaC はドキュメントである。 IaC、設定ファイルはドキュメントを表し、常に最新であるため、労力が軽減される。 残りの資料は、このプロセスに関するものです。 バージョン管理システムでコードを保守します。

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

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

テスト

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

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

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

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

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

Terraform IBM モジュールの活用

Terraform IBM Modules(TIM ) は、 IBM Cloud のために特別に設計された、生産準備の整った再利用可能なインフラストラクチャ・コンポーネントを提供する。 これらのモジュールは、Infrastructure-as-Codeのベストプラクティスに従い、一般的な IBM Cloud サービスの展開の複雑さを大幅に軽減します。

Terraform IBM Modulesを探索し、VPCインフラストラクチャ、セキュリティサービス、observabilityなどのためのビルド済みモジュールを見つけましょう。 各モジュールは、 IBM Cloud の専門家によって徹底的にテストおよび保守されており、信頼性とセキュリティのベストプラクティスの遵守を保証します。

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

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

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

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

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

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

Schematics は、 Schematics ワークスペースとアクションを持つ IaC ツールとして、Terraform と Ansible の両方をサポートしている。 ライフサイクル管理が重要で、定期的に環境を立ち上げたり壊したりする場合は、 Schematics ワークスペースを持つ Terraform を使うことを推奨する。 Terraformは、デプロイされたクラウドインフラストラクチャの現在の状態を記録しておき、 Schematics、手動で介入することなく、依存関係の逆順でインフラストラクチャを削除することができる。

Idempotence

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

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

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

イミュータブル (不変)

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

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