ポイント: インフラストラクチャ as コード (IaC) は、コードを通じてITインフラストラクチャ管理を自動化し、一貫性のある再現可能な環境を提供します。CI/CDパイプラインと統合し、構成管理とスケーラビリティを向上させます。
- IaCは手動プロセスを減少させ、エラーを最小限に抑え、デプロイメントを迅速化します。
- 人気のツールにはTerraform、Ansible、AWS CloudFormationが含まれ、それぞれ異なる管理ニーズに適しています。
インフラストラクチャはソフトウェア開発プロセスの核心的な原則の一つであり、ソフトウェアアプリケーションの安定した運用を直接担っています。このインフラストラクチャは、サーバーやロードバランサ、ファイアウォール、データベースから複雑なコンテナクラスターまで多岐にわたります。インフラストラクチャの考慮は、プロダクション環境にとどまらず、完全な開発プロセスに広がります。これには、CI/CDプラットフォーム、ステージング環境、およびテストツールなどが含まれます。ソフトウェア製品の複雑性が増すにつれて、これらのインフラストラクチャ考慮は増加します。手動でインフラストラクチャを管理する従来のアプローチは、DevOpsベースの現代の迅速なソフトウェア開発サイクルの要求に応えるにはスケーラブルではなくなります。これが、インフラストラクチャ as コード (IaC) が今日の開発における事実上の解決策となった理由です。IaCは、スケーラブルで追跡可能な方法でインフラストラクチャの変更の増大するニーズに応えることを可能にします。
インフラストラクチャ as コードとは？
インフラストラクチャ as コード、またはIaCは、手動プロセスではなく、コードを介して定義されたインフラストラクチャをプロビジョニングおよび管理するプロセスです。インフラストラクチャがコードとして定義されることで、ユーザーは構成を簡単に編集および配布でき、インフラストラクチャの望ましい状態を確保できます。つまり、再現可能なインフラストラクチャ構成を作成できます。さらに、インフラストラクチャをコードとして定義することは、次のことも意味します：
- インフラストラクチャをバージョン管理メカニズムに簡単に統合できるため、追跡可能で監査可能なインフラストラクチャの変更を作成できます。
- インフラストラクチャ管理のための広範な自動化を導入する能力を提供します。これらすべてが、IaCがSDLCの不可欠な部分としてCI/CDパイプラインに統合されることにつながります。
- 手動のインフラストラクチャプロビジョニングと管理の必要を排除します。したがって、ユーザーはインフラストラクチャと構成の避けられない設定のドリフトを簡単に管理し、すべての環境を定義された構成内に保つことができます。
宣言型 vs 命令型 インフラストラクチャ as コード
IaCツールを扱う際、コードを書くための2つの主要なアプローチがあります。これら2つのアプローチは、宣言型と命令型です。簡単に言えば：
- 命令型アプローチは、ユーザーが変更のために取るべき正確な手順を指定でき、システムは指定された手順から逸脱しません。
- 宣言型アプローチは、本質的にユーザーが最終的な要件を定義するだけでよく、特定のツールまたはプラットフォームが定義された要件を達成するために取るべき手順を処理します。
宣言型アプローチは、インフラストラクチャを管理する際のほとんどのユースケースで好まれます。なぜなら、インフラストラクチャを管理する際により大きな柔軟性を提供するからです。Chefは命令型ツールと見なされ、Terraform、Pulumi、CloudFormation、ART、Puppetはすべて宣言型です。特に、Ansibleはほとんど宣言型でありながら命令型コマンドをサポートしています。
IaC vs IaaS
重要なのは、IaCはサービスとしてのインフラストラクチャ (IaaS) の派生物ではないということです。これらは2つの異なる概念です。
- サービスとしてのインフラストラクチャは、主要なクラウドサービスの1つであり、仮想化されたコンピューティングリソース—サーバー、ネットワークインフラストラクチャ、ストレージなど—がクラウドサービスを介して提供されます。
- インフラストラクチャ as コードは、インフラストラクチャをプロビジョニングおよび管理するために使用できるツールです。これは、クラウドベースのリソースのみに制限されていません。実際、IaCはオンプレミスを含むさまざまな環境に適用できます。
インフラストラクチャ as コードを使用するタイミングと方法
IaCは、よりシンプルで複雑性の少ないインフラストラクチャ要件には不要に見えるかもしれませんが、それは正確ではありません。すべてのモダンなソフトウェア開発パイプラインは、インフラストラクチャを管理するためにインフラストラクチャ as コードを使用する必要があります。さらに、IaCの利点は、実装や管理のオーバーヘッドをはるかに上回ります。
IaCの利点
ここにIaCの主な利点があります：
- シャドーITを組織内で減少させ、アプリケーション開発と並行して行われるタイムリーで効率的なインフラストラクチャの変更を可能にします。
- CI/CDプラットフォームと直接統合します。
- 追跡可能で監査可能な構成変更をもたらすバージョン管理されたインフラストラクチャと構成の変更を可能にします。
- 再現可能な構成でインフラストラクチャを容易に標準化します。
- 設定のドリフトを効果的に管理し、インフラストラクチャと構成を望ましい状態に保ちます。
- CapExやOpExを増加させることなく、インフラストラクチャ管理を容易にスケールアップする能力を持っています。IaCを使用すると、手動の時間のかかるインタラクションが不要になり、誤った構成を減らすため、CapExやOpExの支出を全体的に削減できます。
IaCを使用するタイミング
IaCを使用するタイミングがわからないですか？最も簡単な答えは、あらゆる種類のインフラストラクチャを管理する必要があるときです。しかし、正確な要件やツールに応じて、より複雑になります。厳格なインフラストラクチャ管理が必要なものもあれば、インフラストラクチャと構成管理の両方が必要なものもあります。その後、ツールに必要な機能セット、セキュリティの影響、統合などのプラットフォーム固有の質問が出てきます。その上、ユーザーは複雑なツールよりもシンプルで直接的なツールを好むため、学習曲線が影響します。以下の表は、上記のツールを理想的なユースケースに応じて分類したものを示しています。
| ユースケース | 使用すべきツール |
|---|---|
| インフラストラクチャ管理 | Terraform、Pulumi、AWS CloudFormation、Azure Resource Templates |
| インフラストラクチャ管理機能がやや制限された構成管理 | Ansible、Chef、Puppet |
| 構成管理 | CFEngine |
ほとんどのシナリオでは1つのツールでは不十分です。たとえば、Terraformは複数のクラウド環境でのインフラストラクチャ管理に優れていますが、詳細な構成が必要な場合は制限されるかもしれません。そのような状況では、ユーザーはAnsibleのようなツールを利用して必要な構成を行うことができます。同様に、ユーザーは任意のIaCツールを組み合わせて、正確な要件に応じてCI/CDパイプラインで使用することができます。(自分のCI/CDパイプラインを設定する方法を学ぶ。）
インフラストラクチャ as コードツールとプラットフォーム
IaCの大きな傘の下には、専用のインフラストラクチャ管理ツールから構成管理、オープンソースツール、プラットフォーム固有のIaCオプションまで、さまざまなツールがあります。最も人気のあるIaCツールとプラットフォームを見てみましょう。
Terraform
TerraformはマルチクラウドインフラストラクチャのリーディングIaCツールであり、Control-MとのTerraformワークフローの調整が必要なチームにとって、統合により本番デプロイパイプラインの管理されたステップとしてインフラストラクチャのプロビジョニングをスケジュールできます。プラットフォームに依存しないツールとして、Terraformは異なるプラットフォームやプロバイダーを横断して、インフラストラクチャのプロビジョニングと管理ユースケースを促進し、構成全体で望ましい状態を確保できます。
Ansible
Ansibleはクラウドとオンプレミスの環境全体で構成管理に優れており、企業レベルのスケジューリングとガバナンスが必要なチームにとって、Control-M for Ansibleワークロードオーケストレーションが、より広範なアプリケーションとデータパイプラインワークフロー内でAnsible AWXジョブを調整します。(なぜ人々がしばしばAnsibleとControl-Mを比較するかを見てみてください。）
Pulumi
Pulumiは、開発者ファーストのIaC体験を提供することを目的とした比較的新しいツールです。ユーザーに特定の言語や形式を強制する他のツールとは異なり、Pulumiはサポートされているプログラミング言語を自由に使用できるようにします。このツールはPython、TypeScript、JavaScript、Go、C#、F#をサポートし、状態はデフォルトでPulumiサービスを通じて管理されます。
Chef/Puppet
ChefとPuppetは2つの強力な構成管理ツールです。どちらも、開発パイプライン全体で構成管理および自動化機能を提供することを目的としています。
- Chefは、DevOpsプラクティスに簡単に統合できるように開発されています。
- Puppetは、プロセスの自動化をターゲットにして進化しました。今日、Puppetには構成ドリフトを特定するための自動化された組み込みウォッチャーがあります。
(PuppetのDevOpsの現状レポートを確認してください。
CFEngine
CFEngineは構成管理に特化した最も成熟したツールの1つです。基盤となるインフラストラクチャを管理する機能はありませんが、CDEngineはセキュリティの強化からコンプライアンスまで、最も複雑な構成要件にも対応できます。
AWS CloudFormation
CloudFormationは、AWSインフラストラクチャを管理するためのAWS独自のプラットフォーム特有のIaCツールです。CloudFormationはすべてのAWSサービスと深く統合されており、第一者ソリューションとして任意のAWS構成を促進できます。
Azure Resource Templates
Microsoft Azureは、JSONベースのAzure Resource Templatesを使用して、Azureプラットフォーム内でIaCプラクティスを促進します。これらのリソーステンプレートはインフラストラクチャの一貫性を確保し、あらゆる種類のリソース構成に使用できます。上記に加えて、特定のインフラストラクチャおよび構成管理タスクを対象とした専門のツールもあります：
- Packer、EC2イメージビルダー、Azureイメージビルダーは、デプロイ可能なカスタムOSイメージを作成します。
- Cloud-Initは業界標準のクロスプラットフォームクラウドインスタンス初期化ツールです。リソース（サーバー）をプロビジョニングする際にスクリプトを実行できるようにします。
- (R)?exは完全な機能を備えたインフラストラクチャ自動化フレームワークです。
(Azure DevOpsについて知ってください。
インフラストラクチャ as コードの例
AWS EC2インスタンスをプロビジョニングする簡単なシナリオを考えてみましょう。次の例では、Terraform、Ansible、およびAWS CloudFormationコードがこの要件に使用される様子を示しています。
Terraform
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 3.27"
}
}
}
provider "aws" {
access_key = "aws_access_key"
secret_key = "aws_secret_key"
// shared_credentials_file = "/Users/.aws/creds"
region = "us-west-1"
}
resource "aws_instance" "web_server" {
ami = "ami-0123456"
instance_type = "t3.small"
subnet_id = "subnet-a000111x"
vpc_security_group_ids = "sg-dfdd00011"
key_name = "web_server_test_key"
tags = {
Name = "Web_Server"
}
}
Ansible
- hosts: localhost
gather_facts: False
vars_files:
- credentials.yml
tasks:
- name: Provision EC2 Instance
ec2:
aws_access_key: "{{aws_access_key}}"
aws_secret_key: "{{aws_secret_key}}"
key_name: web_server_test_key
group: test
instance_type: t3.small
image: "ami-0123456"
wait: true
count: 1
region: us-west-1
instance_tags:
Name: Web_Server
register: ec2
AWS CloudFormation
AWSTemplateFormatVersion: "2010-09-09"
Resources:
WebInstance:
Type: AWS::EC2::Instance
Properties:
InstanceType: t3.small
ImageId: ami-0123456
KeyName: web_server_test_key
SecurityGroupIds:
- sg-dfdd00011
SubnetId: subnet-a000111x
Tags:
-
Key: Name
Value: Web_Server
実際の例: IaC for DevOps
ソフトウェア開発の文脈において、基本的な制約は、最近開発されたソフトウェアコードがデプロイされるライブ環境を正確に反映する必要があるということです。これが新しいコードが既存のコード定義と衝突しないことを保証する唯一の方法です：エラーや競合を生成し、システム全体を危うくする可能性があります。過去には、ソフトウェアデリバリーはこのようなパターンに従っていました：
- システム管理者が物理サーバーをセットアップし、オペレーティングシステムをインストールし、すべての必要なサービスパックとチューニングを施して、本番環境をサポートするメインオペレーティングライブマシンの状態を反映させます。
- 次に、データベース管理者がサポートデータベースのために同じプロセスを実行し、マシンがテストチームに引き渡されます。
- 開発者がコード/プログラムをテストマシンにコピーすることによって納品し、テストチームがいくつかの運用およびコンプライアンステストを実行します。
- 新しいコードが全プロセスを通過した後、本番の運用環境にデプロイできます。多くのケースでは、新しいコードが正しく動作しないため、追加のトラブルシューティングや再作業が必要です。
(ソフトウェアのデプロイとリリースの違いを理解してください。)ライブ環境の手動再作成は、次のような多数の可能性のある重要な人的エラーの扉を開きます：
- OSバージョン
- パッチレベル
- タイムゾーン
- その他。
ライブ環境のクローンは、ライブ環境と全く同じIaCを使用して作成されており、クローン環境で機能する場合は、ライブでも機能する絶対的な保証があります。DEV、UAT、および本番のための別々の環境を含むソフトウェアデリバリープロセスを想像してみてください。これらの初期環境がソフトウェアビルドバージョンの品質と生産準備状況を測定するために重要であることを考慮すると、プロダクション環境の厳密なミラーを持たないDEVおよびUAT環境の価値はほとんどありません。仮想化の導入により、このプロセスが迅速化され、特にライブ環境を反映するテストサーバーの作成や更新の段階が迅速化されました。しかし、プロセスは手動であり、人間が適宜機械を作成および更新しなければなりませんでした。DevOpsの導入により、これらのプロセスはさらに「アジャイル」になりました。自動化をサーバーの仮想化およびテスト段階に追加することで、人間の介入が置き換えられ、生産性と効率が向上します。要約すると：以前は、ソフトウェアデプロイメントサイクルを完了するために多くの人時間と人的リソースが必要でした（開発者、システム管理者、データベース管理者、運用テスター）。今では、開発者がすべてのタスクを完了できるようになりました：
- 開発者がアプリケーションコードと構成管理関連の指示を書き、仮想化環境やデータベース、アプライアンス、テストツール、配信ツールなどからアクションを引き起こします。
- 新しいコードの納品後、構成管理の指示が自動的にアプリケーションサーバーとデータベースインスタンスを備えた新しい仮想テスト環境を作成し、ライブ運用環境の構造を正確に反映します（これがプロセスのインフラストラクチャ as コード部分です）。
- その後、一連のツールが必要なコンプライアンステストとエラーの特定と解決を行います。新しいコードはその後、ライブIT環境へのデプロイメントの準備が整います。
迅速で追跡可能なインフラストラクチャの変更
インフラストラクチャ as コードは、現代のアプリケーション開発およびデプロイパイプラインの重要な部分となっています。これは、CI/CDプラットフォームに直接統合される迅速で追跡可能なインフラストラクチャの変更を促進することによって達成されます。インフラストラクチャ as コードは、次の両方にとって重要です：
- スケーラブルなインフラストラクチャ管理の促進
- すべての環境での設定ドリフトの効率的な管理
インフラストラクチャ as コードを始めるのは、さまざまなツールやプラットフォームが異なるユースケースを対象としているため、困難に思えるかもしれません。しかし、この障害を乗り越えれば、強力なインフラストラクチャ管理メカニズムを手に入れることができます。
関連するリーディング
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表すものではありません。