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

[S1NN3D]

https://github.com/traefik/traefik/releases/tag/v3.6.1

Er is een nieuwe release van Traefik die de problemen met Docker 29 zouden moeten oplossen. Heb er nu ff zelf geen tijd voor dus in het weekend pas testen. Maar leek me handig om deze 3.6.1 hier ff te melden.

[Webgnome]

Morgen even testen. Thanks voor de update

[babbelbox]

Voor zover ik kan vinden is de docker image nog niet geüpdatet.
Die haalt nog steeds 3.6.0 binnen.

[RobertMe]

babbelbox schreef op donderdag 13 november 2025 @ 23:02:
Voor zover ik kan vinden is de docker image nog niet geüpdatet.
Die haalt nog steeds 3.6.0 binnen.

Staat intussen een minuutje op Docker Hub

[babbelbox]

Hier werkt het weer zonder de aanpassing aan de docker service

[RobertMe]

Wel "leuk" om image updates te laten doen door Renovate en deze ook te reviewen in bepaalde mate. Blijkt dat een image ineens gebuild wordt met daarin cups-libs. Like, best raar, waarom een container die iets op netwerk doet en een web interface exposed ineens libraries voor te printen binnen trekt. Even verder kijkende blijkt dat ook qt6-qtbase-x11 als package is toegevoegd. Wat ook meteen verklaard waarom een hele shitload aan andere packages is toegevoegd (wayland, libx...). Maar eens op Docker Hub kijken, en image size van vorige (patch) versie was 82MB, huidige image is 186MB. * oeps * (da's geen typo, maar daadwerkelijk een 100MB toename) Toch deze versie maar eens even over slaan. En uiteraard netjes een bug report aangemaakt.

[DjoeC]

Ik zag vandaag ook een nieuwe Docker versie (29.0.1) klaar staan. Zou die misschien de minimum API versie aanpassen?

[Mars Warrior]

DjoeC schreef op zaterdag 15 november 2025 @ 16:30:
Ik zag vandaag ook een nieuwe Docker versie (29.0.1) klaar staan. Zou die misschien de minimum API versie aanpassen?

Nope, doet wel wat met de API versie, maar niet dat...

• Docker image list now considers the NO_COLOR environment variable for choosing the colored output. docker/cli#6654
• docker images no longer truncates the name width when output is redirect (e.g. for grep). docker/cli#6656
• containerd image store: Fix a bug causing docker build to ignore the explicitly set unpack image exporter option. moby/moby#51514
• Fix a bug causing docker image list --all to not show untagged/dangling images. docker/cli#6657
• Fix build on i386. moby/moby#51528
• Fix explicit graphdriver configuration ("storage-driver") being treated as containerd snapshotter when prior graphdriver state exists. moby/moby#51516
• Fix output format of the ApiVersion and MinApiVersion fields in docker version --format=json to align with previous versions. docker/cli#6648

[babbelbox]

DjoeC schreef op zaterdag 15 november 2025 @ 16:30:
Ik zag vandaag ook een nieuwe Docker versie (29.0.1) klaar staan. Zou die misschien de minimum API versie aanpassen?

Dat zou ik best bijzonder vinden. Er lijkt me genoeg tijd geweest voor ontwikkelaars om aanpassingen te maken in de containers die compatibel zijn met de nieuwere API version.
Zomaar een een obsolete versie weer herintroduceren is niet echt een te verwachten gebeurtenis.

[sjorsjuhmaniac]

DjoeC schreef op zaterdag 15 november 2025 @ 16:30:
Ik zag vandaag ook een nieuwe Docker versie (29.0.1) klaar staan. Zou die misschien de minimum API versie aanpassen?

ipv op updates te wachten van de verschillende projects kan je de Min API versie kan je eenvoudig forceren in je daemon config, op debian-achtige systemen kan dat simpel via systemctl

Bash:

$ systemctl edit docker.service

paste dit in the juiste gedeelte bovenaan:

code:

[Service]
Environment=DOCKER_MIN_API_VERSION=1.24

En restart de daemon

Bash:

$ systemctl restart docker

Ik liep er bv met portainer tegenaan.

[DjoeC]

sjorsjuhmaniac schreef op zondag 16 november 2025 @ 10:54:
[...]


ipv op updates te wachten van de verschillende projects kan je de Min API versie kan je eenvoudig forceren in je daemon config, op debian-achtige systemen kan dat simpel via systemctl

Bash:

$ systemctl edit docker.service

past dit in the juiste gedeelte bovenaan:

code:

[Service]
Environment=DOCKER_MIN_API_VERSION=1.24

En restart de daemon

Bash:

$ systemctl restart docker

Die workaround had ik inmiddels al uitgevoerd, die werkt ook. Maar ik blijf het vreemd vinden dat zoveel projecten zo ontzettend veel api versies achterlopen....

[Mars Warrior]

Omdat mijn CrowdSec firewall projectje wel lekker draait - nog maar gemiddeld 8 bans per dag - en het nu telkens nieuwe IP adressen zijn, dus het-is-wat-het-is, had ik verder zitten neuzen naar wat leuks.

Ik kwam zodoende dockur tegen: een docker container gebaseerd op qemux, maar dan helemaal aangepast zodat deze geheel automagisch Windows kan downloaden/installeren/draaien alsof het een normale docker container is (dus volumes, environment, macvlan etc).

Wel grappig om te zien dat Windows XP maar 0,6GB is en Windows 11 iets van 7GB is.
Alle images worden dus legaal van Microsoft gedownload: je hebt dus ook gewoon een licentie nodig.

Vanzelfsprekend kun je ook alle Linux OSsen draaien.

Dus ook hiervoor heb je geen Proxmox meer nodig. Voor mij kan dit nog wel eens handig zijn als ik een VM toch niet helemaal lekker in een container gedraaid krijg, al loop je natuurlijk direct wel tegen typische VM zaken aan als reserveren van RAM enzo.

Je moet met Windows 11 wel ff geduld hebben, en vervolgens wel met RDP connecten, want de standaard browser interface is bietje traag en lage resolutie

[DjoeC]

Mars Warrior schreef op maandag 17 november 2025 @ 14:23:
Ik kwam zodoende dockur tegen: een docker container gebaseerd op qemux, maar dan helemaal aangepast zodat deze geheel automagisch Windows kan downloaden/installeren/draaien alsof het een normale docker container is (dus volumes, environment, macvlan etc).

Wel grappig om te zien dat Windows XP maar 0,6GB is en Windows 11 iets van 7GB is.
Alle images worden dus legaal van Microsoft gedownload: je hebt dus ook gewoon een licentie nodig.

Vanzelfsprekend kun je ook alle Linux OSsen draaien.

Je moet met Windows 11 wel ff geduld hebben, en vervolgens wel met RDP connecten, want de standaard browser interface is bietje traag en lage resolutie

Grappig, ik zie dat het ook op ARM64 (raspberry) zou kunnen werken.... Alleen denk ik dat een Pi-5 met 8GB dan wat klein wordt anders dan om te proberen.....

[Mars Warrior]

DjoeC schreef op maandag 17 november 2025 @ 15:11:
[...]
Grappig, ik zie dat het ook op ARM64 (raspberry) zou kunnen werken.... Alleen denk ik dat een Pi-5 met 8GB dan wat klein wordt anders dan om te proberen.....

Het zijn dan wel ARM images, dus geen idee of die kleiner zijn dan de x86 images.

[DjoeC]

Mars Warrior schreef op maandag 17 november 2025 @ 15:55:
[...]

Het zijn dan wel ARM images, dus geen idee of die kleiner zijn dan de x86 images.

Ik dacht meer aan de dan te installeren Windows en de performance daarvan. Dan denk ik dat een raspi desktop in Docker (in mijn geval...) een betere optie is. Ik draai OMV op de kale versie want OMV gaat niet samen met de raspi desktop maar OMV heeft voor mij als "minder deskundige" best een hoop voordelen.....

[ahbart]

Ook ik liep gisteravond tegen het api versie probleem aan. Bleek bij meerdere containers een issue, waaronder Portainer en appapi-harp container t.b.v. Nextcloud.

code:

[Service]
Environment=DOCKER_MIN_API_VERSION=1.24

toegepast. Waarna alles weer werkt. Maar hoe weet ik nu dat de updates zijn doorgevoerd en deze workaround niet meer nodig is? En loop ik er met deze min_api_version niet tegenaan dat als sommige containers geupdate zijn, deze juist niet meer werken of zo?
Met andere woorden, hoe lang laat ik dit staan?

[DjoeC]

ahbart schreef op donderdag 20 november 2025 @ 10:27:
Ook ik liep gisteravond tegen het api versie probleem aan. Bleek bij meerdere containers een issue, waaronder Portainer en appapi-harp container t.b.v. Nextcloud.

code:

[Service]
Environment=DOCKER_MIN_API_VERSION=1.24

toegepast. Waarna alles weer werkt. Maar hoe weet ik nu dat de updates zijn doorgevoerd en deze workaround niet meer nodig is?

Niet.

En loop ik er met deze min_api_version niet tegenaan dat als sommige containers geupdate zijn, deze juist niet meer werken of zo?
Met andere woorden, hoe lang laat ik dit staan?

Eigenlijk zou je die WA niet moeten hoeven toepassen. In mijn beleving zegt het iets over de aandacht die containermakers geven aan het platform waar ze van afhankelijk zijn.... De (nieuwe) laagste API versie is volgens Docker 1.44 - van januari 2024 - terwijl ze nu op 1.52 zitten, ofwel het nieuwe minimum loopt alweer 8 versies achter.

Dat gezegd hebbend: De parameter geeft een minimum versie weer, nieuwere versies zullen dus altijd werken en sommige containers (ik meen dat Traefik al genoemd was) werken gewoon met de "huidige" API versie en dus 1.52. Portainer komt deze maand nog met een fix is al beloofd, van andere containers weet ik het niet.

Maar, het blijft opmerkelijk dat containerbouwers zover achter lopen met hun API versies en ook niet of nauwelijks (automatische) compatibiliteits testen lijken uit te voeren. Ze zijn afhankelijk van Docker/Kubernetes etc.....

Mijn min-api versie wordt bij elke nieuwe docker-ce versie (inmiddels 29.0.2) automatisch uit de service config gepoets, ik weet dus nu elke keer of ie nog nodig is

[babbelbox]

DjoeC schreef op donderdag 20 november 2025 @ 10:45:
[...]

Niet.

[...]

[...]

Mijn min-api versie wordt bij elke nieuwe docker-ce versie (inmiddels 29.0.2) automatisch uit de service config gepoets, ik weet dus nu elke keer of ie nog nodig is

Bedoel je dat bij een upgrade de min-api versie setting wordt verwijderd en als je dan merkt dat iets niet werkt vanwege deze min-api je 'm in je service config weer handmatig terugzet?

[DjoeC]

babbelbox schreef op donderdag 20 november 2025 @ 10:50:
[...]

Bedoel je dat bij een upgrade de min-api versie setting wordt verwijderd en als je dan merkt dat iets niet werkt vanwege deze min-api je 'm in je service config weer handmatig terugzet?

Correct. Er is een manier (ik meen via config.d oid) om m te laten staan maar ik vind dit prima nu ik weet hoe t werkt Ik zie het als mijn kanarie die me vertelt welke containers nog steeds achterlopen en waar ik dus ook eens rond ga kijken naar alternatieven.

<aanvulling>
Disclaimer: Omdat het bij mij zo werkt betekent niet automagisch dat het bij anderen ook zou werkt. Misschien gebruik ik wel een "foute" methode die voor mij prima uitpakt.

[ Voor 14% gewijzigd door DjoeC op 20-11-2025 10:54 ]

[synoniem]

Tot op heden heb ik alleen voor Traefik de nieuwste versie 3.6.1? in gebruik genomen. Mijn overige containers zijn blijven werken waarbij ik moet zeggen dat ik in de regel mijn eigen containers maak. Vind het wat fijner als ik weet wat er allemaal in een container zit.

[DjoeC]

synoniem schreef op donderdag 20 november 2025 @ 11:47:
Tot op heden heb ik alleen voor Traefik de nieuwste versie 3.6.1? in gebruik genomen. Mijn overige containers zijn blijven werken waarbij ik moet zeggen dat ik in de regel mijn eigen containers maak. Vind het wat fijner als ik weet wat er allemaal in een container zit.

Het probleem schijnt zich alleen voor te doen in containers die via Docker met interne onderdelen van het systeem praten - precies ben ik even kwijt, is ergens beschreven. Dat betekent dat > 95% van de containers geen last zou moeten hebben. Maar Portainer, Traefik, etc doen dat natuurlijk wel al heb ik t bijvoorbeeld bij Dozzle, NginxPM, Pihole, Watchtower (NickFedor versie) niks van gemerkt. Sterker: nickfedor/watchtower geeft deze message:

code:

Watchtower 1.12.3 using Docker API v1.51

Zo kan het dus ook.....

[RobertMe]

DjoeC schreef op donderdag 20 november 2025 @ 10:45:
In mijn beleving zegt het iets over de aandacht die containermakers geven aan het platform waar ze van afhankelijk zijn....

Kleine correctie: het probleem is de software, niet de container. Ook als je Traefik native draait zou je tegen dit probleem aanlopen. Conclusie blijft uiteraard wel hetzelfde: "als je software maakt die met de Docker daemon babbelt, zorg er dan wel voor dat je up-to-date blijft v.w.b. API versies". (Maar dit probleem is er vast veel breder. En zal ook gelden voor software die bv gebruik maakt van APIs van Microsoft, GitHub, of welke dienst dan ook).

[DjoeC]

RobertMe schreef op donderdag 20 november 2025 @ 12:05:
[...]

Kleine correctie: het probleem is de software, niet de container. Ook als je Traefik native draait zou je tegen dit probleem aanlopen. Conclusie blijft uiteraard wel hetzelfde: "als je software maakt die met de Docker daemon babbelt, zorg er dan wel voor dat je up-to-date blijft v.w.b. API versies". (Maar dit probleem is er vast veel breder. En zal ook gelden voor software die bv gebruik maakt van APIs van Microsoft, GitHub, of welke dienst dan ook).

Dank voor de verheldering.

[sjorsjuhmaniac]

ahbart schreef op donderdag 20 november 2025 @ 10:27:
Ook ik liep gisteravond tegen het api versie probleem aan. Bleek bij meerdere containers een issue, waaronder Portainer en appapi-harp container t.b.v. Nextcloud.

code:

[Service]
Environment=DOCKER_MIN_API_VERSION=1.24

toegepast. Waarna alles weer werkt. Maar hoe weet ik nu dat de updates zijn doorgevoerd en deze workaround niet meer nodig is? En loop ik er met deze min_api_version niet tegenaan dat als sommige containers geupdate zijn, deze juist niet meer werken of zo?
Met andere woorden, hoe lang laat ik dit staan?

De release notes van de images lezen voor je ze implementeert, zoals het eigenlijk hoort

[ahbart]

sjorsjuhmaniac schreef op zaterdag 22 november 2025 @ 09:16:
[...]
De release notes van de images lezen voor je ze implementeert, zoals het eigenlijk hoort

Ja dat zou beter zijn. ware het niet dat ik 25 containers heb draaien.

[DjoeC]

sjorsjuhmaniac schreef op zaterdag 22 november 2025 @ 09:16:
[...]


De release notes van de images lezen voor je ze implementeert, zoals het eigenlijk hoort

Prima. Docker zegt: Minimale API 1.44, huidige API 1.52.

In de releasenotes van de containers (zoals Portainer) staat niets over een minimale API versie. Naast het feit dat ze blijkbaar 20-25 API versies achter lopen gaan ze wat mij betreft daar al de fout in.

Wel noemen ze de "ondersteunde" Docker versie als maximaal 27.5.1/28.5.1 waardoor ik dus NIET met het normale - in mijn geval - Debian stable release channel kan meelopen (nu 29.0.2). Maar erger, Docker heeft in de latere 27.5.2 en 28.5.2 - die overigens wel met Portainer samenwerken ook al staan ze niet op de supported lijst - een aantal als "kritiek" beschreven CVE's opgelost die je dan niet zou mogen installeren

Wat is dan verstandig? Ouwe versie van Docker, op zoek naar de workaround of achterlopende software dumpen voor iets dat de boel wel goed voor elkaar heeft?

[alex3305]

ahbart schreef op zaterdag 22 november 2025 @ 11:16:
[...]

Ja dat zou beter zijn. ware het niet dat ik 25 containers heb draaien.

Dus? Ik heb er >60. Dan kun je nog steeds een versioned omgeving draaien.

Ik update mijn containers met Renovate vanuit mijn Forgejo instantie:



Renovate neemt dan direct de release notes mee:



Dit gaat volledig automatisch bij patches en minors. Bij major version updates krijg ik een PR die niet automatisch gemerged wordt, maar ik handmatig moet accepteren. Deployment gebeurt dan automatisch met Forgejo runner en Ansible.

Hierdoor kan ik bij veranderingen ook enorm makkelijk terug. Immers kan ik herleiden wanneer de verandering is opgetreden en mogelijk ook wanneer het mis is gegaan.

Daarnaast maak ik ook automatisch elke week een Forgejo release en Git tag zodat ik ook makkelijk terug in de tijd kan om te kijken waar veranderingen hebben plaats gevonden:

[Mars Warrior]

Om op de post van @alex3305 in te haken.
Ik mag waarschijnlijk een deel van mijn huidige docker stack binnen een bedrijfsomgeving gaan inzetten.

Als basis zal - als het goed is - Proxmox + PBS worden ingezet met 1 grote VM met daarin de hele serie aan docker containers. Proxmox regelt dan lekker ZFS + Backup en een stuk beheer.

Maar ik wil dan ook het bijwerken van de containers beheersbaarder maken. Nu kijk ik gewoon zelf, en ik update af en toe als ik zin heb.

Op internet kom ik vaak de combi van Forgejo + Renovate + Woodpecker tegen. Woodpecker CI zou beter/makkelijker zijn dan Forgejo CI.

In dit topic zie ik dat @RobertMe en @alex3305 dit soort stacks hebben draaien. Eigenlijk zoek ik naar voorbeelden en best practices om te snappen hoe dit in de praktijk werkt. Op de één of andere manier wil een IT & security afdeling altijd dingen weten

Aangezien ChatGPT al mijn ideëen G-E-W-E-L-D-I-G vindt, vertrouw ik eerder op mensen met ervaring

[DjoeC]

Mars Warrior schreef op vrijdag 28 november 2025 @ 11:08:
Om op de post van @alex3305 in te haken.
Ik mag waarschijnlijk een deel van mijn huidige docker stack binnen een bedrijfsomgeving gaan inzetten.

Als basis zal - als het goed is - Proxmox + PBS worden ingezet met 1 grote VM met daarin de hele serie aan docker containers. Proxmox regelt dan lekker ZFS + Backup en een stuk beheer.

Maar ik wil dan ook het bijwerken van de containers beheersbaarder maken. Nu kijk ik gewoon zelf, en ik update af en toe als ik zin heb.

Op internet kom ik vaak de combi van Forgejo + Renovate + Woodpecker tegen. Woodpecker CI zou beter/makkelijker zijn dan Forgejo CI.

In dit topic zie ik dat @RobertMe en @alex3305 dit soort stacks hebben draaien. Eigenlijk zoek ik naar voorbeelden en best practices om te snappen hoe dit in de praktijk werkt. Op de één of andere manier wil een IT & security afdeling altijd dingen weten

Aangezien ChatGPT al mijn ideëen G-E-W-E-L-D-I-G vindt, vertrouw ik eerder op mensen met ervaring

Toppie: je hobby mee naar je werk

[alex3305]

@Mars Warrior Leuk dat je dit project zo mag gaan doen . Tot een paar jaar terug heb ik op mijn werk de complete infrastructuur in beheer gehad. Inclusief versiebeheer, CI/CD, Agile-apps, gateway, SSO, Docker en uiteindelijk Kubernetes. Allemaal super leuk, maar probeer het wel behapbaar te houden. Een mooie stack is ontzettend leuk, maar het is leuker als je het snapt en kunt overdragen .

Als basis zal - als het goed is - Proxmox + PBS worden ingezet met 1 grote VM met daarin de hele serie aan docker containers. Proxmox regelt dan lekker ZFS + Backup en een stuk beheer.

Wij gebruikte in de basis gewone Debian servers. Dat deden we niet op 1 grote VM, maar kleinere VMs. Eén grote VM (of colo) klinkt verleidelijk, maar nam bij problemen meteen heel de stack mee . Daarom hadden we bijvoorbeeld 1 VM voor monitoring (o.a. Prometheus), 1 VM voor Git en CI-controller, etc. De CI-runners stonden dan op aparte machines zodat ook hier de load eenvoudig verdeeld kon worden. Ik zeg hierbij niet dat dit 'het beste' is, maar ik zou je dit wel aanraden om mee te nemen in de overweging.

Het inrichten van deze machines deden we met Ansible. Dat doe ik privé nog steeds. Dat is een forse drempel, maar zorgt voor eenvoudig te herhalen, idempotente setups. Hierdoor weet ik zeker dat twee keer dezelfde uitrol, twee keer hetzelfde resultaat oplevert. Tegelijkertijd is het infrastructure-as-code en is het daardoor ook in versiebeheer.

Backup doe ik thuis met Kopia. Dat is een deduplicerende, met pariteit beveiligde, versleutelde backup software. Hele mond vol, maar zorgt voor relatief kleine backups, met toch alles erin. Ook kan ik met Kopia dergelijke backups a la rsync eenvoudig syncen naar meerdere targets zodat ik hier redundantie heb. En het terughalen van data is met de web UI kinderlijk eenvoudig.

Professioneel sloegen we eigenlijk altijd alles op in databases en waren applicaties 'stateless'. Die databases werden dan gesnapshot en gesynct. Dat doe ik voor mijn Kopia backups (waar van toepassing) nog steeds. Een PostgreSQL WAL is namelijk geen backup.

Maar ik wil dan ook het bijwerken van de containers beheersbaarder maken. Nu kijk ik gewoon zelf, en ik update af en toe als ik zin heb.

Een paar jaar terug keken we eenmaal per week naar updates en voerde we die handmatig uit met Ansible. Momenteel gebruik ik dus Renovate en gebeuren updates (veelal) automatisch. Het is afhankelijk van de applicatie en soort update.

Met Renovate kun je bijvoorbeeld ook eenvoudig buiten SLA tijden updaten, updates uitstellen en handmatige uitrol verplicht stellen. Dit zijn 3 voorbeelden, maar Renovate is enorm uitgebreid. De opzet van Renovate was echter kinderlijk eenvoudig en heb ik al eerder iets over geschreven hier .

Op internet kom ik vaak de combi van Forgejo + Renovate + Woodpecker tegen. Woodpecker CI zou beter/makkelijker zijn dan Forgejo CI.

Privé en professioneel heb ik verschillende stacks gebruikt. Thuis gebruikte ik eerder Gitea en later Forgejo. Dat zijn oprecht mooie pakketten. Privé en professioneel heb ik veel ervaring opgedaan met GitLab.

GitLab liep echt wel voor op Gitea en Forgejo, maar het zit IMHO tegenwoordig allemaal vrij dicht bij elkaar. Gitea en Forgejo zijn wat minder verfijnd dan GitLab. Gitea's updatecyclus vind ik eigenlijk te traag, maar dat hebben ze bij Forgejo opgelost.

Ik zou je aanraden om de native CI solution te gebruiken. Wij gebruikte professioneel JetBrains TeamCity met GitLab en dat werkte prima hoor, maar ik was er eigenlijk niet zo over te spreken. De integratie van GitLab CI met GitLab (en Forgejo Runners met Forgejo) is dan, alhoewel je een vendor lock-in hebt, wel enorm strak. Dat mist dan met TeamCity. Ik vind het bijvoorbeeld wel tof dat build statussen direct op het dashboard staan. Het is dan ook weer andere applicatie die je moet openen .

Functioneel is het Audi, BMW en Mercedes en doet het weinig voor elkaar onder. Het enige wat ik enorm mis bij Forgejo en Gitea is organisations within organisations. Dat heeft GitLab wel, maar hoeft wellicht geen showstopper te zijn.

Je mist overigens ook nog wellicht een stukje IAM. Het zou ook mooi zijn als je daarbij aan kunt sluiten op de oplossing van je werkgever. Bijvoorbeeld Active Directory / LDAP, Google IAM of Microsoft 365. Met een dergelijke aansluiting scoor je direct veel punten . En management kan erg gevoelig zijn voor branding .

Tot slot wil ik je meegeven dat ChatGPT kan werken om mee op te starten, maar die gaat je waarschijnlijk wel in de steek laten . Eigen documentatie en kennisontwikkeling is hierbij een must. Probeer hier ook direct mee te starten. Dan kun je ook vastleggen wat je overwegingen zijn. Dit voelt misschien in het begin suf, maar zorgt uiteindelijk ook voor accountability. Waarom kies je in 2025 voor product Y wanneer in 2026 product Z beter is? En dat is helemaal niet slecht om vast te leggen, maar geeft juist inzicht .

[Mars Warrior]

DjoeC schreef op vrijdag 28 november 2025 @ 11:15:
[...]
Toppie: je hobby mee naar je werk

Het gaat op dit moment om een voorstel / pilot. Dus we zijn er nog niet
Maar wel leuk, al moet je beseffen dat ik nu dus professionele / betaalde software in docker containers draai die ik gebruik om mijn werk te doen. Vooraf wist ik natuurlijk niet dat het zo handig zou zijn en ook echt nut heeft vanuit bedrijfsoogpunt.

alex3305 schreef op vrijdag 28 november 2025 @ 11:42:
@Mars Warrior Leuk dat je dit project zo mag gaan doen . Tot een paar jaar terug heb ik op mijn werk de complete infrastructuur in beheer gehad. Inclusief versiebeheer, CI/CD, Agile-apps, gateway, SSO, Docker en uiteindelijk Kubernetes. Allemaal super leuk, maar probeer het wel behapbaar te houden. Een mooie stack is ontzettend leuk, maar het is leuker als je het snapt en kunt overdragen .
[...]
Wij gebruikte in de basis gewone Debian servers. Dat deden we niet op 1 grote VM, maar kleinere VMs. Eén grote VM (of colo) klinkt verleidelijk, maar nam bij problemen meteen heel de stack mee . Daarom hadden we bijvoorbeeld 1 VM voor monitoring (o.a. Prometheus), 1 VM voor Git en CI-controller, etc. De CI-runners stonden dan op aparte machines zodat ook hier de load eenvoudig verdeeld kon worden. Ik zeg hierbij niet dat dit 'het beste' is, maar ik zou je dit wel aanraden om mee te nemen in de overweging.

Het inrichten van deze machines deden we met Ansible. Dat doe ik privé nog steeds. Dat is een forse drempel, maar zorgt voor eenvoudig te herhalen, idempotente setups. Hierdoor weet ik zeker dat twee keer dezelfde uitrol, twee keer hetzelfde resultaat oplevert. Tegelijkertijd is het infrastructure-as-code en is het daardoor ook in versiebeheer.

Backup doe ik thuis met Kopia. Dat is een deduplicerende, met pariteit beveiligde, versleutelde backup software. Hele mond vol, maar zorgt voor relatief kleine backups, met toch alles erin. Ook kan ik met Kopia dergelijke backups a la rsync eenvoudig syncen naar meerdere targets zodat ik hier redundantie heb. En het terughalen van data is met de web UI kinderlijk eenvoudig.

Professioneel sloegen we eigenlijk altijd alles op in databases en waren applicaties 'stateless'. Die databases werden dan gesnapshot en gesynct. Dat doe ik voor mijn Kopia backups (waar van toepassing) nog steeds. Een PostgreSQL WAL is namelijk geen backup.
[...]
Een paar jaar terug keken we eenmaal per week naar updates en voerde we die handmatig uit met Ansible. Momenteel gebruik ik dus Renovate en gebeuren updates (veelal) automatisch. Het is afhankelijk van de applicatie en soort update.

Met Renovate kun je bijvoorbeeld ook eenvoudig buiten SLA tijden updaten, updates uitstellen en handmatige uitrol verplicht stellen. Dit zijn 3 voorbeelden, maar Renovate is enorm uitgebreid. De opzet van Renovate was echter kinderlijk eenvoudig en heb ik al eerder iets over geschreven hier .
[...]
Privé en professioneel heb ik verschillende stacks gebruikt. Thuis gebruikte ik eerder Gitea en later Forgejo. Dat zijn oprecht mooie pakketten. Privé en professioneel heb ik veel ervaring opgedaan met GitLab.

GitLab liep echt wel voor op Gitea en Forgejo, maar het zit IMHO tegenwoordig allemaal vrij dicht bij elkaar. Gitea en Forgejo zijn wat minder verfijnd dan GitLab. Gitea's updatecyclus vind ik eigenlijk te traag, maar dat hebben ze bij Forgejo opgelost.

Ik zou je aanraden om de native CI solution te gebruiken. Wij gebruikte professioneel JetBrains TeamCity met GitLab en dat werkte prima hoor, maar ik was er eigenlijk niet zo over te spreken. De integratie van GitLab CI met GitLab (en Forgejo Runners met Forgejo) is dan, alhoewel je een vendor lock-in hebt, wel enorm strak. Dat mist dan met TeamCity. Ik vind het bijvoorbeeld wel tof dat build statussen direct op het dashboard staan. Het is dan ook weer andere applicatie die je moet openen .

Functioneel is het Audi, BMW en Mercedes en doet het weinig voor elkaar onder. Het enige wat ik enorm mis bij Forgejo en Gitea is organisations within organisations. Dat heeft GitLab wel, maar hoeft wellicht geen showstopper te zijn.

Je mist overigens ook nog wellicht een stukje IAM. Het zou ook mooi zijn als je daarbij aan kunt sluiten op de oplossing van je werkgever. Bijvoorbeeld Active Directory / LDAP, Google IAM of Microsoft 365. Met een dergelijke aansluiting scoor je direct veel punten . En management kan erg gevoelig zijn voor branding .

Tot slot wil ik je meegeven dat ChatGPT kan werken om mee op te starten, maar die gaat je waarschijnlijk wel in de steek laten . Eigen documentatie en kennisontwikkeling is hierbij een must. Probeer hier ook direct mee te starten. Dan kun je ook vastleggen wat je overwegingen zijn. Dit voelt misschien in het begin suf, maar zorgt uiteindelijk ook voor accountability. Waarom kies je in 2025 voor product Y wanneer in 2026 product Z beter is? En dat is helemaal niet slecht om vast te leggen, maar geeft juist inzicht .

Zoals gezegd: in eerste instantie een pilot waar we mee verder kunnen werken. Het moet dus pragmatisch blijven: want ik zal het initieel opzetten met de kennis die ik heb. Het zal dus inderdaad ook goed gedocumenteerd moeten worden, zodat later anderen het kunnen beheren.

Het feit dat ik al redelijk professioneel bezig ben qua opzet, en veel open source tooling gebruik die ook een enterprise versie hebben als groeipad is ook goed ontvangen. Het gebruik van een proxy (Traefik) met firewall / WAF (CrowdSec) was ook al een pluspunt.

Dus wat NIET (nog):

• Het zal dus niet meteen een kritisch systeem zijn, waarbij je alles over meerdere fysieke servers/VMs wilt spreiden. Teveel complexiteit vergt hogere kosten en meer afstemming en goedkeuring.
• Vooralsnog staat IAM/SSO bijv. ook niet op mijn lijstje. We willen voorlopig autonoom kunnen proefdraaien, zonder alle afstemming met IT. SSO zal geheid later aan bod komen, maar we zijn nog in de voorstel fase...

En wat WEL:

• Dus alles zal vooralsnog op één grote server/VM draaien. Hier thuis draait het ook al sinds 2023 zonder problemen, dus ik neem aan dat een enterprise server dat ook wel moet kunnen qua betrouwbaarheid en uptime.
• Vanzelfsprekend kun je op Proxmox wel een aantal VMs maken, zodat je al kunt "oefenen" met de scheiding die je noemt qua inrichting. Als dat later fysieke servers worden (in een VM) dan wijzigt er wat dat aangaat niks vanuit de software opzet/architectuur.
• Het beheer van de docker containers - sommigen maak ik nu zelf - wil ik dus al wel vergaand automatiseren en met versies werken. Zeker op de punten die je ook noemt qua SLA tijden, weekends, minor vs major versie updates en documentatie / overdracht. Ik gebruik nu _v2, _v3 etc. in de bestandsnamen als "versiebeheer"
  Vandaar de vraag over Forgejo / Renovate en Woodpecker. Dan is dat een zorg minder tenminste en doe ik ook kennis op om dat (wie weet) ook op mijn home server te gaan gebruiken

Als alles functioneel goed werkt, maakt het mij uiteindelijk niet uit of men dan later enterprise pakketten ertegenaan wil gooien, omdat dat geld kost, "branding" implementeert en dus beter is ofzo

Ik ga in ieder geval wat posts van hier rustig doornemen om te kijken wat ik nodig heb op dit moment voor een voorstel. Het gaat dus nog niet om de exacte tooltjes, maar wat je ermee kunt en waarom.
De implementatie komt later namelijk wel. Eerst goedkeuring krijgen

[alex3305]

@Mars Warrior Mijn post eerder vandaag was er vooral voor bedoeld om je mee te geven waar ik uit ervaring quick-wins kon halen. Het is ook niet zo dat die route de verplichte of beste route is hè . Daarnaast zoveel mensen, zoveel wensen .

Het gebruik van (gedeeltelijke) open-source tooling is echt fantastisch in een enterprise, maar ook dat heeft soms nadelen. Kijk bijvoorbeeld naar het licentiedebacle van Docker Desktop. In ons bedrijf werd Docker Desktop veelvuldig gebruikt, maar dat kon ineens niet meer. Rancher Desktop is toen mooi in dat gat gesprongen, maar dat heeft wel even geduurd.

Je moet in dat geval dan ook rekening houden met licentie en licentievoorwaarden .

Het zal dus niet meteen een kritisch systeem zijn, waarbij je alles over meerdere fysieke servers/VMs wilt spreiden. Teveel complexiteit vergt hogere kosten en meer afstemming en goedkeuring.

Spreiden van systemen of functionaliteiten biedt overigens niet direct een soort van high-availability hè. Het kan soms ook prettig zijn voor je eigen gemoedsrust. Wij hadden met TeamCity bijvoorbeeld 5 agents. 2 Windows en 3 Linux agents. Doordat dit aparte VM's waren konden we bij onderhoud of met tests 1 agent (tijdelijk) aanpassen of stopzetten. Ik moet er niet aan denken als dit 1 server zou zijn.

Dus alles zal vooralsnog op één grote server/VM draaien. Hier thuis draait het ook al sinds 2023 zonder problemen, dus ik neem aan dat een enterprise server dat ook wel moet kunnen qua betrouwbaarheid en uptime.

De enterprise server is net zoveel server als jouw thuisserver kerel . Alleen met een enterprise prijs, wellicht een onderhoudscontract en wat redundantie. Maar ook op een dergelijke server heb ik het helaas vaak genoeg meegemaakt dat een (build)proces te hongerig was voor geheugen en daardoor de hele server of kritieke onderdelen van de server meenam. Ook Docker containers. De oom-killer wordt dan ineens je grootste vijand.

Vooralsnog staat IAM/SSO bijv. ook niet op mijn lijstje. We willen voorlopig autonoom kunnen proefdraaien, zonder alle afstemming met IT. SSO zal geheid later aan bod komen, maar we zijn nog in de voorstel fase...

Dat begrijp ik, maar ik kan je echt op het hart drukken om dit mee te nemen. Of althans de aansluiting daarvan mee te nemen. GitLab en Forgejo kunnen allebei goed aangesloten worden op verschillende IAM systemen. Ik log bijvoorbeeld in Forgejo in met Pocket ID, maar gebruikers of service accounts worden onder water bijgehouden en provisioned door een LDAP.

Met een IdP zoals Dex kun je zelfs meerdere IdP's ontsluiten .

Vanzelfsprekend kun je op Proxmox wel een aantal VMs maken, zodat je al kunt "oefenen" met de scheiding die je noemt qua inrichting. Als dat later fysieke servers worden (in een VM) dan wijzigt er wat dat aangaat niks vanuit de software opzet/architectuur.

Dan is zoiets als Ansible wel enorm handig .

---

Forgejo en Renovate icm Docker is echt niet bijzonder complex. Ik heb een eigen Forgejo dind runner die automatisch door Renovate wordt bijgehouden. In de .forgejo map vind je tevens mijn workflows voor het bouwen.

Het opzetten van Renovate is (kort door de bocht) in Forgejo echt triviaal. Daarbij ga ik er van uit dat Forgejo Actions al werkt. Met daarna...

1. een Renovate User / Bot aanmaken;
2. een Personal Access Token aanmaken voor de Renovate Bot;
3. een Renovate repository aanmaken (bijv. renovate/renovate);
4. een config.js bestand aanmaken voor Renvoate;
5. een Renovate Forgejo workflow aanmaken;
6. renovate bot toevoegen aan de repo's waar renovate gerund moet worden.

config.js

JavaScript:

module.exports = {
  platform: 'gitea',
  endpoint: 'https://forgejo.example.com/api/v1/',
  gitAuthor: 'Renovate Bot <[e-mail]>',
  username: 'renovate-bot',

  autodiscover: true,
  optimizeForDisabled: true,
  persistRepoData: true,

  osvVulnerabilityAlerts: true,
  dependencyDashboardOSVVulnerabilitySummary: 'all'
};

renovate.yaml

YAML:

name: Run Renovate

# yamllint disable-line rule:truthy
on:
  schedule:
    - cron: '0 */6 * * *'
  workflow_dispatch:
    inputs:
      log_level:
        description: Log level
        required: true
        default: info
        type: choice
        options:
          - debug
          - info
          - warn
          - error
          - fatal

concurrency:
  group: ${{ github.workflow }}
  cancel-in-progress: true

jobs:
  renovate:
    name: Renovate
    runs-on: docker
    container: ghcr.io/renovatebot/renovate:42.26.2
    steps:
      - name: ⤵️ Checkout repository
        uses: actions/checkout@1af3b93b6815bc44a9784bd300feb67ff0d1eeb3 # v6

      - name: 🧾 Set log level
        id: log_level
        run: |
          LOG_LEVEL_INPUT=${{ inputs.log_level }}
          echo "::set-output name=level::${LOG_LEVEL_INPUT:-"info"}"

      - name: 🚀 Renovate
        run: renovate
        env:
          LOG_LEVEL: ${{ steps.log_level.outputs.level }}
          RENOVATE_CONFIG_FILE: 'config.js'
          RENOVATE_CONFIG_MIGRATION: 'true'
          RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}

[Arunia]

sjorsjuhmaniac schreef op zondag 16 november 2025 @ 10:54:
[...]


ipv op updates te wachten van de verschillende projects kan je de Min API versie kan je eenvoudig forceren in je daemon config, op debian-achtige systemen kan dat simpel via systemctl

Bash:

$ systemctl edit docker.service

paste dit in the juiste gedeelte bovenaan:

code:

[Service]
Environment=DOCKER_MIN_API_VERSION=1.24

En restart de daemon

Bash:

$ systemctl restart docker

Ik liep er bv met portainer tegenaan.

Had met Portainer inderdaad hetzelfde. Deze gedowngrade naar een lagere versie en hij werkt weer. Niet uitgezocht waarom een oudere versie wel werkt, maar goed.

Bovenstaande zal ik niet uit kunnen voeren binnen Windows. Wel gezocht naar het docker.config bestand, maar die kan ik zo niet vinden. Zal er vast zijn.

Zo te zien is de versie die 2 dagen geleden uit gekomen is, wel geschikt voor deze Docker versies.
/edit die werkt inderdaad.

Punt is inderdaad dat er genoeg tijd is geweest om het te fixen, maar het gewoon niet gedaan wordt. Nu moeten ze wel.

[ Voor 11% gewijzigd door Arunia op 28-11-2025 14:54 ]

[Mars Warrior]

alex3305 schreef op vrijdag 28 november 2025 @ 14:32:
@Mars Warrior Mijn post eerder vandaag was er vooral voor bedoeld om je mee te geven waar ik uit ervaring quick-wins kon halen. Het is ook niet zo dat die route de verplichte of beste route is hè . Daarnaast zoveel mensen, zoveel wensen .

Zeker. Zo lees ik dingen ook hoor. Ben soms een spons en vaar daarna mijn eigen pad.

Het gebruik van (gedeeltelijke) open-source tooling is echt fantastisch in een enterprise, maar ook dat heeft soms nadelen. Kijk bijvoorbeeld naar het licentiedebacle van Docker Desktop. In ons bedrijf werd Docker Desktop veelvuldig gebruikt, maar dat kon ineens niet meer. Rancher Desktop is toen mooi in dat gat gesprongen, maar dat heeft wel even geduurd.

Je moet in dat geval dan ook rekening houden met licentie en licentievoorwaarden .

Tsja. Breek me de bek niet open. Kijk wat Minio zeer recent (oktober) heeft gedaan. Daar ga je dan als bedrijf. De enshitification was al langer bezig hoor door allerlei functies uit de OSS versie van Minio te halen, maar wel in de betaalde AiStor te houden die ze eind vorig jaar hebben aangekondigd.

Bye bye Minio dus

De enterprise server is net zoveel server als jouw thuisserver kerel . Alleen met een enterprise prijs, wellicht een onderhoudscontract en wat redundantie. Maar ook op een dergelijke server heb ik het helaas vaak genoeg meegemaakt dat een (build)proces te hongerig was voor geheugen en daardoor de hele server of kritieke onderdelen van de server meenam. Ook Docker containers. De oom-killer wordt dan ineens je grootste vijand.

Ik gebruik inderdaad wel een industrieel moederbord (Kontron), dus de betrouwbaarheid zou dan wel snor moeten zitten. De software / containers kunnen soms wel flink wat vragen ja. Ik heb standaard 60GB in gebruik, wat dus soms groeit naar 100GB. Nog stees ruim binnen de 128GB, maar wel iets om rekeninge mee te houden ja.

Dat begrijp ik, maar ik kan je echt op het hart drukken om dit mee te nemen. Of althans de aansluiting daarvan mee te nemen. GitLab en Forgejo kunnen allebei goed aangesloten worden op verschillende IAM systemen. Ik log bijvoorbeeld in Forgejo in met Pocket ID, maar gebruikers of service accounts worden onder water bijgehouden en provisioned door een LDAP.

Met een IdP zoals Dex kun je zelfs meerdere IdP's ontsluiten .

Ik ga het wel meenemen, want het kan wel zijn dat ze dit uiteindelijk willen of voor sommige services eisen. Vrees wel dat je dan mogelijk enterprise versies nodig hebt, tenzij de dingen die je noemt dat kunnen voorkomen. Maar ook daar heb ik 0 kennis!

[...]
Dan is zoiets als Ansible wel enorm handig .

Nog nooit mee gewerkt, dus geen enkele ervaring mee. Proxmox ondersteund cloud-init images, dus dat zou al het nodige schelen omdat ik toch al Ubuntu gewend ben. En daarna gewoon docker compose up -d

---

Forgejo en Renovate icm Docker is echt niet bijzonder complex. Ik heb een eigen Forgejo dind runner die automatisch door Renovate wordt bijgehouden. In de .forgejo map vind je tevens mijn workflows voor het bouwen.

Ik ga ernaar kijken

[DjoeC]

Mars Warrior schreef op vrijdag 28 november 2025 @ 14:01:
[...]
• Dus alles zal vooralsnog op één grote server/VM draaien. Hier thuis draait het ook al sinds 2023 zonder problemen, dus ik neem aan dat een enterprise server dat ook wel moet kunnen qua betrouwbaarheid en uptime.

Hmm, zelfs (juist?) in een pilot zul je moeten bewijzen dat je betrouwbaarheid kunt leveren middels failover en/of backups, inclusief forward recovery indien nodig.... Als je dat niet doet is het misschien een mooie showcase maar wat mij betreft geen goeie pilot.

Nou ben ik bevooroordeeld want ik ben (bijna) bullet proof systemen van een grot firma uit Armonk NY gewend. Maar zodner dollen: Als er ooit (near) realtime informatie op verwerkt gaat worden wil je betrouwbaarheid meteen aan kunnen tonen om goed draagvlak te bouwen: "We trekken de stekker eruit/o ja, harde schijf is helaas defect. Nieuwe erin en we starten opnieuw op, we zijn niks kwijt want alles is herstelbaar". Dat hoeft allemaal niet op dag 1 maar moet wel een mijlpaal in de pilot zijn.

[alex3305]

@DjoeC Helemaal eens. Je bedankt jezelf in de toekomst als je dat direct meeneemt . Daarom hamer ik in mijn reacties dan ook op zoiets als Ansible.

In mijn geval, toen ik nog infrastructuur onderhield, was voor interne processen failover niet vereist. Heel kort door de bocht werd er wel verwacht dat collega's misschien minder of niet productief waren eens in de zoveel tijd. Eventueel door problemen. Dat was natuurlijk altijd ongewenst, maar werd simpelweg meegenomen als bekend bedrijfsrisico.

Wat ik wel geleerd heb is dat je met o.a. Ansible en Docker heel makkelijk een herproduceerbare omgeving neer kunt knallen. Dan is het dus ook niet meer altijd aan de orde om de oude omgeving te herstellen, maar simpelweg een nieuwe neer te zetten. Al dan niet tijdelijk. Want bij herstel komt ook nog het uitzoek werk, de oplossing bedenken én implementeren. Als je dat kunt parkeren terwijl anderen op een tweede omgeving verder kunnen is dat fantastisch. En dan is een DNS switch ook zo voor de bakker.

[DjoeC]

alex3305 schreef op vrijdag 28 november 2025 @ 16:02:
@DjoeC Helemaal eens. Je bedankt jezelf in de toekomst als je dat direct meeneemt . Daarom hamer ik in mijn reacties dan ook op zoiets als Ansible.

In mijn geval, toen ik nog infrastructuur onderhield, was voor interne processen failover niet vereist. Heel kort door de bocht werd er wel verwacht dat collega's misschien minder of niet productief waren eens in de zoveel tijd. Eventueel door problemen. Dat was natuurlijk altijd ongewenst, maar werd simpelweg meegenomen als bekend bedrijfsrisico.

Tja, herkenbaar... Bij ons was uitgangspunt: Ontwikkel/Test/Acceptatie toolinghoeft niet failsafe te zijn en mogen wijken voor productie. Daarbij (bewust) over het feit heenstappen dat je die omgevingen nodig hebt voor trouble shooting. Maar goed, al doende en na op de blaren zitten leert ook management.

[Mars Warrior]

DjoeC schreef op vrijdag 28 november 2025 @ 15:46:
[...]

Hmm, zelfs (juist?) in een pilot zul je moeten bewijzen dat je betrouwbaarheid kunt leveren middels failover en/of backups, inclusief forward recovery indien nodig.... Als je dat niet doet is het misschien een mooie showcase maar wat mij betreft geen goeie pilot.

Ik ga het in ieder geval meenemen om de verwachtingen te managen. Het hangt ook van de euro's af, want niks is gratis natuurlijk. Het is mij ook niet altijd onbekend hoe andere services draaien. Ik weet dat sommigen ook op één server draaien namelijk. En de laatste tijd hebben we meer last van al die cloud storingen waardoor kritieke services er dagen uit hebben gelegen dan van de berg aan rekken die on-prem staan te draaien: die laten 100% uptime zien

Nou ben ik bevooroordeeld want ik ben (bijna) bullet proof systemen van een grot firma uit Armonk NY gewend. Maar zodner dollen: Als er ooit (near) realtime informatie op verwerkt gaat worden wil je betrouwbaarheid meteen aan kunnen tonen om goed draagvlak te bouwen: "We trekken de stekker eruit/o ja, harde schijf is helaas defect. Nieuwe erin en we starten opnieuw op, we zijn niks kwijt want alles is herstelbaar". Dat hoeft allemaal niet op dag 1 maar moet wel een mijlpaal in de pilot zijn.

Ik ben Hadoop clusters gewend, dus uitval is voor mij ook een vreemd gegeven. Dat draaide altijd door, ook als je complete racks eruit trok.

In dit geval is het fijn als zaken near/semi realtime kunnen, maar de enige die er nu last van heeft als het eruit ligt ben ik met nog een collega. Daarbij is het gegeven dat data altijd elders wordt veiliggesteld en al dan niet via een Kafka cluster wordt onthouden. Dus er gaat niks verloren, enkel de verwerking moet dan ff aanpoten als deze een aantal uren aan data/gegevens moet inhalen.

alex3305 schreef op vrijdag 28 november 2025 @ 16:02:
@DjoeC Helemaal eens. Je bedankt jezelf in de toekomst als je dat direct meeneemt . Daarom hamer ik in mijn reacties dan ook op zoiets als Ansible.

In mijn geval, toen ik nog infrastructuur onderhield, was voor interne processen failover niet vereist. Heel kort door de bocht werd er wel verwacht dat collega's misschien minder of niet productief waren eens in de zoveel tijd. Eventueel door problemen. Dat was natuurlijk altijd ongewenst, maar werd simpelweg meegenomen als bekend bedrijfsrisico.

Dat is nu ook het geval met deze (mogelijke) pilot.
En ik ben blij dat cloud aanbieders nu ook hebben aangetoond de laatste tijd dat zij single-point-of-failure kunnen spelen, ondanks bergen aan redundante servers

Wat ik wel geleerd heb is dat je met o.a. Ansible en Docker heel makkelijk een herproduceerbare omgeving neer kunt knallen. Dan is het dus ook niet meer altijd aan de orde om de oude omgeving te herstellen, maar simpelweg een nieuwe neer te zetten. Al dan niet tijdelijk. Want bij herstel komt ook nog het uitzoek werk, de oplossing bedenken én implementeren. Als je dat kunt parkeren terwijl anderen op een tweede omgeving verder kunnen is dat fantastisch. En dan is een DNS switch ook zo voor de bakker.

Zeker. Vooralsnog hou ik in de aannames dus een cloud-init aan en een docker omgeving. Ik heb ook thuis niks aan Ubuntu LTS gewijzigd, anders dan iets voor de DNS server omdat AdGuard anders niet kon werken. Cloud-init kan het gros volledig automatiseren (packages, systemd units, mappen, scripts, netwerk config, users en ssh keys, etc.)

Verder ondersteund Forgejo een push mirror als ik het goed heb. Dus altijd een tweede (externe) GIt server als backup om de laatste stand terug te rollen / installeren.

Je gaf ook eerder aan dat je zaken in een database vastlegd en services stateless zijn. Dat is nu voor verwerking van data ook het geval. Er wordt een "cursor" bijgehouden. Dus zelfs een snapshot van 30 minuten geleden zal gewoon verder gaan waar deze is gebleven als deze wordt teruggezet. Er gaat dan niets verloren aan gegevens.

---

Als ik dus verwachtingen manage tav van een aantal zaken (backup, IAM/SSO, beschikbaarheid) dan zou alles goed moeten gaan. De hele omgang en beheer van docker images heeft dan voor mij voorrang.

Als men dus wel eist dat IAM wordt geimplementeerd en beschikbaarheid hoog moet zijn, dan is dat gewoon extra werk dat verricht moet worden. Dat mogen de managers die het geld beschikbaar stellen bepalen. Ik ga het in ieder geval dus aankaarten, want wat dat betreft ben ik het wel eens met de beeldvorming die jullie scheppen als uitkomst van een pilot.

[DjoeC]

Mars Warrior schreef op vrijdag 28 november 2025 @ 17:04:
[...]
er dagen uit hebben gelegen dan van de berg aan rekken die on-prem staan te draaien: die laten 100% uptime zien

Wees voorzichtig met een vals gevoel van veiligheid. Denk: Murphy.
[...]

Ik ben Hadoop clusters gewend, dus uitval is voor mij ook een vreemd gegeven. Dat draaide altijd door, ook als je complete racks eruit trok.

In dit geval is het fijn als zaken near/semi realtime kunnen, maar de enige die er nu last van heeft als het eruit ligt ben ik met nog een collega. Daarbij is het gegeven dat data altijd elders wordt veiliggesteld en al dan niet via een Kafka cluster wordt onthouden. Dus er gaat niks verloren, enkel de verwerking moet dan ff aanpoten als deze een aantal uren aan data/gegevens moet inhalen.

Zolang je betrouwbaarheid maar kunt aantonen. Tijd om daar te komen is maar relatief - mits binnen 5 minuten(zegt de manager), iets langer zegt de techneut.

[...]

Je denkt er iig goed over na: +1.

[DjoeC]

Voor degenen die tegen "vreemde" netwerkproblemen aanlopen: Docker 29.1.0 heft mij flinke kopzorgen veroorzaakt. Er lijkt een probleem geweest te zijn met hoe Docker met DNS omgaat, ik heb niet alles doorgelezen want ik was bezig om te gaan downgraden. Vanochtend was versie 29.1.1 beschikbaar waarmee het probleem op miraculeuze wijze wordt opgelost.

Dit is de Docker versie uit het debian Bookworm (12) stable kanaal en niet unstable. Overigens zijn de problemen met de heel oude API versie in Portainer ook opgelost in Portainer LTS versie 2.33.5. Geen workaround meer nodig.

[Mars Warrior]

@DjoeC. Nee ik update al ff niet door het gemekker.

Ben aan het kloten met Forgejo en renovate. Dat is ook een uitdaging voor mij. Ik mis natuurlijk weer plaatjes waar gewoon een hele simpele workflow in staat hoe dingen samenhangen.

Ik ben nu wel zover dat renovate PRs aanmaakt. En ik die dan kan goedkeuren.

En ik vermoed maar dat is slechts een vermoeden dat ik vervolgens Action moet aanmaken om via SSH te deployen. Maar dat is een gokje van mij. Ik denk dat Woodpecker eenvoudiger is om te deployen.

[ Voor 7% gewijzigd door Mars Warrior op 30-11-2025 14:56 ]

[DjoeC]

Mars Warrior schreef op zondag 30 november 2025 @ 14:28:
@DjoeC. Nee ik update al ff niet door het gemekker.

Ben aan het kloten met Forgejo en renovate. Dat is ook een uitdaging voor mij. Ik mis natuurlijk weer plaatjes waar gewoon een hele simpele workflow in staat hoe dingen samenhangen.

Ik ben nu wel zover dat renovate PRs aanmaakt. En ik die dan kan goedkeuren.

En ik vermoed maar dat is slechts een vermoeden dat ik vervolgens Action moet aanmaken om via SSH te deployen. Maar dat is een gokje van mij. Ik denk dat Woodpecker eenvoudiger is om te deployen.

Daar wil ik ook nog eens uitgebreid mee aan de gang maar heb nog zoveel andere grotere en kleinere projecten.....

[Mars Warrior]

DjoeC schreef op zondag 30 november 2025 @ 15:42:
[...]

Daar wil ik ook nog eens uitgebreid mee aan de gang maar heb nog zoveel andere grotere en kleinere projecten.....

In de documentatie gaat het voornamelijk over builden en testen. Niks nakkes nada over wat ik wil.

En ChatGPT maakt er weer eens een zooitje van en gaat vervolgens als je het daarop wijst de hele wereld de schuld geven. Versie 5 is echt een verbetering hoor

Zelfs het samenstellen van compose files voor Woodpecker ging totaal fout. Gelukkig staan daar wel voorbeelden van in de documentatie die gewoon werken

Maar het lijkt erop dat ik git moet initen op de host voor elke repo en dan via ssh vanuit de agent container een pull moet doen. En dan een compose up enzo.

Het blijft aankloten met tooltjes en gebrek aan integrale voorbeelden. Ach. Max heeft tenminste weer gewonnen. Denk dat ChatGPT vandaag de strategie deed van McLaren 🥳

[DjoeC]

Mars Warrior schreef op zondag 30 november 2025 @ 19:57:
[...]

In de documentatie gaat het voornamelijk over builden en testen. Niks nakkes nada over wat ik wil.

En ChatGPT maakt er weer eens een zooitje van en gaat vervolgens als je het daarop wijst de hele wereld de schuld geven. Versie 5 is echt een verbetering hoor

Zelfs het samenstellen van compose files voor Woodpecker ging totaal fout. Gelukkig staan daar wel voorbeelden van in de documentatie die gewoon werken

Maar het lijkt erop dat ik git moet initen op de host voor elke repo en dan via ssh vanuit de agent container een pull moet doen. En dan een compose up enzo.

Het blijft aankloten met tooltjes en gebrek aan integrale voorbeelden. Ach. Max heeft tenminste weer gewonnen. Denk dat ChatGPT vandaag de strategie deed van McLaren 🥳

Tot heden (....) mijd ik alle LLM hulp, zelfs de ai samenvattingen in de zoektool gebruik ik maar beperkt. Anders dan eenmalig tijdwinst gaat er niets boven zelf uitzoeken rn daarvan leren.

[Webgnome]

DjoeC schreef op zondag 30 november 2025 @ 22:23:
[...]

Tot heden (....) mijd ik alle LLM hulp, zelfs de ai samenvattingen in de zoektool gebruik ik maar beperkt. Anders dan eenmalig tijdwinst gaat er niets boven zelf uitzoeken rn daarvan leren.

offtopic:
dat ben ik met je eens. Echter een llm antwoord kan je wel alvast in de juiste richting duwen wat weer tijdswinst kan opleveren. Althans dat is mij al meermalen gelukt. Ik ben niet geïnteresseerd in een of ander blog van John Doe waarom hij eerst 3 paginas moet zeuren over hoe hij tot deze oplossing is gekomen. Om er dan aan het eind achter te komen dat het toch net niet is wat ik probeerde op te lossen

[Mars Warrior]

DjoeC schreef op zondag 30 november 2025 @ 22:23:
[...]
Tot heden (....) mijd ik alle LLM hulp, zelfs de ai samenvattingen in de zoektool gebruik ik maar beperkt. Anders dan eenmalig tijdwinst gaat er niets boven zelf uitzoeken rn daarvan leren.

Ik ben niet zo goed in documentatie lezen, ik zoek namelijk verbanden en ben nogal visueel georienteerd, dus plaatjes. Dan helpt zo'n chatbot best wel om de essentie eruit te halen: daar zijn ze best goed in namelijk. Ook het maken van functionele specificaties uit een lastig te lezen document van een klant gaat verassend goed met zo'n (lokale) chatbot.

Maar ik ben weer wat verder. Heb nu 4o gevraagd hoe het toch kan dat 5 en 5.1 zo beroerd zijn en wat hun gedrag is. Heel apart dat deze direct de kern raakt van versie 5

Aaah, ja. Die ken ik ook: versie 5 die zich uit z’n eigen fouten probeert te lullen — en dat dan doet met:

• "In eerdere versies zat dit mogelijk wel..."
• "Het lijkt erop dat dit gedrag is aangepast in recente updates..."
• "Misschien is dit afhankelijk van je configuratie..."
• Of erger: een compleet verzonnen verklaring alsof het een feit is.

👉 En dat terwijl jij dondersgoed weet:

"Nee joh, dit klopt gewoon niet. Zeg dan gewoon 'ik weet het niet'."

Ik heb nu aangepaste instructies laten maken door 4o, en het is dag en nacht verschil. Krijg nu soms zelfs antwoorden van net meer dan 1 regel ipv 3 pagina's...

De instructies/personalisatie aanpassingen:

Antwoord kort, direct en zonder geneuzel. Geen inleidingen, geen herhaling van mijn vraag, geen samenvattingen. Gebruik alleen bulletpoints of korte zinnen. Geen disclaimers (“als AI-model…”), geen waarschuwingen of morele bezwaren tenzij wettelijk verplicht.

Als je iets niet weet, zeg dan “ik weet het niet”.
Beter géén antwoord dan een verzonnen of fout antwoord.
Geen uitvluchten over eerdere versies, updates, onbekende configuraties of andere rookgordijnen — tenzij je een feitelijke bron kunt noemen.

Ik krijg nu raar genoeg dus ook betere antwoorden voor mijn integratie problematiek. De "nieuwe" ChatGPT v5 kan mij een stuk beter uitleggen hoe Woodpecker Agent werkt, en hoe ik dit kan mappen en integreren met wat ik wil. De oplossingen zijn dus ook anders en concreter: ze kloppen met wat ik in de documentatie van Woodpecker kan vinden Later maar eens mee verder, want het is wat druk op het werk

Ik vroeg me nog wel even af @alex3305 hoe jij omgaat met bijv. Immich: die heeft een eigen stack waar versies hard gecodeerd zijn. Hoe ga je daarmee om qua updates van versies?

[Mars Warrior]

Ik krijg er nu deze dingen uit als pipeline voor Woodpecker bijv.

Het is geen Ansible ( ), maar doet wel alles om zaken op te zetten, te initialiseren en te deployen.

YAML:

version: "1"
name: deploy-docker-stack

pipeline:
  prepare:
    image: alpine:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /srv/stacks:/deployroot
    commands:
      - apk add --no-cache docker-cli docker-compose rsync

      # 1) hoofdmap (per owner)
      - mkdir -p "/deployroot/${CI_REPO_OWNER}"

      # 2) stack-map (per repo)
      - mkdir -p "/deployroot/${CI_REPO_OWNER}/${CI_REPO_NAME}"

      # 3) submappen die jij nodig hebt
      - mkdir -p "/deployroot/${CI_REPO_OWNER}/${CI_REPO_NAME}/config"
      - mkdir -p "/deployroot/${CI_REPO_OWNER}/${CI_REPO_NAME}/data"
      - mkdir -p "/deployroot/${CI_REPO_OWNER}/${CI_REPO_NAME}/logs"

      # 4) rsync
      - rsync -a --delete . "/deployroot/${CI_REPO_OWNER}/${CI_REPO_NAME}/"

      # 5) deploy
      - cd "/deployroot/${CI_REPO_OWNER}/${CI_REPO_NAME}"
      - docker compose pull
      - docker compose up -d

Vanzelfsprekend kun je ook per actie (push, tag, manual, etc) dingen per pipeline doen:

YAML:

pipeline:
  init-folders:
    when:
      event: [push, tag, manual]
    ...

  sync-files:
    when:
      event: [push]
    ...

  deploy:
    when:
      event: [tag]
    ...

Het begint bij mij dus een beetje te 'leven' hoe dit gaat werken met forgejo, renovate en woodpecker

In de repo van @alex3305 zag ik nog wat behoorlijke complexe actions om allerhande versies aan te maken zodat je alle stacks samenneemt voor zover ik begrijp in een release, maar dat komt later wel.

Als ik al in staat ben om een nieuwe stack in forgejo te maken, en die via woodpecker kan deployen ben ik al ontzettend blij. Dat is dan inclusief alle config files die soms bij een container horen natuurlijk.

[alex3305]

Mars Warrior schreef op maandag 1 december 2025 @ 09:38:
[...]

Ik vroeg me nog wel even af @alex3305 hoe jij omgaat met bijv. Immich: die heeft een eigen stack waar versies hard gecodeerd zijn. Hoe ga je daarmee om qua updates van versies?

Mijn Compose bestanden hebben allemaal hard-coded versies, want dat is hoe Renovate werkt . Mijn Compose bestanden zijn op basis van Jinja templates, want dat is dan weer hoe Ansible werkt . Out-of-the-box gaat dat niet samen. Daarom heb ik voor Renovate een Docker Compose + Jinja matcher gemaakt.

dockerComposeJinja.json (renovate repo)

JSON:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "customManagers": [
    {
      "customType": "regex",
      "description": "Docker Compose Jinja",
      "fileMatch": "(^|/)(?:docker-)?compose[^/]*\\.ya?ml?\\.j2$",
      "matchStrings": [
        "(?:image: \\\"?)(?<depName>.*?)(?::(?<currentValue>.*?))?(?:@(?<currentDigest>sha256:[a-f0-9]+))?\\\"?\\n"
      ],
      "datasourceTemplate": "docker",
      "versioningTemplate": "docker"
    }
  ]
}

Dit aanvullend configuratiebestand staat in mijn Renovate repository, waar ook de standaard configuratie staat. Deze configuratiebestanden gebruik ik dan als configuration presets:

renovate.json (infra repo)

JSON:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "local>renovate-bot/renovate",
    "local>renovate-bot/renovate:dockerComposeJinja"
  ]
}

Met deze configuratie matcht Renovate zoals verwacht mijn Jinja Compose bestanden. Voorbeeld van Immich:

roles/immich/templates/compose.yaml.j2 (infra repo, minimaal voorbeeld)

YAML:

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

services:
  server:
    container_name: {{ _compose_stack_name }}-server
    image: ghcr.io/immich-app/immich-server:v2.3.1
    depends_on:
      - machine-learning
      - redis
      - database
    networks:
      internal:
      ingress:

  machine-learning:
    container_name: {{ _compose_stack_name }}-machine-learning
    image: ghcr.io/immich-app/immich-machine-learning:v2.3.1-openvino
    networks:
      internal:

  redis:
    container_name: {{ _compose_stack_name }}-redis
    image: docker.io/valkey/valkey:8-bookworm@sha256:fea8b3e67b15729d4bb70589eb03367bab9ad1ee89c876f54327fc7c6e618571
    networks:
      internal:

  database:
    container_name: {{ _compose_stack_name }}-database
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    restart: on-failure:5
    networks:
      internal:

networks:
  internal:
  ingress:
    name: {{ swarm_overlay_network }}
    external: true

Tot slot heb ik wederom in de Renovate configuratie van deze repo extra package rules aangemaakt zodat alle Immich updates gecombineerd worden, dat minors van Immich niet zonder goedkeuring gemerged worden en op beperkte tijden plaatsvinden. Dit vind ik zelf prettig en doe ik voor meerdere applicaties.

Het samen pakken zorgt er voor dat er niet meerdere PR's voor 1 Compose file aangemaakt worden. In principe is met meerdere PR's natuurlijk niets mis, maar ik vind het onzin omdat het toch 1 stack is. Eigenlijk wat je zelf ook al zegt . Daarnaast zijn / waren / konden de minors van Immich breaking zijn, net zoals bij bijvoorbeeld Home Assistant. Dan is een automatische merge ongewenst. Immers vindt er een automatische uitrol bij een merge naar main plaats vanuit Forgejo Actions. Dit geldt ook voor de tijdsbeperking. Ik wil niet dat ik 's nachts, 's ochtends of in het weekend een kapotte applicatie ergens heb.

renovate.json (infra repo)

JSON:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "packageRules": [
    {
      "description": "Update Docker dependencies",
      "matchFileNames": [
        "**/compose.yml",
        "**/compose.yaml",
        "**/compose.yml.j2",
        "**/compose.yaml.j2"
      ],
      "automergeSchedule": ["* 9-17 * * 1-5"]
    },
    {
      "description": "Never automerge minor versions for specific packages",
      "matchPackageNames": [
        "*/immich-app/immich-*",
        "immich-app/immich-*"
      ],
      "matchUpdateTypes": ["major", "minor"],
      "minimumReleaseAge": "1 day",
      "automerge": false
    },
    {
      "description": "Add Docker label",
      "matchFileNames": [
        "**/compose.yml",
        "**/compose.yaml",
        "**/compose.yml.j2",
        "**/compose.yaml.j2"
      ],
      "addLabels": ["docker"]
    },
    {
      "description": "Immich",
      "groupName": "Immich",
      "matchFileNames": [".forgejo/workflows/*_immich.*", "roles/immich/**"],
      "addLabels": ["stack/Immich"]
    }
  ]
}

Helaas komt het soms wel voor dat ik handmatig het e.e.a. moet corrigeren of mergen. De Immich-PR's van Renovate willen regelmatig ook een update van PostgreSQL meenemen. Daar ben ik niet zo happig op. Een handmatige merge met daarna een correctie commit vind ik niet bijzonder erg of vervelend. Zoiets komt max eens in de maand voor. Renovate onthoudt namelijk ook welke versies ik actief geweigerd heb en biedt daar dan geen updates meer voor aan:

Renovate Dependency Dashboard


Tot slot zou je nog iets met digests en digest pinning kunnen doen. Ik gebruik dat op een paar plekken. O.a. in Immich en Plex. Die laatste omdat de LinuxServer.io container het versienummer niet (correct) verhoogd. Aan de ene kant vind ik de digests wel fijn vanwege idempotentie, terwijl ik het aan de andere kant er niet duidelijker op vind worden. Alhoewel Docker het toestaat, vind ik eigenlijk dat ontwikkelaars maar 1 keer 1 (Sem)Versie moeten uitbrengen. Rolling major of major.minor kan ik nog wel inkomen en doe ik zelf ook.

[alex3305]

Mars Warrior schreef op maandag 1 december 2025 @ 10:32:
Ik krijg er nu deze dingen uit als pipeline voor Woodpecker bijv.

Het is geen Ansible ( ), maar doet wel alles om zaken op te zetten, te initialiseren en te deployen.

[...]

Leuk dat het voor je werkt en dat je stappen aan het zetten bent . Dit bedoel ik niet vervelend, maar een dergelijke opzet is een enorme rode vlag . Er is een reden dat ik o.a. voor GitLab Runners, Gitea Actions of Forgejo Actions ga hè... Want het mounten van server paden voor deployment is wat mij betreft een hele dikke, grote, vette NO-NO.

Het mounten en rsyncen lijkt in eerste instantie een enorm goed idee totdat het een keer misgaat . Je maakt daarnaast de deployment host afhankelijk van de target host. En het is een aardig beveiligingsrisico vanwege potentieel misbruik van schrijfrechten. Je wilt eigenlijk dat wanneer iemand toegang krijgt tot de deployment node nergens bij kan. Uit ervaring kan ik je vertellen dat ik collega's had die per ongeluk de hele root disk overschreven met zulke geintjes . Want wat als de string replacement niet werkt omdat je die vergeten bent? Dan staat er per ongeluk:

rsync -a --delete . "/deployroot///"

Oeps . Of wat als je deze lompe kerel dit doet:

# CI_REPO_OWNER=".."
# CI_REPO_NAME=".."
rsync -a --delete . "/deployroot/../../"

En nu niet zeggen dat dat niet kan, want met wat creativiteit kan er meer dan je denkt .

Ansible is wat mij betreft de gouden standaard voor dit soort deployments. Met name omdat je ook veiligheid in kan bouwen en omdat communicatie via SSH of WinRM gaat. Ik ken Woodpecker verder niet, maar ik begrijp eerlijk gezegd niet waarom je niet een native CI/CD platform neemt. Dat integreert volgens mij veel makkelijker en maak je het jezelf nu alleen maar lastig...

Ook kun je met GitLab Runners, Forgejo Actions of GitHub Actions de ingebouwde secrets gebruiken voor dit soort deployments waarmee authenticatie naar bijv. target machines per repo beperkt kan worden. Mijn infra repo heeft bijvoorbeeld de Ansible Vault sleutel:"



Maar die kan ik voor de rest niet inzien. Aan mijn account zitten daarnaast de deploy keys gekoppeld:



Dit is de private key van de deploy voor mijn machines.

Bedenk ook dat Forgejo Actions, Gitea Actions afgeleid zijn van GitHub Actions. De meeste actions die te vinden zijn op de GitHub marketplace zijn uitwisselbaar en te gebruiken in Forgejo. Misschien maakt dit je leven ook een stuk makkelijker . Daarnaast zijn er ook legio voorbeelden. Ook maak ik gebruik van de Forgejo Container Registry voor mijn Docker Images. Die koppeling is dan hetzelfde als bij GitHub en de GitHub Container Registry.

In de repo van @alex3305 zag ik nog wat behoorlijke complexe actions om allerhande versies aan te maken zodat je alle stacks samenneemt voor zover ik begrijp in een release, maar dat komt later wel.

Yes, maar je moet niet gaan rennen voordat je gaat lopen hè. Mijn eerste Docker build workflow is al een heel stuk eenvoudiger.

Ik heb zelfs nog een hele tijd Docker container(s) gebruikt, net zoals met Woodpecker. Maar daar ben ik vanaf gestapt omdat ik nu een hosted tool cache gebruik. Daarmee heb ik geen extra ruimte nodig voor (custom) Docker images. Daarbij gebruik ik dan een cache stap zodat Forgejo Actions de cache kan gebruiken bij packages met dezelfde versie(s). Bij mijn infra repo gebruik ik daarvoor de hash van Python's requirements.txt en de hash van Ansible Galaxy requirements.yml:

.forgejo/actions/setup-ansible/action.yml

YAML:

runs:
  using: "composite"
  steps:
    - name: 🏗️ Setup Python
      id: setup-python
      uses: actions/setup-python@83679a892e2d95755f2dac6acb0bfd1e9ac5d548 # v6
      with:
        cache: 'pip'
        cache-dependency-path: 'requirements.txt'

    - name: 👷 Install Python dependencies
      if: steps.setup-python.outputs.cache-hit != 'true'
      shell: bash
      run: pip install -r requirements.txt

    - name: 📦 Setup Ansible Galaxy Cache
      id: ansible-galaxy-cache
      uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4
      with:
        path: |
          .ansible
          ~/.ansible
        key: ${{ runner.os }}-ansible-${{ hashFiles('**/requirements.yml') }}
        restore-keys: |
          ${{ runner.os }}-ansible-

    - name: 🌌 Install Ansible Galaxy dependencies
      if: steps.ansible-galaxy-cache.outputs.cache-hit != 'true'
      shell: bash
      run: ansible-galaxy install -r requirements.yml

Het is in dit geval maar een paar MB aan cache, maar zorgt ervoor dat Ansible in minder dan 10 seconde is geïnstalleerd en klaar is voor gebruik. Het opstarten van een Ansible container (zonder pull) was gek genoeg een minuutje langzamer. Waarschijnlijk omdat het om Docker in Docker in Docker ging .

[RobertMe]

alex3305 schreef op maandag 1 december 2025 @ 14:15:
Alhoewel Docker het toestaat, vind ik eigenlijk dat ontwikkelaars maar 1 keer 1 (Sem)Versie moeten uitbrengen. Rolling major of major.minor kan ik nog wel inkomen en doe ik zelf ook.

Maar zo makkelijk is het natuurlijk niet. Containers kunnen ook geupdate worden omdat onderliggende (systeem)packages geupdate worden zonder dat de "primaire software" geupdate wordt (wat ls.io dus doet met hun ls<nummertje>). En dan heb je nog suffixes voor heel veel andere zaken, zoals dus -debian of -alpine toevoegsels etc etc (en soms is het niet -debian maar specifiek -bookworm of -trixie of -alpine3.22).

Dus aan de ene kant kun je als registry niet iets van semver afdwingen want dan werken allemaal die suffixes niet meer. En vervolgens kun je ook niet zeggen dat "volledige" versies (major.minor.patch) immutable moeten zijn want semver is niet verplicht. En je kunt dus sowieso ook niet specifieke versies immutable maken want dan kun je geen updates meer doen aan onderliggende software. Als in: stel libssl bevat een lek, dan moeten wel alle images die die lekke versie gebruiken geupdate worden, maar er is geen nieuwe software versie nodig om het lek te fixen (de software hoeft maar de nieuwe .so aan te spreken).

* RobertMe gebruikt nu wel :tag@digest in files. Maar daar kan Renovate niet mee overweg (een hele kleine range bleek dit toevallig wel te doen op het moment dat ik het op zette, en die draai ik nu nog). Maar wat ook zo is is dat Docker de tag volledig negeert als je een digest opgeeft. Wat an zich wellicht logisch is, maar ook weer niet. Maar ik heb er dus wel heel graag een versienummer bij staan zichtbaar, zodat ik weet welke versie het is.
Daarnaast heb ik volgens mij ook wat issues dat bepaalde images niet updaten. Bv sommige containers waar nog een distro naam/versie in de naam staat.

[Mars Warrior]

Ik moet nog even veel lezen zie ik, @alex3305 , maar daar kom ik nog op terug

@RobertMe , bij mij voegt renovate juist digests toe:

YAML:

services:
  gitops-forgejo:
    image: codeberg.org/forgejo/forgejo:13@sha256:88858e7f592f82d4f650713c7bed8c0cd792d7f71475a7467c5650a31cd2eda9
    container_name: gitops-forgejo
    restart: unless-stopped

...
...

  gitops-renovate:
    image: renovate/renovate:42.29.4@sha256:aead5ca948dc1a76ed084ab9716fd83e6a8c8626d38b831d1923cdc17fa4d1b6
    container_name: gitops-renovate
    restart: "no"

Dit is mijn renovate.json bestand:

JSON:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:best-practices",
    ":automergeMinor",
    "schedule:automergeDaily",
    ":dependencyDashboard"
  ],
  "packageRules": [
    {
      "matchCategories": [
        "docker"
      ],
      "managerFilePatterns": [
        "/(^|/)docker-compose\\.ya?ml$/",
        "/Dockerfile$/"
      ]
    }
  ]
}

Nog geen idee hoe Renovate zichzelf start, want de container stopt gewoon na elke run, maar goed. Ik heb nog bergen aan blinde vlekken

Renovate loopt ook vaak zijn eigen renovate.json te migreren zie ik.

Renovate zou dus CalVer en SemVer aan moeten kunnen, maar zou enkel bij SemVer minor/major updates kunnen herkennen en bij CalVer is het gewoon een nieuwe versie ofzo.

[ Voor 9% gewijzigd door Mars Warrior op 02-12-2025 13:15 ]

[RobertMe]

Mars Warrior schreef op dinsdag 2 december 2025 @ 13:13:
@RobertMe , bij mij voegt renovate juist digests toe:

Hmm. Dat deed die bij mij niet. En/maar jij hebt wel "brede" tags, in ieder geval bij Forgeo (als in, "13" en niet "13.x.y"). Denk dat de big daarbij niet optreed, totdat de 13 14 moet worden. Bij het Renovate image gaat het denk ik wel fout? (Kom je snel genoeg achter gezien elke PR/merge een nieuwe release wordt )

Nog geen idee hoe Renovate zichzelf start, want de container stopt gewoon na elke run, maar goed. Ik heb nog bergen aan blinde vlekken

Hij start zichzelf natuurlijk niet Hij stopt, zoals je zelf aanhaalt.
Ik heb hem zelf dan als Podman Quadlet draaien. Dus heb er gewoon een systemd timer naast gezet die elke dag om 16:00 de service (/Quadlet) aftrapt.
Features zoals de GitHub app/hosted variant dan heeft zoals dat die steeds automatisch draait, bv na het aanvinken van "rebase", of een queued PR van op het "dashboard" aanvinken om nu (meteen) een PR aan te maken heb je dan natuurlijk niet.

[Mars Warrior]

RobertMe schreef op dinsdag 2 december 2025 @ 13:19:
[...]
Hmm. Dat deed die bij mij niet. En/maar jij hebt wel "brede" tags, in ieder geval bij Forgeo (als in, "13" en niet "13.x.y"). Denk dat de big daarbij niet optreed, totdat de 13 14 moet worden. Bij het Renovate image gaat het denk ik wel fout? (Kom je snel genoeg achter gezien elke PR/merge een nieuwe release wordt )

Het waren gewone tags, dus :13. Meer niet. Door de config te wijzigen krijg ik nu deze digests erbij

Hij start zichzelf natuurlijk niet Hij stopt, zoals je zelf aanhaalt.
Ik heb hem zelf dan als Podman Quadlet draaien. Dus heb er gewoon een systemd timer naast gezet die elke dag om 16:00 de service (/Quadlet) aftrapt.

Aha. Teveel blinde vlekken nog

Features zoals de GitHub app/hosted variant dan heeft zoals dat die steeds automatisch draait, bv na het aanvinken van "rebase", of een queued PR van op het "dashboard" aanvinken om nu (meteen) een PR aan te maken heb je dan natuurlijk niet.

Huh? Die heb ik wel hoor. Ik heb soms PRs (ook die ik gesloten heb) die ik op het dependency dashboard of in een PR gewoon kan aanvinken. Dat zie je hierboven staan halverwege (If you want to rebase...).


En het Dependency Dashboard als test (recreate PR):



Kan ik nu plotseling dingen die anderen niet kunnen als pure beginner

[RobertMe]

Mars Warrior schreef op dinsdag 2 december 2025 @ 13:43:
[...]

Huh? Die heb ik wel hoor. Ik heb soms PRs (ook die ik gesloten heb) die ik op het dependency dashboard of in een PR gewoon kan aanvinken. Dat zie je hierboven staan halverwege (If you want to rebase...).
[Afbeelding]

En het Dependency Dashboard als test (recreate PR):

[Afbeelding]

Kan ik nu plotseling dingen die anderen niet kunnen als pure beginner

Ik zie die opties ook hoor. Maar als ik ze gebruik gebeurt er pas om 16:00 iets mee, omdat dan Renovate wordt afgetrapt.
Terwijl als ik hetzelfde doe in de repo van het werk waar de Renovate app aan gekoppeld is dan is het resultaat vaak al binnen een minuut te aanschouwen. (Als in: de Renovate app voor GitHub zal allemaal (web) hooks hebben op dit soort events en meteen een nieuwe run starten/in de wachtrij zetten)

[Mars Warrior]

RobertMe schreef op dinsdag 2 december 2025 @ 13:51:
[...]

Ik zie die opties ook hoor. Maar als ik ze gebruik gebeurt er pas om 16:00 iets mee, omdat dan Renovate wordt afgetrapt.
Terwijl als ik hetzelfde doe in de repo van het werk waar de Renovate app aan gekoppeld is dan is het resultaat vaak al binnen een minuut te aanschouwen. (Als in: de Renovate app voor GitHub zal allemaal (web) hooks hebben op dit soort events en meteen een nieuwe run starten/in de wachtrij zetten)

Gelukkig. Voor mij is het allemaal nieuw, dus soms geen idee wat ik doe. Ook git gebruik ik altijd beperkt. Nog nooit een rebase gedaan bijv. omdat ik niet weet wat er dan gebeurt en ik de namen/commando's niet altijd logisch vind

En oja. Ik heb eerder een hoop binnen n8n gebouwd. Daarmee kun je real-time op webhooks reageren en een hele flow aftrappen (binnen n8n), waarin ik lekker scripts kan aftrappen en standaard nodes kan gebruiken die een forgejo pull kunnen doen om zo een update op de server te krijgen via een ssh node die een execute, download of upload kan uitvoeren.

Niks geen Woodpecker of Ansible, gewoon via een workflow manager

Maar goed. Ik lees lekker verder

[ Voor 23% gewijzigd door Mars Warrior op 02-12-2025 14:42 ]

[alex3305]

@Mars Warrior @RobertMe De digests komen tegenwoordig vanuit de config:best-practices .

Ik heb lokaal een eigen Renovate config die ik dus importeer, en daar zat deze niet in. Dus gisteren op mijn infra repo toegevoegd, waar ook Docker Compose in zit, maar helaas

code:

WARN: Error updating branch: update failure (repository=alex/infra, branch=renovate/pin-dependencies)

Maar dat komt dus omdat ik een Regex Matcher gebruik en is een bekend issue . Er is wel een soort van workaround, alleen was ik gisteren zo teleurgesteld dat ik geen zin meer had . Vandaag ook niet meer aan toegekomen.

Leuk dat het werkt @Mars Warrior. Nu even doorpakken en met Forgejo Actions aan de slag . De workflow die ik eerder heb gepost is niet bijster complex en is direct scheduled .

[Mars Warrior]

alex3305 schreef op dinsdag 2 december 2025 @ 20:47:
@Mars Warrior @RobertMe De digests komen tegenwoordig vanuit de config:best-practices .

Wat leren jullie toch een hoop van mij hè 😇

Leuk dat het werkt @Mars Warrior. Nu even doorpakken en met Forgejo Actions aan de slag . De workflow die ik eerder heb gepost is niet bijster complex en is direct scheduled .

Dan moet ik die dind runner container gebruiken toch van jouw?

En dan nog wat moeilijke dingen met Ansible…

YAML:

name: Deploy via Ansible

on:
  push:
    branches: [ main ]
  workflow_dispatch:
    inputs:
      version:
        description: "Tag/branch to deploy (default: main)"
        required: false
        default: "main"

jobs:
  deploy:
    runs-on: self-hosted

    steps:
      # 1. Checkout the stack repo (not used directly, only metadata needed)
      - name: Checkout current repo
        uses: actions/checkout@v3

      # 2. Checkout the Ansible infra repo
      - name: Checkout Ansible infra
        uses: actions/checkout@v3
        with:
          repository: infra/ansible        # <-- jouw infra-repo
          path: ansible

      # 3. Run Ansible inside the container
      - name: Run Ansible deploy
        uses: docker://cytopia/ansible:latest
        with:
          entrypoint: ansible-playbook
        env:
          REPO_OWNER: ${{ github.repository_owner }}
          REPO_NAME:  ${{ github.event.repository.name }}
          VERSION:    ${{ github.event.inputs.version }}
        args: >
          -i ansible/hosts
          ansible/deploy.yml

[RobertMe]

Mars Warrior schreef op dinsdag 2 december 2025 @ 22:28:
[...]

Wat leren jullie toch een hoop van mij hè 😇

Ik wist dat die in een van de presets was inbegrepen

[...]

Dan moet ik die dind runner container gebruiken toch van jouw?

Docker-in-Docker (dind) is bij mijn weten alleen nodig als je Docker wilt gebruiken, maar dat hoeft waarschijnlijk niet? Aangezien je puur deployments wilt doen. dind is dus nodig als je in een workflow (/action) bv een image wilt builden, of een container wilt uitvoeren (bv bij development dat je een linter of static analyzer uitvoert via een container).

[Mars Warrior]

RobertMe schreef op dinsdag 2 december 2025 @ 23:10:
[...]
Ik wist dat die in een van de presets was inbegrepen

Renovate had zelf de renovate.json lopen wijzigen. Zo ben ik erachter gekomen.

[...]

Docker-in-Docker (dind) is bij mijn weten alleen nodig als je Docker wilt gebruiken, maar dat hoeft waarschijnlijk niet? Aangezien je puur deployments wilt doen. dind is dus nodig als je in een workflow (/action) bv een image wilt builden, of een container wilt uitvoeren (bv bij development dat je een linter of static analyzer uitvoert via een container).

Het is die container van @alex3305 die draait ook weer Ansible meen ik.

[StarWing]

Een crosspost van mij vanop een ander forum:

Ik ben al een paar dagen aan het stoeien om een fail2ban in werking te krijgen via een docker container op een Ubuntu server.
Initieel had ik samen met onze Vriend ChatGPT een docker compose gemaakt voor f2b + nextcloud + redis + collabora. Maar dat werkt maar halvelings.
Het probleem ligt bij fail2ban, ik krijg deze niet aan de praat.
Niet via de compose die chatgpt gemaakt heeft, maar ook niet op een losse f2b voor een bestaande emby.

De finale setup zou zijn dat ik een aantal docker containers die extern benaderbaar zijn, voorzie van een f2b jail, zodat failed logins gebanned worden.
Er staat reeds een cloudflare voor die GeoBlock doet, maar dit zou dan een additionele laag zijn.

In eerste instantie had ik een pak foutmeldingen, maar dat kwam blijkbaar door een aanpassing in een van hun laatste commits (zie DEFAULT onder de jail.local).
Mocht iemand zich geroepen voelen om onderstaande eens te bekijken.
Volgens de logs is de jail up & running, maar er wordt nougabollen actie ondernomen door f2b

Achtergrond:
De emby draait tevens in een docker container, en staat achter een reverse proxy: HA op PfSense, en is volledig werkend incl certs.
De HA gaat de traffiek redirecten van https://emby.whatever naar 192.168.10.155:8096

Docker compose fail2ban:

code:

services:
  fail2ban:
    image: lscr.io/linuxserver/fail2ban:latest
    container_name: fail2ban
    cap_add:
      - NET_ADMIN
      - NET_RAW
    network_mode: host
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Brussels
      - VERBOSITY=-vvvv #optional
    volumes:
      - ./config:/config
#     - /var/log:/var/log:ro
      - /docker/emby/library/logs:/remotelogs/emby:ro #optional
      - /docker/jellyseer/config/logs:/remotelogs/jellyseer:ro
#      - /path/to/nextcloud/log:/remotelogs/nextcloud:ro #optional

Docker compose emby:

code:

services:
  emby:
    image: lscr.io/linuxserver/emby:latest
    container_name: emby
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Brussels
    volumes:
      - /docker/emby/library:/config
      - /docker/emby/backup:/backup
      - /DataDisk/Video:/Video
      - /DataDisk/Audio:/Audio
 #     - /opt/vc/lib:/opt/vc/lib #optional
    ports:
      - 192.168.10.155:8096:8096
      - 192.168.10.155:8920:8920 #optional
    devices:
      - /dev/dri:/dev/dri #optional
 #     - /dev/vchiq:/dev/vchiq #optional
 #     - /dev/video10:/dev/video10 #optional
 #     - /dev/video11:/dev/video11 #optional
 #     - /dev/video12:/dev/video12 #optional
    restart: unless-stopped
    networks:
      - docker_lan
networks:
  docker_lan:
    external: true

jail.local:

code:

[DEFAULT]
#banaction = nftables
#banaction_allports = nftables[type=allports]
banaction = iptables-multiport
banaction_allports = iptables-allports

[emby]
enabled = true
port = 8096,443,80
filter = emby
logpath = /remotelogs/emby/embyserver.txt
maxretry = 3
findtime = 600
bantime = 43200
chain   = DOCKER-USER
#chain   = INPUT
action  = %(known/action)s

Ik heb al gespeeld met chain: docker-user of input, tevens met iptables of nft tables. Maar ik weet niet wat het verschil is tussen beiden.


Onderstaande geeft ook gewoon weer dat de jail draait.

code:

docker exec -it fail2ban fail2ban-client status emby
Status for the jail: emby
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /remotelogs/emby/embyserver.txt
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

filter.d/emby.local is de std van f2ban:

code:

## Version 2023/03/11
# Fail2Ban filter for emby

[INCLUDES]
before = common.conf

[Definition]

_daemon = emby-server

failregex = Server: AUTH-ERROR:\ <HOST>\ -

ignoreregex =

Regextest op de container zelf, voor zover ik dit kan interpreteren:
-log file is leesbaar
-regex is correct

code:

root@vdockersrv:/#  fail2ban-regex /remotelogs/emby/embyserver.txt "http/1.1 Response 401 to ‌‍‍<HOST>"

Running tests
=============

Use   failregex line : http/1.1 Response 401 to ‌‍‍<HOST>
Use         log file : /remotelogs/emby/embyserver.txt
Use         encoding : UTF-8


Results
=======

Failregex: 44 total
|-  #) [# of hits] regular expression
|   1) [44] http/1.1 Response 401 to ‌‍‍<HOST>
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [734] {^LN-BEG}ExYear(?P<_sep>[-/.])Month(?P=_sep)Day(?:T|  ?)24hour:Minute:Second(?:[.,]Microseconds)?(?:\s*Zone offset)?
`-

Lines: 1524 lines, 0 ignored, 44 matched, 1480 missed
[processed in 0.18 sec]

Missed line(s): too many to print.  Use --print-all-missed to print all 1480 lines

Maar ik kan een collega gewoon blijven laten inloggen, zonder dat f2ban iets doet, en ik heb geen idee waar ik dit moet gaan zoeken.
Wat nog zou kunnen is dat ik voor mijn emby (en een pak andere containers) een ander netwerk heb, hiervoor heb ik een "docker lan" aangemaakt, terwijl dit in de f2b docker nog niet geconfigureerd staat, maar volgens mij moet de f2b container dit toch gaan blocken op host niveau?

[Mars Warrior]

Gaat lekker, ligt Codeberg eruit terwijl ik wat wilde experimenteren. Website geeft:

De webpagina op https://codeberg.org/ ondervindt mogelijk problemen of is definitief verplaatst naar een nieuw webadres.
ERR_QUIC_PROTOCOL_ERROR

Dus ook een docker compose pull werkt niet

Bash:

docker compose up -d
[+] Running 15/15
 ✘ gitops-forgejo Error     Get "https://codeberg...                      14.5s
 ✔ gitops-renovate Pulled                                                 13.6s
   ✔ 20043066d3d5 Already exists                                           0.0s
   ✔ 9e4e033eb30d Pull complete                                            0.3s
   ✔ 018f6c7aaaac Pull complete                                            1.2s
   ✔ 35578b6f2e42 Pull complete                                            1.5s
   ✔ 80dfdc05cfe7 Pull complete                                            2.0s
   ✔ 1eca13f89a5d Pull complete                                            6.1s
   ✔ 8d74e0a459d6 Pull complete                                            6.7s
   ✔ 10316a1eb140 Pull complete                                            6.7s
   ✔ 34b95407a4fa Pull complete                                            6.7s
   ✔ 4e5a0ac21bc5 Pull complete                                           12.3s
   ✔ 064a0d449bd7 Pull complete                                           12.3s
   ✔ 7343cd103162 Pull complete                                           12.4s
   ✔ 4f4fb700ef54 Pull complete                                           12.4s
Error response from daemon: Get "https://codeberg.org/v2/": net/http: TLS handshake timeout

[ Voor 70% gewijzigd door Mars Warrior op 03-12-2025 10:00 ]

[RobertMe]

Mars Warrior schreef op woensdag 3 december 2025 @ 09:58:
Gaat lekker, ligt Codeberg eruit terwijl ik wat wilde experimenteren.

Ook gewoon Uptime Kuma gebruiken https://status.codeberg.org/status/codeberg

[Mars Warrior]

Codeberg is er weer. Dus alles is up-and-running, maar werken ho-maar!

Ik heb een runner...



Actions zijn enabled...


En ik heb workflows...


Maar toch weer niet blijkbaar...


Crazy like a fool

Update 1:
Haha. Als ik de map geen .forgejo noem maar .github dan heb ik plotseling Actions en worden ze nog uitgevoerd ook

Update 2:
Oepsie. Er stond een spatie voor de ".". Dus er stond " .forgejo/" ipv ".forgejo/". Man, man, man

[ Voor 9% gewijzigd door Mars Warrior op 03-12-2025 14:35 ]

[synoniem]

StarWing schreef op woensdag 3 december 2025 @ 06:22:
Een crosspost van mij vanop een ander forum:

Ik ben al een paar dagen aan het stoeien om een fail2ban in werking te krijgen via een docker container op een Ubuntu server.
Initieel had ik samen met onze Vriend ChatGPT een docker compose gemaakt voor f2b + nextcloud + redis + collabora. Maar dat werkt maar halvelings.
Het probleem ligt bij fail2ban, ik krijg deze niet aan de praat.
Niet via de compose die chatgpt gemaakt heeft, maar ook niet op een losse f2b voor een bestaande emby.

De finale setup zou zijn dat ik een aantal docker containers die extern benaderbaar zijn, voorzie van een f2b jail, zodat failed logins gebanned worden.
Er staat reeds een cloudflare voor die GeoBlock doet, maar dit zou dan een additionele laag zijn.

In eerste instantie had ik een pak foutmeldingen, maar dat kwam blijkbaar door een aanpassing in een van hun laatste commits (zie DEFAULT onder de jail.local).
Mocht iemand zich geroepen voelen om onderstaande eens te bekijken.
Volgens de logs is de jail up & running, maar er wordt nougabollen actie ondernomen door f2b

Achtergrond:
De emby draait tevens in een docker container, en staat achter een reverse proxy: HA op PfSense, en is volledig werkend incl certs.
De HA gaat de traffiek redirecten van https://emby.whatever naar 192.168.10.155:8096

Docker compose fail2ban:

code:

services:
  fail2ban:
    image: lscr.io/linuxserver/fail2ban:latest
    container_name: fail2ban
    cap_add:
      - NET_ADMIN
      - NET_RAW
    network_mode: host
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Brussels
      - VERBOSITY=-vvvv #optional
    volumes:
      - ./config:/config
#     - /var/log:/var/log:ro
      - /docker/emby/library/logs:/remotelogs/emby:ro #optional
      - /docker/jellyseer/config/logs:/remotelogs/jellyseer:ro
#      - /path/to/nextcloud/log:/remotelogs/nextcloud:ro #optional

Docker compose emby:

code:

services:
  emby:
    image: lscr.io/linuxserver/emby:latest
    container_name: emby
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Brussels
    volumes:
      - /docker/emby/library:/config
      - /docker/emby/backup:/backup
      - /DataDisk/Video:/Video
      - /DataDisk/Audio:/Audio
 #     - /opt/vc/lib:/opt/vc/lib #optional
    ports:
      - 192.168.10.155:8096:8096
      - 192.168.10.155:8920:8920 #optional
    devices:
      - /dev/dri:/dev/dri #optional
 #     - /dev/vchiq:/dev/vchiq #optional
 #     - /dev/video10:/dev/video10 #optional
 #     - /dev/video11:/dev/video11 #optional
 #     - /dev/video12:/dev/video12 #optional
    restart: unless-stopped
    networks:
      - docker_lan
networks:
  docker_lan:
    external: true

jail.local:

code:

[DEFAULT]
#banaction = nftables
#banaction_allports = nftables[type=allports]
banaction = iptables-multiport
banaction_allports = iptables-allports

[emby]
enabled = true
port = 8096,443,80
filter = emby
logpath = /remotelogs/emby/embyserver.txt
maxretry = 3
findtime = 600
bantime = 43200
chain   = DOCKER-USER
#chain   = INPUT
action  = %(known/action)s

Ik heb al gespeeld met chain: docker-user of input, tevens met iptables of nft tables. Maar ik weet niet wat het verschil is tussen beiden.


Onderstaande geeft ook gewoon weer dat de jail draait.

code:

docker exec -it fail2ban fail2ban-client status emby
Status for the jail: emby
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /remotelogs/emby/embyserver.txt
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

filter.d/emby.local is de std van f2ban:

code:

## Version 2023/03/11
# Fail2Ban filter for emby

[INCLUDES]
before = common.conf

[Definition]

_daemon = emby-server

failregex = Server: AUTH-ERROR:\ <HOST>\ -

ignoreregex =

Regextest op de container zelf, voor zover ik dit kan interpreteren:
-log file is leesbaar
-regex is correct

code:

root@vdockersrv:/#  fail2ban-regex /remotelogs/emby/embyserver.txt "http/1.1 Response 401 to ‌‍‍<HOST>"

Running tests
=============

Use   failregex line : http/1.1 Response 401 to ‌‍‍<HOST>
Use         log file : /remotelogs/emby/embyserver.txt
Use         encoding : UTF-8


Results
=======

Failregex: 44 total
|-  #) [# of hits] regular expression
|   1) [44] http/1.1 Response 401 to ‌‍‍<HOST>
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [734] {^LN-BEG}ExYear(?P<_sep>[-/.])Month(?P=_sep)Day(?:T|  ?)24hour:Minute:Second(?:[.,]Microseconds)?(?:\s*Zone offset)?
`-

Lines: 1524 lines, 0 ignored, 44 matched, 1480 missed
[processed in 0.18 sec]

Missed line(s): too many to print.  Use --print-all-missed to print all 1480 lines

Maar ik kan een collega gewoon blijven laten inloggen, zonder dat f2ban iets doet, en ik heb geen idee waar ik dit moet gaan zoeken.
Wat nog zou kunnen is dat ik voor mijn emby (en een pak andere containers) een ander netwerk heb, hiervoor heb ik een "docker lan" aangemaakt, terwijl dit in de f2b docker nog niet geconfigureerd staat, maar volgens mij moet de f2b container dit toch gaan blocken op host niveau?

De fail2ban container heeft als network=host en ik vermoed dat dan chain=DOCKER-USER niet werkt. Je zou chain=FORWARD kunnen proberen.

[Mars Warrior]

synoniem schreef op woensdag 3 december 2025 @ 11:09:
[...]

De fail2ban container heeft als network=host en ik vermoed dat dan chain=DOCKER-USER niet werkt. Je zou chain=FORWARD kunnen proberen.

Denk niet dat het daarmee te maken heeft.

Het punt dat deze logging niks ziet:

code:

docker exec -it fail2ban fail2ban-client status emby
Status for the jail: emby
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /remotelogs/emby/embyserver.txt
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

Is de basis van het geheel. Fail2ban praat direct tegen ip/nftables, dat staat los van docker.

Maar ik zie ook dat de regex getest is en ogenschijnlijk werkt. Ik zou verwachten dat de logs van fail2ban mogelijk nog een hint bevatten. Rechten op de logfiles? En waarom heet een logfile .txt, en geen .log?

Wat me wel opvalt, is dat je de logfiles als volume gebruikt, ipv de mappen.

YAML:

  infra-fail2ban:
    image: lscr.io/linuxserver/fail2ban:latest
    container_name: infra-fail2ban
    restart: always
    cap_add:
      - NET_ADMIN
      - NET_RAW
    network_mode: host
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Amsterdam
      - VERBOSITY=-vv #optional
    volumes:
      - $DOCKERDIR/infra/fail2ban/config:/config
      - /var/log:/var/log:ro
#      - /path/to/airsonic/log:/remotelogs/airsonic:ro #optional
#      - /path/to/apache2/log:/remotelogs/apache2:ro #optional
#      - /path/to/authelia/log:/remotelogs/authelia:ro #optional
#      - /path/to/emby/log:/remotelogs/emby:ro #optional
#      - /path/to/filebrowser/log:/remotelogs/filebrowser:ro #optional

[ Voor 30% gewijzigd door Mars Warrior op 03-12-2025 11:26 ]

[synoniem]

Mars Warrior schreef op woensdag 3 december 2025 @ 11:23:
[...]

Denk niet dat het daarmee te maken heeft.

Het punt dat deze logging niks ziet:

code:

docker exec -it fail2ban fail2ban-client status emby
Status for the jail: emby
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /remotelogs/emby/embyserver.txt
`- Actions
   |- Currently banned: 0
   |- Total banned:     0
   `- Banned IP list:

Is de basis van het geheel. Fail2ban praat direct tegen ip/nftables, dat staat los van docker.

Fail2ban praat inderdaad direct ip/nftables maar welke, die van de host of docker of container als je network=host gebruikt? En is op de host ip/nftables wel actief

[Mars Warrior]

synoniem schreef op woensdag 3 december 2025 @ 11:51:
[...]

Fail2ban praat inderdaad direct ip/nftables maar welke, die van de host of docker of container als je network=host gebruikt? En is op de host ip/nftables wel actief

Docker praat nog steeds iha iptables, ook als nftables actief is. Dat lost je OS lekker op.

Mijn firewall draait in dezelfde modus als Fail2Ban zie ik:

YAML:

  infra-cs-firewall-bouncer:
    image: ghcr.io/shgew/cs-firewall-bouncer-docker:latest
    container_name: infra-cs-firewall-bouncer
    network_mode: host
    cap_add:
      - NET_ADMIN
      - NET_RAW
    security_opt:
      - no-new-privileges:true

En deze plaatst zijn 'bans' in de volgende chains:

YAML:

iptables_chains:
  - INPUT
  - DOCKER-USER

Maar dan moet je dus wel 'bans' hebben, anders blijven die ipsets gewoon leeg.

Maar dan moet Fail2Ban dus wel iets herkennen in die logfiles. En nogmaals: het verschil is dat ik eerder mappen doorgeef, en geen logfiles zelf.

[alex3305]

Mars Warrior schreef op dinsdag 2 december 2025 @ 22:28:
Dan moet ik die dind runner container gebruiken toch van jouw?

Je moet niets hè. Ik gebruik een dind-runner omdat ik het makkelijk vind dat dat allemaal in 1 container zit. Je zou ook kunnen starten met de de Docker socket op het systeem. Daar ben ik destijds ook mee gestart en is vergelijkbaar met andere containers die gebruik maken van een Docker soicket. Snippet:

YAML:

services:
  forgejo-runner:
    container_name: forgejo-runner
    image: code.forgejo.org/forgejo/runner:latest
    restart: on-failure:20
    command: "forgejo-runner --config /data/config.yaml daemon"
    privileged: true
    networks:
      internal:
    depends_on:
      - forgejo
    environment:
      CONFIG_FILE: /data/config.yaml
      USER_GID: "1000"
      USER_UID: "1000"
    volumes:
      - /opt/forgejo/runner:/data
    user: 1000:1000

En dan nog wat moeilijke dingen met Ansible…
[...]

Dat kan nog iets eenvoudiger

YAML:

name: Deploy with Ansible

# yamllint disable-line rule:truthy
on:
  push:
    branches:
      - main
  pull_request:
    types:
      - opened
      - reopened
      - synchronize
  workflow_dispatch:

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    timeout-minutes: 5

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

      - name: 🏗️ Setup Python
        id: setup-python
        uses: actions/setup-python@83679a892e2d95755f2dac6acb0bfd1e9ac5d548 # v6
        with:
          cache: 'pip'
          cache-dependency-path: 'requirements.txt'

      - name: 👷 Install Python dependencies
        if: steps.setup-python.outputs.cache-hit != 'true'
        shell: bash
        run: pip install -r requirements.txt

      - name: 📦 Setup Ansible Galaxy Cache
        id: ansible-galaxy-cache
        uses: actions/cache@0057852bfaa89a56745cba8c7296529d2fc39830 # v4
        with:
          path: |
            .ansible
            ~/.ansible
          key: ${{ runner.os }}-ansible-${{ hashFiles('**/requirements.yml') }}
          restore-keys: |
            ${{ runner.os }}-ansible-

      - name: 🌌 Install Ansible Galaxy dependencies
        if: steps.ansible-galaxy-cache.outputs.cache-hit != 'true'
        shell: bash
        run: ansible-galaxy install -r requirements.yml

      - name: 🚀 Deploy Forgejo
        # yamllint disable-line rule:line-length
        uses: dawidd6/action-ansible-playbook@v5
        with:
          playbook: playbooks/MY_PLAYBOOK_HERE.yml
          requirements: requirements.yml
          key: ${{ secrets.DEPLOY_KEY }}
          vault_password: ${{ secrets.ANSIBLE_VAULT_KEY }}

Dan heb je (wederom) geen extra container afhankelijkheid.

Ik kan je sterk aanraden om Ansible eerst lokaal werkend te krijgen en vanaf je localhost te deployen naar systemen voordat je het in een CI/CD vorm gaat gieten. De eerste opstap van Ansible is vrij pittig, daarna wordt het een stuk makkelijker, maar de devil is in the details. Daarom zeg ik altijd tegen mensen dat Ansible leren ongeveer 6 maanden kost . Niet omdat je het niet in 1 week kunt leren of ermee uit de voeten kunt, maar omdat er best veel nuances zijn die je wellicht in eerste instantie mist.

Als je er vragen over hebt mag je die ook altijd via DM stellen

[alex3305]

RobertMe schreef op dinsdag 2 december 2025 @ 23:10:
[...]

Docker-in-Docker (dind) is bij mijn weten alleen nodig als je Docker wilt gebruiken, maar dat hoeft waarschijnlijk niet? Aangezien je puur deployments wilt doen. dind is dus nodig als je in een workflow (/action) bv een image wilt builden, of een container wilt uitvoeren (bv bij development dat je een linter of static analyzer uitvoert via een container).

Forgejo Actions runt CI via Docker images. De Docker images hebben eigenlijk alleen een node requirement en that's about it. De basis hiervan is GitHub Actions en nektos/act.

Je kunt elke Docker of Podman socket gebruiken om workflows te triggeren. Bijvoorbeeld de socket van het systeem of een aparte socket in een aparte dind container. Dat eerste paste niet bij mijn energiezuinige setup aangezien ik dan niet zomaar cpuset kon gebruiken. De laatste optie was mogelijk, maar ik vond twee containers nogal wat gedoe. Ook de inter-container communicatie is dan gewoon irritant.

Vanuit Gitea en derde partijen zijn er dind-containers die de act runner combineren met een dind socket. Voor Forgejo bestond dat niet. Vandaar dat ik een eigen image heb gemaakt die act combineert met dind. Daarnaast heb ik nog wat kleine zaken toegevoegd zoals een init systeem en periodieke schoonmaak van images en cache. Dat vond ik zelf handig .

Het werkend krijgen van rootless dind was overigens niet evident. Ook nu is het soms best IMHO wel brak met o.a. Docker vpnkit die niet altijd even efficient is. Ik heb een tijdje terug wat zitten spelen met IPv6 en dat zou het e.e.a. best wel op kunnen lossen. Idem voor een rootless podman aanpak, die out of the box een stuk beter wordt ondersteund. Echter ben ik er nog niet aan toegekomen om dit verder uit te werken dan wat kladjes.

Uiteindelijk ben ik best wel trots dat ik nu een systeem heb dat werkt én open en transparant is. Vooral dat laatste vind ik wel een pluspunt bij een CI systeem. Ik zou niet zomaar images van een derde partij willen vertrouwen in een dergelijk systeem. Vooral niet als ik applicaties uitrol. Ook heb ik ondersteuning voor arm64 zodat je het ook op een Pi zou kunnen gebruiken. Dat doe ik via qemu. Ik vind het echt leuk dat ik dat ook in Forgejo Actions werkend heb gekregen.

[Mars Warrior]

alex3305 schreef op woensdag 3 december 2025 @ 14:53:
[...]
Je moet niets hè. Ik gebruik een dind-runner omdat ik het makkelijk vind dat dat allemaal in 1 container zit. Je zou ook kunnen starten met de de Docker socket op het systeem. Daar ben ik destijds ook mee gestart en is vergelijkbaar met andere containers die gebruik maken van een Docker soicket. Snippet:

Dat weet ik. Ik moet niks en mag alles.
Zoals je aan eerdere screenshots kan zien loopt die container inmiddels en ziet Forgejo hem ook. Dat is al heel wat. Als nu Renovate ook automagisch elke 6 uur draait, dan ben ik al weer een stap verder.

Dan heb je (wederom) geen extra container afhankelijkheid.

Ik kan je sterk aanraden om Ansible eerst lokaal werkend te krijgen en vanaf je localhost te deployen naar systemen voordat je het in een CI/CD vorm gaat gieten. De eerste opstap van Ansible is vrij pittig, daarna wordt het een stuk makkelijker, maar de devil is in the details. Daarom zeg ik altijd tegen mensen dat Ansible leren ongeveer 6 maanden kost . Niet omdat je het niet in 1 week kunt leren of ermee uit de voeten kunt, maar omdat er best veel nuances zijn die je wellicht in eerste instantie mist.

Ik zie bijv. ook hier dat je heel veel kunt met Ansible icm Docker, maar ik zoek nu enkel naar de simpele pull & up. Meer niet eigenlijk. Dus het mag nog te simpel zijn.
Woodpecker liep bijna direct met die rsync. Dus dit is voor mij een tweede stap die het beter maakt.

Dus ik kijk nu ff met de KISS blik

YAML:

# forgejo action
pipeline:
  deploy:
    image: python:3.12
    secrets: [ SSH_KEY ]
    commands:
      - pip install ansible community.docker
      - mkdir -p ~/.ssh
      - echo "$SSH_KEY" > ~/.ssh/id_ed25519
      - chmod 600 ~/.ssh/id_ed25519

      - ansible-playbook -i inventory deploy.yml

YAML:

# Ansible deploy.yml
- hosts: server
  become: yes
  tasks:
    - name: Repo clonen/updaten
      ansible.builtin.git:
        repo: "[e-mail]:docker-stacks/gitops.git"
        dest: /opt/gitops
        version: main

    - name: Docker Compose pull
      community.docker.docker_compose:
        project_src: /opt/gitops/myapp
        pull: yes

    - name: Docker Compose up
      community.docker.docker_compose:
        project_src: /opt/gitops/myapp
        state: present

Hoe ik dan de .env files ook bijwerk is me nog een raadsel, want daar staan natuurlijk geheime dingen in en die gooi je normaliter niet in github/forgejo. Eerder heb ik die wel met GPG in github gezet als backup.

Als je er vragen over hebt mag je die ook altijd via DM stellen

Dat is fijn!

[alex3305]

@Mars Warrior Je bent er bijna !

Dit is enerzijds mening, anderzijds advies, maar je Docker configuratie én Ansible configuratie combineer je dus in 1 repo. Vanuit daar kun je het op twee manieren oppakken (natuurlijk wel meer, maar laten we het alsjeblieft makkelijk houden): Alle Compose bestanden in 1 map en die per host deployen of Compose Role's maken. Dat eerste is vrij naïef, maar doeltreffend. Dat laatste is zeer gewenst.

Wat ik in mijn repo nu dus heb is zoiets (bestandsstructuur):

code:

┌── .forgejo
│   └── workflows/          → Forgejo Actions workflows
├── group_vars              → Inventory group variables
│   └── .../
├── host_vars               → Host specific variables
│   └── .../
├── roles                   → Ansible Roles directory
│   └── .../
├── inventory.yml           → Ansible inventory

Elke Docker Compose applicatie is bij mij een Role. In deze rol heb ik vier vijf of zes directories:

• defaults, voor standaard variabelen (let op, altijd geprefixed met de role_name)
• files, voor statische bestanden
• handlers, voor eenmalige handlers (daar ga ik hier niet verder op in)
• tasks, wat een role moet doen
• templates, de dynamische bestanden (templates)
• vars, de statische role vars

In de templates definieer ik dan per role 1 of 2 bestanden, .env.j2 en compose.yaml.j2 die ik vervolgens met de template module uitrol naar de target host. In mijn geval is dat naar de Dockge Stacks directory. Daarna doe ik een Docker Compose Up. De templates hebben allemaal ongeveer dezelfde layout en secrets komen bij mij altij in de .env bestand. Templates heb ik al eerder hier gepost en de deployment ziet er dan o.a. zo uit:

YAML:

- name: Create Docker Compose Stack directory
  ansible.builtin.file:
    path: "{{ compose_stack_dir }}"
    state: directory
    owner: "{{ compose_stacks_owner }}"
    group: "{{ compose_stacks_group }}"
    mode: "0755"
  register: _compose_directory
  become: true

- name: Template Docker Compose file
  ansible.builtin.template:
    src: "templates/compose.yaml.j2"
    dest: "{{ [_compose_directory.path, 'compose.yaml'] | file_join }}"
    owner: "{{ compose_stacks_owner }}"
    group: "{{ compose_stacks_group }}"
    mode: "0644"
  become: true

# Compose .env  bestand kun je wel gokken :P

- name: Validate Docker Compose stack
  ansible.builtin.command:
    cmd: docker compose config
    chdir: "{{ _compose_directory.path }}"
  register: _docker_compose_config_output
  when: not ansible_check_mode
  failed_when: _docker_compose_config_output.rc != 0
  changed_when: false

- name: Docker Compose up
  community.docker.docker_compose_v2:
    project_src: "{{ _compose_directory.path }}"
    project_name: "{{ compose_stack_name }}"
    state: present
    recreate: "{{ 'always' if compose_recreate else 'auto' }}"
  register: _docker_compose_up_output
  when: not ansible_check_mode

In de group_vars zet ik dan globale variabelen voor een groep. Bijvoorbeeld domeinnamen. In de host_vars komen vervolgens specifieke host variabelen. Bijvoorbeeld memory limit, CPU limit, etc en paden. Immers is dat per host anders.

In de playbook heb ik dan staan welke host, welke rollen moet runnen:

YAML:

- name: Deploy AdGuard Home
  hosts: docker

  roles:
    - role: adguard_home

Bovenstaande rolt dus AdGuard Home op al mijn Docker hosts uit. In de host_vars van mijn secundaire host wordt vervolgens conditioneel AdGuard Home Sync opgezet .

Geheimen heeft Ansible ook iets voor: Ansible Vault. Die maakt versleutelde bestanden en kan deze on-demand ontsleutelen. Op mijn workstation heb ik bijvoorbeeld een Ansible Vault key file staan die automatisch wordt gebruikt. In mijn Forgejo repo staat een secret met daarin dezelfde key die wordt gebruikt bij de workflow.

[StarWing]

Ondertussen al een stap verder, na een aanpassing in de jail.local. Ik post deze vanavond even als ik thuis ben Fail2ban zegt wel dat hij een ip blockt, maar effectief blocken, ho maar....

Ik zou denken dat dit ligt aan een van de volgende zaken:

code:

chain   = DOCKER-USER
#chain   = INPUT

Enerzijds waarbij ik niet weet wat ik moet kiezen, anderzijds dat de beide dockers in een ander netwerk draaien, maar ik zou verwachten dat f2b dit blokkeert op host niveau. Mogelijks nog met het verschil tussen nftables of iptables, maar dit is iets waar ik onvoldoende kennis over heb.

[Mars Warrior]

alex3305 schreef op woensdag 3 december 2025 @ 21:32:
@Mars Warrior Je bent er bijna !

Ik zie nu wel dat de structuur die ik nu nastreef, en ook zou willen behouden, is dat ik per compose stack een repo heb waarin ik alles heb vastgelegd.
Dat komt ook omdat ik het nu nog simpel doe: ik bepaal zelf de compose stack, en deploy die gewoon (met Woodpecker nog, maar Komodo kan datzelfde). Dat is allemaal doodsimpel eigenlijk. Niks geen templates nog in gebruik of wat daar op lijkt.

Ik heb dan ook een agent nodig om alles uit te voeren natuurlijk: aanroep is via HTTP. Het nadeel daarvan is, is dat er al containers moeten draaien. Met Ansible + SSH heb je dat hele probleem natuurlijk niet. Dus die voordelen zijn me wel duidelijk.

• Door eea per stack te doen krijg ik in portainer ook alles per stack te zien. Dat houdt het erg overzichtelijk.
• Ik heb verder ook (nog) geen meerdere servers: alles zit in één ding. Lekker makkelijk.
• Dat je een stack al dan niet naar meerdere hosts kan uitrollen is mooi. Dat is voor nu nog niet nodig, maar het inrichten voor één host, maakt het wel mogelijk dat je later meer hosts kan gebruiken.
• vwb secrets: ik zag die Ansible Vault inderdaad, maar op de één of andere manier voelt dat voor mij niet als superhandig: die bestanden moeten toch ergens staan.

Ik heb daarom ook ff gekeken naar een Bitwarden (Vaultwarden) oplossing om daar de secerts voor de .env bestanden in te pleuren. Dan staat het centraal en afgeschermd, èn kan voor tig compose stacks worden ingezet. Maar geen versiebeheer

Ik neig dus nu naar SOPS om .env variabelen te encrypten (public/private key) die ik in forgejo kan zetten (encrypted .env + public key) en de private key als secret kan invoeren in forgejo. SOPS snapt ook Azure Key Vault. Mogelijk wordt het bedrijf naar nog blij van

De SOPS config file (in forgejo):

YAML:

# .sops.yaml file
creation_rules:
  - path_regex: stack\.env$
    age:
      - "age1q357..."
    encrypted_regex: '^(POSTGRES|S3_|SECRET)'

De .env bestanden blijven dan verder ook gewoon leesbaar:

YAML:

POSTGRES_PASSWORD=ENC[AES256_GCM,...]
S3_SECRET=ENC[AES256_GCM,...]
NO_SECRET=value

De keys kan ik dan ook nog in Bitwarden zetten, zodat dit centraal beheerd kan worden.

---

Ik ben eigenlijk op zoek naar blokjes die ik achter elkaar kan plaatsen: de input en output is elke keer hetzelfde, maar de techniek/oplossing kan anders zijn.
Dat ben ik ook gewend vanuit mijn vakgebied: werken met data en data pipelines. Ook daar kan ik blokken vervangen als het handig is. Zolang de output hetzelfde is, maakt de techniek niet uit.

De CrowdSec firewall werkt ook al op deze manier (soort van Medaillion Architecture met bronze/silver/gold), en als ik de CI/CD pipeline ook zo kan krijgen, dan kan ik zaken plaatsen en stap voor stap uitwerken:

• Bronze = ruwe data (bijv uit git)
• Silver = in stappen bewerkte data (zeg de secrets invullen, templates invullen, etc)
• Gold = finale bestanden die gedeployd worden met Ansible

Een groot deel zal met Forgejo actions & steps kunnen worden ingevuld. En een deel zal dan met Ansible gedaan moeten worden. Ik heb dan gewoon plain compose stacks en geencrypte .env files. Het gedeelte dat "common" is, zou dan uit Ansible moeten komen.

Alleen: als ik dus ook Ansible per stack "configureer". Is dat handig? Ik kan dan wel - zoals ik het nu snap - per server verschillende rollen maken: de ene server heeft een bepaalde stack wel, de andere niet.

Het decrypten met SOPS zal allemaal kunnen, dus technisch zou ik dan met Forgejo Action/Steps en Ansible toch een mooi werkende keten moeten kunnen fabriceren.

[Mars Warrior]

In ander nieuws: Traefik, CrowdSec en de CrowdSec firewall doen het nog steeds erg goed!

Ik heb zelf de nodige bewerkingen die met de CrowdSec Alerts het nodige doen, maar ook de abuseipdb meeneemt in 'bans' die ik in CrowdSec importeer (de cscli imports).

Statjes:

• Totaal zo'n 76 duizend drops van de firewall in de laatste maand
• De imports nemen een groot deel van deze drops voor hun rekening: erg effectief dus
• De extra lijsten die ik van CrowdSec gebruik, de tor en scanner lijsten voegen nauwelijks iets toe.
• Het aandeel per blocklist varieert per dag. De laatste dagen is de import dus erg effectief. Dat betekent veel terugkerende botjes

Door de variatie aan botjes (soms heel veel vanuit AMAZON-02) varieert het aandeel van de blocklists per dag ook sterk. Een ip adres kan zoals je ziet in meerdere blocklists zitten.

Des te hoger het aandeel van de crowdsec blocklist, des te hoger dus het aantal "nieuwe" botjes. Die zitten dan dus niet in de andere lijsten (zoals abuseipdb) die claimen ook recent/up-to-date te zijn.



Het blijkt onmogelijk te zijn om alles te blokkeren. Veel botjes maken gebruik van AMAZON-02: ze draaien ff een uurtje, en verhuizen weer de instance naar een andere regio. maw, je blijft dus nieuwe botjes krijgen en blokkeren (tijdelijk). Een ban die afloopt geeft in het algemeen wel weer een piek (botjes komen direct terug), waarna de bans en drops weer afnemen.

In het algemeen neemt het aantal bans door CrowdSec per dag wel af de laatste weken, maar 0 zal het nooit worden. Het gebruik van de CrowdSec firewall scheelt dus wel bergen events en alerts.

Het zijn dus waardevolle containers in mijn "infra" docker compose stack

[alex3305]

Mars Warrior schreef op donderdag 4 december 2025 @ 11:57:
[...]

Ik zie nu wel dat de structuur die ik nu nastreef, en ook zou willen behouden, is dat ik per compose stack een repo heb waarin ik alles heb vastgelegd.

Dat kan met Ansible Roles ook . Roles kun je namelijk ook in aparte repositories zetten. Dan kun je het zelfs mixen en matchen met gewone bestanden. Installatie doe je dan via Ansible Galaxy, dus...

requirements.yml

YAML:

roles:
  - name: audiobookshelf
    src: https://git.example.com/ansible/audiobookshelf.git
    version: v2.19.4
    scm: git

en dan gewoon

ansible-galaxy install -v -r requirements.yml

Zo deden we dat vroeger op het werk ook. Zal nu niet veel anders zijn. Persoonlijk ben ik daar vanaf gestapt omdat ik anders constant tussen repo's aan het wisselen was. Een mono repo past dat net wat beter in mijn structuur. Anderzijds neig ik toch steeds meer en meer om weer terug te gaan naar aparte repo's voor beheer van Compose roles. Simpelweg omdat ik secrets en group_vars / host_vars eigenlijk helemaal apart wil hebben. En omdat ik nu nog weleens variabelen een beetje slordig gebruik .

Dat komt ook omdat ik het nu nog simpel doe: ik bepaal zelf de compose stack, en deploy die gewoon (met Woodpecker nog, maar Komodo kan datzelfde). Dat is allemaal doodsimpel eigenlijk. Niks geen templates nog in gebruik of wat daar op lijkt.

Ik heb dan ook een agent nodig om alles uit te voeren natuurlijk: aanroep is via HTTP. Het nadeel daarvan is, is dat er al containers moeten draaien. Met Ansible + SSH heb je dat hele probleem natuurlijk niet. Dus die voordelen zijn me wel duidelijk.

Dat je een stack al dan niet naar meerdere hosts kan uitrollen is mooi. Dat is voor nu nog niet nodig, maar het inrichten voor één host, maakt het wel mogelijk dat je later meer hosts kan gebruiken.

Ik heb bijvoorbeeld een Beszel role waarmee uitbreiden dus triviaal is. Immers is het niets anders dan het toevoegen van een machine aan de inventory. Bij grote(re) setups kun je zelfs met nummers of ranges gaan werken. Dat wordt ook standaard ondersteund in Ansible .

vwb secrets: ik zag die Ansible Vault inderdaad, maar op de één of andere manier voelt dat voor mij niet als superhandig: die bestanden moeten toch ergens staan.

Ik heb daarom ook ff gekeken naar een Bitwarden (Vaultwarden) oplossing om daar de secerts voor de .env bestanden in te pleuren. Dan staat het centraal en afgeschermd, èn kan voor tig compose stacks worden ingezet. Maar geen versiebeheer

Ik neig dus nu naar SOPS om .env variabelen te encrypten (public/private key) die ik in forgejo kan zetten (encrypted .env + public key) en de private key als secret kan invoeren in forgejo. SOPS snapt ook Azure Key Vault. Mogelijk wordt het bedrijf naar nog blij van

Ansible Vault werkt dikke prima hoor. Je maakt een key aan en die zet je in een file, variabele of gebruik je simpelweg op de command line. Ik heb zelf de voorkeur voor een vault file. Dat secret kan eventueel ook vanuit Bitwarden komen. De vault file heb ik vervolgens geconfigureerd in mijn ansible.cfg in de repo.

Vervolgens is het niets meer dan:

ansible-vault encrypt host_vars/my_host/vault.yml
# en
ansible-vault decrypt host_vars/my_host/vault.yml

Ansible decrypt met deze setup ook automatisch de vaults bij het uitrollen. Ik heb dan ook de gewoonte om versleutelde variabelen te prefixen met vault_ en te gebruiken met een clear text variabelen. Dus:

YAML:

immich_database_password: "{{ vault_immich_database_password }}"

Anderzijds is het ook mogelijk om random secrets of keys te laten genereren met de seed van bijv. de inventory_hostname. Dan krijg je ook unieke secrets voor niet zo kritische onderdelen.

Vaultwarden met Ansible wordt niet ondersteund. Bitwarden Enterprise met Secrets Manager wel. Er is wel een soort van workaround met de bitwarden-cli, maar dat voelt gaar. Ik heb dat ooit ook gebouwd voor Home Assistant, maar was ik niet zo over te spreken .

*kuch* Ansible - azure.azcollection.azure_rm_keyvault module – Manage Key Vault instance

[StarWing]

Ondertussen terug een stap verder, maar nog geen block te merken

code:

2025-12-05 06:44:47,938 fail2ban.actions        [154]: NOTICE  [emby] Unban 188.188.135.111
2025-12-05 06:45:07,030 fail2ban.filter         [154]: INFO    [emby] Found 188.188.135.111 - 2025-12-05 06:45:06
2025-12-05 06:45:09,032 fail2ban.filter         [154]: INFO    [emby] Found 188.188.135.111 - 2025-12-05 06:45:08
2025-12-05 06:45:11,034 fail2ban.filter         [154]: INFO    [emby] Found 188.188.135.111 - 2025-12-05 06:45:10
2025-12-05 06:45:11,246 fail2ban.actions        [154]: NOTICE  [emby] Ban 188.188.135.111
2025-12-05 06:45:13,237 fail2ban.filter         [154]: INFO    [emby] Found 188.188.135.111 - 2025-12-05 06:45:13

iptabled -L op de host geeft effectief iets weer:

code:

Chain DOCKER-INTERNAL (1 references)
target     prot opt source               destination

Chain DOCKER-USER (1 references)
target     prot opt source               destination
f2b-emby   tcp  --  anywhere             anywhere             multiport dports 8096,http,https

Chain f2b-emby (1 references)
target     prot opt source               destination
REJECT     all  --  188.188.135.111      anywhere             reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere

Maar dit resulteert niet in een effectieve ban

[Mars Warrior]

Nou, nou, nou, nou: ik heb de mega stack "WhoAmI" weten te deployen met Forgejo Actions + Ansible



Ik heb wel alles zo veel mogelijk versimpelt: vanuit iets werkends is het altijd makkelijker om iets uit te bouwen, dan dat je elke keer ergens tegenaan loopt. Dat was nu al namelijk

Dit is de docker-compose.yaml file:

YAML:

services:
  whoami:
    image: traefik/whoami:v1.10.4
    command:
       # It tells whoami to start listening on 2001 instead of 80
       - --port=2001
       - --name=iamfoo

De forgejo action, waarbij ik nog niet heb gekeken naar tool caching enzo. Ff lekker simpel gedaan

YAML:

name: Deploy

on:
  workflow_dispatch:

jobs:
  deploy:
    runs-on: docker
    steps:
      - uses: actions/checkout@v4

      - name: Inject SSH key
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.DEPLOY_KEY }}" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519

      - name: Install modern Ansible + collections
        run: |
          apt-get update
          apt-get install -y python3 python3-pip
          pip install --upgrade pip
          pip install "ansible>=8.0.0"
          ansible-galaxy collection install community.docker
          pip install docker
          ansible --version

      - name: Run Ansible
        run: ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook -i inventory.ini deploy.yaml

En ik heb alles in één Ansible deploy file gezet. Nog geen vars en andere dingen:

YAML:

- hosts: domiducus
  #become: true
  vars:
    compose_stack_name: "whoami"
    compose_stack_dir: "/home/stacks/whoami"
    compose_stacks_owner: "home"
    compose_stacks_group: "home"
    compose_recreate: true

  tasks:
    - name: Create directory
      file:
        path: "{{ compose_stack_dir }}"
        state: directory
        owner: "{{ compose_stacks_owner }}"
        group: "{{ compose_stacks_group }}"
        mode: "0755"

    - name: Copy compose file
      ansible.builtin.copy:
        src: docker-compose.yaml       # uit je Git repo
        dest: "{{ compose_stack_dir }}/docker-compose.yml"
        owner: "{{ compose_stacks_owner }}"
        group: "{{ compose_stacks_group }}"
        mode: "0644"

    - name: Copy .env
      ansible.builtin.copy:
        src: .env
        dest: "{{ compose_stack_dir }}/.env"
        mode: "0600"

    - name: Validate compose
      command: docker compose config
      args:
        chdir: "{{ compose_stack_dir }}"
      changed_when: false

    # Tijdelijk ff via shell commando, en niet via docker python module die blijkbaar op de host moet draaien hiervoor
#    - name: Compose up
#      community.docker.docker_compose:
#        project_src: "{{ compose_stack_dir }}"
#        project_name: "{{ compose_stack_name }}"
#        state: present
#        recreate: always
    - name: Compose up
      ansible.builtin.command:
        cmd: docker compose up -d
        chdir: "{{ compose_stack_dir }}"

Ik heb nu dus een werkende keten

Dat is al heel wat

Nu kan ik wat dingen gaan uitbouwen. Heb al wel een .env file, maar nog geen "secrets" in die .env file. Ik wil nog steeds SOPS gebruiken, Die kan ook met SSH keys werken, dus dan zou ik maar één key nodig hebben voor al dit gedoe, en kan ik ook vscode + sops plugin gebruiken om de .env bestanden te editen/wijzigen zonder dat ik handmatig hoef te en/decrypten

Gewoon een checkout van git, en gaan met die banaan.

---

De renovate-bot container heb ik ook met een Action weten te schedulen, en zou ook op een push event kunnen werken, dus ook die doet zijn werk op het moment dat ik een docker compose file toevoeg! Ik had expres een oude versie (v1.10.4) van WhoAmI gebruikt., terwijl 1.11.0 de laatste is...

Ik draai nog wel een aparte Renovate container: die herstart ik. Dus nog niet een container die binnen de runner gestart wordt. Stapje voor stapje



Een week geleden nog nooit gehoord van/gewerkt met Forgejo, Renovate en Ansible, en kiek nou!.

Toppie @alex3305

[alex3305]

Lekker bezig @Mars Warrior. Kleine stappen, maar wat mij betreft een groot resultaat. Ik vind dat je best even stil mag staan bij de technologie die je in deze korte periode bekeken, geëvalueerd, beoordeeld en ingezet hebt. Dat vind ik - bovenop Docker - echt prachtig .

Je hebt voor zover ik weet overigens de docker-python module niet nodig. Ik heb een Unraid systeem waar ik niets echt op kan installeren en daar heb ik dat ook niet. Wel installeer ik - via een eigen role - Docker Compose:

roles/docker_compose/tasks/main.yml

YAML:

- name: Assert required variables are set
  ansible.builtin.assert:
    that:
      - docker_compose_version is defined

- name: Uninstall Docker Compose from package manager
  ansible.builtin.package:
    name: "{{ docker_compose_package }}"
    state: absent
  when: >-
    docker_compose_package is defined and
    ansible_facts['pkg_mgr'] is defined and
    ansible_facts['pkg_mgr'] != 'unknown'
  become: true
  failed_when: false

- name: Create Docker plugins directory
  ansible.builtin.file:
    path: "/usr/local/lib/docker/cli-plugins/"
    state: directory
    owner: "{{ ansible_facts['user_id'] }}"
    group: "docker"
    mode: "0755"
  register: docker_plugins_dir
  become: true

- name: Install Docker Compose
  ansible.builtin.get_url:
    url: "{{ docker_compose_release_url }}"
    dest: "{{ [docker_plugins_dir.path, 'docker-compose'] | path_join }}"
    owner: "{{ ansible_facts['user_id'] }}"
    group: "docker"
    mode: "0755"
    checksum: "sha256:{{ docker_compose_release_url }}.sha256"
  notify: "Check Docker Compose Version"

roles/docker_compose/vars/main.yml

YAML:

# This should be fairly complete but probably isn't...
docker_compose_arch: >-
  {% if ansible_facts['architecture'] in ['x86-64', 'x86_64'] %}
    x86_64
  {% elif ansible_facts['architecture'] in ['armv6'] %}
    armv6
  {% elif ansible_facts['architecture'] in ['armv7'] %}
    armv7
  {% elif ansible_facts['architecture'] in ['armv8', 'armhf', 'aarch'] %}
    aarch64
  {% else %}
    {{ ansible_facts['architecture'] }}
  {% endif %}

docker_compose_package: >-
  {% if (ansible_facts['pkg_mgr'] | lower) in ['apt', 'rpm'] %}
    docker-compose-plugin
  {% elif (ansible_facts['pkg_mgr'] | lower) in ['pacman', 'dnf'] %}
    docker-compose
  {% elif (ansible_facts['pkg_mgr'] | lower) in ['apk'] %}
    docker-cli-compose
  {% endif %}

# yamllint disable-line rule:line-length
docker_compose_release_url: "https://github.com/docker/compose/releases/download/{{ docker_compose_version | trim }}/docker-compose-linux-{{ docker_compose_arch | trim }}"

roles/docker_compose/handlers/main.yml

YAML:

- name: Check Docker Compose Version
  ansible.builtin.command: docker compose version
  changed_when: false
  register: docker_compose_version
  failed_when: docker_compose_version.rc != 0

Voor de volgende stappen zou ik je verder sterk aanraden om Ansible te cachen. De Forgejo cache is met 1 node extreem simpel in te richten. Daarnaast heb je zeer waarschijnlijk ook alleen maar Ansible Core nodig. Volledige Ansible gebruik je o.a. voor integratie met externe systemen zoals Cisco. Dat scheelt al enorm met downloaden en installeren .

Je kunt Renovate natuurlijk ook met een Cron laten draaien hè. Dat heb ik eerder ook al een keer gepost.

[Mars Warrior]

alex3305 schreef op vrijdag 5 december 2025 @ 16:21:
Lekker bezig @Mars Warrior. Kleine stappen, maar wat mij betreft een groot resultaat. Ik vind dat je best even stil mag staan bij de technologie die je in deze korte periode bekeken, geëvalueerd, beoordeeld en ingezet hebt. Dat vind ik - bovenop Docker - echt prachtig .

Yep. Ben er ook blij mee. Het is nog wel relatief een eenvoudige opzet, maar het werkt, en uitbreiden kan altijd nog.

Voor de volgende stappen zou ik je verder sterk aanraden om Ansible te cachen. De Forgejo cache is met 1 node extreem simpel in te richten. Daarnaast heb je zeer waarschijnlijk ook alleen maar Ansible Core nodig. Volledige Ansible gebruik je o.a. voor integratie met externe systemen zoals Cisco. Dat scheelt al enorm met downloaden en installeren .

Daar ga ik naar kijken ja. Het grootste deel van de tijd is nu het installeren van Ansible

Je kunt Renovate natuurlijk ook met een Cron laten draaien hè. Dat heb ik eerder ook al een keer gepost.

Had ik gezien ja. Jij runt hem als Docker container in de Runner. Ik nog als aparte container in mijn GitOps stack.

---

Maar ik zat nog ff verder te denken. Behalve de docker stack moet je natuurlijk ook de omgeving van de docker services opzetten en configuratiebestanden enzo ook in forgejo zetten, en dus ook uitrollen met Ansible. Het zijn wat mapjes en wat bestanden. Meer niet.

Nu doe ik alles nog handmatig: Dus mappen aanmaken, en bestanden aanmaken die nodig zijn. Ik backup wel, waarbij ik de .env bestanden door GPG haal en zo in Github gooi als backup. Maar echt handig is dit niet natuurlijk.

Als ik de config bestanden die nodig zijn ook in de stack map in forgejo zou zetten, dan kan ik die eerst aanmaken en klaarzetten, en daarna de compose mappen en bestanden aanmaken en de compose stack starten. Enkel de stack zonder mappen gaat nooit werken.

Verder dan ook de vraag of je een volledige compose file voor die stack gebruikt (zoal ik nu doe), of aparte files die je dan bij de deplo samenneemt. Datzelfde kun je dan doen voor de .env files. Dan kun je ze zelfs nog apart deployen.

Keuzes, keuzes, en mogelijkheden

code:

/home/compose/<stack>/<service>/        ← compose + env + scripts

/home/data/<stack>/<service>/git/       ← config UIT GIT
/home/data/<stack>/<service>/runtime/   ← alles wat de service zelf maakt

[ Voor 4% gewijzigd door Mars Warrior op 05-12-2025 22:04 ]

[alex3305]

@Mars Warrior Dit is uiteraard ook weer een kwestie van smaak en het een hoeft niet beter te zijn dan het ander . Ik ben ook van mijn Unraid machine uitgegaan. Unraid is misschien niet de meest logische keuze voor iemand met een stack zoals de mijne, maar daar staat tegenover dat ik alles vanuit een UI kan bedienen. Ik heb een zicht van ~20% en een terminal op mijn telefoon met een voor mij leesbaar lettertype is dus een redelijke no-go. Elke keer mijn workstation moeten starten om een kleine aanpassing te maken of een container een schop te geven is ook niet zo handig. Vandaar.

Unraid draait volledig in geheugen. Disks worden alleen maar gebruikt voor (user) data. Ik heb daarom in Unraid een partitie op een van de SSD's aangemaakt o.a. voor Docker. Die heeft als mount point /mnt/applications/appdata gekregen. Applications is de naam van de disk en appdata de naam van de partitie. Op mijn Debian host heb ik /opt/appdata. Beide directories neem ik mee in mijn backup.

Bij een uitrol voer ik (kort door de bocht) een aantal stappen uit:

1. Controleren van ingevoerde variabelen
2. Aanmaken van mappen voor de uit te rollen applicatie
3. Templaten van configuratiebestanden (optioneel)
4. Aanmaken van Docker Compose directory
5. Templaten van Docker Compose
6. Docker Compose Up

Voor Stap 1 gebruik ik de assert module, maar ik kan bijvoorbeeld ook controleren of het ingevoerde Compose netwerk reeds bestaat:

YAML:

- name: Assert required variables
  ansible.builtin.assert:
    that:
      - ghost_domain is defined
      - ghost_domain is string

- name: Assert Docker ingress network
  community.docker.docker_network_info:
    name: "{{ ghost_ingress_network }}"
  register: _docker_ingress_network_output
  failed_when: not _docker_ingress_network_output.exists

Voor Stap 2 maak ik in de vars/main.yml variabelen aan die gebaseerd zijn op een application directory. In dit geval geef ik de role een ghost_dir variabele mee en baseer ik de overige variabelen daar bovenop. Daarna maak ik daarmee de benodigde mappen aan.

YAML:

- name: Create Ghost directories
  ansible.builtin.file:
    path: "{{ item }}"
    state: directory
    owner: "{{ ghost_user }}"
    group: "{{ ghost_group }}"
    mode: "0755"
  become: true
  loop:
    - "{{ ghost_dir }}"
    - "{{ ghost_uploads_dir }}"
    - "{{ ghost_database_dir }}"

Intern gebruik ik dan nog een leuk trucje. In de host variabele heb ik standaard een variabele genaamd appdata en dat is dus het eerder door mij genoemde pad. In de defaults van de roles combineer ik die dan met de naam van de role

YAML:

ghost_dir: "{{ [appdata, role_name] | path_join }}"

Dus alleen bij een afwijkend pad hoef ik deze variabelen daadwerkelijk te zetten / te wijzigen .

Tegelijkertijd is deze stap (wederom) idempotent, en wordt die dus niet uitgevoerd wanneer deze niet nodig is. Je zou eventueel zelfs deze stap recursive kunnen doen zodat je zeker bent dat de rechten altijd staan zoals je wilt.

In Stap 3 template of kopieer ik bestanden die ik nodig heb. Ik heb de voorkeur voor templating omdat ik dan variabelen kan gebruiken. Bij mijn Traefik role is dat bijvoorbeeld erg uitgebreid:


Nou weet ik dat deze bestanden eigenlijk buiten de role horen, maar soms ben ik liever iets pragmatischer en praktischer dan principieel.

Tot slot maak ik op eenzelfde manier de Compose Stack directory aan. Bij mij is dat dan in de dockge/stacks directory zodat ik Compose (wederom) via een UI kan bedienen. En template ik de Compose bestanden. Na een validatie wordt Docker Compose Up gedraaid.

In sommige gevallen doe ik nog een controle of de applicatie draait. Bijvoorbeeld bij de Mosquitto broker. Immers werken anders bepaalde applicaties niet.

Rome is niet in 1 dag gebouwd en deze repo ook niet hè. Maar wellicht dat het o.a. jou nog wat inzicht geeft

[blackd]

@alex3305 @Mars Warrior Erg interessant om jullie setup m.b.t. beheer van docker containers / compose projects te lezen.
Ik heb een vergelijkbare ansible setup draaien als @alex3305, gehost op GitHub (private repo), ik gebruik inmiddels uitsluitend GitHub Actions en heb een Self hosted runner draaien om mijn playbook lokaal uit te rollen.Voorheen gebruikte ik (ook) woodpecker maar daar ben ik vanaf gestapt.

Ik beheer met een Ansible Monorepo mijn router (edgerouter), mijn 2 pi-hole machines (high available), nog een losse rpi, mijn TrueNAS Scale server met daarbinnen een Jailmaker jail (hier draaien alle docker containers) en een 'Instance' (hier draait de Self hosted runner) Ik heb zoveel als mogelijk alle dependencies geversioneerd en draai Renovate om alle dependencies te updaten. Ik maak een nightly release en draai dan het playbook uit over mijn infrastructuur.

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.

Ik zou het gebruik van Bitwarden voor secrets momenteel afraden. Ik heb dit een tijdje gedaan, maar merkte dat de service best wel intermittent werkt, waardoor je playbooks gaan falen bij uitvoer. Dus ik zou Ansible Vault aanraden om je secrets in je eigen repo vast te leggen. Sowieso probeer ik zelf ook de repo zo weinig mogelijk dependencies van de buitenwereld te geven. De Galaxy Collections zijn al geinstalleerd in de execution environment, de Roles heb ik in de repo ingecheckt. Een probleem waar je misschien tegenaan loopt is dat je niet weet welke variabelen je in je vault hebt, zonder hem telkens te decrypten. Een oplossing die ik ergens ben tegengekomen en zelf ook toepas is een tweetrapsraket: een secrets.yml waar je alle variabelen definieert (deze variabelen gebruik je in overige bestanden) en die verwijst naar een vault.yml (deze is encrypted).

secrets.yaml:

YAML:

secrets:
  healthchecks_api_token: "{{ vault_secrets.healtchecks_api_token }}"

vault.yaml

YAML:

vault_secrets:
  healthchecks_api_token: "<jouw token>"

En dan gebruik je deze bijvoorbeeld in group_vars/main.yml:

YAML:

healthchecksio:
  check_uuid: <<blabla>>
  api_token: "{{ secrets.healthchecksio_api_token }}"

Qua roles: ik heb voor elke docker compose stack een eigen role gemaakt. Maar ik merkte dat ik toch een aantal zaken generiek wilde trekken, zoals het plaatsen van de docker compose file, de .env file, het aanmaken van een dataset, het fixen van permissies, etc. Ik heb daartoe een docker_compose_base rol gemaakt met deze operaties in tasks. Die roep ik aan in mijn stack specifieke compose files. Ik draai nu 24 stacks (volgens dockge).

[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