はじめに
こんにちは、原(@kouzyunJa)です。現在のプロジェクト先でAWS Cloud Development Kit (以下、CDK)にてAWS環境を構築しておりまして、せっかくなのでCDKのキホンについて学んだことを記載していきたいと思います。
自己紹介
1995年生まれでAWSエンジニアをやっています。未経験からエンジニアへキャリアチェンジしエンジニア歴としては4年目です。SES企業に未経験から就職し、様々な案件を経験しAWSエンジニアとなりました。TechBullコミュニティへはSRE領域の知識を身に着けるため参画させていただいております!
CDKとは
CDKとはコードを書いてインフラ環境を構築する、Infrastructure as Code(以下、IaC)の一種です。クラウド環境をコードで記述し構築できるツールとして有名どころとしては、CloudFormation, Terraform, CDKなどがあります。CDKはTypeScript、Pythonなどのプログラミング言語を用いてAWSリソースを構築できるIaCです。AzureやGoogle CloudといったAWS以外の環境では使用できません。というのも、CDKの裏側ではAWSの標準サービスであるCloudFormationが動いています。CDKで記述したコードがCloudFormationのコードに変換され、CloudFormationのリソースとしてAWS環境が構築されます。例えば、EC2やRDSといったAWSリソースをCDKのコードで記述した時は以下のような流れでAWSリソースが自動構築されます。
このような動きをすることによって、記述したソースコードに沿ってAWSリソースが構築される訳です。ちなみに、公式ドキュメントによると現在CDKのソースコード記述に対応している言語は使用できるプログラミング言語は「TypeScript、JavaScript、Python、Java、 C#、.Net、Go.」になります(2024年8月時点)。
CDKを構成する主な要素
CDKを構成する主な要素として、App、Stack、Constructというものがあります。これらの要素がツリー構造として関係性を結んでいることでCDKを成り立たせています。それぞれの要素について記載していきます。
App
最上位のStackをまとめる要素になります。Stackをまとめる土台となり、アプリケーション全体を表します。
Stack
リソースをデプロイし構築する際、Stackという単位でまとめて構築します。StackはAppに1つ以上は構成する要素です。CloudFormationのスタックと同義であり、CDKで指定したStackの単位でCloudFormationのスタックが作成されます。
Construct
具体的なAWSリソースをConstructの単位で定義します。Constructにて定義した内容にそって、CDKはAWSリソースを構築します。
3種類のConstructの定義
具体的なAWSリソースを構築するConstructには3種類の定義の方法あります。この3種類の定義の方法は定義を記述する際の抽象度具合の違いでレイヤーが分類されます。
L1 Construct
L1はLow Level(抽象度の低い)なConstructで、CloudFormationに記載する内容に沿うような形で書いていきます。CloudFormationテンプレートは設定値を細かく記載する必要があり、CDKでも同様に設定値を細かく記載する必要があるので抽象度が最も低いConstructとなります。L1のみで設定できるパラメータがあった場合に使用したりします。
L2 Construct
L2はHigh Level(抽象度が高め)なConstructで、CloudFormationの各リソースを抽象化してくれています。L1よりも簡略的に記述することができ、基本的にL2で記述することが一般的です。
L3 Construct
L3は単体のリソースだけでなく、複数のリソースをまとめて1つのパターンとして設定できます。例えば、ECS Fargate + ALBといったアプリケーションを構築したいとき、アーキテクチャパターンを1つのConstructで定義できます。
上記のような3種類の記述方法があります。
その中で、今回はL2の記述方法で以下の例をあげてみます。これはVPCの記述をしていますが、設定値として記載しているのはVPCのCIDRレンジが「10.0.0.0/16」とVPCNameを「MyVPC」と設定しているくらいです。プログラミング言語はTypeScriptを使用しています。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
import { CfnOutput, Stack, StackProps } from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as ec2 from "aws-cdk-lib/aws-ec2"; export class MyCDK extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const vpc = new ec2.Vpc(this, "MyVpc", { ipAddresses: ec2.IpAddresses.cidr('10.0.0.0/16'), vpcName: 'MyVpc' }); } } |
これだけシンプルな設定値の内容で、実は以下のリソースが構築されます。
- VPC (Virtual Private Cloud)
- CIDRブロック
10.0.0.0/16
を持つVPCが作成。 - DNSホスト名とDNSサポートが有効化。
- CIDRブロック
- Public Subnets
- 2つのパブリックサブネットが作成され、それぞれ異なるアベイラビリティゾーンに配置。
- サブネット1のCIDRブロックは
10.0.0.0/18
、サブネット2は10.0.64.0/18
。 - これらのサブネットにはパブリックIPアドレスが自動で割り当てられる。
- Private Subnets
- 2つのプライベートサブネットが作成され、異なるアベイラビリティゾーンに配置。
- サブネット1のCIDRブロックは
10.0.128.0/18
、サブネット2は10.0.192.0/18
。
- Route Tables and Associations
- 各サブネットにはルートテーブルが関連付けられる。
- パブリックサブネットにはデフォルトルート (
0.0.0.0/0
) が設定され、インターネットゲートウェイを経由するように設定される。 - プライベートサブネットにはデフォルトルートが設定され、NATゲートウェイを経由してインターネットにアクセスする。
- NAT Gateways
- 各パブリックサブネットにNATゲートウェイが配置されており、プライベートサブネットからインターネットへのアウトバウンドアクセスを設定。
- Elastic IPs (EIP)
- 各NATゲートウェイには、EIP(Elastic IP)が割り当てられる。
このように具体的な設定値を入力しなくても、CDK側で設定を柔軟に行ってくれることがCDKの特徴であります。
CDKの基本的なコマンド
CDKの基本的なコマンドは以下の通りです。これらのコマンドを使用してCDKのデプロイを行ったりしています。
- CloudFormationテンプレートの作成
1 |
$ cdk synth |
- スタックとローカルの比較
1 |
$ cdk diff |
- スタックのデプロイ
1 |
$ cdk deploy |
- スタックの破棄
1 |
$ cdk destroy |
- TypeScriptのテンプレート生成
1 |
$ cdk init app --language typescript |
- TypeScriptのテンプレート生成(サンプルアプリ付)
1 |
$ cdk init sample-app --language typescript |
- TypeScriptのライブラリテンプレートの生成
1 |
$ cdk init lib ---language typescript |
まとめ
今回は簡単な内容ではありますが私がCDKで学んできた内容を記載してみました。CDKは他のIaCに比べればハードルは高いように感じますが、一度習得すればプログラミング言語で記載しているため、自由度高くインフラ環境のソースコードを記載できると思います。まだまだ私自身もCDKを学び始めたばかりであり、よりスキルアップしていければと思っております。ありがとうございました。
1995年の駆け出しSRE。未経験からエンジニアへキャリアチェンジしエンジニア歴としては4年目となる。SESにて様々なAWS案件に携わる。SRE領域の知識を身につけるためTechBullコミュニティへ参画。元運用監視オペレーターという立場からAWSエンジニアやSREへキャリアアップした経験やクラウド関連の記事を執筆しつつ、コミュニティの1on1を実施している。