アーティファクトの概念¶

アーティファクトは、ワークロードが何を実行するかを記述します。具体的には、イメージURI、ポート、エントリーポイント、環境変数、ヘルスプローブを含むコンテナ仕様です。ワークロードはアーティファクトから作成されます。ロックされた1つのアーティファクトは、多くのワークロードの基盤として機能します。

アーティファクトのタイプ¶

アーティファクトは、type判別子を使用します。APIはservice（デフォルト）およびnim（NVIDIA NIMモデルアーティファクト）を受け付けます。どちらも同じマルチコンテナのcontainerGroupsの形状を使用しますが、NIMでは、生成されたAPIリファレンスにオプションのストレージとGPU向けのオートスケーリング指標が追加されます。

NIMアーティファクトには、オプションのstorageフィールド（NimStorageConfig）があり、2つの選択肢があります。dedicatedPvc（デフォルト）は、モデルの重み用にワークロード独自のPVCを提供します。一方、nimCacheは、モデルイメージをキーとするクラスター全体のPVCを使用します。複数のワークロードが同じNIMイメージを共有する場合は、クラスターが重みのキャッシュされたコピーを1つだけ保持するように、nimCacheを選択します。

NimStorageConfigのフィールド：

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

コンテナの要件¶

プラットフォームが実行するすべてのコンテナは、以下のベースライン要件を満たしている必要があります。

イメージビルド設定¶

ドラフトのserviceアーティファクトの場合、imageUriの代わりにコンテナにimageBuildConfigを設定します。これにより、アップロードされたソースコードからビルドされます（POST /artifacts/{id}/builds）。事前ビルド済みのimageUriまたはimageBuildConfigのいずれかを提供します（両方は不可）。ビルドが成功すると、プラットフォームはimageUriに値を入力します。

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

提供されたDockerfileを使用する例：

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

pathを省略すると、デフォルトの./Dockerfileが使用されます。イメージビルドRESTを参照してください。

イメージURIの検証¶

アーティファクトを作成、更新、またはクローン化する際、プラットフォームはすべてのコンテナの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を通じて同じ名前の環境変数を宣言した場合、その値が優先されます。

アーティファクトのライフサイクル¶

このセクションでは、アーティファクトに関連するdraftとlockedを定義します。ワークロード作成の判断、つまりそれぞれがどの場合に適合し、TTL（time-to-live）、重要度、置き換えルールに関して何を意味するかについては、ドラフトとロックの選択を参照してください。各ステータスは、ライフサイクルと編集可能性が異なります。

ロックは一方向です。ロックされたアーティファクトはドラフトに戻すことができません。ロックされたアーティファクトをさらに反復するには、新しいドラフトアーティファクトを作成します。次のいずれかの方法でアーティファクトをロックできます。

アーティファクトとワークロード：何がどこに存在するか¶

アーティファクトは何を実行するかを定義し、ワークロードランタイムはどのように実行するかを定義します。ランタイムはワークロードごとの環境変数のオーバーライドを受け付けません。デプロイ間で異なる必要がある値は、アーティファクトのenvironmentVarsに属します。

フィールドをどこに定義するかを決定するときは、次のガイダンスを考慮してください。

• フィールドがコンテナのアイデンティティの一部である場合（どのコードが実行されるか、どのポートでリッスンするか、どの環境変数が必要か）、それはアーティファクト仕様に属します。
• フィールドがデプロイ時のつまみ（レプリカ数、CPU割り当て、スケーリングポリシー）である場合、それはワークロードランタイムに属します。

アーティファクトリポジトリ¶

アーティファクトリポジトリは、アーティファクトのバージョンをグループ化し、以下を提供します。

artifactRepositoryIdを設定してアーティファクトを初めて作成すると、プラットフォームは自動的にリポジトリを作成します。