はじめに

この記事では、2019年12月14日に私が書いた「TerraformでALBの高度なリスナールールがより簡潔に書けるようになった話」に関連して、AWSプロバイダーのv2.41.0以前の世界では、管理の仕方をどうしていたのかを書きます。

自己紹介

はじめまして、ななです。

普段は既存のシステムを運用したり、GoプログラムやTerraformコードを書いたり、またエンジニアをより元気にするためにそのシステムを題材にモダン化を図ったりしています。

あと、2019年を振り返ると、一番の思い出は「AWS Summit Tokyo 2019」の2日目で登壇したことですね。詳細はこちらの記事に書いてありますので、興味がある方は覗いてみてください。

ここで本題に入る前に2019年12月14日に投稿した記事がどういうものだったのかを復習してみる

「TerraformでALBの高度なリスナールールがより簡潔に書けるようになった話」では、2019年12月14日 (日本時間) にリリースされたAWSプロバイダーのv2.42.0の中にあるALBの高度なリスナールールに関するアップデートについて書いています。

ALBの高度なリスナールールには色々なパターンがありますが、その記事ではHTTPヘッダーを題材にしました。Terraformでの詳細な書き方や他のパターンについては公式のドキュメントにも書いてありますので、そちらもあわせてご確認ください。

Terraformで実際にALBの高度なリスナールールを書いてみる

前提となる環境

Terraform v0.12
AWSプロバイダー v2.41.0以前（なおv2.42.0以降でも動きます）

設定内容

今回もChromeやSafariブラウザを判定するリスナールールを実現してみます。
elb.tfから一部抜粋した設定を以下に示しています。

elb.tf

resource "aws_cloudformation_stack" "http_header_based_routing" {
  name = "http-header-based-routing-stack"

  template_body = <<STACK
  {
      "Resources": {
        "ListenerRuleBasedOnHTTPHeader": {
          "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
          "Properties": {
            "Actions": [{
              "Type": "forward",
              "TargetGroupArn": "${aws_lb_target_group.tg.arn}"
            }],
            "Conditions": [{
              "Field": "http-header",
              "HttpHeaderConfig": {
                  "HttpHeaderName": "User-Agent",
                  "Values": [
                    "*Chrome*",
                    "*Safari*"
                  ]
              }
            }],
            "ListenerArn": "${aws_lb_listener.front_end.arn}",
            "Priority": 10
          }
        }
      }
  }
  STACK
}

以下のコマンドを用いてデプロイした後で、AWSマネジメントコンソールで確認します。

$ terraform init
$ terraform plan
$ terraform apply

以下の図を見るとちゃんと設定されていますね。

ここでTerraformから作成したCloudFormationのスタックの様子を見てみましょう。まずはスタックの情報を見てみると、「CREATE_COMPLETE」になっていますね。

次にイベントを見てみると、これも「CREATE_COMPLETE」になっていますね。

最後にテンプレートの情報を見てみると、上記で記述された内容が入っていますね。しかも変数が展開されています。

ちなみに、ALBの高度なリスナールールは、Terraformでより簡潔に書けるようになった後と比べると、コードの記述量が2倍近くになっています。一見するとメンテナンスが大変に見えますね。
しかしながら、CloudFormationの既存コードを活かせるため、CloudFormationの記述方法で詰まった際にはAWS公式サポートを享受できたり、公式ドキュメントを活用できたりするので良いですね。またTerraformでしか基本的に書きたくないという方にもマッチする方法ですね。

まとめ

今回は、2019年12月14日に書いた記事の比較対象として、TerraformでALBの高度なリスナールールがより簡潔に書けるようになる前の話を書きました。皆さんも既存のコードを活かしつつインフラ運用に関してどんどん最適化を図っていきましょう。

ありがとうございました。明日は@hamakou108さんです！よろしくお願いします。

余談その1

この記事を書いている時に、TerraformとAWS Cloud Development Kit (AWS CDK) を連携しようと試みているこちらの記事を偶然見つけました。CDKの界隈でも同じように考える人が居るんだなと感じました。

余談その2

AWSプロバイダーのv2.43.0がリリースされましたね。高度なリスナールール周りでも修正があったようです。

TerraformでALBの高度なリスナールールがより簡潔に書けるようになる前の話