IaCの必要性
昔々、企業がソフトウェアを実行したい場合、その唯一の選択肢は、ネットワークプロバイダーに物理的な機器とインターネットアクセスを注文することでした。 これらはオンサイトのデータセンターであり、企業は予想されるトラフィックに基づいて数週間または数か月前にサーバーとネットワーク機器を注文し、オンサイトで手動でプロビジョニングする必要がありました。 これには、冷却システムを備えた物理的な場所と、設置とメンテナンス作業を実行するための数え切れないほどの時間が必要でした。
しかし、その後、他の企業のサーバーを管理できるパブリックデータセンターが登場しました。
データセンターの運用は、それ自体がビジネスとして成り立ち、クライアントにとって大きなメリットがあります。
- 費用のかかる専用サーバールームは不要
- 一般的なサーバーやネットワーク機器のリードタイムを短縮できる可能性
- データセンター事業者が取り扱うサーバ・機器の物理管理
- 貴重な資源の解放
仮想化の出現は、クラウドという別の進化をもたらしました。 パブリック(またはプライベート)クラウドでは、物理機器はクラウドベンダーのデータセンターに配置されていますが、それでも手動で処理する必要があります。 仮想サーバーは、Webインターフェイスを介して企業が利用できるようになり、数秒(最大のリソースの場合は数分)でサーバーやその他のリソースをプロビジョニングできるようになりました。 この段階では、仮想化によって非常に高速なプロビジョニングが可能になりましたが、ほとんどの操作は依然として手動でした。
最終的な開発は、IaCの概念とツールの出現によってもたらされました。 APIを介してクラウドにアクセスできるようになると、リソースのプロビジョニングと管理は、人間ではなくスクリプトと自動化ツールによって処理できるようになりました。 そのため、物理的な機器が設置されて接続されると(まだ手動操作)、すべての仮想ハードウェアリソースのプロビジョニングなど、他のすべてを自動化できます。
パブリッククラウドにプログラムでアクセスできるようになったことで、IaCが台頭しました。 IaCが登場する前は、システムエンジニアはリソースのプロビジョニングと構成のためにWebインターフェイスを手動で操作する必要がありました。 IaCでは、リソースのプロビジョニングと構成はスクリプトで記述され、パブリッククラウドAPIと通信するツールによって読み取られ、現実が望ましい状態と一致することを確認します。
IaCの利点
前述したように、IaC ツールはスクリプトからの入力を使用します。これらのスクリプトは人間によって記述され、特定のクラウドリソースの望ましい状態を記述します。 ツールは、API を介してクラウド ベンダーと通信し、リソースを作成、更新、または削除して、現実が入力スクリプトに記述された望ましい状態と一致するようにします。 手動のプロビジョニングと構成と比較して、IaC は信頼できる唯一の情報源 (入力スクリプト) を提供するため、ほとんどの人為的エラーが排除されます。
IaC スクリプトの実行は反復可能な操作であり、毎回まったく同じ結果が生成されます。 これは、次のような多くの点で役立ちます。
- 同一のワークロードをさまざまな場所や異なるプロジェクトにデプロイする
- 別個ではあるが同一(またはほぼ同一)の環境(ステージング、本番、テストなど)を作成する
- IaCスクリプトと本番環境の最後のバックアップから新しい同一の環境をすばやく作成することで、ディザスタリカバリを実行します
IaC スクリプトは git リポジトリに保存でき、インフラストラクチャの履歴を取得できます。 おまけとして、スクリプトは単なるテキストであるため、バージョンを比較して、何が追加、変更、または削除されたかを確認できます。
もう 1 つの利点は、IaC を使用すると、経験の浅いシステム管理者や技術者以外の人が、技術的な知識がなくてもワークロード全体を作成できることです。 クラウド アカウントを適切に構成すると、アクセス許可が制限されているユーザーが、リソースを直接作成する権限を持っていない場合でも、IaC ツールを使用してこのようなワークロードを作成できるようにすることもできます。 また、追加のツールやテンプレートを活用して、セキュリティポリシーを早期に実装し、IaCスタックをインスタンス化する人によるセキュリティの漏洩や設定ミスの可能性を制限することもできます。
正確な再現性に加えて、手動操作に対するIaCの最も優れた利点の1つは、スケーラブルであることです。 実際、IaC スクリプトを一度記述するだけで、ワークロードを何度でも、ほぼ瞬時にインスタンス化できます。 最後に、IaC スクリプトに適切なアクセス許可を作成するためにより多くの時間を費やすことで、ロールとリソースに付与するアクセス許可が多すぎる手動作業の一般的な欠点を回避できます。
はじめに
通常、現在手動で実行している一部の操作を自動化する必要があります。 そのため、最初のステップは、ワークロードに必要なインフラストラクチャを構築するために必要な手動の手順を文書化することです。 これらは、IaC を使用して自動化する手順です。
次に、IaCソフトウェアを選択する必要があります。 Amazon Web Servicesは CloudFormation、Microsoft Azureは Azure Resource Manager、Google Cloud PlatformはGoogle Cloud デプロイメントマネージャーの3つの主要なクラウドプロバイダーしかないため、これは難しい選択ではありません。 ベンダーに依存しない最もよく知られているオプションは Terraformで、上記の3つのクラウドベンダーだけでなく、さらに多くのクラウドベンダーをサポートしています。
次に、選択した IaC ツール用のスクリプトをいくつか記述して、文書化した手動の手順を再現する必要があります。 通常、これらをテストしながら作業を進めることをお勧めします。 言い換えれば、IaC コードを少し記述し、デプロイし、テストし、問題がなければ、次のコードに移ります。 すべてを一度に記述すると、コードに大きな欠陥が発生し、何時間も作業した後にのみ発見される可能性があり、スクリプトのかなりの部分を書き直さなければならない可能性があります。
シフトレフト
さらに、シフトレフトのトピックは引き続きトレンドになっています。 これは基本的に、できるだけ早くテストを開始し、(問題が発生してから検出して解決するのではなく)問題の防止に集中することを意味します。 その結果、全体的な品質とセキュリティが向上するという考え方です。
理想的には、この シフトレフトは 、可能な限り自動化を活用する必要があります。 実際、セキュリティやコンプライアンスなど、IaC スクリプトの記述の特定の側面を自動化するために利用できるさまざまなツールがあります。 これらのツールは、デプロイメントの前にコードをスキャンして、構成ミス、過度に寛容な設定、既知の脆弱性などの問題の発生を減らします。 これに関するいくつかのユースケース は、こちらで閲覧できます 。
一元化されたチームの必要性
IaCを適切に使用するためには、IaCスクリプトを記述する人は、使用されているクラウドプラットフォームに関する深い知識を持っている必要があります。 したがって、IaC 作業の最も重要な部分がシニア DevOps エンジニアによって行われるようにすることをお勧めします。
通常、IaC の取り組みを主導するシニア DevOps エンジニア (または少なくとも 1 人) のチームを持つことをお勧めします。 このチームは、ベストプラクティスとセキュリティに集中できるため、より多くのジュニアエンジニアが従うべき青写真を提供します。 また、組織内の IaC スクリプト間で再利用できる汎用モジュールを作成できるため、事前に吟味されたビルディング ブロックをより多くの経験の浅いエンジニアがすぐに利用できます。
厳重なセキュリティが重要であり、その可能性が高い場合、このチームは公開されているモジュールやソフトウェアの審査も担当できます。 いくつかのIaCモジュールをオンラインで見つけるのは非常に簡単です。Terraformには、これらの公式 リポジトリ もあります。 ただし、このような公開されているモジュールは、組織またはプロジェクト内で適用されるセキュリティ標準に準拠していない可能性があります。 そのため、IaC チームが吟味したモジュールのみを使用するようにすることが重要です。
さらに、SecOps チームが DevOps チームと一緒に作業することをお勧めします。 このような協力により、プロジェクトの早い段階でセキュリティの観点からDevOpsプロセスを最適化できます。 運用デプロイメント後に検出されたエラーは、特に顧客関係の観点から、非常にコストがかかる可能性があります。 プロセスの早い段階で高品質を確保することは、このような災害を回避するのに大いに役立ちます。
結論
IaCはごく最近の開発ですが、今日ではクラウドリソースを必要とする組織のプロビジョニング戦略の一部であり、少なくともチームに含めるかどうかを評価する必要があります。 組織の規模に関係なく、ワークロードの少なくとも一部を IaC で管理したいと考えるでしょう。
Feedback