Installation: Start Containers
Whether you build or not, the compose command will bring up the application (and download containers provided on Quay.io, previously on Docker Hub, if they aren’t in your cache).
What containers are provided?
Singularity Registry Server (as of April 27, 2023) builds images to GitHub packages, so they are built alongside the code.
For history, Singularity Registry used to build images on Quay via an automated build on CircleCI:
- quay.io/vanessa/sregistry: is the core application image, generated from the Dockerfile in the base of the repository.
- quay.io/vanessa/sregistry_nginx: Is the NGINX container installed with the NGINX upload module, intended for use with speedy uploads. It is generated from the subfolder “nginx” in the repository.
But we switched when Circle had bad behavior, and we also didn’t like the idea of credentials crossing platforms.
Start Containers
$ docker compose up -d
The -d
means detached, and that you won’t see any output (or errors) to the
console. You can easily restart and stop containers, either specifying the
container name(s) or leaving blank to apply to all containers. Note that these
commands must be run in the folder with the docker compose.yml
:
$ docker compose restart uwsgi worker nginx
$ docker compose stop
When you do docker compose up -d
the application should be available at
http://127.0.0.1/
, and if you’ve configured https, https://127.0.0.1/
. If
you need to shell into the application, for example to debug with python
manage.py shell
you can get the container id with docker ps
and then do:
$ NAME=$(docker ps -aqf "name=sregistry_uwsgi_1")
$ docker exec -it ${NAME} bash
Debugging Containers
Sometimes you might want to start containers and debug. The first thing to do is to stop and remove old containers, and if necessary, remove old images.
$ docker compose stop
$ docker compose rm
If you want to re-pull (or for other reason, remove) the core images, do that too:
$ docker rmi ghcr.io/singularityhub/sregistry
$ docker rmi ghcr.io/singularityhub/sregistry_nginx
You can inspect any container by looking at its logs:
$ docker compose logs uwsgi
# Only the last 30 lines
$ docker compose logs --tail=30 uwsgi
# Hanging
$ docker compose logs --tail=30 -f uwsgi
It’s also helpful to (after stopping and removing) bring up the containers but
leave out the -d
This can commonly show issues related to starting up (and
ordering of it).
$ docker compose up
And then press Control+C to kill the command and continue.
Interactive Debugging
This is my preference for debugging - because you can shell into any of the
containers and inspect things in real-time (interactively). For example, let’s
say uWSGI is running, and the container has CONTAINER_ID
of 37b0f7d1332a
(do
docker ps
to get the identifiers). We could shell into it via:
$ docker exec -it 37b0f7d1332a bash
and then find the codebase at /code
. You can get an interactive Django shell:
$ cd /code
$ python manage.py shell
or an interactive database shell.
$ python manage.py dbshell
Restart Containers
If you modify the container code (the Python, or a configuration value, etc.), you should restart the container for changes to take effect. It’s good to be conservative and only restart those containers that are needed (e.g., usually NGINX and uWSGI).
$ docker compose restart uwsgi nginx # uwsgi and nginx
$ docker compose restart # all containers
Build Containers
If you make changes to either of the images locally (or have other reasons to build them on your own), you can do this! In the base of the repository:
$ docker build -t ghcr.io/singularityhub/sregistry .
And then to build NGINX:
$ cd nginx
$ docker build -t ghcr.io/singularityhub/sregistry_nginx .
That’s it! Likely the easiest thing to do is docker compose up -d
and let the
containers be pulled and started, and debug only if necessary. Once you have
issued the commands to generate and start your containers, it’s time to read the
setup guide to better understand how to configure and interact with
your Singularity Registry.