CI/CD

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 を必ず絞ります。 ...

Terraformドリフト検知プレイブック：本番事故を防ぐCI設計と運用手順 Terraform を導入していても、運用が進むほど「実環境がいつの間にかコードとズレる」問題にぶつかります。いわゆるドリフトです。最初は小さな差分でも、放置すると本番変更時に予期せぬ差分が混ざり、障害やリリース遅延の原因になります。 本記事では、Terraform ドリフト検知を単なる terraform plan 実行で終わらせず、継続運用できる仕組みとして実装するための具体策をまとめます。対象は AWS を例にしますが、考え方は他クラウドでも共通です。 1. ドリフト検知で最初に決めるべきこと 多くのチームが失敗するのは、実装前に運用設計を決めないことです。まず以下を決めます。 どの環境をいつ検知するか（prod は毎日、stg は平日など） 検知結果をどこに通知するか（Slack/Discord/Issue） 誰がいつまでに対応するか（当番制、SLA） 「意図した手動変更」をどう扱うか（例外ラベル、期限付き） ここを決めずに CI だけ作ると、通知がノイズ化して無視されます。ドリフト検知は技術課題より運用課題です。 2. リポジトリ構成と state 分離 最小限、次のような構成を推奨します。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 infra/ modules/ vpc/ ecs/ rds/ envs/ prod/ main.tf backend.hcl variables.tf stg/ main.tf backend.hcl .github/ workflows/ terraform-drift.yml 環境ごとに backend と state を分けることが重要です。ドリフト検知ジョブが state を誤って参照すると、存在しない差分が出ます。S3 backend + DynamoDB lock を使う場合は、bucket/key/region/table の整合性を必ず固定化します。 ...

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 連携に必要ですが、不要ジョブで許可しないこと。権限漏れがクラウド侵害に直結します。 ...