Infrastructures-as-Code を理解する

Infrastructure-as-Code (IaC) は、物理的なハードウェア構成やインタラクティブな構成ツールではなく、人間が読みやすい形式で記述して機械で使用できる定義ファイルを通じて、コンピューティング・リソースの管理とプロビジョニングを行います。継続的インテグレーション (CI)、継続的デリバリー (CD)、可観測性などとともに、開発および運用プロセスを自動化し、より高品質で迅速なリリースサイクルを作成するための DevOps の重要なプラクティスの 1 つと考えられています。IaC は、インフラストラクチャをコードのように扱い、同じワークフローを適用することで、コスト削減、市場投入時間の短縮、コストのかかるエラーとセキュリティの脆弱性によるリスクの修正といった測定可能なメリットを提供します。

Ansible は、DevOps ワークフローへの IaC 技術の適用を可能にするツールの代表例です。このブログ記事を読んでいる方々はおそらくすでに Ansible を使用しており、意図的にではなくても、 IaC の技法を使用していることと思います。

Ansible では、インフラストラクチャ (サーバー、クラウドリソース、ネットワーク) の望ましい状態を、Playbook およびロールとして YAML で定義します。この状態は、インベントリや変数とともに、Ansible エンジンによって解析され、強力な抽象化 (モジュール) にマッピングされます。この抽象化は、現在の状態を宣言された目的の状態に調整する作業を行います。新しいサービスのロールアウトや、既存のインフラストラクチャの調整が必要な場合は、Ansible コンテンツに変更を加え、それをコミットして適用します。Ansible は必要なことを実行するだけです。インフラストラクチャが目的の状態にあれば何も行いません。

IaC Ansible Pipeline のアセンブル

インフラストラクチャをコードとして扱う場合は、何らかのソース管理システムで使用します。最近では、ソース管理と言えば Git のことを指します。これは、事実上の業界標準となっている分散型ソース管理システムです。

ソース管理用の Git とインフラストラクチャの状態を管理するための Ansible があれば、あとはリポジトリの内容を自動化して、Ansible をインフラストラクチャに適用する方法が必要なだけです。

業務上これまでさまざまなユーザーのアーキテクチャを見てきましたが、一般的なアーキテクチャパターンは、次の図のようなものです。

DevOps チームは、Ansible コンテンツを作成し、それを Git リポジトリにコミットします。これらのコミットは、CI/CD ツール (通常は Jenkins) によってピックアップされ、Ansible Tower RESTful API を呼び出して、関連する Playbook またはワークフローを起動します。

これは、Ansible を使用して Git 中心の継続的デプロイメント・パイプラインを実装する効果的な方法です。設定後、DevOps エンジニアは、すでに使用しているツールチェーンとワークフローを使用して、すべての作業を Git で行います。CI ツールが変更をピックアップし、Ansible にそれを実行するように指示します。

これは適したやり方ではあるのですが、直感的ではなく、少し複雑です。 そこで、私たちはもっと良い方法があるのではないかと考えました。

Automation Webhook の導入

Red Hat Ansible チームでは、お客様の声に耳を傾け、その使用状況を観察し、これらのパターンが生産性や全体的な品質にもたらすメリットを確認しました。また、Git 中心のデプロイメント・パイプラインに、実装や管理がわかりやすくて簡単な、より優れたユーザーエクスペリエンスを提供できるのではないかと考えました。そこで、昨年の秋、Ansible Automation Platform の一部である Ansible Tower v3.6 に、Automation Webhook を導入しました。

この Automation Webhook を使用すると、git リポジトリと Ansible 自動化をネイティブにリンクできます。リポジトリリンクが設定されると、Ansible は Git システム (GitHub、GitHub Enterprise、GitLab) からイベント (コミット) をキャッチし、それらを使用して自動化ジョブを自動的にトリガーし、プロジェクトとインベントリを更新して、デプロイメントを実行します。Jenkins のような他のツールは一切必要ありません。

構成の使用や管理が必要なツールが 1 つ少ないことのメリットは明らかです。これらの新機能により、変更が生じたときにリポジトリを監視して自動化ジョブを起動するための Jenkins のような追加の CI ツールは必要なくなります。システム全体でジョブパラメーターを同期し、ユーザーアクセスを管理し、アクティビティを監視する必要はありません。可動部分が少なければ破損する可能性のあるものが少なくなり、資格情報が漏洩したり、本番環境に何かをデプロイするために CI システムが悪用されたりするリスクが軽減されます。

それでは、次に Automation Webhook の使い方を見ていきましょう。

Ansible Automation Webhook の最初の設定

Ansible Tower を使用して、Automation Webhook の最初の設定を行いましょう。

まず、GitHub または GitLab のパーソナル・アクセス・トークン (PAT) を Ansible Tower で使用する認証情報として提供し、ステータスの更新を Webhook サービスに送り返します。(作成方法については、Ansible Tower ドキュメントの Credential Types をご覧ください。) この手順はオプションですが、この認証情報は設定しておくことをお勧めします。一度設定すれば、Webhook の受信を有効にする複数のジョブまたはワークフローテンプレートで使用できます。

特定の git リポジトリに変更が生じたときに実行する自動化を特定します。Automation Webhook は、Ansible Tower のジョブまたはワークフローテンプレートから有効化および管理されます。このチュートリアルではジョブテンプレートを使用するので、まだ設定をしていない場合はこの時点で行う必要があります。

ジョブテンプレートの Automation Webhook を有効にするには、「Options」セクションまでスクロールダウンし、「Enable Webhook」チェックボックスをオンにします。Webhook を有効にすると、他の関連フィールドが表示され、Webhook ソースを設定するための追加情報の入力を求められます。

Webhook をリッスンする Git サービスを選択します。現在、Ansible Tower でサポートされているのは GitHub と GitLab のみで、他については検討中です。

次に、必要に応じて、パーソナル・アクセス・トークン (PAT) を、ステータスの更新を Webhook サービスに送り返すために使用する認証情報として選択します。選択する前に認証情報がすでに存在している必要があるため、この手順をスキップした場合は、ここで一旦ストップして設定する必要があります。

Git サービスと PAT を選択すると、Ansible Tower UI がいくつかの追加フィールドを自動的に入力します。POST リクエストへの Webhook サービスの URL や、Ansible Tower に送信されるペイロードに署名するために Webhook サービスが使用する共有秘密鍵が入力されます。「Webhook Key」フィールドの右側に更新アイコンのボタンがあるので、必要に応じてクリックし、別の秘密鍵を生成できます。

この一意の Webhook URL と秘密鍵を使用して、Git サービスに移動し、Ansible Tower が Webhook を受け入れるリポジトリに Webhook を登録します。サポート付きサービス向けの Webhook 設定の詳細については、Ansible Tower ドキュメントの Working with Webhooks を参照してください。このブログシリーズのパート 2 では、Webhook を使用して Windows IIS に変更をデプロイする方法をご紹介しますのでお楽しみに。

これで、Webhook を試用する準備ができました。GitHub と GitLab は、Webhook が適切に構成され、機能していることをテストする方法をそれぞれの UI で提供します。リポジトリのコンテンツを変更し、それを git リポジトリにプッシュして、Ansible Tower がダッシュボードでテイクオーバーするのを確認します。

Automation Webhook はジョブテンプレートだけに限定されません。ワークフローテンプレートで有効にすることもできます。UI と手順は同じです。

Ansible を使用する際、はるかに直感的で簡単に Git 中心のワークフローとそのすべてのメリットを有効にできる方法だと思います。これで、Ansible Playbooks および Ansible Tower ワークフローで実行できることはすべて、git リポジトリへのコミットによって自動的に実行できます。

まとめ

ここまででご理解いただけたと思いますが、Ansible Automation Webhook は、より直感的な Git 中心のワークフローのネイティブサポートを提供します。Git リポジトリを監視して自動化ジョブを起動するために Jenkins のような追加の CI/CD ツールを使う必要はありません。この新機能は、Ansible とこれらのタイプのワークフローによってさらに多くのメリットを引き出すのに非常に役立つと思います。

今後のブログ記事では、Ansible Tower と Automation Webhook を使用して、Kubernetes クラスタだけでなく、クラウドサービスやネットワーク・ハードウェアのような「従来の」IT インフラストラクチャに適用できる GitOps パイプラインを実装する方法をご紹介します。