Podman-compose is the podman equivalent to docker-compose, using the podman container engine. It allows for the creation of rootless containers running in user namespace. For more information see https://podman.io/ and https://github.com/containers/podman-compose
This version of the Singularity Registry Server is set-up to work in a non-root environment. I did not change the code of the applications. I did change the folder structure and the docker-compose.yml file and provide documentation to make this setup run with podman-compose. This setup in it's current configuration is meant to be run with valid SSL certificates. You can change that by deactivating the corresponding settings in the docker-compose.yml and shub/settings/config.py files. In the end you still have to make your configurations (like setting your services addresses, renaming your instance, enabling authentication, etc.) according to the original documentation which you can find at https://singularityhub.github.io/sregistry/
The differences in detail:
- Changed the docker-compose.yml
- Volume paths are not taken from uwsgi directly, but are defined per service. Consquence: You don't need a nginx user on your host system anymore and don't have permissions problems after deactivating PAM again.
- Volume mapping for PAM files changed.
- Volume mapping for SSL certs changed.
- Volume mapping for PostgreSQL database added, so it can save data persistently without initiating a backup procedure.
- A PAM folder with a 'shadow' file was added. You need to copy the information of configured users from your /etc/shadow into this file since rootless containers do not have access to the original /etc/shadow.
- An SSL directory with subdirectories was added to save and access cert files in the rootless environment.
- You need to change the ownership of the sregistry/minio-images folder to the user that is used inside the minio container with the UID and GID 1. To do so, execute the following command inside the sregistry folder:
podman unshare chown -R 1:1 minio-imagesThis will change the ownership to the UID that will be used in user namespace and represents the user with UID 1 inside the minio container.
- You can put your SSL cert and key into the according folders in the sregistry/ssl folder
- You can put your user info from /etc/shadow into sregistry/PAM/shadow
 Cedric Casper 💻 |
 Kevin Kaftan 💻 |
The following section is taken from the original Sregistry repo itself and does not have to do with our changes.
Singularity Registry Server is a server to provide management and storage of Singularity images for an institution or user to deploy locally. It does not manage building but serves endpoints to obtain and save containers.
Singularity Registry consists of several Docker images, and they are integrated to work together using docker-compose.yml.
The images are the following:
- vanessa/sregistry: is the main uWSGI application, which serves a Django (python-based) application.
- nginx: pronounced (engine-X) is the webserver. The starter application is configured for HTTP. However, you should follow our instructions to set up HTTPS properly. Note that we build a custom NGINX image that takes advantage of the nginx-upload-module.
- worker: is the same uWSGI image, but with a running command for queueing jobs and processing them in the background. These jobs run via django-rq backed by a
- redis: database to organize the jobs themselves.
- scheduler jobs can be scheduled using the scheduler.
For more information about Singularity Registry Server, please reference the docs. If you have any issues, please let me know!
This code is licensed under the MPL 2.0 LICENSE.