Save 37% off PRO during our Black Friday Sale! »

awswakaran.tokyo_CI_CD

4365312f9f662ab058e50d1459165e5f?s=47 y-ohgi
July 22, 2019
2k

 awswakaran.tokyo_CI_CD

awswakaran.tokyo の登壇資料です

4365312f9f662ab058e50d1459165e5f?s=128

y-ohgi

July 22, 2019
Tweet

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. まとめ とりあえず やってみよーぜ!