序章

クラウドコンピューティングは、物理ハードウェアおよび必要な基盤となる構成から切り離されたオンデマンドコンピューティングリソースを提供します。 自律型ソフトウェアシステムは、クラウドコンピューティングが提供する自動化を実現するために、クラウドでこれらのコンピューティングリソースをプロビジョニングします。 このような自動化により、クラウドプロバイダーとのインターフェースにより、利用可能なリソースをプログラムで制御および操作することができます。 このようにして、インフラストラクチャの変更(リソースのスケーリングなど)をより迅速かつ確実に実装し、ほとんど手動で操作しなくても操作できますが、プロセス全体を監視し、計画どおりに進まない場合は変更を元に戻すことができます。

Infrastructure as Code (IaC)は、必要なリソースの状態とそれらの相互関係をコードで定義することにより、インフラストラクチャの展開と変更を自動化するアプローチです。 コードは、IaCツールの特殊な人間が読める言語で書かれています。 コードを実行すると、クラウド内の実際のリソースが作成(または変更)されます。 これにより、クラウドプロバイダーのWebインターフェイスを使用せずに、必要な変更を適用するために、ユーザーに代わってクラウドプロバイダーまたはデプロイメントシステムとインターフェイスするようにツールにプロンプトが表示されます。 コードは必要に応じて変更できます。コードの実行時に、IaCツールは、コード内の目的のインフラストラクチャとクラウド内の実際のインフラストラクチャの違いを見つけ、実際の状態を目的の状態と等しくするための手順を実行します。

IaCが実際に機能するためには、作成されたリソースを後で手動で変更しないでください(不変のインフラストラクチャ)。これにより、コード内の予想されるインフラストラクチャとクラウド内の実際の状態の間に不一致が生じます。 さらに、手動で変更されたリソースは、将来のコード実行中に再作成または削除される可能性があり、そのようなカスタマイズはすべて失われます。 これに対する解決策は、変更をインフラストラクチャコードに組み込むことです。

この概念的な記事では、IaCアプローチ、その利点、および実際の実装の例について説明します。 また、オープンソースのIaCプロビジョニングツールであるTerraformも紹介します。 このアプローチにおけるTerraformの役割と、他のIaCツールとの比較について説明します。

IaCの利点

IaCを使用すると、信頼できる唯一の情報源である宣言型コードから、複数のプロバイダーリージョンで、インフラストラクチャ全体のインスタンスを必要な数だけすばやく作成できます。 これには多くの利点があり、管理と手動のセットアップ時間を短縮しながら、エラーなしで一貫してリソースを作成できます。

IaCの主な利点は次のとおりです。

  • 展開:クラウドプロバイダーとの手動プロビジョニングの相互作用を削除すると、展開速度が速くなります。
  • リカバリ:構成の問題を特定することは、障害からの迅速なリカバリを意味する場合があります。
  • 一貫性:リソースのデプロイは毎回同じであり、インフラストラクチャの脆弱性を解決します。
  • 変更:リソースを変更すると、所要時間が短くなる可能性があります。
  • 再利用性:将来のプロジェクトでインフラストラクチャアーキテクチャの一部を再利用します。
  • バージョン管理:インフラストラクチャコードをバージョン管理システムに保存します。
  • 可視性:構成をコードとして記述することは、インフラストラクチャのドキュメントとして機能します。

IaCワークフロー内では、標準化された方法でインフラストラクチャを繰り返し起動できます。つまり、開発、ステージング、品質保証テスト、および本番環境が分離されているため、ソフトウェアの開発とテストがより迅速になります。 インフラストラクチャを必要な回数だけデプロイすることで、コードを記述してライブでテストするプロセスを繰り返すことができます。 作成したインフラストラクチャがすべての要件を満たしたら、それを目的のクラウド環境にデプロイできます。 新しい要件が発生した場合は、プロセスを繰り返すことができます。

IaCはコードに基づいているため、常に Git などのバージョン管理ソフトウェア(VCS)と組み合わせる必要があります。 インフラストラクチャ宣言をVCSに保存すると、チームの全員に変更が表示され、簡単に取得できるようになります。また、履歴ポイントのスナップショットが提供されるため、新しい変更によってエラーが発生した場合は、いつでも以前のバージョンにロールバックできます。 高度なVCSは、承認された変更が追加されたときにIaCツールを自動的にトリガーしてクラウド内のインフラストラクチャを更新するように構成できます。

これで、IaCアプローチとは何か、そしてそれがもたらすメリットがわかりました。 ここで、IaCで採用されているリソース追跡メカニズムである状態について学習します。 次に、IaCを使用してTerraformおよびその他のツールの役割をフォローアップします。

「状態」とは何ですか?

IaC環境では、「状態」という用語は、デプロイメント内の必要なインフラストラクチャリソースの状態を指します。 ある時点で少なくとも3つの状態があります。クラウド内の実際の状態、コードで提示される理想的な状態、およびIaCツールが維持するキャッシュされた状態です。 キャッシュされた状態は、コードが最後に実行されたときのクラウド内の状態を表します。 Terraformを使用すると、同じコードを複数回デプロイして、デプロイメントごとに複数の状態を形成できます。

(管理対象リソースの)クラウドの実際の状態は、ツールのキャッシュされた状態と常に同じである必要があります。 コードを実行すると、ツールは理想的な状態をキャッシュされた状態と比較し、検出された差異をクラウドに適用します。 キャッシュされた状態と実際の状態が一致しない場合、実行が失敗するか、リソースが誤ってプロビジョニングされる可能性が高くなります。

IaCにおけるTerraformの役割

Terraform は、 Go で記述され、Hashicorpによって開発されたオープンソースのIaCリソースプロビジョニングツールです。 DigitalOceanを含む複数のクラウドプロバイダーをサポートします。 インフラストラクチャ定義はHashicorp構成言語(HCL)で記述されており、そこに記述されているソースコードファイルのファイル拡張子は tf.

Terraformは、インフラストラクチャを説明するコードを読み取り、すべてのリソースとそれらの相互関係を含むグラフを生成することで機能します。 次に、それをクラウド内のリソースのキャッシュされた状態と比較し、クラウドに適用される内容と、目的の状態に到達するための順序を詳細に示す実行プランを作成します。

Terraformの基盤となるコンポーネントの2つの主要なタイプは、プロバイダープロバイダーです。 プロバイダーは、特定のクラウドプロバイダーとの対話、リソースの作成、管理、および削除を担当し、プロビジョナーは、作成されたリモートリソースまたはコードが実行されているローカルマシンで特定のアクションを実行するために使用されます。

Terraformは、コンピューティングインスタンス、ロードバランサー、ストレージ、DNSレコードなどの基本的なクラウドプロバイダーコンポーネントの管理をサポートしますが、その拡張性により、プロバイダーとプロビジョナーをさらに追加できます。

IaC Terraformの役割は、クラウド内のリソースの状態がコードで表現された状態と等しくなるようにすることです。 デプロイされたリソースを監視せず、主な焦点は、プロビジョニングされたコンピューティングインスタンスをソフトウェアとタスクでさらにブートストラップすることではありません。 次のセクションでは、他のツールとの比較と、一般的なワークフローでそれらがどのように相互に拡張するかを学習します。

IaCを使用するツール

IaCアプローチは、最新の展開、構成管理、仮想化、およびオーケストレーションソフトウェアで広く使用されています。 DockerKubernetesは、コンテナーの作成とオーケストレーションに使用される主要なツールであり、どちらもYAMLを言語として使用して目的の最終結果を宣言します。 一方、デプロイメントのスナップショットを作成するためのツールである Hashicorp Packer は、JSONを使用して、システムのスナップショットを構築するテンプレートと変数を宣言します。

Ansible Chef 、および Puppet は、最も一般的な3つの構成管理ツールであり、すべてIaCアプローチを使用して、管理するサーバーの望ましい状態を定義します。

Ansibleブートストラップは、特定のプレイブックに従ってサーバーを提供しました。 プレイブックは、適切なYAMLで記述されたテキストファイルであり、既存のターゲットリソースに対して実行する操作をAnsibleに指示します。 このような操作の例には、サービスの実行と開始、システム提供のパッケージマネージャーを使用したパッケージのインストール、カスタムbashコマンドの実行などがあります。 Ansible Playbookの作成の詳細については、 Configuration Managment 101:Writing AnsiblePlaybooksを参照してください。

ChefとPuppetはどちらも、管理対象サーバーのそれぞれにエージェントがインストールされた中央サーバーを必要とします。 Ansibleとは異なり、ChefはRubyを使用し、Puppetはリソースを記述するために独自の宣言型言語を使用します。

Terraformは、他のIaCツールやDevOpsシステムと相互に排他的ではありません。 その強みは、ソフトウェアの追加インストールやサーバーの初期セットアップではなく、ハードウェアリソースのプロビジョニングにあります。

AnsibleやChefなどの構成管理ツールとは異なり、Terraformはターゲットリソースへのソフトウェアのインストールやタスクの設定には適していません。 代わりに、Terraformは、サポートされているリソースと対話するためのプロバイダーを提供します。

Terraformは単一のマシンから動作でき、他のツールとは異なり、プロビジョニングされたリソースにクライアントエージェントがインストールされた中央サーバーを必要としません。 主な焦点はプロビジョニングにあるため、実際の状態をチェックせず、構成を自動的に再適用します。 一般的なワークフローは、Terraformを使用してインフラストラクチャリソースをプロビジョニングし、必要に応じて構成管理ツールを使用してそれらをブートストラップすることです。

Chefの場合、Terraformには組み込みのプロビジョナーがあり、プロビジョニングされたリモートリソースにクライアントエージェントをセットアップします。 これを使用すると、プロビジョニングされたすべてのサーバーをメインサーバーに自動的に追加できます。メインサーバーから、Chefのインフラストラクチャ宣言であるクックブックを使用してサーバーを追加で構成できます。 それらの記述について詳しくは、 Configuration Management 101:Writing ChefRecipesを参照してください。

結論

この記事では、IaCアプローチのパラダイム、従来の手動システム管理に対する利点、IaCリソースプロビジョニングツールとしてのTerraformの基本、および他の一般的なインフラストラクチャ自動化ツールとの比較について説明しました。

Infrastructure as Codeをワークフローに組み込むことを検討している場合は、 Terraformシリーズをチェックして、開発および展開プロセスでこのツールを使用するための基本を学びます。

Terraformを開始する1つの方法は、 Terraformプロジェクトを構築する方法を読んで、インフラストラクチャをスケーラブルで拡張可能な状態に保つ方法を理解することです。