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