Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GitlabとIstioでつくるコンテナネイティブCICD

 GitlabとIstioでつくるコンテナネイティブCICD

Shunsuke Miyoshi

December 03, 2018
Tweet

More Decks by Shunsuke Miyoshi

Other Decks in Technology

Transcript

  1. Who am I ? Kubernetesやってる人 コミュニティ開発だったり普及活動だったり・・・ Certified Kubernetes Administrator •

    たぶん日本最速?(2017年9月 β版時に取得) 休日もコード書いてます(・ω・)b GitHub(https://github.com/sh-miyoshi) 1 Copyright 2018 FUJITSU LIMITED
  2. 発表の対象者 & お伝えしたいこと 開発と運用チームがわかれている 2 Copyright 2018 FUJITSU LIMITED 開発チーム

    運用チーム 友好的な コミュニケーション どういったCI/CD(継続的インテグレーション/継続的デリバリー) のpipelineを書けばいいか
  3. Why Istio? CD(継続的デリバリー)ならSpinnaker(※)でも・・・ Istioはネットワークを制御できる CDだけをやりたいなら別ツールのほうが楽 運用を考えるなら個人的にはIstioがおすすめ 5 Copyright 2018 FUJITSU

    LIMITED ※Netflix社製OSS版のCDツール • どのサービスとどのサービスが つながっているんだっけ? • どれくらいアクセスされているんだっけ? • レイテンシは?
  4. (1)コード 開発 (2)コード品質 確保 (3)コード 統合 (5)成果物 テスト (6)デプロイ 開発チームのタスクの流れ

    運用チームのタスクの流れ 開発ブランチ作成 コーディング (場合により) ローカルレビュー Unit Test Code Analysis Reviewer のアサイン Pull Req 発行. 開発ブランチを masterにマージ マージされるごとに 自動バージョニング テスト環境に デプロイ テスト結果を 確認 リリース可否 判断 本番にデプロイ (Canary release) 状態確認 現用系 切り替え(BG) 失敗 リポジトリにpush (場合により) 自己レビュー (手動) 手動Review (コードとReview 用環境でチェック) 失敗 Review用 環境の準備 自動ビルド Docker registry に保存 registryから 手動(?)で取得 監視用のSidecar とかを追加 どこかで失敗したら開発チームへフィードバック (4)本番用 Appビルド ※アンダーラインが引いてある項目は自動で実行 CICDのpipelineの例(今日の本題) Copyright 2018 FUJITSU LIMITED 9 Gitlabの出番 Istioの出番
  5. Istioのイメージ図 10 Copyright 2018 FUJITSU LIMITED サービス A サービス B

    サービス C サービス D サービス E Istio Control Plane Envoy(Istio Data Plane) エッジプロキシ 各サービス間の通信を肩代わり Envoy間通信の監視と制御