[Docker] [alle OS] Het grote Docker ervaringen en tips topic

[Mars Warrior]

Haha @blackd , nog meer input voor mijn arme hersentjes

Vwb betreft je probleem of omweg om de keys te kunnen lezen in je .env file: daarvoor wil ik dus SOPS gebruiken. De keys blijven volledig leesbaar, enkel de values worden geencrypt.

Zo'n bestand kun je dus ook gewoon in Git gooien. Niemand kan er wat mee. Decrypten is met je SSH key, die je toch nodig hebt voor Ansible om te kunnen deployen. Dus onderdeel van de Action of een Playbook

Nergens dus een bestand met leesbare secrets, zeker niet als je met vscode edit: die en/decrypt automatisch vanuit de editor. Je kunt meerdere SSH Keys gebruiken, dus dat is ook nog een plus vind ik.

En het is nu Vroooeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeem tijd

[blackd]

@Mars Warrior Ja, dat kan natuurlijk ook. Maar dat kan met Ansible Vault ook.
Ik heb ervoor gekozen om alle secrets in 1 yaml bestand te zetten en die in zijn geheel te encrypten.

Houd er in de keuze van je oplossing wel rekening mee of je nog andere tooling gebruikt om je bestanden te verwerken. Je hebt al VSCode benoemd. Maar ik draai zelf Ansible Lint en Docker Compose Lint (ook als GitHub action) bij elke pull request om de repo te valideren. Ansible Lint ondersteunt ook Ansible Vault.
https://docs.ansible.com/projects/lint/
https://docs.ansible.com/projects/lint/usage/#vaults

[alex3305]

T.a.v. het cachen van Ansible nog een tip, ik heb een eigen docker container in beheer (gebaseerd op ansible-dev-tools container) die ik zowel als devcontainer in VSCode gebruik als base image voor mijn Self hosted runner. Hier heb ik de versies van Python, Ansible, Ansible Lint, mijn gebruikte Galaxy Collections en pip dependencies in gefixeerd. Ik onderhoud deze docker container in een aparte repository en bouw deze met Ansible Builder als een execution environment. Ik ben alleen niet heel gelukkig met Fedora als base os. Ik zou dit op termijn nog een keer willen omzetten naar een Debian based OS.
Je zou ervoor kunnen kiezen je runner (of dat nou Woodpecker is of een Github local runner) uit te laten voeren in een eigen container met daarin alle benodigde spullen al geïnstalleerd.

Dat heb ik ook een tijdje gehad, maar vond ik onhandig. Ik wil op mijn workstation niet per se afhankelijk zijn van Docker / devcontainers en/of Visual Studio Code. Ook wilde ik graag mijn Ansible requirements graag meenemen in de container. Daardoor had ik echter twee keer dezelfde dependencies in twee aparte repo's. Dat voelde niet zo lekker.

Ter referentie mijn Ansible Dockerfile

Docker:

FROM node:22.17-alpine

ADD requirements.txt requirements.yml /

RUN apk add --no-cache ca-certificates \
                       git \
                       python3 \
                       py3-pip \
                       openssh-client \
                       openssl \
                       rsync \
                       sshpass \
                       sudo \
    && \
    pip3 install --ignore-installed \
                 --break-system-packages \
                 -r /requirements.txt \
    && \
    ansible-galaxy install -r /requirements.yml \
    && \
    mkdir -p /ansible \
    && \
    rm -rf /root/.cache \
           /requirements.txt \
           /requirements.yml

WORKDIR /ansible

ENTRYPOINT ["ansible-playbook"]
CMD ["--version"]

De Node versie zou best geüpgraded mogen worden. In de requirements.txt had ik dan o.a. Ansible staan:

code:

ansible-core==2.18.6
ansible-lint==25.6.1

En in de requirements.yml stonden dan mijn (externe) roles en collections.

Ik regel dit dus nu in mijn Ansible / infra / Docker repo. Om toch repeatable builds te krijgen heb ik een aantal bestanden aangemaakt:

• .python-version
• requirements.txt
• requirements.yml

Bij het starten van de workflow gebruikt de Forgejo Act runner de generieke setup-python action. Die action gebruikt vervolgens het .python-version bestand om de Python versie te bepalen die geïnstalleerd wordt. Python wordt geïnstalleerd in de hosted tool cache die gedeeld wordt tussen builds. Dezelfde action zet direct ook een cache op voor Python requirements, waar Ansible ook in staat .

In dezelfde repo heb ik ook een setup.sh script staan voor op mijn workstation. Vanuit daar wordt, wanneer nodig, pyenv geïnstalleerd en geconfigureerd. Ik heb ook nog gekeken naar uv, maar dat project was nog niet volwassen genoeg om effectief te zijn. In datzelfde script installeer ik vervolgens wederom dependencies, maar dan dus in een virtualenv binnen pyenv. Ook controleert dit script op een vault pass en kan deze direct geconfigureerd worden. Afijn, alles om te starten.

[alex3305]

Mars Warrior schreef op zondag 7 december 2025 @ 13:59:
Zo'n [SOPS] bestand kun je dus ook gewoon in Git gooien. Niemand kan er wat mee. Decrypten is met je SSH key, die je toch nodig hebt voor Ansible om te kunnen deployen. Dus onderdeel van de Action of een Playbook

Dus hetzelfde als Ansible Vault, maar dan moet ik nog een extra tool hebben en integreert het niet lekker met Ansible .

Ik zou ook mijn SSH key kunnen gebruiken als vault pass. Dat is immers gewoon een string. Als je echter in een team werkt is dat onhandig. Bij mij is dit dus gewoon een shared secret die toevallig alleen ik gebruik.

blackd schreef op zondag 7 december 2025 @ 18:55:
@Mars Warrior Ja, dat kan natuurlijk ook. Maar dat kan met Ansible Vault ook.
Ik heb ervoor gekozen om alle secrets in 1 yaml bestand te zetten en die in zijn geheel te encrypten.

Ik heb per group en host vault bestanden. De setup die je eerder aangaf met mappings (bijv. vault.my_secret) gebruik ik expliciet niet. Ik heb liever expliciete variabelen, dus vault_my_secret. Dat komt omdat ik in het verleden wat nare ervaringen heb gehad met het samenvoegen van dergelijke objecten en onverwachte resultaten. Maar goed, dat is natuurlijk stijl .

Houd er in de keuze van je oplossing wel rekening mee of je nog andere tooling gebruikt om je bestanden te verwerken. Je hebt al VSCode benoemd. Maar ik draai zelf Ansible Lint en Docker Compose Lint (ook als GitHub action) bij elke pull request om de repo te valideren.

Bij elke push / PR draait Ansible Lint op mijn Git server:

YAML:

jobs:
  ansible-lint:
    name: Ansible Lint
    runs-on: ubuntu-latest

    steps:
      - name: ⤵️ Checkout repository
        uses: actions/checkout@1af3b93b6815bc44a9784bd300feb67ff0d1eeb3 # v6

      - name: 🏗️ Setup Ansible
        id: setup-ansible
        uses: ./.forgejo/actions/setup-ansible
        with:
          vault-pass: ${{ secrets.ANSIBLE_VAULT_KEY }}

      - name: 🕵️‍♀️ Run Ansible Lint
        run: ansible-lint
        env:
          ANSIBLE_VAULT_PASSWORD_FILE: >-
            ${{ steps.setup-ansible.outputs.vault-pass-file }}

ansible-lint zit namelijk in de requirements.txt en wordt standaard mee geïnstalleerd .

Ook gebruik ik pre-commit hooks om Ansible Lint te draaien voordat ik commit. Dat heeft ook al enkele oopsies voorkomen en was verrassend eenvoudig op te zetten. Tevens heb ik een eigen pre-commit hook gemaakt die controleert op Ansible Vault files en de commit abort wanneer ik dergelijke bestanden in plain text probeer te committen.

Docker Compose Lint lijkt me interessant, behalve dan dat ik dus mijn Compose bestanden maak met Jinja . Daar moet ik dus nog even vanaf zien. Anderzijds valideer ik Compose bestanden sowieso voor een Up.

[blackd]

alex3305 schreef op zondag 7 december 2025 @ 19:40:
Dat heb ik ook een tijdje gehad, maar vond ik onhandig. Ik wil op mijn workstation niet per se afhankelijk zijn van Docker / devcontainers en/of Visual Studio Code. Ook wilde ik graag mijn Ansible requirements graag meenemen in de container. Daardoor had ik echter twee keer dezelfde dependencies in twee aparte repo's. Dat voelde niet zo lekker.

Wat betreft het eerste, snap ik wat je zegt. Momenteel heb ik ook ansible gewoon nog 'lokaal' geinstalleerd staan.
Het had juist mijn voorkeur om overal exact dezelfde dependencies te hebben. Zowel in CI als lokaal in development.

Ik heb nu inderdaad requirements.yml dubbel geadministreerd staan, dat vind ik wel jammer aan deze setup. Ansible-Lint heeft 'm ook gewoon in de project dir nodig.
Mijn oplossing: een sync d.m.v. een github action van de ene repo naar de andere met deze action.

Ik had eerst de execution environment in dezelfde repo staan (geinspireerd door dbrennand op GitHub) maar dat werd een rommeltje met twee aparte releases in 1 project.

alex3305 schreef op zondag 7 december 2025 @ 19:48:
Ook gebruik ik pre-commit hooks om Ansible Lint te draaien voordat ik commit. Dat heeft ook al enkele oopsies voorkomen en was verrassend eenvoudig op te zetten. Tevens heb ik een eigen pre-commit hook gemaakt die controleert op Ansible Vault files en de commit abort wanneer ik dergelijke bestanden in plain text probeer te committen.

Dat staat nog op mijn wensenlijstje.

Docker Compose Lint lijkt me interessant, behalve dan dat ik dus mijn Compose bestanden maak met Jinja . Daar moet ik dus nog even vanaf zien. Anderzijds valideer ik Compose bestanden sowieso voor een Up.

Ik template ook mijn Compose bestanden maar het enige wat er eigenlijk gevuld wordt zijn de standaard variabelen (${}) en die worden weer gevoed door het .env bestand. En die template ik ook, die wordt gevoed door Ansible.

Voorbeeldje docker-compose.yml in jellyfin role (snippet):

YAML:

services:
  jellyfin:
    image: jellyfin/jellyfin:10.11.4@sha256:aab0b50a3ce43a41621fc7040a379cc57174059aec8f9c17a90176649a0c1ab1
    container_name: jellyfin
    volumes:
      - ${HOST_VOLUME_CONFIG}:/config
      - ${HOST_VOLUME_CACHE}:/cache
      - ${HOST_VOLUME_MEDIA}:/media

.env.j2

YAML:

HOST_VOLUME_CONFIG="{{ jellyfin__compose_volume_config }}"
HOST_VOLUME_CACHE="{{ jellyfin__compose_volume_cache }}"
HOST_VOLUME_MEDIA="{{ jellyfin__compose_volume_media }}"

[alex3305]

blackd schreef op zondag 7 december 2025 @ 20:29:
[...]

Wat betreft het eerste, snap ik wat je zegt. Momenteel heb ik ook ansible gewoon nog 'lokaal' geinstalleerd staan.
Het had juist mijn voorkeur om overal exact dezelfde dependencies te hebben. Zowel in CI als lokaal in development.

Yes. Maar dat heb ik dus . Want lokaal gebruik ik pyenv met een virtualenv die met pip de requirements.txt installeert met daarin o.a. Ansible Core en Ansible Lint. En de CI omgeving doet setup-python hetzelfde. Allebei maken ze gebruik van dezelfde python versie dmv het .python-version bestand. Renovate update hier (wederom) de dependencies.

Ik vind het overigens een voordeel om lokaal geen globale Ansible meer te hebben. Dan kan ik ook niet per abuis een verkeerde of oude versie gebruiken.

Dat staat nog op mijn wensenlijstje.

.pre-commit-config.yaml

YAML:

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v6.0.0
    hooks:
      - id: check-shebang-scripts-are-executable
      - id: detect-private-key
      - id: end-of-file-fixer
      - id: trailing-whitespace

  - repo: https://github.com/ansible/ansible-lint
    rev: v25.12.0
    hooks:
      - id: ansible-lint

In de requirements.txt zit pre-commit==4.5.0 en activeren is dan niets meer dan pre-commit install.

Ik template ook mijn Compose bestanden maar het enige wat er eigenlijk gevuld wordt zijn de standaard variabelen (${}) en die worden weer gevoed door het .env bestand. En die template ik ook, die wordt gevoed door Ansible.

Ik template de Compose bestanden zelf ook. Best uitgebreid overigens . Recent ben ik wat met Ghost in de weer geweest en dan komt er zoiets uit. Dit is een snippet als voorbeeld:

YAML:

#jinja2: lstrip_blocks: True, trim_blocks: True
---
{{ ansible_managed | comment }}

name: {{ _compose_stack_name }}

services:
  ghost:
    container_name: ${COMPOSE_PROJECT_NAME}
    image: ghost:6.10.0-alpine
    environment:
      NODE_ENV: production
      url: ${GHOST_URL}
      database__client: mysql
      database__connection__host: database
      database__connection__user: ${DATABASE_USERNAME}
      database__connection__password: ${DATABASE_PASSWORD}
      database__connection__database: ${DATABASE_NAME}
    networks:
      ingress:
      internal:
    volumes:
      - {{ ghost_uploads_dir }}:/var/lib/ghost/content
    depends_on:
      database:
        condition: service_healthy
      {% if not ghost_use_hosted_activitypub %}
      activitypub:
        condition: service_started
        required: false
      {% endif %}
    {% if ghost_docker_options is defined %}
    {{ ghost_docker_options | to_nice_yaml | indent(4) }}
    {%- endif %}
    labels:
      traefik.enable: true
      traefik.http.routers.{{ _compose_stack_name }}.rule: "Host(`{{ ghost_domain }}`)"
      traefik.http.routers.{{ _compose_stack_name }}.middlewares: "anubis@docker"
      traefik.http.routers.{{ _compose_stack_name }}.service: "{{ _compose_stack_name }}"
      traefik.http.services.{{ _compose_stack_name }}.loadbalancer.server.port: "2368"
      {%- if _is_unraid +%}
      net.unraid.docker.icon: https://avatars.githubusercontent.com/u/2452804?s=200&v=4
      net.unraid.docker.managed: ansible
      net.unraid.docker.shell: /bin/bash
      {% endif %}

Secrets komen bij mij in de .env.j2 zodat deze niet direct zichtbaar zijn.

Conditionals zijn bij mij hier enorm belangrijk omdat ik afhankelijk van variabelen nog weleens het een of het andere uitrol. Bijvoorbeeld een adguard_home_sync op een secundaire node. Dan hoef ik geen twee Compose bestanden te onderhouden. Profielen zijn uiteraard ook nog een optie, maar dat vind ik niet heel transparent. Laatst heb ik daar wel meegespeeld in OpenCloud / OCIS, maar dan wordt het heel snel, heel complex. Met name als je geen of weinig ervaring in de desbetreffende repo hebt.

Bij de labels moet ik (helaas) de Jinja expressie gebruiken omdat Docker Compose ${COMPOSE_PROJECT_NAME} deze al literal neemt in de label naam . Volgens mij is dat niet zo bij de andere syntax, maar ik ga dat niet helemaal omgooien om zoiets doms.

Overigens is dit ook weer allemaal een kwestie van smaak en is het geheel uiteraard fluïde.

[Mars Warrior]

blackd schreef op zondag 7 december 2025 @ 20:29:
[...]
Voorbeeldje docker-compose.yml in jellyfin role (snippet):

YAML:

services:
  jellyfin:
    image: jellyfin/jellyfin:10.11.4@sha256:aab0b50a3ce43a41621fc7040a379cc57174059aec8f9c17a90176649a0c1ab1
    container_name: jellyfin
    volumes:
      - ${HOST_VOLUME_CONFIG}:/config
      - ${HOST_VOLUME_CACHE}:/cache
      - ${HOST_VOLUME_MEDIA}:/media

.env.j2

YAML:

HOST_VOLUME_CONFIG="{{ jellyfin__compose_volume_config }}"
HOST_VOLUME_CACHE="{{ jellyfin__compose_volume_cache }}"
HOST_VOLUME_MEDIA="{{ jellyfin__compose_volume_media }}"

W44r0m z0 dµßß13 0p?? W44r0m n13t m33t33n 1n d3 3nv f1l3 d3 ju1$t3 k3¥ v4|u3z?? Nu m00t j3 t0¢h 3 d1ng3n b1jh0µd3n!! D4t 0nt9a4t m1j 3v3n…

0ƒ h33ƒt d4t t3 m4k3n m3t d3 V4µ|t??

[blackd]

@alex3305 ja dat soort uitgebreidere jinja templating gebruik ik niet. Eigenlijk moet ik zeggen dat ik de template module gebruik, maar ik template niks, want ik kan net zo goed een copy doen. Anders snapt dclint het niet.

@Mars Warrior
In de .env file staan bij mij verschillende soorten waardes, bijv:
- secrets. Die staan zoals gezegd in een apart bestand bij mij.
- host afhankelijke waardes, die worden gevoed door group vars of host vars.

In dit voorbeeld staan absolute paden en die kunnen dus per host in theorie verschillend zijn. Dat wil je niet in je role vastleggen, die dient generiek te zijn.

Daarnaast kan ik de paden als het een variabele in ansible is, hergebruiken. Bijv voor aanmaken dataset, controleren permissies, dat soort zaken.

Ik ben overigens nog wel zoekende naar de juiste structuur qua variabelen. Ik heb laatst variabelen in playbooks gemigreerd naar group_vars. Maar e.e.a kan vast nog beter georganiseerd.

[alex3305]

blackd schreef op zondag 7 december 2025 @ 22:12:
@alex3305 ja dat soort uitgebreidere jinja templating gebruik ik niet. Eigenlijk moet ik zeggen dat ik de template module gebruik, maar ik template niks, want ik kan net zo goed een copy doen. Anders snapt dclint het niet.

Zo'n vermoeden had ik al . Daar is natuurlijk niets mis mee hè.

Ik gebruik de Jinja templates dus in Compose ook als feature toggles. Dat kan soms verdomde handig zijn. Alhoewel de andere kant van de medaille verbositeit is. Met andere woorden, meer code om hetzelfde of soms minder te bereiken . Komt er ook nog bij dat ik vanuit mijn werk enorm veel met Jinja heb gewerkt en er dus best aardig in ben, al zeg ik het zelf . En ik gebruik het veel in Home Assistant. Ik schrik er dus niet zo snel van.

Ik gebruik daarnaast in elke Compose _docker_options zodat ik CPUs en memory kan limiteren waar nodig. Dit doe ik o.a. voor stroombesparing.

Ik ben overigens nog wel zoekende naar de juiste structuur qua variabelen. Ik heb laatst variabelen in playbooks gemigreerd naar group_vars. Maar e.e.a kan vast nog beter georganiseerd.

Ik probeer variabelen zoveel mogelijk toe te passen waar ze horen. Serial numbers en keys horen IMHO niet bij een host, maar bij een groep. En dan eigenlijk zelfs de groep all. Immers veranderd de groepenstructuur in de inventory niets aan de toepasbaarheid van een dergelijke key. Mijn Maxmind GeoIP API sleutel gebruik ik dan zo:

YAML:

# group_vars/all/vault.yml
vault_maxmind_api_key: "secret string here..."

# group_vars/all/all.yml
maxmind_api_key: "{{ vault_maxmind_api_key }}"

# host_vars/leetower/maxmind_geoip.yml OF group_vars/docker/maxmind_geoip.yml
maxmind_geoip_api_key: "{{ maxmind_api_key }}"

De maxmind_geoip role op host leetower (of groep docker als je het op meerdere hosts gebruikt) vereist de API key geprefixed met de role_name. Maar die key hoort wat mij betreft niet bij de specifieke host of groep thuis, maar is algemeen voor mijn play(s).

Ook hier is het aardig verbose, maar zorgt het wat mij betreft wel voor de nodige duidelijkheid. En dat is met Ansible geen overbodige luxe .

[blackd]

alex3305 schreef op zondag 7 december 2025 @ 20:49:
Yes. Maar dat heb ik dus . Want lokaal gebruik ik pyenv met een virtualenv die met pip de requirements.txt installeert met daarin o.a. Ansible Core en Ansible Lint. En de CI omgeving doet setup-python hetzelfde. Allebei maken ze gebruik van dezelfde python versie dmv het .python-version bestand. Renovate update hier (wederom) de dependencies.

Ik wil de venv opzet toch nog wel een kans geven, ik had dat voorheen ook wel maar ik denk dat ik een paar stappen gemist heb om alle dependencies te fixeren en alle installaties te automatiseren. Bij de devcontainer loop ik ook wel tegen wat issues aan (vanwege het OS [Fedora] is feature/docker-outside-docker niet mogelijk en geknoei met permissies door verschillende gebruikers in de container vs op het host OS).
Misschien wil ik wel een hybride setup met lokaal een venv en op CI een docker container (met venv?).

Wat ik begrijp heb je dus Ansible-Core en Ansible-Lint in je requirements.txt staan en specificeer je de Python versie in .python-version.

Hoe zit dat dan met de Python versie? Van wat ik lees zul je de globale python versie (op je dev machine) dan in sync moeten houden met je CI build. Hoe pak je dat aan?

Edit:
Daarnaast heb ik ook nog andere dependencies die ik geinstalleerd moet hebben:
- GitHub CLI (via package manager)
- ACT (via GH CLI extension)
- Task (taskfile.dev) (via package manager)
- NPM
- DCLint (als NPM package)
- Renovate (als NPM package)

Voorheen heb ik een development playbook gemaakt waarin dit soort zaken geautomatiseerd geinstalleerd werden. Nu zit dat in mijn Execution Environment Docker image.

alex3305 schreef op maandag 8 december 2025 @ 11:54:
Ik probeer variabelen zoveel mogelijk toe te passen waar ze horen. Serial numbers en keys horen IMHO niet bij een host, maar bij een groep. En dan eigenlijk zelfs de groep all. Immers veranderd de groepenstructuur in de inventory niets aan de toepasbaarheid van een dergelijke key. Mijn Maxmind GeoIP API sleutel gebruik ik dan zo:

Ik heb API keys e.d. inderdaad in group_vars/all/main.yml en secrets in group_vars/all/secrets.yml en de encrypted versie in group_vars/all/vault.yml.

Daarnaast zoveel als mogelijk alle variabelen die nodig zijn voor de roles in group_vars/<groep>/<role>.yml.
De enige host_vars zijn ansible_host, ansible_user, ansible_password, ansible_connection en vergelijkbaar.

Qua inventory heb ik het ook geordend naar stage:

code:

inventories/
├── development
├── production
│   ├── group_vars
│   │   ├── all
│   │   └── <group>
│   └── host_vars
└── staging
    ├── group_vars
    │   ├── all
    │   └── <group>
    └── host_vars

Staging is voor mij een gevirtualiseerde evenknie van mijn productieomgeving.
Daar heb ik in VirtualBox een TrueNAS installatie draaien met dezelfde configuratie qua pools waarmee ik eenvoudig de Jail, Docker installatie en Docker Containers kan testen bij upgrades van TrueNAS.
Het liefst zou ik de group_vars op 1 plek hebben maar dat is me nog niet gelukt.

Maar stiekem heb ik nog wel wat variabelen in de roles/<role>/vars/main.yml zitten die ik een keer moet migreren naar de groep.
Zo heb ik sinds kort een docker groep gemaakt want ik had de Docker versies nog niet gefixeerd. Met de Traefik API compatibility issue liep ik daar snel tegenaan. Ik gebruik overigens de geerlingguy.docker role via Galaxy.

[ Voor 6% gewijzigd door blackd op 09-12-2025 10:47 ]

[alex3305]

blackd schreef op dinsdag 9 december 2025 @ 10:07:
[...]

Ik wil de venv opzet toch nog wel een kans geven, ik had dat voorheen ook wel maar ik denk dat ik een paar stappen gemist heb om alle dependencies te fixeren en alle installaties te automatiseren. Bij de devcontainer loop ik ook wel tegen wat issues aan (vanwege het OS [Fedora] is feature/docker-outside-docker niet mogelijk en geknoei met permissies door verschillende gebruikers in de container vs op het host OS).
Misschien wil ik wel een hybride setup met lokaal een venv en op CI een docker container (met venv?).

Wat ik begrijp heb je dus Ansible-Core en Ansible-Lint in je requirements.txt staan en specificeer je de Python versie in .python-version.

Yes .

requirements.txt

code:

ansible-core==2.20.0
ansible-dev-tools==25.12.0
ansible-lint==25.12.0
pre-commit==4.5.0
yamllint==1.37.1

.python-version

code:

3.14.2

En dit wordt wederom netjes bijgehouden met Renovate:

renovate.json

JSON:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "packageRules": [
    {
      "description": "Limit requirements to once a week",
      "matchFileNames": [
        "requirements.txt",
        "requirements.yml"
      ],
      "schedule": ["* * * * 3"]
    },
    {
      "description": "Update Python version",
      "matchFileNames": [".python-version"],
      "minimumReleaseAge": "30 days",
      "internalChecksFilter": "strict",
      "matchDatasources": ["python-version"]
    }
  ]
}

Waarbij ik dus afwachtend ben met het updaten van Python.

Hoe zit dat dan met de Python versie? Van wat ik lees zul je de globale python versie (op je dev machine) dan in sync moeten houden met je CI build. Hoe pak je dat aan?

Dat regel ik dus met pyenv. Die staat in mijn home directory en houdt net zoals bijvoorbeeld nvm voor Node een aparte Python environment bij. Installatie en configuratie is dood eenvouudig:

# Requirements installeren voor Debian
sudo apt update
sudo apt install build-essential gdb lcov \
                 pkg-config libbz2-dev libffi-dev libgdbm-dev \
                 libgdbm-compat-dev liblzma-dev libncurses5-dev \
                 libreadline6-dev libsqlite3-dev libssl-dev lzma lzma-dev \
                 tk-dev uuid-dev zlib1g-dev libmpdec-dev libzstd-dev

# pyenv automatic installer
curl -fsSL https://pyenv.run | bash

Waarna ik in mijn .zshrc pyenv configureer voor mijn shell:

Bash:

#!/bin/zsh
# shellcheck shell=zsh
#
# 3) .zshrc - Zsh file loaded for interactive shell sessions
#

ZDOTDIR="${ZDOTDIR:-$HOME}"

# Set the list of directories that zsh searches for commands.
path=(
  $HOME/{,s}bin(N)
  $HOME/.local/{,s}bin(N)
  $HOME/.pyenv/bin(N)
  $HOME/.dotnet/tools(N)
  /usr/local/{,s}bin(N)
  $path
)

# Pyenv
export PYENV_ROOT="$HOME/.pyenv"
eval "$(pyenv init --path)"

Mijn zsh configuratie heb ik in mijn dotfiles repo staan en de installatie van pyenv staat, zoals ik eerder al zei, in mijn infra repo. Ik heb daar een setup scriptje staan die alle benodigde dependencies automatisch kan installeren:


Op de CI omgeving zorgt de GitHub setup-python action voor de setup van de juiste Python versie op basis van het .python-version bestand:

quote: GitHub Setup Python Action

Basic usage
[...]
The python-version input is optional. If not supplied, the action will try to resolve the version from the default .python-version file. [...]

Python wordt hier in de hosted tool cache geïnstalleerd (en dus gecached), evenals de dependencies. Theoretisch is dat een security risico, maar dat neem ik voor lief.

Daarnaast heb ik ook nog andere dependencies die ik geinstalleerd moet hebben:
- GitHub CLI (via package manager)
- ACT (via GH CLI extension)
- Task (taskfile.dev) (via package manager)
- NPM
- DCLint (als NPM package)
- Renovate (als NPM package)

Ik beargumenteer niet dat alle packages verplicht in een venv moeten hè . Je mag best afhankelijk zijn van het OS of een externe package manager. Ik vind alleen de aanpak van een Docker container hier onnodig en onhandig. Evenals de afhankelijkheid van een devcontainer, aangezien dat weer redelijk afhankelijk is van VSCode. Ik vind een vendor lock-in van een editor namelijk nogal beroerd .

In mijn zsh omgeving heb ik sowieso nvm - en dus npm - geconfigureerd staan. De installatie van deze afhankelijkheden zou ik dus simpelweg meenemen in mijn setup script.

Voorheen heb ik een development playbook gemaakt waarin dit soort zaken geautomatiseerd geinstalleerd werden. Nu zit dat in mijn Execution Environment Docker image.

Staging is voor mij een gevirtualiseerde evenknie van mijn productieomgeving.
Daar heb ik in VirtualBox een TrueNAS installatie draaien met dezelfde configuratie qua pools waarmee ik eenvoudig de Jail, Docker installatie en Docker Containers kan testen bij upgrades van TrueNAS.
Het liefst zou ik de group_vars op 1 plek hebben maar dat is me nog niet gelukt.

Ja dat is leuk . Voor thuis heb ik alles fail-fast met één omgeving. Waarbij ik moet toegeven dat er over het algemeen bijzonder weinig kapot vliegt of langdurig kapot gaat. Door Renovate heb ik het vertrouwen om het op deze manier te doen. Rollbacks zijn namelijk triviaal geworden.

Ik gebruik overigens de geerlingguy.docker role via Galaxy.

Die kende ik niet. Mja, Jeff Geerling wel, maar niet zijn role. Wel grappig om te zien dat mijn role nagenoeg gelijk is aan zijn role .

[alex3305]

Even iets anders dan al het Ansible geweld . De laatste tijd krijg ik regelmatige vage foutmeldingen in mijn Forgejo Runner dind omgeving. Gisteren ben ik op speurtocht geweest en ben erachter gekomen dat het komt door cross compilen. Blijkbaar wordt de binfmt_misc kernel module niet meegenomen bij rootless dind . Ondanks een --privileged flag. Gek genoeg werkt het wel als ik een verse Alpine container maak met daarin bijv. Docker of podman.

Aan de hand daarvan was ik nog bezig gegaan met Docker Bake. Ik wil namelijk kijken of ik verschillende varianten van mijn container kan maken. In eerste instantie om mee te testen, maar daarna wellicht ook om uit te brengen.

Het ziet er allemaal leuk uit, maar eigenlijk vind ik het ook wel weer gedoe. Er wordt hcl gebruikt voor configuratie. Helemaal prima, behalve dan dat ik dat weer helemaal nergens anders gebruik .

Wel grappig want ik had op mijn persoonlijke issue lijst momenteel nog drie punten staan:

1. Docker bake uitproberen
2. Podman ipv dind uitproberen
3. ARM (qemu) builds fixen

En dat komt nu toevallig allemaal bij elkaar . Immers kan ik met een test met podman waarschijnlijk qemu oplossen of een workaround maken. En kan ik met Docker bake eenvoudig twee varianten bouwen zodat de oude versie niet breekt .

[blackd]

alex3305 schreef op dinsdag 9 december 2025 @ 12:10:
Dat regel ik dus met pyenv. Die staat in mijn home directory en houdt net zoals bijvoorbeeld nvm voor Node een aparte Python environment bij. Installatie en configuratie is dood eenvouudig:

Nice, pyenv had ik even gemist. Ik had in het verleden alleen een venv gemaakt met de standaard module in Python. Ik ga dit verder onderzoeken, bedankt!

Ik beargumenteer niet dat alle packages verplicht in een venv moeten hè . Je mag best afhankelijk zijn van het OS of een externe package manager.

Mijn doel is ook niet om het allemaal in een venv te proppen maar ik wil voor (mijzelf, haha) een eenvoudig en reproduceerbaar proces hebben om alles wat nodig is te installeren. Mag best global / system wide zijn, zolang ik maar dezelfde versies heb op mijn development laptop als op de CI omgeving.

Zoals ik zei heb ik Woodpecker gebruikt als CI tool, daarvoor wilde ik alles via Semaphore UI laten lopen. Dat was een drama wat betreft dependencies op de ansible control node, daar heb ik best e.e.a. voor moeten 'hacken'. Uiteindelijk draait je Ansible Playbook daar in een aparte container, waardoor je met een playbook getarget op 'local' ook de nodige dependencies kunt installeren. Alleen dat duurde op mijn machine allemaal best wel lang.

Hier komt ook mijn aversie tegen Bitwarden secrets terug, de installatie was een drama vanwege een bug die nog steeds open staat. En de oplossing? Een license file publiceren bij je volgende release. Door het ontbreken daarvan moest ik de SDK vanuit source installeren, waar weer de nodige dev dependencies voor nodig waren.

Ik vind alleen de aanpak van een Docker container hier onnodig en onhandig. Evenals de afhankelijkheid van een devcontainer, aangezien dat weer redelijk afhankelijk is van VSCode. Ik vind een vendor lock-in van een editor namelijk nogal beroerd .

Ik ben ook geen fan van vendor lock-in.
De container die ik heb ontwikkeld is wat dat betreft multi-purpose. Je kan hem als devcontainer gebruiken, je kan hem als container in GitHub Actions gebruiken en het is een execution environment voor Ansible Navigator. Voor dat laatste heb je nog steeds wel Python, Ansible-Navigator en Docker nodig.

Ja dat is leuk . Voor thuis heb ik alles fail-fast met één omgeving. Waarbij ik moet toegeven dat er over het algemeen bijzonder weinig kapot vliegt of langdurig kapot gaat. Door Renovate heb ik het vertrouwen om het op deze manier te doen. Rollbacks zijn namelijk triviaal geworden.

Ik ga ook niet elke wijziging via staging laten lopen, maar zoiets fundamenteels als het onderliggende OS updaten vind ik wel dusdanig dat ik dit eerst wat uitgebreider ga testen.
Door gebruik van Renovate is mijn update proces ook veel betrouwbaarder geworden. Ik auto merge alleen patch en digest updates, minor en hoger review ik altijd de release notes (door schade en schande wijs geworden). Met name de apps met databases is wat ingewikkelder updaten.

Ik kom van TrueNAS Scale in de tijd dat TrueCharts nog een ding was. Dit werd vrij rap niet meer ondersteund. Toen kwam jailmaker waarin ik docker kon draaien. Daarna ging TrueNAS scale ook naar docker bewegen voor ingebouwde apps (met hun eigen app-store). Ik kies er bewust voor dat niet meer te gebruiken maar alles in een aparte omgeving via Ansible te onderhouden om zo flexibel te blijven. Vooralsnog is 'Instances' in TrueNAS Scale experimenteel en werkt Jailmaker ook nog gewoon. Dus er zijn twee manieren om een omgeving te creëren op mijn TrueNAS machine waarin ik Docker + all mijn Compose projects kan uitrollen.

Die kende ik niet. Mja, Jeff Geerling wel, maar niet zijn role. Wel grappig om te zien dat mijn role nagenoeg gelijk is aan zijn role .

Hij heeft best handige roles en zijn content over Ansible vond ik erg leerzaam. Misschien nog een tip voor @Mars Warrior.

[alex3305]

blackd schreef op dinsdag 9 december 2025 @ 12:49:
Nice, pyenv had ik even gemist. Ik had in het verleden alleen een venv gemaakt met de standaard module in Python. Ik ga dit verder onderzoeken, bedankt!

Met standaard Python en venv is het inderdaad een groot drama. uv is the new kid on the block en daarmee dus ook fancy. Met mijn progressieve aanpak wilde ik die eigenlijk gebruiken. Vooral omdat ik dan een pyproject.toml of uv.toml kon toepassen. Dan zou ik ook geen extra requirements.txt meer hebben. Echter kreeg ik dat een paar maanden geleden niet lekker werkend met Ansible. Pyenv voldoet dan gewoon.

Mijn doel is ook niet om het allemaal in een venv te proppen maar ik wil voor (mijzelf, haha) een eenvoudig en reproduceerbaar proces hebben om alles wat nodig is te installeren. Mag best global / system wide zijn, zolang ik maar dezelfde versies heb op mijn development laptop als op de CI omgeving.

100%. Professioneel weet ik dat dat super waardevol is. Vandaar dat ik dat privé ook toepas. Het kost dan vooraf wellicht wat meer tijd om in te richten en op te zetten, dat verdien je op een later moment weer terug.

Ik kom van TrueNAS Scale in de tijd dat TrueCharts nog een ding was. Dit werd vrij rap niet meer ondersteund. Toen kwam jailmaker waarin ik docker kon draaien. Daarna ging TrueNAS scale ook naar docker bewegen voor ingebouwde apps (met hun eigen app-store). Ik kies er bewust voor dat niet meer te gebruiken maar alles in een aparte omgeving via Ansible te onderhouden om zo flexibel te blijven. Vooralsnog is 'Instances' in TrueNAS Scale experimenteel en werkt Jailmaker ook nog gewoon. Dus er zijn twee manieren om een omgeving te creëren op mijn TrueNAS machine waarin ik Docker + all mijn Compose projects kan uitrollen.

Ik heb dus destijds de Unraid afslag genomen. Met name omdat ik al enorm veel ervaring had met Docker, Docker Compose en Kubernetes. Daarom heeft TrueCharts mij dus nooit aangesproken en vond ik dat eigenlijk eerder een nadeel dan een voordeel . Dat is ook de reden dat ik Portainer niet (meer) gebruik. Portainer gebruikt namelijk ander jargon dan Docker en Compose. Dat stoort mij dan gigantisch.

[blackd]

alex3305 schreef op dinsdag 9 december 2025 @ 12:10:
.python-version

code:

3.14.2

[..]

Ik heb daar een setup scriptje staan die alle benodigde dependencies automatisch kan installeren:
[Afbeelding]

Op de CI omgeving zorgt de GitHub setup-python action voor de setup van de juiste Python versie op basis van het .python-version bestand:

Ik heb nu even als test .python-version toegevoegd in mijn repo en Renovate triggert daar op.
Ik gebruik het alleen nog niet in CI/lokaal om de Python versie gelijk te houden.

Hoe 'enforce' je dat je development machine ook dezelfde python versie gebruikt in jouw pyenv t.o.v. wat in de repo gedefinieerd staat? Want als Renovate triggert op een nieuwe Python versie zul je jouw pyenv virtualenv opnieuw moeten opbouwen neem ik aan?

[alex3305]

blackd schreef op woensdag 10 december 2025 @ 09:48:
Hoe 'enforce' je dat je development machine ook dezelfde python versie gebruikt in jouw pyenv t.o.v. wat in de repo gedefinieerd staat? Want als Renovate triggert op een nieuwe Python versie zul je jouw pyenv virtualenv opnieuw moeten opbouwen neem ik aan?

Dat klopt. Ik forceer het inderdaad niet, daar heb je helemaal gelijk in. Ik draai mijn setup script met enige regelmaat.

Je zou natuurlijk met Ansible pre_tasks kunnen controleren of de huidige Python versie gelijk is aan die in .python-version. Idem voor Ansible of andere pakketten.

Als alternatief zou je in zsh (waarschijnlijk ook in andere shells) een shell hook kunnen opzetten zodat bijv. pyenv geüpdatet wordt wanneer je in die directory komt. Dat doe ik al met oh-my-zsh en pyenv:

.oh-my-zsh/custom/python-venv.zsh

Bash:

#!/bin/zsh
# shellcheck shell=zsh
#
# python-venv.zsh - Automatically venv when possible!
# Source: https://dev.to/moniquelive/auto-activate-and-deactivate-python-venv-using-zsh-4dlm
#

python_venv() {
  MYVENV=./.venv

  # when you cd into a folder that contains $MYVENV
  [[ -d $MYVENV ]] && source $MYVENV/bin/activate > /dev/null 2>&1
  # when you cd into a folder that doesn't
  [[ ! -d $MYVENV ]] && deactivate > /dev/null 2>&1
}

autoload -U add-zsh-hook
add-zsh-hook chpwd python_venv

python_venv

En je zou dit ook in de editor (VSCode) kunnen regelen. Ik doe dat bijvoorbeeld voor mijn Home Assistant Configuration repository. Daar maak ik een aantal (mock) bestanden aan zodat de configuratie check in ieder geval werkt.

.vscode/tasks.json

JSON:

{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "setup",
            "type": "shell",
            "command": "./setup.sh",
            "runOptions": {
              "runOn": "folderOpen"
            },
            "presentation": {
              "echo": false,
              "reveal": "silent",
              "focus": false,
              "panel": "shared",
              "close": true,
            }
        }
    ]
}

Het is dus een klein beetje behelpen op sommige vlakken. Mijn oplossing is ook verre van perfect. Aan de andere kant zijn veranderingen veelal incrementeel. Immers accepteer ik expliciet bepaalde minor's. Dan is het dus ook niet bijster erg als ik een keer een versie achterloop, mits ik niet tegen problemen aanloop.

[blackd]

alex3305 schreef op zondag 7 december 2025 @ 20:49:
.pre-commit-config.yaml

Ook maar even opgezet:

YAML:

# See https://pre-commit.com for more information
# See https://pre-commit.com/hooks.html for more hooks
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v6.0.0
    hooks:
      - id: check-shebang-scripts-are-executable
      - id: detect-private-key
      - id: end-of-file-fixer
      - id: trailing-whitespace

  - repo: https://github.com/renovatebot/pre-commit-hooks
    rev: 42.52.4
    hooks:
      - id: renovate-config-validator

  - repo: https://github.com/docker-compose-linter/pre-commit-dclint
    rev: v3.1.0
    hooks:
      - id: dclint

  - repo: https://github.com/ansible/ansible-lint
    rev: v25.12.0
    hooks:
      - id: ansible-lint
        pass_filenames: true

  - repo: https://github.com/mpalmer/action-validator
    rev: v0.8.0
    hooks:
      - id: action-validator

Het meeste draait vrij snel (alleen changes). Over ansible-lint ben ik alleen nog niet heel tevreden..

Om vervolgens te gebruiken moet ik dat installeren, daarom in devcontainer.json:

YAML:

{
  [...]
  "postStartCommand": "pre-commit install"
}

NB: Mocht je een foutmelding krijgen over ontbrekende locale bij gebruik pre-commit, installeer dan glibc-langpack-en.

alex3305 schreef op woensdag 10 december 2025 @ 19:39:
Dat klopt. Ik forceer het inderdaad niet, daar heb je helemaal gelijk in. Ik draai mijn setup script met enige regelmaat.

Je zou natuurlijk met Ansible pre_tasks kunnen controleren of de huidige Python versie gelijk is aan die in .python-version. Idem voor Ansible of andere pakketten.

Heb ik ook aan zitten denken maar druist in tegen de manier waarop het bij mij nu werkt, ik laat de python en ansible versie in de docker container leidend zijn en verifieer of mijn playbook daarop runt.
Deze versies zijn embedded in de community-ansible-dev-tools docker image.

Ik heb geprobeerd om de dependencies geautomatiseerd te installeren maar kom dan vrij snel op het punt dat ik in mijn GitHub Self Hosted runner de workflow in een container wil runnen. Laat dat nou net mijn ansible-ee image kunnen zijn . Enige nadeel is zoals gezegd dat dit o.b.v. fedora is en niet debian/ubuntu.

Wat dat betreft kan een devcontainer wel snel een update van deze dependencies forceren. Zodra renovate een update ziet van een van de dependencies, wordt de PR gevalideerd en indien mogelijk automatisch gemerged. De nightly release produceert een nieuwe docker image. Deze wordt vervolgens in mijn playbook repo door Renovate getriggerd. Wanneer dit gemerged wordt naar main, wordt het ook doorgezet naar develop. Dan krijg ik gelijk van VSCode een melding of ik de container wil rebuilden.

Wat snippets van mijn ansible-ee repo:
execution-environment.yml

YAML:

--
version: 3

images:
  base_image:
    name: ghcr.io/ansible/community-ansible-dev-tools:v25.11.0@sha256:c3ee333e84517404d0940e9fd97b247b18cf60e957cbd1bb45e79ca84848beaa

dependencies:
  galaxy: requirements.yml
  python: requirements.txt

additional_build_steps:
  [..]

In de additional_build_steps installeer ik:

• glibc-langpack-en (via dnf)
• docker-ce-cli (via install script)
• nodejs npm (via dnf)
• gh-cli (via dnf)
• dclint (via npm)
• action-validator (via npm)

Sommige zaken zijn geversioneerd, nog niet alles.
Renovate pakt alleen de updates van base_image nog niet op dus ik moet nog even met de renovate config gaan stoeien.

Dit bouw ik dan met een GitHub Action. Daarin roep ik Ansible Builder aan. Ik gebruik daarbij wel docker/setup-buildx-action, docker/metadata-action en docker/build-push-action aangezien Ansible Builder onderwater gewoon docker build aanroept.

YAML:

[..]
    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@e468171a9de216ec08956ac3ada2f0791b6bd435 # v3
      id: docker_buildx
      with:
        platforms: linux/amd64,linux/arm64
[..]
    - name: Build Execution Environment image
      working-directory: .
      run: | 
        ansible-builder build \
          --container-runtime docker \
          --extra-build-cli-args "--load --builder ${{ steps.docker_buildx.outputs.name }} --platform linux/amd64"
[..]

De docker buildx builder wordt gebruikt bij het aanroepen van ansible-builder.
De output van deze stap wordt gecached in context/en wordt daarna opgepakt door o.a. docker/buld-push-action.

YAML:

    - name: Build and push
      uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83 # v6
      with:
        context: context/
        push: ${{ github.ref_type == 'tag' }}
        tags: ${{ steps.docker_meta.outputs.tags }}
        labels: ${{ steps.docker_meta.outputs.labels }}

Deze workflow draait bij elke pull request (zonder release) en bij elke tag (met release).

[blackd]

Sorry, nu weer wat meer Ansible en Python geweld.

alex3305 schreef op dinsdag 9 december 2025 @ 14:33:
Met standaard Python en venv is het inderdaad een groot drama. uv is the new kid on the block en daarmee dus ook fancy. Met mijn progressieve aanpak wilde ik die eigenlijk gebruiken. Vooral omdat ik dan een pyproject.toml of uv.toml kon toepassen. Dan zou ik ook geen extra requirements.txt meer hebben. Echter kreeg ik dat een paar maanden geleden niet lekker werkend met Ansible. Pyenv voldoet dan gewoon.

Ik las vandaag dat ansible-dev-environment onderwater uv gebruikt.
Het belooft met het commando ade Python, ansible en collections isolatie met venv support.
Wellicht is dat voor jou (nogmaals?) het onderzoeken waard?

alex3305 schreef op woensdag 10 december 2025 @ 19:39:
Je zou natuurlijk met Ansible pre_tasks kunnen controleren of de huidige Python versie gelijk is aan die in .python-version. Idem voor Ansible of andere pakketten.

Ik kwam vandaag een interessante pre-commit-hook tegen in bovengenoemde repo.
https://github.com/ansibl...in/.pre-commit-hooks.yaml

YAML:

---
- id: check-platform-constraints
  name: Check platform constraints and update renovate.json
  entry: check-platform-constraints
  language: python
  additional_dependencies: ["packaging>=23.2", "pyyaml"]
  files: ^pyproject\.toml$
  pass_filenames: false
  description: Validates dependencies against platform constraints and updates renovate.json

Het bijbehorende script: https://github.com/ansibl...k_platform_constraints.py

Python:

#!/usr/bin/env python3
"""Validate and enforce platform constraints.

This script:
1. Defines platform constraints as constants
2. Validates dependencies in pyproject.toml against these constraints
3. Updates renovate.json with allowedVersions rules to prevent automated bumps
"""

En de config met constraints:
https://github.com/ansibl.../platform-constraints.txt

code:

# Platform compatibility constraints for AAP and RHEL
# These represent the MAXIMUM versions we can use to remain compatible
# with downstream platform packages

# AAP 2.5/2.6 ships ansible-core 2.16.x
ansible-core<2.17

# RHEL 8/9 ships cffi 1.15.x
cffi<1.16

# RHEL 8/9 ships setuptools 65.5.1
setuptools<65.6

# galaxy-importer constraint
packaging<25.0

Een dergelijke aanpak is wellicht ook interessant.

[alex3305]

@blackd Zeker. Thanks voor je aanvullingen . Ik had je post eerder vandaag ook gelezen en met jouw aanpak is zeker niets mis. Alleen is het niet helemaal mijn smaak. Ik ben gewoon een beetje allergisch voor devcontainers (leuk om te noemen in het Docker topic ). Niet omdat het niet werkt of omdat het slecht is, maar vanwege het gedoe met containers op Windows al dan niet in combinatie met WSL(2). Ik wil mezelf die complexiteit liever niet meer op de hals halen. Althans niet nu.

blackd schreef op zondag 14 december 2025 @ 19:37:
Ik las vandaag dat ansible-dev-environment onderwater uv gebruikt.
Het belooft met het commando ade Python, ansible en collections isolatie met venv support.
Wellicht is dat voor jou (nogmaals?) het onderzoeken waard?

Misschien wel, maar voor nu werkt pyenv prima. Ik kan het issue zo 1-2-3 niet vinden...



Maar het ging er om dat tools niet zomaar geïnstalleerd konden worden vanuit een pyproject.toml. Wellicht is dat nu (een paar maanden later) wel het geval. Aangezien ik nu een degelijke setup heb laat ik het even zo .

Die pre-commit hook is nog wel een interessante. Dat zou je ook al quick and dirty kunnen doen

Bash:

$(python --version | awk '{print $2}') = $(cat .python-version) ] && echo "true" || echo "false"
# of 
$(python --version | awk '{print $2}') = $(cat .python-version) ] && exit 0 || exit 1

[Mars Warrior]

Mijn hoofd zit nog beetje vol van de afgelopen Forgejo/Ansible posts. Ik ga het voorlopig toch wat simpeler aanpakken. En pas daarna uitbouwen volgend jaar.

Daarom nog een wat info van CrowdSec, Alerts per dag en domein.
Des te roder, des te meer Alerts op dat domein op die dag. Groen is beter, en zwart is het beste, namelijk niks geen alerts!

Na de "massale" aanvallen van begin december (400-500 Alerts per dag) stapsgewijs wat maatregelen genomen:

• Handmatige block van het verre oosten (Japan, Singapore, Zuid-Korea, India, Australie, etc.) voor de MICROSOFT ASN en AMAZON-02 ASN. Het gros van de Alerts kwam uit deze ASNs namelijk
• Scripten - elke dag via cron - van de actuele Abuse Ip database richting CrowdSec. Deze lijst is actueel.

Het resultaat mag er zijn zou ik zeggen. Bijna niks meer op de domeinen (de regels onder <ip>).
Het aantal decisions/bans per dag is nu op een paar vingers te tellen



Dat wordt natuurlijk veroorzaakt doordat de firewall het overgrote deel van het verkeer blokkeert. En dan met name de cscli-import blocklist met ca 70.000 extra decisions bovenop de CAPI lijst van 15.000.

• De firewall laat een aardige toename richting 4.000 - 5.000 drops per dag zien
• Het cscli-import deel is sommige dagen voor 90-95% verantwoordelijk voor het aantal drops. Die actuele lijsten werken dus perfect!
• De CAPI lijst doet steeds minder. Het was ooit ca 30%, en laatste tijd rond de 5%. Vanaf laatste week november ben ik al zelf lijsten gaan toevoegen als test. Die overlappen blijkbaar enorm met de CAPI lijst.

Oftewel: ook met publiek verkrijgbare lijsten kun je een goede verdediging opbouwen.
Je hebt echt geen abbo van CrowdSec nodig. Het is natuurlijk wel extra werk, maar als het eenmaal draait, draait het. En ik update nu 1x per dag, terwijl die lijsten vaak 1x per uur of 30 minuten geactualiseerd worden. Het kan dus nog beter.

[DjoeC]

Ik ben met allerlei aanpassingsklusjes bezig zoals het optuigen van een nieuwe Docker omgeving. Tot heden gebruik ik voor de netwerking een user_bridge omdat die communicatie tussen containers mogelijk maakt. Ik kan die containers natuurlijk ook via <host>:<gemapte poort> bereiken, maar ik zou graag willen dat ik een flink aantal containers - zoals Mariadb - zowel vanuit de rest van het netwerk als onderling in Docker via een hostnaam mariradb1.mijn.lan kan bereiken.

Ik meen dat dit ook met userbridge ooit gewerkt heeft door in mijn lokale dns die hostnaam op te nemen met het IP adres van de Docker machine maar dat lijkt niet altijd te werken.... Pihole heb ik al heel lang draaien op een macvlan met eigen IP adres.

De vraag: Is het gebruik van macvlan een "slechte" gewoonte, zo ja waarom, zo nee waarom niet? Voor mij lijkt het voordeel dat de container met macvlan op elke willekeurige machine in de lucht kan komen terwijl dat met user_bridge niet zo is.... Zijn er simpele, werkbare alternatieven?

[Mars Warrior]

@DjoeC. Is Traefik een optie om als L4 proxy te laten fungeren?

Dat deed ik voorheen met de Caddy L4 plug-in met de nodige beperkingen. Nu met Traefik
Nog niet gebruikt.

Je hebt dan altijd een centraal toegangspunt en ook een URL.

[DjoeC]

Mars Warrior schreef op zondag 4 januari 2026 @ 17:06:
@DjoeC. Is Traefik een optie om als L4 proxy te laten fungeren?

Dat deed ik voorheen met de Caddy L4 plug-in met de nodige beperkingen. Nu met Traefik
Nog niet gebruikt.

Je hebt dan altijd een centraal toegangspunt en ook een URL.

Tja, ik gebruik nu NPM als reverse proxy. Die zal ook wel wat dingen kunnen (en gebruik ik ook af en toe wat truukerig) maar ik wilde dit eigenlijk in Docker zelf oplossen omdat het naar mijn idee ook een Docker uitdaging is. Een extra stap ertussen of erbij doe ik liever niet

Ik gebruik NPM o.a. om de verschillende webinterfaces van binnenuit en soms ook van buitenuit bereikbaar te maken. Maar om dat ook voor databases en MQTT etc in te zetten gaat me wel wat ver.

[ Voor 13% gewijzigd door DjoeC op 04-01-2026 17:31 ]

[Mars Warrior]

DjoeC schreef op zondag 4 januari 2026 @ 17:30:
[...]

Tja, ik gebruik nu NPM als reverse proxy. Die zal ook wel wat dingen kunnen (en gebruik ik ook af en toe wat truukerig) maar ik wilde dit eigenlijk in Docker zelf oplossen omdat het naar mijn idee ook een Docker uitdaging is. Een extra stap ertussen of erbij doe ik liever niet

Ik gebruik NPM o.a. om de verschillende webinterfaces van binnenuit en soms ook van buitenuit bereikbaar te maken. Maar om dat ook voor databases en MQTT etc in te zetten gaat me wel wat ver.

Aha. Het was maar een idee.

Voorheen gebruikte ik ook macvlan. Werkte goed. Maar ik wilde meer afscherming en eenvoud.

En de meeste databases die ik gebruik hebben een webconsole. Dus altijd via Traefik intern bereikbaar via een URL.

[DjoeC]

Mars Warrior schreef op zondag 4 januari 2026 @ 22:28:
[...]

Aha. Het was maar een idee.

Voorheen gebruikte ik ook macvlan. Werkte goed. Maar ik wilde meer afscherming en eenvoud.

En de meeste databases die ik gebruik hebben een webconsole. Dus altijd via Traefik intern bereikbaar via een URL.

Dan moet ik me echt wat meer in Traefik of Caddy gaan verdiepen. NPM vind ik heerlijk snel in te richten, lets encrypt werkt feilloos en ook de accesslijsten ben ik blij mee.. Maar misschien mis ik iets dat nog beter en toch simpel werkt.....

[CH4OS]

DjoeC schreef op zondag 4 januari 2026 @ 16:50:
Ik ben met allerlei aanpassingsklusjes bezig zoals het optuigen van een nieuwe Docker omgeving. Tot heden gebruik ik voor de netwerking een user_bridge omdat die communicatie tussen containers mogelijk maakt. Ik kan die containers natuurlijk ook via <host>:<gemapte poort> bereiken, maar ik zou graag willen dat ik een flink aantal containers - zoals Mariadb - zowel vanuit de rest van het netwerk als onderling in Docker via een hostnaam mariradb1.mijn.lan kan bereiken.

Ik meen dat dit ook met userbridge ooit gewerkt heeft door in mijn lokale dns die hostnaam op te nemen met het IP adres van de Docker machine maar dat lijkt niet altijd te werken.... Pihole heb ik al heel lang draaien op een macvlan met eigen IP adres.

De vraag: Is het gebruik van macvlan een "slechte" gewoonte, zo ja waarom, zo nee waarom niet? Voor mij lijkt het voordeel dat de container met macvlan op elke willekeurige machine in de lucht kan komen terwijl dat met user_bridge niet zo is.... Zijn er simpele, werkbare alternatieven?

Wat bedoel je met user_bridge? Je kunt, in combinatie met docker compose toch ook gewoon gemakkelijk werken met diverse interne en externe netwerken? Dan hoef je niet eens poorten te forwarden, containers op hetzelfde netwerk kunnen elkaar dan ook bereiken, zonder een port forward hoeven in te stellen, dat lijkt mij dus een veel minder complexe methode, ik gebruik het best veel. Met macvlan heb ik in elk geval nog nooit hoeven werken. Enige is af en toe network_mode: host (en dan moet je wel poorten forwarden), maar dat is het dan wel.

Ik begrijp niet helemaal waarom je direct wilt kunnen verbinden met een database in Docker, laat dat lekker aan de applicaties (waarvoor je de database nodig hebt) over...

[ Voor 3% gewijzigd door CH4OS op 05-01-2026 01:39 ]

[CH4OS]

Mars Warrior schreef op woensdag 17 december 2025 @ 14:22:
Mijn hoofd zit nog beetje vol van de afgelopen Forgejo/Ansible posts. Ik ga het voorlopig toch wat simpeler aanpakken. En pas daarna uitbouwen volgend jaar.

Daarom nog een wat info van CrowdSec, Alerts per dag en domein.
Des te roder, des te meer Alerts op dat domein op die dag. Groen is beter, en zwart is het beste, namelijk niks geen alerts!

Na de "massale" aanvallen van begin december (400-500 Alerts per dag) stapsgewijs wat maatregelen genomen:

• Handmatige block van het verre oosten (Japan, Singapore, Zuid-Korea, India, Australie, etc.) voor de MICROSOFT ASN en AMAZON-02 ASN. Het gros van de Alerts kwam uit deze ASNs namelijk
• Scripten - elke dag via cron - van de actuele Abuse Ip database richting CrowdSec. Deze lijst is actueel.

Het resultaat mag er zijn zou ik zeggen. Bijna niks meer op de domeinen (de regels onder <ip>).
Het aantal decisions/bans per dag is nu op een paar vingers te tellen

[Afbeelding]

Dat wordt natuurlijk veroorzaakt doordat de firewall het overgrote deel van het verkeer blokkeert. En dan met name de cscli-import blocklist met ca 70.000 extra decisions bovenop de CAPI lijst van 15.000.

• De firewall laat een aardige toename richting 4.000 - 5.000 drops per dag zien
• Het cscli-import deel is sommige dagen voor 90-95% verantwoordelijk voor het aantal drops. Die actuele lijsten werken dus perfect!
• De CAPI lijst doet steeds minder. Het was ooit ca 30%, en laatste tijd rond de 5%. Vanaf laatste week november ben ik al zelf lijsten gaan toevoegen als test. Die overlappen blijkbaar enorm met de CAPI lijst.

Oftewel: ook met publiek verkrijgbare lijsten kun je een goede verdediging opbouwen.
Je hebt echt geen abbo van CrowdSec nodig. Het is natuurlijk wel extra werk, maar als het eenmaal draait, draait het. En ik update nu 1x per dag, terwijl die lijsten vaak 1x per uur of 30 minuten geactualiseerd worden. Het kan dus nog beter.

[Afbeelding]

Ik ben wel benieuwd hoe je CrowdSec aan de praat hebt gekregen. Ik heb een poosje terug dit ook gebruikt, maar na verloop van tijd stopte het gewoon met werken, bleek de API key ongeldig of zo. Omdat ik het vervolgens niet 1 2 3 meer aan de praat kreeg, maar wel services had die ik wel bereikbaar wilde hebben, heb ik daarom de filtering nu anders opgelost. Maar voor de services die ik wel publiekelijk heb nog, wil ik wel CrowdSec nog tussen zetten. Ik zou CrowdSec dan als plug-in gebruiken voor Traefik, aangezien ik nog geen (dedicated) firewall (ik ben van plan een OpnSense doos neer te gaan zetten ergens dit jaar) heb.

[DjoeC]

CH4OS schreef op maandag 5 januari 2026 @ 01:33:
[...]

Wat bedoel je met user_bridge? Je kunt, in combinatie met docker compose toch ook gewoon gemakkelijk werken met diverse interne en externe netwerken? Dan hoef je niet eens poorten te forwarden, containers op hetzelfde netwerk kunnen elkaar dan ook bereiken, zonder een port forward hoeven in te stellen, dat lijkt mij dus een veel minder complexe methode, ik gebruik het best veel. Met macvlan heb ik in elk geval nog nooit hoeven werken. Enige is af en toe network_mode: host (en dan moet je wel poorten forwarden), maar dat is het dan wel.

Ik begrijp niet helemaal waarom je direct wilt kunnen verbinden met een database in Docker, laat dat lekker aan de applicaties (waarvoor je de database nodig hebt) over...

user_bridge is/was noodzakelijk omdat de "normale" docker bridge mode bij aanvang van mijn docker reis geen contacten tussen containers/services toeliet. Mogelijk is dat veranderd of heb ik nog steeds het hele docker netwerk geneuzel niet door

Netwerk mode Host ken ik (nog) niet. Zal me eens inlezen.

Database: Benaderen vanaf Windows machines, andere SBC's. Mosquitto idem en vanaf ESP bordjes, etc. Er is voor mij wel degelijk een reden om in containers draaiende applicaties vanaf extern, maar ook vanaf intern (andere containerized applicaties zoals Nextcloud, eigen domotica, weerstation, etc.) te kunnen benaderen. Ik wil gewoon 1 database (eventueel als failsafe over 2 instanties op 2 docker hosts), 1 Mosquitto gekoppeld over 2 of meer instanties (dat werkt best mooi) etc. Ofwel: ik weet eigenlijk wat ik wil maar nog niet altijd hoe het slim en eenvoudig onderhoudbaar op te zetten is. Linux, Docker en nog veel meer zijn mijn hobby en niet mijn vak. Vragen om tips en weer veel lezen en leren dus....

[Mars Warrior]

CH4OS schreef op maandag 5 januari 2026 @ 01:43:
[...]
Ik ben wel benieuwd hoe je CrowdSec aan de praat hebt gekregen. Ik heb een poosje terug dit ook gebruikt, maar na verloop van tijd stopte het gewoon met werken, bleek de API key ongeldig of zo. Omdat ik het vervolgens niet 1 2 3 meer aan de praat kreeg, maar wel services had die ik wel bereikbaar wilde hebben, heb ik daarom de filtering nu anders opgelost. Maar voor de services die ik wel publiekelijk heb nog, wil ik wel CrowdSec nog tussen zetten. Ik zou CrowdSec dan als plug-in gebruiken voor Traefik, aangezien ik nog geen (dedicated) firewall (ik ben van plan een OpnSense doos neer te gaan zetten ergens dit jaar) heb.

Er is een CrowdSec plugin/middleware voor Traefik die wordt aanbevolen. Die heb ik gewoon gebruikt. Dat werkt al probleemloos sinds vorig jaar oktober.

Ik ben daarnaast de firewall docker container (iptables) gaan gebruiken van CrowdSec en dat werkt ook probleemloos. Omdat bijna alles op één server draait heb ik ook geen behoefte aan een externe firewall. Alle bans en allowlists (voorheen whitelists) komen automagisch in de firewall terecht.

Door gebruik te maken van externe blocklists die je met een import decisions inleest (helaas geen ondersteuning voor eigen blocklists, zal wel een commerciële reden hebben) heb ik het aantal events/alerts/decisions van CrowdSec zelf drastisch kunnen verlagen: op sommige dagen met 100%



De effectiviteit van de firewall is dus uitstekend: gisteren had ik een flinke scan vanuit SECFIREWALLAS die ff ruim 3.000 drops liet zien in korte tijd voor een totaal van ca 5.000 drops. Die stond dus al op een ban lijst.



Ik ben er blij mee. Het scheelt aan de ene kant ca 0,5% CPU (en dus Wattjes), al neemt (helaas) aan de andere kant het syncen van op dit ogenblik 125.000 bans ook weer de nodige CPU cycles in beslag.

[CH4OS]

Mars Warrior schreef op maandag 5 januari 2026 @ 12:45:
Er is een CrowdSec plugin/middleware voor Traefik die wordt aanbevolen. Die heb ik gewoon gebruikt. Dat werkt al probleemloos sinds vorig jaar oktober.

Ja, volgens mij gebruikte ik deze middleware juist. Binnenkort maar weer eens proberen, al heb ik nu ook niet echt inzichtelijk wat er binnenkomt. Hoe maak je deze grafieken bijvoorbeeld?

[CH4OS]

DjoeC schreef op maandag 5 januari 2026 @ 11:44:
Database: Benaderen vanaf Windows machines, andere SBC's. Mosquitto idem en vanaf ESP bordjes, etc. Er is voor mij wel degelijk een reden om in containers draaiende applicaties vanaf extern, maar ook vanaf intern (andere containerized applicaties zoals Nextcloud, eigen domotica, weerstation, etc.) te kunnen benaderen. Ik wil gewoon 1 database (eventueel als failsafe over 2 instanties op 2 docker hosts), 1 Mosquitto gekoppeld over 2 of meer instanties (dat werkt best mooi) etc. Ofwel: ik weet eigenlijk wat ik wil maar nog niet altijd hoe het slim en eenvoudig onderhoudbaar op te zetten is. Linux, Docker en nog veel meer zijn mijn hobby en niet mijn vak. Vragen om tips en weer veel lezen en leren dus....

Ah, ik heb gewoon gescheiden stacks gemaakt. Daardoor kunnen versies van de databases ook verschillen. Bijvoorbeeld omdat het ene programma niet altijd support heeft voor de bleeding edge of laatste stabiele versies van een database. Dat heeft ook als voordeel dat men ook niet afhankelijk is van elkaar en stacks niet omvallen omdat een andere stack omvalt. Ik denk dat als je gerichter advies wilt (en ik moet zeggen, ik heb niet alles terug gelezen in dit topic) het wellicht ook handig is om te weten hoe je nu een en ander hebt en wat je gebruikt.

[ Voor 7% gewijzigd door CH4OS op 05-01-2026 15:18 ]

[Mars Warrior]

CH4OS schreef op maandag 5 januari 2026 @ 15:05:
[...]
Ja, volgens mij gebruikte ik deze middleware juist. Binnenkort maar weer eens proberen, al heb ik nu ook niet echt inzichtelijk wat er binnenkomt. Hoe maak je deze grafieken bijvoorbeeld?

De grafieken maak in in Metabase (gratis versie). Voorheen leverde CrowdSec een metabase container mee, maar dat doen ze niet meer omdat ze vinden dat hun console meer kan. Ach ja, keep dreaming

Ik heb wel bergen aan scripts om zaken te verwerken en binnen te halen, dus de grafieken zijn de resultaten van heel wat weekjes werk.

Overigens is data verwerking mijn werk, dus dan zijn dit soort dingen voor mij gewoon leuk werk!

[DjoeC]

CH4OS schreef op maandag 5 januari 2026 @ 15:13:
[...]
Ah, ik heb gewoon gescheiden stacks gemaakt. Daardoor kunnen versies van de databases ook verschillen. Bijvoorbeeld omdat het ene programma niet altijd support heeft voor de bleeding edge of laatste stabiele versies van een database. Dat heeft ook als voordeel dat men ook niet afhankelijk is van elkaar en stacks niet omvallen omdat een andere stack omvalt. Ik denk dat als je gerichter advies wilt (en ik moet zeggen, ik heb niet alles terug gelezen in dit topic) het wellicht ook handig is om te weten hoe je nu een en ander hebt en wat je gebruikt.

Ik heb even bijgelezen over "host" networking. Dat kan werken voor sommige containers maar als ik er tig heb die poort 80 of 3000 gebruiken gaat dat natuurlijk niet. Maar, ik ga eens kijken wat voor mij de beste optie is.

Effectief heb ik nu ~30 containers op 1 machine. De meesten daarvan hoeven niet naar buiten open te staan maar bijvoorbeeld alle Joomla instanties (nu poort 80) wel. Bij "sommige" containers is een aangepaste poort via configatie aan te passen maar niet bij allemaal, daar moet dus nog steeds poortmapping gebeuren. Geen probleem, die kan ik allemaal via NPM eenvoudig benaderen.

Stacks gebruik ik niet - minimale uitzonderingen daar gelaten. Ik heb me daar in het begin van mijn Docker inspanningen aan gebrand. Liever 1 losse database om te beheren dan 10 "embedded".... Ook vanuit andere overwegingen gebruik ik 1 MariaDB LTS voor alle generieke database dingen in mijn totale netwerk. Samen met "ghcr.io/tiredofit/docker-db-backup:latest" als container, phpmyadmin in een container en Navicat op de PC is beheer dan "simpel". Ook Mosquitto draai ik 1 keer (heb wat ervaring met zeer grootschalige MQ omgevingen), ook dat is prima beheersbaar met de paar honderd duizend berichten per dag. Op alle uitgangspunten zijn uitzonderingen mogelijk.

Pihole draait via macvlan opeen eigen (vast) ip adres. Dat is ook meteen de (lokale) DNS voor alles in het netwerk (samen met unbound).

Macvlan heeft voordelen want ik kan containers opstarten op (1 uit) meedere machines zonder dat ik de routering hoef aan te passen: De DNS naam veranderd niet, kwestie down brengen op machine 1, opstarten op machine 2.

Maar, zelf met deze (voor mij) uitgesproken manier van inrichten zal er best iets beters met minder inspanning mogelijk zijn, dat zoek ik dus, Alleen zie ik het, ondanks de goede inhoudelijke reacties van mensen hier, nog niet als eenvoudiger voor me - en dat ligt vast aan mij. Misschien lijdt ik aan tunnelvisie.

[CH4OS]

@DjoeC De Joomla installaties zet je dan toch achter Traefik / Caddy / Nginx Proxy Manager?

Met Traefik hoef je dan niet eens de poorten te openen / forwarden, zolang de Traefik container ze maar bereiken kan. Ik zie echt niet waarom de containers op het netwerk buiten Docker zouden moeten zitten, dat laat ik liever Docker regelen icm Traefik (ook via Docker). De back-end(s) voor Joomla kun je dan evenetueel op een intern netwerk (docker network create --insternal <naam>) zetten waardoor buitenaf er niet eens bij kan. De Joomla instanties zet je dan dus op 2 netwerken, zodat ze enerzijds intern de database kunnen bereiken en het andere netwerk is extern, zodat bepaalde resources die je remote ophaalt (afbeeldingen via een CDN bijvoorbeeld, of metadata van een film of serie) dan opgehaald kan worden. Als dat niet eens nodig is voor de Joomla instanties, kan je dus gewoon met 1 intern netwerk af, Traefik gaat dan voor je naar buiten.

Ik denk echt dat je een en ander onnodig complex hebt voor jezelf, als ik jouw bovenstaande reactie zo lees Ook Pi-Hole draai ik zonder macvlan (draait op een simpele Pi 3B in Docker, tezamen met DSMR reader om mijn slimme meter uit te lezen, verder doet de Pi niks), maar dan dus met portforward, voor Ad Guard Home (die ik op mijn homelab draai) idem dito. Voor het draaien van containers op een andere host zonder aanpassingen te hoeven doen, gebruik je dan toch gewoon Docker Swarm?

[ Voor 14% gewijzigd door CH4OS op 05-01-2026 16:40 ]

[DjoeC]

CH4OS schreef op maandag 5 januari 2026 @ 16:26:
@DjoeC De Joomla installaties zet je dan toch achter Traefik / Caddy / Nginx Proxy Manager?

Met Traefik hoef je dan niet eens de poorten te openen / forwarden, zolang de Traefik container ze maar bereiken kan. Ik zie echt niet waarom de containers op het netwerk buiten Docker zouden moeten zitten, dat laat ik liever Docker regelen icm Traefik (ook via Docker). De back-end(s) voor Joomla kun je dan evenetueel op een intern netwerk (docker network create --insternal <naam>) zetten waardoor buitenaf er niet eens bij kan. De Joomla instanties zet je dan dus op 2 netwerken, zodat ze enerzijds intern de database kunnen bereiken en het andere netwerk is extern, zodat bepaalde resources die je remote ophaalt (afbeeldingen via een CDN bijvoorbeeld, of metadata van een film of serie) dan opgehaald kan worden. Als dat niet eens nodig is voor de Joomla instanties, kan je dus gewoon met 1 intern netwerk af, Traefik gaat dan voor je naar buiten.

Ik denk echt dat je een en ander onnodig complex hebt voor jezelf, als ik jouw bovenstaande reactie zo lees Ook Pi-Hole draai ik zonder macvlan (draait op een simpele Pi 3B in Docker, tezamen met DSMR reader om mijn slimme meter uit te lezen, verder doet de Pi niks), maar dan dus met portforward, voor Ad Guard Home (die ik op mijn homelab draai) idem dito. Voor het draaien van containers op een andere host zonder aanpassingen te hoeven doen, gebruik je dan toch gewoon Docker Swarm?

Dank je. Ik ga me er echt nog eens goed in verdiepen want ik wil dit eenvoudiger krijgen. Gaat me wat tijd kosten maar goed

[CH4OS]

DjoeC schreef op maandag 5 januari 2026 @ 17:39:
Dank je. Ik ga me er echt nog eens goed in verdiepen want ik wil dit eenvoudiger krijgen. Gaat me wat tijd kosten maar goed

Graag gedaan! Ik zou toch eens overwegen om meer met stacks (en elimineren van afhankelijkheden zoals een enkele database instance) te gaan werken. In combinatie met docker compose bijvoorbeeld werkt dat echt goed anno nu.

[ Voor 8% gewijzigd door CH4OS op 05-01-2026 19:24 ]

[synoniem]

CH4OS schreef op maandag 5 januari 2026 @ 19:24:
[...]
Graag gedaan! Ik zou toch eens overwegen om meer met stacks (en elimineren van afhankelijkheden zoals een enkele database instance) te gaan werken. In combinatie met docker compose bijvoorbeeld werkt dat echt goed anno nu.

Het aantal mogelijkheden is wat dat betreft best groot. Omdat ik toch een webserver moet draaien en aan Apache2 gewend ben, heb ik een aantal docker compose scripts waarin Traefik alle services verbindt en de Let's Encrypt certificaten regelt. De Apache2 server stelt een aantal webservices beschikbaar maar is tegelijkertijd ook een proxy voor services die hun eigen webserver draaien.

Uiteraard kan Traefik ook het proxy werk doen maar de webserver met proxy had ik al dus het is min of meer zo organisch gegroeid. Het voordeel is wel dat er een service gewoon kan uitvallen. Zolang de webserver maar blijft draaien blijven de andere services bereikbaar. De volgende stap is het redundant maken met k3s en Longhorn.

[CH4OS]

@synoniem Traefik kan ook prima het Let's Encrypt deel doen, dus dat hoeft niet per se in aparte scripts gedaan te worden. Ook ververst het een certificaat dan automatisch voor je. Om daar dan nog een Apache2 als proxy achter te hangen voelt een beetje dubbel als ik jouw verhaal zo lees. Of ik begrijp het verhaal nu een beetje verkeerd.

[synoniem]

CH4OS schreef op maandag 5 januari 2026 @ 19:59:
@synoniem Traefik kan ook prima het Let's Encrypt deel doen, dus dat hoeft niet per se in aparte scripts gedaan te worden. Ook ververst het een certificaat dan automatisch voor je. Om daar dan nog een Apache2 als proxy achter te hangen voelt een beetje dubbel als ik jouw verhaal zo lees. Of ik begrijp het verhaal nu een beetje verkeerd.

Ja ik ben misschien niet duidelijk genoeg. Traefik regelt inderdaad de certificaten, om precies te zijn een wildcard certificaat dat ook mjin mailserver (in een container) gebruikt. De webserver zit in hetzelfde script om alle subdomeinen af te laten vangen door Traefik proxy. Ik heb gewoon mijn webservice maar ook een subdomein voor icecast/mpd, webmail, postfixadmin terwijl git+docker registry en Navidrome etc. ge-proxied worden.

[DjoeC]

CH4OS schreef op maandag 5 januari 2026 @ 19:24:
[...]
Graag gedaan! Ik zou toch eens overwegen om meer met stacks (en elimineren van afhankelijkheden zoals een enkele database instance) te gaan werken. In combinatie met docker compose bijvoorbeeld werkt dat echt goed anno nu.

Alles zit al in docker compose/yaml en dat werkt inderdaad prima!

[CH4OS]

DjoeC schreef op maandag 5 januari 2026 @ 22:11:
Alles zit al in docker compose/yaml en dat werkt inderdaad prima!

Ah, dat is althans wat ik bedoelde met stacks

Toch even een vraag: Hoe beheren jullie deze files/stacks? Ik doe dat 'simpel' met VS Code (al twijfel ik ook om over te stappen op een andere fork, maar weet nog niet welke, hoor ook veel goede verhalen over Google's Antigravity bijvoorbeeld) en docker doe ik gewoon old-school via de commandline. Maar hoe doen jullie dat? Gebruiken jullie bijvoorbeeld Portainer, Dockge, Arcane of een van de vele andere (webbased) beheertools? Lazydocker wellicht?

[ Voor 58% gewijzigd door CH4OS op 05-01-2026 22:20 ]

[DjoeC]

CH4OS schreef op maandag 5 januari 2026 @ 22:16:
[...]
Ah, dat is althans wat ik bedoelde met stacks

Yes, maar dan wel vzv mogelijk 1 service/1 container per yaml/compose/ok, stack Alleen immich wordt uitgebreider maar wel zonder de database, die wil ik echt centraal houden......

Aanvulljng: Ik heb Raspi lite met daaroverheen Openmediavault. Onderdeel daarvan is een steeds meer uitgebreid Docker nanagement, grofweg Portainer kloon maar werkt veel soepeler. Portainer gebruik ik alleen nog voor snel een container stoppen/starten en das alleen omdat omv geen multiselects kent. Daarbij zijn de omv ontwikkelaars ontzettend responsief bij vragen of issues.

[ Voor 35% gewijzigd door DjoeC op 05-01-2026 22:28 ]

[CH4OS]

Ah, ik heb een onderverdeling gemaakt in wat het doeleinde is. Mijn 'Arr stack' bijvoorbeeld heeft 20 services in totaal, waarvan 2 services dubbel draaien ivm limitaties en/of betere filtering en sorteringsopties voor anime. Dat is dan wel gelijk mijn grootste stack, andere stacks die ik heb, zijn dan weer kleiner, zoals mijn networking stack (waarin ik dus Traefik heb zitten en die ik vervolgens op bijna elk Docker netwerk heb zitten). immich is hier ook een aparte stack, net als OpenCloud zijn eigen stack heeft.

[ Voor 8% gewijzigd door CH4OS op 05-01-2026 22:29 ]

[synoniem]

CH4OS schreef op maandag 5 januari 2026 @ 22:16:
[...]
Ah, dat is althans wat ik bedoelde met stacks

Toch even een vraag: Hoe beheren jullie deze files/stacks? Ik doe dat 'simpel' met VS Code (al twijfel ik ook om over te stappen op een andere fork, maar weet nog niet welke, hoor ook veel goede verhalen over Google's Antigravity bijvoorbeeld) en docker doe ik gewoon old-school via de commandline. Maar hoe doen jullie dat? Gebruiken jullie bijvoorbeeld Portainer, Dockge, Arcane of een van de vele andere (webbased) beheertools? Lazydocker wellicht?

Ik gebruik gewoon de commandline en heb mijn yaml in git repos staan. Mijn servers zijn headless dus een mooie tool met grafische interface heeft weinig nut.

[CH4OS]

@synoniem Eigenlijk hebben alle genoemde tools een webinterface, een gui draaien is dus niet nodig... Enige die dat niet heeft is Lazydocker, dat is een commandline tool.

[ Voor 44% gewijzigd door CH4OS op 05-01-2026 22:48 ]

[blackd]

Voor de mensen die Uptime-Kuma gebruiken, ik las gisteren deze blogpost en leerde toen AutoKuma kennen.

Voorheen had ik een Ansible Task gemaakt die via deze Python library en deze ansible collection een web request deed naar Uptime Kuma om monitors aan te maken. Echter kreeg ik hier steeds meer problemen mee. Ik vermoed het gebruik van de SQLite database icm veel monitors en veel historische data, dus wil graag upgraden naar 2.x met MariaDB.

In plaats van bovenstaande aanpak kan ik met AutoKuma nu labels aanmaken in de Compose file zelf om AutoKuma te voeden met de juiste info om de monitors aan te maken.

Ik beheer op deze manier al mijn Traefik configuratie via labels, mijn Homepage configuratie via labels dus dit past mooi in dat straatje.

Ik ben nu bezig alle config als labels in te richten, daarna kan ik eenvoudig upgraden van 1.x naar 2.x in een nieuwe stack en met een schone lei beginnen.

YAML:

services:
  autokuma:
    image: ghcr.io/bigboot/autokuma:uptime-kuma-v1-2.0.0
    restart: unless-stopped
    environment:
      AUTOKUMA__KUMA__URL: http://uptime-kuma:3001
      AUTOKUMA__KUMA__USERNAME: ${KUMA_USERNAME}
      AUTOKUMA__KUMA__PASSWORD: ${KUMA_PASSWORD}
      AUTOKUMA__DOCKER__EXCLUDE_CONTAINER_PATTERNS: "^temp_;^[a-f0-9]{12}_.*_" # Excludes test containers and temporary stack containers.
      AUTOKUMA__DEFAULT_SETTINGS: |-
        docker.docker_container: {{ container_name }}
        http.max_redirects: 10
        *.max_retries: 3
      AUTOKUMA__DOCKER__LABEL_PREFIX: kuma
      AUTOKUMA__SNIPPETS__DOCKER: |-
         {{container_name}}_docker.docker.docker_container: {{container_name}}
         {{container_name}}_docker.docker.docker_host_name: local
         {{container_name}}_docker.docker.name: docker_{{container_name}}
         {{container_name}}_docker.docker.notification_name_list: ["pushbullet"]
      AUTOKUMA__SNIPPETS__WEB: |-
         {{container_name}}_http.http.name: web_{{container_name}}
         {{container_name}}_http.http.url: https://{{container_name}}.domain.tld
         {{container_name}}_http.http.notification_name_list: ["pushbullet"]
    labels:
      kuma.local.docker_host.name: 'Local Docker Socket'
      kuma.local.docker_host.connection_type: 'socket'
      kuma.local.docker_host.path: '/var/run/docker.sock'
      kuma.pushbullet.notification.name: 'Pushbullet'
      kuma.pushbullet.notification.active: 'true'
      kuma.pushbullet.notification.config: |
        {   [ .. config in JSON ..]
        }
     [..]
   [ ook een uptime-kuma container gedefinieerd op poort 3001]

En dan als voorbeeld:

YAML:

name: sabnzbd
services:
  sabnzbd:
    image: ghcr.io/home-operations/sabnzbd:4.5.5@sha256:da57e01cdebc547852b6df85c8df8c0e4d87792742c7608c5590dc653b184e8c
    container_name: sabnzbd
   [..]
    labels:
      - traefik.enable=true
      - traefik.docker.network=traefik-net
      - traefik.http.routers.sabnzbd.rule=Host(`sabnzbd.domain.tld`)
      - traefik.http.routers.sabnzbd.entrypoints=websecure
      - traefik.http.routers.sabnzbd.tls.certresolver=cfdns
      - traefik.http.services.sabnzbd.loadbalancer.server.port=8080
      - kuma.__web
      - kuma.__docker
 [..]

De labels kuma.__web en kuma.__docker zijn snippets die via de labels AUTOKUMA__SNIPPETS__* geconfigureerd worden.

CH4OS schreef op maandag 5 januari 2026 @ 22:16:
[...]
Ah, dat is althans wat ik bedoelde met stacks

Toch even een vraag: Hoe beheren jullie deze files/stacks? Ik doe dat 'simpel' met VS Code (al twijfel ik ook om over te stappen op een andere fork, maar weet nog niet welke, hoor ook veel goede verhalen over Google's Antigravity bijvoorbeeld) en docker doe ik gewoon old-school via de commandline. Maar hoe doen jullie dat? Gebruiken jullie bijvoorbeeld Portainer, Dockge, Arcane of een van de vele andere (webbased) beheertools? Lazydocker wellicht?

Zoveel mogelijk geautomatiseerd met Ansible, elke stack als Ansible Role in een Github project. Ik doe het beheer met VSCode lokaal en het deployen doe ik via Ansible met een Github self hosted runner.

Als het nodig is containers restarten via Dockge of debuggen via Portainer en worst-case via de CLI via SSH.

[ Voor 33% gewijzigd door blackd op 06-01-2026 09:30 ]

[synoniem]

CH4OS schreef op maandag 5 januari 2026 @ 22:45:
@synoniem Eigenlijk hebben alle genoemde tools een webinterface, een gui draaien is dus niet nodig... Enige die dat niet heeft is Lazydocker, dat is een commandline tool.

Tja, ik ben old skool wat dat betreft dus geen beheerinterface aan het net hangen. Een headless server (vps) is bij mij alleen bereikbaar op port 443 en 22 (en eventueel imap en smtp). Ik zou eventueel een beheerinterface aan localhost kunnen hangen en dan via ssh forwarden maar dat is net zoveel werk als met ssh inloggen en het zelf doen.

[ThinkPad]

Ik meen ooit eens een container te hebben gezien voor het bijhouden van verzekeringspolissen, energiecontracten e.d. Kan het alleen niet vinden, ik kom dan uit bij document management systemen zoals Paperless, of warranty trackers waarin ik kan registreren dat de garantie van m'n TV verloopt op 5 nov. 2027 bijv. Of inventarissystemen, om bij te houden hoeveel boodschappen ik nog in huis heb, of hoeveel dozen schroefjes. Niet wat ik zoek

Ik zoek meer een Excel-achtig overzicht waarin ik kan invoeren dat ik m'n auto verzekerd heb bij BedrijfX, dat ik een energiecontract heb bij LeverancierXYZ wat loopt tot dd-mm-yyyy en een internetcontract heb wat loopt tot dd-mm-yyyy

Iemand een idee?

[ Voor 9% gewijzigd door ThinkPad op 06-01-2026 09:21 ]

[synoniem]

ThinkPad schreef op dinsdag 6 januari 2026 @ 09:19:
Ik meen ooit eens een container te hebben gezien voor het bijhouden van verzekeringspolissen, energiecontracten e.d. Kan het alleen niet vinden, ik kom dan uit bij document management systemen zoals Paperless, of warranty trackers waarin ik kan registreren dat de garantie van m'n TV verloopt op 5 nov. 2027 bijv. Of inventarissystemen, om bij te houden hoeveel boodschappen ik nog in huis heb, of hoeveel dozen schroefjes. Niet wat ik zoek

Ik zoek meer een Excel-achtig overzicht waarin ik kan invoeren dat ik m'n auto verzekerd heb bij BedrijfX, dat ik een energiecontract heb bij LeverancierXYZ wat loopt tot dd-mm-yyyy en een internetcontract heb wat loopt tot dd-mm-yyyy

Iemand een idee?

Zoiets als Wallos?

[ThinkPad]

synoniem schreef op dinsdag 6 januari 2026 @ 09:37:
[...]

Zoiets als Wallos?

Yes perfect!

Ik zat al te kijken naar een Excel-template zoals deze, maar die Wallos is precies wat ik zoek zo te zien. Kan ook notificaties sturen als iets bijna verloopt zo te zien.

[Ben.Hahlen]

@DjoeC (en anderen):
Interessante discussie over "de inrichting"
Mijn 2 centen:

Ik heb een hele tijd MACVLan gedraaid en was daar best tevreden over, maar het management is wel "ingewikkeld", want je moet goed bijhouden wat waar draait, in PiHole regeltjes bijhouden voor routing etc.

Ondertussen ben ik al een hele tijd over naar "normale" netwerken, maar ik draai ook nog "generieke" services, dus geen stack per applicatie.
Mijn folder structuur ziet er nu zo uit:

code:

.
├── 01-critical
├── 02-databases
├── 03-middleware
├── 04-management
├── 05-home
├── 06-personal
├── 07-finance
├── 08-travel
├── 09-tools
├── 10-media
├── 11-games
├── 12-websites
├── 13-ai

In the eerste stack zitten bijvoorbeeld Authentik, Traefik, PiHole en Postgres (speciaal voor die stack). Dat is de enige die volledig zelf-contained is.

Voor het managen van de files gebruik ik VSCode en de Compose Stacks starten/stoppen doe ik met dc, een tooltje dat ik voor mezelf geschreven heb.

[DjoeC]

Ben.Hahlen schreef op dinsdag 6 januari 2026 @ 14:30:
@DjoeC (en anderen):
Interessante discussie over "de inrichting"
Mijn 2 centen:

Ik heb een hele tijd MACVLan gedraaid en was daar best tevreden over, maar het management is wel "ingewikkeld", want je moet goed bijhouden wat waar draait, in PiHole regeltjes bijhouden voor routing etc.

Ondertussen ben ik al een hele tijd over naar "normale" netwerken, maar ik draai ook nog "generieke" services, dus geen stack per applicatie.
Mijn folder structuur ziet er nu zo uit:

code:

.
├── 01-critical
├── 02-databases
├── 03-middleware
├── 04-management
├── 05-home
├── 06-personal
├── 07-finance
├── 08-travel
├── 09-tools
├── 10-media
├── 11-games
├── 12-websites
├── 13-ai

In the eerste stack zitten bijvoorbeeld Authentik, Traefik, PiHole en Postgres (speciaal voor die stack). Dat is de enige die volledig zelf-contained is.

Voor het managen van de files gebruik ik VSCode en de Compose Stacks starten/stoppen doe ik met dc, een tooltje dat ik voor mezelf geschreven heb.

Interessant..... Voor mij is het voordeel van MACVLAN nou juist dat ik na de eerste keer geen routering meer hoef aan te passen. Pihole krijgt ip 10.1.1.2 en houd dat, ongeacht op welke docker instantie die draait.... Ben dus wel benieuwd waarom jij routering zou moeten aanpassen. Gewoon elke service z'n eigen hostname in de pihole locale DNS - die ik trouwens op de Fritzbox router ook als overall DNS heb ingesteld.

[Ben.Hahlen]

DjoeC schreef op dinsdag 6 januari 2026 @ 16:41:
[...]
Interessant..... Voor mij is het voordeel van MACVLAN nou juist dat ik na de eerste keer geen routering meer hoef aan te passen. Pihole krijgt ip 10.1.1.2 en houd dat, ongeacht op welke docker instantie die draait.... Ben dus wel benieuwd waarom jij routering zou moeten aanpassen. Gewoon elke service z'n eigen hostname in de pihole locale DNS - die ik trouwens op de Fritzbox router ook als overall DNS heb ingesteld.

Ik zat in die tijd nogal in de "speelfase", dus heel vaak containers weg en nieuwe er voor in de plaats.
Dan gaat het hard met de administratie

PiHole heeft een WildCard verwijzing naar mijn Traefik, zodat intern alles ook op hostname resolved kan worden.

Mijn USG en PiHole wlke ook samen.

[Greatsword]

Ik heb docker op mijn (Ugreen) NAS draaien, voornamelijk voor zaken als Plex, Sonarr, Radarr etc.

Deze applicaties maken netjes wekelijks geautomatiseerde backups in Zip bestanden, maar hoe maak ik nu eigenlijk het beste een backup van Docker? Stel de NAS houdt er mee op dan wil ik dus zo snel mogelijk alles weer terug kunnen zetten.

Is het dan voldoende om de zip bestanden (backups) ergens anders op te slaan of moet ik dan echt de hele Docker / appdata map overzetten.

De NAS staat 24/7 aan en in deze applicaties worden ook continue logs geschreven, dus ben benieuwd of dat nog conflicten met zich kan meebrengen.

[DjoeC]

Ben.Hahlen schreef op woensdag 7 januari 2026 @ 10:16:
[...]

Ik zat in die tijd nogal in de "speelfase", dus heel vaak containers weg en nieuwe er voor in de plaats.
Dan gaat het hard met de administratie

PiHole heeft een WildCard verwijzing naar mijn Traefik, zodat intern alles ook op hostname resolved kan worden.

Mijn USG en PiHole wlke ook samen.

Ik heb me alvast een beetje verder ingelezen. In de revrvse proxy opties is voorlopig Caddy afgevallen. Traefik moet ik me nog meer in verdiepen dus nog geen uiteindelijke selectie gemaakt voor de nieuwe omgeving.

Daarnaast me nog eens opnieuw ingelezen over macvlan in de docker docs. Daar lijken wat nadelen aan te zitten die door gebruik van ipvlan kunnen worden ondervangen. Dan is er nog het onderscheid in ipvlan L2 en L3, daar moet ik eerst ook wat meer van gaan snappen (en wat mee experimenteren)..... Leuk!

[DjoeC]

Greatsword schreef op donderdag 8 januari 2026 @ 15:24:
Ik heb docker op mijn (Ugreen) NAS draaien, voornamelijk voor zaken als Plex, Sonarr, Radarr etc.

Deze applicaties maken netjes wekelijks geautomatiseerde backups in Zip bestanden, maar hoe maak ik nu eigenlijk het beste een backup van Docker? Stel de NAS houdt er mee op dan wil ik dus zo snel mogelijk alles weer terug kunnen zetten.

Is het dan voldoende om de zip bestanden (backups) ergens anders op te slaan of moet ik dan echt de hele Docker / appdata map overzetten.

De NAS staat 24/7 aan en in deze applicaties worden ook continue logs geschreven, dus ben benieuwd of dat nog conflicten met zich kan meebrengen.

Ik maak 2 soorten "backup's" van docker spul. Databases dagelijks middels https://github.com/tiredofit/docker-db-backup , die komen in een shared backup folder die "zodra ze er staan" en Windows beschikbaar is naar Windows worden overgehaald en daar in de Windows backup cyclus meelopen. Daarnaast wordt alle "permanente" docker data (docker-config en docker-data) middels een simpel script naar die backup folder gekopieerd en loopt op dezelfde manier mee. Al het andere is een herstel kwestie van: configatie, datafolders terug zetten, containers opnieuw uitrollen mbv de bewaarde yml's en gaan met die banaan. De databases (mariadb): Eerst kale Mariadb starten en dan alles (behalve system) restoren.

En ja, er zijn meer en veel meer sophisticated manieren, dit werkt voor mij zonder omkijken. O ja, en van pihole draai ik elke nacht een automatische teleporter job. Dan heeft ie ook mijn lokale DNS altijd compleet. 1 dag verlies kan ik mij veroorloven. Als je dat niet kunt: andere maatregelen treffen

[Satom]

Greatsword schreef op donderdag 8 januari 2026 @ 15:24:
Ik heb docker op mijn (Ugreen) NAS draaien, voornamelijk voor zaken als Plex, Sonarr, Radarr etc.

Deze applicaties maken netjes wekelijks geautomatiseerde backups in Zip bestanden, maar hoe maak ik nu eigenlijk het beste een backup van Docker? Stel de NAS houdt er mee op dan wil ik dus zo snel mogelijk alles weer terug kunnen zetten.

Is het dan voldoende om de zip bestanden (backups) ergens anders op te slaan of moet ik dan echt de hele Docker / appdata map overzetten.

De NAS staat 24/7 aan en in deze applicaties worden ook continue logs geschreven, dus ben benieuwd of dat nog conflicten met zich kan meebrengen.

Toen ik nog gebruik maakte van een Intel NUC, gebruikte ik een script + rsync om elke nacht alle docker-compose projecten te stoppen, te kopiëren naar een specifieke te back-uppen map en daarna een-voor-een de docker-compose projecten weer op te starten. De te back-uppen map werd dan op een later tijdstip (geloof een uur later) door Duplicati verwerkt naar de cloud. De downtime die het met zich mee bracht, maakte mij niets uit. Het gehele proces liep als ik lag te slapen.

Op dit moment draai ik een Raspberry Pi 3B+, daarvan hanteer ik bijna dezelfde werkwijze, behalve het kopiëren. Middels scripting worden de docker-compose projecten gestopt, vervolgens gaat Duplicati de boel uploaden naar de cloud, om uiteindelijk de projecten weer te starten. De downtime is hier iets langer, maar ook nu heb ik er geen last van (het proces loopt diep in de nacht).

Zolang als ik self-host (10+ jaar), heb ik altijd downtime verkozen boven, mogelijk, incomplete backups, omdat het spul nog draaiende is. Ik geloof wel dat de tooling tegenwoordig beter is geworden, maar goed

[DjoeC]

Satom schreef op donderdag 8 januari 2026 @ 15:59:
[...]
De downtime is hier iets langer, maar ook nu heb ik er geen last van (het proces loopt diep in de nacht).

Hmm, ik zou toch liever doordraaien, zeker als zoiets hier 1 alle DNS verzorgd wordt (pihole, unbound) en er ook (beschermd via Cloudflare) een paar publieke websites draaien. Ik kan niet voorspellen wie wanneer wel of niet slaapt. Daarnaast vind ik (maar goed, wie ben ik) unattended stops en starts onwenselijk. Maar goed, YMMV.

[DjoeC]

Vraag: ik gebruik momenteel Mosquitto als MQTT broker (bron voor HA en eigen proggies), gevoed vanuit sensoren en ESP's (eigen proggies). Ik gebruik zoveel mogelijk MQTT V5 maar V3 wordt ook nog wel gebruikt.

Nu mis ik een grafische (management) interface waar statistieken, timestamp laatste bericht in een queue, oid te zien zijn. Ik denk NIET aan prometheus achtige oplossingen. Blijkbaar is er een commercieele versie van Mosquitto die dit heeft maar ik zoek eigenlijk gewoon open-source.

Is er een betere MQTT broker met iets meer opties (docker gebaseerd). Ik kom HiveMQ, RabbitMQ, emqx tegen. Heeft iemand ervaring met 1 van die alternatieven?

[Ben.Hahlen]

DjoeC schreef op zaterdag 17 januari 2026 @ 15:21:
Vraag: ik gebruik momenteel Mosquitto als MQTT broker (bron voor HA en eigen proggies), gevoed vanuit sensoren en ESP's (eigen proggies). Ik gebruik zoveel mogelijk MQTT V5 maar V3 wordt ook nog wel gebruikt.

Nu mis ik een grafische (management) interface waar statistieken, timestamp laatste bericht in een queue, oid te zien zijn. Ik denk NIET aan prometheus achtige oplossingen. Blijkbaar is er een commercieele versie van Mosquitto die dit heeft maar ik zoek eigenlijk gewoon open-source.

Is er een betere MQTT broker met iets meer opties (docker gebaseerd). Ik kom HiveMQ, RabbitMQ, emqx tegen. Heeft iemand ervaring met 1 van die alternatieven?

Ik gebruik MQTT Explorer.
Deze connect naar Mosquitto, misschien is dat wat?

[DjoeC]

Ben.Hahlen schreef op maandag 19 januari 2026 @ 15:28:
[...]

Ik gebruik MQTT Explorer.
Deze connect naar Mosquitto, misschien is dat wat?

Ja, die gebruik ik al op Windows maar liefst zou ik iets hebben dat direct onder docker draait - of zou dit zo in een container te "verpakken" kunnen zijn?

Vanochtend heb ik EMQX uitgeprobeerd, dat leip eigenlijk best wel als alternatief voor Mosquitto. Het grote verschil: Mosquitto kan maar 100.000 connecties aan en EMQX wel 1.000.000. Duhhh....

Daar zit een "soort van" combinatie in van MQTT Explorer en https://github.com/sanjeshpathak/Mosquitto-Dashboard maar ik vraag me af of dat pakket niet veel te zwaar is voor een Raspi. Daarbij moet je met EMQX bij een "cluster" al meteen een betaalde licentie aanschaffen, ik neem aan dat dat bij bridgen ook geldt - terwijl bringen van mosquitto gewoon een paar config regels zijn....

Maar goed, als er echt niks is maak ik misschien wel een Python containertje dat statistics naar Home Assistant kan sturen en maak ik daar wel een dashboardje. Werk waar ik niet op zit te wachten - maar dat kan natuurlijk wel.....

[Mars Warrior]

DjoeC schreef op maandag 19 januari 2026 @ 15:37:
[...]

Ja, die gebruik ik al op Windows maar liefst zou ik iets hebben dat direct onder docker draait - of zou dit zo in een container te "verpakken" kunnen zijn?

Vanochtend heb ik EMQX uitgeprobeerd, dat leip eigenlijk best wel als alternatief voor Mosquitto. Het grote verschil: Mosquitto kan maar 100.000 connecties aan en EMQX wel 1.000.000. Duhhh....

Daar zit een "soort van" combinatie in van MQTT Explorer en https://github.com/sanjeshpathak/Mosquitto-Dashboard maar ik vraag me af of dat pakket niet veel te zwaar is voor een Raspi. Daarbij moet je met EMQX bij een "cluster" al meteen een betaalde licentie aanschaffen, ik neem aan dat dat bij bridgen ook geldt - terwijl bringen van mosquitto gewoon een paar config regels zijn....

Maar goed, als er echt niks is maak ik misschien wel een Python containertje dat statistics naar Home Assistant kan sturen en maak ik daar wel een dashboardje. Werk waar ik niet op zit te wachten - maar dat kan natuurlijk wel.....

Dat clusteren van EMQS geld kost wist ik niet. Voorheen draaide ik dat namelijk op een netwerk van RPIs...

Maar EMQX is mooi en informatief als optie voor een GUI.

Daarnaast heb je nog RabbitMQ. Kan wat bewerkelijker zijn omdat je een MQTT plugin moet gebruiken, immers RabbitMQ doet standaard AMQP.

En wat dacht je van deze, MQTTUI?
Dit is een aparte GUI voor een willekeurige broker en draait vanzelfsprekend in Docker.

[Ben.Hahlen]

DjoeC schreef op maandag 19 januari 2026 @ 15:37:
[...]

Ja, die gebruik ik al op Windows maar liefst zou ik iets hebben dat direct onder docker draait - of zou dit zo in een container te "verpakken" kunnen zijn?

Jazeker, dat is de enige manier dat ik hem heb:

YAML:

  mqtt-explorer:
    extends:
      file: ../shared.yml
      service: pubnet-shared
    image: smeagolworms4/mqtt-explorer:latest
    container_name: mqtt-explorer
    hostname: mqtt-explorer
    env_file: mqtt-explorer.env
    volumes:
      - ./mqtt-explorer/config:/mqtt-explorer/config
 

[DjoeC]

Mars Warrior schreef op maandag 19 januari 2026 @ 16:06:
[...]

Dat clusteren van EMQS geld kost wist ik niet. Voorheen draaide ik dat namelijk op een netwerk van RPIs...

Maar EMQX is mooi en informatief als optie voor een GUI.

Daarnaast heb je nog RabbitMQ. Kan wat bewerkelijker zijn omdat je een MQTT plugin moet gebruiken, immers RabbitMQ doet standaard AMQP.

En wat dacht je van deze, MQTTUI?
Dit is een aparte GUI voor een willekeurige broker en draait vanzelfsprekend in Docker.

[Afbeelding]

EMQX heeft de licentie afgelopen jaar aangepast. Multi-node kan nog wel voor eigen gebruik/hobby maar je moet wel een (en daar zat ik waarschijnlijk fout) vzv ik kan zien gratis licentie voor aanvragen. Daar houdt ik niet zo van

RabbitMQ heb ik in het verleden al eens naar gekeken maar toen was hun MQTT ondersteuning er niet/in een pril statium. Misschien ook maar weer eens proberen.

Met Terdia MQTUI ben ik gosteren aan t kloten geweest. Ik kreeg t niet leek aan de gang. Maar als chatgpt t aanbeveelt zal het toch wel goed moeten zijn

En anders wordt t toch weer het vertrouwde Mosquitto, dan maar geen interface - in de huidige "produktie"omgeving doet die ook gewoon wat ie doen moet. Alleen, een mens wil soms wat extra franje..

[DjoeC]

Ben.Hahlen schreef op maandag 19 januari 2026 @ 16:15:
[...]

Jazeker, dat is de enige manier dat ik hem heb:

YAML:

  mqtt-explorer:
    extends:
      file: ../shared.yml
      service: pubnet-shared
    image: smeagolworms4/mqtt-explorer:latest
    container_name: mqtt-explorer
    hostname: mqtt-explorer
    env_file: mqtt-explorer.env
    volumes:
      - ./mqtt-explorer/config:/mqtt-explorer/config
 

Ik ga die zometeen eens uitrollen, die heb ik over t hoofd gezien - zal vast wel verkeerd gezocht hebben. Nou dat dashboard nog, om de stats snel in beeld te hebben, dan ben ik klaar en kan ik gewoon op Mosquitto blijven.

<aanvulling>
MQTT-explorer draait al en net zoals lokaal Top!

[ Voor 4% gewijzigd door DjoeC op 19-01-2026 16:48 ]