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"}'