Qicoo開発プロジェクトの概要-あとGitOpsやCIの話 / qicoo-gitops

36bb9dcd778d2a9621d44e92425d0907?s=47 hhiroshell
January 30, 2019

Qicoo開発プロジェクトの概要-あとGitOpsやCIの話 / qicoo-gitops

cndjp第9回勉強会での発表資料です。
タイトルの通り、Qicoo開発プロジェクトの概要とQicooで取り組んだCI、GitOpsについて。

36bb9dcd778d2a9621d44e92425d0907?s=128

hhiroshell

January 30, 2019
Tweet

Transcript

  1. 2.

    Cloud Native Developers JP • 早川 博(はやかわ ひろし) • 日本オラクル所属

    – Cloud Nativeな技術スタック担当のSA – Microservices / DevOps • 遊舎工房さんの店舗に行きたい 自己紹介 @hhiroshell 2 ※ 遊舎工房さんの店舗はこちら
  2. 6.

    Cloud Native Developers JP お品書き • コミュニティ活動としてのOSSアプリ開発 • QicooのCI/CD –

    GitOpsの一般論 – やってみた!~CIのビューからみたGitOpsの実録 6
  3. 8.

    Cloud Native Developers JP Qicooプロジェクトのモチベーション 勉強会であまり質問が出ない。せっかくのエンジニアが 集まる場で、インタラクションがないのはもったいない! Cloud Nativeな技術を注ぎ込んで何か開発したいっす! QAアプリ…?

    ほほう…。 理想のQAアプリを作ってみよう! コミュニティのボランティアベースでどこまでできるのか? どういう開発のやり方ができるのか?会議は? コミュニケーションは?費用の問題は…? 8
  4. 9.

    Cloud Native Developers JP コミュニティ活動としてアプリを開発するということ • コミュニケーションをどう取るか – 会議 –

    日常的な相談 • 費用はどうやって賄うか – 割り勘、スポンサー、副業…? – なるべく安くしたい 9
  5. 10.

    Cloud Native Developers JP コミュニケーションの工夫 • 無料のオンラインツールをフル活用 – ドキュメンテーション: Scrapbox

    – タスク管理: Trello – 日常のコミュニケーション: Slackの専用チャンネル – オンライン会議(適宜): Discord(画面共有しながら) • これらのツールをフル活用すると、対面で打ち合わせする頻度をか なり抑えられる。大体1回/月で済んだ • 費用はゼロ。リモートでも無理なく作業を進められる 10
  6. 11.

    Cloud Native Developers JP 費用の工夫 • 開発期間: 約3ヶ月(9/7~12/4) • ロゴのほうがお金かかったw

    • クラウドを必要ないときに確実に 落とす工夫(詳しくは後のセッ ションで) 新ロゴ ステッカー作成 ドメイン名 (99円/年) AWS GCP 新ロゴ デザイン費 合計 63,834円 11
  7. 12.

    Cloud Native Developers JP やってみてどうだった? - 全体的な所感 • 技術的な障害を乗り越えるパワー –

    スキルの高さと吸収の速さ – Slackにヘルプすると、皆の知恵が総動員されて短期間で解決に至る • 本業を抱えながら、労力をOSS開発に注ぐのはやはり難しい – 油断すると作業が滞りがちになる(しかたない) – プロジェクトメンバーのモチベーションに支えられた面が大きいのは 反省点。メンバーに感謝 12
  8. 15.

    Cloud Native Developers JP QicooにおけるCI/CDの最大の特徴 • GitOpsを取り入れている • なぜ…? –

    やってみたかったから!! – 流行ってるしモテると聞いたので 15
  9. 16.

    Cloud Native Developers JP GitOpsとは • CI/CDを行うための手法のひとつ • 2017年にロンドン発のスタートアップ「Weaveworks」社によって提 唱された

    • Gitリポジトリのコードを起点にして、システムの実行環境やアプリ ケーションの変更を行う手法 16
  10. 17.

    Cloud Native Developers JP 従来型のCI/CDの課題 • CIツール側で全てのデプロイ先との連携設定を管理する必要がある – 管理が煩雑。Attackされるとやばい •

    最新のmanifestが環境を表現しているとは限らない – ジョブの実行順序が保証されないため • オペレーションにCIツール固有の操作が入り込む 17 CIツール アプリケーション コード Dev コンテナレジストリ Prod Dev Stagin g コードをプッシュ > docker push > kubectl apply
  11. 18.

    Cloud Native Developers JP GitOpsの核となるアイデア • Single Source of Truth

    – Gitリポジトリ上のコードでインフラとアプリケーションの状態が決定する – Single Source of Truthを介してCIとCDを分離する • 状態の差分検出とconversion – 実行環境がSingle Source of Truthとの差分を検出して自律的に状態を変える(Pull型) – 環境の差分が解消されない場合は、アラートを上げる 18 実行環境 差分検出 装置 自環境に 差分を反映 (conversion) CIツール Ops CD CI PR 運用操作 PR アプリの更新 Single Source of Truth (manifest)
  12. 19.

    Cloud Native Developers JP GitOpsによる課題の解決 従来型のCI/CDの課題 GitOpsによる解決方法 CIツール側で全てのデプロイ先との連携設定を 管理する必要がある •

    環境が増えると管理が煩雑 • Attackされるとやばい 理想形では、クラスター内のエージェントが Single Source of Truthを参照しに行く(Pull 型)。CIとの連携方法はクラスター側が知って いる 最新のmanifestが環境を表現しているとは限ら ない(※ ジョブの実行順序が保証されないため) クラスター内のエージェントがクラスターの状 態とSingle Source of Truthの差分を検出して、 一致させるように動作する オペレーションにCIツール固有の操作が入り込 む 運用のインターフェースはGitに統一 19
  13. 21.

    Cloud Native Developers JP 21 QicooにおけるCI/CDの実装 PR: 運用操作 Travis CI

    コンテナレジストリ PR:Kustomizeで環境毎の Manifestを作る アプリケーションコード コードをプッシュ > docker push NS: production Single Source of Truth テンプレート manifest(staging) NS: staging NS: development Spinnaker manifest(prod)
  14. 23.

    Cloud Native Developers JP 23 Qicooのブランチ戦略とCI/CDとの絡み releaseブランチ → staging Feature

    A ブランチ 新たな機能を追加する場合は、 release branchから派生させて実装 ローカル環境で開発なので、CIのみ masterブランチ → production Feature B ブランチ release branchにマージすると、 EKSのstaging環境にCD master branchにマージすると、 EKSのproduction環境にCD
  15. 24.

    Cloud Native Developers JP 24 releaseブランチへのプッシュ TravisCIのジョブ コンテナレジストリ アプリケーションコード releaseブランチにプッシュ

    > docker push NS: production Single Source of Truth テンプレート manifest(staging) NS: staging NS: development manifest(prod) パラメータファイルを作成してプッシュ • どの環境用のmanifestを作るか • デプロイするイメージのタグ パラメータファイルに従って manifestを作成しPR (Kustomize) Spinnaker
  16. 25.

    Cloud Native Developers JP 25 masterブランチへのプッシュ TravisCIのジョブ コンテナレジストリ アプリケーションコード masterブランチにプッシュ

    NS: production Single Source of Truth テンプレート manifest(staging) NS: staging NS: development Spinnaker manifest(prod) パラメータファイルを作成してプッシュ • どの環境用のmanifestを作るか パラメータファイルに従って manifestを作成しPR (Kustomize) イメージは更新しない stagingと同じものを つかう。
  17. 26.

    Cloud Native Developers JP アプリケーションコードのTravisのジョブ • 更新されたブランチ名を拾って、それをもとにパラメータファイル を作っている – release

    → イメージタグと更新する環境 – master → イメージタグ • https://github.com/cndjp/qicoo-api/blob/81b66433d0cfc50937d1398f01ffcbf81e8071d7/Makefile#L220 26 @if test "$(TRAVIS_BRANCH)" = "master"; ¥ then ¥ sed -i -e '/^branch: release/s/release/master/gi' $(HOME)/qicoo-api-manifests/$(KUSTOMIZE_ACTION_FILE_NAME); ¥ elif test "$(TRAVIS_BRANCH)" = "release"; ¥ then ¥ echo 'branch: release' > $(HOME)/qicoo-api-manifests/$(KUSTOMIZE_ACTION_FILE_NAME) ;¥ echo 'tag: $(DOCKER_IMAGE_TAG)' >> $(HOME)/qicoo-api-manifests/$(KUSTOMIZE_ACTION_FILE_NAME) ;¥ …
  18. 27.

    Cloud Native Developers JP manifestのテンプレートとパラメータファイル • manifestテンプレートのリポジトリではmasterブランチしか使わない。 環境ごとの差分設定(KustomizeのOverlayのこと)はディレクトリで 分ける –

    Kustomizeの作法に乗っ取ったやり方 – 今動いている全環境が俯瞰して見られる(いちいち git checkout は面倒) • パラメータファイルで次に作成すべきmanifestを指示 – 環境ごとのmanifestを作るときに参照される – Travisに対して動作を細かく指示できる(バリエーションを簡単に足せる) – https://github.com/cndjp/qicoo-api-manifests/blob/master/kustomize-action.yaml 27 branch: master tag: v0.0.1-20181202-1018
  19. 28.

    Cloud Native Developers JP マニフェストのテンプレートのTravisのジョブ • パラメータファイルを元に環境ごとのmanifestを作っている – manifestの生成はKustomizeを利用 –

    https://github.com/cndjp/qicoo-api-manifests/blob/c1e7e38f1a38b9de44ad0c8c359bccd2411eacd1/Makefile#L11 – https://github.com/cndjp/qicoo-api-manifests/blob/c1e7e38f1a38b9de44ad0c8c359bccd2411eacd1/Makefile#L60 28 ifeq ($(UPDATED_BRANCH), "release") PATCH_DIR := overlays/staging REPOSITORY := https://github.com/cndjp/qicoo-api-manifests-staging.git else ifeq ($(UPDATED_BRANCH), "master") … kustomize-build: $(eval KUSTOMIZE := $(shell echo $(HOME)/kustomize)) mkdir $(MANIFEST_DIR) find $(PATCH_DIR) -type f | xargs sed -i -e "s/@@NEW_TAG@@/$(DOCKER_IMAGE_TAG)/g" $(KUSTOMIZE) build $(PATCH_DIR) -o $(MANIFEST_DIR)/$(MANIFEST_FINAL_NAME_ALL) @if test "$(UPDATED_BRANCH)" = "master"; ¥ then ¥ $(KUSTOMIZE) build $(PATCH_DIR_BASE) -o $(MANIFEST_DIR)/$(MANIFEST_FINAL_NAME_BASE); ¥ $(KUSTOMIZE) build $(PATCH_DIR_CANARY) -o $(MANIFEST_DIR)/$(MANIFEST_FINAL_NAME_CANARY); ¥
  20. 29.

    Cloud Native Developers JP GitOpsを実践して感じたもろもろ • 構築の難しさ – 多くのCIツールがGitOpsのユースケースを想定していないので、結局シェルに 依存しがちになる

    – CIツール、テンプレートエンジン、CDツールを覚えないと構築できない。CD とそれ以外で分担すると良さげ • CDとの相性 – Kustomize + Spinnaker は相性が良い • カナリーデプロイメントで必要な複数のmanifest(イメージタグだけ違う)を用意するには、 Kustomizeが手軽で使いやすい 29
  21. 30.

    Cloud Native Developers JP GitOpsを実践して感じたもろもろ • 拡張性 – アプリの数が増えると複数のアプリのCIジョブからひとつのテンプレートが更 新されることになるので要注意。ライフサイクルが違うアプリはテンプレー

    トを分けたほうが良いのかも? – 環境の数が増える分には、対応しやすそう • 運用管理性 – CI/CDがピタゴラスイッチ状態に • 起点となるアプリのコードの更新と、一連のCI/CDの動きを紐付けて把握しにくい。どのビ ルドがどこまで進んだか • 途中でコケたとき何をどうすれば正常な状態に戻せるんだっけ…となる – 継続的に動かし続けて安定稼働を維持することが大事 30