We can see above that the training is successfully using our GPU via the cuda_blas library. If you want to continue with more steps, please see TensorFlow beginner quickstart.
Singularity containers for CUDA applications can now be developed, tested, and used on a Windows laptop or desktop, and using the Remote Build, Library and Keystore functions of Singularity Container Services.. All of the standard Singularity features work well under WSL2, so it’s a really powerful development environment. When you need to run on more powerful GPU nodes, just take your SIF file to your HPC environment.
In future versions of SingularityCE and SingularityPRO we’ll be aiming to make the –nvccli method of GPU setup the default, simplifying this process further.If you have any questions, comments, or hit any trouble. Reach out via the Singularity community spaces.
We’ve had some questions about this video series and have decided to add a few more features of Singularity and Singularity Container Services.
Encryption of SIF
Encryption is a well-known technology used to protect sensitive information, it can also be used to encrypt the contents of a container across a variety of use cases.
The Singularity client can locally build an encrypted container from a definition file, using passphrase. This feature allows the rootfs within a container to be encrypted at rest, in transit, and even while running. As a result, data is decrypted in kernel space, and there will not be any intermediate, decrypted rootfs lying around after the container is terminated.
This encryption can be performed using either a passphrase or asymmetrically via an RSA key pair in Privacy Enhanced Mail (PEM/PKCS1) format. The container is then encrypted while in transit, at rest, and even while running. In other words, there is no intermediate, decrypted version of the container on disk. Container decryption occurs at runtime completely within kernel space.
Passphrase encryption is less secure than encrypting containers using an RSA key pair. This feature is provided as a convenience, and as a way for users to familiarize themselves with the encrypted container workflow, but users running encrypted containers in production are encouraged to use asymmetric keys.
The container we are going to build from a definition file uses “curl” to call out to a console oriented weather service. Within the Ubuntu WSL2 environment, you can use the nano editor to copy this text and save to a file called “wttr.def”, which is calling to Singularity Container Services Library for a source Debian container, then adding “%post” and “%runscript” commands. For more information on how to use definition files and choosing different bootstrap sources, here is the documentation.
As with our previous demonstration of signing a container, an encrypted container must be locally created since Singularity Container Services does not store your private keys. What’s nice about the WSL2 environment is that users have sudo privileges and can build containers using the sudo command.
Launch the nano editor and paste the contents into the definition file: