Terraform, Ansible, GitLabを使用してIaCプラットフォームの実装

多くの環境にインフラストラクチャーを作成する際に、標準化と効果的なモニタリングを保証しながら、これらの環境を安全にプロビジョニングする必要があります。これを実現するために、環境がコードとしてプロビジョニングされる不変なインフラストラクチャーの取り組み方法を採用することが重要です。

この記事の目的は、GitLabの構造を利用してテンプレートと標準を強制し、Terraformを使用してサーバー間で標準を適用および維持し、Ansibleを使用してソフトウェアのプロビジョニングと設定を行い、リポジトリ間で共有されるロールモデルを使用する方法を示すことです。Terraformを使用してマシンの状態管理を行うために、MinIOを使用しています。なぜなら、この実装を場内で行うことができるからです。

アーキテクチャ設計

ステップ1

プロセスは、標準化された課題を提出し、使用するスタックモデル、ファイアウォールのアクセス権限が必要か否か、新しいセットアップかもしくはリソースのアップグレードだけかどうかを指定することから始まります。

ステップ2

オペレータは課題を確認し、プロセスを開始します。すべての会話と時間の使用は、課題内で記録されます。

ステップ3

新しいプロジェクトがGitLabで作成され、作成されるインフラストラクチャーモデルに基づいています。このプロジェクトはGitLab内の適切なグループに配置され、標準化されたインフラストラクチャー作成のために必要な環境変数を継承します。

ステップ4

プロジェクトを作成する際には、課題(KVM、VMware)で指定された環境に割り当てられるインフラストラクチャーのIPを指定するだけです。Terraformで計画を立てた後、必要なリソースを作成します。必要であればラベルを追加し、Veeamによるバックアップをラベルポリシーに基づいて行います。完了後、作成されたインフラストラクチャーの状態はバケットに格納されます。

ステップ5

次のステップで、すべてのサーバーに対する標準的なタスクを実行します。例えば、识別、パッケージの更新、必要なユーティリティのインストール、Zabbixにホストを登録してオペレーティングシステムとスタックの基本的な監視を行います。リソースグループに応じて、責任のあるチームに適切なアクセスキーを割り当てます。たとえば、DBアドミンはデータベースサーバーのアクセスキーを受け取ります。

ステップ6

選択したモデルに基づいて、すべてのスタックのインストールと構成プロセスが行われます。同様に、必要な場合はユーザーを作成し、Vaultに認証情報を登録します。

ステップ7

新しい環境でアプリケーションが実行中であるため、各スタックに対して特定の監視を行うことができ、Consulに新しいサーバーを登録します。その後、Prometheusは情報を集める必要がある場所を特定します。各スタックには既に監視ダッシュボードが設定されていて、プロジェクト名によってだけ異なります。

ステップ8

新しいインフラストラクチャーは、要求者に提供されます。データベースの場合、Vaultに直接資格情報が提供されます。

プロジェクト構造

GitLab内のフォルダ構造は以下のように組織されています:

• /infrastructure/: 主要なグループであり、グローバルな環境変数とデフォルト値を保存する場所です
• /infrastructure/gitlab-models: パイプラインモデルの場所で、主要な2つのプロジェクトがあります
  • ansible-pipelines: スタックの維持と役割の composition の管理を行うためのプロジェクトです。

• terraform-pipelines: vSphere、KVM、AWSなどの利用可能なインフラストラクチャーモデルのパイプラインです。

• /infrastructure/templates: この群には、スタックモデルを作成するために使用されるブーストレートプロジェクトがあります。

• /infrastructure/provision/ansible/roles: このプロジェクトには、Ansibleの役割だけがあり、これにより役割を集中的に管理し、孤立した形で更新することができます。
• /infrastructure/dependencies-iac: このリポジトリには、プラットフォームの依存性が含まれます。たとえば、TerraformとAnsible用のDockerfileなどで、必要なツールとライブラリのバージョンが変更されないようにしています。
• /infrastructure/modules/: Terraform用のモジュールはこのリポジトリに保存され、各プロジェクトにはそれぞれのフォルダがあります。
• /infrastructure/on-premise/: この群は、作成されたインフラストラクチャを保守し、環境、データセンター、スタック、プロジェクトごとに分割する場所です。画像には、群とサブ群の階層が最終的なプロジェクトまで下りています。これらの各レベルで、グループに関連付けられた変数の値を上書きすることができます。

Platformの使用方法

Platformの使用を簡素化するために、issues-opsという名前のリポジトリを作成しました。ここに、特定のニーズに基づいて選択できるissueテンプレートが提供されています。このように、インフラストラクチャの要求が最初から記録されます。

問題が作成されると、DevSecOpsチームは環境の設定を始めることができます。これを行うために、彼らは適切なグループに移動し、この場合、infrastructure/on-premise/staging/dc1/loadbalancer/nginxに基づいて新しいプロジェクトをテンプレートに基づいて作成します。彼らは作成するプロジェクトの名前を提供し、必要な変数を割り当てる必要があります。

各テンプレート内で、環境作成に必要な.gitlab-ci.ymlファイルは既に設定されています。NGINXの場合、このFormatに設定されています。

この設定には、インフラ作成テンプレートとAnsibleテンプレートが含まれています。これにより、デフォルトのロールがすでにこれらのプロジェクトに統合されています。また、モデルの拡張方法も提供しています。追加のロールが必要である場合、対応するブロックを簡単に追加するだけで、構成に modular, building-block アプローチを適用できます。

以下の画像には、要求された環境作成のパイプラインが表示されています。authorized_keysおよびcommonが.gitlab-ci.ymlで明示的に宣言されていないにも関わらず実行されていることに注意してください。これはインポートされたAnsibleテンプレートからの標準的なロールによるものであり、デフォルトのロールがすべてのプロジェクトに適用されることを保証します。

結論

インフラストラクチャープラットフォームは、新しいインフラストラクチャーを作成する前に、計画、テスト、実装、そしてテンプレートとして提供できる定義されたモデルを要求するため、標準の維持と実装に大変貢献しています。このプロセスは、我々が環境でリソースをプロビジョニングするたびに、一貫性のある標準を設定し、これらの環境のバージョニングを行い、必要であれば信頼性のある再構築を保証します。

主要な課題の1つは、アプリケーションの進化とオペレーティングシステムのバージョンの変更に伴い、モデルの更新と確認を維持することです。インフラストラクチャーをコードとして使用する際、すべての変更をそれによって行うことが重要であり、適切な設定のバージョニングと環境の不変性を保証します。これを疏忽しないと、プラットフォームは環境を定義された状態にリバースさせる可能性があり、手動での変更を上書きするかもしれません。

この記事で提案されるモデルは、オンプレミスとマルチクラウド環境にも適用できる多様性のあるもので、ハイブリッドインフラストラクチャーに効果的な解決策となります。