fnndsc/pman

!https://github.com/FNNDSC/ChRIS_ultron_backEnd/blob/master/docs/assets/logo_chris.png pman

https://github.com/FNNDSC/pman/actions/workflows/ci.yml/badge.svg](https://github.com/FNNDSC/pman/actions/workflows/ci.yml)

[!CAUTION] pman 已被弃用并集成到 https://github.com/FNNDSC/pfcon%E3%80%82

pman（曾代表process manager，流程管理器）是一个Flask应用程序，提供API用于通过各种调度器（如Kubernetes、Podman、Docker Swarm和SLURM）创建作业。它基本上将自身的JSON接口转换为对各种支持的后端的请求。

pman 与https://github.com/FNNDSC/pfcon%E7%B4%A7%E5%AF%86%E8%80%A6%E5%90%88%E3%80%82_pman_ 和 pfcon 通常作为一对部署，提供 pfcon 服务。

运行 pman

查看其实际运行的最简单方法是运行https://github.com/FNNDSC/miniChRIS-docker%E3%80%82%E4%BB%A5%E4%B8%8B%E8%AF%B4%E6%98%8E%E9%80%82%E7%94%A8%E4%BA%8E_pman_%E7%9A%84%E9%BB%91%E5%AE%A2%E5%92%8C%E5%BC%80%E5%8F%91%E4%BA%BA%E5%91%98%E3%80%82

开发

本节描述如何设置本地_pman_实例进行开发。

使用Docker Compose

这些说明使用Docker和Docker Swarm在容器内运行_pman_以调度作业。启用代码更改的热重载。

shell
docker swarm init --advertise-addr 127.0.0.1
docker compose up -d

使用Docker Swarm

要使用docker stack deploy运行完整测试，请运行测试工具test_swarm.sh。

shell
./test_swarm.sh

使用Podman进行开发

_pman_必须能够通过与Podman套接字通信来通过Podman调度容器。

shell
systemctl --user start podman.service
export DOCKER_HOST="$(podman info --format '{{ .Host.RemoteSocket.Path }}')"

使用Python安装_pman_

shell
python -m venv venv
source venv/bin/activate
pip install -r requirements/local.txt
pip install -e .

使用Python在开发模式下运行_pman_

shell
python -m pman

使用Kind通过Kubernetes

https://github.com/FNNDSC/pman/wiki/Development-Environment:-Kubernetes

配置

_pman_通过环境变量进行配置。有关其确切工作方式，请参阅pman/config.py中的源代码。

存储如何工作

_pman_依赖_pfcon_在称为"storeBase"的目录中管理数据。"storeBase"是集群中每个节点都可见的存储空间。

对于使用Docker和Podman的单机部署，最佳解决方案是使用由_pfcon_挂载在/var/local/storeBase的本地卷。_pman_应配置为STORAGE_TYPE=docker_local_volume VOLUME_NAME=...。

在Kubernetes上，应使用单个PersistentVolumeClaim。它由_pfcon_挂载在/var/local/storeBase。_pman_应配置为STORAGE_TYPE=kubernetes_pvc VOLUME_NAME=...。

SLURM没有卷的概念，但SLURM集群通常使用在每个节点上相同路径挂载的NFS共享。_pman_应配置为STORAGE_TYPE=host STOREBASE=...，将共享挂载点指定为STOREBASE。

swarm 与 docker 的比较

最初，_pman_与Docker Swarm API交互是为了支持多节点集群。然而，_pman_通常在单机上运行。开发环境、单机生产部署的CUBE的"主机"计算资源以及Power9超级计算机上的CUBE生产部署都是这种情况。Swarm模式主要是一种麻烦，其多节点能力测试不足。此外，多节点功能更好地由CONTAINER_ENV=kubernetes提供。

在_pman_ v4.1中，CONTAINER_ENV=docker作为新功能引入并成为默认配置。在此模式下，_pman_使用Docker Engine API而不是Swarm API，这对于单机用例更加方便。

Podman支持

CONTAINER_ENV=docker与Podman兼容。

已知Podman版本3或4可以工作。

无根Podman

配置用户能够设置资源限制。

https://github.com/containers/podman/blob/main/troubleshooting.md#symptom-23

环境变量

STOREAGE_TYPE=host

当STORAGE_TYPE=host时，将STOREBASE指定为主机上的挂载点路径。

STOREAGE_TYPE=docker_local_volume

对于单机实例，使用Docker/Podman本地卷作为"storeBase"。卷应在_pman_启动之前存在。可以通过以下两种方式之一识别它：

• 手动，通过将卷名传递给变量VOLUME_NAME
• 自动：_pman_检查带有标签org.chrisproject.role=pfcon的容器，并选择绑定到/var/local/storeBase的挂载点

STORAGE_TYPE=kubernetes_pvc

当STORAGE_TYPE=kubernetes_pvc时，VOLUME_NAME必须是配置为ReadWriteMany的PersistentVolumeClaim的名称。

在卷仅对特定UNIX用户可写的情况下（例如NFS支持的卷），CONTAINER_USER可用作解决方法。

Kubernetes特定选项

当CONTAINER_ENV=kubernetes时适用

SLURM特定选项

当CONTAINER_ENV=cromwell时适用

有关其工作原理，请参见https://github.com/FNNDSC/pman/wiki/Cromwell

容器用户安全

设置任意容器用户（例如CONTAINER_USER=123456:123456）可提高安全性，但会导致（不安全编写的）_ChRIS_插件失败。在某些情况下，ENABLE_HOME_WORKAROUND=yes可以使插件工作而无需更改其代码。

可以使用随机容器用户CONTAINER_USER=1000000000-2147483647:1000000000-2147483647，但考虑到pfcon的UID永远不会更改，这将导致一切中断。

缺失功能

_pman_的配置多年来变得混乱，因为它试图提供跨截然不同系统的接口。某些选项的混合搭配不受支持：

• IGNORE_LIMITS=yes仅适用于CONTAINER_ENV=docker（或podman）。
• JOB_LABELS=...仅适用于CONTAINER_ENV=docker（或podman）和CONTAINER_ENV=kubernetes。
• CONTAINER_USER不适用于CONTAINER_ENV=cromwell
• CONTAINER_ENV=cromwell不转发环境变量。
• STORAGE_TYPE=host不支持Kubernetes

待办事项

• Kubernetes和SLURM的开发环境和测试。