実はhokkai7go

hatenablogに移行しまんた

AWS CDKによるdeployの前に、cdk diffやsynthのレビューを行うのが運用上よいのではないかという話

前置き

CDKについて

AWS CDK使っていますか? 知っている人は適当に読み飛ばしてください。知らない人は全部読んでいってください。

これですこれ。 github.com

Welcome — AWS Cloud Development Kit

aws.amazon.com

CloudFormationでJSON書くのはなかなかしんどく、いい感じにJSON出力してくれるものが出ないかなぁと思ってはいましたが公式で出てきて、わっしょーいという感じです。しかも、TypeScript、JavaScript そして Javaで記述可能ですし、.NET と Python も近々公開されるとか。

AWS CDKの使い方については、公式リポジトリの /examples/cdk-examples-typescript 以下が参考になりますね。既存リソースの import もできますね。

aws-cdk/examples/cdk-examples-typescript at master · awslabs/aws-cdk · GitHub

CDKでの開発について

AWS CDKは、まだ正式リリースではないのですが、stagingの構築等で使っている方も結構いそうな気がします。 意図しない変更が本番に反映されるのは嫌なので、インフラの人とか開発チーム内でレビューするのが良さそうです。

ちょうど、CDKには cdk synthというコマンドがありCloudFormationのJSONを出力してくれます。

こうしたサンプルを食わせると

import cdk = require('@aws-cdk/cdk');
import s3 = require('@aws-cdk/aws-s3');

class MyStack extends cdk.Stack {
    constructor(parent: cdk.App, id: string, props?: cdk.StackProps) {
        super(parent, id, props);

        new s3.Bucket(this, 'MyFirstBucket', {
            versioned: true
        });
    }
}

class MyApp extends cdk.App {
    constructor() {
        super();
        new MyStack(this, 'hello-cdk');
    }
}

new MyApp().run();

こうしてJSONを出力します。

cdk synth
Resources:
  MyFirstBucketxxxxx:
    Type: AWS::S3::Bucket
    Properties:
      VersioningConfiguration:
        Status: Enabled
  CDKMetadata:
    Type: AWS::CDK::Metadata
    Properties:
      Modules: "@aws-cdk/aws-codepipeline-api=0.15.2,@aws-cdk/aws-events=0.15.2,@aws-c\
        dk/aws-iam=0.15.2,@aws-cdk/aws-kms=0.15.2,@aws-cdk/aws-s3=0.15.2,@aws-c\
        dk/aws-s3-notifications=0.15.2,@aws-cdk/cdk=0.15.2,@aws-cdk/cx-api=0.15\
        .2,hello-cdk=0.1.0"

diffとして出すこともできます。 蛇足ですがdiffの仕組みがどうなってるのか、複数人でCDKで開発したときにどうなるのか。Terraformのようにstateファイルがないのに、はて…。となっています。調べてわかったら記事を書くかもしれません。

cdk diff
[~] 🛠 Updating MyFirstBucketxxxxx (type: AWS::S3::Bucket)
 └─ [-] .BucketEncryption:
     └─ Old value: {"ServerSideEncryptionConfiguration":[{"ServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]}
[~] 🛠 Updating CDKMetadata (type: AWS::CDK::Metadata)
 └─ [~] .Modules:
     ├─ [-] Old value: @aws-cdk/aws-codepipeline-api=0.15.2,@aws-cdk/aws-events=0.15.2,@aws-cdk/aws-iam=0.15.2,@aws-cdk/
aws-kms=0.15.2,@aws-cdk/aws-s3=0.15.2,@aws-cdk/aws-s3-notifications=0.15.2,@aws-cdk/cdk=0.15.2,@aws-cdk/cx-api=0.15.2
     └─ [+] New value: @aws-cdk/aws-codepipeline-api=0.15.2,@aws-cdk/aws-events=0.15.2,@aws-cdk/aws-iam=0.15.2,@aws-cdk/
aws-kms=0.15.2,@aws-cdk/aws-s3=0.15.2,@aws-cdk/aws-s3-notifications=0.15.2,@aws-cdk/cdk=0.15.2,@aws-cdk/cx-api=0.15.2,he
llo-cdk=0.1.0

本題

前置き長かったですね。cdk synthコマンドでのCloudFormationのJSONや、cdk diffコマンドの出力結果をプルリクエストに添えたら便利だと思いませんか。適当なラッパースクリプトを叩いたらcdk synth, cdk diffを行い、その結果をプルリクエストに簡単にくっつけられる。そんな仕組みを作ったらInfra as Codeが加速し、DevとOpsとの境目はもっとゆるふわになるのではないか。そう思って、記事を思いつきで書いてみました。

  • インフラエンジニアとしては、既存リソースへの影響範囲を変更前に知ることができる
  • アプリケーションエンジニアとしては、コードやJSON、diffでインフラエンジニアと対話する手段を得ることができる
  • しかもこれについてのコードレビューや会話をGitHub上で行うことができる。

ということで早く正式リリースされてほしいですね。現段階では、ドキュメントに書いてある内容が間違っていることもあるのでコントリビューションチャンス!という気がします。