We deploy the stack to a Docker Swarm mode cluster (cluster with one node) with a Traefik proxy using the ideas from DockerSwarm.rocks. This allows automatic HTTPS certificate renewal, etc. Usually, we use Gitlab CI (continuous integration) to do it automatically but one can reproduce the CIs process with the workflow below.
To use docker on petra server, first authenticate the docker cli using the token from Repository -> Settings -> Deploy Tokens and
docker login gitlab.lrz.de:5005
There are 3 steps:
Here are the steps in detail:
TAG=prodFRONTEND_ENV=productionbuild.sh file with those environment variables:TAG=prod FRONTEND_ENV=production bash scripts/build.sh
Note: if the deployment Docker Swarm mode "cluster" has more than one server, you will have to push the images to a registry or build the images in each server, so that when each of the servers in your cluster tries to start the containers it can get the Docker images for them, pulling them from a Docker Registry or because it has them already built locally.
If you are using a registry and pushing your images, you can omit running the previous script and instead using this one, in a single shot.
TAG=prodFRONTEND_ENV=productionbuild-push.sh file with those environment variables:TAG=prod FRONTEND_ENV=production bash scripts/build-push.sh
DOMAIN=example.comTRAEFIK_TAG=example.comSTACK_NAME=example-comTAG=proddeploy.sh file with those environment variables:DOMAIN=example.com \ TRAEFIK_TAG=example.com \ STACK_NAME=example-com \ TAG=prod \ bash scripts/deploy.sh
If you change your mind and, for example, want to deploy everything to a different domain, you only have to change the DOMAIN environment variable in the previous commands. If you wanted to add a different version / environment of your stack, like "preproduction", you would only have to set TAG=preproduction in your command and update these other environment variables accordingly. And it would all work, that way you could have different environments and deployments of the same app in the same cluster.
Building and pushing is done with the docker-compose.yml file, using the docker-compose command. The file docker-compose.yml uses the file .env with default environment variables. And the scripts set some additional environment variables as well.
The deployment requires using docker stack instead of docker-swarm, and it can't read environment variables or .env files. Because of that, the deploy.sh script generates a file docker-stack.yml with the configurations from docker-compose.yml and injecting the environment variables in it. And then uses it to deploy the stack.
You can do the process by hand based on those same scripts if you wanted. The general structure is like this:
# Use the environment variables passed to this script, as TAG and FRONTEND_ENV # And re-create those variables as environment variables for the next command TAG=${TAG?Variable not set} \ # Set the environment variable FRONTEND_ENV to the same value passed to this script with # a default value of "production" if nothing else was passed FRONTEND_ENV=${FRONTEND_ENV-production?Variable not set} \ # The actual comand that does the work: docker-compose docker-compose \ # Pass the file that should be used, setting explicitly docker-compose.yml avoids the # default of also using docker-compose.override.yml -f docker-compose.yml \ # Use the docker-compose sub command named "config", it just uses the docker-compose.yml # file passed to it and prints their combined contents # Put those contents in a file "docker-stack.yml", with ">" config > docker-stack.yml # The previous only generated a docker-stack.yml file, # but didn't do anything with it yet # docker-auto-labels makes sure the labels used for constraints exist in the cluster docker-auto-labels docker-stack.yml # Now this command uses that same file to deploy it docker stack deploy -c docker-stack.yml --with-registry-auth "${STACK_NAME?Variable not set}"
There is a main docker-compose.yml file with all the configurations that apply to the whole stack, it is used automatically by docker-compose.
And there's also a docker-compose.override.yml with overrides for development, for example to mount the source code as a volume. It is used automatically by docker-compose to apply overrides on top of docker-compose.yml.
These Docker Compose files use the .env file containing configurations to be injected as environment variables in the containers.
They also use some additional configurations taken from environment variables set in the scripts before calling the docker-compose command.
It is all designed to support several "stages", like development, building, testing, and deployment. Also, allowing the deployment to different environments like staging and production (and you can add more environments very easily).
They are designed to have the minimum repetition of code and configurations, so that if you need to change something, you have to change it in the minimum amount of places. That's why files use environment variables that get auto-expanded. That way, if for example, you want to use a different domain, you can call the docker-compose command with a different DOMAIN environment variable instead of having to change the domain in several places inside the Docker Compose files.
Also, if you want to have another deployment environment, say preprod, you just have to change environment variables, but you can keep using the same Docker Compose files.
The .env file is the one that contains all your configurations, generated keys and passwords, etc.
Depending on your workflow, you could want to exclude it from Git, for example if your project is public. In that case, you would have to make sure to set up a way for your CI tools to obtain it while building or deploying your project.
One way to do it could be to add each environment variable to your CI/CD system, and updating the docker-compose.yml file to read that specific env var instead of reading the .env file.