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

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に必要な機能が備えられている