GitHub Actions

GitHub Actionsでモノレポを安全に自動リリースする設計: 変更検知・段階配布・失敗復旧 モノレポのCI/CDは、単一リポジトリだから楽になる一方で、リリース設計を誤ると一気に難しくなります。 1つの変更で全サービスを再デプロイしてしまう 並列ジョブが増えてキュー渋滞する どのコミットがどのサービスへ反映されたか追跡できない 一部失敗時のロールバックが曖昧 本記事では、GitHub Actionsでモノレポを運用しているチーム向けに、実務で耐えるリリース自動化の構成を具体的に説明します。 1. モノレポCI/CDで先に決める設計原則 最初に次の原則を明文化します。 変更のないサービスはデプロイしない リリース対象は機械的に決定する 本番反映は段階的（canary/割合配布） 失敗時の復旧手順を自動化する 監査ログ（誰が何をいつ）を残す この5つがないと、運用が属人化し、障害時対応が遅れます。 2. 変更検知をワークフローの入口に置く モノレポでは「どのディレクトリが変わったか」を最初に判定し、対象サービスだけを処理します。 2.1 changed-filesの例 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 jobs: detect: runs-on: ubuntu-latest outputs: matrix: ${{ steps.set-matrix.outputs.matrix }} steps: - uses: actions/checkout@v4 - id: changed uses: tj-actions/changed-files@v45 with: files_yaml: | api: - services/api/** web: - services/web/** worker: - services/worker/** - id: set-matrix run: | python .github/scripts/build_matrix.py '${{ toJson(steps.changed.outputs) }}' ここでmatrixを作り、後続ジョブを fromJson で動的展開します。 ...

GitHub Actions OIDCで実現する鍵レス本番デプロイ：漏えい事故を減らす実装プレイブック CI/CD の事故は、ビルドが失敗することより「漏えいしても気づけない鍵」が残り続けることのほうが深刻です。特に AWS_ACCESS_KEY_ID のような長期シークレットを GitHub Secrets に保存し続ける運用は、便利ですがリスクが高いです。 本記事では、GitHub Actions の OIDC（OpenID Connect）連携を使って、長期鍵を使わずに AWS へデプロイする実践手順をまとめます。単なる設定紹介ではなく、最小権限・ブランチ制限・監査ログ設計まで含めて、明日から本番投入できる形で説明します。 1. まず何が危険なのか：長期シークレット運用の限界 従来構成では、次のような問題が起きます。 Secret が漏れても検知が遅い（CIログ、誤コミット、権限の広いメンバー） ローテーションが後回しになる 1つの鍵で複数環境へアクセスできてしまう 「誰のどの workflow 実行が何をしたか」が追いにくい OIDC 連携では、GitHub が発行する短命トークンを信頼し、AWS 側で一時認証情報を払い出します。つまり、保管する鍵そのものを減らすのが最大の価値です。 2. 全体アーキテクチャ 基本フローは以下です。 GitHub Actions ジョブが OIDC トークンを取得 AWS IAM の OIDC プロバイダとロール信頼ポリシーで検証 条件に一致したジョブだけ AssumeRoleWithWebIdentity 一時クレデンシャルで S3/CloudFront/ECR/ECS へデプロイ ポイントは「GitHub 側の workflow 制御」だけでなく、AWS 側で repo・branch・workflow を強制することです。 3. AWS 側の初期設定（OIDC Provider + IAM Role） 3.1 OIDC Provider を作成 CLI 例（すでに存在する場合はスキップ）: 1 2 3 4 aws iam create-open-id-connect-provider \ --url https://token.actions.githubusercontent.com \ --client-id-list sts.amazonaws.com \ --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1 3.2 信頼ポリシーを厳密化する 以下のように sub と aud を必ず絞ります。 ...

GitHub Actions高速化実践：Matrix戦略・依存キャッシュ・失敗切り分けの設計ガイド GitHub Actions は便利ですが、プロジェクトが成長すると「遅い」「不安定」「原因が分かりにくい」という三重苦になりがちです。特に monorepo や複数ランタイム対応（Node/Python/Go など）では、ワークフローの設計次第で CI 時間が 2〜3 倍変わります。 本記事では、実行時間を短くしながら失敗時の調査コストも下げるために、matrix 設計・キャッシュ設計・障害時の確認順序を具体的に整理します。 1. まず「何を並列化するか」を決める Actions の高速化は、いきなりキャッシュ最適化から入るより、先にジョブ分解を決める方が効きます。原則は次の通りです。 並列化すべき: 独立テスト（OS/バージョン別、サービス別） 直列にすべき: デプロイ、DB マイグレーション、本番反映 依存を分ける: lint/typecheck/test/build を一つに詰め込まない 悪い例は、1ジョブに全部詰め込み、失敗時に最初から再実行するパターンです。良い設計では「lint は通るが test だけ失敗」のように切り分けできます。 2. matrix を作るときの実践ルール matrix は便利ですが、組み合わせ爆発で逆に遅くなることがあります。例えば os x runtime x db をすべて直積にすると、不要なジョブが大量発生します。そこで include/exclude を活用します。 1 2 3 4 5 6 7 8 9 10 11 12 strategy: fail-fast: false matrix: os: [ubuntu-latest, macos-latest] node: [20, 22] include: - os: ubuntu-latest node: 22 coverage: true exclude: - os: macos-latest node: 20 ポイントは次です。 ...

GitHub Actions再利用ワークフロー運用設計：属人化を防ぎつつ開発速度を上げる実践ガイド 複数リポジトリを運用していると、ほぼ同じ CI 設定を各リポジトリにコピーし続ける状態になりがちです。最初は早く見えますが、半年後には「どこに正解があるのかわからない」状態になります。セキュリティパッチを当てたいだけなのに 20 リポジトリを横断修正し、1つだけ取りこぼして監査で指摘される、というのは珍しくありません。 この問題に効くのが GitHub Actions の workflow_call を使った再利用ワークフローです。ただし、単に共通化するだけでは逆に運用事故が増えることがあります。重要なのは、共通化の粒度、権限境界、変更リリース方法を最初に設計することです。 本記事では、実運用で詰まりやすいポイントを中心に、導入から定着までを具体的に解説します。 1. 再利用ワークフローの基本方針 まず押さえるべき方針は次の 3 つです。 再利用ワークフローは「プラットフォーム製品」として扱う 呼び出し側（各アプリ repo）は薄く保つ 破壊的変更はバージョンを切って段階移行する 「共通化＝1ファイルに全部詰め込む」ではありません。lint, test, build, deploy を1個にまとめると、対象外プロジェクトまで影響します。まずは小さく分割し、必要なものだけ組み合わせられる構造にします。 2. 推奨ディレクトリ構成 共通ワークフローを専用 repo に分離しておくと、監査や変更履歴の管理が容易になります。 1 2 3 4 5 6 7 8 9 org-ci-workflows/ .github/workflows/ ci-node.yml ci-python.yml security-scan.yml release-tag.yml docs/ onboarding.md migration-checklist.md 呼び出し側は以下のように最小化します。 ...

GitHub Actionsセルフホストランナー防衛術：CI/CDの供給網リスクを減らす実装ガイド セルフホストランナーは高速で柔軟です。特定ツールチェーンや社内ネットワーク接続が必要な環境では、ほぼ必須といえます。一方で、設定を誤ると CI/CD が攻撃経路になります。 近年のインシデントでは、依存パッケージ汚染だけでなく「Actions workflow の権限過多」「fork 由来PRでの秘密情報流出」「ランナー残存データ」が問題化しています。 本記事では、セルフホストランナーを安全に運用するための防衛策を、設計レイヤごとに整理します。 脅威モデルを先に定義する まず守る対象を明確にします。 リポジトリのソースコード Secrets（クラウド鍵、署名鍵、トークン） 配布物の完全性（改ざん防止） 社内ネットワーク接続経路 攻撃経路は主に次です。 悪意ある PR が workflow を悪用 Marketplace Action の supply chain 汚染 ランナー上に残る credential / build artifact 過剰な GITHUB_TOKEN 権限 この4点を潰す設計が防御の中心になります。 1. ランナーは「使い捨て」を前提にする 長寿命ランナーは便利ですが、攻撃後の残留リスクが高いです。可能ならジョブ単位で破棄できる ephemeral 構成を採用します。 Kubernetes + Actions Runner Controller VMテンプレートから都度起動 ジョブ終了後に完全破棄 少なくとも /tmp と workspace を確実に消去し、Docker layer cache の共有範囲を制御してください。 2. workflow 権限を最小化する permissions: write-all は禁止レベルです。workflowごとに最小権限を明記します。 1 2 3 4 permissions: contents: read pull-requests: write id-token: write 特に id-token: write は OIDC 連携に必要ですが、不要ジョブで許可しないこと。権限漏れがクラウド侵害に直結します。 ...