Executors
在Nextflow框架体系结构中，执行器是确定管道进程运行的系统并监督其执行的组件。
执行器提供了管道进程和底层执行系统之间的抽象。这允许您编写独立于实际处理平台的管道函数逻辑。
换句话说，只需更改Nextflow配置文件中的执行器定义，就可以编写管道脚本，并让它在计算机、集群资源管理器或云上运行。
Local
默认情况下使用本地执行器。它在启动Nextflow的计算机中运行管道进程。这些进程通过生成多个线程和利用CPU提供的多核架构来实现并行化。
在一个常见的使用场景中，本地执行器对于在计算机中开发和测试管道脚本非常有用，当需要在生产数据上运行它时，可以切换到集群设施。
SGE
SGE执行器允许你通过使用Sun Grid Engine集群或兼容平台(Open Grid Engine, Univa Grid Engine等)来运行管道脚本。
Nextflow通过使用qsub命令将每个进程作为单独的网格作业来管理，并将其提交给集群。
因此，管道必须从qsub命令可用的节点启动，也就是说，在常见的使用场景中，从集群头节点启动。
要启用SGE执行器，只需将其设置为process。Executor属性在下一个流中更改sge值。配置文件。
每个作业提交请求的资源数量由以下进程指令定义:
LSF
LSF执行器允许您使用平台LSF集群来运行管道脚本。
Nextflow通过使用bsub命令将每个进程作为提交到集群的独立作业来管理。
因此，管道必须从bsub命令可用的节点启动，也就是说，在常见的使用场景中，从集群头节点启动。
要启用LSF执行器，只需将其设置为process.Executor属性设置为下一个流中的lsf值。配置文件。
每个作业提交请求的资源数量由以下进程指令定义:
Note
LSF支持每个核和每个作业的内存限制。Nextflow假设LSF工作在每核内存限制模式下，因此它将请求的内存除以请求的cpu数量。当LSF被配置为在每个作业内存限制模式下工作时，这不是必需的。您需要指定在Nextflow配置文件的Scope执行器中添加
perJobMemLimit选项。当LSF被配置为在每个作业内存限制模式下工作时，这不是必需的。您需要指定在Nextflow配置文件的Scope执行器中添加perJobMemLimit选项。See also the Platform LSF documentation.
SLURM
SLURM执行器允许您使用SLURM资源管理器来运行管道脚本。
Nextflow通过使用sbatch命令将每个进程作为提交到集群的独立作业来管理。
因此，管道必须从可用sbatch命令的节点启动，即在常见使用场景中，从集群头节点启动。
要启用SLURM执行程序，只需将process.executor属性设置为nextflow.config文件中的 slurm值。
每个作业提交请求的资源数量由以下进程指令定义:
Note
可以将SLURM分区视为作业队列。Nextflow允许您使用上面的queue指令来设置分区。
Tip
Nextflow不提供对SLURM多集群特性的直接支持。如果需要将工作流执行提交给不是当前的集群，可以在启动环境中设置SLURM_CLUSTERS变量来指定它。
PBS/Torque
PBS执行器允许您使用属于批处理调度程序PBS/Torque系列的资源管理器来运行管道脚本。
Nextflow通过使用调度程序提供的qsub命令，将每个进程作为提交到集群的独立作业来管理。因此，管道必须从qsub命令可用的节点启动，也就是说，在常见的使用场景中，从集群登录节点启动。
要启用PBS执行程序，只需在nextflow.config文件中设置属性process.executor = 'pbs'。
每个作业提交请求的资源数量由以下进程指令定义:
PBS Pro
PBS Pro执行器允许您使用PBS Pro资源管理器来运行管道脚本。
Nextflow通过使用调度程序提供的qsub命令，将每个进程作为提交到集群的独立作业来管理。因此，管道必须从qsub命令可用的节点启动，也就是说，在常见的使用场景中，从集群登录节点启动。
要启用PBS Pro执行器，只需在nextflow.config文件中设置属性process.executor = 'pbspro'。
每个作业提交请求的资源数量由以下进程指令定义:
Moab
Moab执行器允许您通过Adaptive Computing使用Moab资源管理器来运行管道脚本。
Warning
这是一个正在酝酿的特性。在未来的Nextflow版本中可能会更改。
Nextflow使用资源管理器提供的msub命令，将每个进程作为提交到集群的独立作业进行管理。因此，管道必须从可以使用msub命令的节点启动，即在通用使用场景中，计算集群登录节点。
要启用Moab执行器，只需在nextflow.config文件中设置属性process.executor = 'moab'。
每个作业提交请求的资源数量由以下进程指令定义:
NQSII
NQSII执行器允许您使用NQSII资源管理器来运行管道脚本。
Nextflow通过使用调度程序提供的qsub命令，将每个进程作为提交到集群的独立作业来管理。因此，管道必须从qsub命令可用的节点启动，也就是说，在常见的使用场景中，从集群登录节点启动。
要启用NQSII执行器，只需在nextflow.config文件中设置属性process.executor = 'nqsii'。
每个作业提交请求的资源数量由以下进程指令定义:
HTCondor
HTCondor执行器允许您使用HTCondor资源管理器来运行管道脚本。
Warning
这是一个正在酝酿的特性。在未来的Nextflow版本中可能会更改。
Nextflow通过使用condor_submit命令将每个进程作为提交到集群的独立作业来管理。因此，管道必须从condor_submit命令可用的节点启动，即在常见的使用场景中，从集群头节点启动。
Note
此时，Nextflow的HTCondor执行器不支持HTCondor将输入/输出数据传输到相应作业计算节点的能力。因此，计算节点需要使用共享文件系统目录来访问数据，Nextflow工作流必须从该目录执行(或通过-w选项指定)。
要启用HTCondor执行器，只需将process.executor属性设置为nextflow.config文件中的condor值。
每个作业提交请求的资源数量由以下进程指令定义:
Ignite
Ignite执行器允许您使用嵌入Nextflow运行时的Apache Ignite集群技术来运行管道。
要启用Ignite执行器，只需在nextflow.config文件中设置属性process.executor = 'ignite'。
每个任务提交所请求的资源数量由以下进程指令定义:
Note
阅读Apache Ignite一节，了解如何配置Nextflow以在基础设施中部署和运行Ignite集群。
Kubernetes
Nextflow提供了对Kubernetes集群技术的内置支持。它允许您在Kubernetes集群中部署和透明地运行Nextflow管道。
下面的指令可以用来定义所需的计算资源数量和要使用的容器:
请参阅Kubernetes文档了解如何在Kubernetes集群中部署工作流执行。
AWS Batch
Nextflow支持AWS批处理服务，该服务允许在云中提交作业，而无需剥离和管理虚拟机集群。AWS Batch使用Docker容器来运行任务，这使得部署管道更加简单。
管道进程必须通过在管道脚本或nextflow.config文件中定义容器指令来指定要使用的Docker映像。
要启用此执行程序，请在nextflow.config文件中设置属性process.executor = 'awsbatch'。
管道可以在本地计算机或EC2实例中启动。后者建议用于繁重或长时间运行的工作负载。此外，S3桶必须用作管道工作目录。
有关进一步的配置细节，请参阅AWS Batch页面。
Azure Batch
Nextflow支持Azure Batch服务，该服务允许在云中提交作业，而无需剥离和管理虚拟机集群。Azure Batch使用Docker容器来运行任务，这使得部署管道更加简单。
管道进程必须通过在管道脚本或nextflow.config文件中定义容器指令来指定要使用的Docker映像。
要启用此执行程序，请在nextflow.config文件中设置属性 process.executor = 'azurebatch'。
管道可以在本地计算机或云虚拟机中启动。后者建议用于繁重或长时间运行的工作负载。此外，必须使用Azure Blob存储容器作为管道工作目录。
更多的配置细节，请参阅Azure Batch页面。
Google Life Sciences
Google Cloud Life Sciences是一个托管计算服务，允许在谷歌云平台基础设施中执行容器化的工作负载。
Nextflow提供了对生命科学API的内置支持，允许在云中无缝部署Nextflow管道，将流程执行卸载为管道(它需要Nextflow 20.01.0或更高版本)。
管道进程必须通过在管道脚本或 nextflow.config 文件中定义容器指令来指定要使用的 Docker 映像。 此外，管道工作目录必须位于 Google Storage 存储分区中。
要启用此执行程序，请在nextflow.config文件中设置属性process.executor = 'google-lifesciences'。
有关更多配置详细信息，请参阅 Google Life Sciences页面。
GA4GH TES
Warning
这是一个实验性的特性，在未来的版本中可能会改变。它需要Nextflow版本0.31.0或更高版本。
GA4GH标准化活动发起的任务执行模式(TES)项目致力于定义一个标准化的模式和API，以可移植的方式描述批执行任务。
Nextflow包括对TES API的实验性支持，它提供了一个TES执行器，允许将工作流任务提交到远程执行后端，以暴露TES API端点。
要使用该特性，请在工作流启动环境中定义以下变量:
export NXF_MODE=ga4gh
export NXF_EXECUTOR=tes
export NXF_EXECUTOR_TES_ENDPOINT='http://back.end.com'
很重要的一点是，端点的指定不带末尾斜杠;否则，生成的url将不会被规范化，对TES的请求将会失败。然后，您将能够使用常见的Nextflow命令行在TES上运行工作流。确保指定要使用的Docker映像，例如:
nextflow run rnaseq-nf -with-docker alpine
Note
如果省略变量NXF_EXECUTOR_TES_ENDPOINT，则默认端点为http://localhost:8000。
已知的限制:
OAR
OAR执行器允许您使用OAR资源管理器来运行管道脚本。
Nextflow通过使用oarsub命令将每个进程作为一个单独的作业提交给集群。因此，管道必须从可使用oarsub命令的节点启动，即在常见的使用场景中，从集群头节点启动。
要启用OAR执行程序，只需将process.executor属性设置为nextflow.config文件中的oar值。
每个作业提交请求的资源数量由以下进程指令定义:
已知的限制:
- clusterOptions应该给出，如果多于一个，用分号分隔。它确保准确格式化OAR批处理脚本。
clusterOptions = '-t besteffort;--project myproject'
