Conversation
| ### Can Singularity support daemon processes? | ||
| Singularity has container "instance" support which allows one to start a container process, within its own namespaces, and use that instance like it was a stand alone, isolated system. | ||
|
|
||
| At the moment (as above describes), the network (and UTS) namespace is not well supported, so if you spin up a process daemon, it will exist on your host's network. This means you can run a web server, or any other daemon, from within a container like and access it directly from your host. |
There was a problem hiding this comment.
Ooops, is this redundant?
There was a problem hiding this comment.
no I think it's ok, I wanted to suggest changing (as above described) to (as described above) because it's more commonly used
| 2. **Mobility of compute:** Singularity must be able to transfer (and store) containers in a manner that works with standard data mobility tools (rsync, scp, gridftp, http, NFS, etc..) and maintain software and data controls compliancy (e.g. HIPPA, nuclear, export, classified, etc..) | ||
| 3. **Compatibility with complicated architectures:** The runtime must be immediately compatible with existing HPC, scientific, compute farm and even enterprise architectures any of which maybe running legacy kernel versions (including RHEL6 vintage systems) which do not support advanced namespace features (e.g. the user namespace) | ||
| 4. **Security model:** Unlike many other container systems designed to support trusted users running trusted containers we must support the opposite model of untrusted users running untrusted containers. This changes the security paradigm considerably and increases the breadth of use cases we can support. | ||
|
|
There was a problem hiding this comment.
This is redundant from FAQ - does it read ok having the same text in two places? It seems more appropriate for about than FAQ, but it probably doesn't hurt to have in two places.
There was a problem hiding this comment.
I am impartial on it. :)
There was a problem hiding this comment.
ok let's leave until someone complains about it :)
| Singularity containers are purpose built and can include a simple binary and library stack or a complicated work flow that includes both network and file system access (or anything in between). The Singularity container images are then completely portable to any binary compatible version of Linux with the only dependency being Singularity running on the target system. | ||
| Singularity has two primary roles: | ||
|
|
||
| 1. **Container Image Management:** Singularity supports building different container image formats from scratch using your choice of Linux distribution bases or leveraging other container formats (e.g. Docker Hub). Container formats supported are the default compressed immutable (read only) image files, writable raw file system based images, and sandboxes (*chroot* style directories). |
There was a problem hiding this comment.
Would we really call this management? When I think management I think of Singularity Registry (eg, an actual manager to organizer and control images). Singularity is the maker of the containers, but not really the organizer. This paragraph is getting more at Container Image Formats. But I see you want it to be a "role." Maybe just Container Image Generator? THE BEST Container Image ? lol
There was a problem hiding this comment.
Image generator works too! I'm fine with it :)
There was a problem hiding this comment.
okay I like that too, let's change to that.
| Singularity containers are designed to be as portable as possible, spanning many flavors and vintages of Linux. The only known i86 limitation is the version of Linux running on the host. Singularity has been ported to distributions going as far back as RHEL 5 (and compatibles) and works on all flavors of Debian, Gentoo and Slackware. Within the container, there are almost no limitations aside from basic binary compatibility. | ||
| <font color='red' size='+1'>Ascineimsasasessssss!</font> | ||
|
|
||
| Within the container, there could be an entire distribution of Linux or a very lightweight tuned set of packages to support a particular work-flow. The work-flow can be scripted to run completely within the container or interact with files and other programs outside the container. The container can also emulate a single program and can be executed directly (yes, you heard that right). Containers have the execute bit set such they can be executed and configured to run a defined script or program when executed in this manner. |
|
hey @gmkurtzer if you want to update the header to Image Generator this guy is then ready for merge! |
|
Done :D |
|
Awesome! Good teamwork! |
|
Wahoooooo! |
2 participants
Changed security, about, and faq with minor edits elsewhere.