Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ラクマにおけるGitOps導入事例
Search
Hidekazu Miyamoto
May 26, 2021
Technology
0
1.4k
ラクマにおけるGitOps導入事例
https://resources.github.com/webcasts/jp-github-infocus-devops/
Hidekazu Miyamoto
May 26, 2021
Tweet
Share
More Decks by Hidekazu Miyamoto
See All by Hidekazu Miyamoto
#DevOpsDaysTokyo ラクマとGitHub ActionsとGitOps
hiiiide
1
720
Other Decks in Technology
See All in Technology
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
280
AIエージェント開発用SDKとローカルLLMをLINE Botと組み合わせてみた / LINEを使ったLT大会 #14
you
PRO
0
130
Android Audio: Beyond Winning On It
atsushieno
0
3.4k
「どこから読む?」コードとカルチャーに最速で馴染むための実践ガイド
zozotech
PRO
0
570
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
280
Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか
iwatatomoya
1
1.2k
Bedrock で検索エージェントを再現しようとした話
ny7760
2
110
RSCの時代にReactとフレームワークの境界を探る
uhyo
11
3.5k
「その開発、認知負荷高すぎませんか?」Platform Engineeringで始める開発者体験カイゼン術
sansantech
PRO
2
870
今日から始めるAWSセキュリティ対策 3ステップでわかる実践ガイド
yoshidatakeshi1994
0
120
Firestore → Spanner 移行 を成功させた段階的移行プロセス
athug
1
500
なぜテストマネージャの視点が 必要なのか? 〜 一歩先へ進むために 〜
moritamasami
0
240
Featured
See All Featured
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
810
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.1k
Unsuck your backbone
ammeep
671
58k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
The World Runs on Bad Software
bkeepers
PRO
70
11k
RailsConf 2023
tenderlove
30
1.2k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
Visualization
eitanlees
148
16k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
850
The Cult of Friendly URLs
andyhume
79
6.6k
Writing Fast Ruby
sferik
628
62k
Transcript
May 26th, 2021 GitHub InFocus Hidekazu Miyamoto C2C Service Development
Section. Rakuten Group, Inc. ラクマにおけるGitOps導⼊事例
2 Hidekazu Miyamoto Tech Lead, Rakuma SRE Team Hello!
3
4 ラクマSREについて ラクマSREチームについて
5 SREチームの任務 • サービスを提供するインフラシステムの設計・構築・運⽤ • 24/365のサービスの安定稼働 • パフォーマンスチューニング • ⼈でスケールするのではなく、システムでスケールさせること
6 課題 • 新たな機能をどんどん追加してサービスを成⻑させないといけない時期 SRE
7 課題 • 新たな機能をどんどん追加してサービスを成⻑させないといけない時期 • 新機能追加時の構成相談や、設定変更依頼、インフラに関する問い合わせが増加 Consultation Capacity Consultation Architect
Change setting request Trouble Shooting SRE Support
8 課題 • 新たな機能をどんどん追加してサービスを成⻑させないといけない時期 • 新機能追加時の構成相談や、設定変更依頼、インフラに関する問い合わせが増加 • サービスの稼働率の担保、監視、障害対応も並⾏して⾏わないといけない Consultation Capacity
Consultation Architect Change setting request Trouble Shooting Monitoring CI/CD Incident Audit SRE Oparation Support
9 課題 • 新たな機能をどんどん追加してサービスを成⻑させないといけない時期 • 新機能追加時の構成相談や、設定変更依頼、インフラに関する問い合わせが増加 • サービスの稼働率の担保、監視、障害対応も並⾏して⾏わないといけない Consultation Capacity
Consultation Architect Change setting request Trouble Shooting Monitoring CI/CD Incident Audit SRE Oparation Support
10 監査の証跡集めに必要なもの • いつ、誰が、どのような変更をしたのか • 責任者の承認をえた上で変更作業を実施しているのか
11 ラクマSREについて GitOpsについて
12 GitOpsとは https://www.weave.works/blog/gitops-operations-by-pull-request • 2017年に公開されたWeaveworks社のブログで “GitOps”という⾔葉が誕⽣ • 要約すると、⼈の⼿を介さずにインフラに関するのコードをGitで管理する思想 • 主にKubernetesのリソース管理で使われることが多い
• インフラの変更に関する追跡情報が集約されているため、監査の証跡集めとしても有効
13 ラクマSREについて Terraformの実⾏環境の仕組み
14 実現したい事 - 開発編 Cloud Platform Developer GitHub Actions 1.
PullRequest 2. Action 4. plan terraform-repo 3. init, fmt 5. Add the result to comment
15 実現したい事 – リリース編 Cloud Platform Developer GitHub Actions 1.
Approve 3. Action 4. apply terraform-repo Code Owner 2. Merge
None
None
None
19 Sample Code https://gist.github.com/hiiiide/1ae69bebb8c0335c177a8b32763e505e
20 ラクマSREについて Kubernetesのリソース管理を どのようなGitHub Actionsを組み合わせて GitOps化したか
21 実現したい事 Developer application-repo k8s-manifest-repo GitHub Actions Container Registry 1.
Push 2. Action 3. Push Image 4. Push manifest file 5. Polling 6. apply
22 コンテナのビルドとプッシュ Developer application-repo k8s-manifest-repo GitHub Actions Container Registry 1.
Push 2. Action 3. Push Image 4. Push manifest file 5. Polling 6. apply
23 コンテナのビルドとプッシュ
24 コンテナのビルドとプッシュ コンテナレジストリのログイン処理 ビルド、プッシュ処理 初期処理
25 マニフェストファイルの更新 + Pull Request作成 Developer application-repo k8s-manifest-repo GitHub Actions
Container Registry 1. Push 2. Action 3. Push Image 4. Push manifest file 5. Polling 6. apply
26 マニフェストファイルの更新 + Pull Request作成 • 外部のレポジトリ(k8s-manifest-repo)のチェックアウトが必要 • デフォルトで⽤意されているCheckoutで実現可能 •
対象のレポジトリを⽤意するだけでOK(pathの指定は任意)
27 マニフェストファイルの更新 + Pull Request作成 • マニフェストファイル(Deployment)をGitHub Actions内で変更する • 今回はrubyスクリプトを⽤意して、コンテナイメージのタグを更新
• もっとシンプルにしたい場合は yq コマンドを使⽤すると良い
28 マニフェストファイルの更新 + Pull Request作成
29 マニフェストファイルの更新 + Pull Request作成
30 マニフェストファイルの更新 + Pull Request作成
31 GitOpsのブランチ戦略について
32 前提 • Kustomizeを使⽤したKubernatesのマニフェストファイルを、どのようなブランチ戦略で管理してくか に焦点を当てる • Kustomizeとは、Kubernetesのyamlを効率よく運⽤するのに特化したパッケージングツール
33 PRD K8S Cluster staging branch develop branch main branch
feature branch STG K8S Cluster DEV K8S Cluster ブランチ戦略 Pattern1 3. merge 2. merge 1. checkout 4. merge
34 PRD K8S Cluster staging branch develop branch main branch
feature branch STG K8S Cluster DEV K8S Cluster ブランチ戦略 Pattern2 4. merge 3. merge 2. merge 1. checkout
35 PRD K8S Cluster main branch feature branch STG K8S
Cluster DEV K8S Cluster ブランチ戦略 Pattern3 - overlay更新時 2. merge 1. checkout
36 PRD K8S Cluster main branch feature branch STG K8S
Cluster DEV K8S Cluster ブランチ戦略 Pattern3 - base更新時 2. merge 1. checkout
37 Pattern3 Pros Cons List Pattern1 Pattern2 Pros Cons Pattern1
ブランチが固定になっている為わかりやすい overlaysの対応を⾏う時に他のbranchへのマージ漏れが出てくる可能性があ る Pattern2 ブランチが固定になっている為わかりやすい Pattern1で懸念していたマージ漏れは回避できる 対応するフローが多く⾯倒 Pattern3 ブランチの構成がシンプル Pattern1で懸念していたマージ漏れは回避できる baseの対応時のbranch切り替え作業が⾯倒
38 まとめ • インフラの設定管理もコードで管理すれば、監査対応も楽になる • 何かやりたいことがあれば、まずはGitHub MarketplaceでActionsを探そう • GitOpsを導⼊するときはブランチ戦略を考えてから実戦に挑もう
None