6.6K Views
February 29, 24
スライド概要
私たちのチームは長年、Circle CI と Jenkins を活用して CI/CD 環境を構築してきました。しかし、運用の複雑さと高コストに直面し、より効率的な方法を模索していました。この問題を解決するために、GitHub Actions への移行を決定しました。その結果、運用コストの削減と操作の簡易性を実現しました。
本登壇では、私たちが既存の CI/CD を GitHub Actions に移行する過程で直面した課題と、それらをどのように解決したか、なぜこのタイミングになったのかなどを共有します。本登壇が、同様の問題に直面しているエンジニアの皆さんに具体的な解決のヒントとなることを願っています。
※資料内の動画は後日公開されるセッション動画でご覧いただけます
DeNA が社会の技術向上に貢献するため、業務で得た知見を積極的に外部に発信する、DeNA 公式のアカウントです。DeNA エンジニアの登壇資料をお届けします。
CI/CD の課題解消! GitHub Actions への移行で可能になったこと 古屋 姫美愛 © DeNA Co., Ltd.
⾃⼰紹介 古屋 姫美愛 エンターテインメント開発事業本部オープンプラット フォーム事業部ゲームプラットフォーム部サーバーグ ループ 2016年8⽉から DeNA の⼀員としてサーバーサイドエンジ ニアとして Join。 2020年、2022年に産休‧育休を取得、2023年より復帰し ました。現在はMobageプラットフォームの開発運⽤に加 えて、全社⽤セルフホストランナーの運⽤改善も。 kimikimi714 kimikimi714 © DeNA Co., Ltd. 2
⽬次 1. GitHub Actions とは 2. 直⾯していた課題 3. 移⾏によって解消した課題 ○ 困まったこと ○ よかったこと 4. 今後やっていきたいこと © DeNA Co., Ltd. 3
GitHub Actions とは © DeNA Co., Ltd. 4
GitHub Actions とは ● GitHub ⾃体が提供している継続的インテグレーション(CI)と継続的デリバリー (CD) の プラットフォーム。 ○ ● 現在弊社で利⽤中の GitHub Enterprise Server ではバージョン3.0からGA。 GitHub で発⽣する各種イベント(push, pull_request, issues など)で発⽕するワークフ ローと呼ばれる⼀連の処理をおこなわせることが可能。 ○ ● 処理を実際におこなうのはランナーと呼ばれるデーモン。 GitHub Enterprise Server では GitHub Enterprise Cloud と異なり、セルフホストラン ナーを⽤意する必要がある。 © DeNA Co., Ltd. 5
GitHub Actions とは © DeNA Co., Ltd. 6
すでに⾃分のチームでは Jenkins® と CircleCI® でCI/CDしていた。 ※1 Jenkins®は、LF Charities Incの登録商標です。 ※2 CircleCI®は、Circle Internet Services, Incの商標または登録商標です。 © DeNA Co., Ltd. 7
直⾯していた課題 © DeNA Co., Ltd. 8
直⾯していた課題 1. CircleCIのジョブ管理者が実質⾃分のみ 2. Jenkins のジョブが GUI ベースでコード管理されてない 3. Jenkins で利⽤しているプラグインのアップデートが困難 4. 新しいプロジェクトのCI/CDは Jenkins / CircleCI 以外にしたい © DeNA Co., Ltd. 9
CircleCIのジョブ管理者が実質⾃ 分のみ ● メンバーの異動で残ったのが⾃分 だった。増やすにはユーザーの追 加購⼊が必要。 ● 外部協⼒者の⽅が落としたテスト を代わりに⾒に⾏って伝える運⽤ があった。 ● 引⽤: オンプレミスの CI/CD - CircleCI さすがにユーザーを追加したもの の、メンバーの異動で同じ問題が また起こる。 © DeNA Co., Ltd. 10
Jenkins のジョブが GUI ベースで コード管理されてない ● 歴史的事情から Jenkinsfile など で管理できてない。 ● ジョブやパイプラインの変更差分 が追えない。レビューできない。 ● プロジェクトごとに処理がほとん ど共通のパイプラインであっても コピーで増やしてる状態。 © DeNA Co., Ltd. Jenkinsで実⾏されているパイプラインの例 11
Jenkins で利⽤しているプラグイ ンのアップデートが困難 ● 他のチームも利⽤しており、⾃ チームの判断だけでアップデート ができない。 ● Jenkins ⾃体の知識が⾜りない… ⼀部のJenkinsプラグインの状態 © DeNA Co., Ltd. 12
新しいプロジェクトのCI/CDは Jenkins / CircleCI 以外にしたい ● すでに運⽤課題があるところに新規追加はおこないたくない。 ● CI/CDプラットフォームの⼀本化を図りたい。 © DeNA Co., Ltd. 13
求める要件 1. GitHub のアカウントさえあれば使える。 2. 利⽤にあたって追加費⽤がかからない or 安い。 3. ワークフロー⾃体がコードで管理可能。 4. 学習コストが低めでメンテしやすい。 これらの条件を GitHub Actions は満たしている! © DeNA Co., Ltd. 14
GitHub のアカウントさえあれば 使える ● 基本的にリポジトリ、組織ごとに 利⽤するかどうかを決められる。 引⽤: Managing GitHub Actions settings for a repository - GitHub Enterprise Server 3.10 Docs © DeNA Co., Ltd. 15
利⽤にあたって追加費⽤がかから ない or 安い ● セルフホストランナーを運⽤する料 ⾦は⾃分たちで持つことになるが、 それ以外に追加費⽤はかからない。 ● セルフホストランナーを⽴てるイン スタンスの運⽤次第で料⾦が変わっ てくる(GitHub Actions ⾃体の問題 ではない)。 ● セルフホストランナーが⽴てられる 要件を満たしたEC2インスタンスを ⾃チームですでに持っていた。 © DeNA Co., Ltd. 引⽤: About billing for GitHub Actions 16
ワークフロー⾃体がコードで管理可能 / 学習コストが低めでメンテしやすい ● ワークフローは YAML 形式。 name: hello on: push ● 詳しい書き⽅などは Understanding GitHub Actions を参照。 pushイベントで発⽕する defaults: run: shell: bash jobs: hello: runs-on: [self-hosted] 実⾏したい処理を書く steps: - name: "echo Hello" run: echo "::notice ::Hello, DeNA TechCon!" © DeNA Co., Ltd. 17
GitHub Actions 移⾏によって解消した課題 © DeNA Co., Ltd. 18
(再掲)直⾯していた課題 1. Circle CIのジョブ管理者が実質⾃分のみ 2. Jenkins のジョブが GUI ベースでコード管理されてない 3. Jenkins で利⽤しているプラグインのアップデートが困難 4. 新しいプロジェクトのCI/CDは Jenkins / Circle CI 以外にしたい © DeNA Co., Ltd. 19
課題の解消 1. Circle CIのジョブ管理者が実質⾃分のみ ○ 2. Jenkins のジョブが GUI ベースでコード管理されてない ○ 3. © DeNA Co., Ltd. → YAMLで書ける! Jenkins で利⽤しているプラグインのアップデートが困難 ○ 4. → チーム全員で管理できる! → アップデートをしなくてよくなった! 新しいプロジェクトのCI/CDは Jenkins / Circle CI 以外にしたい ○ → GitHub Actions が新たな選択肢になった! ○ (ものによっては AWS CodePipelineを使っているものもある。) 20
移⾏にあたって困ったこと © DeNA Co., Ltd. 21
Jenkins のパイプラインをGUIか ら読み解くことが難しかった ● Job A→Job B→Job C→…みたい に次々にジョブが⾛るものなどが 難しい。 ● Job A→Job B程度のものから移 ⾏していく。 ● そのまま移⾏ではなく、あるべき 姿で移⾏していく。 © DeNA Co., Ltd. Jenkinsで実⾏されているパイプラインの例(再掲載) 22
セルフホストランナーが⽴ってい るOSが古く Node.js v18以上が動 かなかった ● Node.js v18以上で動かすアク ションが軒並み動かない。 ● 全社⽤セルフホストランナーであ れば使える。ジョブごとにラン ナーを切り替えて対応。 ● ⾃チームのOSのバージョンアッ Node.js v18+ で必要なライブラリが⾒つからなかった プは別途進⾏中。 © DeNA Co., Ltd. 23
本番環境で実⾏できるワークフ ローを制限する⼿段が導⼊した当 初はまだなかった ● 本番環境で実⾏可能なワークフ ローはプルリクもちゃんと通した ものだけにしたかった。 ● 現在は指定したワークフローだけ が本番環境にあるセルフホストラ ンナーで動かせる。 ● github.com では enterprise アカ ウントなどで利⽤可能(リンク)。 © DeNA Co., Ltd. ワークフローを指定する例 24
導⼊当初はワークフローの共通化 ができなかった ● 現在は Reusable workflow とい うもので共通ワークフローを定義 できる。 jobs: ReuseableMatrixJobForDeployment: strategy: matrix: 共通ワークフローを呼び出す target: [dev, stage, prod] uses: octocat/octo-repo/.github/workflows/deployment.yml@main with: target: ${{ matrix.target }} 引用: Reusing workflows - GitHub Enterprise Server 3.10 Docs © DeNA Co., Ltd. 25
移⾏にあたってよかったこと © DeNA Co., Ltd. 26
CircleCI から GitHub Actions の ワークフロー読み替えは簡単 ● ⽤語や概念に違いはあるものの、 読み替えるのは難しくなかった。 ● 公式が移⾏ガイドを⽤意している (移⾏当時知らなかった)。 ● 移⾏ガイド⾒なくても移⾏でき た。 © DeNA Co., Ltd. 引用: Migrating from CircleCI to GitHub Actions 27
シェルスクリプトの呼び出しがで
きる
●
Jenkins で動かしていたシェルス
DEPLOY_COMMAND="source ${HOME}/.bashrc &&
source ${HOME}/perl5/perlbrew/etc/bashrc &&
perlbrew use infra &&
クリプトをほぼそのまま GitHub
Actions で流⽤できた。
●
メンテできなくなってた Slack
bot の移植もできた。
cd ${HOME}/example_js &&
-
git checkout ${branch} &&
-
git reset --hard origin/${branch} &&
-
git pull origin ${branch} &&
+
git reset --hard &&
+
git fetch origin -P &&
+
git checkout ${RELEASE_COMMIT} &&
releaseCommand -c ${HOME}/etc/release/example_js.perl
${COMPONENT} deploy:all -s service=dev_sandbox &&
releaseCommand -c ${HOME}/etc/release/example_js.perl
${COMPONENT} deploy:all -s service=dev_service
"
JenkinsからGitHub Actions へ移行する時の修正差分例
© DeNA Co., Ltd.
ランナーのインストールは簡単 ● インストール⽅法はランナー追加 # フォルダを作る $ mkdir actions-runner && cd actions-runner 時に右のコードのように表⽰され る。 ● # ダウンロードする $ curl -o actions-runner-osx-x64-2.304.0.tar.gz -L -H 'Authorization: Bearer hoge' 表⽰されたコマンドを素直に叩く https://github.com/_services/pipelines/_apis/distributedtask/package だけでいい。 # 解凍する download/agent/osx-x64/2.304.0 $ tar xzf ./actions-runner-osx-x64-2.304.0.tar.gz ● インストールでつまずくことはな # インストールする $ ./config.sh --url https://github.com/kimikimi714/example --token かった。 XXXX # ランナーを起動する $ ./run.sh © DeNA Co., Ltd. 29
今後やっていきたいこと © DeNA Co., Ltd. 30
今後やっていきたいこと 1. 2. 3. 脱 Jenkins ○ Jenkins のパイプラインの数が多い。 ○ Reusable workflow で共通化しつつ移⾏していく予定。 本番デプロイの⾃動化 ○ 現在はあたたかみのある⼿動運⽤。 ○ チームメンバーと協⼒して進⾏中。 GitHub マシンユーザーの排除 ○ マシンユーザーのパスワード管理が⼀部メンバーに依存している。 ○ リポジトリのチェックアウトなど GitHub Apps で可能。 ○ すでに⼀部リポジトリではマシンユーザーを使わずにチェックアウトしてテストを回せてい る。 © DeNA Co., Ltd. 31
ご清聴ありがとうございました © DeNA Co., Ltd. 32
Appendix © DeNA Co., Ltd. 33
FAQ ● 全社⽤セルフホストランナーがあるのに⾃チーム⽤にセルフホストランナーを⽴てたの はなぜ? ○ 全社⽤セルフホストランナーと⾃チームの開発環境のネットワークが隔離されて いて、CDが全社⽤セルフホストランナーでは動かせない。 ○ また GitHub Actions が全社に導⼊された当初はまだ全社⽤セルフホストランナー がなく、⾃前で⽴てるしかなかった。 ○ 今は⽤途に応じて全社⽤セルフホストランナーと⾃チームのセルフホストラン ナーを使い分けている。 © DeNA Co., Ltd. 34
FAQ ● Jenkins プラグインのアップデートが困難だというが、actions のアップデートも必 要。困難さに変わりはないのでは? ○ Dependabot や Renovate のようにactionsの更新をおこなうツールが今は充実し ている。 ○ テストが通れば⾃動マージも設定次第で組むことが可能なので Jenkins プラグイ ンのアップデートよりも運⽤しやすい。 © DeNA Co., Ltd. 35
FAQ ● CircleCIからの移⾏って本当に簡単だったの?困ったことはなかった? ○ .circlrci/config.yml から .github/workflow/ci.yml に書き換えること⾃体は本当に 簡単だった。 ○ 難しかったのは CircleCI の CI で利⽤していた独⾃ Docker image からの脱却。 ○ あるプロジェクトでは Dockerfile に compass のインストールが記述されてるもの があった。 ○ © DeNA Co., Ltd. 先に脱 compass してから脱 CircleCI の順に進めた。 36
FAQ ● 「ジョブごとにランナーを切り替えて対応」と⾔ってたが、どんなことをしてるのか? ○ Node.js v18+ が必要なフロントエンドのビルドは全社⽤セルフホストランナー で、デプロイは⾃チーム運⽤のランナーでおこなっている。 ○ ビルドしたJSは全社⽤セルフホストランナー上に⽣成されるので actions/upload-artifact でアーティファクトとして⼀時保存し、デプロイ時に actions/download-artifact でデプロイ⽤ディレクトリにダウンロードしてくる構 成になっている。 © DeNA Co., Ltd. 37