CI/CDわからん awswakaran.tokyo #1

● 大木 裕介 (24) ○ SRE ● すき ○ アニメ/Node.js/Cloud ● Twitter ○ @_y_ohgi だれ

● CI/CDわからん ● CI/CDやってみようぜ ● まとめ はなすこと

● CI/CDわからん ● CI/CDやってみようぜ ● まとめ はなすこと

CI/CDわからん サービス開発がいい感じになるらしい

サービス開発の流れ 開発 テスト リリース 監視

● 継続的インテグレーション ● 開発物の品質担保 ● 自動でビルド&テストを実行 ○ gitのコミットを起点とするなど Continuous Integration 開発 テスト リリース 監視

● 開発時から意識しておくこともある ● 自動テストは可能か ○ そもそもテスト書いてますか？ ● 開発者間の事前の合意 ○ 各バージョン・コーディング規約 ○ PRはCIを通してからレビューするなど ● CIツールの選定 ○ CI上でDBなどを動かしたい ○ 複数バージョンのテストをしたい Continuous Integration 開発 テスト リリース 監視

- 継続的デプロイメント(/デリバリ) - ビルド&テストが終わった成果物を自動的 にリリース Continuous Deployment(/Delivery) 開発 テスト リリース 監視

● 監視も必要 ● 環境差分がある ○ テストが通っても環境差分でエラーは起きる ● バージョン差異に気づける仕組み ○ デプロイした直後など、複数バージョンが入り交じる状 況が起きる ○ エラーログを見るときに、新旧バージョン見分けられる 仕組みが必要 Continuous Deployment(/Delivery) 開発 テスト リリース 監視

サービス開発の流れ 開発 テスト リリース 監視

サービス開発の流れ 開発 テスト リリース 監視 ぐるぐる

● CI/CDわからん ● CI/CDやってみようぜ ● まとめ はなすこと

とりあえず やってみよーぜ！

ツールにあてはめてみる 開発 テスト リリース 監視

ツールにあてはめてみる 開発 テスト リリース 監視 ● GitHub Enterprise ○ みんな大好きGitHubの商用版 ● docker-compose ○ ローカル用dockerオーケストレーション ツール ○ 起動コマンドを統一可能 ○ 複数コンテナの起動可能

ツールにあてはめてみる 開発 テスト リリース 監視 ● CircleCI Enterprise ○ CIサービス ○ GitHub Enterpriseと連携が用意 ○ 基本的にcircleci.comと遜色なく使用 可能

ツールにあてはめてみる 開発 テスト リリース 監視 Amazon ECS Code 兄弟 ● Code兄弟 ○ マネージドなCDサービス ○ CodePipeline/CodeBuild/CodeDeployを利用 ● Amazon ECS ○ コンテナオーケストレーションツール ○ データプレーンにはFargateを活用

ツールにあてはめてみる 開発 テスト リリース 監視 Amazon ECS Code 兄弟 ● Datadog ○ 複数の環境（AWS/オンプレ/GCP/etc）を統合的に監 視可能 ○ メトリクスだけじゃなく、ロギングやトレースも可能

ツールにあてはめてみる 開発 テスト リリース 監視 Amazon ECS Code 兄弟 作ってみたらまだまだあった！

ツールにあてはめてみる 開発 テスト リリース 監視 Amazon ECS Code 兄弟 ここらへんがつらい 〜CIとCDの狭間〜

● 環境差分 ○ ステージングや本番など、どのフェーズ（ツール）で環境差分を吸収する？ ● migrationの実行 ○ DBのmigrationをどこで、だれが、いつ実行するのか ● サービス間の疎通 ○ マイクロサービス化していると、サービス間の疎通がつらい ● デプロイ手法の混在 ○ サービスによってデプロイ方法が違う CI/CDの狭間

環境差分 ● 環境は複数存在 ○ 本番/ステージング/QA/負荷試験/etc…、用途によって 複数存在 ● いつCI/CD実行する？ ○ ブランチをマージしたタイミング？ ○ タグを付けたタイミング？ ○ Dockerをpushしたタイミング？ ● とりあえず増やせるようにする ○ 本番/ステージングの2パターンだけ考慮して いると、あとからQAや負荷試験の要求が来た ときに詰む ○ とりあえず増やせるようにしておく master develop

● 1デプロイ1回 ○ 1回のデプロイサイクルで1度だけ実行されるようにす ることが重要 ○ コンテナ起動時にmigrationを行うとコンテナ起動毎に 実行されて死ぬ ● CDのサイクルの1部に組み込む ○ 例えばCodeBuildのような任意のコードを実行できる 場所で行う ○ ECRのイメージを使ったり、タスク定義からコンテナを 実行したり、既存の成果物を使用すると楽 migrationの実行 CodePipeline CodeBuild CodeDeploy Amazon ECS migrationの実行

● 複数のデプロイ手法が混在 ○ サービスが複数存在するようになってくるとデプロイ手 法が別れてくる ○ 「masterブランチにマージしたら」「tagをつけたら」 「Jenkinsから」とかとか... ● どうなるのか ○ デプロイが混在すると安易にデプロイできなくなる ○ ドキュメントをあさり続けることに（1週間後には忘却） ● 統一する ○ 隣のエンジニアに「ooをしたら本番にデプロイされる」こ とを教えなくて良い世界線へ デプロイ手法の混在 ？

● サービス間の疎通 ○ マイクロサービス化されていると複数のサービスが通 信できる必要がある ● 接続方法はいろいろある ○ 「エンドポイントは？」「ステージングだけIP開放申 請？」「認証認可は？」「プロトコルは？」 ● API Gateway ○ AWSのAPI Gatewayサービスじゃなく、microservice のAPI Gatewayパターン ● ServiceMesh ○ AppMeshとかIstioとか、サービス間の通信をいい感じ にしてくれる サービス間の疎通 https://www.appcentrica.com/the-rise-of-microservices/ App Mesh

● CI/CDわからん ● CI/CDやってみようぜ ● まとめ はなすこと

まとめ とりあえず やってみよーぜ！