Deploy TypeScript with CodePipeline in Fargate

ビットバンク株式会社
Deploy TypeScript with CodePipeline in Fargate
shogo ishikawa / bitbank, Inc
東京Node学園祭　Day2-LT
2018/11/24

Copyright © bitbank, inc.
自己紹介
ビットバンク株式会社
AWSエンジニア
shogo ishikawa
CodePipelineを用いたTypeScriptなどのデプロイフローの構築を担当
インフラ領域を専業としているが、LambdaでNode.jsを使ったりすることもあ
る。

bitbankのJavascriptへの取り組み
# TypeScriptの全面採用により、
開発メンバーのダイナミックなアサインが可能

今回話すこと
● TypeScriptアプリケーションのデプロイ方法の紹介
● 細かいTips
● やってみてよかったこと・つらみ

Fargateとは
● EC2(サーバ）を気にしなくてよい、コンテナマネージド・サービス
● リソースベースの課金(CPU / MEM)
● 画面ポチポチで簡単にコンテナを構築できる

CodePipelineとは
● 様々なAWSサービスと連携可能
● CI/CDで、AWSサービスにアプリケーションデプロイの自動化が可能

CodePipelineとは
● 以下のサービスと連携可能
Sorurce Build Deploy
● CodeCommit
● S3
● GitHub
※ それ以外で管理している場
合は、CodeCommitかS3を経
由させれば良い。
● CodeBuild
● CodeDeploy
● ECS/Fargate
● CloudFormation
● ElasticBeastalk

まず手動でデプロイした例を考えてみましょう

手動デプロイの例
● TypeScriptアプリケーションをFargateにデプロイする場合の例

手動デプロイの例
● TypeScriptアプリケーションをFargateにデプロイする場合の例
● 以下のような作業が必要
○ TypeScriptをテスト
○ TypeScriptをビルド
○ Dockerイメージをビルド
○ Docker レジストリにログイン
○ Docker レジストリにPush
○ コンテナデプロイ作業

そもそも人の手でこれやるのちょっとしんどいですよね？

サーバレスなCI/CD導入の背景
● 開発と本番デプロイを自動化したい
● ソースコードテストを確実にしたい
● レビューを通過したものだけをデプロイしたい
● デプロイサーバの保守をしたくない
○ パッケージのバージョンアップ
○ 脆弱性対応
○ クラウドサービス側のメンテナンスに伴う再起動
○ OSのサポート終了　...

なぜCodePipelineなのか
● 各AWSサービスと連携できること
● デプロイを自動化できる
● サーバレスであること
○ OSレベルでの保守が不要　＝　インフラエンジニアがいない場合でもなんとかなる。

CodePipelineを用いたデプロイ例
①ソースコード変更検知
②TypeScript Build & Docker push
④Deploy
③Docker push
⑤Docker Pull
アプリケーション起動
CodeCommitへPush

CodeCommit：ソースコード変更検知
● CodeCommitにPushを検知
● CodePipelineが起動
②TypeScript Build
④Deploy
③Docker push
⑤Docker Pull
CodeCommitへPush

CodeBuild：ビルド
● TypeScriptのビルド
● Dockerイメージをビルド＆プッシュ
②TypeScript Build
④Deploy
③Docker push
⑤Docker Pull
CodeCommitへPush

CodeBuild：Yamlファイルで記述可能
②TypeScript Build
④Deploy
③Docker push
⑤Docker Pull
version: 0.2
phases:
pre_build:
commands:
- $(aws ecr get-login --no-include-email)
build:
commands:
- npm install
- npm run build
- docker build -t ${REPOSITORY_URI}":latest .
post_build:
commands:
- docker push "${REPOSITORY_URI}":latest
artifacts:
files: imagedefinitions.json
CodeCommitへPush

CodeBuild: スペックは高性能
● 最大でvCpu：8G / Mem：15G のインスタンスタイプがあるので、CPUに負荷をかけるTypescripのBuildも可
能

Fargate：デプロイ
● TypeScriptのビルド
● DockerイメージをPush
②TypeScript Build
④Deploy
③Docker push
⑤Docker Pull

Tips：機密情報の管理方法
● KMSで暗号化して保管
● アプリケーションが必要とする際に、復号

Tips：Dockerイメージをカスタマイズして高速化
● Dockerイメージの容量を可能な限り減らす
○ DockerイメージをDockerレジストリにPush・Pullする時間を短縮
○ アプリケーションをオートスケールさせる際の時間を短縮
○ 最小限のアプリケーションしか無いため、セキュリティ向上

Tips：Dockerイメージをカスタマイズして高速化
● Alpine LinuxのDockerイメージを採用
● デフォルトのイメージの容量が圧倒的に少ない
○ node:10.13.0　　　　→　 674MB
○ node:10.13.0-alpine　→　 70.2MB
● 約１０倍小さい
● パッケージのインストールが早い
つまりDockerイメージ容量は軽い方がいい

Tips：CodePipelineのデプロイフローをIaCで効率化
● CloudFormation（AWSのIaC）を採用して
● CodePipelineの一撃構築を実現
● シェルを実行するのみで、デプロイフローが構築されるようになった

やってみて良かったこと😊
● デプロイ方法が共通化された
● レビューを通過したコードのみがデプロイされるようになったので、安全になった
● リポジトリにPushすればデプロイされるので、デプロイが楽になった
● CodePipelineを「アプリケーション開発のフェーズ」から導入することで、高頻度なデプロイが可能になった
● サーバレスで構築したので、運用負担は無い
● アプリケーション開発に集中できるようになった

つらみ😂
● リポジトリ数が増加してしまう。
● リポジトリのブランチにCodePipelineが紐づくため、リポジトリをパイプラインに合わせた管理方法となって
しまう。
○ モノリシックリポジトリはCodePipelineだと管理できない。
○ 細かいLambdaのFunctionを一つのリポジトリにまとめて置くことができない。

まとめ
● CodePipelineでデプロイフローを構築することで、デプロイを自動化できる。
● マネージド・サービスのみで、構築可能なので、サーバに対する深い知見が不要で容易に構築できる。
○ インフラエンジニアがいなくても大丈夫？
● テスト段階から、デプロイフローを導入することで、開発スピードを向上できる。

以上

Deploy TypeScript with CodePipeline in Fargate

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Deploy TypeScript with CodePipeline in Fargate

Similar to Deploy TypeScript with CodePipeline in Fargate (20)

More from bitbank, Inc. Tokyo, Japan

More from bitbank, Inc. Tokyo, Japan (17)

Deploy TypeScript with CodePipeline in Fargate