37.1K Views
August 31, 22
スライド概要
TECH STAND #9 GitHubというイベントで発表したスライドです。
TECH STAND #9 GitHub - connpass
https://standfm.connpass.com/event/256786/
# 概要
サイボウズ株式会社では GitHub Enterprise Server(GHES、オンプレ版 GitHub)とGitHub Enterprise Cloud(GHEC、github.com の上位プラン)の両方を使っています。
元々 GHES のみを使っていたのですが、github.com を使いたいという社内の要望から GHEC も利用するようになりました。
だんだん GHEC 利用が増えてきたのですが、いくつかの理由で GHES 移行できないリポジトリもあります。GHEC を使いたいのになかなか移行できないチームのために、GHEC へ移行しやすくするための取り組みを行なってきたのでそれらをご紹介します。
サイボウズ株式会社 開発本部 生産性向上チームで働いています。
脱オンプレGitHub︕ クラウド移⾏促進のための取り組み Tech Stand #9 GitHub サイボウズ株式会社 ⽣産性向上チーム 平⽊場 ⾵太
⾃⼰紹介 n ⿅児島県出⾝、第⼆の故郷は宮崎 n 2020年にサイボウズへ新卒⼊社、 ⽣産性向上チームに配属 n 好きな技術は CI/CD や IaC 周り 平⽊場 ⾵太 Futa Hirakoba Twitter: @Shitimi_613 GitHub: @korosuke613 n 好きな⾷べ物は⾟麺とチキン南蛮 n Zenn で Productivity Weekly という記 事をよく書いてる n https://zenn.dev/topics/productivityweekly?order=latest 2
今⽇話すこと オンプレ GitHub からクラウド GitHub への移⾏をしやすくするためにやったこと n 社内ネットワークにつながるオートスケールする GitHub Actions セルフホストランナー環境の提供 n 社内 Maven レジストリを GHEC の Packages へ移⾏ n Actions、Packages の利⽤料を細かく記録 https://standfm.connpass.com/event/256786/ 3
サイボウズとは n グループウェア作ってるSaaS企業 n 理念「チームワークあふれる社会を創る」 n 4 つの主な製品 4
⽣産性向上チームとは n サイボウズの開発者の⽣産性を上げる ための活動をするチーム n 仕事 n 開発基盤の整備 n チーム⽀援 n ⽣産性向上技術のキャッチアップ・共有 n 開発チームからの依頼を受けて作業を することが多い サイボウズの開発者の⽣産性を上げる「⽣産性向上チーム」とは︕︖ https://note.com/cybozu_dev/n/n1c1b44bf72f6 5
サイボウズの GitHub 事情とクラウド GitHub の話 6
サイボウズでは GHES と GHEC の両⽅を利⽤ n クラウド版 GitHub n Free n Team n Enterprise Cloud (GHEC) ⇦ 契約 n オンプレ版 GitHub n Enterprise Server (GHES) ⇦ 契約 7
クラウドの機能を使いたい開発チーム n 元々は GHES のみ利⽤ n GHEC 導⼊後、GHES からリポジトリを移⾏したいという声が出てきた クラウドの機能 使いてぇなぁ ✨ ✨ ✨ 8
背景︓開発に関するエコシステムを広げていく GitHub n 2019年05⽉ Dependabot 買収 n 2019年11⽉ Actions GA Packages(旧Package Registry) GA n 2020年10⽉ Code Scanning GA n 2021年03⽉ Discussions for private repo GA n 2021年08⽉ Codespaces GA n ... 9
背景︓開発に関するエコシステムを広げていく GitHub n CI/CD: Actions n パッケージ管理: Packages n 開発環境: Codespaces n コラボレーション: Discussions n プロジェクトマネジメント: Projects n セキュリティ: Dependabot Alerts、Code scanning n プラグイン: Marketplace GitHub のみで開発できる時代に... 10
背景︓クラウドとオンプレで新機能の使えるタイミングは異なる n クラウド版の新機能がオンプレ版ですぐに使えるとは限らない n オンプレ版で GA となっても全ての機能が使えるとは限らない n例 GitHub Actions クラウド版 (GA になった⽉) オンプレ版 (GA になった⽉) 2019年11⽉ 2021年2⽉ (v3.0) ただし cache 機能は 2022年5⽉ (v3.5) GitHub Packages 2019年11⽉ 2021年2⽉ (v3.0) ただし Container Registry はまだベータ 11
いざクラウド n GHES から GHEC への移⾏を⼿伝うことに 移⾏のお⼿伝いを しましょう クラウドの機能 使いたいです ⽣産性向上チーム ✨ ✨ ✨ 12
いざクラウド n GHES から GHEC への移⾏を⼿伝うことに n しかし現実は⽢くなかった 移⾏のお⼿伝いを しましょう クラウドの機能 使いたいです ⽣産性向上チーム ✨ ✨ ✨ 13
今回話すトピック 開発チームがクラウド移⾏をしやすくするためには︖ n GHEC でも簡単に社内ネットワークに依存する CI を回せるようにする n 社内ネットワークへの依存を減らす n 予算を把握しやすくする・使いすぎを防⽌する 14
実現したいこと GHEC でも簡単に社内ネットワークに依存する CI を回せるようにする 15
ざっくりとしたサイボウズの製品開発環境 n 社内ネットワーク内に CI/CD サービス、E2E テスト環境、各 種レジストリが存在する n インターネットからはアクセスで きない 16
これはできない ❌ ❌ ❌ 17
GitHub Actions セルフホストランナー GitHub Actions では⾃分で⽤意したランナーでジョブを動かすことができる (Self-hosted runner) n メリット n 強⼒なスペックのマシンでジョブを動かせる n よく使うソフトウェアをあらかじめインストールしておける n ランナー側から GitHub へセッションを確⽴しにいくため、 社内ネットワークに⽴てたランナーを GitHub.com から利⽤可能 18
GitHub Actions セルフホストランナー n デメリット n ⾃分でマシンを⽤意しないといけない n スケーラビリティの確保も考えないといけない n GitHub-hosted runner と同程度の環境(プリインストールソフトウェア など)を再現するのは⼤変 n 個⼈や各チームでセルフホストランナー環境を⽤意するのは⼤変 → ⽣産性向上チームで⽤意 19
社内で使えるセルフホストランナー環境を⽤意 n もともと Amazon VPC と社内開発ネットワークを VPN 接続する仕組みが 整っていた → AWS 上で構築 20
社内で使えるセルフホストランナー環境を⽤意 n AWS 上に構築するオートスケール を実現する OSS を利⽤ n セルフホストランナープールと呼称 n philips-labs/terraform-awsgithub-runner https://github.com/philips-labs/terraformaws-github-runner 21
詳しくは過去のスライドを参照 https://www.slideshare.net/miyajan/github-actions-250042631 22
社内で使えるセルフホストランナー環境を⽤意 n GHEC の GitHub Actions から社内ネットワークへアクセス可能に 23
社内で使えるセルフホストランナー環境を⽤意 n さらに GHES でも GitHub Actions を利⽤できるように 24
作ってみた結果 n 社内ネットワークへつながるセルフホストランナーを簡単に利⽤可能に n 既存の社内 CI/CD サービスのワークフローを少しづつ Actions のワークフ ローへ移⾏できるように n ⼤規模ワークフローをだんだんと Actions のワークフローに置き換えること で、リポジトリのクラウド移⾏がしやすくなった 25
実現したいこと 社内ネットワークへの依存を減らす 26
社内ネットワークに依存するワークフローを GHEC でも流せるように n 社内ネットワークに依存している場合にセルフホストランナープールを利⽤ 社内ネットワークに 依存するなら セルフホストランナー 依存しないなら GitHub-hosted ランナー 27
社内ネットワークへの依存を減らす n それでも社内ネットワークへの依存は減らしたい n 常時起動が必要な台数を抑えるため n ネットワーク転送量を抑えるため n ランナーの選択肢の幅を広げるため n (オンプレシステムのメンテ⼯数を減らしたいという理由も) → 社内ネットワーク内システムを徐々にクラウド移⾏していく 28
社内 Maven レジストリ n 複数製品で利⽤するための Maven レジストリが社内にあった n 古いシステムで動いていたことが問題に n VM 1 台で動作。最低限のメンテのみ → 社内 Maven レジストリのクラウドサービスへの移⾏が決定 29
移⾏先の選定 n 主に GitHub Packages と AWS CodeArtifact を⽐較し、Packages に決定 n AWS よりも GitHub に慣れ親しんでいる社員が多かったことが主な要因 n 慣れ親しんだ認証 n 慣れ親しんだ UI n 料⾦など CodeArtifact の⽅が優勢な部分もあった 30
GitHub Packages の良いところ n リポジトリにひもづくため、リポジトリへのアクセス権限をそのまま使える n 認証が楽(GitHub ユーザにとって) n GitHub Actions との連携が強⼒ n 転送料⾦の優遇 n GITHUB_TOKEN による認証 https://github.co.jp/features/packages 31
レジストリの移⾏ n 移⾏の流れ 1. 各チームにアーティファクトのアップロード先へ Packages を追加してもらう 2. 旧レジストリに保存されているアーティファクトを Packages にコピー 3. 利⽤者(CI 含む)が Packages からアーティファクトをダウンロードするように設定 してもらう 4. 各チームにアーティファクトのアップロード先から旧レジストリを削除してもらう 5. 旧レジストリを停⽌ n 開発を停⽌させずにレジストリを移⾏させることに成功 n 社内 Maven レジストリ停⽌後に問題は起こっていない 32
移⾏してみた効果 n Maven の利⽤にセルフホストランナープールを介する必要がなくなった n 常時起動ランナー数削減 n ネットワーク帯域の節約 n GHEC 上で CI を回しやすくなった n オンプレレジストリのメンテナンス⼯数削減 n マネージドサービス万歳 33
実現したいこと 予算を把握しやすくする・使いすぎを防⽌する 34
予算が不安という声 使えば使うほど お⾦かかるんでしょ︖ わかる 予算⾷い潰すの 怖いな〜 開発チーム 残りどれくらい使えるか︖ って都度聞くのもめんどいし ⽣産性向上チーム 35
Actions & Packages の使いすぎ注意︕ n Budget 的な機能があるため、全体でのクラウド破産は防げる n https://docs.github.com/en/billing/managing-billing-for-github-actions/managing-yourspending-limit-for-github-actions n しかし、どれくらいの勢いで増えたかなどは Usage Report (CSV) をダウン ロード&分析する必要がある n 各チームが Billing を閲覧するのは権限上難しい n 強⼒な権限が必要 (Enterprise の Admin) 36
github-billing-reporter n GHEC の各種サービス利⽤量を取得&記録する仕組みを作成 n GitHub Actions で毎⽇実⾏ n 各種サービス利⽤量の異常値や推移を分析しやすくした 37
余談︓GitHub Actions 利⽤規約 n GitHub-hosted runner においては開発に関連しない理由での Actions 利⽤を禁⽌している(意訳)ため注意 n > if using GitHub-hosted runners, any other activity unrelated to the production, testing, deployment, or publication of the software project associated with the repository where GitHub Actions are used. https://docs.github.com/en/site-policy/github-terms/github-terms-for-additional-products-and-features ※github-billing-reporter はセルフホストランナーを利⽤しているためこの制限に該当しない 38
kintone n サイボウズが提供するノーコード・ローコードの 業務改善プラットフォーム n 簡単にデータの集計・可視化ができる n APIを⽤いてプログラマブルにデータを送受信できる 39
GitHub Action & Packages 使⽤量アプリ ※数字はダミーです 40
GitHub Action & Packages 使⽤量アプリ ※数字はダミーです ⽉ごとの合計料⾦ ⽉ごとの Actions 合計利⽤時間 ⽉ごとの合計転送量 ⽉ごとのストレージ使⽤量 41
作ってみた結果 n 開発チームが利⽤量を確認できるようになった n 予算の不安を解消しやすくなり、Actions & Packages 活⽤が加速 n 来期予算を予想しやすくなった n 使⽤量が急激に上がったタイミングを分析しやすくなった 42
まとめ 43
クラウド移⾏をしやすくするためにやったこと n GHEC でも簡単に社内ネットワークに依存する CI を回せるようにする → 社内ネットワークにつながるオートスケールする GitHub Actions セルフホストランナー環境の提供 n 社内ネットワークへの依存を減らす → 社内 Maven レジストリを GHEC の Packages へ移⾏ n 予算を把握しやすくする・使いすぎを防⽌する → Actions、Packages の利⽤料を細かく記録 44
まとめ n 開発チーム⽬線でクラウド移⾏のハードルは下がった n だがこれで全てが終わったわけではない n 古い CI/CD ワークフローの置き換えコスト n まだまだ社内ネットワークに依存システムがある n ... 45
ちなみに︓最近の GitHub は各種移⾏ツールを開発している n github/gh-gei n GHES から GHEC へのリポジトリ移⾏ツール n Issue や PR も移⾏できる n https://github.com/github/gh-gei n github/gh-valet n 各種 CI/CD サービスから GitHub Actions への移⾏ツール n 移⾏後のコストを試算したりもできる こういうのあると めちゃ助かる n https://github.com/github/gh-valet 46
俺たちの戦いはこれからだ︕ ご清聴ありがとうございました 🎉 47