CI/CD環境としてGitHub Actionsを選んだ理由 July 21th, 2023 Matsumoto Hiroki Marketing Cloud Platform Department Rakuten Group, Inc.

2 Profile 松本宏紀 ( Matsumoto Hiroki ) • Reliability Engineering Team • Software Engineer • Joined Rakuten in 2020 • Published • OSS: Passenger Go Exporter • Presentation: デプロイメント⼿法を選択する ~ Flagger/Argo Rollouts ~ • GKE + Java + Cassandra → Ruby + Go + Kubernetes ( Private Cloud / AKS ) • Twitter : @hirokimatsumo13

3 Table of Contents 1. CI/CD環境の歴史 2. GitHub Actionsの機能 3. Self Hosted Runner環境 4. 学習コストと⽣産性、そして独⾃性

4 CI/CD環境の歴史 GitHub + CircleCI Bitbucket + Jenkins GitHub + GitHub Actions 2021 より⾼い再利⽤性と学習容易性を求めてGitHub Actionsに移⾏ Actionの再利⽤性、そして簡潔なコードがとても魅⼒的。 GitHubのアカウントさえあれば、簡単に開発して動かすことができることとても開発者に対して良い体験を もたらすことができる。

5 GitHub Actionsの機能 Action 環境構築部分などはほぼコードを書く必要がない。また⾃分たちでこのActionを容易に作ることができる。 ロジックを書くというよりも、やるべきことをYamlで宣⾔するという感覚に近い。 タイミング • プルリクエストが作成・変更された場合 • タグが作成された場合 • ⽇時ベースでのスケジューリング 独⾃のアクション • デプロイ先にmatrixの提供 (後述) 実際の例 • https://github.com/rakutentech/passenger-go-exporter/blob/main/.github/workflows/pull-request.yml • https://github.com/rakutentech/passenger-go-exporter/blob/main/.github/workflows/releease.yml

6 GitHub Actionsの機能 Strategy Libraryにおいて、複数の環境下でのテストを⾏う際、また複数のKubernetesクラスタへのアプリケーション のデプロイなどで利⽤。配備先の管理は別に管理できる。 実際の例 • https://github.com/rakutentech/passenger-go-exporter/blob/main/.github/workflows/e2e.yaml name: Kubernetes Clusters outputs: matrix: value: ${{ steps.set-matrix.outputs.matrix }} runs: using: composite steps: - id: set-matrix run: | cat <> $GITHUB_OUTPUT matrix={ "include": [ { "k8s": ”$CLUSTER", "version": "v1.25.6", "overlays-resource-name": "$OVERLAYS" }, { "k8s": "$CLUSTER", "version": "v1.25.6", "overlays-resource-name": "$OVERLAYS" } ] } EOF shell: bash

7 GitHub Actionsの機能 Environments 環境ごとに変更したい変数管理、対象ブランチの指定、必須レビューの担当を指定できる。 実際の利⽤例 ・リリース時のフロー kubectl diffの表⽰ Approval kubectl applyの実⾏ Tagの作成 Productionに関してはレビュー必須、その他環境はレ ビュー無しといったことが可能。

8 GitHub Actionsの機能 Notification • https://github.com/integrations/slack • https://github.com/integrations/microsoft-teams ⾃分たちの場合は、Webhookを利⽤したActionを利⽤。

9 GitHub Actionsの機能 CI/CD Tool 理解・習得性 解析性 試験性 安定性(※) ランニングコスト(※) Jenkins Circle CI GitHub Actions 個⼈でも利⽤しやすくて学びやすい、そしてfork先で簡単にテストできる部分がとても良い。 独⾃に共通部分を作る部分は少なくMarketplaceで数多く提供されており、その知識や経験を 即戦⼒として活かしやすい。独⾃に作られた領域の学習コストは⾼い。 ※楽天でのon-premises環境における⽐較であり、SaaS環境として提供される環境での⽐較ではありません。

10 GitHub Actionsを通じた学び 仕事を通じてより⼀般的な技術要素を学ぶ機会が増える。エンジニアとしても⾃信につながる。

11 Self Hosted Runner 環境 楽天環境下ではEnterpriseレベルのRunnerは提供されていない。 各⾃がSelf Hosted Runnerを管理する必要がある。 Actions Runner Controllerを利⽤して、最適化を図っている。 管理対象 10 organizations Over300 repositories Azure AKS Actions Runner Controllers controller organization runner 0~Nでqueueベースでのスケーリング。

12 Self Hosted Runner 環境 Metrics監視のためにリポジトリ登録しないといけない問題 https://github.com/actions/actions-runner-controller/blob/master/docs/automatically-scaling-runners.md 頻度が少ないために忘れがち。特にDev Teamの⽅はこれを対応しないとCI/CDが満⾜に動かせない問題 がある。だからといって、hookして⾃動登録するほどのものでもないよなというジレンマがある。 Permission 問題 おそらく下記に関連。 https://github.com/actions/checkout/issues/956 docker run –it –rm bundle -v $(pwd):/xxx xxx exec rspecなどでroot権限などで動かし、ファイルが⽣成さ れた時にクリーンアップされず、次回checkout時にエラーが発⽣する問題があった。 https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job https://github.com/actions/actions-runner-controller/pull/1268 上記を利⽤して、$GITHUB_WORKSPACEを最後にクリーンアップするようにして解決。 #!/bin/sh if [ -n "$GITHUB_WORKSPACE" ]; then echo "CLEAN UP !!!! ${GITHUB_WORKSPACE}” sudo rm -rf $GITHUB_WORKSPACE fi

13 学習コストと⽣産性、そして独⾃性 ⽣産性を上げるために、独⾃性はどうしても⽣まれる 汎⽤的なフレームワーク・ライブラリを⾃分たちのプロダクトに適⽤するためには、そこにどうし ても独⾃性は⽣まれてしまう。 その独⾃性というのは新しく⼊ったエンジニアの障壁となり学習が必要となる。 具体的例として、300以上のリポジトリ管理は⾟く、より管理を楽にするためのシステムを構築し ているが、全体最適化を図ることによってその全体を管理するためのシステムを理解する必要性と いうのが⽣まれてしまう。それを緩和するために特に気をつけていること。 それが如何に優れたプロダクトであれ、閉じられた環境でしか学べない、試せないものはデメリッ トが⼤きい。 理解︓明⽰的なコード・設定・宣⾔ 学習︓試しやすい環境 学習︓より⼀般的・学習しやすい環境

No content