インフラストラクチャ・アズ・コードから環境・アズ・コードへの進化

GitOps を使用して環境を起動すると、一貫性、バージョン管理、速度など、開発チームに多くのメリットがもたらされます。

『How We Evolved from IaC to Environments as Code』からの翻訳。著者の Edan Evantal は Quali の CTO です。 Edan Evantal は、Quali のインフラストラクチャ自動化および環境配信プラットフォームのすべての製品エンジニアリングを担当しています。 Quali に入社する前、Edan は Matrix IT および Sibam Ltd でエンジニアリング管理職を務めていました。ハイテク業界で 18 年以上の経験があります...

長年にわたり、当社のプラットフォームを構築し、当社の製品がサポートする他の DevOps およびプラットフォーム エンジニアと協力する中で、アプリケーション インフラストラクチャの進化によって、本来提供されるはずだった自動化が破壊されている様子を目の当たりにしてきました。

Infrastructure as Code (IaC) ツールは、クラウド サービスの提供を定義および自動化する上で非常に重要です。開発チームのニーズがこの範囲を超えて拡大すると、自動化が機能しなくなることがよくあります。

理由は2つあります。

• IaC ツールは、環境の真実のソースとしてではなく、速度と自動化を目的として設計されています。大規模なチームでは、インフラストラクチャを大規模に活用したり、コードの変更によってアプリケーションのパフォーマンスにどのような影響が出るかを把握したりすることが難しい場合があります。
• IaC ツール間の非互換性。アプリケーションは、さまざまなテクノロジーを使用して定義された複雑なインフラストラクチャにますます依存するようになり、ツールのニュアンスを調整するために手動のオーケストレーションが必要になります。

開発者は、インフラストラクチャ自動化機能とアプリケーションのニーズの現実とのギャップに直面しています。その結果、速度が低下し、インフラストラクチャが管理されていない、または誤って構成されているリスクが増大します。

私たちは、このギャップを埋めるために何ができるかを自問し、次のような単純な疑問にたどり着きました。

インフラストラクチャの範囲や、インフラストラクチャを定義するために使用される IaC ツールに関係なく、任意の環境をコードとして起動できるとしたらどうでしょうか?

Git で環境をコードとして定義する

環境をコードとして定義するには、まず、DevOps が理解しやすく、自動化されたマシンが読み取りやすい形式で定義する必要があります。

Torque プラットフォームを使用して、Git リポジトリに接続し、そこに定義されている IaC モジュールを検出し、リソース構成をプラットフォームによって自動的に生成された新しい YAML にパッケージ化します。

そこから、環境の起動時に生成されるインフラストラクチャ コンポーネント、パラメーター、依存関係、メタデータ、認証、および出力を含めるように、任意の YAML コードを変更することができます。

以下は YAML スニペットの例です。

 kind: environment environment_name: "Workstation Staging A" description: "EC2 workstation for staging workloads" state: inactive owner_email: "[email protected]" blueprint: name: "test-workstation" repository_name: "cloud-native-application" branch: "main" commit: "536955389cd4ecbd1b8895c4a1093fe14a809b65" inputs: service-account: "sa" agent: "review3" grains: create-ec2: source: commit: "697d1" specs: instance_type: "t2.large" ami: "ami-0c55b159ertafe1f0" security_groups: ["sg-0246e9ddc2b2f23f4"] post-deployment: scripts: ["./configure-environment.sh", "./deploy-application.sh"]

これには、環境に必要なすべてのメタデータの単一の定義が構造化された形式で含まれています。

簡単に言えば、既存のインフラストラクチャをコードとして活用して、環境をコードとして定義します。

GitOpsを使用してアプリケーション環境を起動する

お客様のニーズを満たすには、この定義を運用可能にする必要があります。

私たちの最初の答えは、セルフサービス ポータルに頼ることでした。当社のプラットフォームの管理者がこれらの YAML ファイル (環境の「ブループリント」と呼びます) を作成する場合、それを「公開」するオプションがあります。これにより、プラットフォーム内のセルフサービス カタログに環境が追加され、エンド ユーザー権限を持つユーザーがオンデマンドで環境を起動できるようになります。環境を開発者ツール、CI/CD、または社内開発者ポータルに統合している場合は、新しいブループリントの公開もそれらのツールを通じてアクセスできるようになります。

GitOps を採用するチームをサポートするには、公開されたブループリントを日常のワークフローに統合する必要があります。

この新しい YAML ファイルを、IaC モジュールが見つかった元のリポジトリに保存することで、GitOps で環境定義にアクセスできるようになります。実際には、リポジトリにアクセスできるユーザーに環境定義を「公開」します。

開発者は 1 つのコマンドで完全な環境を起動できるようになりました。

このアプローチには、いくつかの追加の利点があります。

• バージョン管理: アプリケーション コードと同様に、環境もバージョン管理して、すべての変更を追跡し、必要に応じてロールバックできるようにすることができます。
• 一貫性: この定義を使用して環境を毎回一貫してプロビジョニングすると、「自分のマシンでは動作する」という問題が解消されます。
• スピード: 開発者はコードをコミットするだけで環境をプロビジョニングできます。これは開発者にとって慣れ親しんだ操作であるため、他のチームの支援なしに開発、テスト、または本番環境のニーズに迅速に対応できます。
• コラボレーションとガバナンス: 環境の共通定義を作成することで、IaC だけでは簡単に実現できないコラボレーションの基盤が築かれます。
• 運用効率: プロビジョニング プロセスを自動化すると、冗長な手作業 (および疲労) が減り、DevOps エンジニアはより価値のあるタスクを引き受けることができます。

プラットフォーム エンジニアリングでは、1 秒 1 秒が貴重であり、すべてのリソースが重要です。インフラストラクチャが複雑になるにつれて、環境をコードとして管理することが、現代の DevOps 組織の成熟における次のステップになります。