:strip_exif()/i/1385569950.png?f=thumbmini)
:strip_icc():strip_exif()/u/94045/crop66c1b4250e8a2_cropped.jpg?f=community)
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
:strip_icc():strip_exif()/u/427742/crop6711f8ea820aa.jpg?f=community)
:strip_icc():strip_exif()/u/72351/Toon_en_Len%25202015-02-02%252070x69.jpg?f=community)
The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long
GoT voor Behoud der Nederlandschen Taal [GvBdNT
Je zult in de logging van de services moeten kijken of je daar een foutmelding ziet.
Overigens blijken heeeeeeeeeeeeeeeeeeeeeeeeeel veel apps de API versie gewoon hard gecodeerd te hebben (vaak 1.24) ipv via de AutoNegotiate functie te doen.
Traefik is er gelukkig mee bezig...om dit voor eens en altijd te fixen.
Als je overigens op internet zoekt naar dit soort problemen met API versies, dan is dit een rinse-and-repeat
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
In ander nieuws, je weet wel die CrowdSec containers enzo 
Gedistribueerde aanvallen op al mijn domeinen:
Ik zie steed meer patronen: hieronder een massieve aanval op al mijn domeinen vanuit AMAZON 02, maar wel allemaal uit een ander land, en allemaal een "vpatch" actie van CrowdSec AppSec die inline gefixed wordt, en dus geen decision/ban geeft (Remedie is false). Deze kunnen op die manier dus terug blijven komen...
/f/image/fnGWPEERSZsukvKs4mxR6Gzq.png?f=fotoalbum_large)
CIDRAM blocklist geeft 90-95% dekking op eigen banlijst:
Verder nog wat geexperimenteerd met bestaande blocklists. Ik heb nu de CIDRAM lijsten gevonden, en dan blijkt als ik een grepcidr doe met mijn eigen banlijst dat die CIDRAM lijsten 90-95% dekking geven: oftewel alles wat bij mij ongeveer langskomt zijn de "usual suspects".
Als ik dus de CIDRAM lijst(en) zou inladen - circa 60.000 ip adressen/ranges - dan zou ik nog max 5-10% van de alerts/decisions overhouden
Aan de andere kant: CrowdSec met een ban van 24 dagen doet het ook goed (242 bans and counting)
Nog even en de IP adressen zijn op van de botjes
/f/image/eKTXIJnaHWOtDenMEY1SGWYr.png?f=fotoalbum_large)
En verder blij dat ik maar af en toe handmatig bijwerk nu ik de gevolgen zie van Docker v29, een versie waar ik wel naar uitkeek vanwege de native support van NFtables
Gedistribueerde aanvallen op al mijn domeinen:
Ik zie steed meer patronen: hieronder een massieve aanval op al mijn domeinen vanuit AMAZON 02, maar wel allemaal uit een ander land, en allemaal een "vpatch" actie van CrowdSec AppSec die inline gefixed wordt, en dus geen decision/ban geeft (Remedie is false). Deze kunnen op die manier dus terug blijven komen...
:strip_exif()/f/image/fnGWPEERSZsukvKs4mxR6Gzq.png?f=user_large)
CIDRAM blocklist geeft 90-95% dekking op eigen banlijst:
Verder nog wat geexperimenteerd met bestaande blocklists. Ik heb nu de CIDRAM lijsten gevonden, en dan blijkt als ik een grepcidr doe met mijn eigen banlijst dat die CIDRAM lijsten 90-95% dekking geven: oftewel alles wat bij mij ongeveer langskomt zijn de "usual suspects".
Als ik dus de CIDRAM lijst(en) zou inladen - circa 60.000 ip adressen/ranges - dan zou ik nog max 5-10% van de alerts/decisions overhouden
Aan de andere kant: CrowdSec met een ban van 24 dagen doet het ook goed (242 bans and counting)
Nog even en de IP adressen zijn op van de botjes
:strip_exif()/f/image/eKTXIJnaHWOtDenMEY1SGWYr.png?f=user_large)
En verder blij dat ik maar af en toe handmatig bijwerk nu ik de gevolgen zie van Docker v29, een versie waar ik wel naar uitkeek vanwege de native support van NFtables
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Helaas zijn niet alle (opensource) bouwers mensen met een "been there, done that" ervaring. Na een aantal jaren weet je waar je je een keer flink aan gaat branden. En hard coderen is er 1 van, niet testen tegen de "RC's" van je basis (noem docker maar het OS) is een andere..... Maar, t scheelt wel veel tijd die je aan nieuwe features kunt besteden.... Geen betere tester dan je eindgebruiker:
[...]
Als je overigens op internet zoekt naar dit soort problemen met API versies, dan is dit een rinse-and-repeat
The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long
GoT voor Behoud der Nederlandschen Taal [GvBdNT
Gelukkig krijg ik (nog) geen mails van elke melding. Da's misschien een toekomstig traject..... Portainer wilde niet correct werken en dus keek ik mbv Dozzle effe snel in het container log.
Ik kijk niet elke dag in Portainer, mail komt automagisch binnen. Blijkbaar gebruikt de mailing-container dus wel de juiste versie.:
[...]
The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long
GoT voor Behoud der Nederlandschen Taal [GvBdNT
Ik snap je punt, maar Traefik is geen hobby clubje in deze.:
[...]
Helaas zijn niet alle (opensource) bouwers mensen met een "been there, done that" ervaring. Na een aantal jaren weet je waar je je een keer flink aan gaat branden. En hard coderen is er 1 van, niet testen tegen de "RC's" van je basis (noem docker maar het OS) is een andere..... Maar, t scheelt wel veel tijd die je aan nieuwe features kunt besteden.... Geen betere tester dan je eindgebruiker
Verder had ik van Docker verwacht dat ze in v28 toch wel depricated meldingen zouden geven om mensen wakker te maken. Dat hoefrt dan niet de bouwer te zijn, maar een gebruiker kan daarop ook een bug report inschieten. Dan helpen we elkaar tenminste.
Nu lijkt dat niet gedaan te zijn, waardoor alles bij een simpele apt update of docker pull vastloopt.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Eens, en ik beweer zeker niet dat projecten zoals Traefik door een "hobby" clubje gemaakt zijn..... Dezelfde issues doen zich voor in organisaties zoals het UVW (vergeten certificaat te vernieuwen???
) of banken of wat dan ook. Al doende leert men door de neus te stoten.Ja, Docker had wel wat duidelijker mogen zijn in de voorbereiding (en mogelijk is er op github wel iets te vinden) maar goed.... Dat je zoals portainer hard gecodeerd 1.41 gebruikt (introductie docker 20.10) terwijl 1.51 de cuurent is (docker 28.3) vind ik wel iets van, dan heb je het versie beheer op je componenten niet op orde.
:strip_icc():strip_exif()/u/340735/crop6448f8f93e3de.jpg?f=community)
/u/298857/crop6471d9676d431.png?f=community)
Mwah, als je 10 of meer versies van de (een, welke dan ook) API achterloopt zie ik dat niet zomaar als regressie..... Ik ben gewend: Actueel + -1 wordt ondersteund, -2 gaat eruit zodra er een nieuwe beschikbaar is. MAAR niet meer dan 1 nieuwe API main versie per jaar. Doe je dit niet dan kom je nooit van ouwe meuk af. Maar, dit hoort meer in software ontwikkeling thuis
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.
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.
:strip_icc():strip_exif()/u/25009/crop65f1e3109d1b7_cropped.jpg?f=community)
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
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
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
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.....:
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
:strip_icc():strip_exif()/u/46311/crop67969c002c0ce_cropped.jpg?f=community)
Niet.
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
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?:
[...]
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
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 ]
Ja dat zou beter zijn. ware het niet dat ik 25 containers heb draaien.:
[...]
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.:
[...]
De release notes van de images lezen voor je ze implementeert, zoals het eigenlijk hoort
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?
:strip_exif()/u/101588/the_lemmings_masacre_2_by_wormthingy.gif?f=community)
Dus? Ik heb er >60. Dan kun je nog steeds een versioned omgeving draaien.:
[...]
Ja dat zou beter zijn. ware het niet dat ik 25 containers heb draaien.
Ik update mijn containers met Renovate vanuit mijn Forgejo instantie:
:strip_exif()/f/image/HbWbWqhrMuC0B0lcH2DBMKrd.png?f=user_large)
Renovate neemt dan direct de release notes mee:
:strip_exif()/f/image/IXNbQkQee45r6X41UjxzVQLD.png?f=user_large)
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:
:strip_exif()/f/image/ucOyojMXTcNN3zihnYeSURBZ.png?f=user_large)
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
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
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Toppie: je hobby mee naar je werk:
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
@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 .
. 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.
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.
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 .
. 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 .
Het gaat op dit moment om een voorstel / pilot. Dus we zijn er nog niet:
[...]
Toppie: je hobby mee naar je werk
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.
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.:
@Mars Warrior Leuk dat je dit project zo mag gaan doen
[...]
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
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
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
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...
- 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
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
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
@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.
. 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.
Met een IdP zoals Dex kun je zelfs meerdere IdP's ontsluiten..
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...
renovate.yaml
. 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
.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.
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.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
.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...
- een Renovate User / Bot aanmaken;
- een Personal Access Token aanmaken voor de Renovate Bot;
- een Renovate repository aanmaken (bijv. renovate/renovate);
- een config.js bestand aanmaken voor Renvoate;
- een Renovate Forgejo workflow aanmaken;
- renovate bot toevoegen aan de repo's waar renovate gerund moet worden.
JavaScript:
1
2
3
4
5
6
7
8
9
10
11
12
13
| module.exports = { platform: 'gitea', endpoint: 'https://forgejo.example.com/api/v1/', gitAuthor: 'Renovate Bot <renovate@example.com>', username: 'renovate-bot', autodiscover: true, optimizeForDisabled: true, persistRepoData: true, osvVulnerabilityAlerts: true, dependencyDashboardOSVVulnerabilitySummary: 'all' }; |
renovate.yaml
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
| 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 }} |
/u/78932/Jewel3GoT.png?f=community)
Zeker. Zo lees ik dingen ook hoor. Ben soms een spons en vaar daarna mijn eigen pad.:
@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è
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.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
Bye bye Minio dus
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.De enterprise server is net zoveel server als jouw thuisserver kerel
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!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
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[...]
Dan is zoiets als Ansible wel enorm handig
Ik ga ernaar kijken
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
@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.
. 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.
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.:
@DjoeC Helemaal eens. Je bedankt jezelf in de toekomst als je dat direct meeneemt
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.
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
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.
Dat is nu ook het geval met deze (mogelijke) pilot.:
@DjoeC Helemaal eens. Je bedankt jezelf in de toekomst als je dat direct meeneemt
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.
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
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.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Wees voorzichtig met een vals gevoel van veiligheid. Denk: Murphy.:
[...]
er dagen uit hebben gelegen dan van de berg aan rekken die on-prem staan te draaien: die laten 100% uptime zien
[...]
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.
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 🥳
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
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.:
[...]
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 🥳
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
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:
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?
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
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.
Vanzelfsprekend kun je ook per actie (push, tag, manual, etc) dingen per pipeline doen:
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.
Het is geen Ansible (
), maar doet wel alles om zaken op te zetten, te initialiseren en te deployen.YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| 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.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| { "$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:
1
2
3
4
5
6
7
| { "$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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| #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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
| { "$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
:strip_exif()/f/image/uXkmMkSc0tQVyRCiUS841sSl.png?f=user_large)
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.
Leuk dat het voor je werkt en dat je stappen aan het zetten bent:
Ik krijg er nu deze dingen uit als pipeline voor Woodpecker bijv.
Het is geen Ansible (
[...]
. 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:"
:strip_exif()/f/image/3aWHLQDv9VuJXnUeIONLG8Gc.png?f=user_large)
Maar die kan ik voor de rest niet inzien. Aan mijn account zitten daarnaast de deploy keys gekoppeld:
:strip_exif()/f/image/CU7Tbets7Nro2nhbRhpwK1il.png?f=user_large)
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.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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| 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
.
Ik moet nog even veel lezen zie ik, @alex3305 , maar daar kom ik nog op terug
@RobertMe , bij mij voegt renovate juist digests toe:
Dit is mijn renovate.json bestand:
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.
@RobertMe , bij mij voegt renovate juist digests toe:
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
| 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| { "$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 ]
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
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
)Hij start zichzelf natuurlijk nietNog geen idee hoe Renovate zichzelf start, want de container stopt gewoon na elke run, maar goed. Ik heb nog bergen aan blinde vlekken
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.
Het waren gewone tags, dus :13. Meer niet. Door de config te wijzigen krijg ik nu deze digests erbij:
[...]
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
Aha. Teveel blinde vlekken nogHij start zichzelf natuurlijk niet
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.
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...).
:strip_exif()/f/image/Q5RckVMiXhFMnrhGOCwXxT56.png?f=user_large)
En het Dependency Dashboard als test (recreate PR):
:strip_exif()/f/image/vimsjVMzicvJRIZdv8HZXTlJ.png?f=user_large)
Kan ik nu plotseling dingen die anderen niet kunnen als pure beginner
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Ik zie die opties ook hoor. Maar als ik ze gebruik gebeurt er pas om 16:00 iets mee, omdat dan Renovate wordt afgetrapt.:
[...]
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
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 ]
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
@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
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 .
.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:
1
| 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 .
Wat leren jullie toch een hoop van mij hè 😇
Dan moet ik die dind runner container gebruiken toch van jouw?Leuk dat het werkt @Mars Warrior. Nu even doorpakken en met Forgejo Actions aan de slag
En dan nog wat moeilijke dingen met Ansible…
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| 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 |
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Ik wist dat die in een van de presets was inbegrepen
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).
Renovate had zelf de renovate.json lopen wijzigen. Zo ben ik erachter gekomen.:
[...]
Ik wist dat die in een van de presets was inbegrepen
Het is die container van @alex3305 die draait ook weer Ansible meen ik.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
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:
Docker compose emby:
jail.local:
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.
filter.d/emby.local is de std van f2ban:
Regextest op de container zelf, voor zover ik dit kan interpreteren:
-log file is leesbaar
-regex is correct
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?
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| [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:
1
2
3
4
5
6
7
8
9
10
| 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
| ## 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| 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?
Page intentionally left blank.
Gaat lekker, ligt Codeberg eruit terwijl ik wat wilde experimenteren. Website geeft:
Dus ook een docker compose pull werkt niet
Bash:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| 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 ]
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Codeberg is er weer. Dus alles is up-and-running, maar werken ho-maar!
Ik heb een runner...
:strip_exif()/f/image/GzSa52jv7cyUl9Iq5aNoUxxg.png?f=user_large)
Actions zijn enabled...
:strip_exif()/f/image/iyKMNVqjIl33TI5C235zefqd.png?f=user_large)
En ik heb workflows...
/f/image/L5zwvZyMnPV35Z9tNsUCS1bQ.png?f=fotoalbum_large)
Maar toch weer niet blijkbaar...
/f/image/5kYxcRaFX4TgWiqkTtz9hCsC.png?f=fotoalbum_large)
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
Ik heb een runner...
Actions zijn enabled...
En ik heb workflows...
:strip_exif()/f/image/L5zwvZyMnPV35Z9tNsUCS1bQ.png?f=user_large)
Maar toch weer niet blijkbaar...
:strip_exif()/f/image/5kYxcRaFX4TgWiqkTtz9hCsC.png?f=user_large)
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 ]
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
De fail2ban container heeft als network=host en ik vermoed dat dan chain=DOCKER-USER niet werkt. Je zou chain=FORWARD kunnen proberen.:
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:
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:
filter.d/emby.local is de std van f2ban:
code:
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?
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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| 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 |
Dat kan nog iets eenvoudiger
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
| 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
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.
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.
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.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
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:
1
2
3
4
5
6
7
8
9
10
11
12
| # 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| # Ansible deploy.yml - hosts: server become: yes tasks: - name: Repo clonen/updaten ansible.builtin.git: repo: "git@forgejo.example.com: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.
Dat is fijn!Als je er vragen over hebt mag je die ook altijd via DM stellen
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
@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):
Elke Docker Compose applicatie is bij mij een Role. In deze rol heb ik vier vijf of zes directories:
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:
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.
!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:
1
2
3
4
5
6
7
8
9
| ┌── .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
YAML:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
| - 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:
1
2
3
4
5
| - 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.
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:
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.
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:
1
2
| 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.
Page intentionally left blank.
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 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:
1
2
3
4
5
6
| # .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:
1
2
3
| 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
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.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
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:/f/image/oqTznUI78A5U094Fy9gwpuXe.png?f=fotoalbum_large)
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.
/f/image/S9NQNl3BtYmh7XkLY1jNRoVz.png?f=fotoalbum_large)
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
/f/image/c4cVDvFIx2SSdPFBPdMe7NQB.png?f=fotoalbum_large)
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
:strip_exif()/f/image/oqTznUI78A5U094Fy9gwpuXe.png?f=user_large)
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.
:strip_exif()/f/image/S9NQNl3BtYmh7XkLY1jNRoVz.png?f=user_large)
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
:strip_exif()/f/image/c4cVDvFIx2SSdPFBPdMe7NQB.png?f=user_large)
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
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:
1
2
3
4
5
| 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.
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
.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.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
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:
1
| 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
Ondertussen terug een stap verder, maar nog geen block te merken
iptabled -L op de host geeft effectief iets weer:
Maar dit resulteert niet in een effectieve ban
code:
1
2
3
4
5
6
| 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:
1
2
3
4
5
6
7
8
9
10
11
| 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
Page intentionally left blank.
Nou, nou, nou, nou: ik heb de mega stack "WhoAmI" weten te deployen met Forgejo Actions + Ansible
/f/image/QOVoBbb0yEICTca84LgTo7sA.png?f=fotoalbum_large)
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:
De forgejo action, waarbij ik nog niet heb gekeken naar tool caching enzo. Ff lekker simpel gedaan
En ik heb alles in één Ansible deploy file gezet. Nog geen vars en andere dingen:
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
/f/image/3jYFXgUus0ECnTp8Eok4AA7L.png?f=fotoalbum_large)
Een week geleden nog nooit gehoord van/gewerkt met Forgejo, Renovate en Ansible, en kiek nou!.
Toppie @alex3305
:strip_exif()/f/image/QOVoBbb0yEICTca84LgTo7sA.png?f=user_large)
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:
1
2
3
4
5
6
7
| 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
| 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| - 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
:strip_exif()/f/image/3jYFXgUus0ECnTp8Eok4AA7L.png?f=user_large)
Een week geleden nog nooit gehoord van/gewerkt met Forgejo, Renovate en Ansible, en kiek nou!.
Toppie @alex3305
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
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
roles/docker_compose/vars/main.yml
roles/docker_compose/handlers/main.yml
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.
.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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| - 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:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
| # 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:
1
2
3
4
5
| - 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.
Yep. Ben er ook blij mee. Het is nog wel relatief een eenvoudige opzet, maar het werkt, en uitbreiden kan altijd nog.:
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
Daar ga ik naar kijken ja. Het grootste deel van de tijd is nu het installeren van AnsibleVoor 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
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:
1
2
3
4
| /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 ]
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
@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:
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.
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
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:
:strip_exif()/f/image/KSwoaHEAXKLWMfb7x6vT8Z1Z.png?f=user_large)
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
. 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:
- Controleren van ingevoerde variabelen
- Aanmaken van mappen voor de uit te rollen applicatie
- Templaten van configuratiebestanden (optioneel)
- Aanmaken van Docker Compose directory
- Templaten van Docker Compose
- Docker Compose Up
YAML:
1
2
3
4
5
6
7
8
9
10
11
| - 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:
1
2
3
4
5
6
7
8
9
10
11
12
| - 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:
1
| 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
/u/21638/crop626ad1243c0f9_cropped.png?f=community)