Upgrading Postgresql deployed on Docker Swarm I have deployed an app in staging on Docker Swarm, and it uses a postgresql database, using the Docker image with version 15.4. With Postgresql 16.0 published recently, here’s how I upgraded it. The setup I’m using a one-node Docker Swarm, but I suspect this should apply to multi-nodes as well. The postgresql container of the stack is pinned to a specific node, and is mounting the host directory /data/myowndb/db at /var/lib/postgresql/data for data persistence.

Gitlab limited the number of CI minutes freely available, and although I’m working on an opensource project and could possibly apply to get more free minutes, I decided not to if possible. I’m happy to be able to use their service freely, and in their competition with a megacorp, I’d rather not participate in unnecessarily using their limited financial means. Most deployment of Gitlab Runners are probably done on servers, but the workstation I’m developing on has a lot of spare resources, which I would be happy to use to run CI jobs.

If you enable ipv6 for your docker containers with these lines in your /etc/docker/daemon.json like illustrated in the official documentation, { "ip6tables": true, "fixed-cidr-v6": "2001:db8:1::/64" } your containers will get an ip from the range 2001:db8:1::/64. But this range is just used as an example in the documentation, and has nothing special. It is a normal routable range. It is advised to not reuse that range if it was not assigned to you.

Staying with Docker Swarm in 2023 TL;DR: Things seem to move favorably for Docker Swarm. Last year I started to use Docker Swarm on a single node swarm, wondering if it was the right choice, with all attention going to Kubernetes. I went for Swarm because the possibilities offered by Kubernetes were not worth the price to pay in complexity. Nearly one year later, I’m happy with my choice. Docker Swarm brings enough flexibility for me (as for a lot of situations for a lot of people I think), and deploying and managing it was a pleasure.

When maintaining a Docker Swarm, you might need to take actions on a specific container, possibly identified by a task id logged by docker. But in Swarm, you run and manage services on multiple nodes, you don’t have directly access to the containers. Here’s how to get to the containers. 1) Identify the node running the container You can list all tasks running for a service with docker service ps $SERVICE_NAME.

Kubernetes has the concept of init containers. This does not exist in Docker Swarm, and the depends_on is ignored when deploying to a swarm. There are situation when the init containers are convenient, but in my Docker Swarm usage this doesn’t seem to cause trouble: before I discovered that depends_on is a no-op when deploying to a Swarm, I used it to (I thought) simulate init containers! Let’s see my usage scenario.

Here’s an easy workflow to use the container registry make available to Gitlab projects. You first need to create a token. A Personal Access Token is usable with any project you have access to. A Deploy token is scoped to a group or a project. Personal Access Token If you decide to use a Personal Access Token you first need to create one with the api access. As mentioned in the doc, you can do this on the gitlab.

I wanted to test a docker setup and the easiest was to do it in a vm. I was looking for a solution as easy as docker, and went with Vagrant. To have a vagrant-managed vm it’s possible to use an existing box, but I’m more comfortable knowing exactly what’s in the boxes I use, so I decided to build one with Packer. This post is based on this blog post and the config and scripts used are public.

We will see how to store the compose files of a Docker Swarm in git, together with encrypted authentication data to retrieve images from private repositories. We will access a private registry hosted by Gitlab. Authentication to the registry is done with a deploy token, which gives you a username and password giving access only to the relevant registry. Docker authentication Authentication to a docker registry is done with the command docker login -u $login --password $password (or alternatively with --password-stdin to avoid putting the password on the command line).

Intro I started using Docker Swarm in 2022 and am still very satisfied with it. I am currenyl using it as a one node swarm. This post assumes you deployed Swarm with a Traefik reverse proxy as described on DockerSwarm.rocksi, that all services are deployed under the doomain stored in the DOMAIN environment variable, and that the variable DOCKER_HOST is set correctly. I wanted to test authelia for protecting a web app to be deployed on a Docker Swarm, and I decided to test it on an existing Docker Swarm.