Promoting applications from test to production

Setting up an application in the test environment

Adding and naming stacks

The purpose of having a test environment is to allow applications to be stood up and tested without disturbing the other applications in the group. I have tried to not add too many additional stacks to the original set, but the author's interests and mine diverge a little bit. Going forward, adding applications to a stack is done by adding a new stack with a number at the end. For example, adding applications to the admin stack is done with a new stack called admin2. An admin3 can be added so that the number of applications in a stack don't become unmanageable.

Incorporating the docker-compose.yml file into the stack

Docker compose is a great tool for managing stacks of individual services. It is a definite improvement from having a shell script with a bunch of docker run commands in it. Further improvement comes from the addition of the dockge and dockhand tools. These two applications are different approaches to managing the stacks. For the sake of discussion, stacks contain containers and containers contain images. An image, while defined in a single line, cans contain a number of images.

A docker compose file will start out looking a lot like this one:

services:
  ctroadmap:
    image: ghcr.io/noobcity99/ctroadmap:beta
    container_name: ctroadmap-beta
    ports:
      - "8088:8088"
    volumes:
      # Persistent atlas data and generated exports live beside this compose file.
      - ./data:/app/data
      - ./exports:/app/exports
    restart: unless-stopped

There are other directives, but this one is typical. The indentation levels are important and it assumed that lines at the same indentation level are linked together. Generally, the order of lines at the same group and level don't matter. The very first line that you see under services defines how the container will be identified on from the outside. The container_name directive is usually have the same name, but not always.

Since the order is a bit of a free for all, I like to regularize the declaration order and there are a few additions that I put in whether I need them or not.

The volumes listed under the volumes directive almost always need to be modified. Proper definition here allows for data used by the application to be persistent. It also makes things easy to find and backup. It is most common for an application two have two volumes defined. The first is to store configuration data. Often some historical data is stored there along with modest databases. The storage pool, called tank, for all of this is 2TB so putting a large set of data there, even if it is only temporary, could create problems.