Artifact concepts¶

An artifact describes what a Workload runs: a container specification with image URI, port, entrypoint, environment variables, and health probes. Workloads are created from artifacts; one locked artifact can serve as the foundation for many Workloads.

Artifact types¶

Artifacts use a type discriminator. The API accepts service (default) and nim (NVIDIA NIM model artifacts). Both use the same multi-container containerGroups shape; NIM adds optional storage and GPU-oriented autoscaling metrics in the generated API reference.

NIM artifacts include an optional storage field (NimStorageConfig) with two choices: dedicatedPvc (default) gives the Workload its own PVC for model weights. Alternatively, nimCache uses a cluster-wide PVC keyed on the model image—pick nimCache when multiple Workloads share the same NIM image so that the cluster keeps a single cached copy of the weights.

NimStorageConfigのフィールド

NIMアーティファクトでは、事前に行われたモデル設定でのNIMテンプレートを参照するためのオプションのtemplateIdフィールド（文字列）も受け付けます。

Container requirements¶

Every container the platform runs must satisfy the following baseline requirements:

Image build configuration¶

For draft service artifacts, set imageBuildConfig on a container instead of imageUri. This then builds from uploaded source code (POST /artifacts/{id}/builds). Provide either a pre-built imageUri or imageBuildConfig (not both). After a successful build, the platform populates imageUri.

ImageBuildConfig.dockerfileは判別可能ユニオン（discriminated union）です。sourceフィールドはタグであり、その値によって以下のどのフィールドが適用されるかが決まります。デフォルトはprovidedで、ソースディレクトリ内の./Dockerfileが使用されます。

Example using a provided Dockerfile:

"imageBuildConfig": {
  "dockerfile": {
    "source": "provided",
    "path": "./Dockerfile"
  }
} 

Omit path to use the default ./Dockerfile. See Image builds REST.

Image URI validation¶

アーティファクトを作成、更新、またはクローン化する際、プラットフォームはすべてのコンテナのimageUriを、クラスターで設定された許可リストおよび拒否リストと照合して検証します。 デフォルトでは、広く知られているパブリックレジストリ（例：Docker Hub、Quay.io、GHCR、パブリックECR（public.ecr.aws）、GitLab Container Registry、JFrog、NVIDIA NGC）は許可されていますが、内部レジストリおよびクラウドプロバイダーのプライベートレジストリ（プライベート ECR、ACR、GCR、GCP Artifact Registry）は許可されていません。 クラスター管理者はこのポリシーをカスタマイズできるため、許可されるレジストリの具体的なセットはインストール環境によって異なる場合があります。

imageUriを直接指定しているコンテナのみがチェックの対象となります。imageBuildConfig（コードからワークロードへの構築フロー）を通じて構築されたコンテナは、この時点ではimageUriを持っていないため、チェックの対象外となります。

許可されていないimageUriの場合、アーティファクトの作成、更新、またはクローン化は失敗し、以下のいずれかのエラーが発生します。

いずれのエラーも解決するには、クラスターが許可するレジストリにイメージをプッシュし、imageUriでそれを参照してください。

環境変数のタイプ¶

コンテナ環境変数（environmentVars）は、sourceフィールドの判別可能ユニオン（discriminated union）です。 APIでは3つのタイプを受け付けます。

3つのタイプすべてを使用した例

"environmentVars": [
  {"name": "APP_MODE", "value": "production"},
  {"source": "dr-credential", "name": "DB_PASSWORD", "drCredentialId": "64abc...", "key": "password"},
  {"source": "api-key"}
] 

api-keyエントリーにはnameがありません。プラットフォームがこれを、DataRobot SDKが期待する標準的な名前であるDATAROBOT_API_TOKENに解決します。 トークンを別の名前でマウントするには、nameを明示的に設定してください：{"source": "api-key", "name": "MY_DR_TOKEN"}。

これらのワークロードごとのキーは、コンソールのアカウント設定 > APIのキーとツール > Workload APIキーで確認でき、そこで名前を変更したり削除したりすることができます。詳しくは、APIキーの管理を参照してください。

プラットフォームが管理する環境変数¶

アーティファクト仕様で宣言されたenvironmentVarsに加え、プラットフォームは実行時にすべてのコンテナに一連の環境変数を注入します。 これらは仕様には反映されず、GET /artifacts/{id}やGET /workloads/{id}によっても返されず、削除することもできません。 environmentVarsを通じて同じ名前の環境変数を宣言した場合、その値が優先されます。

Artifact lifecycle¶

This section defines draft and locked as they relate to artifacts. For the Workload-creation decision—when each fits and what each implies for TTL (time-to-live), importance, and replace rules—see Choose draft vs. locked. Each status differs in lifecycle and editability.

Locking is one-way: locked artifacts cannot return to draft. To iterate further on a locked artifact, create a new draft artifact. You can lock an artifact using either of the following methods:

Artifact vs. Workload: what lives where¶

The artifact defines what runs; the Workload runtime defines how it runs. The runtime does not accept per-Workload environment variable overrides—values that need to vary across deployments belong in the artifact's environmentVars.

Consider the following guidance when deciding where to define a field:

• If a field is part of the container's identity (which code runs, what ports it listens on, which env vars it needs), it belongs in the artifact spec.
• If a field is a deployment-time knob (replica count, CPU allocation, scaling policy), it belongs in the Workload runtime.

Artifact repositories¶

Artifact repositories group artifact versions and provide:

The platform creates a repository automatically the first time you create an artifact with artifactRepositoryId set.