部署注意事项
内容
部署注意事项¶
得益于开源社区的努力，有工具可以将 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 或一个自动管理此功能的商业产品来实现这一点。
控制成本¶
忘记关闭集群并在周末产生昂贵的账单很容易。一些部署库也可能无法始终完全清理集群——例如，dask-cloudprovider 如果在客户端 Python 进程（或机器！）突然关闭时不会清理云资源。
因此，在生产环境中自动启动集群，或让许多团队成员启动它们时，您应该确信所有资源将被清理，或者如果它们超过成本阈值，将被关闭。
在团队管理Dask时，您可能还希望限制单个用户可以花费的金额，以防止意外超支。
监控成本¶
能够回答以下问题是非常好的：
我们在Dask上花费了多少？
我们在什么上花钱？（机器，本应关闭的机器，本不应发生的网络出口等。）
谁/什么是负责的？
大多数部署工具不内置这种监控功能。需要此功能的组织要么最终构建自己的工具，要么转向商业部署产品。
管理网络¶
Dask 客户端需要能够与调度器通信，调度器可能位于不同的系统上。用户喜欢能够从 Web 浏览器访问 仪表板。集群中的机器需要能够相互通信。通常，无论您使用哪种 部署系统，都会为您处理这个问题。不过，有时可能会有关于使用哪种网络以获得最佳性能的额外考虑。网络也可能产生相关成本——例如，云提供商可能会对某些类型的网络配置收取固定或基于使用量的费用。
您可能还有其他系统位于受限网络中，工作人员需要访问这些系统以读取和写入数据，或调用API。连接到这些网络可能会增加额外的复杂性。
一些组织可能有额外的网络安全策略，例如要求所有流量都进行加密。Dask 通过 TLS 支持这一点。一些部署系统使用自签名证书自动启用此功能；其他系统可能需要额外的配置，特别是如果使用来自组织的证书。
可观测性¶
The dashboard 是一个用于监控实时集群的强大工具。但是一旦集群停止（或崩溃），仪表板就会消失，因此记录比集群更持久的信息对于调试来说是无价的。这在运行自动化作业时尤为重要。
Dask 提供 Prometheus 指标，这些指标提供了接近仪表板级别的详细信息，但在集群关闭后仍能持久存在，因此对于监控和调试生产环境中的临时解决方案特别有价值。它们还可以被聚合，这在同时运行多个集群时非常有用，甚至可以用来触发自动警报。使用这些指标需要部署和管理 Prometheus <https://prometheus.io>`_（或兼容 Prometheus 的服务），配置网络以便其能够访问集群中的机器，并且通常还需要部署 `Grafana 来可视化指标和创建仪表板。
将本地数据存储在本地机器之外¶
如果你在集群上部署Dask，大多数数据可能已经存储在远程位置，因为部署Dask而不是 本地运行 的主要原因之一是将工作进程运行在数据附近。然而，通常也可能有一些较小的本地辅助数据文件。
在这种情况下，您可能需要在远程存储这些辅助文件的地方，以便工作人员可以访问它们。根据您的部署系统，有许多选项，从网络文件系统到像S3这样的云对象存储。无论如何，这可能是另一项需要管理和保护的基础设施。
关于托管的 Dask 服务¶
如所示，设置和管理一个成熟的 Dask 部署，尤其是对于团队或生产用途，可能会涉及 Dask 本身之外的相当多的复杂性。解决这些挑战通常超出了开源 Dask 部署工具的范围，但还有其他项目以及处理这些考虑的商业 Dask 部署服务。按字母顺序排列：
Coiled 负责在云计算环境（AWS、Azure 和 GCP）中创建和管理 Dask 集群。
Saturn Cloud 允许用户在托管平台上或在其自己的 AWS 账户内创建 Dask 集群。