awswakaran.tokyo_CI_CD

awswakaran.tokyo の登壇資料です

Transcript

1. CI/CDわからん awswakaran.tokyo #1
2. • 大木 裕介 (24) ◦ SRE • すき ◦ アニメ/Node.js/Cloud • Twitter ◦ @_y_ohgi だれ
3. • CI/CDわからん • CI/CDやってみようぜ • まとめ はなすこと
4. • CI/CDわからん • CI/CDやってみようぜ • まとめ はなすこと
5. CI/CDわからん サービス開発がいい感じになるらしい
6. サービス開発の流れ 開発 テスト リリース 監視
7. • 継続的インテグレーション • 開発物の品質担保 • 自動でビルド&テストを実行 ◦ gitのコミットを起点とするなど Continuous Integration 開発 テスト リリース 監視
8. • 開発時から意識しておくこともある • 自動テストは可能か ◦ そもそもテスト書いてますか？ • 開発者間の事前の合意 ◦ 各バージョン・コーディング規約 ◦ PRはCIを通してからレビューするなど • CIツールの選定 ◦ CI上でDBなどを動かしたい ◦ 複数バージョンのテストをしたい Continuous Integration 開発 テスト リリース 監視
9. - 継続的デプロイメント(/デリバリ) - ビルド&テストが終わった成果物を自動的 にリリース Continuous Deployment(/Delivery) 開発 テスト リリース 監視
10. • 監視も必要 • 環境差分がある ◦ テストが通っても環境差分でエラーは起きる • バージョン差異に気づける仕組み ◦ デプロイした直後など、複数バージョンが入り交じる状 況が起きる ◦ エラーログを見るときに、新旧バージョン見分けられる 仕組みが必要 Continuous Deployment(/Delivery) 開発 テスト リリース 監視
11. サービス開発の流れ 開発 テスト リリース 監視
12. サービス開発の流れ 開発 テスト リリース 監視 ぐるぐる
13. • CI/CDわからん • CI/CDやってみようぜ • まとめ はなすこと
14. とりあえず やってみよーぜ！
15. ツールにあてはめてみる 開発 テスト リリース 監視
16. ツールにあてはめてみる 開発 テスト リリース 監視 • GitHub Enterprise ◦ みんな大好きGitHubの商用版 • docker-compose ◦ ローカル用dockerオーケストレーション ツール ◦ 起動コマンドを統一可能 ◦ 複数コンテナの起動可能
17. ツールにあてはめてみる 開発 テスト リリース 監視 • CircleCI Enterprise ◦ CIサービス ◦ GitHub Enterpriseと連携が用意 ◦ 基本的にcircleci.comと遜色なく使用 可能
18. ツールにあてはめてみる 開発 テスト リリース 監視 Amazon ECS Code 兄弟 • Code兄弟 ◦ マネージドなCDサービス ◦ CodePipeline/CodeBuild/CodeDeployを利用 • Amazon ECS ◦ コンテナオーケストレーションツール ◦ データプレーンにはFargateを活用
19. ツールにあてはめてみる 開発 テスト リリース 監視 Amazon ECS Code 兄弟 • Datadog ◦ 複数の環境（AWS/オンプレ/GCP/etc）を統合的に監 視可能 ◦ メトリクスだけじゃなく、ロギングやトレースも可能
20. ツールにあてはめてみる 開発 テスト リリース 監視 Amazon ECS Code 兄弟 作ってみたらまだまだあった！
21. ツールにあてはめてみる 開発 テスト リリース 監視 Amazon ECS Code 兄弟 ここらへんがつらい 〜CIとCDの狭間〜
22. • 環境差分 ◦ ステージングや本番など、どのフェーズ（ツール）で環境差分を吸収する？ • migrationの実行 ◦ DBのmigrationをどこで、だれが、いつ実行するのか • サービス間の疎通 ◦ マイクロサービス化していると、サービス間の疎通がつらい • デプロイ手法の混在 ◦ サービスによってデプロイ方法が違う CI/CDの狭間
23. 環境差分 • 環境は複数存在 ◦ 本番/ステージング/QA/負荷試験/etc…、用途によって 複数存在 • いつCI/CD実行する？ ◦ ブランチをマージしたタイミング？ ◦ タグを付けたタイミング？ ◦ Dockerをpushしたタイミング？ • とりあえず増やせるようにする ◦ 本番/ステージングの2パターンだけ考慮して いると、あとからQAや負荷試験の要求が来た ときに詰む ◦ とりあえず増やせるようにしておく master develop
24. • 1デプロイ1回 ◦ 1回のデプロイサイクルで1度だけ実行されるようにす ることが重要 ◦ コンテナ起動時にmigrationを行うとコンテナ起動毎に 実行されて死ぬ • CDのサイクルの1部に組み込む ◦ 例えばCodeBuildのような任意のコードを実行できる 場所で行う ◦ ECRのイメージを使ったり、タスク定義からコンテナを 実行したり、既存の成果物を使用すると楽 migrationの実行 CodePipeline CodeBuild CodeDeploy Amazon ECS migrationの実行
25. • 複数のデプロイ手法が混在 ◦ サービスが複数存在するようになってくるとデプロイ手 法が別れてくる ◦ 「masterブランチにマージしたら」「tagをつけたら」 「Jenkinsから」とかとか... • どうなるのか ◦ デプロイが混在すると安易にデプロイできなくなる ◦ ドキュメントをあさり続けることに（1週間後には忘却） • 統一する ◦ 隣のエンジニアに「ooをしたら本番にデプロイされる」こ とを教えなくて良い世界線へ デプロイ手法の混在 ？
26. • サービス間の疎通 ◦ マイクロサービス化されていると複数のサービスが通 信できる必要がある • 接続方法はいろいろある ◦ 「エンドポイントは？」「ステージングだけIP開放申 請？」「認証認可は？」「プロトコルは？」 • API Gateway ◦ AWSのAPI Gatewayサービスじゃなく、microservice のAPI Gatewayパターン • ServiceMesh ◦ AppMeshとかIstioとか、サービス間の通信をいい感じ にしてくれる サービス間の疎通 https://www.appcentrica.com/the-rise-of-microservices/ App Mesh
27. • CI/CDわからん • CI/CDやってみようぜ • まとめ はなすこと
28. まとめ とりあえず やってみよーぜ！