インフラストラクチャ・アズ・コード (IaC) を 1 つの記事で理解する

Infrastructure-as-Code (IaC) とは、手動のプロセスではなくコードを使用してインフラストラクチャを定義および管理することを意味します。さらに重要なのは、IaC はソフトウェア エンジニアリングの原則と手法をクラウド インフラストラクチャに導入することです。この記事では、IaC の基本と関連する環境の設定方法について説明します。

IaC の紹介

IaC 以前は、インフラストラクチャは、単純なユーザー インターフェイス、バッチ スクリプト、構成管理ツールなどの方法でプロビジョニングされていました (場合によっては現在もそうです)。これらの方法は、今日のクラウド コンピューティングには適していません。

同様に、今日のいわゆる IaC の多くは、実際にはかなり「テキストとしてのインフラストラクチャ」に近いものになっています。構造化テキストで記述されたインフラストラクチャであるため、繰り返し可能であり、バージョン管理が可能です。しかし、アプリケーション コードと連携する必要があるソフトウェア エンジニアリングを実装する場合には、不十分です。たとえば、標準の開発ツール、テスト フレームワーク、パッケージ管理はサポートされていません。

真の IaC ソリューションには、標準的なソフトウェア エンジニアリング実装計画とツールを適用できるように、クラウド インフラストラクチャ専用に設計されたプラットフォームを使用する必要があります。

IaC が重要なのはなぜですか?

IaC が重要な理由は主に次の 3 つです。

1 つ目は、現在企業がクラウドに全面的に移行していることです。オンプレミスのデータセンターからクラウドに移行するワークロードはますます増えており、この傾向は今後も続くでしょう。ただし、クラウド コンピューティング自体は、信頼性が高くスケーラブルなインフラストラクチャを確保および維持するための万能薬ではありません。物理データセンターと同様に、クラウド インフラストラクチャには一貫性がなく、文書化が不十分なスクリプト セットが存在する可能性があります。 IaC は実証済みのエンジニアリング手法を強制するため、混沌に秩序をもたらします。

第二に、一般の人々がクラウドを使用する方法はより複雑です。ビジネス ユーザーは、収益を向上させるために、設備、モデル、作業方法を変更しようとします。 IaC は、単純な CapEx と OpEx の比較ではなく、バージョン管理やテストなど、エンジニアリング ライフサイクルを構成するすべての要素を統合して、クラウドが提供できるすべての価値を引き出す方法についてです。エンジニアリング手法を活用してクラウド コンピューティングの可能性を最大限に活用し、イノベーションをより良く、より速く推進して、企業のビジネスを推進することができます。

3 つ目は、クラウド インフラストラクチャの管理の負荷が増加していることです。利用可能なクラウド サービスの種類は年々増加しており、ますます多くの企業が最新のクラウド インフラストラクチャ (コンテナーやサーバーレス インフラストラクチャなど) を採用しています。これらの機能は、多くの場合、疎結合で相互依存する多くのコンポーネントで構成されているため、エンジニアが管理しなければならないクラウド リソースの数は驚くべき速度で増加します。これは、ビジネス ユーザーがクラウドからより多くのメリットを得てビジネスの成長を促進することを意味するため、もちろん良いことですが、結果としてクラウド リソースの複雑さと規模が増大しています。

たとえば、クラウドのメリットを享受する方法の 1 つは、クラウド プロバイダーが提供するサービスの増加を活用することです。これらのサービスはイノベーションを推進し、ビジネスの進歩を加速します。しかし同時に、新しいサービスごとに新しい API が導入され、インフラストラクチャの複雑さが増します。

クラウド リソースの規模と複雑さが増すにつれて、最新の IaC アプローチが必要になります。エンジニアがインフラストラクチャを構築、展開、管理するのに役立ちます。エンジニアが 1 ～ 10 個のリソースを管理している場合は、単純なポイント アンド クリックで十分です。 10 ～ 100 個のリソースを管理する場合は、「テキストとしてのインフラストラクチャ」または従来の IaC ツールが依然として役立つ場合があります。

しかし、リソースの数が数百または数千に達するとどうなるでしょうか?これは今では珍しいことではありません!何よりも素晴らしいのは、これらの何千ものリソースが月に一度ではなく、1 日に複数回更新されることです。これらすべてを管理する最善の方法は、アプリケーション コードに使用するのと同じソフトウェア エンジニアリングのプラクティスとツールを導入することです。

次の質問について考えてみましょう。

（1）ビジネスをサポートし、競争上の優位性を生み出すために、インフラストラクチャを迅速に拡張、変更、進化させるにはどうすればよいですか？

（2）クラウドインフラストラクチャとその変更に対する可視性をどのように維持していますか？

（３）セキュリティと信頼性を確保するためのポリシーとデータガードレールをどのように開発するか？

（4）より優れたコラボレーションとプロセスを通じて、チームがインフラストラクチャを構築、展開、管理できるように、最も科学的にチームを強化するにはどうすればよいでしょうか？

上記の問題に対処するには、最新の IaC アプローチが必要です。最新の IaC アプローチは、クラウド コンピューティングの可能性を最大限に活用する方法です。

IaC の使用に関する重要な考慮事項

IaC プラットフォームの選択は非常に重要です。ユーザーが既存の標準ソフトウェア エンジニアリング ツールと操作を使用する場合は、選択時に次の機能を考慮する必要があります。

1. 標準言語

標準言語の優れたサポートにより、開発者は TypeScript、Go、Python、C# などの同じアプリケーション コード言語を使用してインフラストラクチャを簡単に定義および構成できます。多くの従来の IaC ツールは独自のドメイン固有言語 (DSL) を使用しているため、開発者は一般的なプログラミング機能が不足していることに気付くことが多く、問題が発生する可能性があります。

エンジニアは、選択したプラットフォーム上で、厳密に型指定されたインストルメント化された構成を簡単に作成し、ループ、定数、関数など、これまで常に頼りにしてきた機能を使用できる必要があります。また、標準言語を使用するもう 1 つの利点は、開発者がすでにその言語に精通しており、すぐにコーディングを開始できることです。 DSL の特性と制限を再度学習する必要がある場合、それはおそらく時間がかかり、イライラする作業になるでしょう。

2. 標準開発ツール

標準プログラミング言語を使用するということは、開発者が IDE などの標準開発ツールも使用できることを意味します。 1 つの利点は、開発者が慣れ親しんだ環境で作業できるという親しみやすさです。もう 1 つは、開発者がコードを簡単に作成、デバッグ、テスト、デプロイできる環境で活躍できることです。

3. テストフレームワーク

アプリケーションと同様に、インフラストラクチャを徹底的にテストすることが重要です。優れた IaC プラットフォームは、標準のテスト フレームワークをサポートし、チームが実行するテストの種類を拡張できるようにもする必要があります。

標準的な操作および保守テストは、受け入れテストに重点を置いています。つまり、運用チームはクラウドでインフラストラクチャを起動し、すべてが正常であるかどうかをテストします。もちろん、正しく起動しない場合は、運用チームがそれを破棄して再展開する必要があります。しかし、これは最適なアプローチではありません。なぜなら、チームの反応の速さによっては、おそらく起こるはずのなかったことが起こる可能性があるからです。優れた IaC プラットフォームは、展開前と展開中に頻繁にテストを行うことで、チームが「リスクを転嫁」できるようにする必要があります。上記の手順がまだ実行されていない場合、チームは IaC プラットフォームを使用して次の種類のテストを実行できる必要があります。

（１）ユニットテスト

ユニット テストは、インフラストラクチャの動作を個別に評価します。データベースなどの外部依存関係は、リソースの構成と応答性をチェックするためにモックに置き換えられます。クラウド サービス プロバイダーからの応答は十分に知られており、テスト済みであるため、シミュレーションが使用されます。テスターは、いくつかのパラメータが与えられた場合にサプライヤーがどのように応答するかをすでに知っています。

ユニット テストはプロセス外呼び出しなしでメモリ内で実行されるため、非常に高速になります。開発中の迅速なフィードバック ループに使用します。ユニット テストは、開発者がインフラストラクチャ ライフサイクルの早い段階で問題を修正するのに非常に役立ちます。

（２）統合テスト

統合テスト (ブラック ボックス テストとも呼ばれます) は単体テストの後に行われ、異なるアプローチを採用します。統合テストでは、クラウド リソースをデプロイし、その実際の動作を検証します (もちろんステージング環境で)。ステージング環境は、実稼働環境をシミュレートする短期的な環境です。通常は単純で、テスト対象のコードの第 1 レベルの依存関係のみが含まれます。統合テストが完了したら、一時的なインフラストラクチャを破棄できます。

（３）安全性試験

セキュリティ テストは、最後の最後まで残されたり、「完成した」コードとしてセキュリティ チームに渡されたりして、開発プロセス全体から除外されてしまうことがよくあります。実はこの考えは「死を求めている」とも言えるのです。

最新の IaC プラットフォームでは、機密性の高い構成データを暗号化し、キーのローテーションなどの標準的なセキュリティ対策を有効にする必要があります。また、プラットフォームが状態メタデータを暗号化し、機密値がプレーンテキストで公開されないよう徹底していることを確認します。また、プラットフォームは、クラウド プロバイダーが提供するセキュリティ サービスと簡単かつシームレスに統合される必要があります。

さらに、他の種類のテストと同様に、IaC プラットフォームは、開発者が独自に作成したセキュリティ テストをワークフローに追加できるように支援する必要があります。コードの単体テストを早期に行う必要があるのと同様に、セキュリティの問題を早期に発見するためのテストも行う必要があります。これらのテストは CI/CD パイプラインの一部であるため、インフラストラクチャはリリース前に脆弱性がないか徹底的にテストされます。

4. 再利用可能なコンポーネントを作成する

再利用可能なコンポーネントとは、開発者が単一のコンポーネントからより高レベルのリソースを構築できることを意味します。これらを使用することで、エンジニアは他の場所で再利用できる便利な抽象化を作成できます。これらのコンポーネントは、社内のベストプラクティスを使用して記述し、社内およびコミュニティと共有できます。再利用可能なコンポーネントを使用すると、繰り返し可能で信頼性の高いインフラストラクチャを作成できます。したがって、検討しているプラ​​ットフォームがこれらのコンポーネントを簡単に作成できるかどうかを慎重に調査してください。

5. 標準パッケージマネージャー

再利用可能なコンポーネントを作成する場合は、簡単に共有できるようにパッケージ化する方法が必要です。標準ツールの使用に加えて、標準パッケージ マネージャーのサポートも必要です。たとえば、開発者はコンポーネントを GitHub リポジトリに配置し、NPM 経由で公開したい場合があります。そうすれば、IaC プラットフォームでこれを簡単に実行できるはずです。

6. 行動を可視化する

すべてのインフラストラクチャ リソースの集中的な可視性と、時間の経過に伴う変更の履歴ビューは、説明責任とコラボレーションを促進するために重要です。開発者が選択するプラットフォームは、ログ監査と、クラウド リソースの変更時の差分の可視性を提供することで、インフラストラクチャ全体の可視性を提供する必要があります (チームが Git などのコラボレーション ツールを使用する方法と同様)。さらに、プラットフォームは、どのユーザーがインフラストラクチャにアクセスして変更を加えることができるかをきめ細かく制御する機能を提供する必要があります。

7. 複数のクラウドプロバイダーをサポートする

すべての企業が複数のクラウドベンダーの利用を望んでいるわけではありませんが、検討すべき事項です。開発者が複数のオプションを保持したい場合は、単一のクラウド ベンダーに限定されない IaC プラットフォームを選択してください。

8. ポリシーをコードとして

IaC で見落とされがちなもう 1 つの側面は、コードとしてのポリシーです。最新の IaC プラットフォームでは、インフラストラクチャの場合と同様に、開発者がソフトウェア エンジニアリングの原則と手法を独自の戦略に適用できる必要があります。ポリシーをコードとして扱うことの利点は、インフラストラクチャをコードとして扱うことの利点とほぼ同じです。ポリシーは、セキュリティ、コンプライアンス、コスト管理の観点から、組織のクラウド ガバナンスを継続的に強化します。ポリシーは明確で、標準の言語とツールを使用して記述でき、バージョン管理、テスト、そして最終的にはすべてのインフラストラクチャが会社のベストプラクティスに準拠するように CI/CD パイプラインに統合できます。

インフラストラクチャ・アズ・コード・ツール

多くのオープンソース IaC ツールを使用して、リソースの割り当て、展開、管理を自動化できます。使用にあたっての鍵は、自分に合ったインフラストラクチャ自動化ツールを正しく選択することです。一般的な IaC カテゴリとツールは次のとおりです。

Terraform を使用したコードとしてのインフラストラクチャの実装

Terraform は、開発者がインフラストラクチャを宣言型構成ファイルとして記述できるようにする、プラットフォームに依存しないオープンソース ツールです。 Terraform は幅広いクラウド プロバイダーをサポートしているため、開発者は AWS、Google Cloud、Azure、Oracle などの主流のクラウド プラットフォームでリソースを構成できます。

Terraform を使用すると、エンジニアはインフラストラクチャ リソースの構成を迅速に拡張できます。デプロイメント プロセスを自動化すると、組織内の開発チームの生産性が向上し、デプロイメント インフラストラクチャに変更を加えることができるようになります。また、Terraform は集中型インフラストラクチャ チームへの依存を軽減し、開発チームの作業速度を速め、ビジネス機能のサイクル タイムを短縮するのに役立ちます。

Terraform を使用してリソースを構成するには、次のコマンドを使用します。

Terraform モジュールを使用した再利用可能なインフラストラクチャの作成

Terraform モジュールの概念はシンプルです。開発者はモジュール内にコードを記述し、コードベース全体の複数の場所でそれを再利用できます。 Terraform モジュールを使用すると、わずか数行のコードでインフラストラクチャを迅速に構築できます。インフラストラクチャが拡大し続けると、開発者はさまざまな環境 (開発やステージングなど) に同様のリソースを展開する必要があり、同じコードを何度もコピーして貼り付けたいと思う人は誰もいません。

Terraform モジュールは読みやすくなります。開発者が Terraform ファイルにハードコードしないベストプラクティスを適用します。モジュールをさまざまなチームで再利用し、さまざまなインスタンスに適応させるには、モジュールを構成可能にする必要があります。また、環境の複数のリソースに追加のパラメータを渡す機能もあります。 Terraform は、十分にテストされ、完全に文書化された集中型モジュールを備えているため、非常に信頼性が高いです。

ベストプラクティスとしては、インフラストラクチャを再利用可能なモジュールとして考え始める必要があります。 Terraform モジュールは、コードの再利用を促進し、重複を回避し、組織内でのモジュールの共有に役立ちます。これにより、開発者は集中化された再利用可能なモジュールの品質を向上させるために、より多くの時間と労力を費やすことができます。

サンプルコード:

以下は、Terraform モジュールを使用してさまざまな環境で AWS S3 バケットを作成するために必要な手順です。まず、AWS を使用して必要なリソースとやり取りします。次のコードは AWS プロバイダーを構成します。

 1 テラフォーム {
 2 つの必須プロバイダー {
 3 AWS = {
 4 ソース = "hashicorp/aws"
 5 バージョン = "~> 4.9"
 6 }
 7 }
 8 }
 9
 10 プロバイダー「aws」{
 11 リージョン = "us-east-1"
 12 }

次に、S3 バケット リソースを構成するための Terraform モジュールを作成します。

 1 つのリソース "aws_s3_bucket" "s3-bucket" {
 2 バケット = var.bucket
 3 ポリシー = var.policy != null ? var.policy: null です
4 タグ = merge(var.tags, { Name = "${var.bucket}-bucket" })
 5
 6 サーバー側暗号化構成 {
 7 ルール {
 8 デフォルトでサーバー側の暗号化を適用する {
 9 sse_algorithm = "AES256"
 10 }
 11 }
 12 }
 13

 14 動的「ライフサイクルルール」{
 15 for_each = var.expire-days > 0 ? [変数有効期限] : []
 16 コンテンツ {
 17 id = "期限切れ"
 18 有効 = 真
19 有効期限
20 日 = var.expire-days
 21 }
 22 }
 23 }
 24 }

左右にスワイプして完全なコードを表示します

このモジュールは、バケット、ポリシー、有効期限、タグなどのさまざまなパラメータをサポートしています。

 1 変数「バケット」{
 2 説明 = "S3 バケット名"
 3 タイプ = 文字列
4 }
 5
 6 変数「ポリシー」{
 7 description = "適用するオプションの S3 バケットポリシー。有効な JSON 文字列である必要があります"
 8 タイプ = 文字列
9 デフォルト = null
 10 }
 11
 12 変数「有効期限」{
 13 説明 = "正の数に設定すると、指定された日数後にオブジェクトを期限切れにするライフサイクル ポリシーがバケットに添付されます"
 14 タイプ = 番号
15 デフォルト = 0
 16 }
 17
 18 変数「タグ」{
 19 description = "すべてのリソースに適用される共通タグ"
 20 タイプ = マップ(任意)
 21}

左右にスワイプして完全なコードを表示します

再利用可能な S3 モジュールを作成したので、さまざまな環境 (dev や live など) からモジュールを呼び出して、必要な変数を渡すことができるようになりました。

 1 モジュール「dev-dzone-bucket」{
 2 ソース = "../modules/s3-bucket"
 3 バケット = "dev-dzone-iac-bucket"
 4 ポリシー = null
有効期限5日 = 7
 6 タグ = local.tags
 7 }
 8
 9 モジュール「live-dzone-bucket」{
 10 ソース = "../modules/s3-bucket"
 11 バケット = "live-dzone-iac-bucket"
 12 ポリシー = null
有効期限13日 = 14
 14 タグ = local.tags
 15 }

左右にスワイプして完全なコードを表示します

Terraform プロジェクト内のファイルレイアウトは次の図のようになり、AWS リソースを含む「terraform-modules」(つまり、Terraform モジュール) の下に開発環境と本番環境用の別々のフォルダーがあります。

IaC を有効にするためのチェックリスト

最新の IaC プラットフォームをスタートアップ企業や、グリーンフィールド ソフトウェア プロジェクトを多数抱える企業に導入することは、それほど難しいことではないかもしれません。しかし、ほとんどの企業にとって、それは簡単な作業ではありません。規模の大小を問わず、多くの企業では、クラウド プロバイダーが提供するシンプルなコンソールを通じて、すでに多くの既存インフラストラクチャを構築しています。多くの新しいプロジェクトは、このようにして簡単に開始されます。ある日、運用エンジニアは、新しいプロジェクトが本番環境のインフラストラクチャになっていることに突然気づきます。より「公式」なものにするために、運用チームは、一般的なタスクを実行する場合にどのボタンをクリックすればよいかを詳細に記述したランブックまたは wiki を作成します。また、1 人か 2 人しか理解できない Bash または PowerShell スクリプトに囲まれていることもよくあります。このような状況に直面した場合、どうすればよいでしょうか?

（１）冷静でいること

変化は時には恐ろしいものであるということを理解しなければなりません。インフラに触れると考えるだけで倒れてしまいそうな気分になる人も多い。彼らはそれが複雑すぎると考えており、これがどのように機能するかを理解していません。したがって、自信を持つことでのみ問題を解決できるのです。

（２）「完璧」という概念を正しく定義する

開発者は、ツールや方法論の評価を始める前に、会社にとって「完璧」が何を意味するかを理解する必要があります。開発者が使用するツールに関係なく、特定の仮定が立てられます。これらを理解することによってのみ、目標を達成することができます。グループによる意思決定は、企業のクラウド インフラストラクチャのビジネス目標を適切に策定する 1 つの方法です。

（３）評価ツールの選択

上記の重要なポイントを考慮した後、最適なプラットフォームの選択肢をいくつかに絞り込んで評価します。開発者は、プラットフォームが仕事の要件を満たしているかどうかをテストすることを目的とした小さなプロジェクトを設計できます。

（４）既存インフラへの導入

ツールを選択したら、既存のインフラストラクチャをインポートしてみます。開発者が適切なプラットフォームを選択した場合、このステップは簡単に実行できるはずです。

（５）既存のエンジニアリング実施計画との統合

インフラストラクチャ コードが継続的デリバリー パイプラインに統合されている場合は、アプリケーション コードと同じベスト プラクティスを確立し始めることができます。

（6）小さく始める

何か問題が発生してもビジネスに影響が及ばないように、新しいサービスを構築するか、重要でないサービスから始めます。プロジェクトを選択し、その重要性と価値をできるだけ早く確認し、繰り返します。

結論は

最新の IaC は、クラウドの複雑さを軽減し、クラウドの可能性を最大限に引き出してイノベーションを推進する最良の方法です。適切なプラットフォームを選択し、最新の IaC を使用することで、開発者は標準的なソフトウェア エンジニアリングのプラクティスとツールをインフラストラクチャに適用できます。一般的には以下のようなメリットが得られます。

1. イノベーション、スピード、俊敏性の推進

最新の IaC を使用すると、チームは最新のソフトウェア開発で使用されるのと同じ操作、厳格なテスト、自動化をクラウド インフラストラクチャに適用できるため、リリースの速度と信頼性が向上し、企業は顧客のフィードバックに迅速に対応し、タイムリーに更新を行うことができます。

2. インフラリスクの軽減

IaC では、開発者が標準のテスト フレームワークを使用できるため、「リスクが移転」されます。早期かつ適切で完全なテストは、CI/CD パイプラインだけでなく開発プロセスの一部にもなります。ポリシーとセキュリティ要件はコードに埋め込まれているため、すべての展開でコンプライアンスとセキュリティが自動的にテストされます。

3. 連携を強化する

最新の IaC プラットフォームは標準のツールと言語を使用し、インフラストラクチャ、アプリケーション開発、セキュリティ チーム間のサイロを解消できます。共有されたプラクティスとツールを使用すると、チーム間のコラボレーションが促進されます。

参考リンク: https://dzone.com/refcardz/getting-started-with-iac