> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt > Use this file to discover all available pages before exploring further. # Launch エージェントを設定する > Docker や Kaniko のビルダー、コンテナーレジストリの設定など、W&B Launch エージェントの高度なオプションを構成します。

Advanced agent setup

このガイドでは、W\&B Launch エージェントをさまざまな環境でコンテナーイメージをビルドし、それらのイメージをクラウドのコンテナーレジストリにプッシュし、ビルドプロセスをカスタマイズする方法を構成する方法について説明します。イメージビルドが必要な Launch job を実行する必要があり、エージェントがイメージを生成する場所と方法を制御したい場合に使用してください。このページは、Launch エージェントをデプロイおよび管理する管理者とオペレーター向けです。 ビルドは git とコードアーティファクトのジョブでのみ必要です。Image job ではビルドは必要ありません。 ジョブのタイプの詳細については、[Create a launch job](/ja/products/wandb/platform/launch/create-launch-job) を参照してください。

Builders

Launch エージェントは、コンテナーイメージを生成するための 2 つの builders をサポートしています。エージェントが実行される環境に合った builder を選択してください。 Launch エージェントは、[Docker](https://docs.docker.com/) または [Kaniko](https://github.com/GoogleContainerTools/kaniko) を使用してイメージをビルドできます。 * Kaniko: 特権コンテナーとしてビルドを実行せずに、Kubernetes 内でコンテナーイメージをビルドします。 * Docker: ローカルで `docker build` コマンドを実行してコンテナーイメージをビルドします。 Launch エージェント設定の `builder.type` キーで builder のタイプを制御します。`docker`、`kaniko`、またはビルドをオフにする場合は `noop` に設定してください。デフォルトでは、エージェントの Helm チャートが `builder.type` を `noop` に設定します。エージェントは `builder` セクションの追加のキーを使用してビルドプロセスを構成します。 エージェント設定で 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]` というタグを付けてプッシュします。イメージがすでにレジストリに存在する場合、エージェントはビルドをスキップします。

エージェント設定

エージェントは YAML ファイルから設定を読み込みます。このファイルの指定方法は、エージェントの実行方法によって異なります。 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 リージョンを設定します。 ```yaml title="launch-config.yaml" theme={"system"} environment: type: aws region: [AWS-REGION] builder: type: [BUILDER-TYPE] # エージェントがイメージを保存する ECR リポジトリの URI。 # リージョンが environment で設定したものと一致していることを # 確認してください。 destination: [ACCOUNT-ID].ecr.[AWS-REGION].amazonaws.com/[REPOSITORY-NAME] # Kaniko を使用する場合は、エージェントがビルドコンテキストを保存する # S3 バケットを指定します。 build-context-store: s3://[BUCKET-NAME]/[PATH] ``` エージェントは `boto3` を使用してデフォルトの AWS 認証情報を読み込みます。デフォルトの AWS 認証情報の設定方法の詳細については、[boto3 のドキュメント](https://boto3.amazonaws.com/v1/documentation/api/latest/index.html)を参照してください。 Google Cloud 環境には region キーと project キーが必要です。`region` にはエージェントを実行するリージョンを、`project` にはエージェントを実行する Google Cloud プロジェクトを設定します。エージェントは Python の `google.auth.default()` を使用してデフォルトの認証情報を読み込みます。 ```yaml title="launch-config.yaml" theme={"system"} environment: type: gcp region: [GCP-REGION] project: [GCP-PROJECT-ID] builder: type: [BUILDER-TYPE] # エージェントがイメージを保存する Artifact Registry リポジトリの URI と # イメージ名。リージョンとプロジェクトが environment で設定したものと # 一致していることを確認してください。 uri: [REGION]-docker.pkg.dev/[PROJECT-ID]/[REPOSITORY-NAME]/[IMAGE-NAME] # Kaniko を使用する場合は、エージェントがビルドコンテキストを保存する # GCS バケットを指定します。 build-context-store: gs://[BUCKET-NAME]/[PATH] ``` エージェントがデフォルトの Google Cloud 認証情報を利用できるように設定する方法の詳細については、[`google-auth` のドキュメント](https://google-auth.readthedocs.io/en/latest/reference/google.auth.html#google.auth.default)を参照してください。 Azure 環境では追加のキーは必要ありません。エージェントは起動時に `azure.identity.DefaultAzureCredential()` を使用してデフォルトの Azure 認証情報を読み込みます。 ```yaml title="launch-config.yaml" theme={"system"} environment: type: azure builder: type: [BUILDER-TYPE] # エージェントがイメージを保存する 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` のドキュメント](https://learn.microsoft.com/python/api/azure-identity/azure.identity.defaultazurecredential?view=azure-python)を参照してください。

エージェントの権限

エージェントは、コンテナーレジストリにイメージをプッシュする権限と、Kaniko を使用する場合は、クラウドストレージでビルドコンテキストを読み書きする権限が必要です。必要なエージェントの権限はユースケースによって異なります。

レジストリの権限

エージェントは、レジストリの権限が必要です。これにより、リポジトリの作成、イメージレイヤーのアップロード、タグ付きイメージのプッシュが可能になります。Launch エージェントがレジストリとやり取りするために必要な権限は以下のとおりです。 ```yaml theme={"system"} { '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': '*', }, ], } ``` ```js theme={"system"} artifactregistry.dockerimages.list; artifactregistry.repositories.downloadArtifacts; artifactregistry.repositories.list; artifactregistry.repositories.uploadArtifacts; ``` [`AcrPush` ロール](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles/containers#acrpush) を追加します (Kaniko ビルダーを使用する場合) 。

Kaniko のストレージ権限

Kaniko ビルダーを使用する場合、Launch エージェントにはクラウドストレージへのプッシュ権限が必要です。Kaniko は、ビルドジョブを実行する Pod の外部にあるコンテキストストアを使用します。 AWS では、Kaniko ビルダーのコンテキストストアとして Amazon S3 を使用します。エージェントに S3 バケットへのアクセス権を付与するには、次のポリシーを使用します。 ```json theme={"system"} { "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 権限が必要です。 ```js theme={"system"} storage.buckets.get; storage.objects.create; storage.objects.delete; storage.objects.get; ``` ビルドコンテキストを Azure Blob Storage にアップロードするには、エージェントに [Storage Blob Data Contributor](https://learn.microsoft.com/azure/role-based-access-control/built-in-roles#storage-blob-data-contributor) ロールが必要です。

Kaniko ビルドをカスタマイズする

ビルド Pod のキャッシュの動作や環境変数などのデフォルトを上書きするには、Kaniko が実行する Kubernetes Job をカスタマイズします。Kaniko ジョブが使用する Kubernetes Job の spec を、エージェント設定の `builder.kaniko-config` キーで指定します。例: ```yaml title="launch-config.yaml" theme={"system"} 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 にデプロイする

GPU アクセラレーション対応のインフラストラクチャーがワークロードに適している場合は、Launch エージェントを CoreWeave Cloud にデプロイできます。CoreWeave は、GPU アクセラレーションを活用するワークロード向けに構築されたクラウドインフラストラクチャーです。 Launch エージェントを CoreWeave にデプロイする方法については、CoreWeave のドキュメントを参照してください。 Launch エージェントを CoreWeave のインフラストラクチャーにデプロイするには、[CoreWeave アカウント](https://cloud.coreweave.com/login)の作成が必要です。 ## Related topics - [Launch を設定する](/ja/products/wandb/platform/launch/set-up-launch.md)