Docker on Sysadmin Tales

Meilisearch Dumpless Upgrades

Fri, 03 Apr 2026 15:54:33 -0400

Short one today.

I learned that Meilisearch has added experimental support for dumpless upgrades.

So far it works well, though to be fair none of my Meilisearch databases are particularly important.

I have one for better searches in Jellyfin and another for my Karakeep search index.

Losing either of them would be a minor inconvenience, whereas it’s been a massive inconvenience for me to have to dump and manually import every single time I patch Meilisearch.

You can either pass meilisearch the --experimental-dumpless-upgrade flag on the CLI, or set the MEILI_EXPERIMENTAL_DUMPLESS_UPGRADE environment variable.

In Docker you’d set it like this:

environment:
  - MEILI_EXPERIMENTAL_DUMPLESS_UPGRADE=true

Getting started with Docker

Sun, 26 Oct 2025 15:41:37 -0400

Getting started with Docker

So, you wanna use docker-compose…

Introduction

Welcome! If you’re looking at this post, I assume that you’re new to Docker and you want to learn to get up and running quickly.

There are several areas of Docker that confuse new users, and I will do my best to address most of the most common pitfalls in this post.

docker run vs docker compose

Don’t use docker run. If the thing you want to run in Docker only gives you the docker run syntax, you take that thing over to Composerize and you convert it.

There’s nothing particularly wrong with docker run, but docker compose is far easier to maintain and troubleshoot.

Tools like yamllint make diagnosing issues with compose file formatting much more tractable.

Docker networking

This seems to be the area that causes the most confusion.

Don’t worry, you don’t need to be a network engineer to get a grasp of this, but having a good understanding of how networking works is very helpful.

Network namespaces

Docker uses Linux kernel network namespaces to achieve isolation. You don’t need to really understand any of this, but click the link if you’re at all interested.

Effectively what this means is that containers by default are isolated from both the host operating system’s networking stack, and from each other.

Whenever you create a new Docker compose project, by default it will create a new Docker network bridge, with its own internal subnet and DNS.

Containers in the same Docker compose project (in the same docker-compose.yml file, or separate files linked together with the -p flag) share the same network bridge, and thereby are able to communicate with each other.

Communicating with containers by name

Docker also does some things under the hood to make it possible for docker containers in the same stack to communicate with each other by service name.

To illustrate this, lets go with a simple example.

services:
  app:
    image: myapp
    restart: unless-stopped
    environment:
      - POSTGRES_CONNECTION_STRING=postgresql://postgres-db1:5432
    volumes:
      - ./config:/config
  postgres-db1:
    image: postgres
    restart: unless-stopped

Above, we have an extremely simple docker compose file, with a single application and a PostgreSQL database.

You can see in the POSTGRES_CONNECTION_STRING environment variable that it is using the name of the service to communicate with the database.

Creating network bridges

But what if I don’t want or can’t have the containers in the same Compose project?

That’s where creating your own bridges comes in.

There are several different adapter types in Docker, the most common of them is the bridge, so that’s the only one we’ll be talking about in this article.

I’m sure as hell not going to get into macvlan or any of that, that’s a whole article on its own.

Here you can create a bridge:

docker network create proxy

Where proxy can be anything you like, it’s just the name you gave the bridge.

This is how you can use external bridges in Docker compose:

services:
  app01:
    networks:
      - proxy

networks:
  proxy:
    external: true

The key here is that you specify that the network is external to the compose project, and that you specify that each container should use that network instead of the default bridge that would have been created.

You can also specify more than one network per container. This can be useful if you have some containers that need external connectivity but others that don’t.

For example, you could have one bridge that’s used by containers to communicate with the database, and another that the frontend uses to talk to the backend.

Example:

services:
  app01:
    networks:
      - proxy
      - database

networks:
  proxy:
    external: true
  database:

Note that the database network is not external here, so it will be created when you run docker compose up.

Exposing ports

Next, lets get into how Docker handles exposing ports.

Lets take the Jellyfin docker compose file for an example:

---
services:
  jellyfin:
    image: lscr.io/linuxserver/jellyfin:latest
    container_name: jellyfin
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - JELLYFIN_PublishedServerUrl=http://192.168.0.5 #optional
    volumes:
      - /path/to/jellyfin/library:/config
      - /path/to/tvseries:/data/tvshows
      - /path/to/movies:/data/movies
    ports:
      - 8096:8096
      - 8920:8920 #optional
      - 7359:7359/udp #optional
      - 1900:1900/udp #optional
    restart: unless-stopped

You’ll notice the ports key. These are what’s known as published ports.

The number on the left is what is mapped outside the container (on the machine running Docker), and the one on the right is inside the container.

In 99% of cases, you want to leave the number on the right alone.

For example, if I wanted the Jellyfin web interface, which by default runs on port 8096, and expose it on port 9001, I could change the compose file like so:

ports:
  - 9001:8096
  - 8920:8920 #optional
  - 7359:7359/udp #optional
  - 1900:1900/udp #optional

Now, on to another example.

In many cases, you may not want to expose any ports at all!

If users external to the Docker host don’t need to be able to touch that port, then simply don’t publish it.

Take this other example:

services:
  proxy:
    image: "jc21/nginx-proxy-manager:latest"
    restart: unless-stopped
    ports:
      - "80:80" # Public HTTP Port
      - "443:443" # Public HTTPS Port
      - "81:81" # Admin Web Port
      # Add any other Stream port you want to expose
      # - '21:21' # FTP
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vw.domain.tld"
    volumes:
      - ./vw-data/:/data/

You’ll notice that the Vaultwarden container doesn’t have any published ports.

That’s because it doesn’t need them. In this scenario, we would go into Nginx Proxy Manager and configure a proxy host for it.

All communication with Vaultwarden would go through the proxy, so there’s no need to expose the port.

Remember that when containers are talking internally like this, you use the INTERNAL port (the one that would be on the right), instead of the one you would have exposed on the outside.

Nginx can talk to Vaultwarden and vice versa - there is no reason for a user to directly interact with the other container, so why let them?

This is also valid syntax:

ports:
  - 127.0.0.1:8000:80

This is telling the container to only publish port 8000 on localhost. You can substitute any other IP here to make it only listen on that one interface.

I don’t use this a whole lot.

Docker volumes

Docker volumes are simply a piece of your filesystem that you’re giving to the container to store persistent data.

By definition, Docker containers are ephemeral.

Unless you configure a volume, any data produced while the container is running will be lost when the container is destroyed.

The two most popular ways to configure volumes in Docker are named Docker volumes and bind mounts.

This is a named docker volume:

volumes:
  - postgres-data:/var/lib/postgresql/data

And this is a bind mount:

volumes:
  - /apps/myapp/postgres-data:/var/lib/postgresql/data

Note

If it’s a filesystem path on the left, it’s a bind mount.

The path on the right is the mountpoint inside the container.

Honestly as far as I’m concerned it’s mostly personal preference which you use. I like using bind mounts as it makes it easier to keep track of where your data is.

Named docker volumes will store the data in a subdirectory under /var/lib/docker/volumes/.

Whichever one you use, please make sure you do backups… I’m not going to help you try and get your data back, sorry.

Dawarich - A Google Location History Alternative

Wed, 14 May 2025 19:13:45 -0400

Note

2025/05/24 - edited to fix some mistakes I caught later in my docker compose.

Continuing on the theme of moving all of my stuff out of other people’s cloud and into mine - I was recently made aware of Dawarich while listening to the Linux Unplugged podcast.

This is touted as an alternative to Google’s Location History feature, which is something that I use frequently. I need it to account for my time at work, so it’s fairly important that I have a solution like this.

I chose to set this up on one of my VPS machines at Linode rather than running it in my house. The logic behind this being that a datacenter is most likely going to have more reliable power than I do at my house.

That said, I don’t think I’m going to be going through the work of making this truly highly-available - it’s just not worth the headache when I’m the only user.

Installation

As always, I set this up using their provided Docker image.

Dawarich can do either an HTTP or MQTT backend. I already have a webserver on this VPS, so I’ll be using HTTP.

I highly recommend setting up valid HTTPS certificates for this. I’m using free certificates from LetsEncrypt. The Traefik reverse proxy I’m using has an ACME client built right in, which is very handy.

The compose file for this app is quite the doozy. The project provides one, but I made some of my own changes, and added labels for Traefik.

networks:
  traefik:
    external: true

services:
  dawarich:
    image: freikin/dawarich:${DAWARICH_DOCKER_TAG:-latest}
    container_name: ${DAWARICH_CONTAINER_NAME:-dawarich}
    restart: ${DAWARICH_RESTART:-unless-stopped}
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./etc/dawarich/storage:/var/app/storage
    networks:
      - traefik
    stdin_open: true
    tty: true
    entrypoint: web-entrypoint.sh
    command: ["bin/rails", "server", "-p", "3000", "-b", "::"]
    environment:
      - RAILS_ENV=production
      - REDIS_URL=redis://dawarich_redis:6379/0
      - DATABASE_HOST=dawarich_db
      - DATABASE_PORT=5432
      - DATABASE_USERNAME=${DAWARICH_POSTGRES_USER:-postgres}
      - DATABASE_PASSWORD=${DAWARICH_POSTGRES_PW:-password}
      - DATABASE_NAME=dawarich_production
      - MIN_MINUTES_SPENT_IN_CITY=${DAWARICH_MIN_MINS:-30}
      - APPLICATION_HOSTS=localhost,::1,127.0.0.1,${DAWARICH_HOST_NAME:-dawarich}.${HOST_DOMAIN}
      - TIME_ZONE=${TZ}
      - APPLICATION_PROTOCOL=http
      # Can be either km or mi
      - DISTANCE_UNIT=${DAWARICH_DISTANCE_UNIT:-mi}
      - PROMETHEUS_EXPORTER_ENABLED=false
      - PROMETHEUS_EXPORTER_HOST=0.0.0.0
      - PROMETHEUS_EXPORTER_PORT=9394
      - SECRET_KEY_BASE=${DAWARICH_SECRET_KEY_BASE:-1234567890}
      - RAILS_LOG_TO_STDOUT="true"
      # SMTP settings
      - SMTP_SERVER=${DAWARICH_SMTP_SERVER}
      - SMTP_PORT=${DAWARICH_SMTP_PORT}
      - SMTP_USERNAME=${DAWARICH_SMTP_USERNAME}
      - SMTP_PASSWORD=${DAWARICH_SMTP_PASSWORD}
      - SMTP_FROM=${DAWARICH_SMTP_FROM}
      - SMTP_DOMAIN=${DAWARICH_SMTP_DOMAIN}
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "5"
    healthcheck:
      test:
        [
          "CMD-SHELL",
          "wget -qO - http://127.0.0.1:3000/api/v1/health | grep -q '\"status\"\\s*:\\s*\"ok\"'",
        ]
      interval: 10s
      retries: 30
      start_period: 30s
      timeout: 10s
    depends_on:
      dawarich_db:
        condition: service_healthy
        restart: true
      dawarich_redis:
        condition: service_healthy
        restart: true
    deploy:
      resources:
        limits:
          cpus: "0.50" # Limit CPU usage to 50% of one core
          memory: "4G" # Limit memory usage to 2GB
    labels:
      - joyride.host.name=${DAWARICH_HOST_NAME:-dawarich}.${HOST_DOMAIN}
      - traefik.enable=${DAWARICH_TRAEFIK_ENABLED:-true}
      - traefik.http.routers.dawarich.entrypoints=websecure
      - traefik.http.routers.dawarich.rule=Host(`${DAWARICH_HOST_NAME:-dawarich}.${HOST_DOMAIN}`)
      # - traefik.http.services.dawarich.loadbalancer.server.scheme=https # enable if the service wants to connect over https
      - traefik.http.services.dawarich.loadbalancer.server.port=3000
      - com.centurylinklabs.watchtower.enable=${DAWARICH_WATCHTOWER_ENABLED:-true}
      - autoheal=${DAWARICH_AUTOHEAL_ENABLED:-true}

  dawarich_sidekiq:
    image: freikin/dawarich:${DAWARICH_DOCKER_TAG:-latest}
    container_name: dawarich_sidekiq
    volumes:
      - ./etc/dawarich/public:/var/app/public
      - ./etc/dawarich/watched:/var/app/tmp/imports/watched
      - ./etc/dawarich/storage:/var/app/storage
    networks:
      - traefik
    stdin_open: true
    tty: true
    entrypoint: sidekiq-entrypoint.sh
    command: ["bundle", "exec", "sidekiq"]
    restart: on-failure
    environment:
      - RAILS_ENV=production
      - REDIS_URL=redis://dawarich_redis:6379/0
      - DATABASE_HOST=dawarich_db
      - DATABASE_PORT=5432
      - DATABASE_USERNAME=${DAWARICH_POSTGRES_USER:-postgres}
      - DATABASE_PASSWORD=${DAWARICH_POSTGRES_PW:-password}
      - DATABASE_NAME=dawarich_production
      - APPLICATION_HOSTS=localhost,::1,127.0.0.1,${DAWARICH_HOST_NAME:-dawarich}.${HOST_DOMAIN}
      - BACKGROUND_PROCESSING_CONCURRENCY=10
      - APPLICATION_PROTOCOL=http
      - DISTANCE_UNIT=km
      - PROMETHEUS_EXPORTER_ENABLED=false
      - PROMETHEUS_EXPORTER_HOST=dawarich
      - PROMETHEUS_EXPORTER_PORT=9394
      - SECRET_KEY_BASE=${DAWARICH_SECRET_KEY_BASE:-1234567890}
      - RAILS_LOG_TO_STDOUT="true"
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "5"
    healthcheck:
      test:
        ["CMD-SHELL", "bundle exec sidekiqmon processes | grep $${HOSTNAME}"]
      interval: 10s
      retries: 30
      start_period: 30s
      timeout: 10s
    depends_on:
      dawarich_db:
        condition: service_healthy
        restart: true
      dawarich_redis:
        condition: service_healthy
        restart: true
      dawarich:
        condition: service_healthy
        restart: true
    deploy:
      resources:
        limits:
          cpus: "0.50" # Limit CPU usage to 50% of one core
          memory: "4G" # Limit memory usage to 2GB

  dawarich_redis:
    image: redis:7.4-alpine
    container_name: dawarich_redis
    command: redis-server
    networks:
      - traefik
    volumes:
      - ./etc/dawarich/redis:/var/shared/redis
    restart: always
    healthcheck:
      test: ["CMD", "redis-cli", "--raw", "incr", "ping"]
      interval: 10s
      retries: 5
      start_period: 30s
      timeout: 10s

  dawarich_db:
    image: postgis/postgis:17-3.5-alpine
    shm_size: 1G
    container_name: dawarich_db
    volumes:
      - ./etc/dawarich/db:/var/lib/postgresql/data
    networks:
      - traefik
    environment:
      - POSTGRES_USER=${DAWARICH_POSTGRES_USER:-postgres}
      - POSTGRES_PASSWORD=${DAWARICH_POSTGRES_PW:-password}
      - POSTGRES_DB=dawarich_production
    restart: always
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "postgres"]
      interval: 10s
      retries: 5
      start_period: 30s
      timeout: 10s

And here are the environment variables that I have set.

DAWARICH_SMTP_SERVER=mail.mydomain.net
DAWARICH_SMTP_PORT=465
DAWARICH_SMTP_USERNAME=no-reply@mydomain.net
DAWARICH_SMTP_PASSWORD=<your password here>
DAWARICH_SMTP_FROM=no-reply@mydomain.net
DAWARICH_SMTP_DOMAIN=mydomain.net
DAWARICH_HOST_NAME=trips
DAWARICH_POSTGRES_PW=changeme
HOST_DOMAIN=mydomain.net
DAWARICH_SECRET_KEY_BASE=changeme # you can generate this with openssl rand -hex 32

Configuration

Most of the configuration is done for you already via the provided environment variables.

I will also note here that while I’ve included the settings for SMTP - I have yet to actually get it working.

From what I understand, SMTP support is relatively new to this application, so it could be either me being hamfisted, or an actual bug. I have not sorted that out yet.

But it’s not critical, so I chose to leave it there and move on.

The default username and password are demo@dawarich.app and password. Obviously we’ll need to change this… but this is more complicated than you might expect, as I’ll get to in a moment.

Nitpicks

User management in the Dawarich web UI is extremely basic, almost to the point of being useless. The only thing you can do is create a new, unprivileged user.

If you want to create a new admin account and get rid of the default one, you’ll have to drop into the Ruby console for that.

This is detailed on their website, but it’s not ideal.

Fixes

To create a new admin user

First, create a new user from the web interface.

Then do the following steps on the command line:

# Shell into the container
docker exec -it dawarich_app /bin/sh
# Enter the Ruby console
bin/rails console

# Promote your user to admin
User.find_by(email: 'user@example.com').update(admin: true)
# Exit the ruby console.
exit

If you’d like to delete the default admin user (and I recommend that you do) enter this command before exiting the Ruby console:

User.find_by(email: 'demo@dawarich.app').destroy

Using Dawarich with OwnTracks

Using Dawarich with OwnTracks is quite straightforward.

Get API URL

Log into the Dawarich web interface.
Click on your email address in the top right hand side of the page and go to Account.
From there you can copy the API URL example they’ve provided for OwnTracks.

Configuring the app

Install the app on your smartphone from your app store of choice (I like using F-Droid whenever possible) and then go into Preferences
In Preferences, click on Connection
Change the Mode to HTTP
Enter the URL into the provided field.
You do not need to set a username and password under Credentials - the URL you copied earlier contains the needed API key for authentication.