Cloud Service
OCI Artifacts
汎用アーティファクトを保管・バージョン管理し、IAM 制御のもとでチームに安全に配布できるマネージドなリポジトリサービス。AWS の CodeArtifact に近い。
- 1.ZIP やライブラリなど汎用アーティファクトを保管・バージョン管理するマネージドなリポジトリ。
- 2.リポジトリは OCI IAM とコンパートメントで権限を制御し、社内に閉じて安全に配布できる。
- 3.AWS の CodeArtifact に近い位置づけ。コンテナイメージは OCIR を併用する。
解決する課題
ビルドの成果物(汎用アーティファクト)は、ソースコードとは別に、確実に保管してバージョンを追える置き場が必要です。OCI Artifacts は、ZIP やライブラリ、設定ファイル、ビルド成果物などの汎用アーティファクトを保管・共有するためのマネージドなリポジトリサービスです。
- 自前でアーティファクトサーバーを構築・パッチ・スケールしたくない → フルマネージドで運用負荷を抑える
- ビルド成果物を社外に出さず社内だけで配布したい → 既定でプライベート、IAM で制御
- どのバージョンを誰がいつ使ったかを追跡したい → バージョン管理と Audit ログ
- CI/CD の各ステージ間で中間成果物を受け渡したい → リポジトリを共有の置き場にする
- 取得・公開の権限をOCI の利用者と一元管理したい → コンパートメント単位の IAM ポリシー
なお、コンテナイメージ専用のレジストリは OCI Container Registry (OCIR) が担うため、用途で使い分けます。AWS でいえば、本サービスは汎用パッケージ/成果物を扱う CodeArtifact に近く、コンテナイメージは ECR が担う、という関係に対応します。
主要概念と用語
- アーティファクト (Artifact): 保管対象となる成果物の実体。ZIP、ライブラリ、バイナリ、設定ファイルなど形式を問わない汎用ファイル
- リポジトリ (Repository): アーティファクトをまとめて保管する単位。コンパートメントに属し、IAM ポリシーでアクセスを制御する
- 不変リポジトリ / 可変リポジトリ (Immutable / Mutable): 同じパスへの上書きを許すか否かの設定。不変にすると同一アーティファクトの置き換えを禁止でき、再現性を担保しやすい
- アーティファクトパス (Artifact Path): リポジトリ内でアーティファクトを識別する論理パス。バージョンと組み合わせて一意に参照する
- バージョン (Version): 同じパスのアーティファクトの世代を表す識別子。世代を分けて保管・取得できる
- コンパートメント (Compartment): OCI のリソース整理・権限分離の単位。リポジトリの所属先となり、アクセス境界を形成する
- 汎用アーティファクトサービス: 本サービスの中核。Container Registry(コンテナイメージ用)とは扱う対象が異なる点に注意する
仕様・制限・クォータ
- 扱えるのは汎用ファイル全般で、特定のパッケージ形式に縛られない。コンテナイメージは対象外で OCIR を使う
- リポジトリはリージョンごとに存在し、コンパートメントに属して IAM 制御を受ける
- リポジトリはプライベートで、認証されたプリンシパルだけがアクセスできる
- リポジトリを不変 (immutable) に設定すると、既存アーティファクトの上書きを防げる(再現性・改ざん抑止に有効)
- テナンシ/リージョンごとに**サービス制限(リミット)**やアーティファクトサイズの上限があり、具体的な数値はリージョンやプランで変わるため、コンソールの「Limits, Quotas and Usage」で確認する
- アーティファクトの保管には保管容量に応じたストレージ課金が発生する一方、サービス機能自体の追加料金は基本的にかからない
- コンパートメントクォータを定義して利用量を制御できる
内部の仕組み
OCI Artifacts は Oracle が運用するマネージドサービスで、利用者はサーバーを意識しません。アップロードされたアーティファクトはリージョン内で冗長化して保管され、リポジトリとアーティファクトはそれぞれ OCID で一意に識別されます。
アクセス制御は OCI IAM に統合されています。リポジトリはコンパートメントに属し、そのコンパートメントに対する IAM ポリシーで read(取得)や use / manage(アップロード・管理)といった操作可否が判定されます。サービス独自のアクセス制御を別管理する必要はありません。
CI/CD パイプラインや CLI / SDK は、リクエストごとに署名する標準の OCI 認証を用いてアップロード・ダウンロードします。コンピュート上のワークロードからは、動的グループ + インスタンスプリンシパルを使えば長命な資格情報を埋め込まずにアクセスできます。OCI Events や DevOps と組み合わせれば、アーティファクトのアップロードを起点に後続処理を自動化することも可能です。
コンテナイメージは OCI Container Registry (OCIR)、それ以外の汎用成果物(ZIP・ライブラリ・バイナリ・設定ファイルなど)は OCI Artifacts、と覚えると整理しやすいです。両者は同じ「Artifacts」系のサービス群に属しますが、扱う対象とエンドポイントが異なります。
設計パターン / ベストプラクティス
- CI/CD でビルド成果物を集約: ビルド成功時に成果物を Artifacts へアップロードし、後続のデプロイステージはそこから取得する
- 不変リポジトリで再現性を確保: リリース用リポジトリは不変に設定し、同一バージョンの上書きを禁止して「いつのビルドか」を確定させる
- バージョン参照を徹底:
latest的な可変参照に依存せず、明示的なバージョンで取得して再現性を担保する - 環境ごとにリポジトリ/コンパートメントを分離し、本番へのアップロード権限を IAM で強く絞る
- 取得はインスタンスプリンシパルを使い、長命な資格情報の配布を避ける
- 古い・不要なバージョンは運用ルールで整理し、ストレージコストの肥大化を防ぐ
運用・監視
- OCI Audit にアップロード・ダウンロード・リポジトリ作成などの API 操作が記録され、誰がいつ何をしたかを追跡できる
- リポジトリやアーティファクトの一覧・状態はコンソールの「Artifacts」から確認できる
- 取得に失敗する → IAM ポリシー / 動的グループの取得権限、対象コンパートメントとリージョンの一致、アーティファクトパスとバージョンの指定を確認する
- アップロードに失敗する → 対象コンパートメントへの manage 権限、リポジトリが不変で同一パスを上書きしようとしていないか、アーティファクトサイズが上限内かを確認する
- OCI Events と連携し、アップロードを契機に通知や後続パイプラインを起動して運用を自動化する
コスト
OCI Artifacts はサービス機能自体に大きな追加料金はなく、課金は主に保管しているアーティファクトのストレージ容量に対して発生します。具体的な単価は変動するため公式の料金ページで確認してください。
- コストの主因は蓄積されたアーティファクトのストレージ量。古い・未使用バージョンの整理が効く
- 不要バージョンの削除と保管ルールの徹底で容量を抑制する
- リージョンを利用側と合わせ、クロスリージョンの大量転送を避ける
セキュリティ
- リポジトリはプライベートで、認証されたプリンシパルだけがアクセスできる
- 認可は IAM ポリシーで行い、read(取得)・use / manage(アップロード・管理)を最小権限で付与する
- ワークロードからの取得はインスタンスプリンシパル + 動的グループを使い、資格情報の埋め込みを避ける
- 不変リポジトリを使うと、リリース済みアーティファクトの上書き・改ざんを防ぎ、サプライチェーンの完全性を高められる
- 操作は Audit で記録されるため、配布元・取得者のトレーサビリティを確保できる
長命な資格情報を CI 設定やスクリプトにベタ書きしてアップロードに使い回したり、リリース用リポジトリを可変のまま同一バージョンを繰り返し上書きするのは危険です。ワークロードからのアクセスはインスタンスプリンシパルに寄せ、リリース成果物は不変リポジトリに置いて再現性と改ざん耐性を確保しましょう。
Well-Architected の観点
- セキュリティ: プライベート前提・IAM 連携・不変リポジトリ・Audit により、保管と配布の両面で安全性と完全性を確保。最小権限ポリシーとインスタンスプリンシパルで資格情報の露出を抑える
- 運用上の優秀性: フルマネージドでサーバー運用が不要。CI/CD と統合し、バージョン管理と Audit で成果物のトレーサビリティと再現性を高められる
試験で問われるポイント
- OCI Artifacts は汎用アーティファクトを保管・共有するマネージドリポジトリで、対応する AWS サービスは CodeArtifact に近い
- コンテナイメージは対象外で、その用途は OCI Container Registry (OCIR) が担う(すみ分けが問われやすい)
- リポジトリはコンパートメントに属し、アクセス制御はコンパートメント単位の IAM ポリシーで行う
- リポジトリを不変 (immutable) に設定すると、既存アーティファクトの上書きを禁止できる
- ワークロードからの取得はインスタンスプリンシパル + 動的グループで資格情報を持たずに実現できる
- 課金は主に保管ストレージ容量に対して発生する
関連サービス・比較
| 観点 | OCI Artifacts | OCI Container Registry (OCIR) |
|---|---|---|
| 扱う対象 | ZIP・ライブラリなど汎用アーティファクト | コンテナイメージ(Docker / OCI 形式) |
| 位置づけ | 汎用アーティファクトリポジトリ | プライベートコンテナレジストリ |
| 相当する AWS | CodeArtifact に近い | Amazon ECR |
| 既定の公開範囲 | プライベート | プライベート(パブリックにも変更可) |
| 認可 | コンパートメント単位の IAM ポリシー | コンパートメント単位の IAM ポリシー |
| 再現性の仕組み | 不変リポジトリ・バージョン管理 | 不変タグ・イメージダイジェスト |
| 主な連携先 | DevOps / CI/CD / Events | OKE / Container Instances / Functions |
ハンズオン / CLI例
# 1) 汎用アーティファクトのリポジトリを作成(プライベート・不変)
oci artifacts repository create \
--compartment-id "ocid1.compartment.oc1..xxxx" \
--repository-type "GENERIC" \
--display-name "release-artifacts" \
--is-immutable true
# 2) リポジトリ一覧を確認
oci artifacts repository list \
--compartment-id "ocid1.compartment.oc1..xxxx" \
--query "data.items[].{Name:\"display-name\", Id:id, Immutable:\"is-immutable\"}" \
--output table
# 3) ビルド成果物をアップロード(パスとバージョンを指定)
oci artifacts generic artifact upload-by-path \
--repository-id "ocid1.artifactrepository.oc1..xxxx" \
--artifact-path "app/web-app.zip" \
--artifact-version "1.0.0" \
--content-body "./dist/web-app.zip"
# 4) リポジトリ内のアーティファクトを一覧
oci artifacts generic artifact list \
--compartment-id "ocid1.compartment.oc1..xxxx" \
--repository-id "ocid1.artifactrepository.oc1..xxxx" \
--output table
# 5) 指定バージョンのアーティファクトをダウンロード
oci artifacts generic artifact download-by-path \
--repository-id "ocid1.artifactrepository.oc1..xxxx" \
--artifact-path "app/web-app.zip" \
--artifact-version "1.0.0" \
--file "./web-app.zip"
OCI Service
OCI Artifactsを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
開発者ツール
比較で見る軸
クラウド: OCI / カテゴリ: 開発者ツール / 難易度: basic
導入後に効く点
リポジトリは OCI IAM とコンパートメントで権限を制御し、社内に閉じて安全に配布できる。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- OCI
- カテゴリ
- 開発者ツール
- 難易度
- basic
- 関連資格
- —
- 設計柱
- security / operational
判断チェックリスト
- 自社の用途が「開発者ツール / security」に近いか確認する。
- 強みである「ZIP やライブラリなど汎用アーティファクトを保管・バージョン管理するマネージドなリポジトリ。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。