こんにちは。iChain インフラ担当です。 前職ではExcel設計書・パラメータシートベースでの構築が殆どだったのですが、iChainではAWSインフラの構成管理にTerraformを採用しています。
背景
弊社でのサービスプロダクト開発は技術方針としてMicroservice Architectureを採用する方向で固まっており、これらを実現する為のDocker/Kubernetesの採用となっています。 なお、弊社ではクラウドプロバイダのAWS主に利用しており、アプリケーションサービスプロダクトのインフラにKubernetes(EKS)を採用しています。サービスプロダクト毎にEKSクラスターを運用している形となり、上記の環境上に各種ProjectのMicroserviceリソースをデプロイしています。 このような複数のクラスターを運用していく上で、iChainとしての統一的なAWSインフラリソースアセットの構築・管理を行うのに手動での対応には限界があります。その為のIaC(Infrastructure as Code)化は必須であり、そのための構成管理ツールとして、Terraformを採用しています。
Terraformのメリット・デメリット
構成の可視化
メリットとしては、構成がcode上に記載される為、現状のインフラ構成がどうなっているかを正確に把握する事ができます。弊社ではバージョン管理にGitlabを採用しており、Terraformのcodeはそれぞれのプロジェクトのインフラ用レポジトリに格納されています。
再利用性
Terraformでは複数のリソースをmoduleとして定義し、異なる実行環境からmoduleを呼び出す事が可能です。この機能を利用し、異なる環境(e.g. Staging,Production)上に冪等性の高いインフラリソースを構築する事ができるようになります。
デメリット
デメリットは構成のdriftが起こってしまう為、手動での対応が原則利用できなくなるという点です。ここはIaCを採用する上でのトレードオフとなる点ですが、メリットの方が上回ると判断しています。あとは、TerraformのCodingに独自言語HCLを利用する形ですが、こちらに学習コストを一定量かける必要がある点があります。
個人からチームへ
私がjoinした当時はインフラ担当が一人という事で、必然的にTerraformのCode maintananceを行うのも私のみという状況でした。 その為、ローカル上でのplan/applyとなる為CI/CDは必要なかった形ですが、サービスプロダクトのグロースに伴い(有難い事です)、インフラもチーム体制を構築する形となり、Terraformを利用したリソースデプロイに関してもCI/CD環境が必須となってきます。
TerraformCloudでMerge RequestベースのCI/CD環境構築
チーム開発体制に移行するにあたり、CI/CD環境を構築する事は必須でした。 アプローチとしては以下がありました。
- リモートソースコードレポジトリのCI/CD pipeline上にスクリプトを構築する(Gitlab CI等)
- レポジトリから独立したCI/CD pipelineを構築する(jenkins, CircleCI, Codebuild/Codedeploy等)
- terraform cloudをリモートソースコードレポジトリと連携する 上記3点、それぞれメリット、デメリットがあるのですが、最終的にterraform cloudを採択する事に至りました。理由は以下です。
- メリット
- 承認フロー付のdeploy pipelineが低工数で構築できる事
- リソースをterraformで管理できる事
- デメリット pipelineのカスタマイズ性が低い事 それぞれメリット、デメリットがあります。弊社がスタートアップである為、いずれの方式を取るにせよ、工数には限りがあります。 限られた資源で仕組みを構築する為に、terraform cloudが最適であると判断し、導入に至っています。 現在は以下の方式で開発フローを回しています。
- Gitlab上にてトランクからfeatureブランチを作成
- Merge Request作成
- tfcloudがソースコードの差分を検知
- ソースコードレポジトリと連携しているterraform cloud workspace上にてterraform planが作成
- merge時、ソースコードレポジトリと連携しているterraform cloud workspace上にてterraform applyが作成
- 上記confirm時、各環境宛てのapply(デプロイ)が実行
Terraform Cloudを利用したCI/CDデプロイパイプラインを構築する事で、
plan, apply時にレビュアーによるレビュー、承認を取る運用体制となり、
開発リソースに対し一定の品質を担保できるようになりました。
Terraform Cloudを Terraform Cloudで管理する
通常、Terraformを利用する際はAWS, Azure, GCP等のクラウドインフラを管理するイメージが強い方も多いかもしれませんが、 その他にも色々なリソースを管理する事ができます。 terraform cloudのworkspace設定はwebGUIから設定する事もできるですが、この設定自体もterraform providerとして管理する事が可能です。 https://registry.terraform.io/providers/hashicorp/tfe/latest 実際のコードサンプルを下記に記載します。
resource "tfe_workspace" "default" { for_each = local.tf_workspace_each agent_pool_id = "" name = each.value.workspace_name organization = tfe_organization.ichaininc.id terraform_version = each.value.terraform_version working_directory = each.value.working_directory file_triggers_enabled = each.value.file_triggers_enabled execution_mode = each.value.execution_mode ssh_key_id = "" trigger_prefixes = each.value.trigger_prefixes_list vcs_repo { identifier = each.value.vcs_repo_id ingress_submodules = each.value.vcs_ingress_submodules oauth_token_id = var.gitlab_oauth_token branch = each.value.vcs_branch } } resource "tfe_notification_configuration" "default" { for_each = local.tf_workspace_each name = "${each.value.workspace_name}-notify" enabled = true destination_type = "slack" triggers = [ "run:created", "run:errored", "run:needs_attention", "run:completed" ] url = var.slack_webhook_url workspace_id = tfe_workspace.default[each.key].id }
実際の運用では複数のworkspaceを立てる事になる為、予めfor_eachにて複数のリソースを構築する形でcodingしています。 新しくworkspaceを追加する度にfor_eachにて読み込むパラメータを更新する形となります。 その他、ここには記載していませんが、AWS Credentialの設定等もcode化できます。 詳しくは公式documentをご確認ください。
課題等
こうしてCI/CD周り環境を整えて運用する事はできていますが、現状まだvalidationチェック、セキュリティポリシーテスト等が pipelineに載せる事が出来ていないので、ここは随時改善できればと考えています。
最後に
iChainでは保険業界向けのSaaSプロダクトを担うAWSインフラの改善、向上に努めてくれるエンジニアを募集中です。 今回取り上げたCI/CD pipelineの構築・運用等、まだまだ改善すべき点は多々あるので、一緒にプロダクトを成長させていく事に興味がある方、 是非応募ください!よろしくお願いいたします。