为什么奇点容器在登录和 slurm HPC 上的计算节点上的行为不同

Question

为什么我能够在奇点容器中手动运行 R 脚本而不会出现问题，但作为 slurm HPC 上的数组作业，它会在各个级别上失败。这与容器允许通过适度的努力实现再现性的假设相矛盾。

首先，我尝试将外部目录绑定到与感兴趣的脚本所在的目录并行的容器目录：

srun singularity exec --bind ./extdirectory:/home/user/intdirectory image.sif Rscript /home/user/intdirectory2/script.R

如果没有

srun

，手动就可以了，但是作为

.sh

文件中定义的数组作业，

.out

文件会说：

Fatal error: cannot open file '/home/user/intdirectory2/script.R': No such file or directory

我确实明白，如果我尝试绑定到容器内感兴趣的脚本所在的同一目录，则安装将覆盖该脚本。

好吧，这是第一个问题。然后，如果我根本不绑定，现在数组作业将失败，如下所示：

Fatal error: cannot open file '/home/user/intdirectory2/script.R': Permission denied

我主要在 Windows 上使用

podman build

将映像构建为 OCI。然后我使用

podman save

导出

.tar

文件，并在HPC上使用

.sif

将其转换为

singularity build image.sif docker-archive://image.tar

图像。在

Containerfile

使用的

podman build

中，我使用以下行降级了容器中的用户权限：

RUN useradd user
RUN chown -R user /home/user
RUN chmod -R 700 /home/user
USER user

但是，当我在手动启动的奇点会话或数组作业中调用

whoami

时，在这两种情况下，我实际上都看到了底层 HPC 的个人用户帐户。

我还尝试执行感兴趣的脚本作为容器的默认操作。我通过在

CMD Rscript /home/user/intdirectory2/script.R

和

Containerfile

中使用

singularity run image.sif

来做到这一点，但没有运气。我还尝试使用

sbcast image.sif /tmp/image.sif

文件中的

.sh

将图像文件分发到计算节点上，并使用

srun singularity exec /tmp/image.sif Rscript /home/user/intdirectory2/script.R

启动容器，同样没有运气。

以下是一些版本：

apptainer version 1.1.9-1.el7
slurm 21.08.8-2

在尝试在计算节点上的 R 会话中使用

system()

命令启动并行容器后，我最终遇到了这种情况，但最终放弃了，如此处所述。我很困惑。在手动和数组作业情况下，我看到容器根据

INFO: /etc/singularity/ exists...

消息启动，并且从容器中调用

/bin/echo "hello world"

也有效。但由于某种原因，底层系统会影响容器内处理的 R 脚本的可见性（绑定到其他地方）和权限。

进一步研究：

根据 this 教程，应在

singularity exec

文件中不使用

srun

的情况下调用

.sh

。我想我已经尝试过，但我双重验证，如果绑定处于活动状态，仍然无法访问内部脚本。

Answer 1

最后，我能够绑定容器中的外部目录，找到感兴趣的 R 脚本，并有权在数组作业期间使用它。在

Containerfile

中，我更改了

RUN chmod -R 755 /home/user

，对主目录中的内容赋予了更广泛的权限。 但是这个情况仍然很奇怪，并且违背了可复制容器的理念！因为完全相同的

singularity exec --bind ./extdirectory:/home/user/intdirectory image.sif Rscript /home/user/intdirectory2/script.R

在登录节点和计算节点之间的行为不同，尽管容器中的用户至少看起来是相同的。