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

[WheeleE]

@rens-br Ik heb een paar maanden geleden een dozijn containers verhuist van een Synology naar een dockerhost op Proxmox.
Images kun je gewoon opnieuw binnenhalen op je nieuwe omgeving. De inhoud daarvan is hetzelfde, ongeacht op welke host je ze binnenhaalt.
Voor je containers die gebruik maken van die containers is er verschil tussen container die geen data of configuratie in volumes of op schijf hebben staan, en containers die dat wel hebben.

Het Hello-world image is een voorbeeld van de eerste variant. Heeft geen configuratie of persistente data. Zolang je het docker run comando of de compose-file hebt kun je de container gewoon vers aanmaken op je nieuwe host.

Voor containers met een mapping naar een lokale folder moet je de data wel zelf kopiëren.

code:

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /docker/portainer:/data

In dit voorbeeld uit een van mijn compose-files zou ik dus de directory /docker/portainer moeten kopiëren naar de nieuwe host.

Containers met mappings naar docker volumes vergen meer zoekwerk.

code:

services:
  app:
    image: fireflyiii/core:latest
    container_name: firefly-app
    volumes:
      - firefly_iii_upload:/var/www/html/storage/upload

Hier wordt het docker volume firefly_iii_upload gebruikt.
De data in docker volumes wordt uiteindelijk ook ergens op het filesystem van je host opgeslagen.
Als het goed is in /var/lib/docker/volumes/
De directories van de volumes die je perse nodig hebt zou je ook kunnen kopiëren naar je nieuwe host. Dat kan echter wel wat tricky zijn vanwege rechten, maar is zeker wel mogelijk.

[rens-br]

RobertMe schreef op vrijdag 22 november 2024 @ 14:55:
[...]

Als je zelf geen mapping opgeeft dan maakt Docker automatisch een volume aan (op te vragen met docker volume ls meen ik). In hoeverre is deze kunt exporteren durf ik niet te zeggen, en daarnaast gelden daarvoor uiteraard dezelfde kanttekeningen. Kopieren werkt wellicht, maar geen garantie.

In ieder geval portrainer zelf maakt gebruik van zo'n volume, verder zijn er volgens Portrainer nog 12 andere volumes in gebruik.

WheeleE schreef op vrijdag 22 november 2024 @ 15:14:
@rens-br Ik heb een paar maanden geleden een dozijn containers verhuist van een Synology naar een dockerhost op Proxmox.
Images kun je gewoon opnieuw binnenhalen op je nieuwe omgeving. De inhoud daarvan is hetzelfde, ongeacht op welke host je ze binnenhaalt.
Voor je containers die gebruik maken van die containers is er verschil tussen container die geen data of configuratie in volumes of op schijf hebben staan, en containers die dat wel hebben.

Het Hello-world image is een voorbeeld van de eerste variant. Heeft geen configuratie of persistente data. Zolang je het docker run comando of de compose-file hebt kun je de container gewoon vers aanmaken op je nieuwe host.

Voor containers met een mapping naar een lokale folder moet je de data wel zelf kopiëren.

code:

services:
  portainer:
    image: portainer/portainer-ce:latest
    container_name: portainer
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /docker/portainer:/data

In dit voorbeeld uit een van mijn compose-files zou ik dus de directory /docker/portainer moeten kopiëren naar de nieuwe host.

Containers met mappings naar docker volumes vergen meer zoekwerk.

code:

services:
  app:
    image: fireflyiii/core:latest
    container_name: firefly-app
    volumes:
      - firefly_iii_upload:/var/www/html/storage/upload

Hier wordt het docker volume firefly_iii_upload gebruikt.
De data in docker volumes wordt uiteindelijk ook ergens op het filesystem van je host opgeslagen.
Als het goed is in /var/lib/docker/volumes/
De directories van de volumes die je perse nodig hebt zou je ook kunnen kopiëren naar je nieuwe host. Dat kan echter wel wat tricky zijn vanwege rechten, maar is zeker wel mogelijk.

Bedankt voor de verhelderende uitleg, korte samenvatting dus:

• Maak een backup van alle externe gebruikte mappen. (In mijn geval voornamelijk de /opt/ folder
• Maak een backup van de volumes (/var/lib/docker/volumes)
• Zet de backups terug
• Installeer docker op de nieuwe machine
• Voer daar alle docker-compose commands opnieuw uit
• Klaar is kees?

[WheeleE]

rens-br schreef op vrijdag 22 november 2024 @ 16:30:
[...]


In ieder geval portrainer zelf maakt gebruik van zo'n volume, verder zijn er volgens Portrainer nog 12 andere volumes in gebruik.
[...]


Bedankt voor de verhelderende uitleg, korte samenvatting dus:

• Maak een backup van alle externe gebruikte mappen. (In mijn geval voornamelijk de /opt/ folder
• Maak een backup van de volumes (/var/lib/docker/volumes)
• Zet de backups terug
• Installeer docker op de nieuwe machine
• Voer daar alle docker-compose commands opnieuw uit
• Klaar is kees?

Volgens mij is Kees inderdaad Klaar met die samenvatting.

Voor de zekerheid zou ik wel éérst docker installeren op de nieuwe machine en daar een simpele testcontainer opzetten die gebruik maakt van een volume. Zo kun je zien welke rechten er op de bestanden in /var/lib/docker/volumes horen te staan.
En dan liever per volume:
- aanmaken in portainer
- inhoud van directory op de oude host naar directory op de nieuwe host kopiëren
- privileges corrigeren indien nodig

Portainer zou je wellicht ook vers kunnen installeren in plaats van de backup te gebruiken.
Als je dan per container/stack met de compose files de boel stap voor stap opbouwt heb je uiteindelijk weer een goedlopende en consistente omgeving. (en geen risico op conflicten uit je backup)

[Mars Warrior]

rens-br schreef op vrijdag 22 november 2024 @ 14:36:
[...]
Al die images hebben toch data / settings in zich? Domoticz heb ik draaien en die heeft een mapping naar buiten (opt/Domoticz) die mappen kan ik inderdaad wel verplaatsen van oud naar nieuw. Maar bij containers die geen mapping naar buiten hebben, kan zo zelf geen voorbeelden noemen, gaat dat dan automatisch goed?

Het hele punt van docker is nu juist, dat data en image gescheiden is: oftewel als jij data niet extern mapped (named volume, of een map) deze data weg is na een herstart/recreate van de container.

Dus als jij toestaat dat data in de container wordt opgeslagen en je doet een update van de container, je deze data helemaal kwijt bent: een image is nl in principe read-only!

Zou ik bijvoorbeeld niet gewoon de gehele var/lib/docker map kunnen kopieren van oud naar nieuw?

---

Anders gezegd. Als ik bijvoorbeeld de Unifi Controller opnieuw moet installeren via de dockerfiles, dan moet ik ook alle stappen opnieuw doen. En mogelijk?/waarschijnlijk mijn configuratie opnieuw inladen, toch?

En zo heb ik meer dockers die wat zaken vereisen die ik zou moeten uitvoeren.Dus is best wel wat werk, denk ik, omdat voor 37 dockers opnieuw in te moeten stellen.

Als jij een docker compose file gebruikt dan hoef je niks af te lopen omdat je in die compose file al kunt zien in welke mappen data staat. Die moet je dan overzetten. Je kunt daarbij de rechten ook goed overzetten als je op de juiste manier de spullekes inpakt (is een tar optie vziw).

Databases zou ik inderdaad altijd met een export/import doen. Dan zit je altijd goed, onafhankelijk van gewijzigde structuren.

Wat ik 1 keer heb gedaan is de bestaande compose file overzetten (mappen voor data al aangemaakt), dan alle containers aan laten maken (een database moet er wel zijn om te kunnnen importeren), en daarna d e data overzetten. Databases laat ik draaien voor het overzetten en de rest van de containers stop ik dan om de config/instellingen/data over te zetten. Na een herstart van de containers zou alles 1:1 moeten draaien.

[Mars Warrior]

Pffffffffffffffffffffffffffffffff

Het is gelukt om TimescaleDB (Postgres v17++) toegang over poort 5432 in Caddy Layer4 werkend te krijgen, inclusief een TLS certificaat van Let's Encrypt.

Vanaf mijn desktop kon ik in een testje 125.000 rijen toevoegen in ca 16 seconden over een 1Gbit verbinding. Uiteindelijk moet dit richting de 500 miljoen rijen gaan (werk gerelateerd experiment).

Vanzelfsprekend omdat Postgres V17 - die nu zelf TLS ondersteund - vreselijk nieuw is, zijn er natuurlijk geen echte voorbeelden te vinden, en snapt ook ChatGPT er niks van.

De oplossing van ChatGPT die ik eerder poste klopt overigens ook van geen kant. Caddy verwijderde dit deel gewoon omdat het geen geldige configuratie voorstelde, laat staan dat er ook maar iets van Layer4 wilde werken...

Wat was het doel?

• TimescaleDB over TLS verbinding poort 5432 op specifiek subdomein
• Caddy die het certificaat opvraagt voor dit subdomein
• Volledige definitie/configuratie via Docker labels (en dus de Caddy Docker Proxy plugin)

Met wat beperkingen is dit gelukt. Geen idee of ik die beperkingen nog kan fixen.

• Layer4 vraagt een domein als label. Hierin zitten '.' karakters die de Caddy Docker Proxy plugin helaas gaat lopen omzetten. Geen idee hoe ik dit kan voorkomen.
• Het certificaat voor het subdomein moet in de Postgres map staan, inclusief owner en r/w rechten. Dat is nu handmatig gedaan vanuit de Caddy map. Ik vermoed dat ik dit enkel met een script kan oplossen dat bijv. elke week draait om de updates van het certificaat te automatiseren.

Layer4 definities om eea te laten werken:

YAML:

      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}= ""
      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}[e-mail]= sni ${TIMESCALEDB_VOS_DOMAIN}
      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}.route= "@postgres"
      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}.route.0_tls.connection_policy.alpn= "postgresql"
      - caddy.layer4.0_${TIMESCALEDB_VOS_FULL}.route.1_proxy= ${TIMESCALEDB_VOS_FULL}

Forceren TLS certificaat voor dit domein. Er is immers geen HTTP/HTTPS ingang hiervoor.
Mogelijk kan dit nog op een andere plek, namelijk bij het tls deel hierboven.

YAML:

      - caddy_1=${TIMESCALEDB_VOS_DOMAIN}
      - caddy_1.tls.issuer="acme"

De omgevingsvariabele TIMESCALEDB_VOS_FULL mag dus geen punten bevatten. Ik heb dus nu in de DNS lokaal enkel een naam ingevoerd om op de server uit te komen.

Vraag me dus af of de Layer4 definitie toch nog anders kan, zodat ik niet tegen dit probleem aanloop. Ik heb nu maar alles per regel uitgeschreven, maar of dat nodig is?

Wie weet kan de die variabele ook aan de rechterkant van het "=" teken staan net als bij het caddy_1 gedeelte voor het certificaat. Nou ja. Dat is voor later.

Edit/Update:
Vanzelfsprekend moet je in de config file van Postgres nog aangeven dat je ssl wilt, en waar dan de certificaten (.crt en .key) staan en hoe ze heten. De owner moet 70:70 zijn en beveiliging op 600, want anders wordt het certificaat geweigerd.

[ Voor 4% gewijzigd door Mars Warrior op 27-11-2024 18:44 ]

[Kimi-Alonso]

Hebben jullie tips voor leuke 'dashboard' containers?

Voor mijn homeserver gebruik ik Homer Dashboard naar tevredenheid (zie afb). Ben benieuwd naar de dashboards van anderen.

[Ortep]

@Kimi-Alonso

Ik heb naar een aantal van die dashboards gekeken. Ook bv Heimdall. Maar ik snap het nut niet helemaal.

Dat is het voordeel boven bv een aantal tabs kiezen in een willekeurige browser en dat als 'Home Pages' bewaren?

Als je dan dat profiel opent kan je ook alle dingen benaderen.

Ik heb op die manier net als jij een Media versie, en een Synology management versie en een informatie versie

[Mars Warrior]

Kimi-Alonso schreef op dinsdag 17 december 2024 @ 16:21:
Hebben jullie tips voor leuke 'dashboard' containers?

Voor mijn homeserver gebruik ik Homer Dashboard naar tevredenheid (zie afb). Ben benieuwd naar de dashboards van anderen.

[Afbeelding]

Leuk

Ik gebruik Plugsy hiervoor. Ooit mee begonnen en niet meer verder gekeken.

@Ortep Natuurlijk als je weinig containers hebt, dan kan het ook via de browser, maar dit soort dashboards - in ieder geval Plugsy - zijn dynamisch: als ik wat toevoeg komt het op dit dashboard.

Ik heb ca 40 containers, met soms meervoudige GUI's per container. Dat is niet meer te doen met een browser tabje. Ik zou dan van 40 containers de urllen moeten onthouden. Dat doet mijn hoofd niet meer.

Van 10 vrouwen de namen onthouden is soms al een uitdaging

[Freee!!]

Ortep schreef op dinsdag 17 december 2024 @ 17:03:
@Kimi-Alonso

Ik heb naar een aantal van die dashboards gekeken. Ook bv Heimdall. Maar ik snap het nut niet helemaal.

Dat is het voordeel boven bv een aantal tabs kiezen in een willekeurige browser en dat als 'Home Pages' bewaren?

Als je dan dat profiel opent kan je ook alle dingen benaderen.

Ik heb op die manier net als jij een Media versie, en een Synology management versie en een informatie versie

Het voordeel is dat je een aantal minder gebruikte tabs, die je normaal niet open hebt staan, vlot kunt selecteren.
En ik gebruik Heimdall voor een paar portainers en een Omada controller.

[Kimi-Alonso]

Mars Warrior schreef op dinsdag 17 december 2024 @ 17:16:
[...]

Leuk

Ik gebruik Plugsy hiervoor. Ooit mee begonnen en niet meer verder gekeken.

@Ortep Natuurlijk als je weinig containers hebt, dan kan het ook via de browser, maar dit soort dashboards - in ieder geval Plugsy - zijn dynamisch: als ik wat toevoeg komt het op dit dashboard.

Ik heb ca 40 containers, met soms meervoudige GUI's per container. Dat is niet meer te doen met een browser tabje. Ik zou dan van 40 containers de urllen moeten onthouden. Dat doet mijn hoofd niet meer.

Van 10 vrouwen de namen onthouden is soms al een uitdaging

Plugsy ken ik niet! Dat werkt met een docker socket connection zie ik.
Deze ga ik eens proberen, thanks!

[Ortep]

Mars Warrior schreef op dinsdag 17 december 2024 @ 17:16:

Ik heb ca 40 containers, met soms meervoudige GUI's per container. Dat is niet meer te doen met een browser tabje. Ik zou dan van 40 containers de urllen moeten onthouden. Dat doet mijn hoofd niet meer.

Ik heb er 20, verdeeld over 3 browser profiles. Eentje met 12 tabs en 2 met 4. Ik zit toch niet door elkaar te werken.

Als ik met de 4 Synology's die ik beheer bezig ben wil ik snel tussen de systemen kunnen schakelen.
Dan ben ik meestal niet tegelijk met Media bezig. Daarvoor start ik een ander profiel op.
Maar in theorie kan het zelfs in een enkel browser profiel als je ook nog met groepen werkt.
Dus een groep Servers met 4 tabs er in en een groep Media met 12 tabs er in.

Ik begrijp ook je opmerking over Urllen onthouden niet. Die tik je toch maar een keer in en daarna hoef je ze nooit meer in te tikken? Als ik de volgende keer de browser met dat profiel open, opent hij vanzelf de opgeslagen tabs.

Ik heb net voor de gein Heimdall nog eens in een docker container opgestart. Die doet niet wezenlijk iets anders.
Ik moet eerst (met enge moeite) allerlei buttons maken op het home scherm. En daar moet ik dan ook urellen invoeren. En als ik daar dan op klik opent hij een nieuw tabje in mijn browser.
Waarom de omweg? Ik had net zo goed gelijk de zaak in tabs kunnen zetten en dan in de instellingen kiezen voor sla huidige tabs op als home scherm. Dan hoef ik niet eerst naar Heimdall.

Ik probeer net te trollen of zo, iedereen moet werken zoals het goed voelt.
Ik probeer alleen te begrijpen waarom sommige mensen dit kiezen. Voor mij lijkt het alleen een omweg om hetzelfde te bereiken. Maar misschien mis ik iets heel belangrijks.

[alex3305]

@Kimi-Alonso Ik heb een dashboard in Home Assistant gemaakt. Klein stukje:



Ik gebruik hiervoor wel een trucje door de Tile card te modden met een subtitel:

YAML:

type: tile
entity: input_button.dummy
name: AdGuard Home
icon: mdi:dns
color: light-green
icon_tap_action:
  action: none
tap_action:
  action: url
  url_path: http://dns:3000/
card_mod:
  style:
    ha-tile-info$: |
      .secondary { 
        visibility: hidden; 
      }
      .secondary::before {
        content: 'DNS en adblocker';
        visibility: visible;
      }

Zelf gebruik ik het weinig, maar mijn vrouw vind het wel enorm prettig. Ze is nogal zelfredzaam en hierdoor hoeft ze niet altijd te vragen wat de URL ook alweer was van iets.

[Sp33dFr34k]

Ik gebruik Homepage, heb zo ongeveer alles geprobeerd en vind weinig ideaal, maar ben hierop blijven hangen

[ Voor 20% gewijzigd door Sp33dFr34k op 17-12-2024 23:27 ]

[RobertMe]

Ik ben al een tijdje op zoek naar een tool waarvan ik niet weet of die bestaat, en die ik nog niet direct heb kunnen vinden, maar misschien weten anderen hier dat wel

De "case" is dat ik nu compose files heb met gewoon de latest tag (of een latest achtige variant), en dus niet vast op een versie. Vervolgens ga ik periodiek de "mapjes" af en doe een docker compose up -d --pull op hoop van zegen dat alles blijft werken.
Echter heb ik ook een Gitea server draaien. En ken ik de tool Renovate om dependencies van een project te "monitoren" en pull requests aan te maken voor updates, en Renovate ondersteund daarbij ook compose files. Waar ik dus naar op zoek ben is een workflow waarbij ik per stack een Git repository aan maak en Renovate deze laat monitoren op updates. Waarbij in de compose files dus steeds specifieke versie tags gebruikt (kunnen) worden, de Renovate PR de notificatie is dat er een update is van het pakket, en de PR ook meteen een changelog bevat (en naar changelog linkt).

Echter wil ik dan wel dat als ik de PR merge, dat deze ook automatisch wordt "uitgerold". Waar ik dus op zoek ben is een tool waarin ik bv een mapping kan zetten van (lokale) mappen met bijbehorende Git repository (of alleen de map, want de git repo is uit te lezen uit de map), en die te koppelen is aan webhooks (van Gitea in dit geval). Waarbij de tool bij changes van in de repository (op basis van de webhook) vervolgens automatisch een pull van die repository doet en vervolgens een docker compose up -d

Ergo een stukje GitOps. Waarbij wijzigingen in de Git repository automatisch worden toegepast / uitgerold.

Het enige dat ik tot nu toe ben tegengekomen is Komodo die "iets" van ondersteuning voor [url=https://komo.do/docs/docker-compose]Docker Compose heeft in combinatie met Git[/mono]. Alleen kan ik daar nog niet uit op maken of die ook met de "lokale" repository werkt en dus ook alle bestanden in de repository pullt etc.. Immers zijn er ook voldoende stacks die uit "meer" bestaan. Bv een stack met Traefik wil ik ook de traefik.yaml in de repo zetten. De Home Assistant stack wil ik ook alle automations etc in dezelfde repository zetten, ... Waarbij zo'n tool pluspunten scoort als die variabel is in wat te doen. Als de compose file geupdate is doe een docker compose up -d. Als een config file veranderd is doe een docker compose restart, of roep een custom API endpoint aan, voer een script uit, you name it.

[sjorsjuhmaniac]

RobertMe schreef op donderdag 16 januari 2025 @ 19:33:
Ik ben al een tijdje op zoek naar een tool waarvan ik niet weet of die bestaat, en die ik nog niet direct heb kunnen vinden, maar misschien weten anderen hier dat wel

De "case" is dat ik nu compose files heb met gewoon de latest tag (of een latest achtige variant), en dus niet vast op een versie. Vervolgens ga ik periodiek de "mapjes" af en doe een docker compose up -d --pull op hoop van zegen dat alles blijft werken.
Echter heb ik ook een Gitea server draaien. En ken ik de tool Renovate om dependencies van een project te "monitoren" en pull requests aan te maken voor updates, en Renovate ondersteund daarbij ook compose files. Waar ik dus naar op zoek ben is een workflow waarbij ik per stack een Git repository aan maak en Renovate deze laat monitoren op updates. Waarbij in de compose files dus steeds specifieke versie tags gebruikt (kunnen) worden, de Renovate PR de notificatie is dat er een update is van het pakket, en de PR ook meteen een changelog bevat (en naar changelog linkt).

Echter wil ik dan wel dat als ik de PR merge, dat deze ook automatisch wordt "uitgerold". Waar ik dus op zoek ben is een tool waarin ik bv een mapping kan zetten van (lokale) mappen met bijbehorende Git repository (of alleen de map, want de git repo is uit te lezen uit de map), en die te koppelen is aan webhooks (van Gitea in dit geval). Waarbij de tool bij changes van in de repository (op basis van de webhook) vervolgens automatisch een pull van die repository doet en vervolgens een docker compose up -d

Ergo een stukje GitOps. Waarbij wijzigingen in de Git repository automatisch worden toegepast / uitgerold.

Het enige dat ik tot nu toe ben tegengekomen is Komodo die "iets" van ondersteuning voor [url=https://komo.do/docs/docker-compose]Docker Compose heeft in combinatie met Git[/mono]. Alleen kan ik daar nog niet uit op maken of die ook met de "lokale" repository werkt en dus ook alle bestanden in de repository pullt etc.. Immers zijn er ook voldoende stacks die uit "meer" bestaan. Bv een stack met Traefik wil ik ook de traefik.yaml in de repo zetten. De Home Assistant stack wil ik ook alle automations etc in dezelfde repository zetten, ... Waarbij zo'n tool pluspunten scoort als die variabel is in wat te doen. Als de compose file geupdate is doe een docker compose up -d. Als een config file veranderd is doe een docker compose restart, of roep een custom API endpoint aan, voer een script uit, you name it.

Ik gebruik de functie zelf niet maar ik weet dat portainer i.i.g. de compose vanuit een git kan halen. Je zou eens in de documentatie kunnen kijken of het verder is wat je zoekt.


Mijn persoonlijke workflow is vergelijkbaar met wat je beschrijft, echter doe ik het met de hand. Ik loop de repo na en fetch/pull waar nodig, op mijn pc. Check de changelogs en push dat dan naar mijn eigen branch op mijn gitea. Op de server waar docker draait pull ik dan weer mijn eigen branch vanaf gitea . Daarna update ik met de hand de compose in portainer. Ik heb iets van 10stacks dus ik vind het nog te overzien.

[Sp33dFr34k]

Ik heb gewerkt met verschillende stacks, maar vond het lomp. Heb nu alles in 1 stack (+- 40 containers). Ik doe handmatig iedere maand een pull en loop dan alles na. Zelden problemen mee eigenlijk...

[DjoeC]

Sp33dFr34k schreef op zaterdag 18 januari 2025 @ 16:04:
Ik heb gewerkt met verschillende stacks, maar vond het lomp. Heb nu alles in 1 stack (+- 40 containers). Ik doe handmatig iedere maand een pull en loop dan alles na. Zelden problemen mee eigenlijk...

Grappig... Ik hoor dit vaker maar heb nog niet (nooit) begrepen waarom alles in 1 stack beter zou zijn. Ik heb helemaal geen stacks maar alleen (nu 29) losse compose files. Portainer doet de pulls van nieuwe versies, daarna is het aan mij om de compose wel of niet opnieuw uit te voeren.

Misschien zie ik iets over t hoofd?

[Sp33dFr34k]

DjoeC schreef op zaterdag 18 januari 2025 @ 16:11:
[...]

Grappig... Ik hoor dit vaker maar heb nog niet (nooit) begrepen waarom alles in 1 stack beter zou zijn. Ik heb helemaal geen stacks maar alleen (nu 29) losse compose files. Portainer doet de pulls van nieuwe versies, daarna is het aan mij om de compose wel of niet opnieuw uit te voeren.

Misschien zie ik iets over t hoofd?

Ik gebruik geen Portainer, ik ben een CLI man

[sjorsjuhmaniac]

DjoeC schreef op zaterdag 18 januari 2025 @ 16:11:
[...]

Grappig... Ik hoor dit vaker maar heb nog niet (nooit) begrepen waarom alles in 1 stack beter zou zijn. Ik heb helemaal geen stacks maar alleen (nu 29) losse compose files. Portainer doet de pulls van nieuwe versies, daarna is het aan mij om de compose wel of niet opnieuw uit te voeren.

Misschien zie ik iets over t hoofd?

Een compose file == stack als je maar een node hebt.

[sjorsjuhmaniac]

Sp33dFr34k schreef op zaterdag 18 januari 2025 @ 16:04:
Ik heb gewerkt met verschillende stacks, maar vond het lomp. Heb nu alles in 1 stack (+- 40 containers). Ik doe handmatig iedere maand een pull en loop dan alles na. Zelden problemen mee eigenlijk...

Had ik vroeger ook maar wordt snel vervelend als je meerdere services draait die afhankelijk zijn van een andere service. Met verschillende stacks kan je een service bewerken zonder dat een andere er last van hoeft te hebben. Ik heb BV mijn reverse proxy in z’n eentje in een compose staan. Die hoeft dan niet herstart te worden als ik bv een van de webservices wil updaten. Dan blijft bv de file storage gewoon beschikbaar terwijl je met de webservice bezig bent.

Maar ieder z’n ding

[Sp33dFr34k]

sjorsjuhmaniac schreef op zaterdag 18 januari 2025 @ 18:13:
[...]


Had ik vroeger ook maar wordt snel vervelend als je meerdere services draait die afhankelijk zijn van een andere service. Met verschillende stacks kan je een service bewerken zonder dat een andere er last van hoeft te hebben. Ik heb BV mijn reverse proxy in z’n eentje in een compose staan. Die hoeft dan niet herstart te worden als ik bv een van de webservices wil updaten. Dan blijft bv de file storage gewoon beschikbaar terwijl je met de webservice bezig bent.

Maar ieder z’n ding

Hoeft bij mij ook niet hoor

Ik update meestal de service die ik wil met de containernaam in het commando. Heeft geen enkele andere container last van.

[Mars Warrior]

sjorsjuhmaniac schreef op zaterdag 18 januari 2025 @ 18:13:
[...]
Had ik vroeger ook maar wordt snel vervelend als je meerdere services draait die afhankelijk zijn van een andere service. Met verschillende stacks kan je een service bewerken zonder dat een andere er last van hoeft te hebben. Ik heb BV mijn reverse proxy in z’n eentje in een compose staan. Die hoeft dan niet herstart te worden als ik bv een van de webservices wil updaten. Dan blijft bv de file storage gewoon beschikbaar terwijl je met de webservice bezig bent.

Maar ieder z’n ding

Huh?

Ik heb ook maar 1 compose file met ca 40 containers. Lekker makkelijk met al die depends_on dingen.

Als ik 1 van de services wijzig, wordt enkel die ene service ge-recreate door docker. Alle anderen blijven gewoon draaien. Tenzij er afhankelijkheden zijn, dan wordt een hele rits containers herstart.

Dus

code:

docker compose up -d

Natuurlijk kun je ook explixiet de container naam hierin opgeven, maar dat hoeft niet.

De 40 containers draaien circa 300 applicaties/processen
De 3 grootste containers draaien al 180 processen (100 + 40 + 40).

[sjorsjuhmaniac]

Aah. Ok kruip weer terug in mij hol het is nogal even geleden eer ik op de cli met docker bezig was.

[CH4OS]

Sp33dFr34k schreef op donderdag 22 augustus 2024 @ 13:51:
Afhankelijkheden, bedoelen jullie daarmee de "depends_on"? Want die doet irl niet zoveel, houdt alleen rekening met volgorde van opstarten en meer niet.

Ik weet het, dit is een wat oudere post, maar dit is wel kort door de bocht. Zet maar eens een healthcheck op de container(s) die in depends_on genoemd zijn.

Ik heb overigens wél meerdere docker-compose.yml files. Ik heb de stacks eigenlijk gecategoriseerd. Containers voor de downloads zitten dan daarin. Ik heb dan vervolgens twee netwerken; $categorie en $categorie-ext. De backend containers zitten dan in het $categorie netwerk dat internal is, is er ook extern toegang nodig, krijgt de container ook het $categorie-ext netwerk. Vervolgens wordt dat al dan niet ontsloten via Traefik.

Binnenkort ga ik eens stoeien met socket-proxy voor Traefik, ipv direct de socket met :ro te mounten.

[ Voor 38% gewijzigd door CH4OS op 19-01-2025 12:12 ]

[Arunia]

Lang geleden, maar hoop na mijn operatie gewoon wat meer hier aan te werken.
Denk dat ik docker desktop probeer te vervangen. Geloof dat dat meer zoiets is als Portainer. Die draai ik ook gewoon. Dus ben daarin met Stacks bezig. Op een enkeling na die niet binnen Portainer is gemaakt, lijkt dat gewoon prima te werken.
Moet nog steeds bekijken hoe ik dat met mijn kookboek container doe. Deze heb ik blijkbaar geen admin account voor aangemaakt. De default lijkt ook niet beschikbaar te zijn, maar dat kan ook een oudere variant zijn waardoor ik de volgende credentials heb.

Gewoon uiteindelijk alles wat netter maken en beter beheerbaar.

[Airw0lf]

Ik probeer via Docker-cli een Redis container te starten met een custom config file via een named volume:

code:

docker run \
  --name redis \
  --network host \
  -v /opt/docker/redis/redis-data:/redis-data \
  -v /opt/docker/redis/redis-config:/usr/local/etc/redis \
  -e TZ=Europe/Amsterdam \
  -d \
  --restart unless-stopped \
  docker.io/redis

Ondanks dat er een config-bestandje in de container-folder /usr/local/etc/redis
staat lijkt dit niet te worden uitgevoerd.

Het config-bestandje heet redis.conf en bevat maar één regel: bind 127.0.0.1.

Iemand suggesties?

[ Voor 9% gewijzigd door Airw0lf op 21-02-2025 11:03 ]

[orvintax]

Airw0lf schreef op vrijdag 21 februari 2025 @ 10:58:
Ik probeer via Docker-cli een Redis container te starten met een custom config file via een named volume:

code:

docker run \
  --name redis \
  --network host \
  -v /opt/docker/redis/redis-data:/redis-data \
  -v /opt/docker/redis/redis-config:/usr/local/etc/redis \
  -e TZ=Europe/Amsterdam \
  -d \
  --restart unless-stopped \
  docker.io/redis

Ondanks dat er een config-bestandje in de container-folder /usr/local/etc/redis
staat lijkt dit niet te worden uitgevoerd.

Het config-bestandje heet redis.conf en bevat maar één regel: bind 127.0.0.1.

Iemand suggesties?

Heeft de container write access naar de folder? Is een vereiste volgens Redis:

The mapped directory should be writable, as depending on the configuration and mode of operation, Redis may need to create additional configuration files or rewrite existing ones.

Als ik kijk naar hun voorbeeld runnen ze zelf ook het "redis-server" command met een path naar de config file:

$ docker run -v /myredis/conf:/usr/local/etc/redis --name myredis redis redis-server /usr/local/etc/redis/redis.conf

[alex3305]

Ik ben de laatste tijd wat minder op Tweakers te vinden, en besefte me daardoor ook dat het alweer even geleden was dat ik iets over Caddy en mijn Docker avonturen had gepost. Inmiddels heb ik in mijn homelab flink wat stappen gemaakt. Ik heb bijna alles naar Ansible gemigreerd. Professioneel heb ik daar best wat ervaring mee, maar dat was weer een flinke tijd geleden en dus weer even wennen. Aangezien dat best wel wat voeten in de aarde heeft, laat ik dat voor nu even.

Wel heb ik mijn Gitea installatie naar Forgejo gemigreerd en ben tegelijkertijd ook met Renovate aan de slag gegaan. Met Renovate kan ik eenvoudig versions pinnen en is het updaten van containers veel overzichtelijker en transparanter. Vooral ten opzichte van mijn eerdere setup met Watchtower. In mijn Renovate config heb ik ook custom managers opgenomen zodat ik in Dockerfiles en YAML files met annotations kan werken en dat Docker Compose in Jinja formaat toch gemanaged wordt. Hieronder een snippet van deze configuratie:

JSON:

{
  "customManagers": [
    {
      "customType": "regex",
      "description": "Match renovate annotations in Dockerfiles",
      "fileMatch": ["(^|/|\\.)Dockerfile$", "(^|/)Dockerfile\\.[^/]*$"],
      "matchStrings": [
        "# renovate: datasource=(?<datasource>[a-z-]+?) depName=(?<depName>.+?)(?: (?:packageName|lookupName)=(?<packageName>.+?))?(?: versioning=(?<versioning>[a-z-]+?))?\\s(?:ENV|ARG) .+?_VERSION=(?<currentValue>.+?)\\s"
      ]
    },
    {
      "customType": "regex",
      "description": "Match renovate annotations in YAML files",
      "fileMatch": ["^.*\\.ya?ml$"],
      "matchStrings": [
        "# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?\\s(?<yamlKey>.*?)?: ['\"]?(?<currentValue>.*?)['\"]?\\s"
      ],
      "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}"
    },
    {
      "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"
    }
  ]
}

Ik gebruik dit bijvoorbeeld in mijn Caddy Dockerfile:

Docker:

# renovate: datasource=github-releases depName=caddyserver/caddy
ARG CADDY_VERSION=2.9.1

FROM caddy:${CADDY_VERSION}-builder-alpine AS builder
RUN GOTOOLCHAIN=go1.24.1 xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    --with github.com/greenpau/caddy-security \
    --with github.com/lucaslorentz/caddy-docker-proxy/v2 \
    --with github.com/mholt/caddy-l4 \
    --with github.com/mholt/caddy-dynamicdns \
    --with github.com/WeidiDeng/caddy-cloudflare-ip

FROM caddy:${CADDY_VERSION}-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

RUN apk add --no-cache tzdata

LABEL org.opencontainers.image.source="https://github.com/caddyserver/caddy"

ENTRYPOINT ["/usr/bin/caddy"]
CMD ["docker-proxy"]

Waarbij het version pinnen van de modules nog op het todo lijstje staat .

Met mijn migratie van Gitea naar Forgejo vond ik het wel enorm jammer dat er geen complete Forgejo runner dind image was zoals bij Gitea. ik heb een tijdje proberen aan te klooien met twee losse containers (runner en dind), maar dat vond ik enorm omslachtig en kreeg het uiteindelijk ook niet werkend. Daarom heb ik hier uiteindelijk een eigen custom image voor gebouwd op basis van de Gitea en Forgejo code. Ik wil dit nog (open source) beschikbaar gaan stellen, maar ben ik nog niet aan toegekomen.

Voortbordurend op Caddy ben ik echt enorm te spreken over mijn setup die ik al een keer eerder heb genoemd met, Caddy Docker Proxy, Caddy Layer4, Caddy Security en Docker labels. Voor Forgejo ziet er dit als Ansible template bijvoorbeeld zo uit:

YAML:

#jinja2: lstrip_blocks: "True", trim_blocks: "True"
---
# {{ ansible_managed }}

services:
  forgejo:
    container_name: {{ role_name }}
    image: codeberg.org/forgejo/forgejo:10.0.3
    restart: on-failure:5
    environment:
      USER_UID: {{ forgejo_user_id }}
      USER_GID: {{ forgejo_group_id }}
    networks:
      internal:
      ingress:
    volumes:
      - {{ forgejo_appdata }}:/data
      - /etc/localtime:/etc/localtime:ro
    {% if forgejo_docker_options is defined %}
    {{ forgejo_docker_options | to_nice_yaml | indent(4) }}
    {%- endif %}
    labels:
      caddy_1: "{{ forgejo_domain }}"
      caddy_1.@{{ docker_compose_project_name }}.import: "local-ip-whitelist"
      caddy_1.@{{ docker_compose_project_name }}.host: "{{ forgejo_domain }}"
      caddy_1.handle: "@{{ docker_compose_project_name }}"
      caddy_1.handle.reverse_proxy: "{{ '{{' }}upstreams 80{{ '}}' }}"
      caddy_2.layer4.:22.@{{ docker_compose_project_name }}-ssh.ssh:
      caddy_2.layer4.:22.@{{ docker_compose_project_name }}-ssh.remote_ip: "{{ local_ip_range }}"
      caddy_2.layer4.:22.route: "@{{ docker_compose_project_name }}-ssh"
      caddy_2.layer4.:22.route.proxy: "{{ '{{' }}upstreams 22{{ '}}' }}"
      {%- if "unraid" in (ansible_kernel | lower) +%}
      net.unraid.docker.icon: https://avatars.githubusercontent.com/u/118922216?s=200&v=4
      net.unraid.docker.managed: ansible
      net.unraid.docker.shell: /bin/bash
      {% endif %}

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

En gerendered dan zo:

YAML:

---
# Ansible Managed

services:
  forgejo:
    container_name: forgejo
    image: codeberg.org/forgejo/forgejo:10.0.3
    restart: on-failure:5
    environment:
      USER_UID: 2001
      USER_GID: 2001
    networks:
      internal:
      ingress:
    volumes:
      - /mnt/applications/appdata/forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    cpus: 2
    cpuset: 12-15
    labels:
      caddy_1: "example.com"
      [e-mail]: "local-ip-whitelist"
      [e-mail]: "example.com"
      caddy_1.handle: "@forgejo"
      caddy_1.handle.reverse_proxy: "{{upstreams 80}}"
      caddy_2.layer4.:[e-mail]:
      caddy_2.layer4.:[e-mail]_ip: "192.168.0.0/16"
      caddy_2.layer4.:22.route: "@forgejo-ssh"
      caddy_2.layer4.:22.route.proxy: "{{upstreams 22}}"
      net.unraid.docker.icon: https://avatars.githubusercontent.com/u/118922216?s=200&v=4
      net.unraid.docker.managed: ansible
      net.unraid.docker.shell: /bin/bash

networks:
  internal:
    name: forgejo-overlay
    external: true
  ingress:
    name: swarm-overlay
    external: true

Daarbij vind ik het echt heel fijn dat dit dynamisch uitgerold wordt. Dat verminderd de beheerlast met bijvoorbeeld een tool zoals Nginx Proxy Manager aanzienlijk.

Bij een push of pull request (update) wordt er automatisch een Forgejo workflow getriggerd. Dit gebeurd standaard als dry-run om in ieder geval het playbook te kunnen test. En afhankelijk van de applicatie wordt er bij een merge naar de hoofdbranch een daadwerkelijke uitrol gedaan. Dus ook bij applicatie updates. Zo'n workflow triggered dan een Ansible playbook die vervolgens na template actie(s) een Docker Compose Up doet op de target machine. Waarbij ik Docker Compose tevens manage via Ansible, Forgejo (Actions) en Renovate .

Grootste project waar ik momenteel nog mee bezig ben is het SSO migreren naar Pocket ID. Dat heeft alleen niet bijster veel met Docker te maken .

[DjoeC]

@alex3305 Tja, wat jij gedaan hebt en hier beschrijft is hoe ik het graag zou willen hebben Helaas ontbreekt het mij aan een stuk basiskennis op dit vlak. Zelfs jaren in (een andere hoek van) de IT bekenet niet dat ik alles zomaar ken en kan...

Dan brengt t voorjaar ook nog eens flink wat huis en tuinklussen die voorrang gaan krijgen.

Maar, ik heb je post gebookmarked om zo af en toe te gebruiken als vertrekpunt bij kennis opbouwen. Dank dus voor die post!

[alex3305]

@DjoeC Het is misschien wat veel voor een GoT post. En het is ook niet alles . Maar ik moet zeggen dat Renovate bijvoorbeeld kinderlijk eenvoudig was om mee te starten . Mijn eigen documentatie is ook erg kort en daarin verwijs ik naar een Gitea pagina / blogpost en een blogpost van Logan Marchione. Ik gebruik dan de volgende workflow:

YAML:

name: Run Renovate

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

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

jobs:
  renovate:
    name: Renovate
    runs-on: docker
    container: ghcr.io/renovatebot/renovate:39.223.0
    timeout-minutes: 30
    steps:
      - name: ⤵️ Checkout repository
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - 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 }}
          DOCKER_HUB_USERNAME: ${{ vars.RENOVATE_DOCKER_HUB_USERNAME }}
          DOCKER_HUB_PASSWORD: ${{ secrets.RENOVATE_DOCKER_HUB_TOKEN }}
          GITEA_REGISTRY_USERNAME: ${{ vars.RENOVATE_GITEA_REGISTRY_USERNAME }}
          GITEA_REGISTRY_PASSWORD: ${{ secrets.RENOVATE_GITEA_REGISTRY_TOKEN }}
          GITHUB_COM_TOKEN: ${{ secrets.RENOVATE_GITHUB_COM_TOKEN }}
          RENOVATE_CONFIG_FILE: 'config.js'
          RENOVATE_CONFIG_MIGRATION: 'true'
          RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}

Met daarna wat slim gekozen instellingen is het vervolgens redelijk hands-off en laat ik Renovate bot het werk doen:




Dat noem ik nogmaals omdat ik merk dat Renovate mij enorm veel werk uit handen heeft genomen. Als in dat ik niet hoef te controleren of er versie-updates zijn. En wanneer ik dan ga of wil updaten. Ook kan ik Renovate op pauze zetten bij bijvoorbeeld vakanties of bepaalde applicaties niet automatisch updaten. Dat is niet zo transparant of evident bij een tool zoals Watchtower.

Toen ik laatst bijvoorbeeld dit issue in Stirling PDF tegenkwam kon ik direct terug naar een oude(re) versie omdat ik wist welke versie (de vorige) nog werkte. En als klap op de vuurpijl heb ik ook de build status van de main branch in de readme:



Ik wil hier nog graag de huidige versienummers bij hebben, maar op deze manier kan ik ook al zien wat de build / deployment status is.

Allemaal verbeteringen die initieel wel wat (meer) tijd kosten, maar uiteindelijk door het gebrek aan aanvullend onderhoud weer veel tijd opleveren om andere leuke dingen te doen .

[Airw0lf]

Klinkt goed en ziet er fraai uit. Hoe verhoudt zich dit tot Kubernetes?

[ Voor 31% gewijzigd door Airw0lf op 31-03-2025 17:48 ]

[alex3305]

Airw0lf schreef op maandag 31 maart 2025 @ 17:48:
Klinkt goed en ziet er fraai uit. Hoe verhoudt zich dit tot Kubernetes?

Goede vraag, maar dat is een beetje appels en peren vergelijken.

Als je degelijke Kubernetes deploys hebt, heb je ook nog abstractie van systemen. Dat houdt in dat je applicaties deployed op je Kubernetes cluster. Het is dan aan de orchestrator en scheduler om op de applicatie op de juiste plek(ken) neer te zetten. Dat is fantastisch als je meerdere systemen hebt die (redelijk) gelijk aan elkaar zijn, maar wat mij betreft ongeschikt als de onderliggende systemen veel van elkaar verschillen. Zoals bij mij. Mijn primaire machine is 10x sneller dan mijn secundaire.

Daarmee kom ik ook meteen op het volgende struikelblok, ik heb (in principe) maar 2 systemen. 1 te weinig voor een minimaal gezond HA cluster van 3 systemen. Ik weet dat er manieren zijn om een cluster te draaien met 1 of 2 machines, maar ik zie het niet zo zitten om een kapot cluster te hebben als ik de master node reboot.

Ook is Kubernetes niet bepaald lichtgewicht. Ik weet niet of CPU affinity (wat ik veel gebruik) ondersteund wordt, volgens mij niet. In Docker Swarm deployments in ieder geval ook niet, vandaar dat ik dat ook niet gebruik. Het mappen van hardware (Zigbee en Z-Wave dongles) is niet altijd evident. En dan heb ik het nog niet over storage gehad .

Voor mijn thuissituatie is Docker met Docker Compose vanuit Ansible voor deployments en Docker Swarm voor networking dus ruim voldoende. Vanuit Docker Swarm gebruik ik toch alleen maar overlay networking.

Ansible vind ik ook niet altijd je-van-het. Voornamelijk door de enorm hoge initiële drempel, maar aangezien ik daar al bekend mee was, was dat voor mij geen probleem. En daarnaast heb ik dit ook niet in één keer opgezet hè. Mijn eerste compose config in Git is misschien ook al van 10 jaar geleden.

[orvintax]

alex3305 schreef op maandag 31 maart 2025 @ 14:53:
Ik ben de laatste tijd wat minder op Tweakers te vinden, en besefte me daardoor ook dat het alweer even geleden was dat ik iets over Caddy en mijn Docker avonturen had gepost. Inmiddels heb ik in mijn homelab flink wat stappen gemaakt. Ik heb bijna alles naar Ansible gemigreerd. Professioneel heb ik daar best wat ervaring mee, maar dat was weer een flinke tijd geleden en dus weer even wennen. Aangezien dat best wel wat voeten in de aarde heeft, laat ik dat voor nu even.

Wel heb ik mijn Gitea installatie naar Forgejo gemigreerd en ben tegelijkertijd ook met Renovate aan de slag gegaan. Met Renovate kan ik eenvoudig versions pinnen en is het updaten van containers veel overzichtelijker en transparanter. Vooral ten opzichte van mijn eerdere setup met Watchtower. In mijn Renovate config heb ik ook custom managers opgenomen zodat ik in Dockerfiles en YAML files met annotations kan werken en dat Docker Compose in Jinja formaat toch gemanaged wordt. Hieronder een snippet van deze configuratie:

JSON:

{
  "customManagers": [
    {
      "customType": "regex",
      "description": "Match renovate annotations in Dockerfiles",
      "fileMatch": ["(^|/|\\.)Dockerfile$", "(^|/)Dockerfile\\.[^/]*$"],
      "matchStrings": [
        "# renovate: datasource=(?<datasource>[a-z-]+?) depName=(?<depName>.+?)(?: (?:packageName|lookupName)=(?<packageName>.+?))?(?: versioning=(?<versioning>[a-z-]+?))?\\s(?:ENV|ARG) .+?_VERSION=(?<currentValue>.+?)\\s"
      ]
    },
    {
      "customType": "regex",
      "description": "Match renovate annotations in YAML files",
      "fileMatch": ["^.*\\.ya?ml$"],
      "matchStrings": [
        "# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?\\s(?<yamlKey>.*?)?: ['\"]?(?<currentValue>.*?)['\"]?\\s"
      ],
      "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}"
    },
    {
      "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"
    }
  ]
}

Ik gebruik dit bijvoorbeeld in mijn Caddy Dockerfile:

Docker:

# renovate: datasource=github-releases depName=caddyserver/caddy
ARG CADDY_VERSION=2.9.1

FROM caddy:${CADDY_VERSION}-builder-alpine AS builder
RUN GOTOOLCHAIN=go1.24.1 xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    --with github.com/greenpau/caddy-security \
    --with github.com/lucaslorentz/caddy-docker-proxy/v2 \
    --with github.com/mholt/caddy-l4 \
    --with github.com/mholt/caddy-dynamicdns \
    --with github.com/WeidiDeng/caddy-cloudflare-ip

FROM caddy:${CADDY_VERSION}-alpine
COPY --from=builder /usr/bin/caddy /usr/bin/caddy

RUN apk add --no-cache tzdata

LABEL org.opencontainers.image.source="https://github.com/caddyserver/caddy"

ENTRYPOINT ["/usr/bin/caddy"]
CMD ["docker-proxy"]

Waarbij het version pinnen van de modules nog op het todo lijstje staat .

Met mijn migratie van Gitea naar Forgejo vond ik het wel enorm jammer dat er geen complete Forgejo runner dind image was zoals bij Gitea. ik heb een tijdje proberen aan te klooien met twee losse containers (runner en dind), maar dat vond ik enorm omslachtig en kreeg het uiteindelijk ook niet werkend. Daarom heb ik hier uiteindelijk een eigen custom image voor gebouwd op basis van de Gitea en Forgejo code. Ik wil dit nog (open source) beschikbaar gaan stellen, maar ben ik nog niet aan toegekomen.

Voortbordurend op Caddy ben ik echt enorm te spreken over mijn setup die ik al een keer eerder heb genoemd met, Caddy Docker Proxy, Caddy Layer4, Caddy Security en Docker labels. Voor Forgejo ziet er dit als Ansible template bijvoorbeeld zo uit:

YAML:

#jinja2: lstrip_blocks: "True", trim_blocks: "True"
---
# {{ ansible_managed }}

services:
  forgejo:
    container_name: {{ role_name }}
    image: codeberg.org/forgejo/forgejo:10.0.3
    restart: on-failure:5
    environment:
      USER_UID: {{ forgejo_user_id }}
      USER_GID: {{ forgejo_group_id }}
    networks:
      internal:
      ingress:
    volumes:
      - {{ forgejo_appdata }}:/data
      - /etc/localtime:/etc/localtime:ro
    {% if forgejo_docker_options is defined %}
    {{ forgejo_docker_options | to_nice_yaml | indent(4) }}
    {%- endif %}
    labels:
      caddy_1: "{{ forgejo_domain }}"
      caddy_1.@{{ docker_compose_project_name }}.import: "local-ip-whitelist"
      caddy_1.@{{ docker_compose_project_name }}.host: "{{ forgejo_domain }}"
      caddy_1.handle: "@{{ docker_compose_project_name }}"
      caddy_1.handle.reverse_proxy: "{{ '{{' }}upstreams 80{{ '}}' }}"
      caddy_2.layer4.:22.@{{ docker_compose_project_name }}-ssh.ssh:
      caddy_2.layer4.:22.@{{ docker_compose_project_name }}-ssh.remote_ip: "{{ local_ip_range }}"
      caddy_2.layer4.:22.route: "@{{ docker_compose_project_name }}-ssh"
      caddy_2.layer4.:22.route.proxy: "{{ '{{' }}upstreams 22{{ '}}' }}"
      {%- if "unraid" in (ansible_kernel | lower) +%}
      net.unraid.docker.icon: https://avatars.githubusercontent.com/u/118922216?s=200&v=4
      net.unraid.docker.managed: ansible
      net.unraid.docker.shell: /bin/bash
      {% endif %}

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

En gerendered dan zo:

YAML:

---
# Ansible Managed

services:
  forgejo:
    container_name: forgejo
    image: codeberg.org/forgejo/forgejo:10.0.3
    restart: on-failure:5
    environment:
      USER_UID: 2001
      USER_GID: 2001
    networks:
      internal:
      ingress:
    volumes:
      - /mnt/applications/appdata/forgejo:/data
      - /etc/localtime:/etc/localtime:ro
    cpus: 2
    cpuset: 12-15
    labels:
      caddy_1: "example.com"
      [e-mail]: "local-ip-whitelist"
      [e-mail]: "example.com"
      caddy_1.handle: "@forgejo"
      caddy_1.handle.reverse_proxy: "{{upstreams 80}}"
      caddy_2.layer4.:[e-mail]:
      caddy_2.layer4.:[e-mail]_ip: "192.168.0.0/16"
      caddy_2.layer4.:22.route: "@forgejo-ssh"
      caddy_2.layer4.:22.route.proxy: "{{upstreams 22}}"
      net.unraid.docker.icon: https://avatars.githubusercontent.com/u/118922216?s=200&v=4
      net.unraid.docker.managed: ansible
      net.unraid.docker.shell: /bin/bash

networks:
  internal:
    name: forgejo-overlay
    external: true
  ingress:
    name: swarm-overlay
    external: true

Daarbij vind ik het echt heel fijn dat dit dynamisch uitgerold wordt. Dat verminderd de beheerlast met bijvoorbeeld een tool zoals Nginx Proxy Manager aanzienlijk.

Bij een push of pull request (update) wordt er automatisch een Forgejo workflow getriggerd. Dit gebeurd standaard als dry-run om in ieder geval het playbook te kunnen test. En afhankelijk van de applicatie wordt er bij een merge naar de hoofdbranch een daadwerkelijke uitrol gedaan. Dus ook bij applicatie updates. Zo'n workflow triggered dan een Ansible playbook die vervolgens na template actie(s) een Docker Compose Up doet op de target machine. Waarbij ik Docker Compose tevens manage via Ansible, Forgejo (Actions) en Renovate .

Grootste project waar ik momenteel nog mee bezig ben is het SSO migreren naar Pocket ID. Dat heeft alleen niet bijster veel met Docker te maken .

Interessante post om te lezen. Coole setup! Ik was in eerste instantie wel verward hoe je Watchtower had "vervangen" door Renovate. Maar als ik het goed begrijp kickt je pipeline een Ansible playbook af die de daadwerkelijke update doet op je Docker host. Dus het is meer de samenwerking tussen Renovate en Ansible die dan het stukje Watchtower vervangt.

Ik ben zelf tegenwoordig wel meer van het eenvoudig te houden. Dus ik laat Renovate lekker gaan, Gitlab CI/CD publisht de image dan naar een container registry. Vervolgens draait Watchtower om de zoveel uur om de update binnen te trekken. Good ol' polling.

[alex3305]

orvintax schreef op dinsdag 1 april 2025 @ 14:57:
[...]

Interessante post om te lezen. Coole setup! Ik was in eerste instantie wel verward hoe je Watchtower had "vervangen" door Renovate. Maar als ik het goed begrijp kickt je pipeline een Ansible playbook af die de daadwerkelijke update doet op je Docker host. Dus het is meer de samenwerking tussen Renovate en Ansible die dan het stukje Watchtower vervangt.

Misschien omdat ik wat teveel in de materie zit, dat ik wellicht over wat details heen ben gevlogen . Eerder controleerde Watchtower (bij mij) iedere dag of er updates voor containers waren. Ik had per Docker Compose stack een aparte Watchtower container draaien zodat dit proces nog enigszins beheersbaar was. Echter gaf het me totaal geen inzicht welke versie nu waar draaide.

Tegelijkertijd beheer(de) ik mijn Docker Compose stacks met Dockge. De Docker Compose stacks kopieerde ik bij aanpassingen handmatig in Dockge. De eerste stap die ik heb gemaakt is om deze met Ansible automatisch over te zetten. Ik gebruikte hiervoor de onderstaande Ansible playbook:

YAML:

- name: Deploy Docker Compose
  hosts: docker

  tasks:
    - name: Ensure remote directories
      ansible.builtin.file:
        path: "/opt/appdata/dockge/stacks/{{ item.path }}"
        state: directory
        mode: "0755"
        owner: "nobody"
        group: "nogroup"
      with_community.general.filetree: "{{ inventory_dir }}/compose/{{ inventory_hostname }}/"
      when: item.state == 'directory'

    - name: Copy regular files
      ansible.builtin.copy:
        src: "{{ item.src }}"
        dest: "/opt/appdata/dockge/stacks/{{ item.path }}"
        mode: "0644"
        owner: "nobody"
        group: "nogroup"
      with_community.general.filetree: "{{ inventory_dir }}/compose/{{ inventory_hostname }}/"
      when: item.state == 'file' and (item.src | splitext | last) != '.j2'

    - name: Template Jinja .j2 files
      ansible.builtin.template:
        src: "{{ item.src }}"
        dest: "/opt/appdata/dockge/stacks/{{ item.path | splitext | first }}"
        mode: "0644"
        owner: "nobody"
        group: "nogroup"
      with_community.general.filetree: "{{ inventory_dir }}/compose/{{ inventory_hostname }}/"
      when: item.state == 'file' and (item.src | splitext | last) == '.j2'

Voor dit voorbeeld en de leesbaarheid heb ik zoveel mogelijk Ansible-eigen constructies eruit gehaald, maar er zijn slimmere manieren om bijvoorbeeld paden aan elkaar te plakken.

De directory layout die ik dan gebruikte was:

┌── compose
│   └── hostnameA/
│       └── adguard_home/
│           └── compose.yaml
│       └── home_assistant/
│           └── compose.yaml
│           └── .env
│   └── hostnameB/
│       └── adguard_home/
│           └── compose.yaml
│       └── zigbee2mqtt/
│           └── compose.yaml
│           └── .env.j2

Dat was voor mij al een enorme verbetering omdat ik hiermee in ieder geval de Compose bestanden niet meer handmatig - en dus foutgevoelig - in hoefde te voeren. Je zou zelfs de onderste stap weg kunnen laten en alleen kopiëren. Ook dat verminderd de complexiteit aanzienlijk.

Je zou dit ook met Forgejo, Gitea of GitLab CI en zoiets als scp kunnen doen. Ik heb vooral Ansible gekozen vanwege het Jinja templaten. En vanaf hier was Renovate eigenlijk een paar kleine stappen.

1. Als eerste heb ik een Renovate user aangemaakt genaamd renovate-bot met hetzelfde e-mailadres als in de configuratie hieronder. Je mag dit zelf kiezen .

2. Voor deze user heb ik een repo aangemaakt genaamd renovate-config.
In die repo zit een secret genaamd RENOVATE_TOKEN en dat is een Personal Access Token met de permissies conform de Renovate documentatie.

3. Ik heb een standaard Renovate config aangemaakt genaamd config.js met uiteraard de juiste gegevens / parameters.

JavaScript:

module.exports = {
  platform: 'gitea',
  endpoint: 'https://git.example.com/api/v1/',
  gitAuthor: 'Renovate Bot <[e-mail]>',
  username: 'renovate-bot',
  autodiscover: true,
  onboardingConfig: {
    $schema: 'https://docs.renovatebot.com/renovate-schema.json',
    extends: ['config:recommended']
  },
  optimizeForDisabled: true,
  persistRepoData: true,
}

4. Vervolgens heb ik een workflow aangemaakt in .forgejo/workflows in dezelfde repository met een hele basic workflow:

YAML:

---
name: Renovate

# yamllint disable-line rule:truthy
on:
  schedule:
    - cron: "@daily"
  workflow_dispatch:

jobs:
  renovate:
    runs-on: ubuntu-latest
    container: ghcr.io/renovatebot/renovate:39.229.0
    steps:
      - uses: actions/checkout@v4
      - run: renovate
        env:
          RENOVATE_CONFIG_FILE: "config.js"
          LOG_LEVEL: "debug"
          RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}

5. En als laatste stap heb ik de renovate-bot toegevoegd aan de repositories waarin ik Renovate wil hebben.

Daarna kon ik een run starten en werkte het... Natuurlijk pakt Renovate geen latest op en moet je zelf eerst de juiste versies intikken. En daarnaast heb ik uiteraard mijn configuratie verder uitgebreid met bijvoorbeeld een dependency dashboard en custom matchers, maar dat hoeft allemaal niet. Daar ben ik ook pas na een maand of anderhalf mee gestart. In ieder geval was ik nu wel af van alle :latest-tags, Watchtower containers (laatste update meer dan 1 jaar geleden!) en had ik transparantie van updates.

Ik ben zelf tegenwoordig wel meer van het eenvoudig te houden. Dus ik laat Renovate lekker gaan, Gitlab CI/CD publisht de image dan naar een container registry. Vervolgens draait Watchtower om de zoveel uur om de update binnen te trekken. Good ol' polling.

Ieder z'n ding . Ik zeg ook niet dat mijn oplossing het einddoel is, maar ik vind het zo verdomd makkelijk werken. En zoals je misschien merkt heb ik me echt verbaasd over de enorm eenvoudige setup.

[Mars Warrior]

Harstikke leuk en luxe @alex3305

Ik doe al mijn 40 containers nog steeds handmatig

Die staan dus iha op vaste versies, en eens in de zoveel tijd kijk ik in de changelog en doe een update. Ik haat namelijk breaking changes

En sommige van mijn containers gebruiken een Ansible playbook intern om de container te initialiseren en te starten: dat is tergend traag, en er worden soms dingen gereset in de config die de container kapot maken.

Andere containers draaien wel in docker, maar zijn feitelijk old-school: je moet bij een upgrade òf een upgrade container draaien voor de nieuwe versie, òf handmatig een backup maken en later weer importeren.

En Yep, betaalde legacy software die nooit gebouwd is voor docker

Ik heb ook nog steeds één compose file. Soms handig, en soms niet. Ik zou dit wel in aparte stacks willen onderbrengen, maar er zijn dikke afhankelijkheden onderling.

[Airw0lf]

Op dit moment gebruik ik op elke docker host een aantal docker-cli scripts om (handmatig) containers te starten. Deze worden wekelijks door watchtower bijgewerkt naar de laatste versie.

Dit zou ik willen automatiseren/verbeteren. Het idee is om te werken met een centrale repository waarin ik per docker host kan aangeven welke containers er gestart moeten worden en met welke parameters. Vervolgens wordt er "iets" aangemaakt en gestart. Bijvoorbeeld in de vorm van een docker compose bestand.

Parallel hieraan loopt er wekelijks een update proces - dat mag watchtower zijn. Maar een wekelijkse compose-down en up is ook prima.

Van deze acties zou ik graag een dashboard hebben waarin is te zien wat de status is van elke container, wat het versienummer is, of er een nieuwere versie is en wat het resultaat is geweest van de laatste 3 update/upgrade acties.

Iemand een idee wat hiervoor een handige aanpak/marsroute is?

[Sp33dFr34k]

Mars Warrior schreef op dinsdag 1 april 2025 @ 16:43:
Harstikke leuk en luxe @alex3305

Ik doe al mijn 40 containers nog steeds handmatig

Die staan dus iha op vaste versies, en eens in de zoveel tijd kijk ik in de changelog en doe een update. Ik haat namelijk breaking changes

En sommige van mijn containers gebruiken een Ansible playbook intern om de container te initialiseren en te starten: dat is tergend traag, en er worden soms dingen gereset in de config die de container kapot maken.

Andere containers draaien wel in docker, maar zijn feitelijk old-school: je moet bij een upgrade òf een upgrade container draaien voor de nieuwe versie, òf handmatig een backup maken en later weer importeren.

En Yep, betaalde legacy software die nooit gebouwd is voor docker

Ik heb ook nog steeds één compose file. Soms handig, en soms niet. Ik zou dit wel in aparte stacks willen onderbrengen, maar er zijn dikke afhankelijkheden onderling.

Niets mis mee toch, ik zit ook rond de 40 containers, en doe ze ook handmatig

Eerst zat ik met Watchtower continue automatisch te updaten, wat weleens iets brak en dan is het moeilijk terug te herleiden. Nu reserveer ik 1 keer in de maand een uurtje, met 3 commando's heb je weer alles up-to-date. Effe snel checken of er niets kapot is en weer door. Ik vind het prima zo.

[alex3305]

Mars Warrior schreef op dinsdag 1 april 2025 @ 16:43:
Ik doe al mijn 40 containers nog steeds handmatig

Hey, ook niets mis mee. Zolang het werkt is het niet dom .

Die staan dus iha op vaste versies, en eens in de zoveel tijd kijk ik in de changelog en doe een update. Ik haat namelijk breaking changes

Same here. Dat vind denk ik niemand echt leuk . Misschien val ik in herhaling, maar mijn huidige workflow geeft me dus grip op veranderingen. Ik heb momenteel automerge aanstaan voor patches en minors, behalve bij packages die CalVer gebruiken. Maar dat hoeft natuurlijk niet, dan krijg je van Renovate namelijk alleen een PR die je handmatig kunt mergen. Renovate werkt deze tevens bij bij updates. Je kunt tevens configureren dat Renovate automatisch de changelog in het PR toevoegt:



Wederom is dit relatief eenvoudig in te stellen. Ook kun je kiezen voor een minimumReleaseAge zodat je minder snel opgezadeld wordt met een verkeerde release.

Ik heb ook nog steeds één compose file. Soms handig, en soms niet. Ik zou dit wel in aparte stacks willen onderbrengen, maar er zijn dikke afhankelijkheden onderling.

Je kunt dit tegenwoordig ook opsplitsen met include(s). Misschien nog interessant voor jou?

[alex3305]

@Airw0lf Ansible en Ansible Tower zou je kunnen gebruiken, maar eerlijk gezegd vind ik dat nogal overkill en Ansible Tower is niet heel eenvoudig om op te zetten . Of te gebruiken .

Ik ben echt te spreken over mijn Forgejo en Forgejo Runner combinatie, dat heb volgens mij al duidelijk gemaakt . Hiervoor had ik Gitea en Gitea Runner en dat werkt niet zo goed. Ik ben met name overgestapt omdat ik wat meer ontwikkeling bij Forgejo zag. GitLab CI werkt ook prima, maar Gitlis wat resource intensief. TeamCity heb ik professioneel ervaring mee en is relatief eenvoudig in gebruik, maar ook een draak om mee te starten.

Het geeft me in ieder geval wel het deploy inzicht:


Alleen mis ik nog een overzicht van huidige versienummers. Daar heb ik al kort naar gekeken, maar was niet heel voor de hand liggend om op te zetten. Dat staat dus nog op de todo.

Verder vind ik mijn setup en repo layout enorm overzichtelijk, ik heb voor applicaties netjes een playbook, bijvoorbeeld van Home Assistant:

YAML:

---
- name: Deploy Home Assistant
  hosts: docker

  roles:
    - role: mosquitto
      tags: [infra, mqtt]
      when: inventory_hostname == 'leetower'

    - role: esphome
      tags: [app, home_automation]
      when: inventory_hostname == 'leetower'

    - role: home_assistant
      tags: [app, home_automation, hub]
      when: inventory_hostname == 'leetower'

    - role: zigbee2mqtt
      tags: [app, home_automation, zigbee]
      when: inventory_hostname == 'brickhouse'

    - role: zwavejs
      tags: [app, home_automation, zwave]
      when: inventory_hostname == 'brickhouse'

Per playbook heb ik dan tevens een vars bestand met daarin de relevante variabelen. Bijvoorbeeld:

YAML:

home_assistant_database_name: homeassistant
home_assistant_database_username: homeassistant
home_assistant_database_password: "{{ vault_home_assistant_database_username }}"

En dan uiteraard een Ansible vault bestand met daarin de secrets. Het wachtwoord daarvan staat tevens in Forgejo als secret, waardoor ik

Voor iets kant-en-klaar en een echt dashboard hiervoor zou je eventueel nog kunnen kijken naar Whats Up Docker. Maar zelf vond ik dat niet prettig werken toen ik dat een hele tijd geleden uitprobeerde.

[Yarisken]

Boys, ik draai een stuk of 30 docker containers met gewoon standaard netwerk dus gebruik makend van het ip van de server.
Ik loop soms tegen zaken aan dat bepaalde poorten hard coded in een docker container zitten zoals bv poort 8080.en deze poort is al in gebruik door een andere docker container.
Om dit te vermijden was ik aan het denken om docker macvlan te gaan gebruiken zodat elke docker container zijn eigen ip gaat hebben . Ik heb nog genoeg interne ip adressen over.

Ik heb er zelf geen ervaring mee dus mijn vraag is of docker macvlan ook nadelen heeft ?

[Mars Warrior]

Yarisken schreef op woensdag 2 april 2025 @ 17:23:
Boys, ik draai een stuk of 30 docker containers met gewoon standaard netwerk dus gebruik makend van het ip van de server.
Ik loop soms tegen zaken aan dat bepaalde poorten hard coded in een docker container zitten zoals bv poort 8080.en deze poort is al in gebruik door een andere docker container.
Om dit te vermijden was ik aan het denken om docker macvlan te gaan gebruiken zodat elke docker container zijn eigen ip gaat hebben . Ik heb nog genoeg interne ip adressen over.

Ik heb er zelf geen ervaring mee dus mijn vraag is of docker macvlan ook nadelen heeft ?

Macvlan kan, heeft elke container zijn eigen adres.

Ik heb alles achter Caddy zitten, dan maakt het niet uit als tig containers op dezelfde poort zitten.

Verder kun je toch altijd een poort mappen, dus dit probleem bestaat toch niet?

[Yarisken]

Mars Warrior schreef op woensdag 2 april 2025 @ 17:26:
[...]

Macvlan kan, heeft elke container zijn eigen adres.

Ik heb alles achter Caddy zitten, dan maakt het niet uit als tig containers op dezelfde poort zitten.

Verder kun je toch altijd een poort mappen, dus dit probleem bestaat toch niet?

Wat bedoel je met poort mappen ? In de docker-compose kan ik de poorten aanpassen maar dit lukt niet voor alle docker-containers.
Dus stel dat er in de compose file 8080 staat verander ik dit in 8081 maar als ik dan de container start via docker-compose -d zodat ik output zie dan start de container met poort 8080 ipv 8081.

[Mars Warrior]

Yarisken schreef op woensdag 2 april 2025 @ 17:36:
[...]


Wat bedoel je met poort mappen ? In de docker-compose kan ik de poorten aanpassen maar dit lukt niet voor alle docker-containers.
Dus stel dat er in de compose file 8080 staat verander ik dit in 8081 maar als ik dan de container start via docker-compose -d zodat ik output zie dan start de container met poort 8080 ipv 8081.

Het mappen van een interne naar een port op de host.

Zie: https://docs.docker.com/g...ports/#use-docker-compose

Dus in docker compose staat dan iets van het volgende om de docker poort 8080 te mappen naar 8081 op de host.

YAML:

ports:
  - 8081:8080

[ Voor 4% gewijzigd door Mars Warrior op 02-04-2025 17:41 ]

[Yarisken]

Mars Warrior schreef op woensdag 2 april 2025 @ 17:40:
[...]

Het mappen van een interne naar een port op de host.

Zie: https://docs.docker.com/g...ports/#use-docker-compose

Dus in docker compose staat dan iets van het volgende om de docker poort 8080 te mappen naar 8081 op de host.

YAML:

ports:
  - 8081:8080

Ja dat werkt ! Hartelijk bedankt, ik kan weer verder zonder alles te herconfigureren in macvlan

[Mars Warrior]

Yarisken schreef op woensdag 2 april 2025 @ 17:46:
[...]
Ja dat werkt ! Hartelijk bedankt, ik kan weer verder zonder alles te herconfigureren in macvlan

Mooi. Heb je weer wat geleerd wat je een hoop werk scheelt

[RobertMe]

Yarisken schreef op woensdag 2 april 2025 @ 17:23:
Boys, ik draai een stuk of 30 docker containers met gewoon standaard netwerk dus gebruik makend van het ip van de server.
Ik loop soms tegen zaken aan dat bepaalde poorten hard coded in een docker container zitten zoals bv poort 8080.en deze poort is al in gebruik door een andere docker container.
Om dit te vermijden was ik aan het denken om docker macvlan te gaan gebruiken zodat elke docker container zijn eigen ip gaat hebben . Ik heb nog genoeg interne ip adressen over.

Ik heb er zelf geen ervaring mee dus mijn vraag is of docker macvlan ook nadelen heeft ?

Je informatie is nogal karig. Standaard zou dan een bridge netwerk gebruikt worden, en dan kun je een port mapping gebruiken zoals @Mars Warrior aangeeft. Maar ik associeer je probleem met dat je wellicht overal network mode host gebruikt, en uberhaupt geen "isolatie" toepast? En dan is er niet direct een oplossing buiten iets anders gebruiken v.w.b. "netwerk".

En laatste optie is dan zoals @Mars Warrior aangeeft in ieder geval alle applicaties met een webserver (/die je via een brower benaderd) achter een reverse proxy te zetten en uberhaupt niet de poort open te zetten. Enqua reverse proxy is er keuze genoeg. Traefik, Caddy, Nginx proxy manager (NPM), ....

[alex3305]

@Yarisken Ik kan je wel aanraden om ipvlan te gebruiken ipv macvlan. De verschillen zijn subtiel, maar het is wat makkelijker te configureren en te beheren.

Alles omgooien valt, gelukkig, ook wel weer mee. In mijn standaard netwerkconfiguratie zonder VLAN's was het aanmaken redelijk triviaal:

docker network create -d ipvlan \
    --subnet=192.168.1.0/24 \
    --gateway=192.168.1.1 \
	-o parent=enp3s0 br0

Waarbij enp3s0 mijn primaire netwerkinterface is. Deze kun je eventueel vinden met ip link show. Waarna ik het kan gebruiken vanuit Compose met:

YAML:

services:
  home-assistant:
    image: ghcr.io/home-assistant/home-assistant:2025.3.4
    networks:
      ipvlan:
        ipv4_address: 192.168.1.3
    volumes:
      - /opt/homeassistant/config:/config
      - /etc/localtime:/etc/localtime:ro

networks:
  ipvlan:
    name: br0
    external: true

Let wel op dat hiermee de ipvlan configuratie in dezelfde range zit als de DHCP en theoretisch dus ip conflicten kan veroorzaken. In mijn DHCP server heb ik daarom de range ingesteld vanaf .50 en wijs ik de IP adressen met de hand toe.

De oplossing die @Mars Warrior voordraagt is overigens wel vele malen beter. Immers heb je dan een single point of entry en geeft je dus veel meer controle.

[orvintax]

alex3305 schreef op dinsdag 1 april 2025 @ 16:12:
[...]

Misschien omdat ik wat teveel in de materie zit, dat ik wellicht over wat details heen ben gevlogen . Eerder controleerde Watchtower (bij mij) iedere dag of er updates voor containers waren. Ik had per Docker Compose stack een aparte Watchtower container draaien zodat dit proces nog enigszins beheersbaar was. Echter gaf het me totaal geen inzicht welke versie nu waar draaide.

Tegelijkertijd beheer(de) ik mijn Docker Compose stacks met Dockge. De Docker Compose stacks kopieerde ik bij aanpassingen handmatig in Dockge. De eerste stap die ik heb gemaakt is om deze met Ansible automatisch over te zetten. Ik gebruikte hiervoor de onderstaande Ansible playbook:

YAML:

- name: Deploy Docker Compose
  hosts: docker

  tasks:
    - name: Ensure remote directories
      ansible.builtin.file:
        path: "/opt/appdata/dockge/stacks/{{ item.path }}"
        state: directory
        mode: "0755"
        owner: "nobody"
        group: "nogroup"
      with_community.general.filetree: "{{ inventory_dir }}/compose/{{ inventory_hostname }}/"
      when: item.state == 'directory'

    - name: Copy regular files
      ansible.builtin.copy:
        src: "{{ item.src }}"
        dest: "/opt/appdata/dockge/stacks/{{ item.path }}"
        mode: "0644"
        owner: "nobody"
        group: "nogroup"
      with_community.general.filetree: "{{ inventory_dir }}/compose/{{ inventory_hostname }}/"
      when: item.state == 'file' and (item.src | splitext | last) != '.j2'

    - name: Template Jinja .j2 files
      ansible.builtin.template:
        src: "{{ item.src }}"
        dest: "/opt/appdata/dockge/stacks/{{ item.path | splitext | first }}"
        mode: "0644"
        owner: "nobody"
        group: "nogroup"
      with_community.general.filetree: "{{ inventory_dir }}/compose/{{ inventory_hostname }}/"
      when: item.state == 'file' and (item.src | splitext | last) == '.j2'

Voor dit voorbeeld en de leesbaarheid heb ik zoveel mogelijk Ansible-eigen constructies eruit gehaald, maar er zijn slimmere manieren om bijvoorbeeld paden aan elkaar te plakken.

De directory layout die ik dan gebruikte was:

┌── compose
│   └── hostnameA/
│       └── adguard_home/
│           └── compose.yaml
│       └── home_assistant/
│           └── compose.yaml
│           └── .env
│   └── hostnameB/
│       └── adguard_home/
│           └── compose.yaml
│       └── zigbee2mqtt/
│           └── compose.yaml
│           └── .env.j2

Dat was voor mij al een enorme verbetering omdat ik hiermee in ieder geval de Compose bestanden niet meer handmatig - en dus foutgevoelig - in hoefde te voeren. Je zou zelfs de onderste stap weg kunnen laten en alleen kopiëren. Ook dat verminderd de complexiteit aanzienlijk.

Je zou dit ook met Forgejo, Gitea of GitLab CI en zoiets als scp kunnen doen. Ik heb vooral Ansible gekozen vanwege het Jinja templaten. En vanaf hier was Renovate eigenlijk een paar kleine stappen.

1. Als eerste heb ik een Renovate user aangemaakt genaamd renovate-bot met hetzelfde e-mailadres als in de configuratie hieronder. Je mag dit zelf kiezen .

2. Voor deze user heb ik een repo aangemaakt genaamd renovate-config.
In die repo zit een secret genaamd RENOVATE_TOKEN en dat is een Personal Access Token met de permissies conform de Renovate documentatie.

3. Ik heb een standaard Renovate config aangemaakt genaamd config.js met uiteraard de juiste gegevens / parameters.

JavaScript:

module.exports = {
  platform: 'gitea',
  endpoint: 'https://git.example.com/api/v1/',
  gitAuthor: 'Renovate Bot <[e-mail]>',
  username: 'renovate-bot',
  autodiscover: true,
  onboardingConfig: {
    $schema: 'https://docs.renovatebot.com/renovate-schema.json',
    extends: ['config:recommended']
  },
  optimizeForDisabled: true,
  persistRepoData: true,
}

4. Vervolgens heb ik een workflow aangemaakt in .forgejo/workflows in dezelfde repository met een hele basic workflow:

YAML:

---
name: Renovate

# yamllint disable-line rule:truthy
on:
  schedule:
    - cron: "@daily"
  workflow_dispatch:

jobs:
  renovate:
    runs-on: ubuntu-latest
    container: ghcr.io/renovatebot/renovate:39.229.0
    steps:
      - uses: actions/checkout@v4
      - run: renovate
        env:
          RENOVATE_CONFIG_FILE: "config.js"
          LOG_LEVEL: "debug"
          RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}

5. En als laatste stap heb ik de renovate-bot toegevoegd aan de repositories waarin ik Renovate wil hebben.

Daarna kon ik een run starten en werkte het... Natuurlijk pakt Renovate geen latest op en moet je zelf eerst de juiste versies intikken. En daarnaast heb ik uiteraard mijn configuratie verder uitgebreid met bijvoorbeeld een dependency dashboard en custom matchers, maar dat hoeft allemaal niet. Daar ben ik ook pas na een maand of anderhalf mee gestart. In ieder geval was ik nu wel af van alle :latest-tags, Watchtower containers (laatste update meer dan 1 jaar geleden!) en had ik transparantie van updates.


[...]

Ieder z'n ding . Ik zeg ook niet dat mijn oplossing het einddoel is, maar ik vind het zo verdomd makkelijk werken. En zoals je misschien merkt heb ik me echt verbaasd over de enorm eenvoudige setup.

Cool! Was verder ook geen kritiek, is meer mijn eigen mening/voorkeur. Ik kom er nu ook pas achter dat Watchtower een beetje dood lijkt te zijn qua maintainers. Verder vind ik het ook een goede dat je Renovate laat comitten met de Renovate Bot gegevens. Bij mij is dit nu nog gewoon mijn persoonlijke account. Maar nu zie ik er wel als heel actieve developer uit.

[Airw0lf]

Mars Warrior schreef op woensdag 2 april 2025 @ 17:40:
[...]

Het mappen van een interne naar een port op de host.

Zie: https://docs.docker.com/g...ports/#use-docker-compose

Dus in docker compose staat dan iets van het volgende om de docker poort 8080 te mappen naar 8081 op de host.

YAML:

ports:
  - 8081:8080

Als aanvulling: dit werkt alleen voor netwerk type bridge - niet voor netwerk type host.

[Yarisken]

Bedankt voor de tip Alex.
Mijn dhcp begint vanaf 192.168.0.100 dus alles daaronder kan ik statisch gebruiken.
Ik ga er is mee testen.
Ik ga ook is kijken naar een reverse proxy. Nog nooit mee gespeeld.

[alex3305]

orvintax schreef op woensdag 2 april 2025 @ 22:23:
Cool! Was verder ook geen kritiek, is meer mijn eigen mening/voorkeur.

Zo pakte ik het ook niet op . Maar ik weet van mezelf dat ik soms wat snel kan gaan. Vooral als ik enthousiast ben . Dan mis ik nogal eens wat details die wellicht voor mij voor de hand liggend zijn.

Ik kom er nu ook pas achter dat Watchtower een beetje dood lijkt te zijn qua maintainers. Verder vind ik het ook een goede dat je Renovate laat comitten met de Renovate Bot gegevens. Bij mij is dit nu nog gewoon mijn persoonlijke account. Maar nu zie ik er wel als heel actieve developer uit.

Op zichzelf hoeft het natuurlijk niet zo'n probleem te zijn als een project maar werkt. Maar ik vind het bij Watchtower toch wel een risico. Het is toch een container die (waarschijnlijk) toegang heeft tot de Docker socket en daarmee dus feitelijk ook beheerrechten heeft. Ik heb daar dan toch ook niet zo'n denderend gevoel over. Vooral niet als het project dan dood lijkt .

Om de Docker labels vanuit Caddy uit te lezen gebruik ik bijvoorbeeld ook Docker Socket Proxy zodat ik enerzijds het gevoel heb wat toegangscontrole toe te passen en anderzijds zodat ik de Docker socket van andere systemen zo eenvoudig kan benaderen. Een waarom een gevoel? Omdat het ook weer een extern stukje software is.

[alex3305]

Yarisken schreef op woensdag 2 april 2025 @ 23:51:
Bedankt voor de tip Alex.
Mijn dhcp begint vanaf 192.168.0.100 dus alles daaronder kan ik statisch gebruiken.
Ik ga er is mee testen.

Als je gaat testen heb je de poortmapping zoals @Airw0lf boven aangeeft dus ook niet meer nodig. Het is immers analoog aan een host network maar dan met een eigen ip.

Ik ga ook is kijken naar een reverse proxy. Nog nooit mee gespeeld.

Mooi om te starten is Nginx Proxy Manager als je graag een GUI wilt of Caddy als je wat meer comfortabel bent met configuratiebestanden.

Het prettige van een reverse proxy is dat je dan op één plek TLS termination kunt doen voor je domeinnaam, bijvoorbeeld met Let's Encrypt. Daarnaast kun je onder water aanpassingen maken aan de configuratie terwijl het endpoint gelijk blijft. Toen ik bijvoorbeeld van poort mapping in het bridge netwerk naar ipvlan migreerde, merkte ik daar niets van. Uiteindelijk bleef (bijvoorbeeld) de url nog steeds: home.example.com. In de reverse proxy ging echter de toewijzing van (pseudo-code):

Diff:

home.example.com {
-   reverse_proxy http://192.168.1.2:8084
+   reverse_proxy http://192.168.1.40:8123
}

En idem toen ik van ipvlan naar een intern Docker (Swarm) overlay netwerk ging:

Diff:

home.example.com {
-   reverse_proxy http://192.168.1.40:8123
+   reverse_proxy http://10.0.4.47:8123
}

Dat zorgt er ook voor dat je geen IP + poortmapping meer hoeft te onthouden, maar simpelweg naar een URL kunt surfen . Dat zorgt ook voor een stukje gemoedsrust. Vanuit daar kun je dan ook bouwen aan bijvoorbeeld authenticatie en autorisatie wanneer dat gewenst is.

[Zenyatta]

Heb op mijn NAS (DS920+) de instructies gevolgd van Mariushosting om Navidrome te installeren. Dat lijkt goed gegaan, behalve dan dat Navidrome geen muziek kan vinden. Hij lijkt niets te zoeken en dus ook geen muziek te kunnen inladen. Iemand een idee of ik dan verkeerd heb geinstalleerd, of dat ik ergens een obvious fout heb gemaakt? Ben niet heel goed thuis in de dockers etc. maar kom ook niet helemaal uit een ei.

Mijn doel is om via een andere muziekspeler dan DS Music mijn muziek te spelen, want DS Music is kortgezegd gewoon ruk. Loopt vaak vast en is niet werkbaar met Android Auto. Dus mijn muziek moet op een andere manier dan dat...

[alex3305]

@Zenyatta Ik denk dat het handig is als je ook even je configuratie deelt .

[Zenyatta]

@alex3305 , wat bedoel je precies?

Heb met de volgende code geinstalleerd:
services:
navidrome:
container_name: Navidrome
image: deluan/navidrome
mem_limit: 6g
cpu_shares: 1024
security_opt:
- no-new-privileges:true
restart: on-failure:5
ports:
- 4533:4533
volumes:
- /volume1/docker/navidrome:/data:rw
- /volume1/pad/naar/muziek:rw
environment:
PUID: 1024
PGID: 100
ND_ENABLEINSIGHTSCOLLECTOR: false

En eerder ook al via deze instructie maar met hetzelfde resultaat:

[Ghoulli]

Navidrome is eigenlijk niks anders dan een programma wat de muziek voor je af kan spelen. Als je al muziek op jouw server hebt staan hoef jij alleen de map van jouw muziek te mappen. Dit kan, volgens mij, Navidrome niet uit zichelf. Hier heb je wat andere, extra dingen voor nodig.

Zo als volgt:
Lidarr - De backbone van de gehele operatie. In Lidarr kun je zoeken naar verschillende artiesten en albums en deze toevoegen aan jouw library. Om de files om te downloaden te vinden heeft Lidarr een Indexer nodig. Deze Indexer, in mijn geval voor Usenet maar kan ook een torrent indexer zijn, moet toegevoegd worden in Lidarr.

Indexer - De Indexer is niks anders dan een groot telefoonboek waarin alle mensen staan die voor jou het album of de artiest hosten naar het internet.

Nadat de Indexer aan Lidarr is toegevoegd moet je een download client hebben. Dit kan NZBGet zijn voor Usenet of qBittorrent voor Torrents. Torrents zijn makkelijker, daar hoef je verder niks voor in te stellen. Bij Usenet (NZBGet) werkt het als volgt: Je hebt een News-server nodig. Deze News-Server vist voor jou de bestanden van het Usenet en plaatst deze in jouw download client, waardoor jij ze vervolgens ook kunt downloaden. Een News-server wordt ook wel een Provider genoemd.

Nadat de bestanden gedownload zijn van de Provider worden deze geplaatst in een map zoals aangegeven in Lidarr. Deze map koppel je aan Navidrome (/pad/naar/muziek) en dan kun je via Navidrome naar je muziek luisteren.

[gijpie]

- /volume1/pad/naar/muziek:rw

Heb je dit aangepast naar het daadwerkelijke pad naar je muziek? Buiten dat map je volgens mij naar niks in je docker container :rw geeft alleen aan read/write. Daar moet ook nog iets als een pad in de container staan.

Eigenlijk zou er iets als volgt moeten staan: /path/to/your/music/folder:/music:rw Waar alles voor de dubbele punt het pad naar je muziekfiles op de NAS moet zijn en alles na de dubbele punt het pad in de container.

Zoiets dus: - /volume1/docker/navidrome/mijn_muziek:/music:rw

Zet je muziek dan in de mijn_muziek map en bij de instellingen in Navidrome selecteer je als bestandslokatie /music

Voor Android kies je een subsonic client zoals bijvoorbeeld substreamer

[ Voor 20% gewijzigd door gijpie op 07-05-2025 00:28 . Reden: android client toegevoegd ]

[Zenyatta]

Ghoulli schreef op dinsdag 6 mei 2025 @ 22:54:
Navidrome is eigenlijk niks anders dan een programma wat de muziek voor je af kan spelen. Als je al muziek op jouw server hebt staan hoef jij alleen de map van jouw muziek te mappen. Dit kan, volgens mij, Navidrome niet uit zichelf. Hier heb je wat andere, extra dingen voor nodig.

Zo als volgt:
Lidarr - De backbone van de gehele operatie. In Lidarr kun je zoeken naar verschillende artiesten en albums en deze toevoegen aan jouw library. Om de files om te downloaden te vinden heeft Lidarr een Indexer nodig. Deze Indexer, in mijn geval voor Usenet maar kan ook een torrent indexer zijn, moet toegevoegd worden in Lidarr.

Indexer - De Indexer is niks anders dan een groot telefoonboek waarin alle mensen staan die voor jou het album of de artiest hosten naar het internet.

Nadat de Indexer aan Lidarr is toegevoegd moet je een download client hebben. Dit kan NZBGet zijn voor Usenet of qBittorrent voor Torrents. Torrents zijn makkelijker, daar hoef je verder niks voor in te stellen. Bij Usenet (NZBGet) werkt het als volgt: Je hebt een News-server nodig. Deze News-Server vist voor jou de bestanden van het Usenet en plaatst deze in jouw download client, waardoor jij ze vervolgens ook kunt downloaden. Een News-server wordt ook wel een Provider genoemd.

Nadat de bestanden gedownload zijn van de Provider worden deze geplaatst in een map zoals aangegeven in Lidarr. Deze map koppel je aan Navidrome (/pad/naar/muziek) en dan kun je via Navidrome naar je muziek luisteren.

Maar Navidrome hoeft alleen de map met muziek te lezen en vervolgens te zorgen dat ik die elders af kan spelen. Downloaden is niet nodig, want de muziek staat al op mijn server.

gijpie schreef op woensdag 7 mei 2025 @ 00:18:
[...]


Heb je dit aangepast naar het daadwerkelijke pad naar je muziek? Buiten dat map je volgens mij naar niks in je docker container :rw geeft alleen aan read/write. Daar moet ook nog iets als een pad in de container staan.

Eigenlijk zou er iets als volgt moeten staan: /path/to/your/music/folder:/music:rw Waar alles voor de dubbele punt het pad naar je muziekfiles op de NAS moet zijn en alles na de dubbele punt het pad in de container.

Zoiets dus: - /volume1/docker/navidrome/mijn_muziek:/music:rw

Zet je muziek dan in de mijn_muziek map en bij de instellingen in Navidrome selecteer je als bestandslokatie /music

Voor Android kies je een subsonic client zoals bijvoorbeeld substreamer

Het pad heb ik aangepast naar de map waar mijn muziek staat opgeslagen. Zal het thuis nog eens nalopen en indien nodig anders instellen.

Via de browser kan ik Navidrome benaderen, daar zou het muziek ook moeten kunnen afspelen. Daar wordt niets gevonden. Substreamer had ik inderdaad al gedownload maar die vind dus vooralsnog ook niets.

Wordt vervolgd.

[gijpie]

Ik heb net nog eens gekeken op https://www.navidrome.org/docs/installation/docker/ en zoals ik begrijp is het default container pad /music en is dit niet aanpasbaar. Als je dit dus (na de dubbele punt) hebt aangepast dan zal Navidrome je muziek collectie niet vinden. Niet aanpassen dus, tenzij je de environment variabele hiervoor aanpast. Laat die toevoeging :rw ook lekker weg. Is niet perse nodig.
Nu er nog voor zorgen dat alles voor de dubbele punt correct is en Navidrome zou gewoon je files moeten vinden. Net zoals Substreamer

Omdat je Navidrome zonder problemen kan benaderen vanuit je browser lijkt de installatie op zich in orde en zit het probleem echt in de mapping van je files.

[Zenyatta]

De clue zat inderdaad in het verwijzen naar mijn mappen. Werkt als een zonnetje nu, in ieder geval op mijn eigen netwerk. Nu nog kijken hoe het buiten mijn netwerk gaat.

[gijpie]

Perfect man.

Volgende stap dan het installeren van een volgende docker container.

Kijk eens naar wg-easy (Wireguard) om een vpn tunnel op te zetten naar je server en zo je bestanden op je lokale ip adres te benaderen. Probleem bij mij is dat Android auto niet echt met een vpn verbinding om kan gaan.

Anders een subdomein registreren op b.v. duckdns (icm b.v. linuxserver/duckdns) en dan een reverse proxy installeren op je Nas bijvoorbeeld nginx proxy manager. Je zal dan wel je poorten 80 en/of 443 open moeten zetten.

Met Wireguard zal je ook een poort moeten openen maar dat is dan udp terwijl nginx een open tcp poort moet hebben.

Leuk om verder te klooien

[FLA NL]

Heb je voor Wireguard geen client waar je alleen Android Auto buiten je vpn verbinding om kan laten gaan? Zo heb ik het voor OpenVPN gedaan.

[ Voor 12% gewijzigd door FLA NL op 08-05-2025 22:08 ]

[gijpie]

Nog niet geprobeerd. Ben in de playstore alleen de officiele WG app tegen gekomen.

Ik los dit nu op met een cloudflare tunnel naar mijn server. Maar ik zal eens kijken wat er verder nog mogelijk is.

Dank je wel.

[Mars Warrior]

Ik zit inmiddels op 47 containers

De laatste aanwinst is Dawarich dat net als Immich Duits is.

Visualize your location history, track your movements, and analyze your travel patterns with complete privacy and control.

Dawarich is ooit begonnen als vervanger van Google Timeline.

Het is net als Immich - hoewel nog jonger - een complete App en goed verzorgt qua instelmogelijkheden en documentatie. Er is ook een iOS app, waarmee je netjes ook automatiseringen kunt instellen zodat bijv. als je je huis verlaat dat de tracking automatisch start en als je thuis komt weer stopt. De Home Assistant App is ook bruikbaar als GPS logger.

Dawarich kan ook foto's uit Immich weergeven op een route. Dat werkt bij mij nog niet lekker. Lijkt erop dat ik een Album ofzo daarvoor moet samenstellen in Immich.

Reverse geo lookup werkt op basis van een Photon container. Ook dat werkt goed. Ik heb nu enkel nl geladen ipv de hele wereld. Die laatste schijnt ca 200GB diskruimte in te nemen. Je kunt op dit ogenblik maar één land kiezen, dus het is 1 of alles

Het zijn totaal 4 containers voor Dawarich en 1 container voor Photon. Het neemt bij mij nu 2GB RAM in volgens de container stats van Portainer.

[ahbart]

gijpie schreef op donderdag 8 mei 2025 @ 22:11:
Nog niet geprobeerd. Ben in de playstore alleen de officiele WG app tegen gekomen.

Ik los dit nu op met een cloudflare tunnel naar mijn server. Maar ik zal eens kijken wat er verder nog mogelijk is.

Dank je wel.

Wg tunnel app werkt heel prettig

[Arosa]

Door de prijs/hardware verhouding onlangs een UGREEN NAS in gebruik genomen, dit heeft zo zijn plus en min-punten. Voor enkele minpunten middels Docker een prima oplossing voor elkaar gekregen, maar nog zoekende naar een goede foto-bibliotheek.

Immich wordt veel aangeraden, maar ik loop vast met mijn foto collectie van de afgelopen 15 jaar. Deze zit in een mappenstructuur en dat ik ik graag zou houden, maar daar is Immich niet op ingericht (schrijft zelfs de ontwikkelaar). Bovendien wil ik deze collectie toegankelijk hebben voor minimaal 2 gebruikers, maar eenvoudig een shared folder toevoegen is er niet bij (lijkt het).

In de ideale wereld wil ik 4 gebruikers hun Android-telefoon laten synchroniseren naar de nas, hier hoeft geen complexe mappenstructuur, in principe is een tijdlijn weergave ala Google Foto's of Immich prima. In principe is ook 1-richtingsverkeer prima, dus als een foto op de telefoon verwijderd wordt, is het prima dat deze op de nas blijft staan. Voor dat verkeer zijn er volgens mij prima apps, zoals Foldersync, daar verwacht ik wel uit te komen.

Maar welke Docker App is nu geschikt om een gedeelde foto bibliotheek (met foto's van de fotocamera) te hebben + een persoonlijke bibliotheek (met telefoonfoto's). En eventueel als bonus nog de optie om gezamenlijke albums te maken, van bijvoorbeeld alle vakantiefoto's?

Ik ken PhotoPrism, PiGallery2, Lychee, Plex Photo's, ... maar welke moet ik nu echt proberen? Of zijn er tips om Immich wel in te richten op de mijn wijze?

[Mars Warrior]

@Arosa je kunt Immich een externe foto bibliotheek laten gebruiken.

Doe ik ook. Dat zijn dus gewoon mappen met jaartallen en daaronder mappen met vakanties enzo.

Werkt gewoon.

[Arosa]

@Mars Warrior :

Kan je een hint geven wat ik verkeerd doe? Best al wat uurtjes gezocht op het internet, maar ik kom niet verder dan dit:

De shared folder krijg ik niet zichtbaar in Immich.

Heb jij ook meerdere gebruikers?

[Mars Warrior]

Arosa schreef op maandag 19 mei 2025 @ 22:48:
@Mars Warrior :

Kan je een hint geven wat ik verkeerd doe? Best al wat uurtjes gezocht op het internet, maar ik kom niet verder dan dit:
[Afbeelding] [Afbeelding] [Afbeelding] [Afbeelding]
De shared folder krijg ik niet zichtbaar in Immich.

Heb jij ook meerdere gebruikers?

Je moet het externe archief definieren.

Dit staat in mijn .env file:

code:

# Read only location of existing archive
EXTERNAL_ARCHIVE=/mnt/pool/Afbeeldingen/Archief

# The location where your uploaded files are stored
UPLOAD_LOCATION=/mnt/pool/Afbeeldingen/Upload

En in mijn compose file voor Immich:

code:

  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    cpuset: $CPUSET_E_CORES_ALL
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - ${EXTERNAL_ARCHIVE}:/usr/src/app/archive
      - /etc/localtime:/etc/localtime:ro

En daarmee ziet Immich je bestaande archief

[Arosa]

Ik heb het voor elkaar gekregen, maar wel op een iets andere wijze:

code:

  volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - ${EXTERNAL_ARCHIVE}:/usr/src/app/archive
      - /volume1/Photos/Archief:/volume1/Photos/Archief:ro
      - /etc/localtime:/etc/localtime:ro

Nog meer verschillende websites geraadpleegd, verschillende oplossingen voorbij zien komen, na meerdere trail&errors tot deze werkende oplossing gekomen.

Ik denk wel dat ik de camera foto's een eigen account ga geven, zodat ik deze wat eenvoudiger aan en uit kan zetten en niet altijd tussen de tijdlijn staan.

[Arosa]

Vanwege de wat beperkte software van Ugreen, was Docker de beste optie om toch alles te kunnen doen.

Ik heb ondertussen de volgende Containers draaien:

• Duplicati
  Gemakkelijk in gebruik te nemen, nu nog een keer testen om zelf te ondervinden hoe betrouwbaar het is.
• Emby
  Net zo makkelijk en werkt prima om een bescheiden dvd-collectie voortaan digitaal te benaderen
• Immich
  Wat problemen gehad om de externe bibliotheek bereikbaar te krijgen, maar ondertussen ook bijna mijn complete collectie mobiele telefoonfoto's 'online'.
• Nginx
  Wat een hoop slechte en onvolledige instructies staan er op internet, dit heeft mij heel wat uurtjes en proberen gekost, maar uiteindelijk met de uitleg van MariusHosting het nu voor elkaar mijn Immich ook buiten de deur te bereiken.

Nu zoek ik nog een tool om eenvoudig verschillende mappen (zonder compressie of versleuteling) naar een usb-schijf te kopiëren (voor mijn eigen gemoedsrust, als extra backup). Iemand nog tips voor een app in Docker? Of kan dat niet?

[Mars Warrior]

Arosa schreef op zondag 25 mei 2025 @ 08:54:
Vanwege de wat beperkte software van Ugreen, was Docker de beste optie om toch alles te kunnen doen.

Ik heb ondertussen de volgende Containers draaien:

• Duplicati
  Gemakkelijk in gebruik te nemen, nu nog een keer testen om zelf te ondervinden hoe betrouwbaar het is.
• Emby
  Net zo makkelijk en werkt prima om een bescheiden dvd-collectie voortaan digitaal te benaderen
• Immich
  Wat problemen gehad om de externe bibliotheek bereikbaar te krijgen, maar ondertussen ook bijna mijn complete collectie mobiele telefoonfoto's 'online'.
• Nginx
  Wat een hoop slechte en onvolledige instructies staan er op internet, dit heeft mij heel wat uurtjes en proberen gekost, maar uiteindelijk met de uitleg van MariusHosting het nu voor elkaar mijn Immich ook buiten de deur te bereiken.

Nginx is ook niet bepaald het meest moderne programma om makkelijk websites te ontsluiten.
Dan is Caddy met de Caddy docker plugin factoren eenvoudiger. Niks geen moeilijke config, geen portmappings nodig en default alles SSL.

Voorbeeld ontsluiten Immich op zijn standaard poort 2283 in de docker compose file:

code:

   labels:
      caddy: immich.mijndomein.nl
      caddy.reverse_proxy: "{{upstreams 2283}}"

Dat is alles om Immich op https://immich.mijndomien.nl te kunnen bereiken

(Vanzelfsprekend moeten de poorten wel opengezet/geforward worden, maar dat is altijd nodig voor IPv4. Voor IPv6 dan weer niet: daar kun je gewoon een IPv6 adres icm poorten gebruiken die je firewall doorlaat)

Nu zoek ik nog een tool om eenvoudig verschillende mappen (zonder compressie of versleuteling) naar een usb-schijf te kopiëren (voor mijn eigen gemoedsrust, als extra backup). Iemand nog tips voor een app in Docker? Of kan dat niet?

Dat klinkt als een min-of-meer standaard Backup programma? Er zal zeker een Docker container voor zijn.

[Airw0lf]

Arosa schreef op zondag 25 mei 2025 @ 08:54:

[...]

Nu zoek ik nog een tool om eenvoudig verschillende mappen (zonder compressie of versleuteling) naar een usb-schijf te kopiëren (voor mijn eigen gemoedsrust, als extra backup). Iemand nog tips voor een app in Docker? Of kan dat niet?

Een cp -R in een cronjob?

[Airw0lf]

dubbele post => verwijderd

[ Voor 130% gewijzigd door Airw0lf op 25-05-2025 10:53 ]

[RobertMe]

Mars Warrior schreef op zondag 25 mei 2025 @ 10:05:
(Vanzelfsprekend moeten de poorten wel opengezet/geforward worden, maar dat is altijd nodig voor IPv4. Voor IPv6 dan weer niet: daar kun je gewoon een IPv6 adres icm poorten gebruiken die je firewall doorlaat)

Hoe noem je dat? Als het blijkbaar niet "open zetten" is? Bij IPv6 is het juist alleen open zetten, bij IPv4 open zetten + een DNAT (destination NAT) regel aanmaken. Maar de meeste consumenten routers zal het gewoon 1 actie zijn. (Als die consumenten router dit al ondersteund bij IPv6. In ieder geval schijnen er nogal wat provider modem/routers te zijn waarbij de firewall gebrekkige IPv6 support heeft en een poort openen/toestaan niet mogelijk is. Terwijl IPv4 port forwards prima mogelijk zijn).

[Mars Warrior]

RobertMe schreef op zondag 25 mei 2025 @ 10:28:
[...]
Hoe noem je dat? Als het blijkbaar niet "open zetten" is? Bij IPv6 is het juist alleen open zetten, bij IPv4 open zetten + een DNAT (destination NAT) regel aanmaken. Maar de meeste consumenten routers zal het gewoon 1 actie zijn. (Als die consumenten router dit al ondersteund bij IPv6. In ieder geval schijnen er nogal wat provider modem/routers te zijn waarbij de firewall gebrekkige IPv6 support heeft en een poort openen/toestaan niet mogelijk is. Terwijl IPv4 port forwards prima mogelijk zijn).

Veel modems noemen het nog steeds "Port Forwarding" om het voor de consument makkelijk te houden.
En qua support: zelfs de stokoude Experia V10 van de KPN ondersteunt dit: gewoon het poortnummer of de service (HTTP, HTTPS, etc) invoeren en je lokale device (drop-down lijst die op je netwerk kijkt voor het bijbehorende IPv6 adres bij dat device/server) selecteren en klaar ben je.

Vanzelfsprekend heb ik vaste IPv6 adressen toegekend aan mijn servers. Ik heb zo'n groot subnet van de KPN dat ik miljoenen servers/devices op mijn adres kan hebben. Vraag me niet waarom KPN zo'n groot subnet (64 bits) uitdeelt, maar goed.

[RobertMe]

Mars Warrior schreef op zondag 25 mei 2025 @ 11:01:
Vanzelfsprekend heb ik vaste IPv6 adressen toegekend aan mijn servers. Ik heb zo'n groot subnet van de KPN dat ik miljoenen servers/devices op mijn adres kan hebben. Vraag me niet waarom KPN zo'n groot subnet (64 bits) uitdeelt, maar goed.

offtopic:
Een /64 is niet groot. Het is maar de helft. En daarnaast is het de verplichte minimale subnet grote. Omdat er binnen IPv6 wat "formules" zijn om een willekeurige suffix te bepalen (op basis van het MAC adres) en dat dus uit gaat van 64 beschikbare bits.

En van KPN krijg je nog meer, je krijgt een /48. En je kunt vervolgens dus nog 16 bits gebruiken om eigen /64 subnets te maken (oftewel 65.536 subnets van /64). Bij Ziggo en veel andere ISPs krijg je dan maar weer een /56, en kun je dus "maar" 256 subnets van /64 groot maken.
Waarbij ook weer is vastgelegd dat /56 de minimale grote moet zijn voor (vaste) aansluitingen. (Op mobiel krijg je normaliter maar een /64, en kun je dus niet subnetten daar onder aanmaken, of in ieder geval als je wilt voldoen aan /64 als minimale subnet grote).

En uiteraard zijn vaste IPv6 adressen op een consumenten lijntje vaak niet echt vast. Immers heb je een dynamische prefix en als die wijzigt heb je een probleem.
Daarom gebruik ik naast de GUA (Globally Unique Address), een link local address ook nog ULA (Unique Local Address, fc00::/7 uit mijn hoofd meen ik dat daarvoor gereserveerd is). Dus bv VLAN 1 gebruikt fd00:1::/64 en VLAN 2 fd00:2::/64 etc. En waar nodig hebben apparaten daar dus echt een statistisch IP adres, onafhankelijk van of Ziggo mij een andere prefix, voor de GUA, geeft.

IPv6 en Docker is echter AFAIK nog steeds wel een dingetje dat wat aandacht verdiend. Zo zou ondersteuning voor DHCPv6-PD zeer welkom zijn. Zodat elke bridge / netwerk ook een pefix kan opvragen bij de DHCP server van de ISP die die dan gebruikt voor het subnet van de bridge (het algoritme om een suffix te genereren om basis van het MAC adres ondersteund die wel. Alleen moet je dus zelf bij het aanmaken van het netwerk ook meteen het subnet (/"prefix") vast leggen, en geeft de ISP je dan een nieuwe prefix moet je dus alle netwerken opnieuw aanmaken .

[Mars Warrior]

Om nog even in te gaan op IPv6 icm Docker en toegang tot containers die het "remote_ip" bepalen

Uitgangssitutatie:

• Al mijn apparaten hebben een vast IPv4 adres. Dat is al jaaaaaaaaaaaaaaaaaaaaaaaaaaaaren zo.
• Verder krijgen ze van de router (ik vermoed via SLAAC / Router Announcements) een IPv6 adres .

Ik heb mij namelijk suf zitten zoeken waarom:

• Sommige containers netjes het externe of lokale IP (altijd IPv4) vastleggen
• Anderen het IPv4 adres van de Docker Gateway van mijn Ingress Netwerk als "remote_ip" bepaalt.
• (meerdere).

Aan die laatste heb ik niks icm Fail2Ban natuurlijk. Besef dat ik Docker nog als IPv4 netwerk draai. IPv6 staat nog niet geenabled/geconfigureerd voor het Ingress Netwerk.

Op het internet is hier veel over te vinden icm Caddy en Docker. Ook ChatGPT vind er wat van, maar behalve een leuke uitleg over IPv6 en hoe je deze in Docker kunt aanzetten, wat ook in de Docker documentatie staat natuurlijk, komt er weinig zinnigs uit. Volgens ChatGPT kan ik namelijk IPv4 en IPv6 mixen

Verder zou Caddy - wederom volgens het almachtige orakel - enkel in "network=host" mode in staat zijn om correct het "X-Forwarded-For" veld in de header te vullen. Caddy zou ik dan achter een proxy moeten zetten zoals HAproxy en dan met het PROXY protocol moeten kletsen om het externe IP door te geven.

Afijn: mogelijk dat dat vroeger zo was met een oude Caddy/Docker versie, maar met de huidige in ieder geval niet, immers een aardig aantal containers krijgt wel degelijk het externe IP adres door van Caddy.
Mogelijk dat dit voor IPv6 wel is (nog niet getest), maar voor IPv4 aantoonbaar niet.

Maar ChatGPT bleef dat mantra volhouden, ondanks dat de feiten anders zijn. Ik denk daarom dat ChatGPT een vrouw is, maar dat terzijde.

Wat is nu het geval (TLDR):

• Als de externe DNS IPv4 only is, dan gaat het altijd goed!
• Als de externe DNS IPv4 én IPv6 adressen geeft, dan gaat het eigenlijk altijd fout: ik krijg het Docker Gateway adres als "remote_ip"

Ik vermoed dat als zowel IPv4 als IPv6 aanwezig is, dat het "moderne internet" voorgaat: er wordt dus gebruik gemaakt van een IPv6 adres.

Het lijkt er dus op dat Docker een "IPv6 -> IPv4 vertaling" doet ofzo en daarmee het gateway adres als "remote_ip" doorgeeft en/of vervangt.

Ik kon dat alleen niet in de documentatie vinden tot nu toe. En het grote boze internet inclusief het orakel ook niet, anders was ik er snel uitgeweest natuurlijk.

Het wordt dus nu testen met IPv6 om te achterhalen of het dan wel goed gaat

[RobertMe]

@Mars Warrior, ik heb geen idee wat nu precies het probleem is / wat je bedoelt?

Maar als ik je goed begrijp (externe IP in services achter Caddy zien een IPv4 adres van de Docker host / gateway van de Docker bridge?) dan lijkt de kans mij zeer groot dat de "docker proxy" (?) op de host draait die luistert op de exposed poort(en) voor IPv6 verkeer (of zelfs alle) en dat verkeer dan 1 op 1 door zet naar het container IP. Waardoor de container dus altijd een verbinding ziet vanaf de Docker host omdat de proxy de verbinding op zet en je dus een TCP verbinding tussen proxy op de host en de software in de container hebt.
Dit is een "techniek" die Docker al eeuwen altijd heeft gehad, als fallback voor als die de firewall niet kan beheren. Dan start die (per port mapping die je gedefinieerd hebt) gewoon een proxy die luistert op de externe poort (+ opgegeven IP als dat het geval is) en stuurt at verkeer 1 op 1 door naar de container (die die exposed port heeft).

En gezien IPv6 bij Docker nogal awkward is, en je bij IPv6 eigenlijk niks met DNAT (/port forwards / destination NAT) wilt doen, zal dit wel de enige optie zijn? Of in ieder geval is dit per definitie de enige optie als je enerzijds extern wilt luisteren op IPv6 en de container alleen IPv4 doet. Immers zijn IPv6 en IPv4 incompatible met elkaar. Je kunt niet een pakketje "herschrijven" naar een "andere bestemming" (DNAT dus) terwijl er een totaal andere IP versie gebruikt wordt. DNAT kan gewoon een veldje in de header aanpassen en klaar. Maar IPv6 en IPv4 zijn incompatible met elkaar, dus kom je uit op "software" die puur de data over zet (een TCP proxy dus).

Wat ik zelf echter doe is...:

1. Überhaupt Docker van mijn firewall af laten blijven (ik gebruik nftable, de iptables opvolger, en Docker kan alleen overweg met iptables of firewalld).
2. Geen exposed ports gebruiken (want anders start die de proxies, en dat wil ik niet)
3. Alle containers krijgen een static IP, waardoor ik dus zelf in de firewall de regels kan aanmaken
4. Alle containers krijgen een IPv6 adres (ook statisch) dat routeerbaar is (in mijn LAN is dat een ULA adres, op mijn VPS is dat een GUA adres)
5. Voor containers die via IPv4 bereikbaar moeten zijn maak ik in de firewall met de hand een DNAT regel aan (bv dus poort 80 binnenkomend op het WAN IP herschrijven naar poort 80 van de Traefik container).
6. Voor containers die via IPv6 bereikbaar moeten zijn maak ik in de firewall een (accept) forward regel aan, direct met "als destination het IP van de Traefik container is en de poort is 80 (of 443) dan accept").

En dat betekend bv dat ik in de Matomo container / logging van een publieke site dus ook prima (mangled / obfuscated) IPv6 adressen van bezoekers zie.

---

Oh, en ja, IPv6 krijgt de voorkeur. Zoekterm: happy eyeballing

[Mars Warrior]

@RobertMe zijn dat soms de userland proxies? Daar wel eerder van gehoord, maar geen idee wat dat was/is.

Het gevolg voor remote_ip staat vziw nergens gedocumenteerd en wordt ook nergens uitgelegd.

Ik gebruik verder gewoon iptables. Dat werkt ootb. Ook fail2ban kan ik dan standaard gebruiken. Nftables vereist aanpassingen.

Ik hoop dat alles straks werkt als ik ipv6 heb aangezet. Afwachten nog. Alles moet daarvoor weer plat. Opstarten duurt ff met bijna 50 containers waaronder een aantal hele zware met meer dan 100 draaiende applicaties.

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 20:05:
@RobertMe zijn dat soms de userland proxies? Daar wel eerder van gehoord, maar geen idee wat dat was/is.

Ja, dat is een userland proxy. Zoals ik aangaf gewoon een programmaatje dat luistert op de host IP/port opgegeven bij de publish en vervolgens het binnenkomende verkeer 1-op-1 doorzet naar een (nieuwe) verbinding richting de container.

Het gevolg voor remote_ip staat vziw nergens gedocumenteerd en wordt ook nergens uitgelegd.

Wat bedoel je hier nu precies mee? remote_ip zoals je in PHP hebt? Maar dat werkt sowieso niet direct als je achter een Caddy reverse proxy zit. Dan moet je naar de X-FORWARDED-FOR header kijken die Caddy zal sturen. Maar okay, bij de proxy variant zal die net zo goed niet kloppen.

Ik gebruik verder gewoon iptables. Dat werkt ootb. Ook fail2ban kan ik dan standaard gebruiken. Nftables vereist aanpassingen.

De grap is dat de Linux kernel al jaaaren alleen maar nftables code bevat. Waarbij er vervolgens iptables (+ ipset + ...) implementatie is die aan de achterkant de nftables APIs van de kernel aanspreekt.

Ik hoop dat alles straks werkt als ik ipv6 heb aangezet.

Nee, gaat niet werken. Om IPv6 te ontvangen in de containers moeten de containers zelf IPv6 doen. En ik heb je niet zien schrijven dat je IPv6 op de Docker networks enabled hebt (docker network create --ipv6 .... IIRC). En netwerken kun je niet bewerken. De enige optie is dus alle containers die in zo'n netwerk (in jouw geval het ingress netwerk?) zitten stoppen, verwijderen, het netwerk verwijderen, het netwerk opnieuw aanmaken met IPv6 en daarna weer de containers aanmaken & starten. En dat gaat dus iets verder dan "aanzetten" en ik heb je nog niet lezen vloeken over dat je de ~50 containers moet verwijderen (en daarna opnieuw aanmaken), dus ik denk niet dat je al zo ver bent

Edit:
Of bedoel je met IPv6 activeren de IPv6 optie in de daemon.json van Docker? Ook dat zal niet veel helpen. Want die optie gaat om het default bridge network. Dat is zeg maar de --ipv6 van docker network create voor die ingebouwde bridge. Niet meer, niet minder. Hetzelfde als die optie voor het IPv6 subnet dat je op kunt geven in de daemon.json, ook die heeft alleen betrekking op het default bridge netwerk.

[ Voor 10% gewijzigd door RobertMe op 29-05-2025 21:32 ]

[Airw0lf]

@RobertMe:
En netwerken kun je niet bewerken. De enige optie is dus alle containers die in zo'n netwerk (in jouw geval het ingress netwerk?) zitten stoppen, verwijderen, het netwerk verwijderen, het netwerk opnieuw aanmaken met IPv6 en daarna weer de containers aanmaken & starten.

Dat klopt an sich wel - netwerken kun je niet bewerken.

Maar wat zou er gebeuren als je een nieuw (bridge) netwerk aanmaakt met IPv6 actief?
En vervolgens alle containers aan dit nieuwe netwerk knoopt?
Als alles goed werkt kan het oude non-IPv6 netwerk verwijderd worden?

Het zou nog steeds een hele klus zijn - maar minder ingrijpend dan alle containers verwijderen en opnieuw aanmaken.

Of heb ik hier nu een klok-en-klepel iets "geschreven"?

[ Voor 6% gewijzigd door Airw0lf op 29-05-2025 21:42 ]

[ed1703]

—

[ Voor 117% gewijzigd door ed1703 op 30-05-2025 01:10 ]

[RobertMe]

Airw0lf schreef op donderdag 29 mei 2025 @ 21:37:
[...]


Dat klopt an sich wel - netwerken kun je niet bewerken.

Maar wat zou er gebeuren als je een nieuw (bridge) netwerk aanmaakt met IPv6 actief?
En vervolgens alle containers aan dit nieuwe netwerk knoopt?
Als alles goed werkt kan het oude non-IPv6 netwerk verwijderd worden?

Het zou nog steeds een hele klus zijn - maar minder ingrijpend dan alle containers verwijderen en opnieuw aanmaken.

Of heb ik hier nu een klok-en-klepel iets "geschreven"?

Potayto potahto

Ja, je kunt gewoon een "ingress-met-ipv6" netwerk maken en bestaande containers een voor een aan het nieuwe netwerk hangen. Dan kun je mogelijk wel half up blijven (/zijn alleen de containers stuk voor stuk even down, i.p.v. dat ze eerst allemaal down moeten, en dan weer allemaal up). Maar uiteindelijk is het kinda net zoveel werk (je moet alle containers na gaan).

Edit:
Of..., dus alleen Caddy naar de buitenwereld toe in een IPv6 netwerk zetten en klaar. Het is niet dat Caddy ook met alle "backends" over IPv6 moet babbelen. Dat kan nog steeds prima via IPv4 (uiteraard met behoud van de juiste X-FORWARDED-FOR header die Caddy naar het backend stuurt).

[ Voor 13% gewijzigd door RobertMe op 29-05-2025 21:56 ]

[Mars Warrior]

RobertMe schreef op donderdag 29 mei 2025 @ 21:15:
[...]
Ja, dat is een userland proxy. Zoals ik aangaf gewoon een programmaatje dat luistert op de host IP/port opgegeven bij de publish en vervolgens het binnenkomende verkeer 1-op-1 doorzet naar een (nieuwe) verbinding richting de container.

Ok. Helder. Ik zie dat ik die kan uitzetten, maar dan wordt inderdaad IPv6 aanvragen domweg geblokkeerd. Logisch eigenlijk.

[...]
Wat bedoel je hier nu precies mee? remote_ip zoals je in PHP hebt? Maar dat werkt sowieso niet direct als je achter een Caddy reverse proxy zit. Dan moet je naar de X-FORWARDED-FOR header kijken die Caddy zal sturen. Maar okay, bij de proxy variant zal die net zo goed niet kloppen.

Nope. Dat is Caddy
Caddy pleurt dingen behalve in de header ook in de logging, waarin je de remote_ip oa kunt zien. En met templates kun je bijv ook handmatig je "X-Real-IP" op {remote} of {remote_host} zetten als je wilt...

Een voorbeeldlog waarin de Docker gateway staat omdat de client IPv6 gebruikt:

JSON:

{
  "level": "info",
  "ts": 1748525274.9179876,
  "logger": "http.log.access.log2",
  "msg": "handled request",
  "request": {
    "remote_ip": "172.30.0.1",
    "remote_port": "48622",
    "client_ip": "172.30.0.1",
    "proto": "HTTP/2.0",
    "method": "GET",
    },
    "Server": [
      "Caddy",
      "Rocket"
    ],
  }
}

En een log waarin wel het juiste externe IP adres staat omdat de client IPv4 gebruikt doordat in de DNS enkel een A record is opgenomen:

JSON:

{
  "level": "info",
  "ts": 1748525327.5075016,
  "logger": "http.log.access.log2",
  "msg": "handled request",
  "request": {
    "remote_ip": "188.207.108.185",
    "remote_port": "26385",
    "client_ip": "188.207.108.185",
    "proto": "HTTP/2.0",
    "method": "GET",
    "Server": [
      "Caddy",
      "Rocket"
    ]
  }
}

[...]
De grap is dat de Linux kernel al jaaaren alleen maar nftables code bevat. Waarbij er vervolgens iptables (+ ipset + ...) implementatie is die aan de achterkant de nftables APIs van de kernel aanspreekt.

Volgens mij gebruik ik dan de compatibility laag. Iets van "legacy" ofzo in de naam. Kan het me vaag herinneren omat het 2,5 jaar geleden is dat ik docker op de server heb gezet

[...]
Nee, gaat niet werken. Om IPv6 te ontvangen in de containers moeten de containers zelf IPv6 doen. En ik heb je niet zien schrijven dat je IPv6 op de Docker networks enabled hebt (docker network create --ipv6 .... IIRC). En netwerken kun je niet bewerken. De enige optie is dus alle containers die in zo'n netwerk (in jouw geval het ingress netwerk?) zitten stoppen, verwijderen, het netwerk verwijderen, het netwerk opnieuw aanmaken met IPv6 en daarna weer de containers aanmaken & starten. En dat gaat dus iets verder dan "aanzetten" en ik heb je nog niet lezen vloeken over dat je de ~50 containers moet verwijderen (en daarna opnieuw aanmaken), dus ik denk niet dat je al zo ver bent

Dat bedoel ik met aanzetten ja
En Nee, daar ben ik nog niet aan begonnen

Ik zal het ingress netwerk van Caddy, waarin natuurlijk alle containers zitten die via Caddy benaderd kunnen worden (zowel via een lokale dns als vanaf extern) met IPv6 moeten uitrusten. Ik heb daar nu enkel een custom IPv4 netwerk in gedefinieerd zodat ik de addressen kan herkennen.

Dat zal ik dus ook voor IPv6 moeten doen, en ja dat betekent dat alle containers die in dat netwerk zitten down moeten en weer moeten worden aangemaakt. Ach...

Aan de andere kant kan ik het ook Docker lekker zelf laten uitzoeken: die maakt dan ULAs aan door enkel een "vinkje" te zetten:

Dynamic IPv6 subnet allocation

If you don't explicitly configure subnets for user-defined networks, using docker network create --subnet=<your-subnet>, those networks use the default address pools of the daemon as a fallback. This also applies to networks created from a Docker Compose file, with enable_ipv6 set to true.

Is dus ook nog een overweging. Ik had namelijk een zelf gedefinieerd IPv4 netwerk gedefinieerd eerder om voor Caddy eventueel nog een proxy te zetten. Dan is een vast adres voor Caddy wel erg handig.

Edit:
Of bedoel je met IPv6 activeren de IPv6 optie in de daemon.json van Docker? Ook dat zal niet veel helpen. Want die optie gaat om het default bridge network. Dat is zeg maar de --ipv6 van docker network create voor die ingebouwde bridge. Niet meer, niet minder. Hetzelfde als die optie voor het IPv6 subnet dat je op kunt geven in de daemon.json, ook die heeft alleen betrekking op het default bridge netwerk.

Nee. Ik gebuik het default bridge netwerk niet. Overal heb ik eigen netwerken opgegeven. De meeste apps eisen dit ook omdat die zelf meerdere containers starten, en dus ook in hun eigen netwerk willen zitten. Alleen de hoofd-app komt extra in het ingress netwerk van Caddy te hangen.

[Mars Warrior]

RobertMe schreef op donderdag 29 mei 2025 @ 21:54:
[...]
Edit:
Of..., dus alleen Caddy naar de buitenwereld toe in een IPv6 netwerk zetten en klaar. Het is niet dat Caddy ook met alle "backends" over IPv6 moet babbelen. Dat kan nog steeds prima via IPv4 (uiteraard met behoud van de juiste X-FORWARDED-FOR header die Caddy naar het backend stuurt).

Alle Aardappelen op een stokje!

Kan dit denk je? Dus behalve het ingress-network waarin de rest van de containers hangen een extra netwerk, laten we zeggen caddy-extern die IPv6 ondersteund, Caddy een schop geven, en klaar?

Zou Caddy dan naar een IPv4 container toch een IPv6 adres meegeven in de header? En als dat om een onverlaat gaat die met admin wil inloggen, dat in de logging van die container het IPv6 adres staat, zodat Fail2Ban die onverlaat een ban kan geven?

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 22:27:
[...]

Ok. Helder. Ik zie dat ik die kan uitzetten, maar dan wordt inderdaad IPv6 aanvragen domweg geblokkeerd. Logisch eigenlijk.

Nouja, uitzetten kan prima, zolang er een andere manier is om de containers te bereiken. Als de containers zelf IPv6 doen is het dus een kwestie van een poort open zetten (als in: het doorsturen van verkeer toestaan. Daar waar je het bij IPv4 hebt over "toestaan van doorsturen" + DNAT om uberhaupt het destination IP (+ evt poort) aan te passen).

[...]

Volgens mij gebruik ik dan de compatibility laag. Iets van "legacy" ofzo in de naam. Kan het me vaag herinneren omat het 2,5 jaar geleden is dat ik docker op de server heb gezet

iptables-legacy lijkt mij juist dat die wel nog de legacy kernel API zou aanspreken, not sure though. Ik gebruik nftables dus houd me niet zo bezig met iptables

Aan de andere kant kan ik het ook Docker lekker zelf laten uitzoeken: die maakt dan ULAs aan door enkel een "vinkje" te zetten:

Het nadeel van ULAs is natuurlijk dat het ULAs zijn. Idealiter knoop je meteen GUAs in de container. Dan kun je gewoon in de externe DNS server dat IPv6 adres gebruiken en werkt dat net zo goed vanaf intern. Maar..., daarvoor is het uiteraard wel nogal belangrijk dat je ook een statische prefix hebt. En bv Ziggo garandeert die niet (/je moet DHCP-PD gebruiken om een prefix op te halen, en daarbij AFAIK geen absolute garantie dat die nooit veranderd. Zoals je bij zakelijke abo's dus wel een vast IP adres krijgt, of bij IPv6 dan een vaste prefix).
ULAs kan uiteraard wel, maar dan moet je dus alsnog DNAT gaan doen, dat niet echt des IPv6 is. Wat daarbij dan weer wel zou kunnen is dat je alsnog verschillende IPv6 adressen aan de host geeft en die 1 op 1 naar containers vertaald. Dus bv een ::80 op de host die ongeacht de destination port vertaald naar het IP van de Caddy container.
* RobertMe gebruikt intern zelfs masquarading . De containers hebben v.w.b. IPv6 alleen een ULA, waardoor de container dus denkt dat IPv6 werkt. Maar dat doet het natuurlijk niet, want met een ULA kan niet het internet op worden gegaan. Vandaar SNAT / masquarading om dus maar weer de afzender te herschrijven naar het (GUA) adres van de host. Op de VPS heb ik uiteraard wel een vast IPv6 subnet (/64). En dat subnet heb ik dan ook opgesplitst in /72 (dus mogelijkheid tot 256x een /72). En dus kan elk Docker netwerk een /72 gebaseerd IPv6 subnet krijgen en kunnen containers rechtstreeks IPv6 naar buiten babbelen en kan binnenkomend verkeer dus ook rechtstreeks worden toegestaan om doorgestuurd te worden.

[...]

Nee. Ik gebuik het default bridge netwerk niet. Overal heb ik eigen netwerken opgegeven. De meeste apps eisen dit ook omdat die zelf meerdere containers starten, en dus ook in hun eigen netwerk willen zitten. Alleen de hoofd-app komt extra in het ingress netwerk van Caddy te hangen.

Uiteraard. Ik bedoelde het meer als "vergis je niet in de betekenis van de IPv6 (+ subnet + ...) instellingen in de daemon.json. Die hebben voornamelijk betrekking op het default bridge netwerk, dat je (waarschijnlijk) niet gebruikt. * RobertMe gebruikt het ook niet, en kan zomaar zijn dat het daadwerkelijk uit staat, want je kunt het ook uit zetten in de daemon.json.

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 22:32:
[...]

Alle Aardappelen op een stokje!

Kan dit denk je? Dus behalve het ingress-network waarin de rest van de containers hangen een extra netwerk, laten we zeggen caddy-extern die IPv6 ondersteund, Caddy een schop geven, en klaar?

Zou Caddy dan naar een IPv4 container toch een IPv6 adres meegeven in de header? En als dat om een onverlaat gaat die met admin wil inloggen, dat in de logging van die container het IPv6 adres staat, zodat Fail2Ban die onverlaat een ban kan geven?

Ik kan mij niet indenken dat dat niet werkt inderdaad. Caddy zal gewoon het binnenkomende IPv6 adres zien en kan die dus ook prima in de logging / X-FORWARDED-FOR header / ... opnamen. En hoe Caddy met de backends babbelt is natuurlijk onafhankelijk van hoe de client met Caddy babbelt. Niet veel anders als de userland proxy van Docker Alleen doet Caddy (mogelijk/waarschijnlijk) HTTP verkeer proxyen, en doet die userland proxy van Docker TCP / UDP proxyen zonder enige verdere kennis van de hogere protocollen.

[Mars Warrior]

RobertMe schreef op donderdag 29 mei 2025 @ 22:48:
[...]

Ik kan mij niet indenken dat dat niet werkt inderdaad. Caddy zal gewoon het binnenkomende IPv6 adres zien en kan die dus ook prima in de logging / X-FORWARDED-FOR header / ... opnamen. En hoe Caddy met de backends babbelt is natuurlijk onafhankelijk van hoe de client met Caddy babbelt. Niet veel anders als de userland proxy van Docker Alleen doet Caddy (mogelijk/waarschijnlijk) HTTP verkeer proxyen, en doet die userland proxy van Docker TCP / UDP proxyen zonder enige verdere kennis van de hogere protocollen.

Ik heb de externe DNS weer omgezet. TTL staat op 10 minuten, maar dat is soms een flink kwartiertje...

Echter het lijkt er nu heel sterk op dat ik nu altijd een IPv4 adres krijg. Ik zie in ieder geval geen Docker Gateway adres meer langskomen. Waar ik voorheen zowel via WiFi als 4G op mijn telefoon dat wel kreeg, krijg ik nu over WiFi het lokale IPv4 adres, en via 4G het externe IPv4 adres.

Dus ja het werkt, maar ook weer niet

Edit: My Bad

Ik had een LLA opgegeven ipv een ULA. Dan krijg je dus dat effect...

Met een ULA (fc00) werkt het nu wel. Ik zie nu IPv6 adressen in de log voorbij komen!

[ Voor 74% gewijzigd door Mars Warrior op 29-05-2025 23:15 ]

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 23:01:
[...]

Ik heb de externe DNS weer omgezet. TTL staat op 10 minuten, maar dat is soms een flink kwartiertje...

Waarom test je niet intern, desnoods door gewoon een regeltje met het IPv6 adres in de /etc/hosts file op te nemen? (en bij Windows nog iets met C:\Windows\... voor /etc/hosts te zetten). Waarbij bij IPv6 dus uberhaupt geen "intern" en "extern" bestaat. Hoogstens dus een globaal IP adres vs een private IP adres (/range, als in: ULA oftewel IPs die binnen fc00://7 vallen).

Zou Caddy nu, omdat de containers in het ingress netwerk enkel IPv4 babbelen de IPv6 aanvraag domweg afwijzen, waardoor er - dankzij die oogballen - altijd een IPv4 verbinding wordt opgezet?

Nee, voor Caddy zal dat irrelevant zijn. Zolang Caddy maar een IP adres (of hostname?) van de backend server weet en die daarmee kan verbinden is dat prima. Caddy doet immers niet veel meer dan gewoon een TCP (client) socket openen om te verbinden met een hostname/IP adres (van de backend server). Dat die dat toevallig doet in reactie op een nieuwe verbinding op een (luisterende) socket die ook nog eens een ander IP protocol gebruikt is irrelevant. En Caddy is natuurlijk een reverse proxy die meer doet. TLS termination / logging / extra headers toevoegen aan HTTP verkeer (/een volledig nieuwe HTTP request opbouwen die toevallig (een deel van) de (meta)data van de originele aanvraag over neemt).
Het is niet zoals bij een firewall met DNAT dat de TCP/IP pakketjes herschreven worden naar een ander bestemmings IP adres. Het is een volledig programma, dat TCP/IP pakketjes ontvangt, en die daadwerkelijk verwerkt, en (wellicht) toevallig in reactie daarop zelf een TCP/IP verbinding op zet met een ander programma. Ter vergelijking: bv dan een PHP server die via IP een request ontvangt kan toch ook prima over een unix socket met de database babbelen. Het is ook niet alsof die dan ineens ook via IP, en dezelfde IP versie, met de database moet babbelen.

[Mars Warrior]

@RobertMe Zie mijn vorige, gewijzigde post!

Het werkt nu, zowel lokaal via WiFi als via 4G: ik krijg netjes IPv6 adressen in de log te zien van een container die in het IPv4 ingress netwerk zit.

Net ff de logfile voor Fail2Ban bekeken, en daar zie ik bij een foute inlog het IPv6 adres. Dus Fail2Ban gaat dan het juiste adres blokkeren. Dan zal het IPv4 adres vervolgens wel weer komen, maar goed. Dat krijg je met zowel IPv4 als IPv6: twee wegen die naar dezelfde server leiden.

Het is wat!

[RobertMe]

Mars Warrior schreef op donderdag 29 mei 2025 @ 23:23:
@RobertMe Zie mijn vorige, gewijzigde post!

Twee edits? Volgens mij had je al een kleine edit gedaan die ik zag in de quote (maar nog niet bij lezen reactie had gezien).
Maar dat je het link local address gebruikt had had ik niet gezien nee. En dan wordt het lastig. Een link local address is immers niet routeerbaar, en het link local address van de container moet wel gerouteerd worden vanaf je gewone LAN.

Net ff de logfile voor Fail2Ban bekeken, en daar zie ik bij een foute inlog het IPv6 adres. Dus Fail2Ban gaat dan het juiste adres blokkeren. Dan zal het IPv4 adres vervolgens wel weer komen, maar goed. Dat krijg je met zowel IPv4 als IPv6: twee wegen die naar dezelfde server leiden.

Ik hoop voor je dat fail2ban uberhaupt de volledige /64 blokkeert. Anders hebben ze sowieso 2^64 (oftewel: 1.8e19) adressen beschikbaar Dat zou dan ook weer een leuke attack vector (/DoS) zijn om fail2ban / de firewall over de zeik te krijgen door een enorme (ip)set op te bouwen met dus miljarden individuele adressen er in.

Edit:
@Mars Warrior, maar heb je nu de ULA in de DNS opgenomen? Dat kan toch sowieso nooit werken? Behalve op wifi dan. Immers is die ULA niet over het internet routeerbaar. In de (externe) DNS zal toch echt een GUA moeten staan. Die je al dan niet in je router, of op de Docker host (of een ander IPv6 capable systeem in je netwerk) DNAT naar de ULA. Of dus als je een gegarandeerd statische prefix hebt dus een GUA gebruiken voor het Docker netwerk, maar dat zou dan wel een GUA in een ander subnet zijn (binnen de /46 die je van KPN kreeg dan), waardoor je router alsnog moet weten dat dat specifieke subnet bereikbaar is (/gerouteerd moet worden) via de Docker host (die routing entry kan dan wel weer op basis van het link local address van de Docker host uiteraard).

[ Voor 25% gewijzigd door RobertMe op 29-05-2025 23:39 ]

[Mars Warrior]

RobertMe schreef op donderdag 29 mei 2025 @ 23:30:
Ik hoop voor je dat fail2ban uberhaupt de volledige /64 blokkeert. Anders hebben ze sowieso 2^64 (oftewel: 1.8e19) adressen beschikbaar Dat zou dan ook weer een leuke attack vector (/DoS) zijn om fail2ban / de firewall over de zeik te krijgen door een enorme (ip)set op te bouwen met dus miljarden individuele adressen er in.

Geen idee hoe Fail2Ban met IPv6 blokkades omgaat. Dat moet ik gaan zien dan de komende tijd.
Er komt niet enorm veel binnen op die containers qua bots en andere zooi, maar wel ff iets om op te letten.

Ik zet voorlopig de ban-tijd niet te lang in ieder geval.

[alex3305]

Vandaag nog een leuke situatie meegemaakt die mij niet eerder bekend was. Ik gebruikte eerder een ipvlan voor al mijn containers, maar ben al een tijdje geleden geswitched naar Docker Swarm met een overlay network. Na de upgrade naar Unraid 7.1.2 had ik echter wat problemen met het ipvlan netwerk. Hierover had ik al wat geschreven in het Unraid topic, maar tl;dr containers in het ipvlan netwerk konden de host niet bereiken en vice-versa. Met macvlan werkte het wel. Wat mij betreft ook prima . In Unraid heet het toch allebei br0.

Nu viel mij in mijn router echter op dat sommige containers een nogal bijzonder netwerkverbruik hadden . Voornamelijk onverwacht. En dan heb ik het over grote(re) transfers. Toen ik echter een docker network inspect br0 deed zag ik o.a. dit:

Even wat geknipt om voornamelijk mijn voorbeeld te illustreren.

JSON:

{
    "Name": "br0",
    "Containers": {
        "37b264686080564a243ca86da90fee6add3a65f27cd760c52c483778ef9f26bf": {
            "Name": "kopia",
            "EndpointID": "9e9e68388dc92541653bb4c42dcb34f3530427554a79f9eee9981a05254d112c",
            "MacAddress": "02:42:c0:a8:01:29",
            "IPv4Address": "192.168.0.41/24",
            "IPv6Address": ""
        },
        "854a9dbb6001d75d9a6dddc005adc7f05febaf4b2c3e3de8c8dc625e8e4e5c8a": {
            "Name": "adguard-home",
            "EndpointID": "c3b35675e624f9dd46928b628a4ad7d23764da15691051f64a3754324953c20e",
            "MacAddress": "02:42:c0:a8:01:04",
            "IPv4Address": "192.168.0.4/24",
            "IPv6Address": ""
        }
        "c8e185d487858dcea0e7fa2060c3f64e7c72b752639975ee8e4c8ea614dbe6c1": {
            "Name": "home-assistant",
            "EndpointID": "448236dfb73cdde6ddf63e35ad798b5e02955aa86de180d1db77e905faf37ab9",
            "MacAddress": "02:42:c0:a8:01:03",
            "IPv4Address": "192.168.0.3/24",
            "IPv6Address": ""
        }
    }
}

Dat Adguard Home er in staat klopt. Immers wil ik mijn DNS server(s) direct kunnen bereiken. Home Assistant klopt ook. Het implementeren van een DNS reflector zoals @RobertMe in het Home Assistant topic beschreef staat naar zijn bericht inmiddels op mijn lijstje. Maar Kopia heb ik al een hele tijd achter mijn Caddy setup draaien . Ook in de Docker Compose vond ik geen enkele verwijzing meer naar br0.

Een volledige docker compose down (vanuit dockge omdat ik lui ben ) zorgde er dan ook voor dat deze netwerkverwijzing verdween .

Ik had eigenlijk verwacht dat een wijziging in de Docker Compose voldoende zou zijn om de netwerktoewijzing teniet te doen. Maar dat is dus wellicht onterecht. Het is ook niet het einde van de wereld, maar vond het vooral verwarrend.

[RobertMe]

alex3305 schreef op donderdag 5 juni 2025 @ 20:34:
Ik had eigenlijk verwacht dat een wijziging in de Docker Compose voldoende zou zijn om de netwerktoewijzing teniet te doen. Maar dat is dus wellicht onterecht. Het is ook niet het einde van de wereld, maar vond het vooral verwarrend.

Geen ervaring met swarm. Maar als je een up doet en de container (definitie) is gewijzigd dan zou die effectief ook gewoon een down + up moeten doen. Of in Docker termen dan een stop + rm + (create + start) (/run). Daarom dat je ook volume mappings of named volumes moet gebuiken. Anders is bij die up al de data in de oude container verdwenen door de rm etc.

Niet toevallig toentertijd wel de compose file gewijzigd, maar niet opgeslagen, vervolgens een up gedaan met nog de oide file en daarna pas opgeslagen?

[alex3305]

@RobertMe Ik weet dat het zo zou moeten lopen, vandaar dat ik zo verbaasd ben . Mijn gehele deployment verloopt geautomatiseerd vanaf mijn workstation met Git naar Forgejo waarbij Forgejo Runner een Workflow aftrapt met Ansible. Die template vervolgens en Compose file naar mijn server, die vervolgens een Docker Compose Up doet.

Deze workflow vind tevens geautomatiseerd plaats bij versie updates door middel van Renovate. En extra bestanden of handmatige aanpassingen worden dan weggehaald. Ook heb ik twee geleden alles nog een keer vers gedeployed.

De laatste keer dat mijn Kopia container het ipvlan / macvlan netwerk gebruikte was meer dan een half jaar geleden . Er waren overigens nog meer containers waarbij dit aan de hand was. Een volledige down en up zorgde er voor dat de toewijzing werd weggehaald.

[alex3305]

alex3305 schreef op donderdag 5 juni 2025 @ 20:34:
[...] Het implementeren van een DNS reflector zoals @RobertMe in het Home Assistant topic beschreef staat naar zijn bericht inmiddels op mijn lijstje. [...]

Ik quote mezelf even, maar ik ben de afgelopen week bezig geweest om dit te implementeren op basis van de blijkbaar enorm veelgebruikte code van Darell Tan. Alleen heb ik het geheel dus in een Docker container gegoten. Het uiteindelijke containertje is niet veel groter dan standaard Alpine. Eventueel zou ik nog naar Busybox kunnen wisselen of wellicht zelfs scratch aangezien alles toch statisch gecompileerd is.

Met de ESPHome werkte deze container echt meteen out-of-the-box toen ik de ipvlan/macvlan toewijzing verwijderde. Maar vreemd genoeg kreeg ik in Home Assistant geen enkel mDNS / Zeroconf record te zien toen ik daar hetzelfde deed. Ik ben enorm benieuwd wat het eigenlijke verschil is tussen deze twee applicaties, want het principe is hetzelfde.

[Mars Warrior]

Nog even terugkomen op mijn IPv4/IPv6 probleem waarbij het "remote address" van een client altijd de Docker gateway was als de client over IPv6 babbelt:

De oplossing om enkel Caddy in een IPv4/IPv6 netwerk te hangen, en de rest van de containers (die andere 48 ofzo) in een IPv4-only netwerk te laten zitten blijkt uitstekend te werken.

Ik krijg dus op een container die enkel IPv4 doet toch netjes de externe/client IPv6 adressen door.
Dat betekent dat een WAF (Web Application Firewall) of Fail2Ban ook de juiste client blokkeert.

Het blokkeren van IPv6 is wel altijd een /128 adres. Dus geen subnet van /64, /56 of /48 aangezien ik ook niet weet hoe groot het subnet aan de andere kant is.
Vooralsnog geen "flood" aan verschillende IPv6 adressen die pogingen doen om binnen te komen, en daarmee een mega lijst van IP adressen geeft voor Fail2Ban om te blokkeren.

Ik gebruik Wordfence als WAF voor Wordpress gerelateerde containers, en daar zie ik dat iha het "Wordfence beveiligingsnetwerk" al bijna al het mens/bot verkeer dat ongewenst is bij voorbaat blokkeert voordat deze op een pagina terechtkomt: die zijn niet eens in staat om een poging te doen om in te loggen

Afwachten of dit in de toekomst nog veranderd als er steeds meer gebruik gemaakt wordt van IPv6.

[RobertMe]

Mars Warrior schreef op zondag 15 juni 2025 @ 13:33:
Het blokkeren van IPv6 is wel altijd een /128 adres. Dus geen subnet van /64, /56 of /48 aangezien ik ook niet weet hoe groot het subnet aan de andere kant is.
Vooralsnog geen "flood" aan verschillende IPv6 adressen die pogingen doen om binnen te komen, en daarmee een mega lijst van IP adressen geeft voor Fail2Ban om te blokkeren.

Het kleinste "geaccepteerde" subnet is /64. Een /64 is namelijk vereist voor SLAAC dat op zichzelf weer dr defacto standaard is om een IPv6 te verkrijgen (door het zelf te genereren dus).
Kleiner dan dat kan "uiteraard" wel, maar zou op zijn minst onwenselijk zijn als niet leiden tot heel wat issies bij "normaal gebruik". En ook in de hosting wereld is het bij mijn weten dus de standaard dat een server (of wellicht een cluster) een /64 (of groter) krijgt.

Enige uitzondering die ik mij kan bedenken zijn VPNs. De VPN aanbieder die ik gebruik gaat per server ("natuurlijk") maar met 1 IPv6 adres het internet op. Mogelijk wellicht misschien dat zij vervolgens wel 1 subnet delen over meerdere (/alle?) servers. Maar ik acht dat eigenlijk ook onwaarschijnlijk (routing zou dan bv per /128 of iets dergelijks moeten, en geen idee of dat mogelijk is, of ze moeten het intern routeren wat mij weer een SPoF op lijkt te leveren).

Ergo: ik zou gewoon een /64 gebruiken. De kans dat je daarmee legitieme gebruikers onterecht blokkeert is zeer klein. En dat zal dan vast een gebruiker zijn die of het of zelf "opzoekt" (VPN gebruiken, altijd een risico dat anderen misbruik doen waardoor het IP geblokkeerd wordt) of meer eigenaardigheden zal hebben.

[Mars Warrior]

RobertMe schreef op zondag 15 juni 2025 @ 13:53:
[...]
Ergo: ik zou gewoon een /64 gebruiken. De kans dat je daarmee legitieme gebruikers onterecht blokkeert is zeer klein. En dat zal dan vast een gebruiker zijn die of het of zelf "opzoekt" (VPN gebruiken, altijd een risico dat anderen misbruik doen waardoor het IP geblokkeerd wordt) of meer eigenaardigheden zal hebben.

dan ga ik eens kijken wat fail2ban kan en doet. Dat is me nog onduidelijk op IPv6 vlak.

Met de implementatie van IPv6 en wat header aanpassingen in Caddy is het uiteindelijke resultaat voor mijn domeinen en subdomeinen inmiddels wel een 100% score op internet.nl 😋

De rest doet de provider allemaal.

Best wel stuitend af en toe als je ziet dat bekende sites een score van nog geen 60% halen. En dan thuis gewoon 100% scoren.

Vanzelfsprekend voel ik me zo veilig dat ik verder overal username/password gebruik om in te loggen 😳🤣

[ Voor 13% gewijzigd door Mars Warrior op 15-06-2025 18:11 ]