Databricks Container Servicesを使用したコンテナーのカスタマイズ

Databricks Container Services では、コンピュートの作成時に Dockerイメージを指定できます。 使用例には、次のようなものがあります。

  • ライブラリのカスタマイズ: インストールするシステムライブラリを完全に制御できます。

  • ゴールデンコンテナー環境: Dockerイメージはロックダウンされた環境で、変化することはありません。

  • Docker CI/CD統合: DatabricksはDocker CI/CDパイプラインと統合できます。

Dockerイメージを使用して、GPUデバイスを備えたコンピュート上にカスタムディープラーニング環境を作成することもできます。 Databricks Container Services での GPU コンピュートの使用に関する追加情報については、 「GPU コンピュートでの Databricks Container Services」を参照してください。

コンテナーが起動するたびにタスクを実行するには、initスクリプトを使用します。

要件

  • Databricks ワークスペースでは、Databricks Container Servicesが有効になっている必要があります。

  • マシンは、最新のDockerデーモン（テスト済みで、クライアント/サーバーバージョン18.03.0-ceで動作するデーモン）を実行している必要があります。また、dockerコマンドをPATHで使用できる必要があります。

制限事項

  • Databricks Container Services は、共有アクセス モードを使用するコンピュートではサポートされていません。

  • 機械学習用Databricks Runtimeは、Databricks Container Servicesをサポートしていません。

  • Databricks Container Services のボリュームにアクセスするには、コンピュートの Spark 構成 フィールドに spark.databricks.unityCatalog.volumes.enabled true構成を追加します。

  • Databricks Container Services は、AWS Graviton インスタンスタイプではサポートされていません。

ステップ1: ベースを構築する

Databricksでは、Databricksで構築およびテストされたベースからDockerベースを構築することをおすすめします。Dockerベースをゼロから構築することも可能です。このセクションでは、これらの2つの方法について説明します。

選択肢1: Databricksで構築されたベースを使用する

この例では、 Databricks Runtime 9.1 LTS以降のバージョンを持つコンピュートをターゲットとするイメージに 9.x タグを使用します。

FROM databricksruntime/standard:9.x
...

最新バージョンのpandasやurllibなどの追加のPythonライブラリを指定するには、コンテナー固有のバージョンのpipを使用します。databricksruntime/standard:9.xコンテナーの場合は、次のものを指定します。

RUN /databricks/python3/bin/pip install pandas
RUN /databricks/python3/bin/pip install urllib3

databricksruntime/standard:8.x以下のコンテナーの場合は、次のものを指定します。

RUN /databricks/conda/envs/dcs-minimal/bin/pip install pandas
RUN /databricks/conda/envs/dcs-minimal/bin/pip install urllib3

ベースイメージはDocker Hub（https://hub.docker.com/u/databricksruntime）でホストされます。これらのベースを生成するために使用されるDockerfileはhttps://github.com/databricks/containersにあります。

注：

サフィックスが「-LTS」であるタグが付いたDocker Hubでホストされているイメージにはパッチが適用されます。他のすべてのイメージは例であり、定期的にパッチが適用されているわけではありません。

注：

ベースイメージdatabricksruntime/standardおよびdatabricksruntime/minimalは、すでに使用できないDatabricks Runtime with Conda（ベータ版）に含まれているdatabricks-standardおよびdatabricks-minimal環境とは関係ないので、混同しないでください。

選択肢2: 独自のDockerベースを構築する

Dockerベースはゼロから構築することもできます。Docker イメージは、次の要件を満たしている必要があります。

独自のイメージをゼロから構築するには、仮想環境を作成する必要があります。 また、Python や R など、Databricks コンピュートに組み込まれているパッケージも含める必要があります。開始するには、適切な基本イメージを使用できます。

  • Rの場合: databricksruntime/rbase

  • Pythonの場合: databricksruntime/python

  • Databricksによって構築された最小限のイメージの場合: databricksruntime/minimal

GitHubのDockerfilesの例を参照することもできます。

注：

DatabricksはUbuntu Linuxの使用をおすすめしています。ただし、Alpine Linuxを使用することは可能です。Alpine Linuxを使用するには、次のファイルを含める必要があります。

さらに、このDockerfileの例に示すように、Pythonをセットアップする必要があります。

警告

カスタム コンテナー イメージを Databricks コンピュートで徹底的にテストします。 コンテナーはローカル コンピューターまたはビルド コンピューターで動作する可能性がありますが、コンテナーが Databricks で起動されると、コンピュートの起動が失敗したり、特定の機能が無効になったり、コンテナーがサイレントであっても動作を停止したりする可能性があります。 最悪のシナリオでは、データが破損したり、誤ってデータが外部に公開されたりする可能性があります。

ステップ 2: ベースイメージをプッシュする

カスタムベースイメージをDockerレジストリにプッシュします。このプロセスは、次のレジストリでサポートされています。

認証や基本認証をサポートしない他のDockerレジストリも動作することが想定されます。

注：

Docker レジストリに Docker Hub を使用する場合は、レート制限が 6 時間で起動すると予想されるコンピュートの量に対応していることを必ず確認してください。 これらのレート制限は、匿名ユーザー、有料サブスクリプションを持たない認証済みユーザー、および有料サブスクリプションで異なります。 詳細については 、Docker のドキュメント を参照してください。 この制限を超えると、"429 Too Many Requests" 応答が返されます。

ステップ 3:コンピュートを起動する

コンピュートは、UI または API を使用して起動できます。

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

  1. [ コンピュートの作成] ページで、Databricks Container Services をサポートする Databricks Runtime バージョンを指定します。

  2. [詳細オプション]で、[Docker]タブを選択します。

  3. [自分のDockerコンテナを使用する]を選択します。

  4. [DockerイメージURL]フィールドに、カスタムDockerイメージを入力します。

    DockerイメージURLの例:

    レジストリ

    タグの形式

    Dockerハブ

    <organization>/<repository>:<tag> （例: databricksruntime/standard:latest）

    Amazon ECR

    <aws-account-id>.dkr.ecr.<region>.amazonaws.com/<repository>:<tag>

    Azure Container Registry

    <your-registry-name>.azurecr.io/<repository-name>:<tag>

  5. 認証タイプを選択します。 シークレットを使用して、ユーザー名とパスワードの認証値を保存できます。 「 認証にシークレットを使用する」を参照してください。

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

  1. APIトークンを生成します。

  2. Databricks CLIを使用して、カスタムDockerベースでコンピュートを起動します。

    databricks clusters create \
--cluster-name <cluster-name> \
--node-type-id i3.xlarge \
--json '{
  "num_workers": 0,
  "docker_image": {
    "url": "databricksruntime/standard:latest",
    "basic_auth": {
      "username": "<docker-registry-username>",
      "password": "<docker-registry-password>"
    }
  },
  "spark_version": "14.3.x-scala2.12",
  "aws_attributes": {
    "availability": "ON_DEMAND",
    "instance_profile_arn": "arn:aws:iam::<aws-account-number>:instance-profile/<iam-role-name>"
  }
}'

    basic_auth 要件は、Dockerイメージの種類によって異なります。

    • パブリックDockerイメージの場合は、basic_authフィールドを含めないでください。

    • プライベートDockerイメージの場合は、basic_authフィールドを追加し、ユーザー名とパスワードとしてサービスプリンシパルのIDとパスワードを使用する必要があります。

    • Azure Container Registryの場合は、basic_authフィールドをサービスプリンシパルのIDとパスワードに設定する必要があります。サービスプリンシパルの作成については、Azure Container Registryのサービスプリンシパル認証に関するドキュメントを参照してください。

    • Amazon ECR イメージの場合は、 basic_auth フィールドを含めないでください。 コンピュートは、イメージが存在する Docker リポジトリから Dockerイメージをプルするアクセス許可を含む インスタンスプロファイル で起動する必要があります。 これを行うには、 インスタンスプロファイルを使用して S3 バケットへの安全なアクセスを設定するプロセスのステップ 3 と 4 に従います。

    • シークレットを使用して認証情報を保存することもできます。 「 認証にシークレットを使用する」を参照してください。

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

       {
   "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>" ]
     }
   ]
 }

      Amazon ECR イメージが Databricks コンピュートとは異なる AWS アカウントにある場合は、コンピュートインスタンスプロファイルに加えて ECR リポジトリポリシー を使用して、コンピュートにアクセス権を付与します。 次に、ECRリポジトリポリシーの例を示します。 コンピュートのインスタンスプロファイルが担う IAM ロールは、 <arn-of-IAM-role>で指定します。

      {
  "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"
    ]
  }]
}

initスクリプトの使用

Databricks Container Services を使用すると、顧客は Docker コンテナーに initスクリプトを含めることができます。 ほとんどの場合、initスクリプトは使用せず、代わりに Docker から直接 (Dockerfile を使用して) カスタマイズを行う必要があります。 ただし、特定のタスクは、コンテナーのビルド時ではなく、コンテナーの開始時に実行する必要があります。 これらのタスクには init スクリプトを使用します。

たとえば、カスタムコンテナー内でセキュリティデーモンを実行するとします。イメージ構築パイプラインを使用して、Dockerイメージにデーモンをインストールしてビルドします。次に、デーモンを起動するinitスクリプトを追加します。この例では、initスクリプトに「systemctl start my-daemon」のような行が含まれます。

API では、次のようにコンピュート仕様の一部として initスクリプトを指定できます。 詳細については、「 クラスター API」を参照してください。

"init_scripts": [
    {
        "file": {
            "destination": "file:/my/local/file.sh"
        }
    }
]

Databricks Container Services イメージの場合は、initスクリプトをクラウド ストレージに格納することもできます。

Databricks Container Services を使用するコンピュートを起動すると、次のステップが実行されます。

  1. VMはクラウドプロバイダーから取得されます。

  2. カスタムDockerイメージはリポジトリからダウンロードされます。

  3. Databricksは、イメージからDockerコンテナーを作成します。

  4. Databricks RuntimeコードがDockerコンテナーにコピーされます。

  5. initスクリプトが実行されます。 init スクリプトとはを参照してください。

DatabricksはDockerのCMDおよびENTRYPOINTプリミティブを無視します。

認証にシークレットを使用する

Databricks Container サービスは、認証にシークレットの使用をサポートしています。 コンピュートリソースを作成するときは、プレーンテキストのユーザー名またはパスワードを入力する代わりに、 {{secrets/<scope-name>/<dcs-secret>}}形式を使用してシークレットを入力します。 シークレットの作成に関する情報については、 「シークレット」を参照してください。

コンテナサービスを有効にする

コンピュートでカスタム コンテナーを使用するには、ワークスペース管理者が Databricks Container Services を有効にする必要があります。

ワークスペース管理者は、 を使用してDatabricks Container サービス を有効にできます。DatabricksCLIJSON リクエスト本文では、次の例のようにenableDcsからtrueを指定します。

databricks workspace-conf set-status \
--json '{"enableDcs": "true"}'