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

CI/CD環境としてGitHub Actionsを選んだ理由

CI/CD環境としてGitHub Actionsを選んだ理由

Hiroki Matsumoto

July 21, 2023
Tweet

More Decks by Hiroki Matsumoto

Other Decks in Technology

Transcript

  1. 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
  2. 3 Table of Contents 1. CI/CD環境の歴史 2. GitHub Actionsの機能 3.

    Self Hosted Runner環境 4. 学習コストと⽣産性、そして独⾃性
  3. 4 CI/CD環境の歴史 GitHub + CircleCI Bitbucket + Jenkins GitHub +

    GitHub Actions 2021 より⾼い再利⽤性と学習容易性を求めてGitHub Actionsに移⾏ Actionの再利⽤性、そして簡潔なコードがとても魅⼒的。 GitHubのアカウントさえあれば、簡単に開発して動かすことができることとても開発者に対して良い体験を もたらすことができる。
  4. 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
  5. 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 <<EOF | tr -d '\n' >> $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
  6. 9 GitHub Actionsの機能 CI/CD Tool 理解・習得性 解析性 試験性 安定性(※) ランニングコスト(※)

    Jenkins Circle CI GitHub Actions 個⼈でも利⽤しやすくて学びやすい、そしてfork先で簡単にテストできる部分がとても良い。 独⾃に共通部分を作る部分は少なくMarketplaceで数多く提供されており、その知識や経験を 即戦⼒として活かしやすい。独⾃に作られた領域の学習コストは⾼い。 ※楽天でのon-premises環境における⽐較であり、SaaS環境として提供される環境での⽐較ではありません。
  7. 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ベースでのスケーリング。
  8. 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