WEARフロントエンドにおけるPull Request毎のPreview環境導入とその効果

by ymktmk

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© ZOZO, Inc. WEAR Webにおける現状と課題  現状  ● 約10年間の技術負債を解消するべく、レガシー技術脱却のためインフラとアプリケーションのリプレイス中    ● インフラはオンプレミスからAWSクラウドへ    ● アプリケーションはFastlyを使用してパスベースルーティングで VBScript + jQueryの構成からRuby on Rails + Next.jsへ  Fastlyのパスベースルーティングで実現する WEARのゆるやかなクラウド移行 : https://techblog.zozo.com/entry/cloud-migration-of-wear-with-fastly WEAR Webフロントエンドリプレイスのアーキテクチャ選定と Next.jsへの移行: https://techblog.zozo.com/entry/wear-web-frontend-replace-with-next-js 6

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© ZOZO, Inc. WEAR Webチームにヒアリング  UIレビューの負担を軽減する  独立したQA環境として活用できるため他の案件に干渉しない etc.  ヒアリング結果  ● Storybookをデザイナーも確認できるようにしたい    ● Fastlyでカナリアリリースできるようにしたい    ● オンプレミスのみ確認できる環境が欲しい    ● Pull Request毎のPreview環境が欲しい  11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© ZOZO, Inc. KubernetesにおけるPull Request毎のPreview環境について考える ● 私たちのチームではコンピューティングサービスにEKSを使用している    ● どうやってKubernetes上でPull Request毎のPreview環境を実現するか    　　　　　　　　　　　    GitHubのPull Requestの検知をして、それ毎に「ServiceとPod」のセットを用意する？    どうやって外部からPull Request用Podへアクセス可能にするのか？  14

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© ZOZO, Inc. 16 Pull Request毎のPreview環境について考える (まとめ) ● Pull Requestが作成されたら、Docker ImageのBuild    ● Pull Requestが作成されたら、Kubernetesリソースのデプロイ  ○ デプロイ方式はPush or Pull型どちらでも良く、Pull Requestをもとに  Kubernetesリソースが作成できれば良い    ● Pull Request毎のPreview環境へアクセス可能なURLが発行される  ○ pr100.preview.wear.jpのような形式のイメージ    ● 各Preview環境へセキュアかつ容易にアクセスできる  ○ 特定の人しかアクセスできない  ■ IP制限、Basic認証、SSO etc. 

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© ZOZO, Inc. 19 Pull Requestが作成されたら、Kubernetesリソースのデプロイを行う  ● Argo CD Pull Request Generator  ○ 主にGitHub APIを使用してリポジトリ内のOpenなPull Requestを検知し、任意のKubernetesリソースをArgo CD Applicationとして作成  ○ 検知するPull Requestを特定のLabelに限定できる  ○ 「ApplicationSet」というCustom Resourceを扱う  ○ KustomizeやHelmを使うことで、生成するArgo CD Applicationのパラメータのオーバーライドが可能 (imageなど)  Argo CD Pull Request Generator公式ドキュメント: https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-Pull-Request

Slide 20

Slide 20 text

© ZOZO, Inc. 20 Pull Request毎のPreview環境へアクセス可能なURLが発行される  ● Istio VirtualServiceのホストアドレスルーティング    ● ワイルドカードドメイン  ○ pr100.preview.wear.jpにアクセスするとpr100のPodに接続できる  ○ ワイルドカードドメインとし、任意のサブドメインでアクセスした場合、Istioを介してホストヘッダーを判別し、特定のPodへアクセスできる 

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© ZOZO, Inc. 25 Pull Request作成によるDocker ImageのBuild 任意のPull RequestのみPreview環境を構築する  ● 「preview」というLabelが貼られている時のみworkflowを実行する    Preview環境は常に新しい状態を保ち続けなければならない  ● 「preview」というLabelが貼られているPull Requestのソースブランチに対してPushなどを行った場合に workflowを実行する 

Slide 26

Slide 26 text

© ZOZO, Inc. 26 動的に生成するK8sリソースのHelm Template化 ● VirtualService, Service, Deploymentなど、Pull Request毎に必要なKubernetesリソースに関してはHelm Template化    ● {{ .Values.name }}と設定しておくことで動的にパラメータを適用できる    Argo CD Pull Request Generatorが values.yamlの値をオーバーライドして適用する  Helm テンプレート: https://helm.sh/ja/docs/chart_best_practices/templates Istio VirtualServiceドキュメント: https://istio.io/latest/docs/reference/config/networking/virtual-service

Slide 27

Slide 27 text

© ZOZO, Inc. 27 Argo CD Pull Request GeneratorによるPull Requestの検知 ● requeueAfterSecondsでGitHub APIを使って Pull Requestを取得するポーリング間隔を設定    ● 「preview」というLabelが貼られたPull Request のみ抽出    ● Helm Templateが存在するGitHubリポジトリとそのパスを指定    条件に合ったPull Requestがあれば、Argo CD Pull Request GeneratorがArgo CD Application としてKubernetesリソースをPull Request毎に生成！   