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

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

hhiroshell
January 30, 2019

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

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

hhiroshell

January 30, 2019
Tweet

More Decks by hhiroshell

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  13. Cloud Native Developers JP
    QicooのCI/CD

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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)

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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)

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  31. Cloud Native Developers JP
    Fin.
    31

    View full-size slide