Docker Deployment and docker compose - sakaki-/gentoo-on-rpi-64bit GitHub Wiki

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

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.

Docker Compose

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

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.

Portainer - Stacks

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)

Portainer - Application Templates

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.

Other Options

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