部署注意事项
目录
部署注意事项¶
得益于开源社区的努力，现在有工具可以将 Dask 部署到几乎任何地方——如果你能让计算机互相通信，你很可能就能将它们变成一个 Dask 集群。
然而，让 Dask 运行起来通常不是最后一步，而是第一步。本文档试图涵盖在管理 Dask 部署时，您可能需要考虑的Dask 之外的一些事项。
当为团队或组织管理 Dask，或将 Dask 用于生产（自动化）用途时，这些挑战尤其相关，但对于在分布式系统上使用 Dask 的个人用户来说，许多挑战也会出现。
一致的软件环境¶
为了 Dask 正常运行，调度器和工作节点上需要安装与客户端上相同的 Python 包集合，且版本一致。在多台机器上部署 Dask 时，最常见的障碍之一是保持集群上安装的软件与客户端上的软件同步更新，特别是如果它们运行在不同的系统上（例如，笔记本电脑和云提供商）。有关可能的解决方法，请参阅管理环境。
一些保持环境一致的方法可能还需要额外的基础设施。例如，在云部署中常用 Docker 镜像，但这需要一个地方来存储镜像，例如 DockerHub、AWS ECR、GCP Container Registry 等。随着使用成熟，您还会希望对 Dockerfile 进行版本控制，并在其更改时使用 CI/CD 系统（如 GitHub Actions、Google Cloud Build 或其他）自动构建和发布新镜像。
当为多个用户管理 Dask 时，软件环境可能尤其具有挑战性。有时，对团队来说，使用一套固定的包就足够了，但个人通常需要不同的包，或相同包的不同版本（包括 Dask 本身！），才能提高工作效率。在这些情况下，您可能最终会让终端用户访问构建系统（例如，要求他们自己构建和维护 Docker 镜像），或者如果您的组织不允许这样做，则需要创建自定义基础设施，或采用变通方法，如 PipInstall 或 UploadDirectory 插件。
额外的挑战可能包括将本地包或脚本传输到集群上（并确保它们是最新的），以及从私有 Git 或 PyPI 仓库安装的包。
无需额外基础设施的环境管理选项
PipInstall插件Coiled 的软件包同步功能可自动将本地环境复制到集群上，包括本地包和 Git 依赖项。
日志记录¶
当集群发生故障时，日志可能是唯一的调试工具。至少，您应该有办法保留集群中所有机器的日志。您可能还希望将这些日志导入专用的日志系统，以便您可以搜索日志，或按时间交错查看来自多个系统的日志。（如果在云提供商上部署，这可能已经由提供商的日志系统为您设置好了，但请注意日志存储可能会产生费用。）
当为团队管理 dask 时，您还需要弄清楚个人用户（可能是技术经验较少的用户）如何访问他们自己的集群的日志和指标。在大型组织中，这甚至可能包括阻止用户访问其他用户集群的日志。
在集群上获取凭据¶
您的笔记本电脑可能有权连接到 S3 存储桶或数据库，但这取决于您的集群如何部署，工作节点可能没有。这可能导致在本地正常工作的代码在集群上运行时因身份验证错误而失败。有关这方面的更多讨论，请参见连接到远程数据页面。
特别是当团队使用时，成熟的 Dask 部署会希望避免用户在代码中直接将自己的凭据传递给集群，而是采用诸如为用户生成临时令牌、使用服务账户对工作节点进行身份验证等策略。
控制访问¶
大多数非商业部署库依赖于启动集群的用户对集群运行的基础系统（例如云提供商、HPC 集群、Kubernetes 等）具有访问权限。在启用团队使用 Dask 时，情况可能并非如此：您希望允许用户按需启动集群，这可能会创建云虚拟机或 Kubernetes Pod，而无需实际授予他们直接创建云虚拟机或 Kubernetes Pod 的权限。Dask-gateway 是实现此目的的一种常见方法，但这确实需要额外的管理工作。
大多数 Dask 部署选项设置了合理的访问默认值（例如，不让您的集群对互联网上的任何人可见），但您仍然应该确保您的集群（或您的用户的集群）不会被未经授权的用户访问。
此外，如果您通过互联网连接到集群，应确保连接是加密的，因为敏感信息（如凭据或专有数据）可能通过它传输。您可以通过 SSH 进行端口转发、使用 TLS，或使用 Dask-gateway 或能够自动管理此事的商业服务来实现。
控制成本¶
很容易忘记关闭集群，导致周末产生高昂的账单。一些部署库也可能并非总能完全清理集群——例如，如果客户端 Python 进程（或机器！）突然关闭，dask-cloudprovider 不会清理云资源。
因此，在生产环境中自动启动集群，或允许许多团队成员启动集群时，您应该确保所有资源都将被清理，或在超出成本阈值时关闭。
当为团队管理 Dask 时，您可能还希望有一种方法来限制个人用户的支出，以防止意外超支。
监控成本¶
能够回答诸如以下问题很有益处：
我们在 Dask 上花费了多少钱？
钱花在了哪里？（机器、本应关闭的机器、不应发生的网络出口流量等）
谁/什么负责？
大多数部署工具没有内置这种监控功能。需要它的组织要么自己构建工具，要么转向商业部署服务。
管理网络¶
Dask 客户端需要能够与调度器通信，而调度器可能位于不同的系统上。用户希望能够通过 Web 浏览器访问仪表板。集群中的机器需要能够互相通信。通常，您使用的部署系统会为您处理这些问题。然而，有时可能需要考虑使用哪种类型的网络以获得最佳性能。网络也可能产生相关成本——例如，云提供商可能会对某些类型的网络配置收取固定费用或按用量收费。
您可能还有其他系统位于受限网络中，工作节点需要访问这些网络才能读写数据或调用 API。连接到这些网络可能会增加额外的复杂性。
一些组织可能有额外的网络安全策略，例如要求所有流量必须加密。Dask 支持使用 TLS 实现这一点。一些部署系统会使用自签名证书自动启用此功能；其他系统可能需要额外的配置，尤其是在使用组织内部证书的情况下。
可观测性¶
仪表板是监控实时集群的强大工具。但是一旦集群停止（或崩溃），仪表板就会消失，因此记录比集群持续时间更长的数据对于调试至关重要。这在运行自动化作业时尤为重要。
Dask 提供Prometheus 指标，它提供接近仪表板级别的详细信息，并且可以在集群关闭很久后仍然存在，这使得它们对于监控和调试生产环境特别有价值。它们也可以聚合，这对于同时运行许多集群很有帮助，甚至可以用来触发自动警报。使用这些指标需要部署和管理 Prometheus（或 Prometheus 兼容的服务），配置网络使其能够访问集群中的机器，并且通常还需要部署 Grafana 来可视化指标并创建仪表板。
将本地数据存储在本地机器之外¶
如果您在集群上部署 Dask，大多数数据可能已经远程存储，因为部署 Dask 而不是本地运行的主要原因之一是让工作节点更接近数据。但是，通常也会有一些较小的辅助数据文件在本地。
在这种情况下，您可能需要一个地方来远程存储这些辅助文件，以便工作节点可以访问它们。根据您的部署系统，有许多选项，从网络文件系统到云对象存储（如 S3）。无论如何，这都可能成为需要管理和保护的另一项基础设施。
关于托管 Dask 服务的说明¶
如前所示，设置和管理成熟的 Dask 部署，特别是针对团队或生产用途，可能涉及 Dask 本身之外的大量复杂性。解决这些挑战通常超出开源 Dask 部署工具的范围，但也有其他项目以及处理许多这些注意事项的商业 Dask 部署服务。按字母顺序排列如下：
Coiled 负责在云计算环境（AWS、Azure 和 GCP）中创建和管理 Dask 集群。
Saturn Cloud 允许用户在托管平台或其自己的 AWS 账户中创建 Dask 集群。