SingularityContainerCreation: Difference between revisions
No edit summary |
|||
(6 intermediate revisions by one other user not shown) | |||
Line 10: | Line 10: | ||
<pre> | <pre> | ||
Bootstrap: docker | Bootstrap: docker | ||
From: centos:latest | From: centos:latest | ||
</pre> | </pre> | ||
The first line indicates that we will use a container from [https://hub.docker.com/explore/ Docker hub], the second line specifies which container (the latest release of CentOS). | The first line indicates that we will use a container from [https://hub.docker.com/explore/ Docker hub], the second line specifies which container (the latest release of CentOS). You can also replace '''latest''' by the version number, like '''7''' or '''8'''. | ||
Now, if you issue the following command : | Now, if you issue the following command : | ||
Line 33: | Line 32: | ||
If you want to transform the sandbox into a single image file, run the following command : | If you want to transform the sandbox into a single image file, run the following command : | ||
<pre> | <pre> | ||
$ sudo singularity build test1.simg test1.img | |||
</pre> | |||
But that's not all ! We can do a little bit better by exploiting the power of definition files ! Let's create the following 'test2.def' file : | |||
<pre> | |||
Bootstrap: docker | |||
From: centos:latest | |||
%post | |||
yum update -y | |||
yum install -y vim | |||
</pre> | </pre> | ||
The post section contains instructions that will be executed after the base OS has been installed at build time. Now, let's check this new definition file : | |||
<pre> | |||
$ sudo singularity build --sandbox test2.img test2.def | |||
</pre> | |||
If you need to include files in the container before the commands of the %post section are executed, add a %file section like in this example : | |||
<pre> | |||
%files | |||
foobar.tgz /root/foobar.tgz | |||
</pre> | |||
Here, the tarball 'foobar.tgz' from the host will be copied into the container in the /root directory before the %post section. This is useful when you need to install some programs from a tarball. | |||
To discover the other possibilities of definition files, please consult this [https://www.sylabs.io/guides/2.6/user-guide/container_recipes.html page]. | |||
== Building containers for T2B == | |||
People working on the T2B need to have access to the following directories : | |||
<pre> | |||
/user | |||
/cvmfs | |||
/scratch | |||
</pre> | |||
They can mount these directories with the '-B' option when they open a shell like this : | |||
<pre> | |||
$ singularity shell -B /cvmfs -B /scratch test2.img | |||
</pre> | |||
However, these directories must exist beforehand in the container ! This can be fixed using the %post section in the definition file when building the container : | |||
<pre> | |||
mkdir /user | |||
mkdir /cvmfs | |||
mkdir /scratch | |||
</pre> | |||
'''Note''' : We may have noticed the absence of the "-B /user" option in the previous example. This is not a mistake : the home directory of the user who launches the container (in this case : /user/<login>) is always mounted by default inside the container. But again (sorry to insist) : the /user directory must exist beforehand in the container ! | |||
= Sources = | = Sources = | ||
* [https://www.sylabs.io/docs/ Singularity website] -> explanations to build a container on this [https://www.sylabs.io/guides/2.6/user-guide/build_a_container.html page]. | * [https://www.sylabs.io/docs/ Singularity website] -> explanations to build a container on this [https://www.sylabs.io/guides/2.6/user-guide/build_a_container.html page]. |
Latest revision as of 13:39, 15 October 2019
Prerequisites
By default, ordinary users don't have the right to create Singularity containers. You must either do it as root, or to work with sudoer account (the best option !).
Creation of a containers
On this page, we will not explain all the methods that exist to build a container, this is already done here. Instead, we will illustrate one method that can rapidly be adopted.
Creation of a container using a definition file
A definition file is a recipe to build a container starting from something else, generally another Singularity or Docker container. Let's create a definition file 'test1.def' with the following content :
Bootstrap: docker From: centos:latest
The first line indicates that we will use a container from Docker hub, the second line specifies which container (the latest release of CentOS). You can also replace latest by the version number, like 7 or 8.
Now, if you issue the following command :
$ sudo singularity build --sandbox test1.img test1.def
after one or two minutes, you get an container ready to be used under the form of a directory test1.img.
Now, let's say you want to install vim inside the container. Issue the following command to open a shell as root inside the container :
$ sudo singularity shell --writable test1.img Singularity: Invoking an interactive shell within container... Singularity test1.img:~>
The "--writable" flag is really important if you want to bring modifications inside the image. Now, you can do "yum install -y vim" and log out.
If you want to transform the sandbox into a single image file, run the following command :
$ sudo singularity build test1.simg test1.img
But that's not all ! We can do a little bit better by exploiting the power of definition files ! Let's create the following 'test2.def' file :
Bootstrap: docker From: centos:latest %post yum update -y yum install -y vim
The post section contains instructions that will be executed after the base OS has been installed at build time. Now, let's check this new definition file :
$ sudo singularity build --sandbox test2.img test2.def
If you need to include files in the container before the commands of the %post section are executed, add a %file section like in this example :
%files foobar.tgz /root/foobar.tgz
Here, the tarball 'foobar.tgz' from the host will be copied into the container in the /root directory before the %post section. This is useful when you need to install some programs from a tarball.
To discover the other possibilities of definition files, please consult this page.
Building containers for T2B
People working on the T2B need to have access to the following directories :
/user /cvmfs /scratch
They can mount these directories with the '-B' option when they open a shell like this :
$ singularity shell -B /cvmfs -B /scratch test2.img
However, these directories must exist beforehand in the container ! This can be fixed using the %post section in the definition file when building the container :
mkdir /user mkdir /cvmfs mkdir /scratch
Note : We may have noticed the absence of the "-B /user" option in the previous example. This is not a mistake : the home directory of the user who launches the container (in this case : /user/<login>) is always mounted by default inside the container. But again (sorry to insist) : the /user directory must exist beforehand in the container !
Sources
- Singularity website -> explanations to build a container on this page.