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.

I found the documentation regarding handling large uploads in a ASP.Net Core app confusing. I didn’t find a lot of code examples, and even none at all using F#. Eventually I found an example I could get inspiration from and build a working solution with. It should work with whatever ASP.Net Core based framework you use, as long as you can get a handle on the Microsoft.AspNetCore.Http.HttpContext instance. You will need to clarify some things before you put the code in production.

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.

VsCodium is the FOSS version of Visual Studio Code, i.e. it is the same code without the private/proprietary addition added when Microsoft packages it. Making it possible to package and publish VSCodium is great, but, without getting in the discussion of how lame this is, the dotnet debugger published by Micro$oft can only be used by Micro$oft published software, meaning not VSCodium. (Did you know the same restriction applies to usage of the VSCode Marketplace?

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.

If you read this blog, you might have understood I’m a Jsonnet fan. To help people getting started with Jsonnet, I have prepared an online training. Here’s the first chapter, an introduction showing why you should be interested in Jsonnet. As this is my first online training production, your feedback is very welcome at yvesdennels@gmail.com. I hope this video raises you interest in Jsonnet. If you’re a self-learner, go to jsonnet.

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).