OCI DevOps

解決する課題

ソースコードをコミットしてから本番に届くまでには、ビルド・テスト・成果物の保管・各環境へのデプロイといった手順が連なります。これを人手で回すと遅く、属人化し、ミスも増えます。OCI DevOps はこの一連を自動化するマネージドな CI/CD サービスです。

• ビルドサーバーを自前で構築・パッチ・スケールしたくない → マネージドなビルド基盤で運用負荷を下げる
• コミットを起点にビルドからデプロイまで自動で流したい → トリガーとパイプラインで連結する
• 同じ成果物を複数環境（開発・本番など）へ一貫した手順でデプロイしたい → デプロイパイプラインと環境定義で再現性を確保
• OKE / Functions / コンピュートインスタンスへのデプロイ方式（ローリング、ブルー・グリーン、カナリア）を仕組みとして持ちたい
• 資格情報やデプロイ権限をOCI の利用者・ロールと一元管理したい → IAM ポリシーで制御

主要概念と用語

• プロジェクト (DevOps Project): パイプラインや成果物などの DevOps リソースをまとめる最上位の入れ物。Notifications のトピックを紐付けて通知を受け取る
• コードリポジトリ (Code Repository): OCI 内でホストされる Git リポジトリ。外部（GitHub / GitLab / Bitbucket など）をミラー／接続先として使うこともできる
• ビルドパイプライン (Build Pipeline): ソース取得・コンパイル・テスト・成果物の生成を順序付けて実行する流れ。ステージを直列・並列に組める
• ビルド仕様 (Build Spec): リポジトリ内の YAML ファイル。各ビルドステップで実行するコマンドや生成物を宣言する。AWS CodeBuild の buildspec に相当
• デプロイパイプライン (Deployment Pipeline): ビルド成果物を環境へ反映する流れ。承認ステージや複数環境への段階適用を組める
• 成果物 (Artifact): デプロイ対象の実体。コンテナイメージ、Kubernetes マニフェスト、Functions のイメージ、汎用ファイルなどを参照定義する
• 環境 (Environment): デプロイ先の宣言。OKE クラスタ、Functions アプリ、コンピュートインスタンスグループなどを表す
• トリガー (Trigger): コードのプッシュやプルリクエストなどのイベントでパイプラインを自動起動する設定
• コネクション (External Connection): GitHub などの外部リポジトリと連携するための認証情報（パーソナルアクセストークンなどを Vault のシークレットで保持）

仕様・制限・クォータ

• ビルドはマネージドなビルドランナー上で実行され、利用者はビルドサーバーを管理しない。ビルド仕様の YAML で手順を定義する
• 1 回のビルドには最大実行時間の上限があり、超える処理はステージ分割や別基盤の利用を検討する
• デプロイ方式としてローリングとブルー・グリーン（対応するデプロイ先で）を選べ、OKE 向けにはカナリア的な段階適用も構成できる
• 成果物は OCI の**Artifact Registry（汎用成果物）**や Container Registry（OCIR、コンテナイメージ） と連携して参照する
• 各リソース（プロジェクト数、パイプライン数、同時ビルド数など）にはテナンシ／リージョン単位の**サービス制限（リミット）**があり、コンソールから引き上げ申請が可能。具体的な上限値は変動するため「Limits, Quotas and Usage」で確認する
• DevOps リソースはリージョンに属し、各リソースはコンパートメントに置かれて IAM 制御を受ける

内部の仕組み

OCI DevOps は Oracle が運用するマネージドサービスで、ビルドはマネージドなランナー上で隔離実行されます。流れの中心は 2 種類のパイプラインです。

• ビルドパイプラインは、コードリポジトリ（OCI 内または外部）からソースを取得し、リポジトリ内の**ビルド仕様（YAML）**に従ってコマンドを実行します。生成したコンテナイメージは OCIR へ、汎用成果物は Artifact Registry へ送り出すよう構成できます。
• デプロイパイプラインは、それらの成果物を環境（OKE / Functions / インスタンスグループ）へ反映します。ステージとして、デプロイ・承認待ち・別パイプライン呼び出しなどを並べられます。

パイプライン間の連結にはトリガーを使います。Git のプッシュやプルリクエストでビルドを起動し、ビルド成功時にデプロイパイプラインへ自動で受け渡す、という連鎖を組めます。各サービスへの認証は IAM（および動的グループ）で行い、外部リポジトリの資格情報は Vault のシークレットとして安全に保持します。実行ログや状態はサービス側で管理され、Logging や Notifications と連携して可視化・通知されます。

設計パターン / ベストプラクティス

• ビルド仕様をリポジトリに同梱し、ビルド手順をコード（YAML）として版管理する
• 成果物はダイジェスト／不変タグで参照し、ビルドした実体を環境間で使い回して再現性を確保する（環境ごとに再ビルドしない）
• デプロイパイプラインに承認ステージを挟み、本番反映の前に人手のゲートを置く
• 段階デプロイ（ブルー・グリーン／カナリア）でリスクを抑え、問題時に素早く切り戻せるようにする
• 環境ごとにコンパートメント／ポリシーを分離し、本番へのデプロイ権限を絞る
• 外部リポジトリ連携の資格情報はVault のシークレットで管理し、設定への直書きを避ける
• 通知はNotifications のトピックへ集約し、失敗・承認待ちをチームへ届ける

運用・監視

• ビルド・デプロイの実行状況、ステージごとの成否、ログはコンソールの「DevOps」から確認できる
• パイプラインの開始・完了・失敗などのイベントは Notifications で配信し、Slack やメールに通知できる
• ビルド／デプロイ中のログは OCI Logging に出力して集約・検索する
• API 操作（パイプライン作成・実行など）は OCI Audit に記録され、変更とトレーサビリティを追える
• デプロイが失敗する → 環境（OKE / Functions）への IAM ポリシー／動的グループの権限、成果物の参照先（OCIR のイメージパス・リージョン）を確認
• ビルドが失敗する → ビルド仕様の YAML の構文・コマンド、外部リポジトリのコネクション資格情報、依存取得のネットワーク経路を確認

コスト

OCI DevOps のコストは主にビルドの実行時間（マネージドランナーの稼働分）と、成果物を保管するArtifact Registry / OCIR のストレージ容量に対して発生します。パイプライン定義そのものや少量の利用は無料枠で収まることもあります。具体的な単価は変動するため、料金は公式の料金ページで確認してください。

• コストの主因はビルド頻度と所要時間。キャッシュ活用や不要ステップ削減で短縮する
• 古い成果物・未使用イメージを整理し、ストレージの肥大化を防ぐ
• デプロイ先と同一リージョンに成果物を置き、クロスリージョン転送を避ける

セキュリティ

• パイプラインからの各サービス操作は IAM ポリシー＋動的グループで最小権限に絞る（DevOps リソース自体をプリンシパルとして扱う）
• 外部リポジトリやレジストリの資格情報は Vault のシークレットで管理し、設定やコードに直書きしない
• 環境ごとにコンパートメントを分離し、本番デプロイ権限を限定する
• デプロイするコンテナイメージはスキャン・署名（OCIR / Vulnerability Scanning と連携）して、サプライチェーンの健全性を担保する
• すべての操作を Audit で記録し、誰がいつ何をデプロイしたかを追跡可能にする

Well-Architected の観点

• 運用上の優秀性: ビルド・デプロイをコード（ビルド仕様 YAML とパイプライン定義）として管理し、フルマネージドな基盤で運用負荷を下げる。トリガーで自動化し、Notifications と Audit で可視化・追跡することで、デプロイの再現性とトレーサビリティを高められる
• 信頼性（補助的に）: ブルー・グリーン／カナリアなどの段階デプロイと承認ステージにより、変更の影響を抑えつつ素早い切り戻しを可能にする

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) DevOps プロジェクトを作成（通知用トピックを紐付け）
oci devops project create \
  --compartment-id "ocid1.compartment.oc1..xxxx" \
  --name "demo-cicd" \
  --notification-config '{"topicId":"ocid1.onstopic.oc1..xxxx"}'

# 2) プロジェクト配下にビルドパイプラインを作成
oci devops build-pipeline create \
  --project-id "ocid1.devopsproject.oc1..xxxx" \
  --display-name "build-web-app"

# 3) デプロイ先となる環境（OKE クラスタ）を登録
oci devops deploy-environment create-oke-cluster-environment \
  --project-id "ocid1.devopsproject.oc1..xxxx" \
  --display-name "prod-oke" \
  --cluster-id "ocid1.cluster.oc1..xxxx"

# 4) ビルドパイプラインを手動で実行（通常はトリガーで自動起動）
oci devops build-run create \
  --build-pipeline-id "ocid1.devopsbuildpipeline.oc1..xxxx"

# 5) デプロイパイプラインを実行
oci devops deployment create-pipeline-redeployment \
  --deploy-pipeline-id "ocid1.devopsdeploypipeline.oc1..xxxx"

# 6) プロジェクト内のパイプライン一覧を確認
oci devops build-pipeline list \
  --project-id "ocid1.devopsproject.oc1..xxxx" \
  --output table