Docker Deployment and docker compose
When it comes to deploying docker images generally the first two main approaches are via
- The use of "docker run" at the command line
- The use of docker compose files such as docker-compose.yml
The main advantage of docker compose files is that you can keep all the settings / ports to be forwarded etc within a single file.
instead of having to remember lots of command line options.
It's also possible to specify multiple containers to be created at the same time, such as a database and application to connect to the database as part of a "stack"
Stacks can be though of as a group of associated containers, so for example a web server and a database server as one stack, a mail server and an application server as another stack.
Generally each stack usually will have it's own seperate network / subnet setup as well at the same time.
For a very small scale setup such as on a Rpi, stacks are probably not something we actually want (such as multiple databases, one for each application).
But they are something to be aware of in the sense of how docker tries to do things by default when using docker compose.
Usually you will see an example of this with docker compose files that contain multiple services such as the gitea example.
We can use docker compose to setup docker container instances just using a file.
As an example lets setup a mariadb instance.
docker-compose.yml
version: "3.8"
services:
mariadb:
image: mariadb:10.5.5
container_name: mariadb-live
environment:
- MYSQL_ROOT_PASSWORD=test
networks:
defnet:
ipv4_address: 10.100.0.100
restart: always
volumes:
- mariadb-live:/var/lib/mysql
ports:
- 3306:3306
volumes:
mariadb-live:
networks:
defnet:
external: true
The container_name directive forces the name of the container to a specific value.
This is useful if you will only be deploying one of these instances.
This will also be resolvable by this name by other docker containers within the same setup.
Now by default docker compose will try to give the instance a "stack" or "project" name this defaults to the same as the name of the directory the docker-compose.yml file sits under
If we want to override this there is a way, we can create a .env file within the same directory as the docker-compose.yml file
.env
COMPOSE_PROJECT_NAME="stack_name_here"
To use / deploy the image, run the following in the same directory as docker-compose.yml
docker-compose up -d
Portainer has had some issues using docker compose directly in the past.
I think due to the way docker compose was originally compiled.
docker compose is now a python base application and can be emerged under gentoo on the Rpi4, so perhaps they will adopt better support for it in the future.
One of the options portainer has available in it's gui is called "Portanier stacks".
This method uses an old library called Libcompose which partially support docker compose style yaml files.
the main drawback to this is that you can't use docker compose V3 scripts. It's limited to Version 2 of the script.
Note this isn't to be confused with docker's recent stacks feature (which use docker swarm mode)
One alternative to docker compose is a type of template employed by portainer called application templates.
These are typically json files read in by portainer. They do have some drawbacks however.
Currently with Version 2 of Portainer there's no support (yet) for adding url's for users own json files in the settings.
This video here shows some other available options for templates
Taisun
This uses a yaml file for it's stack which places values typed in a form into a docker compose file before running it - https://github.com/Taisun-Docker/taisun/wiki/Templates
Yacht
This one seems very pre alpha - https://github.com/SelfhostedPro/Yacht
