AWS CDK 超入門!―導入ポエム―
この記事は某有志アドベントカレンダー2023の1日目の記事です。
目次
CDK ってのどの CDK ?
AWS CDK は、コードでクラウドインフラを管理するいわゆる IaC の一種で、開発者界隈で CDK といえばおそらく AWS CDK が一番にでてくるのではないでしょうか。この記事では、以下 AWS CDK を単に CDK と呼びます。
CDK = Cloud Development Kit と、かなり一般的な名前が使われており、最近は HashiCorp 社の CDK for Terraform (CDKTF) も存在しています。この CDKTF は AWS CDK の Terraform バージョンで、親戚のようなものです。
CloudFormation
CDK に入門するためには、ざっくり CloudFormation を理解する必要があります。しばしお付き合いください。
AWS には数々のサービスが存在していて、日々増えている状況です。サーバーレスでメジャーなものといえば Lambda や DynamoDB があるのではないでしょうか。それらのサービスの各リソース(Lambda 関数や DynamoDB テーブル) は Web ブラウザ上からポチポチと作って管理することもできるのですが、数が増えたり、本番環境と開発環境を用意したりする場合に、だんだんと辛くなってきます。
そこで、これらリソースをコードとして管理するサービス CloudFormation もまた AWS には存在しています。 CloudFormation では、どのようなリソースを構成するかを JSON または YAML 形式で記述することができます。このデータをもとに CloudFormation がデプロイまでを実行してくれます。開発環境用に記述した JSON 等のほとんどはそのまま本番に移植できるため、極めて管理が簡単です。
なぜ CDK ?
ではなぜ、こんな便利な CloudFormation がありながら、 CDK なのでしょうか。それは CloudFormation の JSON を管理するのが、いくつかの理由により人間離れした業だからです。主な理由を 2 つ挙げます。
- JSON 自体がかなり複雑である
- コードリソース等を別途デプロイしておく必要がある
1 つ目の理由は 「JSON 自体がかなり複雑である」 ということです。以下が公式から拾ってきた JSON の一例です。開いて 10 秒だけ見つめてみてください。そしてそっと閉じてください。
JSON の一例
// ...
"InstanceType": {
"Ref": "InstanceType"
},
"ImageId": {
"Fn::FindInMap": [
"AWSRegionArch2AMI",
{
"Ref": "AWS::Region"
},
{
"Fn::FindInMap": [
"AWSInstanceType2Arch",
{
"Ref": "InstanceType"
},
"Arch"
]
}
]
},
"KeyName": {
"Ref": "KeyName"
},
"NetworkInterfaces": [
{
"GroupSet": [
{
"Ref": "WebServerSecurityGroup"
}
],
"AssociatePublicIpAddress": "true",
"DeviceIndex": "0",
"DeleteOnTermination": "true",
"SubnetId": {
"Ref": "PublicSubnet"
}
}
],
"UserData": {
"Fn::Base64": {
"Fn::Join": [
"",
[
"#!/bin/bash -xe\n",
"yum install -y aws-cfn-bootstrap\n",
"# Install the files and packages from the metadata\n",
"/opt/aws/bin/cfn-init -v ",
" --stack ",
{
"Ref": "AWS::StackName"
},
" --resource WebServerInstance ",
" --configsets All ",
" --region ",
{
"Ref": "AWS::Region"
},
"\n",
"# Signal the status from cfn-init\n",
"/opt/aws/bin/cfn-signal -e $? ",
" --stack ",
{
"Ref": "AWS::StackName"
},
" --resource WebServerInstance ",
" --region ",
{
"Ref": "AWS::Region"
},
"\n"
]
]
}
}
// ...
いかがでしたでしょうか。恥しながら、私はこの時点で CloudFormation を諦めました。
続いて 2 つ目の理由は「コードリソース等を別途デプロイしておく必要がある」ということです。 CloudFormation は JSON だけで操作できるシンプルなサービスですが、入力が JSON だけであるため、例えば Lambda 関数をデプロイしようとした場合、「ソースコードは一体どこに入力するんだい?」という疑問が浮かびます。
なかなか面白いことに、さきほど公式から拾ってきた JSON にはソースコードらしきものが埋め込まれています。「JSON に直接ソースコードを書けるよ!」という解決ですね。素晴しいですが、限界を感じますよね。そこで別のアプローチとして、ソースコードを S3 や ECR などのサービスに別途登録しておき、それらを参照する、という方法をとれます。この場合、 JSON はシンプルになりますが、ソースコードを S3 に登録するなどの操作は CloudFormation の外で行う必要があるため、 IaC としては旨みが減ってしまいます。
CDK は以上の問題を完全に解決します。
- JSON の代わりに TypeScript を含む様々な言語を利用できる
- JSON が参照する各種リソースも自動でデプロイしてくれる
1 の旨みについて少し補足させてください。例えば「複数の文字列を結合する」という一見単純な作業をするにしても、生の CloudFormation では JSON 上でそれを表現する必要があるため、 Fn::Join という CloudFormation 独自の記述方法を覚える必要があります。それらが全て TypeScript 上で行えるというのは、まさに革命ですよね。
CDK を書いていて、ときおり壁にぶつかることもありますが、ほとんどの難しさは CloudFormation に由来しており、 CDK 自体はとても簡明です。
CDK for Terraform についてちょっとだけ
AWS CDK は、おそらく CDK for CloudFormation と呼ぶにふさわしいものでしょう。 Terraform も CloudFormation に似た難解さを抱えています。 CDK for Terraform(CDKTF)はその名前の通り、 AWS CDK と同じ方法で Terraform の難解さを解消します。書き心地もほぼ CDK と変わらないので、 CDK と Terraform の抽象的な使い方さえ理解していれば簡単に入門できます。ただし現時点では CDKTF 自体のドキュメントは薄いため、詳細については Terraform のドキュメントをもとに使っていくしかありません。
まとめ
CDK は CloudFormation の痛みを解消してくれる最強ツールなのでした!次回はいよいよ CDK を使ってみます!
CDK の旨みポイント:
- JSON の代わりに TypeScript を含む様々な言語を利用できる
- JSON が参照する各種リソースも自動でデプロイしてくれる
Discussion