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

K8sとTraefikでつくるマイクロフロントエンド

Kim, Hirokuni
September 08, 2020

 K8sとTraefikでつくるマイクロフロントエンド

CloudNative Days Tokyo 2020 #CNDT2020_A

Kim, Hirokuni

September 08, 2020
Tweet

More Decks by Kim, Hirokuni

Other Decks in Technology

Transcript

  1. 6 Marek Nowak (ノバック マレック) Engineering Manager 新UI 開発チームのマネージャー Wall

    Street Journalに載ってた 絵文字エキスパート。 Kim, Hirokuni (金 洋国) Staff Site Reliability Engineer SREチーム CircleCIで5年ほど働いています。サポート、開発、 日本支社立ち上げ、色々やってきました 自己紹介
  2. 13 解決したい問題 (フロントエンド編) ✗ 旧UIのフロントエンドはレガシーコード ◦ 三つのフレームワークが混ざってて 複雑 ▪ ClojureScript/Om

    ▪ ClojureScript/Om Next ▪ JavaScript + Flow ◦ 変更するのは難しい ◦ 新機能の開発はもうムリ ✗ フロントエンド開発したいチームは 複数
  3. 14 解決したい問題 (フロントエンド編) ✗ 旧UIのフロントエンドはレガシーコード ◦ 三つのフレームワークが混ざってて 複雑 ▪ ClojureScript/Om

    ▪ ClojureScript/Om Next ▪ JavaScript + Flow ◦ 変更するのは難しい ◦ 新機能の開発はもうムリ ✗ フロントエンド開発したいチームは 複数 ◦ レガシーコードー直しても また複雑になるリスク
  4. 15 マイクロフロントエンド(MF)とは? Good frontend development is hard. <省略> We'll describe

    a recent trend of breaking up frontend monoliths into many smaller, more manageable pieces, and how this architecture can increase the effectiveness and efficiency of teams working on frontend code. https://martinfowler.com/articles/micro-frontends.html#Benefits マイクロサービスのアイデアをフロントエンドに応用する
  5. 18 projects MF pipeline MF org MF plans MF users

    MF 複数のフロントエンドで作られている
  6. 19 新コードベース ローカル開発環境の セットアップも、 新機能の開発も スピードアップのために。 マイクロサービスは 当たり前 CircleCIではすでにマイクロサー ビスは当たり前になった。

    同じアイデアをフロントエンドにも 適用しましょう! 複数のチームでも 楽々 他のチームを 邪魔せずに 自由に開発できるように。 MFを導入の目的は…
  7. 21 解決したい問題 (バックエンド編) ✗ 気軽に変更できない ◦ すでに circleci.com のホスティングに使われている ◦

    MFを追加する度にリスク ◦ フロントエンド開発者はNginx触りたくない ◦ 毎回SREがやらないといけない
  8. 25 それでどうなった? ELB1 ELB2 ELB3 ELB4 mf-onboarding mf-pipeline mf-user-settings mf-project-settings

    Node Port:30001 Node Port:30002 Node Port:30003 Node Port:30004 DNSとELBをそれぞれのMFごとに作ってNginxを回避 onboarding.circleci.com ui.circleci.com accounts.circleci.com projects.circleci.com circleci.com 新UI 旧UI some pods...
  9. 29 Træfɪk Traefik is a leading modern reverse proxy and

    load balancer that makes deploying microservices easy. Traefik integrates with your existing infrastructure components and configures itself automatically and dynamically. https://containo.us/traefik/
  10. 30 Traefikの特徴 ✓ NginxみたいなReverse Proxy ✓ HAProxyみたいなLoad Balancer ✓ Container

    Native (次のスライドで解説) ✓ 動的な設定のリロード ◦ MFの変更ごとに再起動しなくてもいい ◦ Nginxだと設定変更の度に再起動が必要
  11. 31 Traefik V1 • V1のリリースは 2016年 • No TCPサポート •

    主にHTTPのReverse Proxyとして設計 • V1の最後のバージョンは 1.7.18 • CircleCIでは1.7.18を使用 • MFを構築する機能は十分! Traefik V2 • 2019年9月にV2リリース • ブログ: https://containo.us/blog/traefik-2-0-6531ec5196c2/ • TCPサポート • Middlewareサポート • その他色々 Traefik: V1 vs V2
  12. 32 Container Native ✓ Telemetryの標準サポート ◦ Metrics ◦ Tracing ✓

    マルチプラットフォーム ◦ Docker ◦ Mesos ◦ Kubernetes
  13. 34 IngressとIngress Controllerについて Ingress Controller -> リクエストを実際にハンドリング ✓ Traefik ✓

    Nginx ✓ AWS ALB Ingress -> K8s オブジェクト ✓ Internet -> K8s -> Service のルーティング ✓ Ingressだけでは意味がない
  14. 35 Traefik良かったこと: Self-Serving Deployの推進 kind: Ingress metadata: spec: rules: -

    host: app.circleci.com http: paths: - path: /path-foo backend: serviceName: foo-service /path-foo -> foo-service
  15. 36 Traefik良かったこと: Self-Serving Deployの推進 kind: Ingress metadata: spec: rules: -

    host: app.circleci.com http: paths: - path: /path-foo backend: serviceName: foo-service kind: Ingress metadata: spec: rules: - host: app.circleci.com http: paths: - path: /path-foo backend: serviceName: foo-service - path: /path-bar backend: serviceName: bar-service /path-foo -> foo-service /path-foo -> foo-service /path-bar -> bar-service 追加してデプロイ
  16. 39 Traefik困ったこと: Annotationのテストの難しさ 例えば、https://foo.circleci.com -> https://bar.circleci.com にリダイレクトしたい kind: Ingress metadata:

    annotations: traefik.ingress.kubernetes.io/redirect-permanent: "true" traefik.ingress.kubernetes.io/redirect-regex: ^https://foo.circleci.com traefik.ingress.kubernetes.io/redirect-replacement: https://bar.circleci.com
  17. 40 Traefik困ったこと: Annotationのテストの難しさ 例えば、https://foo.circleci.com -> https://bar.circleci.com にリダイレクトしたい kind: Ingress metadata:

    annotations: traefik.ingress.kubernetes.io/redirect-permanent: "true" traefik.ingress.kubernetes.io/redirect-regex: ^https://foo.circleci.com traefik.ingress.kubernetes.io/redirect-replacement: https://bar.circleci.com 期待通りにリダイレクトされる?
  18. 41 Traefik困ったこと: Annotationのテストの難しさ 例えば、https://foo.circleci.com -> https://bar.circleci.com にリダイレクトしたい kind: Ingress metadata:

    annotations: traefik.ingress.kubernetes.io/redirect-permanent: "true" traefik.ingress.kubernetes.io/redirect-regex: ^https://foo.circleci.com traefik.ingress.kubernetes.io/redirect-replacement: https://bar.circleci.com K8sのテスト環境が必要となる
  19. 43 Traefik困ったこと: SREボトルネック再び ✓ Traefik導入後すぐにMFの数が増えた (現在15個くらい) ✓ 各チームでやりたいことが徐々に複雑に、、、 ◦ 共通のエラーページを使いたい

    ◦ カスタムヘッダーってどう設定するんだっけ? ✓ K8s/Traefikのテスト環境を用意しないといけない SREでやり方を調査する待たせてしまう
  20. 56 MFを導入して学んだこと ✓ MFの段階的なロールアウトは便利 ◦ 一つずつのMFを導入できる ◦ Feature Flagを使用して MF以内の新機能も

    ! モノリスでも、MFでも コミュニケーションは難しい ◦ 「Frontend Roundtable」 ◦ クロスチームコラボレーション
  21. 57 MFを導入して学んだこと ✓ MFの段階的なロールアウトは便利 ◦ 一つずつのMFを導入できる ◦ Feature Flagを使用して MF以内の新機能も

    ! モノリスでも、MFでも コミュニケーションは難しい ◦ 「Frontend Roundtable」 ◦ クロスチームコラボレーション ◦ 「Frontend Platform Team」
  22. 58 MFを導入して学んだこと ✓ MFの段階的なロールアウトは便利 ◦ 一つずつのMFを導入できる ◦ Feature Flagを使用して MF以内の新機能も

    ! モノリスでも、MFでも コミュニケーションは難しい ◦ 「Frontend Roundtable」 ◦ クロスチームコラボレーション ◦ 「Frontend Platform Team」 ✓ 複雑なレガシーコードーになるリスクは 小さくなった
  23. 63 DRY問題 (バックエンド) ✓ グローバルな設定の扱い辛さ ◦ 各IngressのAnnotationに同じことを書かないといけない kind: Ingress metadata:

    annotations: ingress.kubernetes.io/custom-response-headers: Strict-Transport-Security:max-age=N; includeSubDomains 例: Hypertext Strict Transport Security(HSTS)の設定 これを各Ingressに書かないといけない
  24. 64 DRY問題 (バックエンド) K8sマニフェストのラッパーを導入 # ラッパー kind: Ingress metadata: annotations:

    commonSecureHeaders: enable # 実際にレンダリングされる Ingress kind: Ingress metadata: annotations: ingress.kubernetes.io/browser-xss-filter: "true" ingress.kubernetes.io/content-type-nosniff: "true" ingress.kubernetes.io/custom-frame-options-value: SAMEORIGIN ingress.kubernetes.io/custom-response-headers: Strict-Transport-Security:max-age=N; includeSubDomains
  25. 68 DRY問題 (フロントエンド ) ! ブートストラップ     ✨ ➡  ! APIのラッパー      

    ! デザイン ◦ Component System  ! モニタリング ◦ エラー       
  26. 69 DRY問題 (フロントエンド ) ! ブートストラップ     ✨ ➡  ! APIのラッパー      

     ➡  ! デザイン ◦ Component System   ➡  ! モニタリング ◦ エラー        ➡ 
  27. 70 DRY問題 (フロントエンド ) ! ブートストラップ     ✨ ➡  ! APIのラッパー      

     ➡  ! デザイン ◦ Component System   ➡  ! モニタリング ◦ エラー        ➡  ◦ アップタイム    
  28. 71 DRY問題 (フロントエンド ) ! ブートストラップ     ✨ ➡  ! APIのラッパー      

     ➡  ! デザイン ◦ Component System   ➡  ! モニタリング ◦ エラー        ➡  ◦ アップタイム     ➡ 
  29. 72 DRY問題 (フロントエンド ) ! ブートストラップ     ✨ ➡  ! APIのラッパー      

     ➡  ! デザイン ◦ Component System   ➡  ! モニタリング ◦ エラー        ➡  ◦ アップタイム     ➡ 
  30. 73 DRY問題 (フロントエンド ) ! ブートストラップ     ✨ ➡  ! APIのラッパー      

     ➡  ! デザイン ◦ Component System   ➡  ! モニタリング ◦ エラー        ➡  ◦ アップタイム     ➡  ! デプロイ        
  31. 74 DRY問題 (フロントエンド ) ! ブートストラップ     ✨ ➡  ! APIのラッパー      

     ➡  ! デザイン ◦ Component System   ➡  ! モニタリング ◦ エラー        ➡  ◦ アップタイム     ➡  ! デプロイ          ➡  +
  32. 76 MF 続ける? やめる? SREとしては、 ✓ フロントエンドチームの開発速度をあげることができたので続けたい ✓ Traefikの細かい問題はあったけど、多くは v2で改善されている

    フロントエンド開発チームとしては、 ✓ 自由な開発やロールアウトは最高 ✓ クロスチームコミュニケーションはどうしても大事だから頑張らなくちゃ