Skip to content

Installation: Start Containers

Whether you build or not, the compose command will bring up the application (and download containers provided on, 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:

  • is the core application image, generated from the Dockerfile in the base of the repository.
  • 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 , and if you’ve configured https, . If you need to shell into the application, for example to debug with python 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
$ docker rmi

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 shell

or an interactive database shell.

$ python 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 .

And then to build NGINX:

$ cd nginx
$ docker build -t .

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.