標準コンピュート用のDatabricks Container Services

備考

ベータ版

標準コンピュート用のDatabricks Container Servicesベータ版です。ワークスペース管理者は、ワークスペースの プレビュー ページからこの機能を有効にする必要があります。これは、一般提供されている専用コンピュート用のDatabricks Container Servicesとは別のサービスです。

標準コンピュート用のDatabricks Container Servicesを使用すると、標準コンピュートを作成するときにDockerイメージを指定でき、共有コンピュート環境のカスタムコンテナーにアクセスできるようになります。 Dockerイメージはワークロード環境の唯一の定義であるため、リモート環境をローカルに再現して、開発と本番運用全体で一貫した結果を得ることができます。

さらに、カスタムイメージの構築を支援するために、 Databricks 、ニーズに合わせて拡張できる、レス環境バージョンに準拠したベースイメージを提供しています。

要件

標準コンピュートにDatabricks Container Services使用するには:

コンピュートリソースは、Databricks Runtime 18 Beta以上を実行し、**標準**アクセスモードを使用する必要があります。
PATHには、 dockerコマンドが使用可能な最新の Docker デーモンが必要です。

ステップ 1: 標準コンピュート用にDatabricks Container Servicesを有効にする

標準のコンピュートにDatabricks Container Services使用するには、ワークスペース管理者が プレビュー ページから機能を有効にする必要があります。

Databricksワークスペースに管理者としてサインインします。
右上にあるユーザーメニューから 「プレビュー」 をクリックします。
標準コンピュート用の DCS を 見つけてオンにします。

ステップ 2: カスタムイメージを構築する

これらの手順では、Databricksが提供するベースイメージを拡張してカスタムイメージを作成する方法を説明します（推奨）。ベースイメージには、Ubuntu、Python、JDKなど、ワークロードを起動するために必要な依存関係が含まれています。databricksruntime/environment:v5-standardをプルして、その上に独自のパッケージを重ねることで、Databricks が管理する継続的なアップデートとセキュリティパッチを継承できます。

最小限のベースイメージをゼロから構築したい場合は、「リファレンス: 最小限のベースイメージをゼロから構築する」を参照してください。

ステップ 2a: ベースイメージをプルします

ベースイメージを取得するには、以下を実行します。

Bash
docker pull databricksruntime/environment:v5-standard

AWS Graviton (ARM) インスタンスタイプの場合は、ARM バリアントを使用してください。

databricksruntime/environment:v5-standard-arm

ステップ 2b: 基本イメージを拡張する Dockerfile を作成する

ベースイメージの/databricks/python3仮想環境にカスタムPythonパッケージをインストールします。これは、ワークロードを起動するためのシステム仮想環境です。

AWS Gravitonインスタンスタイプを対象とする場合は、 FROM行の:v5-standard :v5-standard-armに置き換えてください。

Dockerfile
FROM databricksruntime/environment:v5-standard

RUN /databricks/python3/bin/python -m pip install <your python package>

以下の例は、プライベートリポジトリからパッケージをインストールする方法を示しています。

Dockerfile
FROM databricksruntime/environment:v5-standard

ENV PIP_INDEX_URL=https://pypi.org/simple

RUN /databricks/python3/bin/python -m pip install --no-cache-dir simplejson

標準的な Dockerfile の命令 (例えば、 RUN 、 ENV 、 WORKDIR 、 COPY ) を使用できます。Databricksがワークロードを起動する方法のため、以下の指示は無視されます。

USER
CMD
ENTRYPOINT
EXPOSE
HEALTHCHECK
SHELL
STOPSIGNAL

注記

Scalaワークロードの場合は、JARファイルをイメージ内の/scala-jars/userディレクトリにコピーし、 chmod 0644してサンドボックスユーザーが読み取れるようにしてください。Databricks はこのパスにある JAR ファイルを Spark のクラスパスにロードします。

ステップ 2c: イメージを構築する

イメージをビルドするには、以下を実行します。

Bash
docker build -f <your-dockerfile> -t <registry-url>/<project>[/<repo>]:<tag> .

警告

Databricksコンピュートでカスタムイメージを徹底的にテストします。ローカル環境やビルド環境では正常に動作するイメージでも、Databricks上で起動すると、起動に失敗したり、機能がサイレントに無効化されたり、動作が停止したりする場合があります。

参考資料：最小限のベースイメージをゼロから構築する

ベースイメージの内容を完全に制御する必要がある場合（たとえば、厳格なイメージサイズ、サプライチェーン、またはコンプライアンス要件を満たすため）、databricksruntime/environment:v5-standard を拡張するのではなく、の最小限の同等品をゼロから構築できます。

警告

ゼロから構築するのは、より高度な選択肢です。Pythonピン処理、セキュリティパッチ、プラットフォームツール、および/databricks/と/etc/environmentの下にあるプラットフォーム必須ファイルを含む、 v5-standardイメージへの上流の変更を追跡する責任を負います。代わりに、Databricks はステップ 2で示したようにdatabricksruntime/environment:v5-standardを拡張することを推奨しています。

Databricksは、 v5-standardの基本的なPython環境を再現する参照Dockerfileとrequirements.txtを提供します。ビルドする前に、両方のファイルを同じディレクトリにダウンロードしてください。

Dockerfile （拡張子.txtなしでDockerfileとして保存）
requirements.txt

イメージをビルドするには、以下を実行します。

Bash
docker build -t <your-registry>/<repo>:<tag> .

ビルドホストがhttps://pypi.orgにアクセスできない場合は、ビルド時に以下のコマンドを実行してpipインデックスを上書きしてください。

Bash
docker build --build-arg PIP_INDEX_URL=https://your-mirror/simple -t <your-registry>/<repo>:<tag> .

次のステップに進む前に、以下を実行して、厳選されたPythonパッケージが問題なくインポートされることを確認してください：

Bash
docker run --rm --cpus 2 <your-registry>/<repo>:<tag> \
  /databricks/python3/bin/python -c \
  "import pandas, numpy, pyarrow, mlflow, databricks.connect; print('OK')"

ステップ 3: イメージをレジストリにプッシュします

次に、イメージをDockerレジストリにプッシュします。Databricks Container Services標準コンピュートと専用コンピュートの両方で同じレジストリをサポートします。

認証なし、または基本認証のみのDocker Hub 。
基本認証を使用したAzure Container Registry 。
IAMを使用するAmazon Elastic Container Registry（Amazon ECR）（ただしCommercial Cloud Services（C2S）を除く）。

認証不要または基本認証をサポートする他のレジストリでも動作するはずです。基本認証では、登録済みのユーザー名とパスワードを使用します。

イメージプルのパフォーマンスを最適化するには、 Databricksワークスペースと同じクラウドおよびリージョン内のレジストリを使用します。

Bash
echo "$REGISTRY_PASSWORD" | docker login -u <registry-username> --password-stdin <registry-url>
docker push <registry-url>/<project>[/<repo>]:<tag>

注記

Docker Hub使用する場合は、レート制限が 6 時間以内に起動する予定のコンピュートに対応していることを確認してください。詳細はDockerのドキュメントを参照してください。この制限を超えた場合、リクエストは429 Too Many Requestsを返します。

ステップ 4: コンピュートを起動します

UI またはAPIを使用して、カスタムイメージを使用するコンピュートを起動できます。以下の要件を満たす必要があります。

コンピュートアクセスモードは 標準で ある必要があります ( APIで、 data_security_modeをDATA_SECURITY_MODE_STANDARDに設定します)。コンピュートが専用アクセスモードに設定されている場合、 Databricks Container Servicesの別のバージョンが使用され、異なるベースイメージが想定されるため、構築したベースイメージでは起動に失敗します。
Databricks Runtime バージョンは**18 Beta**以上である必要があります。

注記

インスタンスプールに対して起動するには、プールはpreloaded_docker_imagesが設定されて作成されている必要があり、クラスターのdocker_imageが一致している必要があります。インスタンスでDatabricks Container Servicesを使用するを参照してください。起動する前に。

UIを使用してコンピュートを起動します

コンピュートの作成ページで、 アクセスモード が標準に、また Databricks ランタイム が 18 Beta 以降に設定されていることを確認してください。
「詳細設定」 で「 Docker」 タブを選択します。
[ 自分のDockerコンテナを使用する ]を選択します。

Dockerイメージ URL」 フィールドにカスタムイメージを入力します。

レジストリ	タグの形式
Dockerハブ	`<organization>/<repository>:<tag>` （例: `databricksruntime/environment:v5-standard`）
Amazon ECR	`<aws-account-id>.dkr.ecr.<region>.amazonaws.com/<repository>:<tag>`
Azure Container Registry	`<your-registry-name>.azurecr.io/<repository-name>:<tag>`

認証タイプを選択してください。Dockerイメージの認証を参照してください。

注記

コンピュートの作成時に Docker 設定が表示されない場合は、 Databricks Container Servicesワークスペースで有効になっていない可能性があります。ユーザーがDockerイメージを指定するには、ワークスペース管理者がそれを有効にする必要があります。「ステップ 1: 標準コンピュート用にDatabricks Container Servicesを有効にする」を参照してください。

APIを使用してコンピュートを起動する

以下は、カスタムイメージを使用して標準のコンピュートを作成するAPI呼び出しの例です。 data_security_modeがDATA_SECURITY_MODE_STANDARDに設定され、 spark_versionが18.x-scala2.13以上に設定されていることを確認してください。

公開画像（認証なし）の場合：

Bash
databricks clusters create \
--cluster-name <cluster-name> \
--node-type-id <node-type> \
--json '{
  "num_workers": 1,
  "docker_image": {
    "url": "<docker-registry-image-url>"
  },
  "spark_version": "18.x-scala2.13",
  "aws_attributes": {
    "availability": "ON_DEMAND"
  },
  "data_security_mode": "DATA_SECURITY_MODE_STANDARD"
}'

基本認証の場合：

Bash
databricks clusters create \
--cluster-name <cluster-name> \
--node-type-id <node-type> \
--json '{
  "num_workers": 1,
  "docker_image": {
    "url": "<docker-registry-image-url>",
    "basic_auth": {
      "username": "<docker-registry-username>",
      "password": "<docker-registry-password>"
    }
  },
  "spark_version": "18.x-scala2.13",
  "aws_attributes": {
    "availability": "ON_DEMAND"
  },
  "data_security_mode": "DATA_SECURITY_MODE_STANDARD"
}'

インスタンスプロファイルを使用する場合（Amazon ECRの場合）：

Bash
databricks clusters create \
--cluster-name <cluster-name> \
--node-type-id <node-type> \
--json '{
  "num_workers": 1,
  "docker_image": {
    "url": "<image-url>"
  },
  "spark_version": "18.x-scala2.13",
  "aws_attributes": {
    "availability": "ON_DEMAND",
    "instance_profile_arn": "arn:aws:iam::<aws-account-number>:instance-profile/<iam-role-name>"
  },
  "data_security_mode": "DATA_SECURITY_MODE_STANDARD"
}'

Dockerイメージの認証

認証要件は、 Dockerイメージの種類によって異なります。シークレットを使用して、認証のユーザー名とパスワードを保存することもできます。「認証にシークレットを使用する」を参照してください。

公開されているDockerイメージの場合、認証情報を含める必要はありません。UIで 認証を 「デフォルト」 に設定します。API呼び出しでは、 basic_authフィールドを含め ないでください 。
プライベートDockerイメージの場合、サービスプリンシパル ID とパスワード (または該当するシークレット) をユーザー名とパスワードとして使用して認証します。
Azure Container Registry の場合は、サービスプリンシパル ID とパスワード (または該当するシークレット) をユーザー名とパスワードとして使用して認証します。サービスプリンシパルの作成に関する情報については、Azure Container Registry サービスプリンシパルの認証のドキュメントを参照してください。

Amazon ECRイメージには、認証情報を含めないでください。代わりに、イメージが存在するDockerリポジトリからDockerイメージをプルする権限を含むインスタンスを使用してコンピュートを起動します。これを行うには、インスタンスを使用してS3バケットへの安全なアクセスを設定するプロセスのステップ 3 と 4 に従います。

任意のイメージをプルする権限を持つIAMロールの例を次に示します。リポジトリは<arn-of-repository>で指定されます。

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ecr:GetAuthorizationToken"],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:GetDownloadUrlForLayer",
        "ecr:GetRepositoryPolicy",
        "ecr:DescribeRepositories",
        "ecr:ListImages",
        "ecr:DescribeImages",
        "ecr:BatchGetImage"
      ],
      "Resource": ["<arn-of-repository>"]
    }
  ]
}

ECRイメージがDatabricksコンピュートとは異なるAWSアカウントに存在する場合は、コンピュートインスタンスオプションに加えてECR リポジトリポリシーを使用して、コンピュートアクセスを許可します。以下は ECR リポジトリポリシーの例です。コンピュートのインスタンスが想定するIAMロールは、 <arn-of-IAM-role>で指定されます。

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountPush",
      "Effect": "Allow",
      "Principal": {
        "AWS": "<arn-of-IAM-role>"
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:DescribeImages",
        "ecr:DescribeRepositories",
        "ecr:GetDownloadUrlForLayer",
        "ecr:GetRepositoryPolicy",
        "ecr:ListImages"
      ]
    }
  ]
}

認証には秘密情報を使用する

Databricks コンテナサービスは、認証にシークレットを使用することをサポートしています。 UI でコンピュートリソースを作成する場合は、認証フィールドを使用して ユーザー名とパスワード を選択し、プレーンテキストのユーザー名またはパスワードを入力する代わりに、 {{secrets/<scope-name>/<dcs-secret>}} 形式でシークレットを入力します。 API を使用する場合は、 basic_auth フィールドにシークレットを入力します。

シークレットの作成については、「シークレット管理」を参照してください。

インスタンスプールでDatabricks Container Servicesを使用する

インスタンスプールでDatabricks Container Servicesを使用するには、UI ではなくInstance プールAPIを使用してプールを作成する必要があります。

プールは、Dockerイメージが事前にロードされた状態で作成する必要があります。これにより、アイドル状態のインスタンスがカスタムイメージでウォームアップされ、ワークロードの起動が速くなります。コンピュートを直接起動する際に使用する画像参照と認証情報と同じものをリクエストのpreloaded_docker_imagesフィールドに設定します。このフィールドはリストなので、1つのプールで複数の画像をプリロードできます。

プールとそれに付属するコンピュートリソースは、 Dockerが使用されているかどうかに同意する必要があります。プールにpreloaded_docker_imagesが設定されていない場合、そのプールに対してDatabricks Container Servicesコンピュートを起動できません。 preloaded_docker_imagesを設定した新しいプールを作成します。

preloaded_docker_imagesで作成されたプールの場合、そのプールに対して起動されるコンピュートリソースは、その作成リクエストで一致するdocker_imageを指定する必要があります。それ以外の場合、コンピュートの作成は'docker_image' must be provided for cluster created with instance pool: <pool-id>で失敗します。

元のDatabricks Container Servicesから移行する

標準コンピュート用のDatabricks Container Services 、専用コンピュート用の元のDatabricks Container Servicesとは別のサービスです。この機能には以下の相違点があります。

ワークロードはSpark Connectプロトコルを介して実行されます。
init スクリプトはワークロードのPython環境を変更しません。 Dockerイメージには、Pythonのすべての依存関係をインストールする必要があります。Datadog エージェントやKafkaエージェントなど、 Sparkからのデータを使用するアプリケーションには、引き続き init スクリプトを使用できます。
AWS Gravitonインスタンスタイプのサポート。

専用コンピュート用の元のDatabricks Container Servicesから移行するには、標準コンピュート用のDatabricks Container Servicesでカスタムイメージを再構築し、コンピュート構成を更新します。

Dockerfile 内のFROM行をFROM databricksruntime/environment:v5-standard (AWS Graviton の場合はv5-standard-arm ) に置き換えてください。
Dockerfileの手順を新しいベースイメージに移植してください。標準の Dockerfile の手順がサポートされていますが、ステップ 2: カスタムイメージをビルドするに記載されている例外があります。
Pythonパッケージを他の仮想環境ではなく/databricks/python3にインストールします。ワークロード (ノートブック、 Python wheelジョブ、 Pythonスクリプトジョブ) はこのパスから読み取られます。
コンピュート構成を標準アクセスモードとDatabricks Runtime 18 ベータ以降を使用するように更新してください。
以前initスクリプトで行っていたPython環境の設定をすべてDockerfileに移動します。

制限事項

標準のコンピュートの制限に加えて、標準のコンピュートのDatabricks Container Servicesには次の制限があります。

コンピュートスコープのライブラリはサポートされていません。
プライベートパッケージリポジトリはサポートされていません。
Databricks Runtime for Machine Learningはサポートされていません。
インスタンスプールに対してDatabricks Container Servicesを使用して標準のコンピュートを起動するには、 preloaded_docker_imagesを設定してプールを作成する必要があります。「インスタンスプールでのDatabricks Container Services使用」を参照してください。

トラブルシューティング

コンピュートの作成時に Docker タブが [詳細設定] に表示されない場合は、ワークスペースに対してDatabricks Container Services有効になっていません。ユーザーがDockerイメージを指定するには、ワークスペース管理者がワークスペース内でこの機能を有効にする必要があります。「ステップ 1: 標準コンピュート用にDatabricks Container Servicesを有効にする」を参照してください。

要件​

ステップ 1: 標準コンピュート用にDatabricks Container Servicesを有効にする​

ステップ 2: カスタム イメージを構築する​

ステップ 2a: ベースイメージをプルします​

ステップ 2b: 基本イメージを拡張する Dockerfile を作成する​

ステップ 2c: イメージを構築する​

参考資料：最小限のベースイメージをゼロから構築する​

ステップ 3: イメージをレジストリにプッシュします​

ステップ 4: コンピュートを起動します​

UIを使用してコンピュートを起動します​

APIを使用してコンピュートを起動する​

Dockerイメージの認証​

認証には秘密情報を使用する​

インスタンスプールでDatabricks Container Servicesを使用する​

元のDatabricks Container Servicesから移行する​

制限事項​

トラブルシューティング​

要件