@@ -105,7 +105,7 @@ $ singularity instance start \
105
105
$ singularity instance list
106
106
```
107
107
108
- This is a complicated set of commands. In the above commands , we
108
+ This is a complicated set of commands. In the above, we
109
109
first build the two containers. There are no checks here if the recipes
110
110
exist, or if the containers themselves already exist.
111
111
We then start instances for them. If we save these commands in a file,
@@ -114,11 +114,10 @@ along with the ip addresses, hostnames, and volumes. There are no checks
114
114
done before attempting the creation if the volumes meant to be bound
115
115
actually exist. We also take for granted that we've already generated an
116
116
` etc.hosts ` file to bind to the container at ` /etc/hosts ` , which will
117
- define the container instances to have the same names supplied with ` --hostname `
118
- so that instances can "see" one another. For the networking, we have
119
- to be mindful of the default bridge provided by Singularity, along with how
120
- to specify networking arguments under different conditions. This entire practice
121
- is clearly tedious. For a user to constantly need to generate and then
117
+ define the container instances to have the same names supplied with ` --hostname ` .
118
+ For the networking, we have to be mindful of the default bridge provided by Singularity,
119
+ along with how to specify networking arguments under different conditions.
120
+ This entire practice is clearly tedious. For a user to constantly need to generate and then
122
121
re-issue these commands, it's not a comfortable workflow. However,
123
122
with Singularity Compose, the user writes a ` singularity-compose.yml `
124
123
file once:
0 commit comments