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

#DevOpsDaysTokyo ラクマとGitHub ActionsとGitOps

#DevOpsDaysTokyo ラクマとGitHub ActionsとGitOps

ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスした「DevOpsDays」にて、サービス成長の時期のなか、運用コストを軽減させた方法の紹介になります。
https://logmi.jp/tech/articles/324808

https://confengine.com/conferences/devopsdays-tokyo-2021/proposal/15222/github-actionsgitops

847ad868505a106e9017752347064609?s=128

Hidekazu Miyamoto

April 16, 2021
Tweet

More Decks by Hidekazu Miyamoto

Other Decks in Technology

Transcript

  1. Apr 16th, 2021 DevOpsDays Tokyo 2021 Hidekazu Miyamoto C2C Service

    Development Section. Rakuten Group, Inc. ラクマとGitHub ActionsとGitOps
  2. 2 Hidekazu Miyamoto Tech Lead, Rakuma SRE Team Hello!

  3. 3

  4. 4 ラクマSREについて ラクマSREチームについて

  5. 5 SREチームの任務 • サービスを提供するインフラシステムの設計・構築・運⽤ • 24/365のサービスの安定稼働 • パフォーマンスチューニング • ⼈でスケールするのではなく、システムでスケールさせること

  6. 6 チーム構成 • ⼈数はエンジニア全体に対して約10% • 複数あるチームを横断して開発をサポート • 別チームにジョインして⼀緒に開発することもある

  7. 7 課題 • 新たな機能をどんどん追加してサービスを成⻑させないといけない時期 • 新機能追加時の構成相談や、設定変更依頼、インフラに関する問い合わせが増加 • 並⾏して、サービスの稼働率の担保、監視、障害対応や運⽤負荷を軽減する為の開発も⾏わないといけない

  8. 8 課題 • 新たな機能をどんどん追加してサービスを成⻑させないといけない時期 • 新機能追加時の構成相談や、設定変更依頼、インフラに関する問い合わせが増加 • 並⾏して、サービスの稼働率の担保、監視、障害対応や運⽤負荷を軽減する為の開発も⾏わないといけない

  9. 9 監査の証跡集めに必要なもの • いつ、誰が、どのような変更をしたのか • 責任者の承認をえた上で変更作業を実施しているのか

  10. 10

  11. 11 Photo by Yancy Min on Unsplash https://unsplash.com/photos/842ofHC6MaI

  12. 監査側で求められているもの GitHub等で⾏っている事 いつ、誰が、どのような変更をしたのか コードで管理されていれば、詳細な変更管理が可能 また、PullRequest作成時に経緯等を記録することが可能 責任者の承認をえた上で変更作業を実施している のか main branch にマージするタイミングでコードオーナー

    の承認をもらってリリースを⾏う
  13. 13 ラクマSREについて GitHub Actionsを使った Terraformの実⾏環境の仕組み

  14. 14 実現したい事

  15. 15 実現したい事

  16. None
  17. None
  18. 18 ラクマSREについて Kubernetesのリソース管理を どのようなGitHub Actionsを組み合わせて GitOps化したか

  19. 19 実現したい事

  20. 20 実現したい事

  21. 21 実現したい事

  22. 22 実現したい事 • コンテナをビルドしてコンテナレジストリにプッシュする • 複数のレポジトリをチェックアウトする • Kubernetesのマニフェストファイルを更新する • 変更したマニフェストファイルに対してPull

    Requestを作成する
  23. 23 コンテナをビルドしてコンテナレジストリにプッシュする

  24. 24 コンテナをビルドしてコンテナレジストリにプッシュする

  25. 25 コンテナをビルドしてコンテナレジストリにプッシュする

  26. 26 コンテナをビルドしてコンテナレジストリにプッシュする

  27. 27 コンテナをビルドしてコンテナレジストリにプッシュする

  28. 28 複数のレポジトリをチェックアウトする

  29. 29 複数のレポジトリをチェックアウトする

  30. 30 Kubernetesのマニフェストファイルを更新する

  31. 31 変更したマニフェストファイルに対してPull Requestを作成する

  32. 32 変更したマニフェストファイルに対してPull Requestを作成する

  33. 33 変更したマニフェストファイルに対してPull Requestを作成する

  34. 34 IaCを⾏う上でのブランチ戦略の 考慮ポイント

  35. 35

  36. 36

  37. 37

  38. 38 ブランチ戦略 Pattern1

  39. 39 ブランチ戦略 Pattern1 • Pros • ブランチが固定になっている為わかりやすい • Cons •

    overlaysの対応を⾏う時に他のbranchへのマージ漏れが 出てくる可能性がある
  40. 40

  41. 41 ブランチ戦略 Pattern2

  42. 42 ブランチ戦略 Pattern2 • Pros • ブランチが固定になっている為わかりやすい • Pattern1で懸念していたマージ漏れは回避できる •

    Cons • 対応するフローが多く⾯倒
  43. 43

  44. 44 ブランチ戦略 Pattern3 - overlay更新時

  45. 45 ブランチ戦略 Pattern3 - base更新時

  46. 46 ブランチ戦略 Pattern3 • Pros • ブランチの構成がシンプル • Pattern1で懸念していたマージ漏れは回避できる •

    Cons • baseの対応時のbranch切り替え作業が⾯倒
  47. 47 Photo by alevision.co on Unsplash https://unsplash.com/photos/D-oimR6JX0E

  48. None