メインコンテンツにスキップ
GitHubでこのページを編集

Docker Composeの使用



注意

docker compose は、主に**単一ホスト**でコンテナのセットを実行するように設計されており、**高可用性**の要件をサポートできないため、本番環境タイプのユースケースをサポートするために docker compose 構造を使用することはサポートも推奨もしていません。単一ホスト環境では、minikube と k8sへのインストール ドキュメントを併用することをお勧めします。

クイックスタートガイドで述べたように、LinuxまたはMac OSXコンピューターでSupersetをローカルで試す最も速い方法は、Docker Composeを使用することです。SupersetはWindowsを公式にサポートしていません。また、完全に機能する**開発環境**を迅速に立ち上げる最も簡単な方法でもあります。

docker compose を実行するためにサポートされている3つの主要な方法があることに注意してください

  1. **docker-compose.yml:** インタラクティブな開発用。フロントエンド/バックエンドファイルを含むローカルフォルダをマウントし、アプリに加えた変更をリアルタイムで確認できます。
  2. **docker-compose-non-dev.yml:** ローカルブランチに基づいてより不変なイメージをビルドし、必要なすべてのイメージを実行します。起動時にローカルブランチに加えられた変更は反映されますが、up 中のコード変更はアプリに反映されません。
  3. **docker-compose-image-tag.yml:** たとえば、3.0.0 リリースのdocker-hubからイメージを取得して起動し、試すことができます。ここでは、ローカルブランチの内容は実行中の内容に影響を与えません。docker-hubから事前にビルドされたイメージを取得して実行するだけです。docker compose が起動するPostgresイメージと一緒に動作するには、export TAG=4.0.0-dev または export TAG=3.0.0-dev のように、-dev 接尾辞が付いたTAGを指す必要があります。デフォルトは latest-dev です。これは、dev ビルドが、docker compose ビルドの一部として起動されたPostgresデータベースに接続するために必要な psycopg2-binary をパッケージ化するためです。 ``

これらの2つのアプローチの詳細については、いずれかの要件を設定した後述べます。

要件​

このドキュメントでは、Docker と git がインストールされていることを前提としています。また、以前は docker-compose を使用していましたが、非推奨になる予定であるため、現在は docker compose を使用しています。

1. SupersetのGitHubリポジトリのクローンを作成する​

ターミナルで次のコマンドを使用して、Supersetのリポジトリのクローンを作成します

git clone --depth=1  https://github.com/apache/superset.git

コマンドが正常に完了すると、現在のディレクトリに新しい superset フォルダが表示されます。

2. Docker Composeを介してSupersetを起動する​

まず、docker compose の仕組みに精通していることを前提とします。ここでは、docker compose up を使用して新しいリモートイメージのチェックを強制する場合や、docker compose build でビルドを強制する場合、または docker compose build --pull を使用して最新のベースイメージでビルドを強制する場合がありますが、一般的に docker compose up と呼びます。ただし、ほとんどの場合、単純な up コマンドで十分です。トピックの詳細については、docker composeのドキュメントを参照してください。

オプション＃1-インタラクティブな開発環境の場合​

docker compose up
ヒント

開発モードで実行する場合、UIが正しくレンダリングされるためには、superset-node コンテナがアセットのビルドを完了する必要があります。コードを変更せずにSupersetを試してみたい場合は、以下に示す production または特定のバージョンの手順に従ってください。

ヒント

デフォルトでは、ローカルのsuperset-frontendフォルダをここにマウントし、npm install と npm run dev を実行します。これにより、webpackがフロントエンドコードをコンパイル/バンドルします。ローカルの設定によっては、特にメモリが16GB未満の場合、これらの操作の実行が非常に遅くなる可能性があります。この場合、環境変数 BUILD_SUPERSET_FRONTEND_IN_DOCKER を false に設定し、代わりにターミナルでローカルで実行することをお勧めします。単に npm i && npm run dev をトリガーするだけで、はるかに高速になります。

オプション＃2-ローカルブランチから不変なイメージのセットをビルドする​

docker compose -f docker-compose-non-dev.yml up

オプション＃3-公式リリースを起動する​

export TAG=3.1.1
docker compose -f docker-compose-image-tag.yml up

ここでは、さまざまなリリースタグ、github SHA、および最新の master をTAG環境変数で参照できます。Docker Hubからポイントできる既存のタグの詳細については、docker関連のドキュメントを参照してください。

docker compose ヒントと設定​

注意

チャート、ダッシュボード、ユーザーなど、Supersetインスタンスに属するすべてのコンテンツは、そのメタデータデータベースに保存されます。本番環境では、このデータベースをバックアップする必要があります。docker composeを使用したデフォルトのインストールでは、そのデータがDocker ボリュームに含まれるPostgreSQLデータベースに保存されます。これはバックアップされていません。

繰り返しますが、**本番環境には使用しないでください**

マシンで起動されているコンテナからのログ出力のストリームが表示されます。この出力が遅くなると、ローカルマシンでSupersetのインスタンスが実行されているはずです！今後の実行でテキストの壁を回避するには、docker compose up コマンドの最後に -d オプションを追加します。

詳細設定​

以下は、Docker ComposeでSupersetの実行方法を設定したいユーザー向けです。そうでない場合は、次のセクションにスキップできます。

docker/README.mdに記載されている手順に従って、追加のPythonパッケージをインストールし、設定のオーバーライドを適用できます。

docker/.env は、docker compose で使用されるすべてのdockerイメージのデフォルトの環境変数を設定し、docker/.env-local はこれらのデフォルトをオーバーライドするために使用できることに注意してください。また、docker/.env-local は .gitignore で参照されているため、開発者が機密性の高い設定をリポジトリにコミット/プッシュするリスクを回避できます。

重要な変数の1つは SUPERSET_LOAD_EXAMPLES です。これは、superset_init コンテナがサンプルデータとビジュアライゼーションをメタデータデータベースに入力するかどうかを決定します。これらの例は、Supersetの学習とテストに役立ちますが、経験豊富なユーザーや本番環境のデプロイメントには不要です。読み込みプロセスには数分とかなりのCPUがかかる場合があるため、リソースに制約のあるデバイスでは無効にすることをお勧めします。

通常は PYTHONPATH にある superset_config.py ファイルで管理される、より高度なまたは動的な設定については、gitによって無視される docker/pythonpath_dev/superset_config_docker.py を提供することで実行できることに注意してください（ローカル設定をリポジトリにコミット/プッシュすることを防ぎます）。この仕組みは docker/pythonpath_dev/superset_config.py にあります。ここでは、ロジックが from superset_config_docker import * を実行していることがわかります。

注記

ユーザーはしばしばSupersetから他のデータベースに接続したいと考えます。現在、これを行う最も簡単な方法は、docker-compose-non-dev.ymlファイルを修正し、他のサービスが依存するサービスとして（x-superset-depends-onを介して）データベースを追加することです。network_mode: hostをSupersetサービスに設定しようとした人もいますが、設定ではサービス名にDocker Compose DNSリゾルバーを使用する必要があるため、これらは一般的にインストールを中断します。この問題に対する良い解決策があれば、お知らせください！

注記

Supersetは、Scarf Gatewayを使用してテレメトリデータを収集します。Supersetの異なるバージョンごとのインストール数を把握することで、プロジェクトのパッチ適用と長期サポートに関する意思決定に役立ちます。Scarfは個人を特定できる情報（PII）を削除し、集計された統計のみを提供します。

Docker ComposeベースのインストールによってScarf Gateway経由でダウンロードされたパッケージのデータ収集をオプトアウトするには、docker-compose.ymlおよびdocker-compose-non-dev.ymlファイルのx-superset-image:行を編集し、apachesuperset.docker.scarf.sh/apache/supersetをapache/supersetに置き換えて、Docker Hubから直接イメージをプルします。

Scarfテレメトリピクセルを無効にするには、ターミナルまたはdocker/.envファイルでSCARF_ANALYTICS環境変数をFalseに設定します。

3. Supersetにログインする​

ローカルのSupersetインスタンスには、データを格納するためのPostgresサーバーも含まれており、Supersetに付属するいくつかのサンプルデータセットが既にプリロードされています。Webブラウザでhttp://localhost:8088にアクセスすることで、Supersetにアクセスできます。多くのブラウザは現在デフォルトでhttpsを使用しています。お使いのブラウザがそのうちの1つである場合は、httpを使用していることを確認してください。

デフォルトのユーザー名とパスワードでログインします

username: admin
password: admin

4. Supersetをローカルデータベースインスタンスに接続する​

dockerまたはdocker composeを使用してSupersetを実行する場合、Supersetが完全に別のマシンで実行されているかのように、独自のDockerコンテナ内で実行されます。したがって、ホスト名localhostを使用してローカルデータベースに接続しようとすると、localhostはSupersetが実行されているDockerコンテナを指し、実際のホストマシンを指していないため、機能しません。幸いなことに、Dockerはコンテナ内からホストマシンのネットワークリソースにアクセスする簡単な方法を提供しており、この機能を活用してローカルデータベースインスタンスに接続します。

ここでは、Superset（Dockerコンテナ内で実行されている）からpostgresql（ホストマシンで実行されている）に接続するための手順を示します。他のデータベースでは設定がわずかに異なる場合がありますが、要点は同じで、2つの手順に要約されます。

  1. （Macユーザーはこの手順をスキップできます）パブリックの着信接続を受け入れるようにローカルのpostgresql /データベースインスタンスを設定します。デフォルトでは、postgresqlはlocalhostからの着信接続のみを許可し、Dockerでは、--network=hostを使用しない限り、localhostはホストマシンとDockerコンテナでそれぞれ異なるエンドポイントを参照します。postgresqlがDockerからの接続を受け入れるようにするには、postgresql.confおよびpg_hba.confファイルに1行の変更を加える必要があります。このタスクについては、WebでOS / PGバージョンに合わせた役立つリンクを簡単に見つけることができます。Dockerの場合、*ではなくIP 172.0.0.0/8のみをホワイトリストに登録すれば十分ですが、いずれの場合も、本番データベースでこれを行うと、データベースをパブリックインターネットに公開するため、 disastrous な結果になる可能性があることに注意してください。
  2. localhostの代わりに、データベースに接続しようとするときに、ホスト名としてhost.docker.internal（Macユーザー、Ubuntu）または172.18.0.1（Linuxユーザー）を使用してみてください。これはDockerの内部的な詳細です。Macシステムでは、Docker Desktopはホストマシン。正アドレスに解決されるホスト名host.docker.internalのDNSエントリを作成しますが、Linuxでは（少なくともデフォルトでは）そうではありません。これらの2つのホスト名のいずれも機能しない場合は、使用する正確なホスト名を見つける必要があります。そのためには、ifconfigまたはip addr showを実行し、Dockerによって作成されたはずのdocker0インターフェースのIPアドレスを確認できます。または、docker0インターフェースが表示されない場合は、（必要に応じてsudoを使用して）docker network inspect bridgeを試してみて、"Gateway"のエントリがあるかどうかを確認し、IPアドレスをメモしてください。