このガイドでは、さまざまな環境でコンテナーイメージをビルドするための W&B Launch エージェントの設定方法について説明します。
ビルドが必要なのは、git ジョブと code artifact ジョブのみです。Image jobs ではビルドは不要です。ジョブのタイプの詳細については、launch job を作成するを参照してください。
Launch エージェントは、Docker または Kaniko を使用してイメージをビルドできます。
- Kaniko: ビルドを特権コンテナーとして実行せずに、Kubernetes 上でコンテナーイメージをビルドします。
- Docker: ローカルで
docker build コマンドを実行してコンテナーイメージをビルドします。
ビルダーのタイプは、Launch エージェントの設定内の builder.type キーで制御でき、docker、kaniko、またはビルドを無効化する noop を指定できます。デフォルトでは、エージェントの Helm チャートで builder.type は noop に設定されています。builder セクション内の追加キーは、ビルドプロセスの設定に使用されます。
エージェントの設定でビルダーが指定されておらず、動作する docker CLI が見つかった場合、エージェントはデフォルトで Docker を使用します。Docker を利用できない場合、エージェントはデフォルトで noop を使用します。
Kubernetes クラスターでイメージをビルドする場合は Kaniko を使用してください。それ以外の場合は Docker を使用してください。
Launch エージェントは、ビルドしたすべてのイメージに一意のソースハッシュをタグとして付与します。エージェントは、builder.destination キーで指定されたレジストリにそのイメージをプッシュします。
たとえば、builder.destination キーが my-registry.example.com/my-repository に設定されている場合、エージェントはイメージにタグを付け、my-registry.example.com/my-repository:<source-hash> にプッシュします。イメージがレジストリにすでに存在する場合、ビルドはスキップされます。
Helm チャート経由でエージェントをデプロイする場合は、values.yaml ファイルの agentConfig キーでエージェント設定を指定します。
wandb launch-agent を使って自分でエージェントを起動する場合は、--config フラグで YAML ファイルのパスを指定してエージェント設定を渡せます。デフォルトでは、設定は ~/.config/wandb/launch-config.yaml から読み込まれます。
Launch エージェント設定 (launch-config.yaml) では、environment キーと registry キーに、それぞれターゲットリソースの環境名とコンテナー レジストリを指定します。
以下のタブでは、環境とレジストリに応じた Launch エージェントの設定方法を示します。
AWS 環境の設定には region キーが必要です。region には、エージェントを実行する AWS リージョンを指定します。environment:
type: aws
region: <aws-region>
builder:
type: <kaniko|docker>
# エージェントがイメージを保存する ECR リポジトリーの URI。
# リージョンが環境で設定したものと一致していることを
# 確認してください。
destination: <account-id>.ecr.<aws-region>.amazonaws.com/<repository-name>
# Kaniko を使用する場合は、エージェントが
# ビルドコンテキストを保存する S3 バケットを指定します。
build-context-store: s3://<bucket-name>/<path>
エージェントは boto3 を使用してデフォルトの AWS 認証情報を読み込みます。デフォルトの AWS 認証情報の設定方法について詳しくは、boto3 documentation を参照してください。 Google Cloud 環境には region キーと project キーが必要です。region にはエージェントを実行するリージョンを設定します。project にはエージェントを実行する Google Cloud プロジェクトを設定します。エージェントは Python の google.auth.default() を使用してデフォルトの認証情報を読み込みます。environment:
type: gcp
region: <gcp-region>
project: <gcp-project-id>
builder:
type: <kaniko|docker>
# エージェントがイメージを保存する Artifact Registry リポジトリーと
# イメージ名の URI。リージョンとプロジェクトが
# 環境で設定したものと一致していることを確認してください。
uri: <region>-docker.pkg.dev/<project-id>/<repository-name>/<image-name>
# Kaniko を使用する場合は、エージェントが
# ビルドコンテキストを保存する GCS バケットを指定します。
build-context-store: gs://<bucket-name>/<path>
エージェントから利用できるようにデフォルトの Google Cloud 認証情報を設定する方法について詳しくは、google-auth documentation を参照してください。 Azure 環境では追加のキーは不要です。エージェントの起動時に、azure.identity.DefaultAzureCredential() を使用してデフォルトの Azure 認証情報を読み込みます。environment:
type: azure
builder:
type: <kaniko|docker>
# エージェントがイメージを保存する Azure Container Registry リポジトリーの URI。
destination: https://<registry-name>.azurecr.io/<repository-name>
# Kaniko を使用する場合は、エージェントが
# ビルドコンテキストを保存する Azure Blob Storage コンテナーを指定します。
build-context-store: https://<storage-account-name>.blob.core.windows.net/<container-name>
デフォルトの Azure 認証情報の設定方法について詳しくは、azure-identity documentation を参照してください。
必要なエージェント権限は、ユースケースによって異なります。
以下は、Launch エージェントがクラウドレジストリを操作する際に通常必要となる権限です。
{
'Version': '2012-10-17',
'Statement':
[
{
'Effect': 'Allow',
'Action':
[
'ecr:CreateRepository',
'ecr:UploadLayerPart',
'ecr:PutImage',
'ecr:CompleteLayerUpload',
'ecr:InitiateLayerUpload',
'ecr:DescribeRepositories',
'ecr:DescribeImages',
'ecr:BatchCheckLayerAvailability',
'ecr:BatchDeleteImage',
],
'Resource': 'arn:aws:ecr:<region>:<account-id>:repository/<repository>',
},
{
'Effect': 'Allow',
'Action': 'ecr:GetAuthorizationToken',
'Resource': '*',
},
],
}
artifactregistry.dockerimages.list;
artifactregistry.repositories.downloadArtifacts;
artifactregistry.repositories.list;
artifactregistry.repositories.uploadArtifacts;
Kaniko ビルダーを使用する場合は、AcrPush ロールを追加してください。
エージェントが Kaniko ビルダーを使用する場合、Launch エージェントにはクラウドストレージにプッシュする権限が必要です。Kaniko は、ビルドジョブを実行する pod の外部にあるコンテキストストアを使用します。
AWS 上の Kaniko ビルダーで推奨されるコンテキストストアは Amazon S3 です。次のポリシーを使用して、エージェントに S3 バケットへのアクセス権を付与できます。{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::<BUCKET-NAME>"]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": "s3:*Object",
"Resource": ["arn:aws:s3:::<BUCKET-NAME>/*"]
}
]
}
Google Cloud では、エージェントがビルドコンテキストを GCS にアップロードするために、次の IAM 権限が必要です。storage.buckets.get;
storage.objects.create;
storage.objects.delete;
storage.objects.get;
エージェントがビルドコンテキストを Azure Blob Storage にアップロードするには、Storage Blob Data Contributor ロールが必要です。
Kaniko ジョブで使用する Kubernetes Job spec は、agent の設定にある builder.kaniko-config キーで指定します。たとえば次のとおりです。
builder:
type: kaniko
build-context-store: <my-build-context-store>
destination: <my-image-destination>
build-job-name: wandb-image-build
kaniko-config:
spec:
template:
spec:
containers:
- args:
- "--cache=false" # 引数は "key=value" の形式で指定してください
env:
- name: "MY_ENV_VAR"
value: "my-env-var-value"
Launch エージェントを CoreWeave にデプロイする
必要に応じて、W&B Launch エージェントを CoreWeave Cloud のインフラストラクチャーにデプロイできます。CoreWeave は、GPU アクセラレーション ワークロード向けに特化して構築されたクラウド インフラストラクチャーです。
Launch エージェントを CoreWeave にデプロイする方法については、CoreWeave のドキュメントを参照してください。
CoreWeave のインフラストラクチャーに Launch エージェントをデプロイするには、CoreWeave アカウントを作成する必要があります。