既存のインフラストラクチャをTerraformにインポートする

編集者注： この記事は当初、 CloudSkiff.comに掲載されました。 CloudSkiffはSnykに加わりました （2021年10月）。

既存のインフラストラクチャをTerraformにインポートする必要が生じることがあります。その理由はさまざまです。インフラストラクチャの移行が必要になり、既存の環境をもとに新しいコードベースを構築する方もいます。専門家であっても、コンソールを操作してすばやく作成したPOC（概念実証）から、本番環境で安定して稼働させる必要のあるプロジェクトへ移行しなければならないことがあります。

クラウドコンソールから構築した稼働中のインフラストラクチャがすでにあるとします……そこからTerraformコードを作成し、さらに重要なこととして、そのコードをどう動かせばよいのでしょうか？

この記事では、既存の環境からインフラストラクチャコードを自動生成する主な方法を簡単に紹介します。環境を複製して動作させ、再現可能にする方法を見ていきましょう。

Terraform importを使って既存のインフラストラクチャをTerraformにインポートする

コード化するリソースが少数で、必要なスキルもある場合は、コードを書き直すだけで済みます。ただし、リソースの構成を正確に把握している必要があります。

既存のTerraformコードベースがある場合は、コードを書いた後、コードベース内でterraform importを実行する必要があります。terraform importはTerraformのサブコマンドです。このコードはクラウドプロバイダーのアカウントにある既存のリソースと完全に一致するため、コード、既存のリソース、TFStateファイルの間に完全な整合性を保てます。

インポーターを使って既存のインフラストラクチャをTerraformにインポートする

先ほど紹介した方法は少数のリソースには有効ですが、大規模な環境では作業が大変になることがあります。市場には、役立つさまざまなインポーター、コンバーター、スキャナー、Terraformジェネレーターなどがあります。

その1つであるTerraformerは、テルアビブにあるWazeのSREチームによって開発されました。

認証情報を入力すると、Terraformerはクラウドプロバイダーのアカウントをスキャンしてリソースを検出し、Terraformコードと動作するstateファイルに変換します。

生成されるコードは決してきれいとは言えず、DRYでもありませんが、作業の80%は完了します。あとはそれを土台に構築を進められます。

インポートしたインフラストラクチャを動作するTerraformコードにするための重要な手順

既存のリソースをTerraformにインポートしたら、正しく動作させるために、さらにいくつかの手順を踏むことが重要です。この段階では、コードはまだ整理も最適化もされていません。

すべてで変数を使い、変数の形式を統一してください。

VPCという名前のVPCネットワークがあるとします。リージョンごとに1つのVPC名しか使用できない場合、これは問題になることがあります。Amazon S3バケットがその例です。すべての顧客を通じて、世界中で同じ名前のS3バケットは1つしか作成できないためです。

リソース名の変更には少し時間がかかります。しかし、変数を使って名前が一意になるようにすれば、別のリージョンでもコードを再利用できるという確信が得られます。

依存関係を明示的に宣言する

リソースをTerraformコードに自動インポートする際によくある問題の1つは、リソース間の関連付けが設定されないことです。全体としては意味のあるリソースでも、依存関係が明示的に宣言されていない場合があります。宣言されていても、変数を介していないこともあります。

たとえば、セキュリティグループのルールが宣言され、そのセキュリティグループのIDに関連付けられ、全体が正しく機能している状況を考えてみましょう。しかし、内部リンク、より正確に言えばコード内の依存関係がなければ、次に別のリージョンへ再デプロイするとき、ルールとセキュリティグループが関連付けられないままデプロイされる可能性があります。

最後に重要なこと：ランダム性を活用して再現性を確保する

最後の重要な手順は、ランダム性を活用して再現性を確保することです。基本的には、名前に数文字をランダムに加えるだけで十分です。

私は個人的に、サフィックスとしてランダムな文字列を使っています。これにより、特殊文字を含まない8文字の非常にシンプルなランダム文字列が生成されます（名前に不自然な文字を含めたくないためです）。ここではローカル変数を作成します。

本番環境とステージング環境では、その文字列をサフィックスとして追加します。これにより、本番環境でもステージング環境でも、それをもとに一意のランダムな名前を付けられます。また、コピー＆ペーストするだけで、テスト用の別環境を簡単に作成できます。

1# cluster name needs to be unique
2resource "random_string" "suffix" {
3  length  = 8
4  special = false
5}
6locals {
7  production_cluster_name = "eks-production-${random_string.suffix.result}"
8  staging_cluster_name    = "eks-staging-${random_string.suffix.result}"
9}
10# Production Cluster
11module "production_cluster" {
12  source          = "terraform-aws-modules/eks/aws"
13  version         = "7.0.1"
14  cluster_name    = local.production_cluster_name
15  cluster_version = var.kubernetes_version
16  manage_aws_auth = true
17  worker_ami_name_filter = "amazon-eks-node-1.14-v20200312"
18  subnets = module.vpc.private_subnets
19  vpc_id = module.vpc.vpc_id
20  map_users = var.map_users
21  workers_additional_policies          = [aws_iam_policy.allow_ecr.arn]
22  worker_additional_security_group_ids = [aws_security_group.management.id]
23  worker_groups = [
24    {
25      name                 = "production-1.14-wg-small"
26      instance_type        = "t3.small"
27      asg_max_size         = 2
28      asg_desired_capacity = 1
29    },
30    {
31      name                 = "production-1.14-wg-medium"
32      instance_type        = "t3.medium"
33      asg_max_size         = 3
34      asg_desired_capacity = 2
35      asg_min_size         = 2
36    }
37  ]
38  tags = {
39    environment = "production"
40    Terraform   = "true"
41  }
42  workers_group_defaults = {
43    key_name = aws_key_pair.admin.key_name
44  }
45}

まとめ

リソースのインポートは最初の一歩にすぎず、それだけで十分なことはほとんどありません。

コードを実際に使える状態にするため、次の手順を進めましょう。

• すべてで変数を使う

• すべての変数の形式を統一する

• 依存関係を宣言して関連付ける

• 変数をランダム化して一意の名前を生成する

Terraformコードを保護する

Snyk IaCは、コーディング中にTerraformの設定（Kubernetes、CloudFormation、ARMテンプレートも対象）を保護し、ガイド付き修正でスムーズなマージと作業継続を支援します。コードを書きながらテストし、Gitリポジトリの変更を監視できるほか、デプロイ前にビルドパイプラインでのテストを自動化できます。無料プランなら数分で始められます。一方、IaCの設定ミスによる侵害は、取り返しのつかない被害をもたらす可能性があります。以下から登録して、設定の保護を始めましょう。