CI/CD

2 件の記事

CI/CD

Why CI/CD?

  • 手順実行の確実化
    • 手作業は漏れやすい、間違いやすい
    • 自動化で確実に
  • 効率化
    • 毎回人力で行うのは手間がかかる。特にビルドを挟むものや手順が多いものは威力大
    • 自動化で効率よく
  • 明確化
    • 人力だと見えない手順が隠れていて暗黙知になることも
    • 明文化で作業の透明性確保
    • 誰が実行したかもしっかり記録(トレーサビリティ)

セキュリティ重視

  • 乗っ取られると被害が大きい。対策はしっかりと
  • 基本は最小権限の原則とアカウント管理
  • 最小権限の原則
    • 完璧主義でなくてもいい、ただしリスクを許容できる域まで落とす
    • 管理者権限は以ての外
  • アカウント管理
    • CI/CDを編集できるアカウントはMFA必須
      • 業務利用のCI/CDにID・Passwordだけでログインしているアカウントは関与させない
    • APIキーもできる限り使わない
      • 短時間トークンやOIDCで回す
  • GitHub Actionsはやや特殊。コード管理と権限管理を同時に行う
    • でないとセキュリティの穴が開きやすい

信頼性

  • pre-buildコンテナの活用
    • 高速化というメリットもあるが、外部リポジトリに依存しなくて済む点もメリット
  • バージョンは極力指定する
    • latest運用は思わぬ仕様変更で挙動が変わる恐れがある
    • 脆弱性の問題もあるので定期的な更新は必要
    • 手間はかかる
    • 重要なものだけ。完璧主義は報われない

なにで組むか?

  • 利便性重視でいいならGitHub Actions、セキュリティ優先ならAWS CodePipeline
  • 便利なのはGitHub Actions
    • GitHubとの連携が楽
      • コードも読めるPRもIssueも作れる
    • 開発者体験もいい
    • コスパも悪くない
    • 信頼できるメンバーで集まって小規模開発をするならこれでいい
      • シュッと作ってすぐCI/CDを実現できるのは強み
    • 一方セキュリティの穴を作らないように組むのはかなり気を遣う
      • 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を使うほどでなければ特に効く
  • pre-buildコンテナの活用
    • 必要なツールを先に入れておく
    • 安定する、早い
    • ただし管理が手間
  • それでも重いビルドやテストはGitHub ActionsのSelf Hosted Runnerも手
    • ハイスペックなマシンを使いやすい
    • 費用もお手頃

CI/CDをあえて避けるケースも

  • つまりはオーバーエンジニアリングを避ける
  • 実験環境で作業効率優先の場合
    • Try&Errorが多い場合はCI/CDを挟むと辛い
      • GHAがコンテナを立ち上げている暇に、ローカルでちょろっとなおしたスクリプトをすぐsync

概要と背景

かつて先進的な取り組みであったIaCやCI/CDも昨今はさほど珍しいものではなくなりました。その有益性が実感されていればこそでしょう。DORAのサイトにおいても、“Infrastructure-as-code allows you to manage changes effectively, and to apply information security controls. “と述べられるように、効果的かつセキュアな運用にIaCやCI/CDは大きく貢献します。

しかし具体的にどのようなメリットがあるのかを改めて説明しようとすると意外と難しいものです。そこでこの機にまとめなおしてみました。

og

DevOpsにつきもののCI/CD、そのメリットとは?

なぜIaCとCI/CDを用いるのか。得るべきそのメリットとは。

IaCとCI/CDのメリットをそれぞれ整理したのが以下の表です。

IaC(Infrastructure as Code)のメリット

区分具体的な利点説明
再現性同じコードから何度でも同一環境を構築可能設定漏れや設定ミスの発生を抑止し、環境差異の極めて少ない環境構築が可能になります。
可読性・共有性インフラを設定で可視化できる必然的に設定が明文化されるため、知識が属人化しにくくなります。
バージョン管理Gitでバージョン管理できるインフラをGitで管理できます。変更を追いかけるロールバックも容易です。
モジュール化による再利用共通コードで省力化何度も利用する設定をモジュール化して使いまわせば効率よく構築できます。設定ミスがおきづらいことから信頼性も高いです。
ツールの利用静的解析でチェックできるcheckovなどでコードレベルでインフラの構成をチェックできます。

実はIaC(インフラのコード化)単体ではメリットを出しづらく、多くはほかの施策や技術と組み合わせることで効果を発揮します。

例えば、再現性や可読性、モジュール化による再利用はそれを可能にするコードを書いてこそ機能します。バージョン管理はGitを導入・運用していなければなりません。静的解析のツールも同様です。

IaCの導入とは、ただTerraform(あるいはCDKやCloudFormation等)を用いるだけではなく、その他のツールや技術も合わせた総合的な施策なのだと言えます。

CI/CDのメリット

区分具体的な利点説明
自動化による信頼性向上plan -> (approve) -> apply を自動で実行できる作業ミスやメンバーごとの手順の違いなどを抑止します。運用の信頼性を向上させます。
テスト・チェックの確実な実行静的解析やterraform planなどを自動実行できるチェック忘れがなくなります。手動で行っているとフォーマッタやテストツールの実行を忘れるのも日常茶飯事です。
ガバナンス強化レビューと承認フローを必須にできるterraform planの結果とApprove機能のことです。Githubの機能と組み合わせるとさらに強力です。雑な仕事、悪意ある(!)作業を抑止できます
証跡保存コード変更・CI 実行ログが残るログがチーム共用の場に残るため追跡が容易になります。
アクセス権の保護権限をクラウド上で集中管理できる普段はCI/CDで更新するようにしておけばメンバーが普段から強すぎる権限を持たずに済みます。ただしブレイクグラスや、そこまでシビアでないならAssumeRoleなど、臨時作業の手段も用意しておく必要があります。

CI/CDの売りはなんといっても信頼性の向上です。昔から業界には作業漏れや作業ミスの笑い話(?)が絶えません。しかし自動化した部分については――自動化でミスしていれば別ですが――そのような問題を抑止することができます。逐一手順書をかかずに済むなど、本番作業の省力化に繋がることもあるでしょう。またミスのリカバリ作業が減ることからコストメリットも副次的に生じるかもしれません。