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

Spinnakerでハマった6個のポイント #cndjp / spinnaker-hamari...

sugimount
January 30, 2019

Spinnakerでハマった6個のポイント #cndjp / spinnaker-hamari-six-point

sugimount

January 30, 2019
Tweet

More Decks by sugimount

Other Decks in Technology

Transcript

  1. Who? 2 • 名前:杉山 卓 (すぎやま すぐる) • 趣味:ベース 歴7年

    • 会社:某SIer インフラエンジニア @sugimount • 好きな作曲家:田中秀和 主にアニメ・ゲームへ楽曲提供 キャッチーなメロディーラインと、耳に残るコード進行がエモい。大好き
  2. もくじ 5 Qicooのアーキテクチャ 1 2 Spinnakerとは 3 Spinnakerのハマりポイント - Install

    - PipelineのArtifactの扱い - Pipelineの手動実行 4 - カナリアリリースの構成 - カナリアリリースの課題 - おうちKubernetesで検証 CI/CDとは
  3. もくじ 6 Qicooのアーキテクチャ 1 2 Spinnakerとは 3 Spinnakerのハマりポイント - Install

    - PipelineのArtifactの扱い - Pipelineの手動実行 4 - カナリアリリースの構成 - カナリアリリースの課題 - おうちKubernetesで検証 CI/CDとは
  4. もくじ 10 Qicooのアーキテクチャ 1 2 Spinnakerとは 3 Spinnakerのハマりポイント - Install

    - PipelineのArtifactの扱い - Pipelineの手動実行 4 - カナリアリリースの構成 - カナリアリリースの課題 - おうちKubernetesで検証 CI/CDとは
  5. もくじ 13 Qicooのアーキテクチャ 1 2 Spinnakerとは 3 Spinnakerのハマりポイント - Install

    - PipelineのArtifactの扱い - Pipelineの手動実行 4 - カナリアリリースの構成 - カナリアリリースの課題 - おうちKubernetesで検証 CI/CDとは
  6. Spinnakerとは 14 • CD(継続的デリバリー)ツール • Netflix・Googleにより公開されているOSS。2015年に公開 • ローリングアップデート、カナリアリリース、Blue/Greenアップデート、承認、ロールバックといった、 継続的デリバリーに必要な機能が備えられている •

    Multi-Cloudに対応しており、様々なPlatformを抽象化し、自動化に対応することが可能 • 自分はKubernetes界隈でSpinnakerを知ったので、Kubernetes専用のツールだと 思っていたが、Multi-Cloudに対応しているかっこいいツール
  7. Spinnakerで出来ることの例 16 • Kubernetesでローリングアップデート apiVersion: apps/v1 kind: Deployment metadata: name:

    qicoo-api namespace: staging spec: replicas: 2 ----- snip ----- spec: containers: image: cndjp/qicoo-api:v2 push Webhookで通知 Kubernetesの機能で ローリングアップデート 新たなバージョンのImageを指定 Webhookの通知先を Spinnakerへ設定
  8. アーキテクチャ 17 https://www.spinnaker.io/reference/architecture/ コンポーネント名 概要 Deck SpinnakerのWebUIを提供 Gate API Gateway

    各種操作を実行するAPIエンドポイントを提供 Orca オーケストレーションエンジン Clouddriver クラウド環境へのDeployなどの操作を管理 Front50 メタデータやパイプライン、プロジェクト、通知の管理 Rosco 仮想マシンイメージの作成機能を提供 Hashicorpのpackerを利用している Igor CI(継続的インテグレーション経由)で 処理を行うためのトリガーを管理 Echo イベントや通知の管理 Fiat 認証機能を提供 Kayenta 自動カナリア分析を提供
  9. もくじ 18 Qicooのアーキテクチャ 1 2 Spinnakerとは 3 Spinnakerのハマりポイント - Install

    - PipelineのArtifactの扱い - Pipelineの手動実行 4 - カナリアリリースの構成 - カナリアリリースの課題 - おうちKubernetesで検証 CI/CDとは
  10. ハマり1. Spinnakerのインストール(Halyard) 20 • Halyardの使い方にハマった • 以下の設定を行う必要があったが、Documentに無い部分もあり、試行錯誤 • Cloud Providerの指定

    (Kubernetes v2) • Artifactの有効化 • Spinnakerの永続ストレージの指定 (S3) • Slack通知の有効化 • GitHubのアカウント設定 • DockerHubの設定 • Timezoneの指定 • Kayentaの有効化 • 解決方法 次を参照:詳細な設定方法 Qiita https://qiita.com/sugimount/items/0627f99b1bdabf511927 Example halyard config > hal config provider kubernetes enable > hal config deploy edit --type distributed --account-name ¥ kubernetes-admin > hal config storage s3 edit --endpoint $ENDPOINT ¥ --access-key-id $ACCESS_KEY ¥ --secret-access-key > hal config notification slack edit --bot-name ¥ $SPINNAKER_BOT --token Spinnaker Deploy > hal deploy apply > hal deploy connect
  11. ハマり2. Artifactの扱い 21 • Spinnakerには、Artifactと呼ばれている外部リソースを扱う概念がある • 代表的なArtifactは以下 • DockerImage •

    GitHub上のFile • S3上のFile • Kubernetes上のリソース Pipeline 自動処理1 自動処理2 自動処理3 Artifact 外部リソースを登録 例:GitHub上のマニフェストファイル Pipeline上の自動処理で Artifactを利用
  12. ハマり2. Artifactの扱い 22 • Artifactに、[GitHubのFile] と [DockerHubのImage] の2つを定義して Pipelineを動かすことが出来なかった (自分の検証範囲。これ以外のものもハマると思う)

    • 以下のSpinnakerの挙動となっているため • Artifactへ登録できるものは、Pipelineの開始トリガーに関連するもののみ • GitHubのpushをPipelineのトリガーとすると、git add で変更・追加したもののみArtifactに登録される • 開始トリガーに関係ないものは、基本的にはArtifactとして登録されない • Pipelineに定義したArtifactのすべてがSpinnakerに登録されないとエラーとなる Pipeline Artifact1 Artifact2 GitHubのPushをトリガー GitHubはArtifactへ登録 DockerHubはArtifactへ 登録されない OK NG
  13. ハマり3. Pipelineの手動実行 25 • 解決方法1 GitHubへPushして、Pipelineを起動させる • 解決方法2 Pipelineのデバッグなどで、GitHubへPushするのがめんどくさいときは、 GitHubのUI・

    curlコマンドで手動実行が可能 • GitHubにPushしてWebhookを実行すると、Webhookのイベントの詳細をGitHub上で確 認することが可能
  14. ハマり4. カナリアリリースの構成方法 31 • GitHubへマニフェストファイルをPushし、Pipelineをトリガー。SpinnakerはArtifactを登録 いまここ Deployment Manifest Production用 image

    : cndjp/qicoo-api:v2 Deployment Manifest Baseline用 image : cndjp/qicoo-api Deployment Manifest Canary用 image : cndjp/qicoo-api:v2 Production用で使用 カナリア分析のために 一時的に使用 バージョンは空白 カナリア分析のために 一時的に使用 Artifact1 Production Artifact2 Baseline Artifact3 Canary push webhook
  15. ハマり4. カナリアリリースの構成方法 32 • CanaryのDeploymentがapplyされる いまここ Artifact1 Production Artifact2 Baseline

    Artifact3 Canary Deployment Production Pod94個 Image : cndjp/qicoo-api:v1 Kubernetesクラスタ Service LoadBalancer app: qicoo-api apply Deployment Canary Pod3個 Image : cndjp/qicoo-api:v2 app: qicoo-api app: qicoo-api
  16. ハマり4. カナリアリリースの構成方法 33 • Production で使用しているDockerImageのバージョンを取得 (バージョン1を取得) いまここ Artifact1 Production

    Artifact2 Baseline Artifact3 Canary Deployment Production Pod94個 Image : cndjp/qicoo-api:v1 Kubernetesクラスタ Service LoadBalancer app: qicoo-api Deployment Canary Pod3個 Image : cndjp/qicoo-api:v2 app: qicoo-api app: qicoo-api DockerImageの バージョンを取得 Artifact4 qicoo-api:v1
  17. ハマり4. カナリアリリースの構成方法 34 • 取得したバージョンを、Baseline用のマニフェストに紐づける いまここ Artifact1 Production Artifact2 Baseline

    Artifact3 Canary Artifact4 qicoo-api:v1 Deployment Manifest Baseline用 image : cndjp/qicoo-api → cndjp/qicoo-api:v1 バージョンを紐づけて、空白をv1へ書き換える
  18. ハマり4. カナリアリリースの構成方法 35 • Baseline用のマニフェストファイルをapplyする いまここ Artifact1 Production Artifact2 Baseline

    Artifact3 Canary Artifact4 qicoo-api:v1 Deployment Production Pod94個 Image : cndjp/qicoo-api:v1 Kubernetesクラスタ Service LoadBalancer app: qicoo-api Deployment Canary Pod3個 Image : cndjp/qicoo-api:v2 app: qicoo-api app: qicoo-api apply Deployment Baseline Pod3個 Image : cndjp/qicoo-api:v1 app: qicoo-api
  19. ハマり4. カナリアリリースの構成方法 36 • この構成の問題点 • トラフィックの分散は、Podの数に依 存する (LoadBalancerの分散) •

    KubernetesクラスタにIstioや、 NginxIngressControllerを 入れることで、解消できそう (まだやってない。 誰かやったら教えてほしい) いまここ Deployment Production Pod94個 Image : cndjp/qicoo-api:v1 Kubernetesクラスタ Service LoadBalancer app: qicoo-api Deployment Canary Pod3個 Image : cndjp/qicoo-api:v2 app: qicoo-api app: qicoo-api Deployment Baseline Pod3個 Image : cndjp/qicoo-api:v1 app: qicoo-api 94% 3% 3%
  20. ハマり4. カナリアリリースの構成方法 37 BaselineとCanary間で重要なMetricを比較し、 Canaryの正常性を自動分析 (Kayenta) いまここ Deployment Production Pod94個

    Image : cndjp/qicoo-api:v1 Kubernetesクラスタ Service LoadBalancer app: qicoo-api Deployment Canary Pod3個 Image : cndjp/qicoo-api:v2 app: qicoo-api app: qicoo-api Deployment Baseline Pod3個 Image : cndjp/qicoo-api:v1 app: qicoo-api 94% 3% 3% monitoring OKであれば次のステージへ進む NGであれば、そこでPipelineを止める • カナリア自動分析
  21. Canary Analysis ベストプラクティス 38 https://www.spinnaker.io/guides/user/canary/best-practices/ • 比較するべきメトリック • レイテンシー •

    アプリケーションへRequestしてから、Responseが返ってくるまでの時間 • Errorの率 • Requestを失敗したError率 • 飽和 • Systemに影響のあるリソースの飽和度を比較 例えば、メモリが重要なシステムはメモリ使用量。ストレージI/Oが重要なシステムはI/Oのレイテンシーなど
  22. Canary Analysis ベストプラクティス 39 https://www.spinnaker.io/guides/user/canary/best-practices/ • 数時間カナリアを実行して、メトリックを比較する • 必ずしもBestではないが、3時間を基準にカナリアを実行するのが良い •

    短時間のメトリック比較では、値の信頼性が落ちるため • 現行バージョン(v1)として新たにBaselineをDeployして、Canaryと比較する • Production環境で稼働しているPodとCanaryを比較したくなるが、適切ではない • 長時間稼働しているProduction環境のものは、新たに構成したCanaryとは条件が異なるため • その他のベストプラクティスは下のURLを参照
  23. ハマり4. カナリアリリースの構成方法 40 いまここ Deployment Production Pod94個 Image : cndjp/qicoo-api:v1

    Kubernetesクラスタ Service LoadBalancer app: qicoo-api Deployment Canary Pod3個 Image : cndjp/qicoo-api:v2 app: qicoo-api app: qicoo-api Deployment Baseline Pod3個 Image : cndjp/qicoo-api:v1 Artifact1 Production Artifact2 Baseline Artifact3 Canary Baselineの削除 • Baselineの削除
  24. ハマり4. カナリアリリースの構成方法 41 いまここ Deployment Production Pod94個 Image : cndjp/qicoo-api:v1

    Kubernetesクラスタ Service LoadBalancer app: qicoo-api Deployment Canary Pod3個 Image : cndjp/qicoo-api:v2 app: qicoo-api Artifact1 Production Artifact2 Baseline Artifact3 Canary Canaryの削除 • Canaryの削除
  25. ハマり4. カナリアリリースの構成方法 42 いまここ Deployment Production Pod94個 Image : cndjp/qicoo-api:v2

    Kubernetesクラスタ Service LoadBalancer app: qicoo-api app: qicoo-api Artifact1 Production Artifact2 Baseline Artifact3 Canary apply • Productionのローリングアップデート
  26. ハマり5. カナリアリリースの課題 43 • Backend(REST API : JSON)のカナリアリリースを実施したが、以下の課題がある (未解決) •

    特定のユーザに限定して、カナリアをアクセスさせたい • LoadBalancerではラウンドロビンとなってしまうため、アクセスするたびに機能が変化してしまう • Istio の LoadBalancerSetting にある sticky session を使用すると、特定のユーザに限定したカナリア が出来そう。 • https://istio.io/docs/reference/config/istio.networking.v1alpha3/#LoadBalancerSettings • Frontendとの兼ね合い • Backendはカナリアしたとして、Frontendはどうするべき? • BackendとFrontendを同期してカナリア?どうやって実現? • アップデート内容によって、カナリアをしたいときと、したくないときがありそう • 良い方法がありそうならディスカッションしたい
  27. ハマり6. おうちKubernetesで検証 45 • 解決方法 local環境を公開するサービスを使う • UltraHook ←自分はコレで検証した •

    Ngrok ※ Globalに晒すことになるので、セキュリティに気を付けてください http://xxx.zzz.ultrahook.com/ UltraHook
  28. まとめ 46 • Spinnakerのハマリポイントのお話 - Install - PipelineのArtifactの扱い - Pipelineの手動実行

    - カナリアリリースの構成 - カナリアリリースの課題 - おうちKubernetesで検証 • Spinnakerは使いにくい部分はあるが、CDに必要な機能が備えられている