IBM Cloud Docs
Infrastructure as Code とは何ですか?

Infrastructure as Code とは何ですか?

簡単に言うと、Infrastructure as Code (IaC) は、コードを使用して、手動プロセスではなく、記述モデルでインフラストラクチャー (ネットワーク、仮想マシン、ロード・バランサー、クラスター、サービス、および接続トポロジー) を管理およびプロビジョンします。

IaC, 構成ファイルによってインフラストラクチャが定義されるため、構成の編集、共有、再利用が容易になります。 インフラストラクチャーをコード化することで、文書化されていない随時の構成変更を回避するたびに、同じ環境をプロビジョンします。

Schematics は、オープン・ソースの Ansible と Terraform を使用して、クラウド・インフラストラクチャーをプログラムするためのサービスとして IaC ツールの強力なセットを提供します。 Schematics では、この豊富な一連の IaC 自動化機能を使用して、クラウド・リソースのスタックの構築、そのライフサイクルの管理、構成の変更の管理、アプリケーション・ワークロードのデプロイ、および day-2 操作の実行を行うことができます。

Infrastructure as Code の利点

インフラストラクチャーのデプロイメントに IaC アプローチを採用すると、インフラストラクチャーのプロビジョニングに関する多くの一般的な問題が解決され、いくつかの利点が得られます。 Schematics を使用すると、独自の IaC ツールをインストール、実行、および管理することなく、これらの利点を実現できます。

  • 信頼性と整合性 (Reliability and Consistency): 新しい環境またはインフラストラクチャーが確実にプロビジョンされます。 手動プロセスではエラーが発生します。 IaC を使用すると、同じ構成が何度も繰り返しデプロイされますが、違いはありません。 IaC は、環境間およびデプロイメント間の整合性を向上させます。

  • スピード: IaC を使用すると、自動化によって完全なインフラストラクチャーを素早くセットアップできます。 開発環境から実動環境、ステージング環境、QA 環境など、すべての環境に適用します。 これにより、環境のデプロイ、管理、および保守にかかる時間が短縮されるため、コストの削減につながる可能性があります。

  • トラッキングとアカウンタビリティー: 既存のインフラストラクチャーに対する変更はコード内で行われ、変更は追跡されます。 他のソース・コード・ファイルと同様に、構成に対して行われた変更の完全なトレーサビリティーがあります。

  • 環境のドリフトを検出して修正: インフラストラクチャーの一部がコードの外部で手動で変更された場合、次回の実行時にその一部を望ましい状態に戻すことができます。 ドリフト検出 は、 Schematics ワークスペースの機能です。

ベスト・プラクティス

プロビジョニングおよび構成管理のために IaC を採用する場合、いくつかの推奨プラクティスがあります。 これらのプラクティスは、 Schematicsを使用する場合に完全にサポートされます。

IaC でのすべてのコード化

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

資料の最小化

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

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

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

テスト

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

継続的統合 (CI) を使用すると、テンプレート・インフラストラクチャー構成を、最小限の変更を効果的に適用して、 developmentUATQA、または 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 などのリソースは更新が必要なときに再デプロイする必要があります。

次のステップ

これでIaC,についての理解が深まったと思いますが、SchematicsでIaCの使い方を復習してみてはいかがでしょうか: