试用deepmodeling/dflow和一些配置的细节
如果手头有很多复杂的计算环境,或是有服务性质的计算能力伸缩需求,可以考虑使用建立在 kubernetes 上的 argoflow,来保证计算工作流程的标准化和可持续交付。
kubernetes
可以将 kubernetes 视为 HPC 集群的计算管理节点,但其调度的不是一个个 node,而是以各类方式运行的 container,即容器。此类容器服务在一些云服务商处表现为弹性伸缩和以秒为粒度的计费,并且有极强的丰富性,能够灵活地扩容和缩容来控制成本。
在个人电脑(Win)上可以利用 docker desktop 自带的 kubernetes 来使用 kubernetes 的组件,如果要配置,可以尝试借助https://github.com/AliyunContainerService/k8s-for-docker-desktop 提供的脚本,但要注意使用自己 docker desktop 对应的版本,通常直接由 docker desktop 进行 pull 和配置就没有问题。 kubernetes 主要依赖于如图的一些 image 来运行,docker desktop 会下载相应的 image。
当然,可以通过配置 Docker Engine 中的 registry-mirrors 来更快地配置,此处略去。
kubernetes 的一些概念
kubectl
kubectl 是 kubernetes 运行后的命令行管理工具,重要的命令有:
1 | kubectl get [node/pod/....] |
用于列出当前 kubernetes 集群中的节点、pod(调度的最小单元,是【一组】容器)。需要注意,在创建时会存在命名空间(namespace)的概念,pod 与此相关,使用时需要加上-n [namespace_name]
对于初学者用不到其他的命令(逃
容器
可以看作是虚拟机,它从镜像启动,并可以为其分配启动时对应的一些资源,由 docker 等具体的执行工具调用和管理。
image
镜像,也就是一个个精心准备好的虚拟机文件,初始化和分配资源后就成了一个个容器。image 可以在 dockerhub 等处找到,比如 intelopenapi 的 image 环境、cudart+cudnn 的环境等,可以快速地启动(很多不同功能的)虚拟机。
其他的不重要(
部署 dflow
部署 argoflow
如果是中国大陆地区用户,请注意 deepmodeling/dflow 的 argoflow 配置文件使用了一个连接不稳定的 registry,建议使用 aliyun 等的 registry-mirrors,并配合修改 yaml 文件中的 registry。(当然实际上可以自己 pull 好 hash 一致的 image,docker 会跳过 pull)
以 dflow 提供的快速配置文件( https://github.com/deepmodeling/dflow/blob/master/manifests/quick-start-postgres.yaml )为例,
主要是启动了 argoserver、httpbin、minio、postgres、workflow-controller,pull 了如图所示的 argocli、argoexec、workflow-controller 和 minio、postgres 等 image。
然后注意通过 kubectl 暴露这些容器的端口以便访问 UI 和 io:
1 | kubectl -n argo port-forward deployment/argo-server 2746:2746 |
如果端口被占用,可以修改为 2747:2746 等,后一个由 yaml 确定,请记住前一个,以便 dflow 运行使用。
部署 dflow
dflow 只是一个 python 包,通过封装 argo.workflows 实现一些功能。
如果 kubernetes 已经按上述方式配置完毕,并启动了端口转发(映射),配置 conda/pipenv 环境,pip 安装 dflow 即可:
1 | pip install pydflow |
小声:一人血书 conda 包(1/∞)。
然后可以尝试运行 test_steps.py ( https://github.com/deepmodeling/dflow/blob/master/examples/test_steps.py )。注意:如果此前修改了端口号,应对应修改其中的第 28 行:
1 | wf = Workflow(name="steps") |
为:
1 | wf = Workflow(name="steps",host="https://127.0.0.1:2747") |
以及60行:
download_artifact(step.outputs.artifacts[“bar”])
为
1 | download_artifact(step.outputs.artifacts["bar"],endpoint="127.0.0.1:9000") |
执行python脚本,即可在argo的ui localhost:{你的argo-server端口号}
下看到flow:
点进去有细节:
如果执行失败,也会有对应的显示,如:
dflow的主要功能模块
(为了方便理解,我自己分的)
- workflow manager(Workflow类),以argoflow配置(地址、端口、命名空间等)作初始化
- Template类:细粒度地控制任务镜像和命令。
- Step类,每个flow步骤的最小单元,以template、dag等进行配置。
- I/O(upload_artifact、download_artifact)略(注意启动minio)
其他的类看起来想不明白怎么用_(:з)∠)_因为写起来有点反人类,循环和条件重试很难阅读,希望能有方便的UI来构建flow。
(所以还是小声地回去用自己魔改的dpdispatcher了,逃