この記事は、開発者、ITインフラストラクチャエンジニア、インフラストラクチャ自動化プロジェクトに取り組んでいるマネージャー、IaC の取り組みを開始するためのリードを探しているビジネスプロフェッショナル、もしくはとにかく IaC について知りたいと思っている方に、ぜひ読んでいただきたい内容になっています。
このブログシリーズでは、一般に「IaC」として知られる Infrastructure as Code について取り上げます。 主に利用可能なツール、ベストプラクティス、例を含むコーディング方法、最近の傾向などを中心に説明します。
シリーズ全体を読んでいただくことも、関心のある特定の IaC トピックにスキップしていただくこともできます。
ここでは、一般によく使用されているIaCツールを紹介します。 あなたのプロジェクトに関連する最適なIaCツールを選択できるように、これらのツールを徹底的に比較してみます。
※こちらの記事は公開済みの英語記事の翻訳版となります。原文はこちら。 tech-blog.jtp.co.jp
目次
イントロダクション
IaC 市場には、インフラストラクチャのプロビジョニングと管理に使用できるIaC ツールが数多くあります。ただし、プロジェクトに適したものを選択するのは大変な作業です。どのツールが適切かは、次のようなさまざまな要因によっても異なります。
- プロジェクト要件 (プロビジョニングと管理、またはプロビジョニングのみ)
- 導入を想定してるプラットフォーム(AWS、Azure、オンプレミスなど)
- チーム内で利用可能なスキルセット(開発用に知られている言語を含む)
- などなど ...
利用可能な IaC ツール、それらのツールで利用できる機能、および他のツールとの違いについて、もう少し詳しく見てみましょう。
人気のあるツール、あなたに最適なツールは?
ここでは、人気の IaC ツールと、それらをどのような状況で使用すると最も生産的なツールになるかを見てみましょう。あなたのプロジェクトの要件に適した IaC ツールを選択するために比較してみましょう。
IaCへのアプローチ
前回のブログ last blog, で説明したように、インフラストラクチャをコードとして記述する方法は 2 つあります。
- 命令型
- 宣言型
これらのアプローチは、 IaC ツールを決める上で重要な要素となります。それでは、IaCツールを見ていきましょう。
IaCツールの種類
Terraform
Terraformは、現時点で最も広く仕様されている IaC ツールです。これは、HashiCorp社が提供する、インフラストラクチャ自動化のためのプラットフォームに依存しないオープンソースのツールです。 コードを使用したインフラストラクチャの構成、プロビジョニング、管理に役立ちます。
アプローチ: 宣言型
ほぼすべての主要なクラウド プロバイダーだけでなく、Kubernetes や Heroku などのプラットフォームもサポートしているため、マルチクラウド デプロイメントに使用できます。 それにもかかわらず、オンプレミスのインフラストラクチャの構築も可能です。
Terraform 構成は、HashiCorp社によって開発された、HCL (HashiCorp Configuration Language) として知られる言語で記述されます。
また、Terraform はコマンドライン インターフェイス(CLI)を提供しており、デプロイ前に計画(Plan)を作成してコードの事前チェックを行うことができます。 これにより、構成が期待どおりであるかどうかを確認しやすくなります。 状態(State)はファイルとして保存し、ディスク、S3、ソース管理などに保存できます。さらに、インフラストラクチャ全体を一度に破壊(Destroy)することもできます。
HashiCorp社は、自社で管理する Terraform のSaaS版である「Terraformクラウド」も提供しています。チームが Terraform を共同で使用する時に役立ちます。 独自のクラウド インフラストラクチャにデプロイされた使い捨ての仮想マシン インスタンスを備え、一貫性と信頼性の高い環境で管理および実行されます。
AWSおよびその CDK チームとの連携を経て、2020年7月には「CDK for Terraform」(CDK TF)も導入しました。 これは、AWS CDK の 2 つの重要な機能を使用することを目的としています。
Terraform 用の CDK は、AWS CDK のライブラリを使用して Terraform 構成を生成します。開発者にとって、これは非常に良いことです。 TypeScript、Python、Java、C#、Go (実験的) などの汎用プログラミング言語を使用して Terraform 構成を生成できるため、HCL を学習する必要がなくなります。
AWS CloudFormation
AWS には、AWS CloudFormation (略して「CFn」と呼ばれる) と言う、独自のクラウド プラットフォーム用の人気のあるIaCツールがあります。 AWS リソース スタックをプロビジョニング、デプロイ、管理する方法を提供します。
アプローチ: 宣言型
CloudFormation テンプレートは、YAML または JSON 形式で記述されます。 AWS プラットフォームのみに限定されていますが、他の AWS リソースとの統合機能があるため、非常に普及しています。 これにより、AWS インフラストラクチャのデプロイと管理、リージョンとアカウント間のレプリケーションが簡素化され、変更の制御と追跡が容易になります。
CloudFormation の用語では、関連するリソースが 1 つのユニットとして結合され、スタックと呼ばれます。 また、スタック内の実行中のリソースに対する提案された変更の概要である「変更セット」を作成することもできます。 CFn はロールバック トリガーも使用して、スタックを以前の状態に復元します。
AWS CDK
AWS CDK (Cloud Development Kit) は、クラウド インフラストラクチャをコードとして定義するためのオープンソース フレームワークです。 CDK を使用すると、プログラミング言語 TypeScript、JavaScript、Python、Java、C#/.Net、および (開発者プレビューでは) Go でコードを記述し、Constructs として知られる再利用可能なクラウド コンポーネントを定義できます。
アプローチ: 宣言型
バックエンドでは、CDK が汎用プログラミング言語コードを CloudFormation テンプレートに変換し、リソースを AWS にデプロイします。
フローは次のようになります:
-> TypeScript、Python などで CDK コードを作成 -> CDK が CloudFormation テンプレートを生成 -> CDK が AWS リソースをデプロイおよび管理
これは、開発者にとって最高の IaC ツールの 1 つです。開発者はプログラミング言語の柔軟性と表現力を活用し、ソフトウェア エンジニアリングの手法を使用してインフラストラクチャの信頼性と堅牢性を高めることができるからです。
Azure Resource Manager
Microsoft Azure プラットフォームは、インフラストラクチャの展開と管理を自動化する「Azure Resource Manager」と呼ばれる IaC ツールを提供しています。 これにより、グループ内のリソースをデプロイ、管理、監視できるようになります。
アプローチ: 宣言型
Azure Resource Manager はJSON 形式で定義された ARM テンプレートを使用して、インフラストラクチャ内のリソースとその依存関係を定義および管理しています。 使い方も簡単なので、業界では広く普及しています。
Azure はデフォルトでロールベースのアクセス制御 (RBAC) をサポートしており、これによりサービスとリソースへのアクセスを制御する機能が追加されます。これを使用すると、管理グループ、サブスクリプション、およびリソース グループへのきめ細かいアクセスを提供できます。また、リソースにタグを付けてサブスクリプション内で論理的に整理したり、特定のタグが付いているリソースのコストをチェックしたりすることもできます。
Azure Resource Manager を使用すると、開発ライフサイクル全体を通じてインフラストラクチャを迅速に複数回デプロイできたり、リソースを一貫した状態に維持することができるので非常に便利です。
Google Cloud Deployment Manager
Google社は、独自の Google Cloud プラットフォーム向けに「Google Cloud Deployment Manager」と呼ばれるインフラストラクチャ導入サービスを提供しています。 これは、Google Cloud リソースの作成、デプロイ、管理の自動化に使用されます。
アプローチ: 宣言型
Python または YAML を使用して、リソースの定義、モデルの構築、デプロイ前の変更のプレビュー、コンソール ユーザー インターフェイスでのデプロイの進行状況の表示を行うことができます。 Google Cloud Deployment Manager を使用すると、多くのリソースを同時にデプロイできます。 コード形式の構成は、インフラストラクチャを一貫した状態に維持するための唯一の信頼できる情報源として使用されます。
Puppet
Puppet は、独自の宣言型言語を持つ最も古い構成管理ツールの 1 つです。これは、インフラストラクチャ管理機能を備えた、インフラストラクチャ自動化のもう 1つのツールです。
アプローチ: 宣言型
Puppet には、「Puppet コード」と呼ばれる、Ruby に基づく独自のドメイン固有言語 (DSL) があり、インフラストラクチャの望ましい状態を定義できます。Puppet エコシステムには、「Puppet Primary Server」と「Puppet Agent」で構成される「Puppet プラットフォーム」があり、インフラストラクチャを自動化し、望ましい状態を維持するために使用されます。
Puppet プライマリ サーバーは、望ましい状態を定義するコードを保存します。 Puppet エージェントはコードをコマンドに変換し、指定したシステム上でそれを実行します。これを「Puppet run」と呼びます。
Puppet のユーザー インターフェイスは非常に直感的であり、単一画面を通じてインフラストラクチャ全体をリアルタイムで監視および管理できます。 AWS、Azure、GCP、VMWare など、ほぼすべての主要なクラウド IaC プラットフォーム プロバイダーのインフラストラクチャを自動化するために使用できます。
Ansible
Ansible は、インフラストラクチャのプロビジョニングを自動化するために使用されるオーケストレーションおよび構成管理ツールです。 ただし、インフラストラクチャ管理ではなく、構成管理とインフラストラクチャ プロビジョニングに重点を置いています。
アプローチ: 命令型
Ansible コードは YAML 形式で記述されており、多くの場合「Ansible Playbook」と呼ばれ、管理対象ノードで繰り返し実行するタスクのリストを保存するために使用されます。 Ansible を使用すると、これらの Playbook を実行して、必要な構成を備えたインフラストラクチャを作成できます。 Ansible はエージェントレスであり、SSH または Windows リモート管理 (WinRM) 経由で一時的に接続することでタスクを実行します。
Ansible は、インフラストラクチャとアプリケーションの構成管理の最も簡単な方法の 1 つと考えられています。 さらに、独自のモジュールやプラグインを作成して、必要に応じて既存の機能を拡張することもできます。 オンプレミス環境とクラウド環境の両方をサポートしています。
Pulumi
Pulumi は、最新の Infrastructure as Code ツールの 1 つであり、開発者第一のアプローチと優れた柔軟性で急速に市場を獲得しました。 これは、クラウド インフラストラクチャを作成、展開、管理するためのオープンソース ツールです。 コンテナ、Kubernetes クラスタ、サーバーレス機能もサポートします。
アプローチ: 宣言型
Pulumi は、構成属性でリソースを定義するだけでなく、複雑なプログラミングおよび開発テクニックを使用して、Go、C#、Java、Python、TypeScript、JavaScript などの汎用プログラミング言語でコードを作成できるため、真の IaC ツールです。 これにより、DevOps のベスト プラクティスを活用しやすくなります。
pulumi CLI、ランタイム、ライブラリ、ホスト型サービスが連携して、クラウド インフラストラクチャのプロビジョニング、更新、管理を行います。
IaC ツールの比較
IaC Tool | Terraform | AWS CloudFormation | AWS CDK | Azure Resource Manager | Google Cloud Deployment Manager | Puppet | Ansible | Pulumi |
---|---|---|---|---|---|---|---|---|
タイプ | オーケストレーション (IaC) ツール | オーケストレーション (IaC) ツール | オーケストレーション (IaC) ツール | オーケストレーション (IaC) ツール | オーケストレーション (IaC) ツール | 構成自動化/管理ツール | 構成自動化/管理ツール | オーケストレーション (IaC) ツール |
インフラストラクチャー | 不変 | 不変 | 不変 | 不変 | 不変 | 可変 | 可変 | 不変 |
ユースケース | 主要なクラウドおよびオンプレミスのインフラストラクチャのプロビジョニングと管理 | AWSインフラストラクチャのプロビジョニングと管理 | 汎用プログラミング言語を使用した AWS インフラストラクチャのプロビジョニングと管理 | Azure インフラストラクチャのプロビジョニングと管理 | Google Cloud インフラストラクチャのプロビジョニングと管理 | 主要なクラウドおよびオンプレミスのインフラストラクチャのプロビジョニングと構成 | 既存のシステムを構成し、ネットワーク デバイスの自動化をサポート | 汎用プログラミング言語を使用した、主要なクラウドおよびオンプレミスのインフラストラクチャのプロビジョニングと管理 |
アプローチ | 宣言型 | 宣言型 | 宣言型 | 宣言型 | 宣言型 | 宣言型 | 命令型 | 宣言型 |
言語サポート | HCL (HashiCorp Configuration Language) | YAML, JSON | Typescript, Javascript, Python, C#/.Net, Java, Go (実験的) | ARM Template (JSON) | Python, YAML | Puppet Code (Ruby-based DSL) | YAML Playbooks | Typescript, Javascript, Python, C#, Go (実験的) |
VMプロビジョニング、ネットワーキング、ストレージ管理 | 包括的 | 包括的 | 包括的 | 包括的 | 包括的 | 部分的 | 部分的 | 包括的 |
ライフサイクル/状態管理 | ライフサイクルを意識し、デプロイメントの状態を S3、DynamoDB、ローカルなどに保存可能 | AWS 内の状態をスタックの形式で自動的に維持 | AWS CloudFormation を通じて内部で自動的に状態を維持 | Azure の状態をテンプレートとして自動的に維持 | Google Cloud の状態を自動的に維持 | 望ましい状態は、Puppet プライマリ サーバーによって管理および維持 | インフラストラクチャの状態を追跡しない | 状態はローカル、S3、または Pulumi サービス バックエンドに保存可能 |
エージェントレス | はい | はい | はい | はい | はい | いいえ | はい | はい |
コマンドラインインターフェース | はい | はい | はい | はい | はい | はい | はい | はい |
構成のドリフト検出 | はい | はい | はい | はい | はい | はい | はい、実装可能 | はい |
変更管理 | Terraform Planの使用 | 変更セットの使用 | cdk diff の使用 | 「what-if」操作の使用 | 「--preview」フラグの使用 | エージェントベースのドリフトアラートを使用 | いいえ | Pulumi プレビューの使用 |
モジュールサポート | インフラストラクチャはモジュールを利用して再構築可能 | スタック間の参照およびスタックのネストを許可 | 複数のスタック、ネストされたスタックをすべて 1 つのプロジェクトで作成し、内部で参照可能 | 異なるパラメータを持つテンプレートを使用して複数の環境をデプロイ可能 | テンプレートはさまざまな導入環境で再利用可能 | モジュールはコードの再利用と共有可能 | プレイブックが再利用可能 | インフラは再現可能 |
自動ロールバック | いいえ | はい | はい | はい | はい | いいえ | いいえ | いいえ |
マルチクラウドサポート | はい | いいえ、AWS のみ | いいえ、AWS のみ | いいえ、Azure のみ | いいえ、GCP のみ | はい | はい | はい |
メリット | 複数のクラウドプロバイダーにわたって動作可能; 複数のクラウドサービスと外部機能を統合可能; 提案された変更をテストするための「Plan」フェーズ機能 | 他の AWS サービスと密接に統合可能; 導入失敗の自動ロールバック; AWS コンソールによる管理機能 | あらゆるプログラミング言語を使用可能な柔軟性; コードと環境の間のドリフトを検出可能 | 他の Azure サービスと緊密に統合可能; Azureコンソールから管理可能 | 他の Google Cloud サービスと緊密に統合可能; Python を使用してテンプレート内でカスタム ロジックを実行可能; Kubernetes の状態管理にも役立つ | Web UI コンソールで管理が簡単; 非常に堅牢で、ネイティブのシェル構築機能; 活発なパペットコミュニティを備えた安定した成熟したシステム | エージェントレス操作; マルチベンダー環境に対応; オープンソースとベンダーコミュニティのサポート | クラス最高の Kubernetes サポート; 組み込みのシークレット管理; あらゆるプログラミング言語を柔軟に使用可能 |
デメリット | 自動ロールバックは不可能; HCL の使用は導入を妨げる可能性 | AWS でのみ利用可能 | AWS でのみ利用可能; プログラミングの知識が必要; 機能の遅延が時々ある | Azure でのみ利用可能 | GCP でのみ利用可能; 不十分なドキュメンテーション | プルベースのシステム (エージェント)のため時間がかかる; 高度なタスクには CLI が必要; Puppet DSL の使用は少し複雑 | 大量の情報を収集すると遅い; 機能はデバイス固有の構成に合わせて調整される | 不十分なドキュメンテーション |
価格 | Cloud; Enterprise; Open-source | 無料 | 無料 | 無料 | 無料 | Enterprise; Open-source | Standard; Premium; Open-source | Team; Enterprise; Business Critical; Open-source |
サポート | HashiCorp のサポートと大規模なオープンソース コミュニティ | AWS サポートと大規模なオープンソース コミュニティ | AWS サポートとオープンソース コミュニティ | Microsoft サポートとオープンソース コミュニティ | Google Cloud サポートとオープンソース コミュニティ | Puppet サポートとオープンソース コミュニティ | Red Hat カスタマーサポートとオープンソースコミュニティ | Pulumi サポートとオープンソース コミュニティ |
結論
Infrastructure as Code は、ほぼすべてのクラウドおよびオンプレミスのインフラストラクチャ、さらには一般的にあらゆるソフトウェア開発ライフサイクルにとって不可欠な部分となっています。
そして、プロジェクトのすべての要件、制限、その他の重要な側面を考慮して、プロジェクトに適切な IaC ツールを選択することは非常に重要な作業です。 これらのツールを使用すると、インフラストラクチャの開発、プロビジョニング、管理が簡単になり、共同作業するチームにとって管理しやすくなります。
今後のブログでは、他の IaC 関連のトピックも取り上げていきたいと思います。 それでは、乞うご期待!
作成者:
Atul Anand, Fellow
JTP Co., Ltd.