Automation för automationens skull?
Jag är den typen som ser ett manuellt steg och omedelbart börjar fundera på hur det kan automatiseras. Man kan alltid göra lite mer.
Mitt hemlab kör ett antal olika Docker-containers som fyller olika funktioner för mitt nätverk - DNS, Reverse-proxy, Annons-blockering, övervakning m.m. Jag har länge använt Diun för att övervaka images och för att få en ping på en privat Discord-server när det finns uppdateringar. Jag valde denna approach efter att ha kört Portainer en tid, som i sin tur körde Watchtower för att uppdatera images automatiskt. Portainer hade hög overhead och funktioner jag inte behövde.
När jag har gått igenom vad som ska uppdateras körde jag helt enkelt en docker compose pull && docker compose up -d över SSH.
Det var flera manuella steg inblandade och jag funderade på om jag inte kunde automatisera flödet. Jag hade sen tidigare redan ett privat Git-repo i GitHub för att dokumentera mitt hemlab, så tanken gick direkt till att skapa upp Pull Request som jag enkelt kunde godkänna och sen pusha uppdateringen till servern.
Automatisering
Efter sommaren 2025 hade jag gjort ett gediget arbete med Claude Code för att dokumentera upp mitt nätverk, både med beskrivningar och med Infrastrcture as Code principer. Detta gjorde att jag hade en bra grund för att se över mer automatiserade CI/CD flöden.
Jag började med att titta på ersättare till Diun, där jag hittade Renovate som finns som plugin till Github - det är gratis och har som syfte att övervaka dependencies till repositories och skapa issues/pull requests när det finns skäl att göra det.
Flödet jag tittade på :
-
Renovate skannar mina dependencies och skapar PRs när uppdateringar finns
-
Jag granskar PR och mergar om jag vill göra uppdateringen
-
Uppdateringen körs - här fanns det 2 alternativ:
- GitHub Actions med en self-hosted runner som kör Ansible
- GitHub Webhook som anropar en tjänst hos mig som kör scriptet
Jag testade först en self-hosted runner, men det krävde SSH-access mellan maskiner och ytterligare en tjänst att underhålla. Webhook-varianten kändes enklare.
Jag hittade adnanh/webhook som gjorde att jag inte behövde skriva en eget webhook interface för att köra shell kommandon. Jag kombinerade den med en Cloudflare Tunnel för att exponera tjänsten mot GitHub utan att öppna portar.
Det funkade ganska bra men efter några dagar insåg jag att jag inte sparat in på antalet aktiviteter - jag granskade fortfarande varje uppdatering manuellt. Istället för att köra docker compose pull hade jag nu ett komplext flöde med flera tjänster som alla behövde underhållas.
Till slut gick jag tillbaka till Diun och manuella uppdateringar. Ibland är resan viktigare än destinationen. Verktygen jag testade är bra och fyller sina syften! Men för mig är det enklare flödet rätt val just nu.
Referenser
| Verktyg | Beskrivning |
|---|---|
| Diun | Övervakar Docker images och notifierar vid uppdateringar |
| Portainer | GUI för Docker-hantering |
| Watchtower | Automatisk uppdatering av Docker containers |
| Renovate | Skannar dependencies och skapar PRs automatiskt |
| adnanh/webhook | Enkel webhook-server som kör shell-kommandon |
| Cloudflare Tunnel | Exponerar lokala tjänster utan öppna portar |
| Ansible | Infrastructure as Code och konfigurationshantering |
| GitHub Actions | CI/CD med stöd för self-hosted runners |
| Claude Code | AI-assistent för kodning och dokumentation |