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