AWS Cloud Development Kit -CDK- Meetup https://awsclouddevelopmentkitcdkmeetu.splashthat.com の発表資料です 資料で言及したライブラリはこちら https://github.com/cohalz/cirrocumulus
CDKを用いたモダンなECSクラスタの構築と運用AWS Cloud Development Kit -CDK- Meetupid:cohalz
View Slide
自己紹介・id:cohalz / @cohalz・株式会社はてな 2018年新卒入社・システムプラットフォーム部 SRE
よくCDKのコントリビュートしてます
話すこと1. どうしてCDKを採用したか2. ECSのライブラリを作る3. CDKを使ったデプロイ手法4. 開発時にやったこと
1. どうしてCDKを採用したか
社内のコンテナ事情について
社内のコンテナ事情について・クラウド環境は主にAWS・アプリケーションのコンテナ化を進めている・既に一部のチームでECSの運用実績がある=> ECSを採用していく予定
どうやって知見を横展開するか?
どうやって知見を横展開するか?・サービスそれぞれで要求される特性が違う ・サービスごとにECSクラスタを分けることになりそう・今までCFnで管理をしていたけど,どう展開する?
CloudFormationを横展開するのは大変・CFnテンプレートを配って都度書き換えていく?・特にECSは関連コンポーネントが多くて大変
CloudFormationに代わるもの・横展開しやすいもの ・IaCできるもの・学習コストは下げたい
ということでCDKを採用
CDKの採用・独自の言語で書く必要がない・パッケージ化して配布できる・CFnテンプレートを出力可能 ・もし撤退したくなってもやりやすい
CDKの強力なCLIツール・IAM・SG周りの変更で警告を出せる ・ECSはコンポーネントが多くなるので特に役立つ
2. ECSのライブラリを作る
ECSのライブラリを作る・公式のライブラリはあったが機能が足りない・拡張してより使いやすいライブラリを作ることに
ライブラリに組み込んだ機能・ecs.configを使いやすく書き換え・ホスト名わかりやすくする・ローリングアップデート対応・SSMエージェントの導入・スポットインスタンス対応などなど
その他の機能
ECS運用の課題・インスタンスにファイルをデプロイしたいことがある ・SSHキーや監視のエージェントなど・定期的にパッケージのアップデートもしたい
デプロイしたいタイミングって?・クラスタを作ったとき・ファイルを変更したとき・オートスケーリングしたとき
解決案・ユーザデータ?・cfn-initとcfn-signal?・ChefやAnsibleなどのツール経由?
(再掲)デプロイしたいタイミングって?・クラスタを作ったとき・ファイルを変更したとき・オートスケーリングしたとき
(再掲)デプロイしたいタイミングって?・クラスタを作ったとき・ファイルを変更したとき・オートスケーリングしたとき=> これらのツールでは対応が難しかった
これもCDKで解決
これもCDKで解決・CDKでデプロイできるものを作った・ディレクトリとデプロイ先(タグ)を指定するだけで使える
裏側の構成・CDKからこういう構成が作られる
CDKでファイルをS3にアップロードBucketDeploymentを使うとデプロイ時にアップロードできる
S3のPUTイベントをCloudWatch Eventsに流す・CloudTrail経由でイベントを取得
イベント時にs3 syncする・Systems Manager経由で各インスタンスからs3 sync
嬉しいところ・SSMの関連付けはインスタンス起動時にも実行してくれる・対象をタグで決めるのでインスタンスを意識しなくて済む・利用者は別にこの構成を知らなくても使える
シェルスクリプトを実行・s3 sync後に自動でシェルスクリプトを実行できる ・パッケージアップデート ・監視エージェントの追加
OSSで公開してますhttps://github.com/cohalz/cirrocumulus
3. CDKを使ったデプロイ手法
GitOpsの手法をECS+CDKで構築
GitOps by ECS+CDK
GitOps by ECS+CDKのポイント・アプリケーションとCDKのリポジトリを分ける・CDKコマンドはCodeBuildから実行 ・手元からは実行しない
CodeBuildがAppイメージをECRにpush
AppとCDKのリポジトリを分ける
masterの変更をトリガーにCDKリポジトリにPR
PR内容・最新のイメージを使うような変更をbotが作る
PRとともにstaging環境が自動更新
PRがマージされたら自動で本番環境が更新
嬉しかったこと・アプリケーションとインフラのコードを分離・インフラの構成がGitリポジトリをマスターに・CDKはCFnベースなので失敗してもロールバック可能
これからの課題・cdk diffをどうやって確認するか?・この仕組み自体はまだ手作り
4. 開発時にやったこと
開発時にやったこと・テストにJestのスナップショットテストを使う・アップデートやバグへの対応
Jestのスナップショットテストを使う・生成されるCFnが以前と変わっていないかをテスト・テストの網羅性も高く,実装も簡単
ライブラリアップデート時・Renovateと組み合わせてテスト通れば自動マージ
アップデートやバグへの対応・Slackで #aws-cdk チャンネルを作って情報共有・複数チームで並行して試していたので知見が貯まっていく
アップデートやバグへの対応・結構壊れるので積極的にバグ報告やPRをする
バージョンを固定して使うことも・最終的にはCFnなので,実際そこまで困らない・今はGAになったので全部上げていってるタイミング
まとめ・CDKは仕組みをライブラリとして提供しやすい ・CFnが慣れた言語で書ける以上のメリットがある・IaCとそのデプロイツールとしても利用できて便利・まだまだ出たばかりなので知見共有は大事 ・社外事例待ってます!