Software Design 202407
Github Actions
基本
- 料金
- パブリックリポジトリでは無料
- プライベートリポジトリでは有料だが無料枠あり
- Windows は Linux の 2 倍、Mac は 10 倍
- 手軽さ
- Webhook の設定が不要なので簡単
- イベント / ワークフローをキックする
- ワークフロー / 1 つ以上のジョブを実行する自動化されたプロセス
- ジョブ / 同一のランナー内で実行される一連のステップのまとまり / 逆に言えばジョブが違えば全く異なるまっさらな環境で実行される
- ステップ / 最小の単位 / 以下の 2 つが可能
run
によるスクリプトの実行uses
によるアクション(事前定義された処理のプリセット)の実行- このとき
with
でパラメータを渡すことができる
- このとき
- ステップ / 最小の単位 / 以下の 2 つが可能
- ジョブ / 同一のランナー内で実行される一連のステップのまとまり / 逆に言えばジョブが違えば全く異なるまっさらな環境で実行される
- ワークフロー / 1 つ以上のジョブを実行する自動化されたプロセス
ハンズオン
${{}}
という書式は、GihHub Actions 上で利用できる変数にアクセスするための書式- e.g.
${{ github.actor }}
で実行した Github のユーザー名を取得できる - e.g.
${{ secrets.GITHUB_TOKEN }}
で GitHub Actions で使えるデフォルトのトークンを取得できる
- e.g.
- 以下ような用途には専用の actions が用意されているのでそれを使うと吉
- docker コマンドを使った認証
- docker コマンドを使ったレジストリへのプッシュ
- Amazon ECS や Google Cloud Run などのデプロイ
実運用
- コンテキスト
- github コンテキスト
- ワークフローをトリガーしたイベントやリポジトリに関する情報を持つ
- ブランチ名
${{ github.head_ref }}
- PR の番号
${{ github.event.pull_request.number }}
- PR の作成者
${{ github.event.pull_request.user.login }}
- ブランチ名
- ワークフローをトリガーしたイベントやリポジトリに関する情報を持つ
- job, steps コンテキスト
- 現在のジョブやステップに関する情報を持つ
- ジョブの実行結果
${{ job.status }}
- ステップの実行結果
${{ steps.<step-id>.conclusion }}
- ジョブの実行結果
- 現在のジョブやステップに関する情報を持つ
- vars, secrets
- あらかじめリポジトリや Organization に登録した、変数やシークレット情報
${{ vars.SOME_VALUE }}
${{ secrets.SOME_SECRET }}
- vars と secrets の違いは、secrets はログで
*
でマスクされる点
- あらかじめリポジトリや Organization に登録した、変数やシークレット情報
- github コンテキスト
- アーティファクト
- 成果物を保存するための仕組み
- 専用の action が用意されている
- 複数のジョブ間でのデータの受け渡しのためや、人間が結果を利用するために使う
- 複数 job の順番制御
needs
に依存先のジョブ名を書くことで行う
- 成否による処理分岐
- ステップやジョブに
if: ${{ always() }}
を指定することで、前段の処理が失敗しても必ず処理が実行されるようになる - その他、成功時のみ実行する
if: ${{ success() }}
、失敗時のみ実行するif: ${{ failure() }}
もある
- ステップやジョブに
- キャッシュ
actions/setup-***
などにおいて、キャッシュを有効にするオプションが用意されているactions/cache
を使うことで、任意のフォルダを自由にキャッシュすることも可能- この場合、key の設定には注意。ファイルのハッシュに加えて OS の種類を含める必要がある場合もある。
- トリガーの種類
- label トリガー
- コストが高い処理について、手動でトリガーをかけるときなどに使う
- スケジュール実行
- バッチ処理や、不要リソースの定期削除などに使う
- 最小間隔は 5 分
- 必ずその時間に実行されるわけではなくベストエフォートなので、確実な実行が必要であれば自前でスケジューラを立てて、workflow を API を介して dispatch するなどの方法が必要
- 手動トリガー(workflow_dispatch)
- Github の Web 画面や API を介して、手動実行が可能になる。手元から
gh workflow run
も可能になる。 - 対象のブランチを指定できる。また、あらかじめ指定したパラメータも指定できる。
- 通常のトリガーと併用可能なので、転ばぬ先の杖として使える
- Github の Web 画面や API を介して、手動実行が可能になる。手元から
- label トリガー
- トリガーのフィルタ
- 特定のブランチでのみ実行する
on.push.branches
- 特定のフォルダ内に変更があったときのみ実行する
on.pull_request.paths
- ファイルのフォルダに加え、ワークフローの yaml も含めないと、ワークフロー自体の変更時にトリガーされないので注意
- 特定のブランチでのみ実行する
- 権限
GITHUB_TOKEN
- GihHub Actions が GitHub の特定リソースを扱うための権限
- 特に設定無しで使える
- contents, packages, metadata の 3 つが ある
- contents: read(規定), write, none
- packages: read(規定), write, none
- metadata: 常に読み取り許可で固定
- 明示する場合は、contents と packages の両方を列挙しないと書かなかったものは none になるので注意
- OIDC を用いたクラウドサービス連携
- ワークフロー実行時に、GitHub から発行された OIDC トークンをクラウドプロバイダーに投げ、アクセストークンを得る方法
- クラウド側では OIDC トークンの subject claim を見て、許可を判断する
- subject claim の例:
repo:<OWNER>/<REPO>:refs/heads/main
- subject claim の例:
- クラウド側では、事前に以下の設定を済ませておく必要がある
- 受け入れる subject claim の形式(≒ 対象のリポジトリとブランチ)
- 与える権限
- セキュリティ対策
- 特にパブリックなリポジトリではインジェクションに注意
- なるべく actions を使うこと
- 文字列をコンテキストから取る場合は、一度環境変数に入れてから使うなどの対策が必要
- 特にパブリックなリポジトリではインジェクションに注意
大規模開発での Actions の課題と解法
- コンテナを使う方法
- ジョブコンテナ
- ジョブを実行するコンテナ
runs-on
の階層でcontainer
を指定する
- サー ビスコンテナ
- ジョブの開始時に起動する任意のコンテナ
- DB を立ち上げてテストを実行する際などに使う
runs-on
の階層でservices
を指定する
- ジョブコンテナ
credentials
プロパティにレジストリの認証情報を書くことができる- docker のパブリックイメージを使う場合でも、pull rate limit を防ぐ意味で書いておくとよい
- ランナーの種類
- GitHub-hosted (larger) runner
- Self-hosted runner
- matrix strategy
- ジョブの実行を複数の変数の組み合わせで行うための機能
- ユースケース 1: テストの分割実行
- 例えば jest は shared オプションを使うことで並列実行が可能
- ユースケース 2: テストの動的実行
- JSON を入力として受け取れるので、前段のジョブで条件の組み合わせ一覧を JSON で生成し、それを使って後段で複数のテストを実行することが可能
- GITHUB_TOKEN の制約
- 別のワークフローの実行や、別のプライベートリポジトリへのアクセスはできない
- かといって PAT の利用は非推奨
- GitHub Apps の仕組みに乗る方法がよい(詳細はドキュメント参照)
- キャッシュ
- 上限は 10GB で、超えたら GitHub のお気持ちにより削除される
actions/cache/(save/restore)
を使うことで、キャッシュするしないをコントロールできる- 例えば Dependabot の PR ではキャッシュ読み込みはするけど保存はしないなどの設定はよい取り組み
大規模開発でのワークフロー設計
- ワークフローを DRY にする方法
- Custom actions
- ワークフローから呼び出す形で再利用可能なステップ群
- 呼び出し元と同じランナーで実行される
- ユースケース
setup-***
系のアクションが存在しないツールのインストール- クラウドサービス等への認証
- キャッシュの設定
- 成果物やテストデータのアップロード
- Slack 等への完了通知
- Reusable workflows
- 単体で再利用可能なワークフロー
- 呼び出し元とは異なるランナーで実行されるため、値の受け渡しは inputs, outputs のみ利用可能
- ユースケース
- テストのワークフローをいろんな場所で実行したい
- 環境ごとにデプロイしたい
- Custom actions
- イベントの詳細な種類
on.<event>.types
によりイベントの種類を細かく制御できる- e.g. プルリクエストなら、オープン時、再オープン時、更新時、クローズ時など
- 必須ステータスチェックとジョブのスキップの両立
- モノレポなどでは、対象ディレクトリの変更がなければ テストをスキップしたりするが、このとき必須ステータスチェックに引っかかると困る
- この場合、単一のワークフローの最初のジョブでテストの要否を判断し、後続のジョブでテストをスキップする構成に必要がある
- 失敗したテストだけをテストする
- 失敗したテストの情報をキャッシュに残しておき、2 回目以降の実行ではそこだけ実行することができる(詳細は本文参照)
脆弱性入門
- XSS の種類
- 反射型 XSS
- 攻撃用の JavaScript が攻撃者の用意したサイトや URL に存在するタイプ
- URL の例:
https://example.com/?q=<script>alert(1)</script>
- 持続型 XSS
- 攻撃者が入力したコンテンツが Web サービスのデータベースに保存され、他のユーザーにも表示されるタイプ
- DOM ベース型 XSS
- サーバー側の処理を経由せず、クライアント側で不正な JavaScript が実行されるタイプ
- 反射型 XSS
ハピネスチームビルディング / モチベーション 3.0
内発的動機づけで主体的に行動するという考え方。1.0 は生きるため。2.0 はアメとムチ。3.0 は内発的動機づけ。これらのどれが一番効くのかは人によって違うので、それぞれの人に合わせたアプローチが必要。
- 自律性: 自ら方向を決定したい
- 個人の裁量を大きくして、自由にいろいろなことができるようにする
- 熟達: 価値がある技能を上達させたい
- 自分が学びたいスキルや知識を得られるようにする
- 簡単すぎず難しすぎない仕事だと、フロー状態に入って熟達につながりやすい
- 目的: 自分以外の人、もの、社会に貢献したい
- 会社や社会に対する貢献を実感できる機会を用意する
Chrome の世界 / セキュリティ
OS のセキュリティ境界がプロセスであるのと同じように、Web ではオリジン(Origin)がセキュリティ境界として最適であると考えられてきた。この考えを Same Origin Policy / SOP という。origin はプロトコル、ホスト、ポートの組み合わせのこと。
https://www.example.com
(比較対象)http://www.example.com
(プロトコルが違うので別オリジン)https://www.example.com:8080
(ポートが違うので別オリジン)https://sub.example.com
(ホストが違うので別オリジン)
オリジンが異なると、通信ができないな どいくつかの制約がかかる。これを必要に応じて緩和する仕組みが Cross Origin Resource Sharing / CORS である。例えばサイト B のリソースをサイト A でも使っていい場合、サイト B のサーバーは以下のような HTTP ヘッダを付与する。
Access-Control-Allow-Origin: https://siteA.com
ブラウザは複数のオリジンを同一プロセスで扱うため、CORS だけではセキュリティ上の問題がまだ残っていた。このため、サイト(Site)ごとに異なるプロセスで扱うようになった。この仕組みを Site Isolation という。サイトはオリジンよりもゆるい分け方で、eTLD(TLD + ccTLD 等)とその一つ前のドメインを使って分ける。これを eTLD+1 という。
https://www.example.com
(比較対象)http://sub.example.com:8080
(プロトコルもホストもポートも違うけど、同一サイト)
ドメイン解体新書 / DNS のプライバシー
もろもろ検討されている技術はあるものの、進捗はあまりよろしくない。
- DNS over (HTTPS|TLS|QUIC)
- クライアントとキャッシュサーバ間の通信暗号化、改ざん防止、接続先認証
- ODoH
- oblivious DNS over HTTPS
- クライアントとキャッシュサーバの間にプロキシを挟むことで、クライアントの IP アドレスを隠す仕組み
- HTTPS(TLS)
- クライアントとホスティングサーバ間の通信暗号化、改ざん防止、接続先認証
- ENSI, ECH
- Server Name Indication / SNI は、ひとつの IP アドレスに複数のドメインをホストできるようにする通信の仕組み
- この情報はダダ漏れだったので、SNI を暗号化する仕組みである Encrypted SNI(ENSI)や、傍受を防ぐ Encrypted Client Hello(ECH)という仕組みが生まれた。