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

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

9d6837978a1407452ebd46126c7a205f?s=47 sugimount
January 30, 2019

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

9d6837978a1407452ebd46126c7a205f?s=128

sugimount

January 30, 2019
Tweet

Transcript

  1. 1 Spinnakerでハマった6個のポイント Suguru Sugiyama(@sugimount) Cloud Native Developers JP #9

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

    • 会社:某SIer インフラエンジニア @sugimount • 好きな作曲家:田中秀和 主にアニメ・ゲームへ楽曲提供 キャッチーなメロディーラインと、耳に残るコード進行がエモい。大好き
  3. Japan Container Days18.12 3 • EKSを使用してWebアプリケーション(Qicoo)を開発して、登壇しました https://speakerdeck.com/cndjp/jkd-v18-dot-12-2w3 • 参考:EKSでQicooを外部公開した時のお話 https://speakerdeck.com/sugimount/expose-service-eks-externaldns-acm

  4. 今回はなすこと 4 • Qicooでは、Spinnakerを使用してCD(継続的デリバリー)を実装 • Spinnakerのさまざまなハマりポイントをご紹介

  5. もくじ 5 Qicooのアーキテクチャ 1 2 Spinnakerとは 3 Spinnakerのハマりポイント - Install

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

    - PipelineのArtifactの扱い - Pipelineの手動実行 4 - カナリアリリースの構成 - カナリアリリースの課題 - おうちKubernetesで検証 CI/CDとは
  7. Qicooのアーキテクチャ 7 • QicooではAWSを利用 • KubernetesサービスのEKSを中心にしてシステムを構成

  8. Qicooのアーキテクチャ 8

  9. Qicooのアーキテクチャ 9 静的コンテンツを配布 S3やCloudFront 質問データをJSONで取得 EKSでコンテナを稼働 今回お話するのはココのCD

  10. もくじ 10 Qicooのアーキテクチャ 1 2 Spinnakerとは 3 Spinnakerのハマりポイント - Install

    - PipelineのArtifactの扱い - Pipelineの手動実行 4 - カナリアリリースの構成 - カナリアリリースの課題 - おうちKubernetesで検証 CI/CDとは
  11. CI/CDとは 11 • CI(継続的インテグレーション)/CD(継続的デリバリー)と呼ばれている • アプリケーション開発のサイクルに自動化を取り入れて、リリース頻度を高める手法 自動Deploy 自動Build 自動Test

  12. CI/CDとは 12 • CI/CDが登場するまでは、アプリケーションのリリースに時間がかかっていた • 温もりのある手作業で、月ごと、四半期ごと、半年ごと、といった長いサイクルでリリース • CI/CDの自動化により、短い時間でアプリケーションをリリース可能 • これにより素早くフィードバックを受けることが出来、ビジネスの競争力向上に貢献が可能

    温もりの手作業 Code Build Test Deploy 時間がかかってユーザに 価値を届けるのが遅い CI/CD 自動化 Code Build Test Deploy 素早くリリースして ビジネスの競争力向上
  13. もくじ 13 Qicooのアーキテクチャ 1 2 Spinnakerとは 3 Spinnakerのハマりポイント - Install

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

    Multi-Cloudに対応しており、様々なPlatformを抽象化し、自動化に対応することが可能 • 自分はKubernetes界隈でSpinnakerを知ったので、Kubernetes専用のツールだと 思っていたが、Multi-Cloudに対応しているかっこいいツール
  15. Supported Multi-Cloud 15 • Spinnakerが対応しているCloudProvider • IaaS上の仮想マシンで構築された環境でも、Blue/Greenデプロイメントなどのリリース自動化 が可能 https://www.spinnaker.io/

  16. 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へ設定
  17. アーキテクチャ 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 自動カナリア分析を提供
  18. もくじ 18 Qicooのアーキテクチャ 1 2 Spinnakerとは 3 Spinnakerのハマりポイント - Install

    - PipelineのArtifactの扱い - Pipelineの手動実行 4 - カナリアリリースの構成 - カナリアリリースの課題 - おうちKubernetesで検証 CI/CDとは
  19. ハマり1. Spinnakerのインストール(Halyard) 19 • Spinnakerの導入方法は、複数存在している 本番環境での利用を見据えると、Halyardと呼ばれるInstallerツールを使用して、 Kubernetes上へSpinnakerの各コンポーネントを導入方法が強く推奨されている https://www.spinnaker.io/setup/quickstart/halyard-gke/deployment.png

  20. ハマり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
  21. ハマり2. Artifactの扱い 21 • Spinnakerには、Artifactと呼ばれている外部リソースを扱う概念がある • 代表的なArtifactは以下 • DockerImage •

    GitHub上のFile • S3上のFile • Kubernetes上のリソース Pipeline 自動処理1 自動処理2 自動処理3 Artifact 外部リソースを登録 例:GitHub上のマニフェストファイル Pipeline上の自動処理で Artifactを利用
  22. ハマり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
  23. ハマり2. Artifactの扱い 23 • 解決方法 ArtifactはできるだけSimpleにした形でPipelineを構成する Artifactに登録したいFileは必ず変更(git add)した状態でpushを行う Pipeline 自動処理1

    自動処理2 自動処理3 Artifact Pipeline上の自動処理で Artifactを利用
  24. ハマり3. Pipelineの手動実行 24 • Pipelineのトリガーを GitHubへPush を条件にした場合 SpinnakerのWebUIでPipelineを手動Startすると必ずエラーになる (DockerHubのImage更新を条件にした場合は、手動Startは実行可能。紛らわしい) SpinnakerのWebUIで

    Pipelineを手動Startするボタ ンがあるが、 必ずエラーになる
  25. ハマり3. Pipelineの手動実行 25 • 解決方法1 GitHubへPushして、Pipelineを起動させる • 解決方法2 Pipelineのデバッグなどで、GitHubへPushするのがめんどくさいときは、 GitHubのUI・

    curlコマンドで手動実行が可能 • GitHubにPushしてWebhookを実行すると、Webhookのイベントの詳細をGitHub上で確 認することが可能
  26. ハマり3. Pipelineの手動実行 26 • 最近のWebHook一覧が表示されている クリックすると詳細画面へ遷移 https://developer.github.com/webhooks/testing/

  27. ハマり3. Pipelineの手動実行 27 • Webhookの再実行が可能 Redeliver を押すと 再度Webhookが実行されて SpinnakerのPipelineが走る https://developer.github.com/webhooks/testing/

    RequestのHeaderやPayloadを コピーしてcurlコマンドで実行して もOK
  28. ハマり4. カナリアリリースの構成方法 28 • カナリアリリース、および、カナリア分析の方法についてもDocumentが少なく、試行錯誤 • Qicooでは次のPipelineを構成した カナリア (Canary)

  29. ハマり4. カナリアリリースの構成方法 29 • 順を追って確認 • 具体的な構成方法は、Qiitaを参照 https://qiita.com/sugimount/items/8bedb35af947f30b9819

  30. ハマり4. カナリアリリースの構成方法 30 • Pipeline実行前。バージョン1のアプリケーションが稼働している状態 Deployment Production Pod94個 Image :

    cndjp/qicoo-api:v1 Kubernetesクラスタ Service LoadBalancer app: qicoo-api app: qicoo-api いまここ monitoring
  31. ハマり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
  32. ハマり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
  33. ハマり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
  34. ハマり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へ書き換える
  35. ハマり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
  36. ハマり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%
  37. ハマり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を止める • カナリア自動分析
  38. Canary Analysis ベストプラクティス 38 https://www.spinnaker.io/guides/user/canary/best-practices/ • 比較するべきメトリック • レイテンシー •

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

    短時間のメトリック比較では、値の信頼性が落ちるため • 現行バージョン(v1)として新たにBaselineをDeployして、Canaryと比較する • Production環境で稼働しているPodとCanaryを比較したくなるが、適切ではない • 長時間稼働しているProduction環境のものは、新たに構成したCanaryとは条件が異なるため • その他のベストプラクティスは下のURLを参照
  40. ハマり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の削除
  41. ハマり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の削除
  42. ハマり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のローリングアップデート
  43. ハマり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を同期してカナリア?どうやって実現? • アップデート内容によって、カナリアをしたいときと、したくないときがありそう • 良い方法がありそうならディスカッションしたい
  44. ハマり6. おうちKubernetesで検証 44 • Spinnakerの検証をおうちKubernetesでやりたい • PublicCloudのKubernetesサービスはお金がかかるので、コスト削減がしたい • Spinnakerの導入は問題なく可能。しかし、ローカル環境では、 GitHubのWebhook通知が出来ないので、検証がむずかしい部分がある

    Webhook通知が 届かない
  45. ハマり6. おうちKubernetesで検証 45 • 解決方法 local環境を公開するサービスを使う • UltraHook ←自分はコレで検証した •

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

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