Ansible、Google Cloudを用いた多環境構築完全自動化を目指して(IaC)

ここからは各機能の詳細について紹介します。

まず、Infrastructure as Codeというモデルに基づき構成していますので定義から紹介します。

Infrastructure as Code（IaC）とは

物理的なインフラストラクチャやクラウドリソースを手動で設定するのではなく、コードによってインフラストラクチャを管理・プロビジョニングする手法です。

IaCのメリット

• 手作業による人為的なヒューマンエラーの削減

• 作業時間の短縮

  • 多環境で構築する際に同じ環境を展開する必要がある場合にも、自動構築されるためです。

• 不具合の際に第三者検証が可能

  • コードをバージョン管理することで、いつ修正したのかが明確となるためです。

• 一元化/体系化による柔軟な拡張

  • 環境構築に伴う定義が一元的に統合されているため、それらを利用して新規の環境などに適応可能です。

特にヒューマンエラーの削減、作業時間の短縮、そしてシステム構築のための体系化において大きなメリットを感じています。

次にアーキテクチャの①で利用していたinventory情報の取得方法についてです。

Dynamic Inventoryとは

まずよく利用されるケースとして、静的なinventoryがあります。

静的な管理の中では手動で必要に応じ修正し書き換えを行います。ファイル形式はINIもしくはYAML形式。

以下に、静的inventoryのイメージを示します。

一方、Dynamic Inventoryはホスト一覧を動的に生成するための仕組みです。

JSON形式の標準出力形式になります。イメージとしては以下の通りです。

playbookでは、Dynamic Inventoryでも静的なinventory管理の時と同様に通常の変数として取り扱うことができます。

Axross  Recipeでは法人企業様の契約増加に伴い、新規環境の追加構築が多く、inventory管理において人的な負担が大きくなっていました。そこで手動で情報取得の必要のないDynamic Inventoryを導入しました。

Dynamic Inventoryの情報取得方法

Axross  Recipeでは上図のようにオペレータが管理画面で新規お客様のご要望を入力します。その情報をDBに保存します。そして、DBの情報をセキュアに取得するためにDevOps用のPodを立ち上げており、そこで内部からのアクセスのみを許可したAPIを作成していて環境IDの情報をJSON形式で取得しています。

この構成の意図としては、将来的な構想としてエンジニアの人手を介さず、オペレーターが管理画面で入力、自動で構築が完了することを目指しているためです。そのために、DevOpsのためにpodを立ち上げpod化/api化を進めています。

AnsibleとTerraformの併用利用

環境構築においてAnsibleで全体のプロセス管理、プロセス中でGoogle Cloud(インフラ部分)のキックはTerraformという役割の分けをしています。

AnsibeとTerraformの違い

Ansible

サーバ構成管理、アプリケーションデプロイ、自動化タスクといった汎用的な自動化に対応します。

手続き型 (または命令型) であり、タスクを完了するための命令の手順を定義します。

実行プロセスを作成者が決定する必要があり、task作成において依存関係も考慮する必要があります。

例を以下に示します

Terraform

主にクラウドインフラのプロビジョニングに特化しています。

宣言型のため、方法の詳細ではなく、最終的な結果を記述するコードを作成します。

Terraform が実行する必要がある一連のコマンドは、エンドユーザーには見えません。 依存関係の解消も自動的に行います。

例を以下に示します。

これらの違いを踏まえ、Axross RecipeではAnsibleで全てを統合管理しています。これは、整合性のある統合プラットフォームを実現するためです。

環境構築後のjob転送やDBでの権限設定、一部証明書配布などをTerraformも併用しながら、全体定義に沿って各環境に展開できるようになってます。

また、リリースされたばかりの最新機能の利用することが多く、Terraformでは対応してない機能なども、Ansibleでは柔軟にコマンド組み合わせで対応できるというメリットも感じています。

[補足] Ansibleの環境指定(環境ID)について

一般的にAnsibleではサーバー単位での構成管理だと思います。inventoryではサーバー単位で指定します。

しかし、Axross Recipeでは環境単位構成管理としています。サーバー名やIPアドレスを指定するのではなく、podごとansibleで変数を設定し構成管理を行っています。（環境IDと呼びます）

サーバー単位での構成管理

axrossでの環境単位構成例　ここでenvは１つの環境を示す

まとめ

今回は、Axross RecipeにおけるAnsible、Google Cloudを利用した環境構築についてお話ししました。

現状では、オペレーターが管理画面に入力した内容を元にエンジニアがAnsibleを実行させるフローとなっています。最終的な目標はオペレーターが管理画面で必要情報を入力すると自動的に環境構築を実施する状態を目指しています。

間違いやアドバイスありましたらコメントいただければ幸いです！

アドベントカレンダー 22日にバトンをお渡します。