使用Docker Compose

caution

由于 docker-compose 主要用于在单一主机上运行一组容器， 且无法满足高可用性的要求，我们不支持也不建议使用我们的 docker-compose 结构来支撑生产级别的应用场景。对于单一主机环境， 我们建议使用minikube并参照我们的在 k8s 上安装 文档。

正如我们在快速入门指南中提到的， 尝试本地运行 Superset 最快的方式是在 Linux 或 Mac OSX 计算机上使用 Docker Compose。 Superset 官方不支持 Windows 系统。同时，这也是迅速搭建一个功能完备的开发环境最简便的方法。

请注意，我们支持运行 docker-compose 主要有以下3种方式：

1. docker-compose.yml: 用于交互式开发，我们将挂载包含前端/后端文件的本地文件夹， 你可以编辑这些文件，并实时体验你在应用中所做的更改。
2. docker-compose-non-dev.yml 在这里我们基于本地分支构建更不可变的镜像，并启动所有必需的容器。当你启动时， 本地分支中的更改将被反映出来，但是在 up 运行期间对代码的任何更改不会在应用中即时体现。
3. docker-compose-image-tag.yml 在这里我们从 docker-hub 拉取镜像，比如 3.0.0 版本的发布，然后启动它以便你可以试用。 在这种情况下，本地分支的内容对正在运行的应用没有影响，我们只是从 docker-hub 获取并运行预构建的镜像。

在为这两种方法设置好相应需求后，我们将进一步详细介绍它们。

需求

请注意，本文档假设你已安装了Docker, docker-compose, 以及 git。

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 pull 强制检查更新的远程镜像， 或者使用 docker compose build 强制构建， 又或者使用 docker compose build --pull 在最新的基础镜像上进行构建。 然而，在大多数情况下，简单的 up 命令就足够了。关于更多细节，请参考 docker compose 的官方文档。

Option #1 - 用于交互式开发环境

docker compose up

tip

在开发模式下运行时，superset-node 容器需要完成构建资源，以确保 UI 能够正确渲染。 如果你只想试用 Superset 而无需做任何代码修改，请按照下面记录的 production 环境或特定版本的步骤操作。

tip

默认情况下，我们会挂载本地的 superset-frontend 文件夹， 并运行 npm install 以及 npm run dev，这会触发 webpack 去编译/打包前端代码。 根据你的本地配置，特别是如果内存小于 16GB，这些操作可能会非常慢。 在这种情况下，我们建议你将环境变量 BUILD_SUPERSET_FRONTEND_IN_DOCKER 设置为false， 并在本地终端中运行这些命令。只需触发 npm i && npm run dev，这样应该会快得多。

Option #2 - 从本地分支构建一系列不可变的镜像

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

Option #3 - 启动官方发布的版本

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

在这里，不同的发布标签、github 的 SHA 值， 以及最新的 master 分支都可以通过环境变量 TAG 来引用。 请参考与 docker 相关的文档，了解更多关于可以从 Docker Hub 指向的现有标签信息。

docker-compose 小贴士 & 配置

caution

属于Superset实例的所有内容 - 图表、仪表板、用户等 - 都存储在其元数据数据库中。 在生产环境中，这个数据库应该进行备份。 使用 docker compose 的默认安装会将这些数据存储在一个位于 Docker volume中的 PostgreSQL 数据库里， 但这个 volume 本身是不会被备份的。

再次强调，切勿将此用于生产环境

你应该能看到来自机器上启动容器的日志输出流。一旦输出变慢，你应该已经在本地机器上运行了一个 Superset 实例！ 为了避免将来运行时出现大量的文本输出，可以在 docker compose up 命令末尾添加 -d 选项。

进一步配置

以下是为那些想要配置 Superset 在 Docker Compose 中如何运行的用户准备的； 否则，你可以跳过本节直接进入下一节。

你可以通过遵循 docker/README.md 中提到的步骤来安装额外的 python 包并应用配置覆盖。

请注意，docker/.env 设置了 docker-compose 使用的所有 docker 镜像的默认环境变量， 而 docker/.env-local 可以用来覆盖这些默认值。 还需注意，docker/.env-local 在我们的 .gitignore 中有引用，防止开发人员不小心将潜在敏感的配置提交到仓库中。

一个重要的变量是 SUPERSET_LOAD_EXAMPLES， 它决定了 superset_init 容器是否会将示例数据和可视化加载到元数据数据库中。 这些示例有助于学习和测试 Superset，但对于有经验的用户和生产部署来说并非必要。 加载过程有时会花费几分钟时间并消耗大量 CPU 资源，因此在资源受限的设备上，你可能希望禁用它。

对于更高级或动态的配置，这些配置通常在 PYTHONPATH 下的 superset_config.py 文件中管理， 需要注意的是，可以通过提供一个 docker/pythonpath_dev/superset_config_docker.py 文件来实现， 这个文件会被 git 忽略（防止你将本地配置提交/推送回仓库）。 这一机制在 docker/pythonpath_dev/superset_config.py 中实现， 你可以看到其中的逻辑会运行 from superset_config_docker import *。

note

用户经常需要从 Superset 连接到其他数据库。 目前，最简单的方法是修改 docker-compose-non-dev.yml 文件， 将你的数据库作为一个服务添加进去，让其他服务依赖于它（通过 x-superset-depends-on）。 其他人尝试在 Superset 服务上设置 network_mode: host， 但这通常会导致安装失败，因为配置要求使用 Docker Compose 的 DNS 解析器来解析服务名称。 如果你有好的解决方案，请告诉我们！

note

Superset 使用 Scarf Gateway 来收集遥测数据。 了解不同 Superset 版本的安装数量有助于项目做出关于修补和长期支持的决策。 Scarf 会清除个人可识别信息（PII），仅提供聚合统计信息。

若要选择不参与通过 Scarf Gateway 由你的基于 docker compose 的安装下载的软件包的数据收集， 你应编辑 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 一起提供的示例数据集。 你现在可以通过访问 http://localhost:8088 在浏览器中访问 Superset。 请注意，许多浏览器现在默认使用 https；如果你的浏览器也是这样，请确保它使用的是 http。

使用默认的用户名和密码登录：

username: admin

password: admin

4. 将 Superset 连接到你的本地数据库实例

当使用 docker 或 docker compose 运行 Superset 时， 它会在自己的 docker 容器中运行，就像 Superset 在完全独立的机器上运行一样。 因此，试图使用主机名 localhost 连接到你的本地数据库将不会成功， 因为 localhost 指的是 Superset 正在运行的 docker 容器， 而不是你实际的主机。幸运的是，docker 提供了一种简单的方法， 可以在容器内部访问主机上的网络资源，我们将利用这种能力来连接到我们的本地数据库实例。

这里的指导是关于如何从运行在 docker 容器中的 Superset 连接到在你的主机上运行的 postgresql。 其他数据库可能有略微不同的配置，但大体思路相同，归结为以下两个步骤：

1. (Mac用户可以跳过此步骤) 配置本地的 postgresql/数据库实例以接受公共传入连接。 默认情况下，postgresql 只允许来自 localhost 的传入连接， 在 Docker 环境下，除非你使用 --network=host， 否则 localhost 将分别指向主机上的不同端点和 docker 容器。 让 postgresql 接受来自 Docker 的连接涉及对 postgresql.conf 和 pg_hba.conf 文件进行一行更改； 你可以在网上轻松找到针对你的操作系统/PG 版本的有用链接完成这项任务。 对于 Docker，只需将 IP 白名单设置为 172.0.0.0/8 即可，而不是 *， 但在任何情况下，你都被告知，在生产数据库中这样做可能会产生灾难性的后果， 因为你正在将数据库开放给公共互联网。

2. 在尝试连接到数据库时，不要使用 localhost， 而是尝试使用 host.docker.internal（Mac用户，Ubuntu）或 172.18.0.1（Linux用户）作为主机名。 这是 Docker 内部的一个细节——在 Mac 系统中，Docker Desktop 为 host.docker.internal 创建了一个DNS条目， 解析为主机的正确地址，而在 Linux 中则不是这种情况（至少默认情况下不是）。 如果这两个主机名都无法工作，那么你可能需要找到你想要使用的精确主机名， 为此，你可以执行 ifconfig 或 ip addr show，查看 docker0 接口的 IP 地址， 这个接口应该是 Docker 为你创建的。或者，如果你甚至看不到 docker0 接口，尝试（如果需要的话，使用 sudo）docker network inspect bridge， 看看是否有 "Gateway" 条目，并记下 IP 地址。