Apptainer_Singularity容器原理

Singularity容器技术是劳伦斯伯克利国家实验室开发专门用于高性能计算场景的容器技术（Slurm系统是劳伦斯利弗莫尔国家实验室研发），Singularity完全基于可移植性进行虚拟化，更加轻量级，部署更快，Singularity目前被广泛地各高性能计算中心。后由于Singularity项目加入Linux基金会，改名为Apptainer，以下还是按照原称即Singularity展开介绍。

Docker在HPC集群中的问题

在上篇Docker原理，简要介绍了容器以及Docker容器技术。但是可以设想这样一个场景，就是现在有一万台机器需要部署应用、同时有多个项目使用这些机器且项目的环境各不相同、为了提高资源的利用率需要弹性且自动化的去部署机器、面对可能存在的故障需要有较高的容错率…如果还是传统的一个一个去部署，不仅时间上成本高，后期维护也较为复杂，如果使用容器的话，就问题不大。
Docker与Singularity是两种常见的容器技术，Docker应用最为广泛，隔离性高，但是在大规模集群上并不适合，主要有以下几个方面：

• 资源限制问题：Slurm 利用 cgroups 实现资源分配，需要在配置文件中中进行细粒度的资源划分，可以参考以前整理的Slurm配置cgroup问题，Docker 通过Docker daemon无法实现资源限制，即调度管理器的资源限制无法施加到容器中
• 权限问题：Docker daemon守护进程使用 root 用户启动，HPC 场景期望使用普通用户运行容器，如Slurm普通用户也可以提交作业一样，不需要什么操作都需要root用户来管理
• 容器化方便应用批量部署和后期维护，但是Docker容器技术也包含了不必要的资源开销，如docker镜像有可能携带多余的文件导致镜像体积大，占用系统资源

集群中的资源使用通常需要由调度管理器来进行分配，例如Slurm/PBS/SGE等系统负责资源分配。调度管理器根据用户需求为每个作业分配一定的资源，实质上是利用cgroups针对每个作业进行配置实现的。而Docker镜像的启动实际上是由Docker Daemon去执行的，如此一来资源限制自然会失效。并且Docker Daemon是由 root 用户启动的，无论是为普通用户设置sudoer还是将普通用户添加到 docker 用户组中都不是一个安全的方式。

Singularity在HPC集群的优势

Singularity容器技术就是专门针对高性能计算场景的。因此解决了诸如Docker在大规模集群上的问题。具体优势有以下几种：

• 权限问题，singularity可以继承用户的权限，比如A用户使用的容器，只有A用户有权限进行操作
• singularity方便迁移，拉取镜像直接放到自己目录下，直接拷贝走镜像即可，且Singularity没有复杂的缓存机制，镜像已经过压缩，只需占用非常少的磁盘空间；而docker所有人的镜像都放在固定位置，虽然docker也可以打包拷贝走，但操作起来比较麻烦
• 和现有系统无缝整合：系统用户权限、网络等均直接继承宿主机配置，并且无需进入某个镜像后再执行命令，可以直接在外部调用镜像内的指令，就像执行一个本地安装的指令一样
• 不需运行 daemon守护进程：Singularity提供的完全是一个运行时的环境，在不使用时不需要单独的进程，软件安装到一个虚拟机文件中，随时启动，不占用任何资源。资源限制和权限问题也得以解决。
• 绑定目录的问题，docker每次运行都要绑定目录到容器中，非常麻烦，而singularity可以直接访问。
• 根据Singularity研发主管Gregory Kurtzer的说法，Singularity与GPU协同，非常适合与机器学习软件

除此之外，Singularity还具有启动迅速、资源开销小、轻松的迁移和扩展等优点，Singularity还支持多种镜像和容器文件格式，甚至可以直接使用 Docker 提供的镜像。Singularity可以轻易的现有的 HPC 系统整合，几乎无需任何额外的开发就能让现有的 HPC 变成一个轻量级的容器云。

从上图可以看到，虽然在构建镜像采用不同的规范，但是Docker的镜像是可以直接运行在Singularity容器中的，与Docker相比Singularity更有优势的一点在于，Singularity对于并行计算MPI的支持。

通过上图可以看到，在centOS中使用Singularity进行并行计算MPI的时延更低。
传统的HPC集群中，主要运行包括科学计算、气象仿真、流体仿真、等等，需要不同的专业软件。以生物信息分析为例。生物信息中的分析流程往往需要消耗很大的内存，读写以TB计算的数据，属于典型的高性能计算(HPC)应用。生物信息分析流程中要调用大量的分析程序以及内部开发脚本，环境的配置与管理极为复杂，可重复性低，导致流程的升级、管理、迁移成为大难题。

现有的技术中其实有解决以上问题的方法，如Docker。然而生物信息分析集群和普通的IT服务器又有很大区别，如开发人员无root权限，分析任务需要进行资源管理(内存，CPU)。这些问题都让Docker技术在HPC环境的应用受限，Singularity因此应运而生。Singularity通过封装应用为单一的可执行文件，实现了应用的方便迁移。

与其他容器比较，Singularity具有明显的优势

Singularity相关知识

结构

Singularity并不是围绕微服务进程隔离的概念而设计的。因此，它使用最小数量的namespace来实现其主要设计目标。与为完全隔离设计的容器平台相比，这为Singularity提供了更小的占用、更大的性能潜力和更容易的集成。但是也存在相应的缺点，在后文提到。通过封装好的库文件，singularity容器直接与内核进行交互，同时用户共享使用主机的相关资源，直接继承主机相关信息，使得singularity与现有系统无缝衔接。从架构图中也可以看到singularity可以直接访问主机的文件系统，而不是通过类似与docker mnt namespace的方式将目录挂载到容器里。
一个Singularity容器有几个文件，它们在运行时直接与该容器交互。这些文件及其描述如下：

• /singularity：包含用户指定脚本的文件，将在容器直接执行或通过“singularity run”命令时运行
• /.env/包含容器运行时源代码文件的目录。文件将按照约定XX−*，命名，其中XX表示描述优先级的两个数字（更高的数字具有更高的优先级），*表示任意字符串（例如01−singularity）
• Entrypoint：在调用相应的singularity命令时执行的脚本，并将额外的命令行参数传递到已执行的二进制文件中
  • /.exec：提供/.env/中的环境文件，并执行用户指定的命令
  • /.shell：在/.env中的环境文件，并执行/bin/sh
  • /.run：在/.env中的环境文件，并执行位于/singularity的运行脚本
• Header：每个singularity镜像都包含一个镜像标题
  • 镜像的SHA256哈希
  • 描述自上次singularity哈希操作以来，镜像是否已被修改
  • 描述镜像是否为静态状态（不可修改）。具有此位集的镜像将无法以可写模式运行
  • 镜像的结构
  • 与镜像关联的元数据

Singularity工作流

一般的工作流从一个终端上的开发转移到一个共享的计算资源（上图）。在左边部分，有一个由用户控制的终端。这是一个典型的笔记本电脑、工作站或服务器。在此空间中，用户可以根据需要创建、修改和更新一个容器。一旦创建了包含必要的应用程序、库和数据的容器，它就可以很容易地共享给其他主机，并在不需要访问根权限的情况下进行访问。再次对容器进行更改需要返回到具有根的端点系统，会将容器重新上载到共享资源。如果用户在其终端上没有根目录，则可以使用虚拟机开发singularity容器。

Singularity权限问题

使用容器不得不考虑安全性，安全性来自两个方面，一个是使用了不被信任的容器，这个就像你在电脑上安装了不被信任的软件一样，Singularity提供了签名机制来验证；另一方面是容器会不会越权对Host 做一些不该做的事情，这个是需要考虑的。
singularity 的解决办法是会在容器内动态创建一个用户，该用户与Host里的用户名、组名、权限等都保持一致。这样你在Host 中做不了的事情，在容器里也干不了。

Singularity镜像

singularity镜像有两种格式：sif格式可用于部署；sanbox格式是可写的文件系统，用于开发过程，方便根据需要修改其中的内容。两种格式之间相互转换，即开发完成后转换为sif。特性：

• 比如可在本地构建docker镜像，然后上传服务器使用singularity运行，从而避免使用root相关权限；
• Singularity镜像 中的文件可以直接在当前系统操作修改；但是通过shell 启动容器后，容器内是只读的文件系统，如果要在容器内修改，需要root 权限，且指定 -writable；
• 可直接在sandbox容器内创建环境，安装软件等；

Singularity Hub

singularity引导定义被提交并推送到一个GitHub存储库（名为“singularity”）。GitHub通过一个web钩子与singularity hub通信，并通过持续集成排队构建镜像。一旦构建，生成的镜像将存储在谷歌云中并可以访问。使用singularity hub示例如下：

$ singularity shell shub://$UNIQUE_ID
$ singularity run shub://$USER/$CONTAINER:$TAG

在HPC中使用Singularity潜在的问题

Singularity 的缺点在于，它对构建大型应用程序的复杂性有一定的限制，并且缺乏一些常见的高级功能，比如容器缓存，自动健康检查等。此外，Singularity 也没有完整的生态系统可支持其使用，这意味着用户可能需要编写大量自定义代码来解决特定的问题，这可能会增加开发时间和成本。Singularity 仍然是一个新技术，它可能存在一些尚未发现的潜在问题，需要谨慎考虑。
就目前而言，Singularity存在的问题集中在：

• 缺少网络虚拟化的支持
• 目前未实现 PID Namespace

Singularity应该是为了解决 HPC 环境下的软件不兼容而设计的应用容器，所以它并没有像Docker那样提供非常完善的隔离和虚拟化，例如没有 PID namespace 隔离、没有网络虚拟化。并且它的知名度远不如 Docker，社区支持较少，在国内也没有镜像源导致下载镜像速度非常慢甚至失败。在大规模使用Singularity的时候需要慎重。

参考：
1、Singularity介绍：http://t.csdn.cn/FigvE
2、Singularity官方文档：https://apptainer.org/docs
3、Singularity论文：https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5706697/pdf/pone.0188511.pdf
4、Singularity hub：https://singularityhub.com/