You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pages/docs/user-docs/action-mount.md
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,21 +6,21 @@ toc: false
6
6
folder: docs
7
7
---
8
8
9
-
{% include toc.html %}
9
+
Singularity allows you to map directories on your host system to directories within your container using bind mounts. This allows you to read and write data on the host system with ease.
10
10
11
-
## Bind Paths
12
-
Singularity 'swaps' out the currently running root operating system on the host for what is inside the container, and in doing so none of the host file systems are accessible anymore. As a workaround for this, Singularity will *bind* those paths back in via two primary methods: system defined bind points and conditional user defined bind points.
11
+
{% include toc.html %}
13
12
14
-
{% include asciicast.html source='docs-create-rootmount.js' uid='how-to-mount-and-copy' title='How to mount an image and copy files to it' author='davidgodlove@gmail.com'%}
13
+
## Overview
14
+
When Singularity 'swaps' the host operating system for the one inside your container, the host file systems becomes inaccessible. But you may want to read and write files on the host system from within the container. To enable this functionality Singularity will *bind* directories back in via two primary methods: system defined bind points and conditional user defined bind points.
15
15
16
-
To *mount* a bind path inside the container, a ***bind point*** must be defined within the container. The bind point is a target location entity to which the actual directory or file can be bound to. This means that if you want to bind to a point within the container such as `/global`, that directory must already exist within the container.
16
+
To *mount* a bind path inside the container, a **bind point** must be defined within the container. The bind point is a directory within the container that Singularity can use to bind a directory on the host system. This means that if you want to bind to a point within the container such as `/global`, that directory must already exist within the container.
17
17
18
-
It is however possible that the system administrator has enabled a Singularity feature called *overlay* in the `/etc/singularity/singularity.conf` file. This will cause the bind points to be created on an as needed basis in an overlay file system so that the underlying container is not modified. But because the *overlay* feature is not always used, it maybe necessary for container standards to exist to ensure portability from host to host.
18
+
It is however possible that the system administrator has enabled a Singularity feature called *overlay* in the `/etc/singularity/singularity.conf` file. This will cause the bind points to be created on an as needed basis so that the underlying container is not modified. But because the *overlay* feature is not always used or unavailable in some kernels, it maybe necessary for container standards to exist to ensure portability from host to host.
19
19
20
-
If a bind path is requested, and the bind point does not exist within the container, a warning message will be displayed, and Singularity will continue trying to mount file system. For example:
20
+
If a bind path is requested, and the bind point does not exist within the container, a warning message will be displayed, and Singularity will continue trying to start the container. For example:
WARNING: Non existant bind point (directory) in container: '/global'
25
25
Singularity: Invoking an interactive shell within container...
26
26
@@ -30,17 +30,17 @@ Singularity.Centos7-ompi.img>
30
30
Even though `/global` did not exist inside the container, the shell command printed a warning but continued on. If we enable `enable overlay = yes` in the `/etc/singularity/singularity.conf` you will find that we no longer get the error and `/global` is created and accessible as expected:
Singularity: Invoking an interactive shell within container...
35
35
36
36
Singularity.Centos7-ompi.img>
37
37
```
38
38
39
-
####System defined bind points
39
+
### System defined bind points
40
40
The system administrator has the ability to define what bind points will be included automatically inside each container. The bind paths are locations on the host's root file system which should also be visible within the container. Some of the bind paths are automatically derived (e.g. a user's home directory) and some are statically defined (e.g. `bind path = ` in `/etc/singularity/singularity.conf`).
41
41
42
42
43
-
####User defined bind points
43
+
### User defined bind points
44
44
If the system administrator has enabled user control of binds (via `user bind control = yes` in `/etc/singularity/singularity.conf`), you will be able to request your own bind points within your container.
45
45
46
46
Further, if the administrator has enabled the use of file system overlay (via `enable overlay = yes` in `/etc/singularity/singularity.conf`), you can bind host system directories to directories that do not exist within the container. Singularity will dynamically create the necessary bind points in your container on demand. This feature may not be supported on older host systems.
Copy file name to clipboardExpand all lines: pages/docs/user-docs/docs-checks.md
+8-4Lines changed: 8 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,14 +6,18 @@ folder: docs
6
6
toc: false
7
7
---
8
8
9
-
New to Singularity 2.4 is the ability to, on demand, run container "checks," which can be anything from a filter for sensitive information, to an analysis of content on the filesystem. Checks are installed with Singularity and [managed by the administration](/docs-admin-checks), however as a user they are accessible to you for use during bootstrap or on demand:
9
+
New to Singularity 2.4 is the ability torun container "checks" on demand. Checks can be anything from a filter for sensitive information, to an analysis installed binaries. A few defualt checks are installed with Singularity and others can be [added by the administrater](/docs-admin-checks). Users can perform checks at build time or on demand:
10
10
11
+
{% include toc.html %}
12
+
13
+
Perform all default checks, these are the same
11
14
```
12
-
# Perform all default checks, these are the same
13
15
$ singularity check ubuntu.img
14
16
$ singularity check --tag default ubuntu.img
17
+
```
15
18
16
-
# Perform checks with tag "clean"
19
+
Perform checks with tag "clean"
20
+
```
17
21
$ singularity check --tag clean ubuntu.img
18
22
```
19
23
@@ -29,7 +33,7 @@ USAGE
29
33
30
34
EXAMPLE
31
35
32
-
singularity check --tag docker ubuntu.img
36
+
$ singularity check --tag docker ubuntu.img
33
37
```
34
38
35
39
If you want to run checks associated with a different security level, you can specify with `--low`, `--med`, or `-high`:
Copy file name to clipboardExpand all lines: pages/docs/user-docs/docs-environment-metadata.md
+41-35Lines changed: 41 additions & 35 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,36 +6,40 @@ folder: docs
6
6
toc: false
7
7
---
8
8
9
-
Singularity containers support environment variables and labels that can be added by user during the bootstrap process.
9
+
Singularity containers support environment variables and labels that you can add to your container during the build process.
10
10
11
11
{% include toc.html %}
12
12
13
13
## Environment
14
14
15
-
If you are importing a Docker container, the environment will be imported as well. If you want to define custom environment variables in your bootstrap recipe file `Singularity` you can do that like this
15
+
If you build a container from Singularity Hub or Docker Hub, the environment will be imported into the container at build time. You can also define custom environment variables in your Recipe file like so:
16
16
17
-
```bash
18
-
Bootstrap:docker
19
-
From: ubuntu:latest
17
+
```
18
+
Bootstrap: shub
19
+
From: singularityhub/ubuntu
20
20
21
21
%environment
22
22
VARIABLE_NAME=VARIABLE_VALUE
23
23
export VARIABLE_NAME
24
24
```
25
25
26
-
If you need to add an environment variable to your container during the `%post` section, you can do so using the `$SINGULARITY_ENVIRONMENT` variable with the following syntax:
26
+
You may need to add environment variables to your container during the `$post` section. For instance, maybe you will not know the appropriate value of a variable until you have installed some software.
27
+
28
+
To add variables to the environment during `%post` you can use the `$SINGULARITY_ENVIRONMENT` variable with the following syntax:
Text in the `%environment` section will be appended to the file `/.singularity.d/env/90-environment.sh` while text redirected to `$SINGULARITY_ENVIRONMENT` will end up in the file `/.singularity.d/env/91-environment.sh`. Because files in `/.singularity.d/env` are sourced in alpha-numerical order, this means that variables added using `$SINGULARITY_ENVIRONMENT` take precedence over those added via the `%environment` section.
35
+
Text in the `%environment` section will be appended to the file `/.singularity.d/env/90-environment.sh` while text redirected to `$SINGULARITY_ENVIRONMENT` will end up in the file `/.singularity.d/env/91-environment.sh`.
36
+
37
+
Because files in `/.singularity.d/env` are sourced in alpha-numerical order, this means that variables added using `$SINGULARITY_ENVIRONMENT` take precedence over those added via the `%environment` section.
34
38
35
-
Forget something, or need a variable defined at runtime? You can set any variable you want inside the container by prefixing it with "SINGULARITYENV_". It will be transposed automatically and the prefix will be stripped. For example, let's say we want to set the variable `HELLO` to have value `WORLD`. We can do that as follows:
39
+
Need to define a variable at runtime? You can set variables inside the container by prefixing them with "SINGULARITYENV_". They will be transposed automatically and the prefix will be stripped. For example, let's say we want to set the variable `HELLO` to have value `WORLD`. We can do that as follows:
Notice the `-e`? That is the argument (or `--cleanenv`) that specifies that we want to remove the host environment from the container. If we remove the `-e`, we will still pass forward `HELLO=WORLD`, and the list shown above, but we will also pass forward all the other environment variables from the host. Here is a command to directly echo the variable we define:
Notice the `--cleanenv` in the example above? That argument specifies that we want to remove the host environment from the container. If we remove the `--cleanenv`, we will still pass forward `HELLO=WORLD`, and the list shown above, but we will also pass forward all the other environment variables from the host.
56
55
57
-
If you want to look at the environment inside a container, you can look inside the metadata env folder as follows:
58
-
59
-
```bash
60
-
singularity exec centos7.img ls /.singularity.d/env
61
-
01-base.sh 10-docker.sh 99-environment.sh
62
-
```
63
-
64
-
The variables in `01-base.sh` are a set of defaults set upon container creation, and the `10-docker.sh` come from a Docker import.
Here is a command to directly echo the variable we define:
70
57
71
58
## Labels
72
-
Your container stores metadata about it's build, along with Docker labels, and your custom labels that you define in a bootstrap`%labels` section. For containers that are generated with Singularity version 2.4 and later, labels are represented using the <ahref="http://label-schema.org/rc1/">rc1 Label Schema</a>. For example:
59
+
Your container stores metadata about it's build, along with Docker labels, and custom labels that you define during build in a `%labels` section. For containers that are generated with Singularity version 2.4 and later, labels are represented using the <ahref="http://label-schema.org/rc1/">rc1 Label Schema</a>. For example:
You will notice that the one label doesn't belong to the label schema, `MAINTAINER`. This was a user provided label during bootstrap. Finally, for Singularity greater than version 2.4, the image build size is added as a label, `org.label-schema.build-size`, and the label schema is used, period. For versions earlier than 2.4, containers did not use the label schema, and looked like this:
77
+
You will notice that the one label doesn't belong to the label schema, `MAINTAINER`. This was a user provided label during bootstrap. Finally, for Singularity versions >= 2.4, the image build size is added as a label, `org.label-schema.build-size`, and the label schema is used througout. For versions earlier than 2.4, containers did not use the label schema, and looked like this:
0 commit comments