GitHub Actions を初めて自作したので学んだことをまとめる

タダです.

GitHub Actions を初めて自作したのでその過程で学んだことをこの記事にまとめていこうと思います.

自作した GitHub Actions の概要

自作した GitHub Actions は TypeScript で書いた GraphQL を叩いて dependabot の情報を抽出するもので,プライベートリポジトリ間で使えるようにする必要がありました.このあたりで学んだことは関連記事に書いています.この記事では関連記事に書けていないことをまとめます.

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

学んだこと一覧

TypeScript で作るために取っ掛かりとしてよかったもの

TypeScript で Actions を作るぞってなってもどう作るの？なんかサンプルが欲しいなと思っていました.そんな時に良かったのが, typescript-action です.これは TypeScript の GitHub Actions サンプルで自分のリポジトリにテンプレートして持ってこれるため,一番はじめにどういうふうなコードを書けばいいのか,必要なパッケージ類は何かなどを GitHub のドキュメントと合わせて読んで理解を進めることができました.

github.com

結局何が必要なのか

結局,今回自作するために最低限必要になるなと感じたのは下記のものです.

• Actions のソースコード
  • Actions を動かすためのコード本体.TypeScript,package-json が最低限必要.
• action.yml
  • Actions の定義ファイル.これがないと呼び出し先で GitHub Actions が動作しない.
• @actions/core
  • Actions が呼び出し先からインプットの情報を得るために必要.
• @vercel/ncc
  • 後述する Actions を配布する時に必要.

Actions を使ってもらう時にパッケージ類をどうするか

TypeScript のコードを書いてローカルで意図通りに動作したから次はどう配布するかのときに悩みました.プライベートリポジトリ間の呼び出しは上述した記事に書いたように解決したものの,Actions を呼び出し先では package.json にあるパッケージは既にインストールされた状態で実行できなければ機能しないけど,どうやって配布するのかがわかりませんでした.結論として @vercel/ncc を使って TypeScript のコードをビルドしたものを呼び出し元のリポジトリに配置しておけば,呼び出し先で Actions が動作しました.

ビルド例

ncc build src/index.ts

github.com

まとめ

GitHub Actions を初めて自作したのでその過程で学んだことをまとめました.これまで使うばかりだったのですが,自作できる経験がなかったので今後も作っていきたいです.

プライベートリポジトリで自作 GitHub Actions を動作させるために必要な設定

タダです.

業務で GitHub Actions を開発したのですが,その Actions はプライベートリポジトリに起き,別のプライベートリポジトリから Actions を呼び出すことをやったので小ネタとしてまとめます.

概要

リポジトリ A に Actions のコードが入っており,リポジトリ B で Actions を呼び出すとします.

リポジトリ B の workflow 設定

.github/workflows 配下にリポジトリ A の Actions を呼び出す定義を書いてみます.

設定例

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          repository: hoge/リポジトリ A
          ref: main
          path: .github/actions/リポジトリ A
          token: ${{ secrets.PERSONAL_GITHUB_TOKEN }} 
      - name: test actions
        uses: ./.github/actions/リポジトリ A
        with:
          param1: value1
          param2: value2

上記の設定でリポジトリ A で main ブランチにあるコードをチェックアウトしてきます.その際に,Personal Access Token を使っているので,発行して Secrets に登録しておきます.この際に設定する権限は repo 全般の権限で確認しました.actions/checkoutが通れば,自作している Actios を実行するのに必要なパラメータをセットしたりすればよいですが,usesでチェックアウトで指定したパスを指定してます.指定したパスに action.yml がないとエラーで何回か失敗したので指定には注意ください.

関連情報

github.com

zenn.dev

まとめ

プライベートリポジトリ間での GitHub Actions の呼び出し方法をまとめました.今回の経験でこれまで Actions はパブリックリポジトリじゃないと呼べないのだろうと一方的に勘違いしていたのを正せました.また,企業内のリポジトリであれば,こういった使い方はありうると思いますしあまり記事を見かけたなかったので記事にしてみました.

SRE NEXT 2022 Day2 参加レポート #srenext

タダです.

SRE NEXT 2022 の Day2 参加レポートを書いていきます.自分が聞いたセッションでのメモを転記しながら感想を書きます.

sre-next.dev

Day1 の参加レポート

sadayoshi-tada.hatenablog.com

SRE bridge the gap: Feature development to Core API / 機能開発チームとコアAPIチームの架け橋としてのSRE

Shopify の SRE の記事を見てから気になっていたキーノートでした.Shopify の中での SRE の実践でやっていった内容も興味深かったのですが,Shopify の中での信頼性に関する考えやキャリアの多様な在り方を認める文化って素敵だと感じました.

sre-next.dev

メモ

• どういったタイミングで Production Engineering モデルが導入され,SRE チームが何を担っているか
  • Production Engineeringの独立組織を作ってえた効果(2016~2017頃)
    • 機能開発チームで自分たちの環境を自律的に運用するためのツール開発
    • スケーラビリティやレジリエンシーへの投資
      • 結果として3倍のデプロイ頻度が増えた
  • Production Engineeringのチームも大きくなってきた(2020年ころ)
    • Incident Manager On Call(IMOC)を担い始めた
      • SLO 違反になりそうなインシデント
  • 信頼性について
    • Shopifyの考え：信頼性を脅かすことを享受すること(必要なこと)でしなやかなシステムにできる
      • 未来のRPMにするために学ぶ
    • Shopifyの複雑さ
      • フラッシュセール:トラフィックがスパイキー
      • ショップごとに機能要件が異なる
    • 対応
      • Semian
        • 外部サービスへの通信して遅くなったら失敗したときにサーキットが落とす 関連記事
      • Load Shedder
        • DDoS を受けた時に同じようなトラフィックをEdgeでブロックする
      • Toxiproxy
        • 外部サービスの失敗したのシミュレーションできる
          • Game Dayで失敗をして学ぶ
      • 文化やプロセス
        • 燃え尽き症候群が少ない
        • タイムゾーン別シフトを組んで、引き継ぎを行っていく
• キャリアの話
  • キャリアの3つの観点
    • 機能開発
    • CoreAPI
    • SRE
  • 機能開発
    • 剣を使う人
      • どれだけ早くエンドユーザーにリリースできるかが関心事
  • Core API
    • 剣を作る人
      • ドメインエキスパート
  • SRE
    • 剣を研ぐ人
      • 分散型システムの失敗パターンに対するエキスパート
  • それぞれのキャリア分野を掛け算ができる
    • 1つのチームの中で計画をする際に,違った視点を入れていく

Who owns the Service Level?

二年前の SLO Review の発表からの振り返りを共有いただいたセッションでした.なにかアクションを取る時に自己完結化できるようにすることは重要だと自分の経験上感じていたり,そのための権限や調整も必要だと思っていました.その中で組織内の技術戦略にまで踏み込んでいったお話は自分にとってなかった考えで,いろんな人々を巻き込んで進めることを体現されているなと感じました.

sre-next.dev

資料

メモ

• SRE を実現するために必要な要素
  • 指標をもとに完全し続ける文化
  • 自己完結化を支えるプラットフォーム
  • 優先順位を変更するための技術戦略
• SRE でやること
  • ユーザーが期待する信頼性を保っていること
    • やりすぎなくていい
  • SLI/SLO を設定して非機能、機能の優先度決定するのに活用している
  • 目標値のモニタリングとポリシーがチームで同意されている
  • 定期的に見直されている
• チムトポ
  • SRE と 開発チームの関係性
    • SRE : Platform(APIを使って提供),Enabling(専門家として他のチームが自律的に運用できるようにする)
    • 開発チーム : Stream Aligned (自分たちで必要なものを自分たちで用意できる/自己完結化)
• MVVの話
  • Mission
    • 自己完結化の重要な理由：他チームに必要なものを用意するために時間がかかってもったいない
      • 自己完結化が進むと,Dev vs Opsのような関係から And の関係になる
• SLO Review の発表振り返り
  • 良かったこと
    • 開発チームの認知不可を徹底的に下げることに拘った
  • うまくいかなかった
    • エラーバジェットができなかった
      • SLI / SLO に従って行動できなかった
        • 非機能要求に対する権限・予算不足
    • SLO 違反したら全ての開発を止めてその修正を行うのは現実的ではないが、目標値を下回ったときのアクションを決める
      • 全員で負担する
• 技術戦略
  • ビジネスの速度に追随するため、技術戦略が必要
    • 変更をしやすいシステム・コード・組織にする
      • 変更速度を妨げる要因を排除
  • 技術的課題・負債をコントロール下におく
    • 特定の人に依存しないようにする

SLO決定のためのArt of SLO

転職先でも SLO の策定の話が出てきたので改めて決定に至るプロセスを確認したくて参加しました.CUJ -> SLI -> SLO -> エラーバジェットを策定するのが良さそう,加えてワークショップの紹介や質疑応答で SLO で追う目標値の数は 3~5 個で良いや SLO が顧客の期待に応えているかを見るのは難しいものの山口さんより参考情報をいただけたのは参考になりました.

sre-next.dev

メモ

• CUJ
  • Critical User Journey
  • シーケンス図を書く
    • コンポーネント間のリクエストの様子を明らかにする -> SLI を決める
• CUJからSLIを導き出すプロセス => 3~5くらいにするといい(振り返りで有効なものを選ぶ)
  • SLIを導き出すメニューが有る
  • SLI を導くイベントをもとに見るべき数値やメトリクスが決まってくる
• SLO決定のためのプロセス
  • 目標値と測定期間が必要
    • 過去データを参考にどれくらいのユーザーをカバーできているかを確認する
    • リクエストをカバーしないと収益に問題ないか
• The Art of SLO ワークショップ
  • グループワークで進めるコンテンツのためチームで SLO 策定の際にやってみると良さそう
  • 下記のブログでも CUJ から SLI/SLO/エラーバジェットを定めるプロセスをさらえる

medium.com

まとめ

Day2 で参加したセッションとそのメモ,所感をまとめてみました.運営の皆さん,登壇された皆さん,お疲れさまでした！ Podcast でも雑談しました.

anchor.fm

Day2 の公開された資料

直接セッションを見に行けてないですが,公開された資料のリンクをまとめてくださっている方がいたのでリンクを貼らせていただきます.

docs.google.com

SRE NEXT 2022 Day1 参加レポート #srenext

タダです.

SRE NEXT 2022 の Day1 参加レポートを書いていきます.自分が聞いたセッションでのメモを転記しながら感想を書きますが,私用の関係で最後まで参加できていないところがあります 🙇

sre-next.dev

How We Foster "Reliability" in Diversity

SRE as Service で他社の SRE プラクティスを実践してきた経験からどのように組織で SRE を実践.組織に適した SRE を定義して育てていくための取り組みの紹介するお話でした.SRE の実践の5つのステップは自分が体感したものと合致したので納得感があったり,組織変革のためのアプローチで MVV の作成や環境変化に伴うためのアプローチで組織の多様性が役立つというのは新たな気づきを与えてもらったセッションでした.

sre-next.dev

資料

メモ

• 適切な SRE の実践がなぜ難しいのか
  • SRE に求められるものが多様化している
    • 組織ごとに信頼性が異なる(サービスを取り巻く全ての要素が同じにならない)
    • 信頼性の計測方法も異なる
• システムの特性によって信頼性が異なる(緊急速報とコーポレートサイトの比較)
  • 短距離じゃなくて長距離
• 技術的な側面と文化やプロセスなどの組織的な課題が関わる
  • SRE は組織の変革を伴うから一朝一夕にできない
• SRE の実践の取り組み
  • SRE の実践における5つのステップ
  • 組織が自律的に動けるようにする
  • 組織の氷山モデル
    • 組織変革は上からも下からもアプローチが必要
    • Level3 からのアプローチ
  • SRE の方向性と価値観を明確にする
    • SRE のミッション、ビジョン、バリューを定義する
  • 企業・組織コンテキストの把握
    • 会社の方向性と SREs の MVV を合わせる
    • 企業活動を俯瞰的に捉えて,SRE の影響のある主要な変数を整理する
    • 様々なリソース：企業方針/サービス/組織のコンテキストを把握する
• MVV 作成のステップ
  • 関係者へヒアリング
  • たたき台作成(8割位作る)
  • レビュー&修正
    • 大枠を固めたら使う言葉の選定やニュアンスの確認を同期的に行う
  • KPI
    • 文化情勢のためのMVVを作るだけでなくKPIを定めていく
• 環境の変化に対してどのように取組むか
  • サービスによって適切な信頼性は変わるので変化の対応するための良いアプローチがないか模索
  • SRE 本 18.3.5 チームの力学 では多様性によってチームの問題点への盲点をなくす
    • 組織の環境変化への耐性を保つために組織の多様性が役立つ

SRE の歩き方・始め方

Q&A 方式で SRE とは？実践の仕方の紹介のセッションでした.特に Toil 削減の話は SRE 本でも見て実施していく必要があると思っていましたが,なぜやるのかの部分で改めて SRE の時間の確保だけでなくキャリアの停滞や燃え尽きなどの悪影響を見て,自動化できるものはしていく必要があると再認識しました.

sre-next.dev

メモ

• そもそもSREとはなにか？
• SRE は 2004年からGoogleにチームが発足
  • サーバー/MW のセットアップをソフトウェアの課題として扱う
  • オペレーションに正しくエンジニアリングを取り入れて改善し続けること
    • システムが安定してればいいというのではなく,数字でコントロールする
    • 手作業を行わず自動化してサービスをスケールさせていく(人を増やすのではなく)
• SRE と DevOps の関係とは？
  • 同じ課題を別のアプローチで解こうとしている関係性
  • Dev/Opsのサイロ化という課題を解消しようとする側面がある(オペレーションをソフトウェアとして扱う、DevとOpsを分業するのではなく協業していく)
    • class SRE implements DevOps
  • SRE のプラクティスはDevOpsの範囲外(TOILの削減)範囲内(Dev / Ops の協業体制)の具体的な手法が提案されている
• class SRE implements DevOpsを踏まえ、どういう形で SRE の実践・プラクティスを実践するか
  • SLI/SLO & Error Budget -> 信頼性のプラクティス,Window: SLI/SLOを評価する期間
• SLI/SLO , Error Budgetの決め方
  • SLI :何らかの割合となるように値を定める
    • サービスや事業の目標と関連するような指標を定めるといい
    • サービスステークホルダー目線にもそったものにして、指標の状況に沿って開発の課題も向き合えるようにすると良い
  • SLO: 高い値を目指しすぎないこと
    • 開発速度とサービスの信頼性をうまくコントロールできるように値を調整
  • 大事なこと:サービスのステークホルダーや関係者と合意を取りながら決めること,決めたものを改善し続けること
• Toil はSREのエンジニアリングの時間を奪うものになるので削減していく
  • ほっとくと増えるからSREの作業の50%未満になるように意識する
  • Toil はすべて解消しないと、仕事の時間を確保できないし、キャリアの停滞、燃え尽きなどの悪影響
    • 解消しなくてもいいものも多少はあることを受け入れる
• ポストモーテムは組織全体がインシデントから学ぶフロー
  • ポストモーテムをかく基準や文化の醸成が必要
• SRE プラクティスを組織に導入するためにきをつけること
  • SRE がエンジニアリングができるようにすること
• 実践例として Embeded SRE がある
  • 開発チームに SRE が入ることで開発側からすると SRE の実践をそばで見れる
  • 開発チームの事情も SRE がチームに持ち帰れる

事業の成長と歩む、ABEMAのSRE探求の歴史

SRE のプラクティス実践における活動の中での行ってきたこと,振り返り,そこから改善したことをユースケースで知ることができました.SRE の実践は小さく初めて素早く失敗する大切さと関連するステークホルダーとの関係性を考えつつ進める必要があると感じた事例セッションでした.

sre-next.dev

メモ

• ABEMA のサービス紹介からチームとして活動してきたことと今後について
• SRE チーム発足の背景
  • 24/365だから障害時のインパクトが高い
  • 映像の通信トラフィックが多いので、物理的な限界を考慮する必要あり
  • 様々なデバイス対応しているため、デバイスに応じて品質維持
  • サービス、組織規模、システムの巨大化に伴いサービス品質維持しつつ、事業成長に伴ったシステムをスケールするためのチーム発足
• 2018~2020年の活動
  • 横断的な活動をして、アジリティとプラクティスの導入をやった
    • マイクロサービスも非常に多くあったので,SRE だけで品質担保が難しく開発プロセスを含めていった(Production Rediness Checklist 作成)
    • キャパプラを開発チームに移譲
    • On-Callからの離脱(自律性向上)
    • SRE 文化の推進
  • 多くの課題が発生
    • 開発チームのリソースが確保できない
      • 開発チームのベネフィットを意識すること(アジリティと信頼性を保つ)
    • システム構成が少しずつ不明
    • リスク把握のコスト増
    • SRE チーム内で優先度が決めづらい
      • 兼務は難しい
• 2021年〜現在の活動
  • 体制変更の実施
    • クラウド基盤のチームと SRE のチームを分離
    • 開発チームの中でも SRE の実践メンバーを抽出
  • SLI/SLOの先導
    • リクエスト数の少ないサービスでのアラート調整
    • 新しい計測手法の導入
    • 設定の簡略化
    • 効果としてサービス全体を俯瞰して品質が把握できるようになった
  • インシデント関連
    • インシデントへの参加やポストモーテムの先導を通して,インシデントフロー見直し,障害レベルの設定や障害を先導する Bot の開発
    • 効果として組織全体の障害への練度上昇
  • モニタリング課題の解決 *フロントエンドにおけるモニタリング強化するために要件,検証して New Relic 導入
    • 効果として広い範囲での可視化,アラート対応がフロンエンドエンジニアだけでできるようになってる
• 今後として FIFA の無料放送を行うことになったので負荷対策や障害対策をしていく

LegalForceの契約データを脅かすリスクの排除と開発速度の向上をどうやって両立したか

プロダクトで重要なセキュリティの管理と開発のアジリティを維持しながら顧客への価値提供を行っていくための取り組みを紹介するセッションでした.セッション中に出てきた認知過負荷という言葉を初めて知り,組織スケールや扱うプロダクトの複雑性が増してくると発生しそうで早めに手を付けて改善しとかないと手がつけられなくなりそうだなと思いました.自分が遭遇したら改善や明瞭にすることを図っていきたいです.

sre-next.dev

• 契約データの重要性
  • 第三者へ漏洩すると犯罪に発展する可能性がある
  • インサイダーや詐欺などの悪用される
    • 契約データは最優先で保護する必要があるが、開発上の課題がある
• 認知過負荷の課題
  • 変更に対するリスク制御が困難、リスク肥大化のおそれ
  • 変更時や動作確認テストの工数増大 -> デプロイ頻度低下 -> 顧客への価値提供低減
• 認知過負荷に対する取り組み
  • 守るべきものの定義
    • PRR & Premortem(大きめの機能開発時に実施)
      • PRR:機密情報の有無、リスク
      • Premortem:扱う機密情報が漏洩しないかの議論
    • ガードレールの導入
      • AWSのサービスで実施(アカウント分離,SSO,監査ログ基盤に集約 etc)
    • 人の権限情報のコード化と自動デプロイ:誰でも閲覧・編集できるような状態にするため
    • 既存の権限内容の簡素化:条件分岐図と真理値表、論理式を書いて実装に落とす
      • 認知負担がへった
      • 環境差をなくす
• 実践の効果
  • 開発者に体験向上した点をヒアリングして,認知的負荷の低減を確認

一人から始めるプロダクトSRE

プロタクト SRE のロールを持っているのは1人だけという状況で現場に合わせて意思決定を行ったり,目の前の課題解決,SRE 立ち位置の定め方,メンバーの巻き込み方を紹介のセッションでした.

sre-next.dev

資料

メモ

• クラウド勤怠の場合
  • 最初のSREとしてはいった
  • 開発者はSREにコンバートする余裕はなく、経験している人もいない
• 現状把握 *ドメイン知識やチーム状況を把握

  * チームの課題状況を観察する
  

  • 運用ペインが発生している可能性があるので理想と実態とのギャップを埋める
    • 無差別アラートによって開発者生産性が低下
    • 適切なモニタリングを行うのをやる
      • SLI/SLO策定
      • ダッシュボードの構築
• プロダクトチームへの安心してもらうための取り組み
  • SREの責務 -> どうプロダクトに関わらるのか、誤解があれば解消
  • 在り方を伝える -> ミッションを決める
  • SRE1人問題への向き合う
    • Core? Embederd? Enabling? => Enabling を選んで取り組んだ
• Enabling SRE としてやってきたこと
  • メンバーの活動をフォローや感謝を送る
  • システムダッシュボード振り返り会
  • 工数の調整と優先度付(dely さんの取り組みを参考)
  • 人として信頼されること

まとめ

Day1 で参加したセッションとそのメモ,所感をまとめてみました.運営の皆さん,登壇された皆さん，お疲れさまでした！Day2 も楽しみ！

Day1 の公開された資料

直接セッションを見に行けてないですが,公開された資料のリンクもまとめていきます.

TypeScript で GitHub GraphQL API を叩いてみた

タダです.

GitHub GraphQL API を叩く機会が初めてあったのでこの記事に備忘録としてまとめていきます.

前準備

事前準備として GitHub アクセストークンを発行します.権限として下記のものをつけます.

• repo
• admin:org read
• admin:repo_hook read
• user
• admin:gpg_key read

https://docs.github.com/ja/graphql/guides/forming-calls-with-graphql

試したコード

dependabot アラートにあるものをリストするようなコードを書いてみました.ライブラリとして @octokit/graphqlを使っています.クエリで使っているパラメータはドキュメントを参照して設定しています.

github.com

コード抜粋

const QUERY = `
  query getVulnerabilityAlerts($org: String!, $repo: String!) {
    repository (name: $repo, owner: $org){
      vulnerabilityAlerts(last: 100, states: OPEN) {
        nodes {
          createdAt
          vulnerableRequirements
          securityVulnerability {
            package {
              name
              ecosystem
            }
            advisory {
              ghsaId
              publishedAt
            }
            severity
            package {
              ecosystem
              name
            }
            updatedAt
            vulnerableVersionRange
          }
        }
      }
    }
  }
`;

async function main() {
  try {
    const result:any = await graphql(QUERY, {org: `${process.env.org}`, repo: `${process.env.repo}`});
    const detailResult = result['repository']['vulnerabilityAlerts']['nodes']
    console.log(detailResult)
  } catch (err) {
    console.error(err);
  }
}

下記の FastAPI のセキュリティアラートをリストした場合の出力例です.

出力例

[
  {
    createdAt: '2022-01-29T08:39:43Z',
    vulnerableRequirements: '= 0.65.1',
    securityVulnerability: {
      package: [Object],
      advisory: [Object],
      severity: 'HIGH',
      updatedAt: '2021-06-09T13:34:55Z',
      vulnerableVersionRange: '< 0.65.2'
    }
  }
]

まとめ

簡単に TypeScript で GitHub GraphQL API を叩いてみたのでまとめました.これを dependabot の運用でアラートが滞留しているリポジトリや新規のアラートを気づけてない場合にコードを上げるたび都度通知するような GitHub Actions に利用できたら良いかもしれません.

参考記事

maku.blog