Cloud Native Developers JP Qicoo開発プロジェクトの概要 あとGitOpsやCIの話 @hhiroshell 1

Cloud Native Developers JP • 早川 博（はやかわ ひろし） • 日本オラクル所属 – Cloud Nativeな技術スタック担当のSA – Microservices / DevOps • 遊舎工房さんの店舗に行きたい 自己紹介 @hhiroshell 2 ※ 遊舎工房さんの店舗はこちら

Cloud Native Developers JP Qicooとは • ぼくがかんがえた（将来的に）さいきょう のリアルタイムQA投稿アプリ • cndjp運営メンバーが深夜に開発 • Cloud Nativeな技術スタックの実験の場 3

Cloud Native Developers JP 本勉強会の質問はQicooにて受け付けます • https://qicoo.tokyo/ i 投稿いただいた質問データは、アプリの改善や今後よりよい機能を開発するうえでの 参考データとして保存・活用させていただきます。 個人や端末と紐づけて質問が保存されることはありません。 4

Cloud Native Developers JP 5 出来上がったもの 今日はコレを作った話です。

Cloud Native Developers JP お品書き • コミュニティ活動としてのOSSアプリ開発 • QicooのCI/CD – GitOpsの一般論 – やってみた！～CIのビューからみたGitOpsの実録 6

Cloud Native Developers JP コミュニティ活動としての OSSアプリ開発 7

Cloud Native Developers JP Qicooプロジェクトのモチベーション 勉強会であまり質問が出ない。せっかくのエンジニアが 集まる場で、インタラクションがないのはもったいない！ Cloud Nativeな技術を注ぎ込んで何か開発したいっす！ QAアプリ…？ ほほう…。 理想のQAアプリを作ってみよう！ コミュニティのボランティアベースでどこまでできるのか？ どういう開発のやり方ができるのか？会議は？ コミュニケーションは？費用の問題は…？ 8

Cloud Native Developers JP コミュニティ活動としてアプリを開発するということ • コミュニケーションをどう取るか – 会議 – 日常的な相談 • 費用はどうやって賄うか – 割り勘、スポンサー、副業…？ – なるべく安くしたい 9

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

Cloud Native Developers JP 費用の工夫 • 開発期間: 約3ヶ月(9/7～12/4) • ロゴのほうがお金かかったw • クラウドを必要ないときに確実に 落とす工夫（詳しくは後のセッ ションで） 新ロゴ ステッカー作成 ドメイン名 (99円/年) AWS GCP 新ロゴ デザイン費 合計 63,834円 11

Cloud Native Developers JP やってみてどうだった？ - 全体的な所感 • 技術的な障害を乗り越えるパワー – スキルの高さと吸収の速さ – Slackにヘルプすると、皆の知恵が総動員されて短期間で解決に至る • 本業を抱えながら、労力をOSS開発に注ぐのはやはり難しい – 油断すると作業が滞りがちになる（しかたない） – プロジェクトメンバーのモチベーションに支えられた面が大きいのは 反省点。メンバーに感謝 12

Cloud Native Developers JP QicooのCI/CD

Cloud Native Developers JP QicooのCI/CD 目次 • GitOpsの一般論 • やってみた！～CIのビューからみたGitOpsの実録 14

Cloud Native Developers JP QicooにおけるCI/CDの最大の特徴 • GitOpsを取り入れている • なぜ…？ – やってみたかったから！！ – 流行ってるしモテると聞いたので 15

Cloud Native Developers JP GitOpsとは • CI/CDを行うための手法のひとつ • 2017年にロンドン発のスタートアップ「Weaveworks」社によって提 唱された • Gitリポジトリのコードを起点にして、システムの実行環境やアプリ ケーションの変更を行う手法 16

Cloud Native Developers JP 従来型のCI/CDの課題 • CIツール側で全てのデプロイ先との連携設定を管理する必要がある – 管理が煩雑。Attackされるとやばい • 最新のmanifestが環境を表現しているとは限らない – ジョブの実行順序が保証されないため • オペレーションにCIツール固有の操作が入り込む 17 CIツール アプリケーション コード Dev コンテナレジストリ Prod Dev Stagin g コードをプッシュ > docker push > kubectl apply

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)

Cloud Native Developers JP GitOpsによる課題の解決 従来型のCI/CDの課題 GitOpsによる解決方法 CIツール側で全てのデプロイ先との連携設定を 管理する必要がある • 環境が増えると管理が煩雑 • Attackされるとやばい 理想形では、クラスター内のエージェントが Single Source of Truthを参照しに行く（Pull 型）。CIとの連携方法はクラスター側が知って いる 最新のmanifestが環境を表現しているとは限ら ない（※ ジョブの実行順序が保証されないため） クラスター内のエージェントがクラスターの状 態とSingle Source of Truthの差分を検出して、 一致させるように動作する オペレーションにCIツール固有の操作が入り込 む 運用のインターフェースはGitに統一 19

Cloud Native Developers JP QicooのCI/CD 目次 • GitOpsの一般論 • やってみた！～CIのビューからみたGitOpsの実録 20

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)

Cloud Native Developers JP Kustomize • ベースのmanifestを元に、バリエーションを生成するツール • 変更したい部分だけを抜粋したmanifest(Overlay)をベースに被せる仕 組み 22

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

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

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と同じものを つかう。

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) ;¥ …

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

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); ¥

Cloud Native Developers JP GitOpsを実践して感じたもろもろ • 構築の難しさ – 多くのCIツールがGitOpsのユースケースを想定していないので、結局シェルに 依存しがちになる – CIツール、テンプレートエンジン、CDツールを覚えないと構築できない。CD とそれ以外で分担すると良さげ • CDとの相性 – Kustomize + Spinnaker は相性が良い • カナリーデプロイメントで必要な複数のmanifest（イメージタグだけ違う）を用意するには、 Kustomizeが手軽で使いやすい 29

Cloud Native Developers JP GitOpsを実践して感じたもろもろ • 拡張性 – アプリの数が増えると複数のアプリのCIジョブからひとつのテンプレートが更 新されることになるので要注意。ライフサイクルが違うアプリはテンプレー トを分けたほうが良いのかも？ – 環境の数が増える分には、対応しやすそう • 運用管理性 – CI/CDがピタゴラスイッチ状態に • 起点となるアプリのコードの更新と、一連のCI/CDの動きを紐付けて把握しにくい。どのビ ルドがどこまで進んだか • 途中でコケたとき何をどうすれば正常な状態に戻せるんだっけ…となる – 継続的に動かし続けて安定稼働を維持することが大事 30

Cloud Native Developers JP Fin. 31