为什么HPC环境更推荐Singularity而非Docker？CentOS7.9实战安装教程

嗑着瓜子听你唠嗑

306人浏览 · 2026-02-27 04:04:38

嗑着瓜子听你唠嗑 · 2026-02-27 04:04:38 发布

为什么HPC环境更推荐Singularity而非Docker？CentOS7.9实战安装教程

如果你是一位在高性能计算集群上工作的研究员或系统管理员，可能已经对Docker的便利性深有体会，但也一定为它在共享环境中的权限问题头疼过。想象一下，你需要运行一个包含特定软件栈的生物信息学流程，Docker镜像似乎是完美的解决方案。但当你尝试在学校的超算中心或公司的HPC集群上启动容器时，却被告知没有sudo权限，操作被无情拒绝。这种挫败感，正是Singularity旨在解决的核心痛点。

与面向云原生和微服务的Docker不同，Singularity从诞生之初就瞄准了科学计算和学术研究领域。它允许普通用户像运行普通程序一样运行容器，无需提权，同时保持了与主机文件系统的无缝集成。这对于处理基因组数据、进行物理模拟或运行任何需要高性能、高安全性和用户隔离的科研任务来说，是一个游戏规则的改变者。本文将深入剖析这两种容器技术在HPC语境下的根本差异，并手把手带你完成在经典的CentOS 7.9系统上部署Singularity的全过程。无论你是负责维护集群的工程师，还是亟需在受控环境中运行复杂工作流的研究者，这篇文章都将为你提供清晰的路线图。

1. 核心理念之争：为何HPC是Singularity的主场

要理解技术选型，不能只看安装命令，更要看设计哲学。Docker和Singularity虽然都打着“容器”的旗号，但它们的目标用户和解决的核心问题截然不同。

Docker的架构根植于服务部署与运维。它的守护进程（dockerd）以root权限运行，管理着整个主机上的容器生命周期。这种设计带来了强大的功能和灵活性，但也引入了显著的安全边界模糊问题。在共享的HPC环境中，让普通用户通过Docker接触root权限是系统管理员无法接受的风险。此外，Docker鼓励“一个容器一个进程”的微服务模型，而科学计算工作流往往是单次运行、资源密集型的单体应用，两者在范式上并不完全匹配。

相比之下，Singularity的设计遵循了**“以用户为中心”的原则。它的核心目标是让科学家能够将自己复杂的、依赖繁多的软件环境打包成一个可移植、可重复执行的单一文件（.sif镜像），然后可以在任何支持Singularity的系统上，以用户自身的身份和权限**直接运行。这带来了几个关键优势：

无需特权：用户无需root权限即可启动容器，完全符合HPC集群严格的安全策略。
自然的文件系统集成：容器内能直接“看到”并访问用户家目录（/home）、共享存储（如/scratch）等挂载点，数据输入输出变得极其自然，无需复杂的卷映射命令。
对MPI等HPC技术的原生友好：Singularity能够与Slurm、PBS等作业调度器以及OpenMPI、MPICH等并行计算库很好地协同工作，容器内的进程可以直接与主机的高性能网络互联（如Infiniband）通信。

为了更直观地对比两者在HPC场景下的关键特性，可以参考下表：

特性维度	Docker	Singularity	HPC场景下的影响
运行权限	需要root或docker组权限	普通用户权限即可	Singularity消除了权限提升的安全隐患，更受管理员欢迎。
镜像格式	分层镜像，存储在仓库中	单一文件（.sif），易于分发	.sif文件像二进制程序一样拷贝、共享，适合在计算节点间传输。
与主机集成	隔离性强，需显式挂载卷	自动挂载用户家目录、临时目录等	科研人员更习惯直接访问主机路径，简化了数据管理。
守护进程	必须运行`dockerd`守护进程	无守护进程，直接执行	减少了集群的维护复杂性和单点故障风险。
主要生态	微服务、CI/CD、云原生	科学计算、高性能计算、生物信息学	社区和工具链更贴近科研工作者的需求。

注意：选择哪种容器技术，最终取决于你的应用场景。如果你的工作流需要与Kubernetes深度集成，或者本身就是由多个微服务构成，Docker及其生态仍是更优选择。但对于传统的、计算密集型的科学模拟和数据分析，Singularity往往是更贴合实际的那一个。

2. 部署基石：准备你的CentOS 7.9系统

CentOS 7.9是一个长期稳定版，至今仍在许多HPC中心和保守型企业中广泛使用。在开始编译安装Singularity之前，确保系统环境干净、依赖完整是成功的第一步。我们假设你已经以root身份登录，或者拥有sudo权限来执行系统级的安装命令。

首先，更新系统并安装必要的开发工具和库文件。这些包提供了编译软件所需的编译器、头文件和基础库。

# 更新系统到最新状态
yum update -y

# 安装开发工具组，包含gcc, make, autoconf等
yum groupinstall -y 'Development Tools'

# 安装Singularity编译所需的特定依赖库
yum install -y \
    openssl-devel \
    libuuid-devel \
    libseccomp-devel \
    wget \
    squashfs-tools \
    cryptsetup

这里安装的每个依赖都有其作用：

openssl-devel: 提供加密和证书相关功能支持。
libuuid-devel: 用于生成唯一标识符。
libseccomp-devel: 至关重要，它允许Singularity应用内核的“安全计算”模式来限制容器内进程的系统调用，是安全性的关键一环。
squashfs-tools: 用于创建和操作Singularity镜像文件（.sif）所需的SquashFS文件系统。
cryptsetup: 为加密容器提供支持（如果你的场景需要）。

完成上述步骤后，你的系统就已经具备了编译Singularity的基础环境。接下来，我们需要为其准备一个合适的“编译器”——Go语言环境。

3. 安装与配置Go语言环境

由于Singularity是用Go语言编写的，我们需要先安装Go来编译它的源代码。访问Go官方下载页面获取最新稳定版的Linux压缩包。这里我们以go1.24.2.linux-amd64.tar.gz为例。

提示：在HPC环境的内网中，直接从外网wget下载大文件可能速度缓慢或失败。一个更可靠的做法是先在本地或跳板机上下载好安装包，然后通过scp或rsync工具上传到CentOS服务器。这种方法虽然多了一步，但能避免因网络问题导致的安装中断。

假设你已经将Go的安装包上传到了服务器的/tmp目录，接下来进行解压和安装：

# 切换到临时目录并解压Go安装包
cd /tmp
tar -zxvf go1.24.2.linux-amd64.tar.gz -C /usr/local

解压后，Go的所有文件都在/usr/local/go目录下。现在需要设置环境变量，让系统知道Go的执行路径以及将来Go项目的工作目录。

# 编辑当前用户的bash配置文件（如果是root用户，通常是/root/.bashrc）
vim ~/.bashrc

在文件的末尾添加以下几行：

# 设置Go的安装路径
export GOROOT=/usr/local/go
# 设置Go项目的工作目录（可自定义，如/home/username/go）
export GOPATH=$HOME/go
# 将Go的可执行文件目录加入系统PATH
export PATH=$GOROOT/bin:$GOPATH/bin:$PATH

保存退出后，使用source命令使配置立即生效，并验证安装：

source ~/.bashrc
go version

如果终端成功打印出go version go1.24.2 linux/amd64，那么Go环境就已经准备就绪。GOPATH目录会在你首次使用go get等命令时自动创建。

4. 编译与安装Singularity

有了Go环境，我们就可以编译Singularity了。同样，建议从GitHub Releases页面下载特定版本的源码包（例如singularity-ce-4.3.0.tar.gz）并上传到服务器，这比在线克隆仓库更稳定。

编译安装过程分为配置、编译和安装三步。Singularity使用了一套基于mconfig的构建系统。

# 1. 解压源码包
tar -zxvf singularity-ce-4.3.0.tar.gz
cd singularity-ce-4.3.0

# 2. 运行配置脚本
# `--without-libsubid` 是一个常见选项，用于避免对某些特定UID/GID管理库的依赖，在最小化安装的系统上兼容性更好。
./mconfig --without-libsubid --prefix=/usr/local

# 3. 进入构建目录进行编译
make -C builddir

# 4. 安装到系统（需要root权限）
make -C builddir install

编译过程可能会花费几分钟到十几分钟，具体取决于你的服务器性能。--prefix=/usr/local参数指定了安装目录，这样安装后的二进制文件会出现在/usr/local/bin，库文件在/usr/local/lib，符合Linux系统管理第三方软件的习惯。

安装完成后，执行一个简单的命令来验证：

singularity --version

如果返回类似singularity-ce version 4.3.0的信息，那么恭喜你，Singularity已经成功安装在你的CentOS 7.9系统上了。

5. 基础使用与镜像管理实战

安装只是第一步，真正发挥威力在于使用。让我们通过几个最常见的场景，快速上手Singularity。

从容器仓库拉取镜像： Singularity可以直接从Docker Hub、Singularity Library等仓库拉取镜像，并将其转换为本地的.sif文件。这是获取软件环境最快捷的方式。

# 从Docker Hub拉取一个轻量级Alpine Linux镜像
singularity pull docker://alpine:latest
# 执行后，当前目录会生成一个名为 `alpine_latest.sif` 的文件

# 从Singularity Library拉取一个生物信息学常用工具镜像
singularity pull library://sylabsed/examples/lolcow:latest

运行容器： 运行.sif镜像文件就像运行一个可执行程序。

# 以默认方式运行，启动容器中定义的默认命令
singularity run alpine_latest.sif

# 或者，直接执行容器内的某个特定命令，例如启动一个shell
singularity exec alpine_latest.sif /bin/sh

# 对于交互式任务，可以启动一个可写的沙盒环境（基于镜像创建一个目录）
singularity build --sandbox my_sandbox/ docker://ubuntu:22.04
singularity shell --writable my_sandbox/

与主机文件系统交互： 这是Singularity在HPC中的一大亮点。你的家目录、当前工作目录以及/tmp、/proc、/sys等系统目录默认会自动绑定挂载到容器内部。这意味着你可以在容器内直接读取主机上的数据文件，并将计算结果写回主机目录，流程非常直观。

# 假设主机当前目录下有一个input.data文件
# 在容器内运行一个处理程序，并直接读写主机上的文件
singularity exec my_tool.sif ./process --input ./input.data --output ./result.data

构建自定义镜像： 虽然拉取现成镜像很方便，但有时你需要构建包含特定软件和配置的专属环境。Singularity使用一种名为Singularity Definition File（定义文件）的文本文件来描述镜像构建过程，通常以.def为后缀。

一个简单的定义文件示例如下：

# 文件名：my_python_app.def
Bootstrap: docker
From: python:3.9-slim

%post
    # 在镜像构建阶段执行的命令
    apt-get update && apt-get install -y --no-install-recommends \
        gcc \
        && rm -rf /var/lib/apt/lists/*
    pip install numpy pandas matplotlib

%environment
    # 设置容器运行时的环境变量
    export LC_ALL=C.UTF-8

%runscript
    # 当使用 `singularity run` 时执行的命令
    echo "欢迎使用我的Python分析环境！"
    exec /usr/local/bin/python "$@"

%labels
    # 镜像的元数据
    Author Your.Name@example.com
    Version v1.0

使用定义文件构建镜像：

# 需要root权限或使用fakeroot工具来构建镜像
sudo singularity build my_python_app.sif my_python_app.def
# 或者，如果系统支持且已配置，可以使用非特权构建
singularity build --fakeroot my_python_app.sif my_python_app.def

掌握了这些基本操作，你就能将Singularity融入到日常的科研计算任务中，享受容器化带来的可重复性和便利性，同时又无需与HPC系统的安全策略对抗。

6. 性能调优与生产环境考量

在个人环境测试成功只是开始，要将Singularity部署到生产级HPC集群，还需要考虑性能、稳定性和管理便利性。

缓存管理： Singularity会在用户家目录下的.singularity/cache中缓存拉取的镜像层和库文件。对于长期运行的任务或共享账户，这个缓存目录可能会变得非常大。定期清理或配置缓存到共享存储（如Lustre或GPFS）是必要的。

# 查看缓存使用情况
singularity cache list

# 清理所有缓存（谨慎操作）
singularity cache clean --all

# 在运行singularity命令前，通过环境变量指定缓存位置
export SINGULARITY_CACHEDIR=/shared/storage/singularity_cache/$USER

与作业调度器集成： 在Slurm脚本中调用Singularity是标准做法。关键是要注意镜像文件的路径在所有计算节点上都可访问（通常放在共享存储上），并且正确绑定必要的目录。

#!/bin/bash
#SBATCH -J singularity-job
#SBATCH -N 2
#SBATCH --ntasks-per-node=16

# 假设镜像在共享存储上
SIF_FILE="/shared/software/images/my_analysis.sif"
INPUT_DATA="/shared/data/input_${SLURM_JOB_ID}.h5"
OUTPUT_DIR="/shared/results/${SLURM_JOB_ID}"

# 在每个任务中运行容器
srun singularity exec --bind /shared $SIF_FILE python /app/analysis.py $INPUT_DATA $OUTPUT_DIR

网络与MPI支持： 对于需要跨节点通信的MPI应用，推荐使用主机上的MPI库（Host MPI）。这意味着你需要在容器内安装与主机MPI版本、配置完全兼容的MPI运行时库（通常不包含编译器），然后在运行时使用主机的mpirun或srun来启动容器内的MPI程序。Singularity能很好地传递环境变量和挂载点，确保网络设备可见，从而实现高性能的跨节点通信。

安全加固： 虽然Singularity默认比Docker更安全，但在多租户HPC环境中仍需注意：

使用--containall或--contain标志来加强隔离，限制容器对主机目录的访问。
对于不受信任的镜像，可以在沙盒模式或非特权命名空间下先进行测试。
关注Singularity的安全公告，及时更新版本。

从实验室的原型到生产环境的稳定服务，中间往往隔着对细节的把握。在集群上大规模部署前，务必与系统管理员沟通，了解存储策略、网络配置和作业管理的最佳实践。我自己的经验是，先在测试节点上模拟完整的作业流程，记录下所有可能出错的地方——比如某个特定的库版本冲突、临时存储空间不足、或者MPI库的符号链接问题——这些小坑填平了，迁移到生产环境才会顺畅。