CI/CD
Why CI/CD?
- 手順実行の確実化
- 効率化
- 毎回人力で行うのは手間がかかる。特にビルドを挟むものや手順が多いものは威力大
- 自動化で効率よく
- 明確化
- 人力だと見えない手順が隠れていて暗黙知になることも
- 明文化で作業の透明性確保
- 誰が実行したかもしっかり記録（トレーサビリティ）
セキュリティ重視
- 乗っ取られると被害が大きい。対策はしっかりと
- 基本は最小権限の原則とアカウント管理
- 最小権限の原則
- 完璧主義でなくてもいい、ただしリスクを許容できる域まで落とす
- 管理者権限は以ての外
- アカウント管理
- CI/CDを編集できるアカウントはMFA必須
- 業務利用のCI/CDにID・Passwordだけでログインしているアカウントは関与させない
- APIキーもできる限り使わない
- GitHub Actionsはやや特殊。コード管理と権限管理を同時に行う
信頼性
- pre-buildコンテナの活用
- 高速化というメリットもあるが、外部リポジトリに依存しなくて済む点もメリット
- バージョンは極力指定する
- latest運用は思わぬ仕様変更で挙動が変わる恐れがある
- 脆弱性の問題もあるので定期的な更新は必要
- 手間はかかる
- 重要なものだけ。完璧主義は報われない
なにで組むか？
- 利便性重視でいいならGitHub Actions、セキュリティ優先ならAWS CodePipeline
- 便利なのはGitHub Actions
- GitHubとの連携が楽
- 開発者体験もいい
- コスパも悪くない
- 信頼できるメンバーで集まって小規模開発をするならこれでいい
- 一方セキュリティの穴を作らないように組むのはかなり気を遣う
- GitHubと一体な分、守るべき場所が多い
- アカウント管理もAWS IAM Identity Centerと比べると緩い
- ビジネスの根幹となってるインフラのIaCを任せるべきかは考えどころ
- IaCでCI/CDをやるなら強い権限を渡さざるを得ない
- 強すぎる権限を渡すと設定の穴を突かれた際に被害が大きい
- それなのに穴があきやすい
- 「設定を完璧にやれば問題ない」はその通りだが、何年も運用する間ずっと完璧でいられるかが問題
- セキュリティ優先ならAWS CodePipeline
- AWS・IaC・CI/CDで重要システムを構築するならこれが手堅い
- フロントエンドやバックエンド（データ操作系以外）はGHA、インフラやマイグレーション等はこちらという使い分けもあり
- アカウント管理は堅牢そのもの
- 「SCP(サービスコントロールポリシー)を使った権限制限」「MFA必須」様々な工夫がある
- 権限管理もGitHub Actionsよりさらに細かく設定可能
- ただし設定が手間
- AIのおかげでマシになったが、それでも設定には苦労する
- セキュリティに強いのと裏表だが権限設定はとても細かいので大変
- UXももっさり感ある
- 大昔と比べると遥かに良くなってはいるがGitHub Actionsほど手軽かと言われると辛い
- もっともGHAはその分セキュリティ面で泣き所がある
高速化
- ジョブの並列実行
- CPU数を確保できるインスタンスを利用しつつ、ジョブの中でも並列実行
- キャッシュも実行
- pre-buildコンテナの活用
- 必要なツールを先に入れておく
- 安定する、早い
- ただし管理が手間
- それでも重いビルドやテストはGitHub ActionsのSelf Hosted Runnerも手
CI/CDをあえて避けるケースも
- つまりはオーバーエンジニアリングを避ける
- 実験環境で作業効率優先の場合
- Try&Errorが多い場合はCI/CDを挟むと辛い
- GHAがコンテナを立ち上げている暇に、ローカルでちょろっとなおしたスクリプトをすぐsync
Show Text to ShareCI/CDポリシー
CI/CD
https://www.tricrow.com/policies/cicid.html
この記事を書いた人
T.Nakamura
SRE | セキュリティ前提の設計・運用・監査対応(PCI DSS) | ドキュメント整備と仕組み化で開発・運用を整えます | AWS SAP / 日商簿記一級
フォローはこちら