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

[alex3305]

@blackd Goede vragen

Alhoewel ik best het e.e.a. strak heb ingericht is er bij mij ook nog ruimte voor verbetering. Met andere woorden, ik heb dat nu niet. Ik heb dat eigenlijk ook niet helemaal nodig. In ieder geval niet met mijn workflow. In principe doe ik na het wijzigen van mijn group_vars of host_vars sowieso een deploy vanaf mijn lokale workstation. Enerzijds om het te testen en direct problemen op te lossen, anderzijds omdat ik snel resultaat wil . Wijzigingen in de vars worden dus door middel van het fail fast principe snel getest.

Tegelijkertijd heb ik ook mijn vars voor een heel groot gedeelte opgesplitst per role. Simpelweg omdat ik veel liever met veel kleine bestanden werk dan met 1 grote. Want...

Ik heb het hier vaker op Tweakers verteld, maar ik ben slechtziend en heb een zichtvermogen van circa 20%. Mijn letters zijn dus ietsjes groter dan ehh gemiddeld . Om een indicatie te geven hierbij een screenshot van een gemiddeld VS Code window waarbij ik de 80 karakterlimiet heb aangewezen met een rode pijl



Dit venster neemt 75% van mijn 32" display in beslag. Een display waar ik een 25-30 centimeter vanaf zit . Verticaal passen er zo'n 40 regels op mijn scherm voordat het ophoudt. Mijn truc is overigens om code aan de structuur te herkennen en simpelweg te onthouden waar alles staat. Ik kan daardoor bijna blind (hurdur) door code heen navigeren.

Ik ben dus bijna verplicht om veel kleine bestanden te gebruiken. Sterker nog, van Traefik heb ik zelfs twee vars bestanden in mijn group_vars, één met de configuratie en de andere met de dynamische reverse proxy configuratie. In mijn group_vars heb ik daarbij de variabelen die nodig zijn voor het geheel, dus domeinnaam, middleware configuratie, ingress netwerk, etc. En in de host_vars staan alleen variabelen die nodig zijn voor die host.

Bij een check (en deployment, want dat is bij mij hetzelfde) doe ik sowieso een deploy van het playbook. In sommige gevallen de applicatie zelf, maar in andere gevallen de complete stack. Dat is een beetje afhankelijk van de applicatie en wat ik prettig vind. Ik heb dan wat Shields in mijn README die ik kan checken wat de status is en eventueel Gatus voor status. Het feest gaat sowieso niet door bij een probleem in het playbook, inclusief validatie problemen.

Ook Renovate rolt het hele playbook uit bij een versie upgrade, maar altijd in check mode in de PR. Als een check mode niet slaagt wordt het PR niet gemerged. Klaar, uit. Ik vind dat veilig genoeg.

Eigenlijk heb ik de afgelopen jaar of jaren nog geen een echte probleem deployment gehad. Behalve dan door mijn eigen gepruts. Vaak door haastigheid . Ik voel dus niet de noodzaak om dit proces nog strakker in te richten. En al helemaal niet als ik zie hoeveel runs ik heb gedaan in de afgelopen ~2 jaar:



Niet om te pochen, maar dit gaat dus om ~1000 runs per maand of gemiddeld zo'n 30 per dag. Als er dan niet echt iets misgaat vind ik het wel best.

[blackd]

alex3305 schreef op dinsdag 17 maart 2026 @ 21:18:
@blackd Goede vragen

Alhoewel ik best het e.e.a. strak heb ingericht is er bij mij ook nog ruimte voor verbetering. Met andere woorden, ik heb dat nu niet. Ik heb dat eigenlijk ook niet helemaal nodig. In ieder geval niet met mijn workflow. In principe doe ik na het wijzigen van mijn group_vars of host_vars sowieso een deploy vanaf mijn lokale workstation. Enerzijds om het te testen en direct problemen op te lossen, anderzijds omdat ik snel resultaat wil . Wijzigingen in de vars worden dus door middel van het fail fast principe snel getest.

Met mijn vragen probeer ik te ondekken hoe jouw workflow is ingericht .
We hebben weer een overeenkomst te pakken, mijn workflow voor grote wijzigingen of nieuwe roles is ook dat ik dit op mijn laptop ontwikkel en (uiteindelijk) ga uittesten op de omgeving. Met molecule heb ik daar nog een test resource bij die ik eerder kan gebruiken. De --diff parameter is daarbij heel handig om direct bij converge te zien wat je output is (bijv. de output van een template task).
extensions/molecule/config.yml

YAML:

---
ansible:
  executor:
    args:
      ansible_playbook:
        - --diff
        - --force-handlers
        - --inventory=${MOLECULE_SCENARIO_DIRECTORY}/../inventory.yml
  env:
[.snip.]

Conclusie is volgens mij dat jij jouw deploy-<app>.yml workflows primair hebt bedoeld voor gebruik van Renovate. Check jij hier dan nog op in de workflow, bijv. met een label in de PR? Ik laat Renovate een label plaatsen, daarmee zijn die PR's herkenbaar.

Tegelijkertijd heb ik ook mijn vars voor een heel groot gedeelte opgesplitst per role. Simpelweg omdat ik veel liever met veel kleine bestanden werk dan met 1 grote. Want...

Ik ben dus bijna verplicht om veel kleine bestanden te gebruiken. Sterker nog, van Traefik heb ik zelfs twee vars bestanden in mijn group_vars, één met de configuratie en de andere met de dynamische reverse proxy configuratie. In mijn group_vars heb ik daarbij de variabelen die nodig zijn voor het geheel, dus domeinnaam, middleware configuratie, ingress netwerk, etc. En in de host_vars staan alleen variabelen die nodig zijn voor die host.

Los van jouw beperking in zichtvermogen vind ik het zelf ook prettig om met kleine overzichtelijke eenheden te werken. Dus ik wil ook toewerken naar een config file per role.

Ik zou daar wat meer op willen in zoomen, want in jouw screenshot staan variabelen die bedoeld zijn voor de role beszel en in de tree explorer staat er een voor de role adguard_home.
Ik had die op group_vars niveau verwacht.

Ik heb het nu zo ingericht:

code:

production
├── group_vars
│   ├── all
│   │   ├── main.yml
│   │   ├── secrets.yml
│   │   └── vault.yml
│   ├── truenas_apps
│   │   ├── authentik.yml
[..snip..]
│   │   └── uptime_kuma.yml
│   └── truenas_host
│       └── jailmaker.yml
├── host_vars
│   ├── docker.yml
│   ├── localhost.yml
│   └── nas.yml
└── inventory.yml

waarbij ik de inventory.yml file heb:

YAML:

truenas_host:
  hosts:
    nas:

truenas_apps:
  hosts:
    docker:

truenas_shared:
  children:
    truenas_hosts:
    truenas_apps:

Op mijn 'docker' host draai ik alle docker compose roles.
Ik heb dus een indirectie via een group:
docker (=host, met een IP adres, dit is een jail op de TrueNAS machine) > truenas_apps (=group)
Alle playbooks apply ik op de group, niet op de host.
Als gevolg hiervan heb ik alle role variabelen in de truenas_apps group een eigen file gegeven met de role variabelen.

In host_vars staan echt alleen host specifieke variabelen:
inventory/production/host_vars/nas.yml:

YAML:

ansible_host: [..]
ansible_user: [..]
ansible_password: "{{ secrets.truenas_admin_password }}"
ansible_become_password: "{{ secrets.truenas_admin_password }}"
ansible_ssh_common_args: '[ jump host ]'

Ik vraag me af of mijn indirectie zin heeft of dat het ook simpeler kan. Want zo te zien heb jij alle role variabelen op host_var niveau geplaatst. Klopt dat of heb ik het mis?

Daarnaast vraag ik me af, ik heb compose stacks die ik 2x uitrol, dat zijn nu twee roles, maar die wil/kan ik generaliseren naar één role. Bijv. traefik en traefik_external. Die hebben allebei een aparte folder voor het compose project. Ik ontkom er niet aan om de variabele die de folder naam stuurt, in het playbook te specificeren:

YAML:

---
- name: Deploy traefik
  hosts: truenas_apps

  roles:
     - role: traefik
       vars:
          traefik__stack_name: traefik
          traefik__external: false
     - role: traefik
       vars:
          traefik__stack_name: traefik-external
          traefik__external: true
          [ andere variabelen die anders zijn, zoals poorten, labels ... ]

Bij een check (en deployment, want dat is bij mij hetzelfde) doe ik sowieso een deploy van het playbook. In sommige gevallen de applicatie zelf, maar in andere gevallen de complete stack. Dat is een beetje afhankelijk van de applicatie en wat ik prettig vind. Ik heb dan wat Shields in mijn README die ik kan checken wat de status is en eventueel Gatus voor status. Het feest gaat sowieso niet door bij een probleem in het playbook, inclusief validatie problemen.

Met 'het playbook' bedoel je jouw meta playbooks/all.yml en dat gebruik je op jouw lokale machine?
Of heb je hier ook een check/deploy workflow voor in CI?

Want wanneer je klaar bent met lokaal ontwikkelen wil je wel de lint, test, check en deploy ook uitvoeren en testen of je checkin compleet is. Hoe maak je dan het onderscheid tussen de overige deploy workflows die voor Renovate gebruikt worden?

Ook Renovate rolt het hele playbook uit bij een versie upgrade, maar altijd in check mode in de PR. Als een check mode niet slaagt wordt het PR niet gemerged. Klaar, uit. Ik vind dat veilig genoeg.

Wat bedoel je met een versie upgrade? Bedoel je hiermee dependencies zoals ansible-core, python, collections en external-roles?

Ik zie de volgende stromen aan changes in mijn repo voorbij komen:

1. Docker image upgrades, getriggerd door Renovate, onderdeel van een role.
2. Package updates (docker-ce, apt packages, dat soort dingen), getriggerd door Renovate, onderdeel van een (externe) role.
3. Core updates (ansible-core, python, roles, collections), onderdeel van mijn execution environment, getriggerd door Renovate vanuit mijn andere repo.
4. Development updates (pre-commit, ansible-lint, renovate-cli, ...), getriggerd door Renovate, onderdeel van andere files in mijn repo (pre-commit-config.yml, etc.).
5. Renovate reconfigure
6. Workflow aanpassingen
7. Feature/Fix PR's, getriggerd door mijzelf, aanpassingen in al het bovenstaande mogelijk.

Eigenlijk wil je per flow van werk een goede CI inrichten om het te testen en waar nodig deployen.
Flow 1 heb ik nu met de deploy-<role>.yml workflows wel goed ingericht, maar de overige flows wil ik nog kijken of ik dat wat strakker kan inrichten.

Eigenlijk heb ik de afgelopen jaar of jaren nog geen een echte probleem deployment gehad.

Ik de laatste tijd eigenlijk ook niet, maar ik kom van Semaphore UI, daarna Woodpecker CI en nu Github Actions. Ik heb de afgelopen tijd wel e.e.a. aan wijzigingen doorgevoerd om sneller feedback te krijgen door meer te linten en testen. Ik ben afgestapt van Semaphore UI vanwege de inflexibiliteit van de run omgeving (de container waar je playbook draait) en de keuzes die ik toen had gemaakt (bitwarden integratie) wat heel lastig op te zetten was. Woodpecker CI was daar al wat beter in, maar toen ging ik ook Github Actions gebruiken en dan is de wisselwerking niet te doen (bijv. check mode afhankelijk van een job test). Daarom helemaal over naar Github Actions. Tot nu toe gaat dat goed, maar de job moet niet te groot zijn. Ik heb de eerste 'out of disk space' al gehad bij een Molecule test met alle scenario's.

Ik gebruik nu dus Github Actions, deels de Github runners en deels lokaal. Als ik een grote refactoring doe, kom ik makkelijk aan de 2000 minuten/maand (=limiet). Ik heb vorige maand ook 900 jobs gedraaid, 1600min en dan doe ik niks geks.

Mijn initial commit van deze repo was Dec 2024. Ik ben ergens in Jun 2024 met Ansible gestart, dat was om Pi-Hole in een HA cluster te draaien. Mijn job is wel in de IT maar als software engineer, dus ik doe dit puur voor de hobby.

Is het al tijd voor een 'Ansible Automation' topic .

[alex3305]

blackd schreef op woensdag 18 maart 2026 @ 10:29:
Met mijn vragen probeer ik te ondekken hoe jouw workflow is ingericht .

Yes. En ik krijg inzicht in hoe jij het doet . Tegelijkertijd is het ook niet verkeerd om hier kritisch over te blijven denken. Dank daarvoor.

Conclusie is volgens mij dat jij jouw deploy-<app>.yml workflows primair hebt bedoeld voor gebruik van Renovate. Check jij hier dan nog op in de workflow, bijv. met een label in de PR? Ik laat Renovate een label plaatsen, daarmee zijn die PR's herkenbaar.

Primair is misschien niet het juiste woord. Primair is het voor alle deployment, maar als ik iets in mijn vars verander dan test ik dat wel eerst met een deployment vanuit mijn lokale host voordat ik dat vanuit CI uitrol. Aangezien een CI deploy bij mij altijd wordt uitgevoerd bij een commit naar main, wordt dus de deployment dus altijd idempotent herhaald.

Ik plaats zeker labels . Ik heb een eigen label sync action gebouwd zodat ik labels in een yaml bestand kan managen. Op het moment dat ik deze yaml wijzig, worden de labels geüpdatet. Vanuit Renovate voeg ik dan de juiste labels bij PR's toe:



In principe krijgen Renovate PR's altijd de labels CI en maintenance.

Ik vraag me af of mijn indirectie zin heeft of dat het ook simpeler kan. Want zo te zien heb jij alle role variabelen op host_var niveau geplaatst. Klopt dat of heb ik het mis?

Dat heb je mis .

De connection parameters zoals ansible_user, ansible_host, etc. heb ik in mijn inventory opgenomen.

In mijn group_vars staan variabelen die voor heel de groep gelden. De meeste van mijn applicaties zijn Docker applicaties dus de meeste van mijn group_vars bevinden zich bij mij in de docker group. Wellicht dat ik dat nog een keer splits. Pak ik dan home_assistant.yml in mijn docker group_vars, dan heb ik daarin bijvoorbeeld het domein en netwerk staan waarin de Home Assistant applicatie zich bevindt.

In de host_vars van mijn primaire host heb ik ook een home_assistant.yml waarin ik o.a. de cpuset configureer Dit is namelijk host afhankelijk. Op de secundaire host heb ik ook een home_assistant.yml waar ik mijn Zigbee en Z-Wave adapter heb ingesteld. Wederom is dit host afhankelijk. Dit zou je ook in een eigen yml kunnen doen.

Daarnaast vraag ik me af, ik heb compose stacks die ik 2x uitrol, dat zijn nu twee roles, maar die wil/kan ik generaliseren naar één role. Bijv. traefik en traefik_external. Die hebben allebei een aparte folder voor het compose project. Ik ontkom er niet aan om de variabele die de folder naam stuurt, in het playbook te specificeren.

Ik heb geen rollen die ik twee keer naar dezelfde host uitrol. Als ik dat wel heb, pas ik inderdaad de variabelen van 1 role aan.

Met 'het playbook' bedoel je jouw meta playbooks/all.yml en dat gebruik je op jouw lokale machine?
Of heb je hier ook een check/deploy workflow voor in CI?

Nee, het playbook van de applicatie die ik aan heb gepast. Het all playbook gebruik ik nauwelijks.

Want wanneer je klaar bent met lokaal ontwikkelen wil je wel de lint, test, check en deploy ook uitvoeren en testen of je checkin compleet is. Hoe maak je dan het onderscheid tussen de overige deploy workflows die voor Renovate gebruikt worden?

Niet? Dat is gewoon dezelfde workflow. Ik gebruik wel een pre-commit hook voordat ik alles commit.

Wat bedoel je met een versie upgrade? Bedoel je hiermee dependencies zoals ansible-core, python, collections en external-roles?

Ook. Maar ik bedoel hiermee de applicatie uit Docker Compose.

Eigenlijk wil je per flow van werk een goede CI inrichten om het te testen en waar nodig deployen.

Ik zie dat toch net anders. Ik heb 1 flow per Compose applicatie of stack. Op het moment dat er een stack aangepast wordt, wordt deze in check mode uitgevoerd en uiteindelijk deployed. Alle andere tooling die daaronder zit komt automatisch mee en wil ik dus niet apart testen. Met andere woorden: dat geloof ik wel. Omdat ik toch fail fast gebruik zie ik problemen snel genoeg.

En mocht er toch een onderdeel problemen geven, dan wordt de applicatie niet deployed. Enerzijds omdat waarschijnlijk eerder in het proces het probleem al ontstaat, anderzijds omdat de check mode dan sowieso faalt en het PR niet wordt gemerged.

Ook wil ik alles zsm deployen, wederom vanwege4 fail fast, maar ook omdat Ansible idempotent hoort te zijn. Zijn er dus constant changes, dan gaat er waarschijnlijk iets anders mis.

Is het al tijd voor een 'Ansible Automation' topic .

Eerder iets over CI / homelab / selfhosting .

[blackd]

@alex3305 Thanks voor je reactie, je zet me aan het denken m.b.t. de workflow strategie.
Ik denk dat ik dit alles even moet laten bezinken en verder moet gaan met de playbooks gaan opknippen met de juiste path mapping en de juiste roles applyen.

Want het risico wat ik zie met opknippen en niet het main.yml playbook te gebruiken is dat je iets mist met je checkins en niet uitrolt, zodat je omgeving niet (compleet) in de desired state is. Maar misschien is dat een gevoel wat nu ontstaat door dit opknippen en dat er straks niks meer aan de hand is.

Daarnaast zit ik nog te puzzelen (in mijn hoofd) hoe ik bepaalde generieke (externe) rollen goed moet organiseren en laten triggeren door Renovate. Bijv. voor docker gebruik ik geerlingguy.docker en daarmee kan ik de docker-ce version configureren. Dat is nu een group variable, dus dan moet het docker-ce playbook daarop triggeren. Vandaar mijn vragen over host_vars en group_vars.

alex3305 schreef op zaterdag 14 maart 2026 @ 14:48:
Nu heb ik namelijk regelmatig 3 - 5 Renovate PR's openstaan, terwijl ik voor digests zelfs al alleen branches gebruik . Dat houdt elkaar ook nog eens op, want elke keer moeten PR's gesynct worden én wordt er dus opnieuw een Ansible-playbook met check mode uitgevoerd om te testen of het geheel nog werkt.

Al eens naar een merge-queue gekeken? Ik zag dat Github het wel ondersteunt, maar alleen voor betalende klanten of openbare repo's. Voor Forejo staat een feature request open zag ik.

[ Voor 30% gewijzigd door blackd op 18-03-2026 12:49 ]

[alex3305]

@blackd Je hebt gelijk dat het gebruik van opgeknipte playbooks risico's met zich meebrengt. Wat mij betreft is dat een trade-off tussen snelheid (development velocity) en mogelijke instabiliteit of eigenlijk beter gezegd een 'incomplete' omgeving. Ik besef me op dat moment ook dat mijn meta-playbooks uiteindelijk allemaal gebruik maken van de applicatie playbooks. De kans dat ik dus iets mis bij het uitrollen acht ik daarmee dus minimaal, immers vinden die vaak genoeg plaats.

Toen ik Ansible gebruikte op grotere omgevingen en met klanten rolde we ook vaak alleen specifieke veranderingen en/of klantapplicaties uit. En dan periodiek alles. Wat mij betreft is dat een prima verhouding, maar dat is natuurlijk een kwestie van smaak. Net zoals met veel aspecten die ik hier neerpen. Het is bijvoorbeeld ook niet verkeerd om klein te beginnen en uit te bouwen. Of een andere opzet dan de mijne te hebben. Ik vind dit fijn, jij misschien niet. Prima, toch? Ik vind het vooral belangrijk om een open blik te houden naar de opzet en mening van anderen. Daar kun je alleen maar van leren .

Daarnaast zit ik nog te puzzelen (in mijn hoofd) hoe ik bepaalde generieke (externe) rollen goed moet organiseren en laten triggeren door Renovate. Bijv. voor docker gebruik ik geerlingguy.docker en daarmee kan ik de docker-ce version configureren. Dat is nu een group variable, dus dan moet het docker-ce playbook daarop triggeren. Vandaar mijn vragen over host_vars en group_vars.

Oh ja. Grappig genoeg heb ik die role dus zelf gebouwd en is die vrijwel gelijk aan die van geerlingguy . Dat soort dingen zou ik in een 'group_vars/docker/all.yml' zetten en daarop laten triggeren. Of wellicht 'group_vars/docker/version.yml'. Die kun je dan direct door Renovate met een yaml comment laten bijhouden. Zo'n extra file voelt misschien gaar, maar tegelijkertijd is het wel heel erg duidelijk. Immers heb ik ook een python-version bestand in mijn repo.

Al eens naar een merge-queue gekeken? Ik zag dat Github het wel ondersteunt, maar alleen voor betalende klanten of openbare repo's. Voor Forejo staat een feature request open zag ik.

Goed idee, maar ik gebruik bijna geen GitHub. En aangezien het dus nog niet in Forgejo zit, gebruik ik het sowieso niet . Ik heb er enorm veel schik in om alles zelf te hosten. Dat probeer ik dus zover als het kan. GitHub is prima, maar ik vind bijv. Copilot enorm ruk. Ook omdat ik niet alles in de cloud wil hebben...

Wat dat betreft is zo ongeveer het enige wat ik nog echt mis is een mailserver. Laatst wel naar Docker mailserver gekeken, maar ik wilde het eigenlijk achter Traefik hebben en dat ging niet. Misschien dat ik binnenkort nog eens een poging waag.

[blackd]

alex3305 schreef op woensdag 18 maart 2026 @ 16:44:
Toen ik Ansible gebruikte op grotere omgevingen en met klanten rolde we ook vaak alleen specifieke veranderingen en/of klantapplicaties uit. En dan periodiek alles. Wat mij betreft is dat een prima verhouding, maar dat is natuurlijk een kwestie van smaak. Net zoals met veel aspecten die ik hier neerpen. Het is bijvoorbeeld ook niet verkeerd om klein te beginnen en uit te bouwen. Of een andere opzet dan de mijne te hebben.

Periodiek het hele playbook runnen zou een goed compromis zijn.
Ik zag ergens anders dat jij periodiek een release doet van je codebase.
Op dit moment doe ik een nightly release en dan apply ik de gehele omgeving. Dat zou ik nog steeds kunnen doen, maar misschien wat minder vaak (wekelijks bijv.).

Ik vind dit fijn, jij misschien niet. Prima, toch? Ik vind het vooral belangrijk om een open blik te houden naar de opzet en mening van anderen. Daar kun je alleen maar van leren .

Helemaal eens, daarom geef ik ook aan dat het misschien bij mij nog een kwestie van gewenning is.
Mijn repo is aan het groeien, ik loop al langer met de gedachtes om e.e.a. sneller te maken. Maar hoe, dat wist ik niet. Jouw aanpak met deploy per role lijkt tot nu toe een mooie oplossing en ik heb de grootste wijzigingen in mijn playbook al doorgevoerd.

Daarnaast heb ik tot nu toe bijna alles zelf geleerd wat betreft Ansible, deze discussies voeren versnelt het leerproces, dus dat vind ik erg tof! .

Oh ja. Grappig genoeg heb ik die role dus zelf gebouwd en is die vrijwel gelijk aan die van geerlingguy . Dat soort dingen zou ik in een 'group_vars/docker/all.yml' zetten en daarop laten triggeren. Of wellicht 'group_vars/docker/version.yml'. Die kun je dan direct door Renovate met een yaml comment laten bijhouden. Zo'n extra file voelt misschien gaar, maar tegelijkertijd is het wel heel erg duidelijk. Immers heb ik ook een python-version bestand in mijn repo.

Hele goede suggestie, ik was al die richting op aan het bewegen. Ik heb al een group 'pkg_docker' met de hosts waarop docker draait dus een group_vars/pkg_docker/docker_version.yml vind ik een mooie, ik moet nog e.e.a. centraliseren maar de workflow voelt zo heel logisch:

YAML:

name: Docker-ce
on:
  push:
    branches:
      - main
    paths:
      - 'inventories/production/group_vars/*/docker_version.yml'
  pull_request:
    types:
      - opened
      - synchronize
      - reopened
    paths:
      - 'inventories/production/group_vars/*/docker_version.yml'

Een renovate yaml comment had ik al voor elkaar gekregen, de docker-version string had ik al in een group var, het ging alleen om de naamgeving van de file en hoe daarop te triggeren.

Goed idee, maar ik gebruik bijna geen GitHub. En aangezien het dus nog niet in Forgejo zit, gebruik ik het sowieso niet . Ik heb er enorm veel schik in om alles zelf te hosten. Dat probeer ik dus zover als het kan. GitHub is prima, maar ik vind bijv. Copilot enorm ruk. Ook omdat ik niet alles in de cloud wil hebben...

Het ging mij meer om het principe van een merge queue, misschien is het ook wel op een andere manier te bereiken, weet ik niet.

Ik vind self-hosting ook heel gaaf, maar kies er wel voor bepaalde zaken bewust buiten de deur te houden.
Mijn resources op mijn server zijn beperkt (TrueNAS Scale draait op een HP Microserver Gen10 met 16GB ram en dat laatste is een behoorlijke bottleneck).

Daarentegen is GitHub niet mijn favoriete plek om mijn broncode op te slaan. Ik had al een GitHub account ver voor de overname van Microsoft. Liever gebruik ik een EU privacyvriendelijk alternatief. Self-hosting vind ik nog wat spannend: als mijn server of docker host down is, kan ik ook niet meer bij de broncode. Het omgekeerde is natuurlijk ook waar als GitHub besluit mijn account te closen .

Maar wat me ook nog tegenhoudt is dat ik bij Woodpecker CI (wat draaide op mijn docker host) een kip-ei probleem had. Als het Playbook mijn docker-ce package ging upgraden, stopte Woodpecker CI dus ook en hield mijn Playbook ermee op. Mijn GitHub Local Runner draait op een eigen Container op mijn TrueNAS. Dan zou ik een extra Container oid moeten hebben met een git server.

Hoe doe heb jij dat ingericht?

Wat dat betreft is zo ongeveer het enige wat ik nog echt mis is een mailserver. Laatst wel naar Docker mailserver gekeken, maar ik wilde het eigenlijk achter Traefik hebben en dat ging niet. Misschien dat ik binnenkort nog eens een poging waag.

Persoonlijk ga ik daar niet (meer) aan beginnen en is e-mail een goed voorbeeld waarvoor ik liever een privacyvriendelijk, EU-hosted alternatief zoek en daar graag voor betaal. In een ver verleden MDaemon op Windows gedraaid maar tegenwoordig pas ik daarvoor.

[alex3305]

blackd schreef op woensdag 18 maart 2026 @ 19:50:
[...]

Ik zag ergens anders dat jij periodiek een release doet van je codebase.
Op dit moment doe ik een nightly release en dan apply ik de gehele omgeving. Dat zou ik nog steeds kunnen doen, maar misschien wat minder vaak (wekelijks bijv.).

Yes. Ik doe een weekly release.



Die wordt op zondag / maandag automatisch aangemaakt, of anders op de volgende dag mocht die gemist zijn om de een of andere reden.

Verder zijn mijn release notes niets meer dan een opsomming van commits:

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Deze release doe ik voornamelijk om bij te kunnen houden waar er iets is gebeurd of eventueel misgaat. In principe zit alles in commit logs, maar ik vind dit mij net wat meer inzicht geven.

Daarnaast heb ik tot nu toe bijna alles zelf geleerd wat betreft Ansible, deze discussies voeren versnelt het leerproces, dus dat vind ik erg tof! .

Same

Hele goede suggestie, ik was al die richting op aan het bewegen. Ik heb al een group 'pkg_docker' met de hosts waarop docker draait dus een group_vars/pkg_docker/docker_version.yml vind ik een mooie.

Misschien flauw, maar waarom pkg_docker? Een eigenschap van de host is toch docker of containers en niet de package containers? Ik heb ook een group dns (of dns_server) bijvoorbeeld, die zou ik ook AdGuard Home kunnen noemen of pkg_adguardhome of container_adguardhome, maar dat vind ik niet beschrijvend genoeg en misschien ook niet helemaal de waarheid als het dns servers zijn, want het zou ook Pi-Hole kunnen zijn.

Wat ik daarmee vooral bedoel te zeggen is dat ik dus een bewust onderscheid maak ik naamgeving en merk in rollen. Immers zijn dat de pakketten die AdGuard Home of Pi-Hole installeren én de functionele groepen in de inventory. Bijvoorbeeld dns of dns_server. Waarbij dns bij mij beschrijvend genoeg is. Omdat alle machines al een dns client hebben en dat dus niet apart benoemd hoeft te worden.

Docker is in mijn geval vergelijkbaar met Luxaflex, wat eigenlijk gewoon lamellen zijn . Onder water zal het me roesten welke container technologie er draait, als ik maar zeker weet dat wanneer ik een container deploy deze daadwerkelijk opstart. Zo heb ik dus ook de groepen ci en git. Maar ook zigbee, thread en zwave. Dan kies ik er namelijk bewust voor om een host met een compatibel dongle in de juiste groep te zetten.

Het ging mij meer om het principe van een merge queue, misschien is het ook wel op een andere manier te bereiken, weet ik niet.

Ik bedoelde het niet vervelend. Het concept is me bekend en zou prachtig zijn, maar ja, als het er niet in zit kan ik het ook niet gebruiken .

Mijn resources op mijn server zijn beperkt (TrueNAS Scale draait op een HP Microserver Gen10 met 16GB ram en dat laatste is een behoorlijke bottleneck).

Ik heb jaren met een J4105 gespeeld en later ook een J1800 in een NAS. Ik weet hoe het is om met beperkte riemen te roeien . Forgejo en Gitea zijn gelukkig heel lichtgewicht. Het kan geen kwaad om een push of pull mirror te hebben. En laat die functionaliteit nou standaard in beide pakketten zitten . Dan hoef je nog geen CI te gebruiken.

Daarentegen is GitHub niet mijn favoriete plek om mijn broncode op te slaan. Ik had al een GitHub account ver voor de overname van Microsoft.

Mja same. Ik heb niet zoveel tegen Microsoft, maar ik vind Copilot / AI die mijn code analyseert en daar gratis mee leert geen heel prettig gevoel.

Liever gebruik ik een EU privacyvriendelijk alternatief.

Codeberg of GitLab zijn dan goede alternatieven.

Self-hosting vind ik nog wat spannend: als mijn server of docker host down is, kan ik ook niet meer bij de broncode. Het omgekeerde is natuurlijk ook waar als GitHub besluit mijn account te closen .

Dan moet je zorgen dat je server of Docker niet down is . Duidelijk een skill issue . Nee joh, slap geouwehoer.

Ik maak met Kopia incrementele, versleutelde, de-duplicerende backups van mijn data en daar kan ik, zo heb ik inmiddels geleerd, goed op vertrouwen. Ik maak periodiek ook koude kopieën en de data schrijf ik weg naar een remote server en een Drive. Daarnaast heb ik uiteraard een kopie van mijn Git repo op mijn workstation. Kwijtraken zal mij dus niet bijster snel overkomen. En herstel heb ik al meermaals uitgetest.

Maar wat me ook nog tegenhoudt is dat ik bij Woodpecker CI (wat draaide op mijn docker host) een kip-ei probleem had. Als het Playbook mijn docker-ce package ging upgraden, stopte Woodpecker CI dus ook en hield mijn Playbook ermee op. Mijn GitHub Local Runner draait op een eigen Container op mijn TrueNAS. Dan zou ik een extra Container oid moeten hebben met een git server.

Hoe doe heb jij dat ingericht?

Dat is bij mij ook nog een heikel punt. Ik heb daar wel over nagedacht en kwam tot een paar oplossingen:

• Uitvoeren vanaf mijn workstation
• Host A Host B laten updaten en daarna vice-versa
• Tijdelijk een extra container opzetten, de build afbreken, starten in de tijdelijke container en weer weggooien
• Permanent een container laten draaien voor updates

De tweede optie is op zichzelf het meest geschikt, maar nu voer ik het periodiek uit vanaf mijn workstation. Forgejo wordt ook niet bijster vaak geügpraded en dat geeft vooralsnog geen problemen.

[blackd]

alex3305 schreef op woensdag 18 maart 2026 @ 21:17:
Yes. Ik doe een weekly release.

Verder zijn mijn release notes niets meer dan een opsomming van commits:

Deze release doe ik voornamelijk om bij te kunnen houden waar er iets is gebeurd of eventueel misgaat. In principe zit alles in commit logs, maar ik vind dit mij net wat meer inzicht geven.

Hier hetzelfde qua release notes.
Maar doe jij dan ook die periodieke uitrol?

Misschien flauw, maar waarom pkg_docker?

Sorry voor je relaas en ik snap je helemaal, maar ik had al een host genaamd docker en wilde geen name collisions.

Ik heb jaren met een J4105 gespeeld en later ook een J1800 in een NAS. Ik weet hoe het is om met beperkte riemen te roeien . Forgejo en Gitea zijn gelukkig heel lichtgewicht. Het kan geen kwaad om een push of pull mirror te hebben. En laat die functionaliteit nou standaard in beide pakketten zitten . Dan hoef je nog geen CI te gebruiken.

Dat is best interessant, dat ga ik eens onderzoeken.

Codeberg of GitLab zijn dan goede alternatieven.

Ik maak met Kopia incrementele, versleutelde, de-duplicerende backups van mijn data en daar kan ik, zo heb ik inmiddels geleerd, goed op vertrouwen.

Hier moet ik nog wat mee, dat is ook de reden dat ik geen Immich draai maar een dienst afneem.

Ik zou ook paperless willen draaien, maar dan moet ik wel de backup strategie strak in orde hebben.

Dat is bij mij ook nog een heikel punt. Ik heb daar wel over nagedacht en kwam tot een paar oplossingen:

• Uitvoeren vanaf mijn workstation
• Host A Host B laten updaten en daarna vice-versa
• Tijdelijk een extra container opzetten, de build afbreken, starten in de tijdelijke container en weer weggooien
• Permanent een container laten draaien voor updates

De tweede optie is op zichzelf het meest geschikt, maar nu voer ik het periodiek uit vanaf mijn workstation. Forgejo wordt ook niet bijster vaak geügpraded en dat geeft vooralsnog geen problemen.

Ik had Woodpecker op een gegeven moment uit de playbook gehaald met tags en die update ik vanaf mijn pc. Dat ging goed. Maar docker is een ander verhaal.

De Github runner update zichzelf. In de container draait verder niet zoveel.
Dus op dit moment houd ik die container buiten schot wat betreft de playbooks.

Misschien is ansible-pull ook nog een alternatief?
Door met een scheduled task op de machine zelf het playbook uit te voeren.
Ik heb het verder nog niet gebruikt, dus misschien sla ik de plank compleet mis.

[alex3305]

blackd schreef op woensdag 18 maart 2026 @ 22:13:
[...]

Hier hetzelfde qua release notes.
Maar doe jij dan ook die periodieke uitrol?

Nee, nog niet. Dat is 's nachts en ik doe geen uitrollen 's nachts.

Wederom is dit iets wat ik op mijn lijstje heb staan, maar gewoon nog geen noodzaak voor heb gehad of niet aan ben toegekomen.

Sorry voor je relaas en ik snap je helemaal, maar ik had al een host genaamd docker en wilde geen name collisions.

Maak je niet druk . Ik ben tijdens mijn studie en later tijdens mijn werk doodverveeld met functional en non-functional requirements. Blijkbaar heeft het toch indruk gemaakt . Inmiddels is het een concept waar ik wat strakker aan vast houd. Het helpt dan ook als ik ergens van dienst wissel. Mijn vrouw of ik hoeven dan bijvoorbeeld geen nieuwe / andere URL te onthouden voor zoiets als de router, want dat is gewoon 'router.domein.nl' en niet 'asus.domein.nl' of 'unifi.domein.nl'.

Hier moet ik nog wat mee, dat is ook de reden dat ik geen Immich draai maar een dienst afneem.

Ik zou ook paperless willen draaien, maar dan moet ik wel de backup strategie strak in orde hebben.

Immich en Paperless zijn twee van mijn meest gebruikte diensten . Kopia is op zichzelf niet bijster complex om op te zetten of te beheren. Het is ook niet super fancy of zo. Van Docker applicaties neem ik over het algemeen ook gewoon snapshots mee, behalve van databases ivm WAL. Die gooi ik dan in een .kopiaignore. Van de databases maak ik overigens een dump en die neem ik dan wel mee in de backup.

Maar docker is een ander verhaal.

Ah, dat was even niet binnengekomen . Ja, niet dus ...

Misschien is ansible-pull ook nog een alternatief?
Door met een scheduled task op de machine zelf het playbook uit te voeren.
Ik heb het verder nog niet gebruikt, dus misschien sla ik de plank compleet mis.

Zag ik laatst ook langskomen. Neem ik ook nog even mee. Dit zou mij ook nog helpen voor wat andere zaken waar ik evt. een Ansible task of play wil uitvoeren zonder dat ik direct allemaal rechten hoef toe te kennen .

[blackd]

alex3305 schreef op woensdag 18 maart 2026 @ 22:38:
Dat is 's nachts en ik doe geen uitrollen 's nachts.

Wat misschien nog wel een interessante aanpak is om je playbook in --diff mode te draaien. Hiermee zie je verschillen t.o.v. desired state. Dat in combinatie met --check mode, kun je als het ware controleren in hoeverre je afwijkt van je gewenste configuratie. Dat zou je prima 's nachts kunnen draaien, waarna je 's ochtends een lijstje met afwijkingen kan raadplegen en kijken of er actie nodig is.

Je moet dan alleen wel goed in de smiezen houden of je tasks geen ongewenste changes aanbrengen op het systeem. In een paar van mijn playbooks update ik de apt cache en dat resulteert in een changed state. Je kan dan uren discussieren of dat gewenst is of niet, maar het rapporteert wel zo (tenzij je changed_when opgeeft).

Inmiddels is het een concept waar ik wat strakker aan vast houd. Het helpt dan ook als ik ergens van dienst wissel.

Ik snap je, maar dit ging om een groep van hosts waar docker draait. Eigenlijk dus 'dockerhosts' of 'dockerservers' (analoog aan webservers, dbservers) in het patroon group inventory by function. Ik heb nl. 3 machines waar docker-ce op draait: twee dnsservers en een TrueNAS machine.

Maar eigenlijk zou het iets als 'container orchestration' moeten noemen, dan kan dat docker, podman, lxc, k8s, etc. zijn. Maar ja, aan de andere kant kan ik het ook niet zomaar uitwisselen. Mijn roles zijn toegespitst op docker (compose) dus niet eenvoudig uitwisselbaar.

[blackd]

alex3305 schreef op woensdag 18 maart 2026 @ 22:38:
Kopia is op zichzelf niet bijster complex om op te zetten of te beheren. Het is ook niet super fancy of zo. Van Docker applicaties neem ik over het algemeen ook gewoon snapshots mee, behalve van databases ivm WAL. Die gooi ik dan in een .kopiaignore. Van de databases maak ik overigens een dump en die neem ik dan wel mee in de backup.

Ik heb een andere backup strategie, namelijk dat TrueNAS verantwoordelijk is voor het backuppen van de data naar twee online storage providers (ook dat is nog US based en staat nog op mijn lijstje, maar goed, kan niet alles tegelijk ).

Backup van mijn data op TrueNAS is dus wel geregeld, maar voor mijn docker apps nog niet. Kopia is voor mij niet perse nodig want op zich ben ik tevreden met de replicatie die in TrueNAS is ingebouwd.

Per Docker compose project heb ik grofweg de volgende structuur:
- Een folder waarin het compose project staat waar docker compose up gedaan wordt
- Een folder (met verschillende subfolders) waar alle data leeft, dit splits ik op per compose project per service, dus bijv.

code:

..../authentik/redis/data
..../authentik/postgresql/data
..../authentik/server/media

Wil ik een backup van authentik data, dan zou ik die authentik folder dus helemaal kunnen repliceren zodat deze wordt meegenomen in de backup van TrueNAS.
Maar voor de database, zoals je zelf al schetst, is dat wat uitdagender want dan moet je een db dump hebben en die meenemen in de backup.

Hoe pak jij dit aan?

Een mogelijke aanpak die ik had bedacht is om een backup playbook of task te maken die voor elke postgresql db een dump maakt. Of omgekeerd, eigenlijk zou ik per app een backup task willen hebben en dan voor alle apps de backup task willen runnen.

Veel apps hebben geen database en zijn eenvoudig te backuppen (ZFS snapshot zou voldoende zijn), maar ik heb er een paar met een eigen database. Sommige apps hebben ook een backup / export functie, denk aan de unifi controller. Dus eigenlijk wil ik dat per app afhandelen.

De stappen zijn hier beschreven met gebruik van de postgres_db Ansible module. Dat zou dan voor één app werken, dat wil ik dan doortrekken naar meerdere apps.

Of is dit bij jou onderdeel van een Kopia action?

[alex3305]

@blackd Goede vraag, daar ben ik toevallig de afgelopen week mee bezig geweest .

Momenteel draai ik vanuit Unraid's crontab een script om een database dump te maken. Bijvoorbeeld:

Bash:

# MariaDB
docker exec -i home-assistant-database sh -c 'mariadb-dump --all-databases > /var/lib/mysql/dump.sql'

# PostgreSQL
docker exec -i paperless-ngx-database sh -c 'PGPASSWORD=$POSTGRES_PASSWORD pg_dumpall --username=$POSTGRES_USER' > /mnt/applications/appdata/paperless-ngx/database.sql

Dat gaat periodiek en dat gaat dus ook periodiek met de Kopia backup mee. Waarom niet vanuit Kopia zelf? Omdat Kopia dan rechten zou moeten hebben in de containers of op de host. Dat is niet iets wat ik wil.

Eerder in dit topic heeft @Mars Warrior aangegeven dat hij een DB Backup container gebruikt en die richting wilde ik eigenlijk ook op. Echter ben ik de afgelopen week met Ofelia bezig geweest.

Ofelia is een relatief simpele task scheduler die gebruik maakt van Docker labels. Omdat het simpel is kost het ook weinig resources. Tegelijkertijd wil ik ook niet veel functies, behalve taken. Maar bovenstaande wordt dan dus:

YAML:

services:
  mariadb:
    labels:
      ofelia.enabled: true
      ofelia.job-exec.home-assistant-database-dump.schedule: "35 */4 * * *"
      ofelia.job-exec.home-assistant-database-dump.command: "sh -c 'mariadb-dump --all-databases > /var/lib/mysql/dump.sql'"

Nu heb ik dit nog niet getest, maar andere tasks zoals het syncen van mijn backups en een andere database dump waarmee ik test lijken vooralsnog prima te werken .

[blackd]

@alex3305 Thanks voor het uiteenzetten van de opties, dat helpt enorm. De route van Ofelia als task scheduler en dan per compose project je database dump definieren als label spreekt mij op dit moment het meeste aan.

Je draait dan het commando in de container (in dit geval van de mariadb van Home Assistant) en plaatst de database dump dan in een directory die gemount is op het host systeem, waarna Kopia dit oppikt en meeneemt in de backup?

[alex3305]

blackd schreef op zaterdag 21 maart 2026 @ 14:56:
Je draait dan het commando in de container (in dit geval van de mariadb van Home Assistant) en plaatst de database dump dan in een directory die gemount is op het host systeem, waarna Kopia dit oppikt en meeneemt in de backup?

Excuses, ik besef me nu dat ik daar een klein beetje te summier was .

Het commando wordt inderdaad uitgevoerd in de Docker container en de dump wordt in dezelfde directory geplaatst als de database files van MariaDB of PostgreSQL. Alhoewel dat normaliter niet helemaal gewenst is, vind ik dat wel het meest praktisch. Een extra mount zou ook nog kunnen als je wat meer scheiding zou wensen.

Ik regel dan met een .kopiaignore dat de raw database bestanden niet meegenomen worden. Bijvoorbeeld bij Home Assistant:

code:

config/*.log
config/*.log*
config/tmp_core_entity

database/*
database/**
!database/dump.sql

Toevallig heb ik deze setup nog niet geactiveerd voor Home Assistant, maar wel bij mijn Outline wiki en daar ziet er dat in Kopia dan zou uit:

[blackd]

blackd schreef op zondag 14 december 2025 @ 14:18:
Wat snippets van mijn ansible-ee repo:
execution-environment.yml

YAML:

--
version: 3

images:
  base_image:
    name: ghcr.io/ansible/community-ansible-dev-tools:v25.11.0@sha256:c3ee333e84517404d0940e9fd97b247b18cf60e957cbd1bb45e79ca84848beaa

dependencies:
  galaxy: requirements.yml
  python: requirements.txt

additional_build_steps:
  [..]

In de additional_build_steps installeer ik:

• glibc-langpack-en (via dnf)
• docker-ce-cli (via install script)
• nodejs npm (via dnf)
• gh-cli (via dnf)
• dclint (via npm)
• action-validator (via npm)

Weer even gestoeid met mijn execution environment.
Aanleiding was dat Fedora42 standaard met nodejs22 komt en Renovate config validator nodejs24 prefereert.
Dat laatste heb ik helaas niet helemaal kunnen oplossen zoals ik het wilde.

Mijn nieuwe execution-environment.yml:

YAML:

---
version: 3

images:
  base_image:
    name: ghcr.io/ansible/community-ansible-dev-tools:v26.3.1@sha256:026a44e20b2d66d4192a1cc8d9dbd17a53b58ced4a7b75c01eafbcdf70f6ae98

dependencies:
  galaxy: requirements.yml
  python: requirements.txt
  system: bindep.txt

additional_build_files:
  - src: files/docker-ce.repo
    dest: configs
  - src: files/gh-cli.repo
    dest: configs
  - src: files/task.repo
    dest: configs

additional_build_steps:
  prepend_base:
    - ADD _build/configs/docker-ce.repo /etc/yum.repos.d/docker-ce.repo
    - ADD _build/configs/gh-cli.repo /etc/yum.repos.d/gh-cli.repo
    - ADD _build/configs/task.repo /etc/yum.repos.d/task.repo

  append_final:
    - RUN npm install --g dclint@3.1.0
    - RUN npm install --g @action-validator/core @action-validator/cli --save-dev
    - RUN dnf clean all && rm -rf /var/cache/dnf
    - RUN rm -rf /tmp/* /var/tmp/*

De grote verschillen:

1. system: bindep.txt toegevoegd, dit is een lijst met packages die via de package manager geinstalleerd worden. Hiervoor had ik RUN dnf install -y commando's in de append_base stap.
2. additional_build_files bevat nu 3 custom repo's voor docker-ce, gh-cli en task. Die laatste was nog lastig, maar uiteindelijk via de juiste URL een config weten te downloaden. Deze files kopieer ik naar de juiste plek in de additional_build_steps.
3. append_final hier installeer ik nu twee npm dependencies, via bindep.txt lukte me dat niet dus dan maar zo.

Het lukte mij ook niet de nodejs standaard naar 24 te krijgen. met dnf nodejs24 installeren lukt wel, maar dan is hij nog niet de default. Als iemand nog tips heeft hiervoor.. (gaat om fedora 24). Hier staat uitgelegd hoe je extra versies kunt installeren. De route via dnf modules werkt niet meer. Via nvm wordt heel omslachtig met install scripts.

bindep.txt: welke door ansible-builder gebruikt wordt:

code:

jq [platform:rpm]
docker-ce-cli [platform:rpm]
gh [platform:rpm]

Het jammere is dan weer dat bindep.txt wel versies ondersteunt (analoog aan pip) maar dat ansible-builder dat weer niet snapt. Kan ik de versies niet pinnen.

Uiteindelijk ervoor gekozen nodejs24 via een feature in devcontainer te installeren:

JSON:

{ 
  [..]
  "features": {
    "ghcr.io/devcontainers/features/node:1": {
      "version": "24.14.0",
      "nvmVersion": "0.39.5"
    }
  },
  [..]
}

Daardoor duurt het rebuilden wel wat langer, dus liever zou ik nodejs24 als default hebben in de container.

[witchdoc]

ja watte....
Leuk verhaal dat ansible maar een stap te ver voor mij vrees ik.

Wat is de beginners editie hiervan?
Ik zoek 'iets' dat simpeler is dan ansible maar wel beter is dan mijn huidige manier: notepad++ met compose files hier en daar zonder enige versioning of automatisering en af en toe nog een docer run erbij ook als de guide dat voorstelt.

Dat dit niet goed werkt heb ik ondertussen door, maar hoe start ik de weg naar iets beter? Weet dat ik noch Linux guru, noch coder ben maar wel wil leren.

Zit zelf op Windows PC met docker op een Proxmox Host met Docker VM.

- VSCode? na installeren Connect to docker host? Verder helaas option overload dus nog steeds geen idee hoe ik het nu echt zou gebruiken.
EDIT: ok, 'gewoon' SSH naar de docker en je kan rechtstreeks op die machine compose file sbeheren met leuke kleurtjes

- Git? Self-hosted? lab? hub? hoe

Hoe hangt dit allemaal aan elkaar?

[ Voor 6% gewijzigd door witchdoc op 21-04-2026 18:33 ]

[synoniem]

witchdoc schreef op dinsdag 21 april 2026 @ 12:32:
ja watte....
Leuk verhaal dat ansible maar een stap te ver voor mij vrees ik.

Wat is de beginners editie hiervan?
Ik zoek 'iets' dat simpeler is dan ansible maar wel beter is dan mijn huidige manier: notepad++ met compose files hier en daar zonder enige versioning of automatisering en af en toe nog een docer run erbij ook als de guide dat voorstelt.

Dat dit niet goed werkt heb ik ondertussen door, maar hoe start ik de weg naar iets beter? Weet dat ik noch Linux guru, noch coder ben maar wel wil leren.

Zit zelf op Windows PC met docker op een Proxmox Host met Docker VM.

- VSCode? na installeren Connect to docker host? Verder helaas option overload dus nog steeds geen idee hoe ik het nu echt zou gebruiken.
- Git? Self-hosted? lab? hub? hoe

Hoe hangt dit allemaal aan elkaar?

Ik heb zowel Dockerfile, docker-compose.yml als de container image zelf in Forgejo (voorheen Gitea) staan (git, container registry en runners ineen). Daarmee heb je versiebeheer van de drie belangrijke onderdelen van Docker. Voor de data heb je meerdere keuzes de meeste van mijn projectjes gebruiken een database of bind volumes die bij allemaal onder de map data staan en dagelijks gebackupped worden naar een externe locatie. Voor Kubernetes/Swarm projecten gebruik ik Rancher voor shared volume of databases of REST api's.

Forgejo/Gitea draai ik overigens ook in Docker maar is een aparte VM die in zijn geheel door Proxmox dagelijks gebackupped wordt naar een externe locatie.

[Wienen]

witchdoc schreef op dinsdag 21 april 2026 @ 12:32:
ja watte....
Leuk verhaal dat ansible maar een stap te ver voor mij vrees ik.

Wat is de beginners editie hiervan?
Ik zoek 'iets' dat simpeler is dan ansible maar wel beter is dan mijn huidige manier: notepad++ met compose files hier en daar zonder enige versioning of automatisering en af en toe nog een docer run erbij ook als de guide dat voorstelt.

Dat dit niet goed werkt heb ik ondertussen door, maar hoe start ik de weg naar iets beter? Weet dat ik noch Linux guru, noch coder ben maar wel wil leren.

Zit zelf op Windows PC met docker op een Proxmox Host met Docker VM.

- VSCode? na installeren Connect to docker host? Verder helaas option overload dus nog steeds geen idee hoe ik het nu echt zou gebruiken.
EDIT: ok, 'gewoon' SSH naar de docker en je kan rechtstreeks op die machine compose file sbeheren met leuke kleurtjes

- Git? Self-hosted? lab? hub? hoe

Hoe hangt dit allemaal aan elkaar?

Ik ben recentelijk aan mijn Homelab avontuur begonnen (en dus ook nog een redelijke leek, maar met mijn IT achtergrond wel heel snel lerende) en heb daarvoor Unraid draaien, met daarop een container met de app Dockhand.

Dit is een container manager waar je heel gemakkelijk al je docker apps kunt beheren. Er zit al een goede compose/env editor in verwerkt, maar deze doet niet aan versiebeheer.

Daarom heb ik Gitea lokaal gehost en deze gekoppeld aan mijn lokaal gehoste Code Server (VS Code) zodat ik nu Code Server gebruik voor het schrijven van m'n yaml/env files, en gitea gebruik voor het bewaren van mijn files en het versiebeheer daarop. Gitea kun je vervolgens weer aan dockhand koppelen zodat je na een commit eventueel automatisch je containers kan laten redeployen.

Dit alles was zelfs voor mij als beginner "relatief" eenvoudig te installeren. Ik heb alles uitgebreid gedocumenteerd (welliswaar in het engels en door AI) maar beschrijft exact alle benodigde stappen en bevat ook mijn deelbare config files. Mocht je interesse hebben dan stuur me maar een DM.

[divvid]

docker compose vraagje: mijn script geeft output over iteraties. Als ik het run met

code:

docker run

dan krijg ik direct de output. Als ik docker compose build/up gebruik, dan krijg ik de output pas als alle iteraties klaar zijn (en dat is nou net niet de bedoeling).

Hoe kan ik dat oplossen
script is een simpel python ding in python 3.11-slime image

[RobertMe]

divvid schreef op zaterdag 2 mei 2026 @ 12:34:
docker compose vraagje: mijn script geeft output over iteraties. Als ik het run met

code:

docker run

dan krijg ik direct de output. Als ik docker compose build/up gebruik, dan krijg ik de output pas als alle iteraties klaar zijn (en dat is nou net niet de bedoeling).

Hoe kan ik dat oplossen
script is een simpel python ding in python 3.11-slime image

Als ik docker compose up doe dan zie ik gewoon live alle stdout / stderr output van de container (/software in de container). Note: zonder -d dus, dan draait die op de achtergrond en zie je dus helemaal geen output.

[dehardstyler]

Wienen schreef op woensdag 22 april 2026 @ 09:20:
[...]


Ik ben recentelijk aan mijn Homelab avontuur begonnen (en dus ook nog een redelijke leek, maar met mijn IT achtergrond wel heel snel lerende) en heb daarvoor Unraid draaien, met daarop een container met de app Dockhand.

Dit is een container manager waar je heel gemakkelijk al je docker apps kunt beheren. Er zit al een goede compose/env editor in verwerkt, maar deze doet niet aan versiebeheer.

Daarom heb ik Gitea lokaal gehost en deze gekoppeld aan mijn lokaal gehoste Code Server (VS Code) zodat ik nu Code Server gebruik voor het schrijven van m'n yaml/env files, en gitea gebruik voor het bewaren van mijn files en het versiebeheer daarop. Gitea kun je vervolgens weer aan dockhand koppelen zodat je na een commit eventueel automatisch je containers kan laten redeployen.

Dit alles was zelfs voor mij als beginner "relatief" eenvoudig te installeren. Ik heb alles uitgebreid gedocumenteerd (welliswaar in het engels en door AI) maar beschrijft exact alle benodigde stappen en bevat ook mijn deelbare config files. Mocht je interesse hebben dan stuur me maar een DM.

Ik vind Dockhand ook top, gebruik het nu 3 maanden ofzo denk ik. Gebruik je hierbij dan gevulde .env files? Ik zit nu nog elke keer in een Github private repo te klooien, maar zelfs daar wil ik geen secrets in etc, dus dan moet ik weer met .env.example werken. Misschien moet ik het ook maar gewoon lokaal hosten.

[synoniem]

dehardstyler schreef op zaterdag 2 mei 2026 @ 13:16:
[...]


Ik vind Dockhand ook top, gebruik het nu 3 maanden ofzo denk ik. Gebruik je hierbij dan gevulde .env files? Ik zit nu nog elke keer in een Github private repo te klooien, maar zelfs daar wil ik geen secrets in etc, dus dan moet ik weer met .env.example werken. Misschien moet ik het ook maar gewoon lokaal hosten.

Dat is de reden dat ik voorheen Gitea nu Forgejo lokaal (in docker) heb draaien. Heb je en een git-repo en een docker registry en de mogelijkheid van actions/runners.

[Wienen]

dehardstyler schreef op zaterdag 2 mei 2026 @ 13:16:
[...]


Ik vind Dockhand ook top, gebruik het nu 3 maanden ofzo denk ik. Gebruik je hierbij dan gevulde .env files? Ik zit nu nog elke keer in een Github private repo te klooien, maar zelfs daar wil ik geen secrets in etc, dus dan moet ik weer met .env.example werken. Misschien moet ik het ook maar gewoon lokaal hosten.

Mijn .env zijn voorzien van alle variabelen en de bijbehorende waardes. Enkel de variabelen van mijn secrets zijn niet voorzien van waardes. Bij het toevoegen van een nieuwe stack importeer ik mijn yaml/env vanuit gitea, dockhand geeft dan aan dat de waardes voor mijn secret variabelen nog handmatig ingevuld moeten worden. Dit doe ik vanuit mijn password manager (zodat ik deze nog wel ergens achter de hand heb) en druk dan op het sleuteltje zodat ze in de vault van Dockhand opgeslagen worden. Vanaf dat moment zijn ze in Dockhand ook niet meer uit te lezen. (vandaar het gebruik van de PW manager)

[dehardstyler]

Wienen schreef op zaterdag 2 mei 2026 @ 14:29:
[...]


Mijn .env zijn voorzien van alle variabelen en de bijbehorende waardes. Enkel de variabelen van mijn secrets zijn niet voorzien van waardes. Bij het toevoegen van een nieuwe stack importeer ik mijn yaml/env vanuit gitea, dockhand geeft dan aan dat de waardes voor mijn secret variabelen nog handmatig ingevuld moeten worden. Dit doe ik vanuit mijn password manager (zodat ik deze nog wel ergens achter de hand heb) en druk dan op het sleuteltje zodat ze in de vault van Dockhand opgeslagen worden. Vanaf dat moment zijn in Dockhand ook niet meer uit te lezen. (vandaag het gebruik van de PW manager)

Dat is nog mooier indd! Ik ga ef knutselen binnenkort.

[Wienen]

Succes 💪🏻 en bij vragen weet je me te vinden!

[divvid]

@RobertMe dat was dus ook wat ik veronderstelde, maar dat gebeurt dus niet. Het lijkt wel of alle output gecached wordt en pas aan het einde van het script weergegeven wordt. Overigens draai ik zonder -d

Inmiddels opgelost. Niet zozeer een docker dingetje, maar een python dingetje. Blijkbaar buffert python de output in non-shell envs.

In de yaml file moet je

code:

environment:
      - PYTHONUNBUFFERED=1

specificeren, anders wordt de output door python blijkbaar gebufferd.
typisch zo'n dingetje waar je een paar uur op stuk bijt. (google was ook niet erg behulpzaam)

[ Voor 47% gewijzigd door divvid op 03-05-2026 15:31 ]

[Mars Warrior]

Ik merkte in mijn CrowdSec-setup wederom dat domme gedoe dat vpatches niet tot een decision leiden omdat CrowdSec dat pas doet als een IP-adres verschillende vpatches raakt. Reden: voorkomen van false positives als een gebruiker 'per ongeluk' een vpatch raakt.

Tuurlijk. Die gaat 'per ongeluk' toegang tot een .env file oid vragen

Oftewel: duizenden onnodige Alerts...

Werd dus tijd voor een aangepaste profiles.yaml...

YAML:

name: force_vpatch_ban
filters:
  - Alert.GetScenario() == "crowdsecurity/appsec-vpatch"
decisions:
  - type: ban
    duration: 4h
on_success: break

.
En hoppa, weg met die idiote onnodige rode Alert blokken



Nu blijf ik waarschijnlijk ook weer netjes binnen de 500 alerts per maand voor het gratis account

Verder ga ik nog wat experimenteren met mTLS. Sommige apps ondersteunen dit, dus zou ik nog wat minder alerts binnenkrijgen omdat zo'n bot al helemaal geen verbinding meer kan opbouwen…

Moet wel zeggen dat adoptie traag is. Bitwarden doet er al een jaar over om het in de iOS-app te bouwen, laat staan in de Windows-app. Moeilijk hoor die paar regels code om een certificaat mee te geven. Echt heel moeilijk, en het past elke keer net niet binnen het release window

Self-hosting heeft natuurlijk niet zo veel prioriteit als de eigen stack.

[Le Enfant!]

Edit: Opgelost door 'block bogon network' uit te schakelen in de VLAN interface in Opnsense.

Ik ben nu al een kleine week aan het proberen om een L2 ipvlan aan te maken om een aantal containers binnen een VLAN te beheren, maar dit wil maar niet lukken.
Ik heb de ipvlan aangemaakt met volgend command:
[code]
docker network create -d ipvlan \
--subnet=192.168.X.0/24 \
--gateway=192.168.X.1 \
-o parent=enp5s0.4 \
br0.4
[/code]
Volgende werd in de docker compose file geplaatst per container:
[code]services:
test:
image: test
container_name: test
networks:
br0.4:
ipv4_address: "192.168.X.3"
ports:
- 7878:7878
restart: unless-stopped


networks:
br0.4:
external: true
name: br0.4[/code]

De port van de container staat gedefinieerd in deze file, maar bij het testen heb ik dit weggelaten in de docker compose.

Als ik vanaf mijn laptop de web interface van de containers probeer te bereiken, dan krijg ik een foutmelding dat de pagina niet kan bereikt worden.
Als ik ping vanaf de VLAN van de laptop of vanaf de opnsense firewall naar een IP binnen de IPvlan, dan krijg ik geen reply.
Als ik een trace laat lopen vanaf de VLAN van de laptop of vanaf de firewall naar een IP binnen de IPvlan, dan krijg ik een reply tot en met de fysieke docker host. Maar vanaf dan krijg ik geen reply.
Als ik ping vanuit de docker containers naar de default gateway, dan krijg ik geen reply. Als ik ping vanaf de container naar andere containers binnen de IPvlan, dan lukt dit wel. Pingen naar de docker host lukt dan weer niet, maar dit is normaal gedrag volgens de documentatie van Docker.

Wat heb ik tot nu toe allemaal geprobeerd:
- promiscuous mode ingeschakeld op zowel de docker host als de VLAN interface op de opnsense firewall,
- als test een static route aangemaakt op zowel de docker host, docker container als op de opnsense firewall
- port forwarding op de docker host ingeschakeld
- de poort van de switch waar de fysieke docker host mee is verbonden aangepast naar een trunk port.
- Als test een macvlan netwerk aangemaakt, maar daar hetzelfde probleem
- Als test een L3 IPvlan aangemaakt met een static route en dat lukt wel. Maar dan loopt al het verkeer binnen de VLAN van de docker host en niet op de VLAN van de containers.

In principe zou het moeten lukken volgens de Docker documentatie en volgens Claude, maar toch wil het maar niet werken. Ik heb tevens nog eens alles overlopen met Claude, maar daar draaien we ondertussen ook rondjes.

Iemand die me op weg kan helpen om dit probleem op te lossen? Ik zie even door de bomen het bos niet.

[Arunia]

Na ondertussen allerlei dingen gefixt te hebben ook buiten Docker om.
Ga ik toch kijken of ik binnenkort Docker Desktop onder Windows kan uit faseren en over te stappen naar iets anders, of gewoon plat WSL2. Maar blijf het spannend vinden om "opnieuw" te beginnen. Plat een backup maken lijkt niet mogelijk te zijn zodat ik die weer terug kan zetten in een nieuwe omgeving. Heb hier echt al tig keer naar gezocht. Maar eerlijk is eerlijk, zoveel dingen draai ik nog niet welke of een backup nodig hebben of eigenlijk wel met een eigen backup deels teruggezet kunnen worden.
Veel is nog in de teststadium, maar het voelt moeilijk om gewoon te zeggen dat ik genoeg in een backup heb zitten en Docker Desktop deinstalleer en dan of iets nieuws, of gewoon Portainer onder WSL2 docker draai.

Ja, ik ben een twijfelaar en altijd geweest.

[Wienen]

Ik ben een paar maanden geleden geswitcht van Windows (met docker desktop) naar Unraid. Dit is allemaal probleemloos verlopen. Het kost wel wat tijd, en Unraid/Linux was nieuw voor me maar met een beetje IT kennis/afiniteit kom je een heel eind!

Wil je dezelfde hardware blijven gebruiken of ga je er iets langs opbouwen? Als je er nieuwe hardware langs gaat plaatsen is het helemaal makkelijk, dan kun je eenvoudig je compose/env files en bijbehorende data overzetten en alles draait probleemloos verder. Ik ben op dezelfde hardware om gegaan en heb mijn Windows installatie omgezet naar een VM welke ik vervolgens weer binnen Unraid gemount heb om zo alles makkelijker over te kunnen zetten en altijd nog iets had om op terug te vallen.

[Arunia]

Wienen schreef op maandag 15 juni 2026 @ 16:12:
Ik ben een paar maanden geleden geswitcht van Windows (met docker desktop) naar Unraid. Dit is allemaal probleemloos verlopen. Het kost wel wat tijd, en Unraid/Linux was nieuw voor me maar met een beetje IT kennis/afiniteit kom je een heel eind!

Wil je dezelfde hardware blijven gebruiken of ga je er iets langs opbouwen? Als je er nieuwe hardware langs gaat plaatsen is het helemaal makkelijk, dan kun je eenvoudig je compose/env files en bijbehorende data overzetten en alles draait probleemloos verder. Ik ben op dezelfde hardware om gegaan en heb mijn Windows installatie omgezet naar een VM welke ik vervolgens weer binnen Unraid gemount heb om zo alles makkelijker over te kunnen zetten en altijd nog iets had om op terug te vallen.

Ik blijf gewoon bij Windows omdat ik er ook andere dingen bij heb. Ik wil Docker Desktop weg hebben omdat ik ondertussen wel weet dat er weinig extra bij komt kijken en ik heb het idee dat DD steeds meer verbruikt terwijl er eigenlijk weinig bij is gekomen.
Tuurlijk is een linux variant beter in het opzicht van Docker, maar op dit moment nog geen reden voor mij om over te stappen.

Daarnaast ook gewoon deze hardware nog. Is redelijk zuinig en nog prima voor ons gebruik. Nou ja, mijn gebruik haha.
Zodra docker goed draait en in gebruik is, kan ik altijd kijken naar een upgrade. Maar voor nu qua prijzen niet echt nuttig om die stap te maken.

/edit:
Ik heb nu net Docker Desktop verwijderd... Here goes nothing! Moet toch ergens beginnen. Ben benieuwd wat het geheugen verbruik gaat doen nadat WSL2 ingesteld is met Docker.
Verwijderen van DD zorgt ook voor het verwijderen van de VM met Docker erin. Ging er niet vanuit, maar had wel een backup van wat ik echt met alles erbij terug wilde hebben.

[ Voor 10% gewijzigd door Arunia op 16-06-2026 11:18 ]

[Wienen]

De reden dat ik van Docker Desktop/Windows ben afgestapt is omdat dit toch niet echt lekker performde, en ik zaken beter wou isoleren. Daarnaast bleek na onderzoek dat 99% van de applicaties welke ik gebruikte er ook een docker image van was.

Voor het andere deel heb ik een Windows VM opgetuigd binnen Unraid zodat ik daar altijd nog op terug kan vallen.

Succes met je migratie 💪🏻

[Arunia]

@Wienen Voor zover zal het bij mij nooit een hele grote omgeving worden. Wel is me opgevallen dat het sinds een half jaar ontzettend veel verbruikt. Mits dat het gedeelte was hoor.

Qua installeren met tutorials is het niet heel erg makkelijk.
Enige wat ik zoek is WSL2, Docker en Docker-Compose met dezelfde uitkomst als middels Docker Desktop.
Alleen om één of andere reden loop je toch tegen vage problemen aan.
Docker hello-world doet het in ieder geval. Alleen nu Portainer dan nog wat ik dan het liefste via docker-compose doe, maar wellicht moet ik daar gewoon vanaf stappen.
Zodra portainer erop staat, kan ik kijken of ik daar bij kom en of het naar buiten toe in het netwerk zelf ook werkt.

Enige voordeel is dat DD dit wel automagisch doet voor je. Genoeg mensen die het zonder DD willen, maar om één of andere reden is iedere uitleg weer anders. Wellicht toch dat iedereen het anders doet.

Maar, het lijkt erop dat Portainer nu wel geinstalleerd is. Volgende stap is automatisch laten starten bij een herstart van Windows. Zelfde probleem met Docker Desktop, maar ook dat is opgelost. Startte hiervoor eerst Windows en dan een batch bestand welke Windows weer locked. >_>

[ Voor 13% gewijzigd door Arunia op 16-06-2026 17:19 ]

[Mars Warrior]

Om nog even terug te komen op een onderwerp van denk ik 6 maanden geleden

Op het werk heeft men een server bijeengesprokkeld. Die is dus gratis vanuit de boekhouding gezien, maar heeft wel een 24 core Xeon, 256GB RAM, en over het 10/40GBit netwerk SSD storage

Dus dat is geregeld. Nu ging het tig maanden geleden over het inrichten van deze server. Hij draait op Proxmox + PBS. Ik ga daar 2 VMs maken:

• een VM voor GitOps
• een VM voor productie

Het grootste punt zit in het onderhoud van alle containers. Dus Ansible gaat niet gebeuren

Ik neig nu sterk naar:

• Forgejo + runner
• Renovate
• Portainer BE (gratis voor 3 nodes) met Edge Agent op de productie node. Die kan vanuit Git een compose file met alles wat daarbij hoort halen en deployen. Klaar
• Mogelijk wat extra's per container om wat scripting en testen uit te voeren in plaats van de standaard image entry, en die dan aanroepen. Ben ik van alles af. Ook geen gezeur meer met depends_on bij reboot van server.

Zou perfect moeten werken volgens de documentatie.

Erbij:

Als ik meer controle wil hebben is Komodo ook een perfect alternatief. Die kan het bouwen van eigen containers en backuppen van databases ook overnemen. Is dat ook meteen verzorgd en hoef ik ook daar verder niks extra's voor te regelen.

Komodo kan ook met SOPS werken zodat alle .env files ook on the fly tijdens deployment gedecrypt worden. Een VScode plugin doet dat ook met decrypt/encrypt, dus dan kunnen er ook geen wachtwoorden en andere sleutels in git/forgejo komen.

Rathole zou ik dan daarbij als container kunnen gebruiken om een tunnel / bridge op te zetten, zodat ik nog zelf wel lekker met SSH en een browser (socks5) overal bij kan komen, zonder dat poort 22 open moet staan. Daar houden ze niet zo van...

[ Voor 24% gewijzigd door Mars Warrior op 17-06-2026 09:08 ]

[Arunia]

Vandaag Docker Engine in WSL2 draaiend waarbij ik Portainer op andere clients aan kan spreken.
Rustdesk en Mealie geinstalleerd waarbij er wel melding gegeven wordt dat de verbinding actief is, maar toch niet helemaal lekker werkt.
Mealie lijkt ook niet helemaal te werken. Container draait, maar daar kom ik dan weer niet bij. Aparte is dan weer dat bij mijn vorige niet Stack variant er 2 poorten open stonden en bij deze dat niet zo is. Maar goed, basis is gelegd. De rest komen we ook wel uit natuurlijk.

[Wienen]

Arunia schreef op woensdag 17 juni 2026 @ 16:25:
Vandaag Docker Engine in WSL2 draaiend waarbij ik Portainer op andere clients aan kan spreken.
Rustdesk en Mealie geinstalleerd waarbij er wel melding gegeven wordt dat de verbinding actief is, maar toch niet helemaal lekker werkt.
Mealie lijkt ook niet helemaal te werken. Container draait, maar daar kom ik dan weer niet bij. Aparte is dan weer dat bij mijn vorige niet Stack variant er 2 poorten open stonden en bij deze dat niet zo is. Maar goed, basis is gelegd. De rest komen we ook wel uit natuurlijk.

Ik wil graag met je meedenken, maar dan zul je toch wel met iets meer info moeten komen. Wellicht enkel ter info bedoeld

[Arunia]

Wienen schreef op woensdag 17 juni 2026 @ 18:47:
[...]

Ik wil graag met je meedenken, maar dan zul je toch wel met iets meer info moeten komen. Wellicht enkel ter info bedoeld

Haha, soms post ik gewoon inderdaad ter info. Dat niet altijd alles van een leien dakje gaat.
Maar het lijkt nu wel te werken, ook na een Windows herstart komt bijvoorbeeld Portainer weer op. Dus, Mijn WSL2 start automatisch en daarin Docker ook. Kostte wat moeite om de juiste uitleg te vinden.

Nu nog wat dingen fixen en het liefste had ik eigenlijk bepaalde mappen op Windows beschikbaar gehad, maar het is wat het is. Denk ook gewoon gewenning. Ik weet hoe het werkt en kan straks ook bepaalde media mappen beschikbaar maken.

[synoniem]

Arunia schreef op donderdag 18 juni 2026 @ 09:33:
[...]

Haha, soms post ik gewoon inderdaad ter info. Dat niet altijd alles van een leien dakje gaat.
Maar het lijkt nu wel te werken, ook na een Windows herstart komt bijvoorbeeld Portainer weer op. Dus, Mijn WSL2 start automatisch en daarin Docker ook. Kostte wat moeite om de juiste uitleg te vinden.

Nu nog wat dingen fixen en het liefste had ik eigenlijk bepaalde mappen op Windows beschikbaar gehad, maar het is wat het is. Denk ook gewoon gewenning. Ik weet hoe het werkt en kan straks ook bepaalde media mappen beschikbaar maken.

Windows mappen zijn toch in WSL2 beschikbaar onder /c/..........?

[Arunia]

synoniem schreef op donderdag 18 juni 2026 @ 17:41:
[...]

Windows mappen zijn toch in WSL2 beschikbaar onder /c/..........?

Klopt volgens mij wel. Kwam er andersom wel achter dat in verkenner je geen rechten hebt.

Daarnaast draait het spul nu wel gelukkig en volgens mij zonder echte problemen. Enige is dat het geheugen gebruik toch nog steeds tegen de 99 procent aan blijft tikken.
Kan zomaar iets anders zijn, maar heb het geheugen gelimiteerd naar 1100MB. Zoveel draait er nog niet.
Je zou zeggen dat 16GB voldoende moet zijn, maar blijkbaar valt dat tegen, terwijl ik best een tijd gewoon geen problemen heb gehad. Anders in deze dure tijden toch maar een upgrade zien te vinden naar 32GB. Moet dan wel de oude vervangen dan omdat ik maar 2 slots heb.

[Wienen]

Mijn unraid systeem waarop ik 26 containers heb draaien gebruikt in totaal maar 6,21GB. Waarvan deze containers slechts 2,74GB gebruiken en het Unraid OS 3,47GB. (OS is volledig in RAM geladen, ongeveer 1,5GB de rest zijn plugins)

Wat betreft geheugengebruik en performance was het echt een verademing om van Windows over te stappen naar Unraid. Al zal dit voor ieder Linux based OS gelden.

[Arunia]

Qua dat is het mij duidelijk, maar overstappen durf ik nog niet zo.

Heb het geheugen ingeperkt en het lijkt rond de 80 procent nu te zitten. Het vage is dat het vroeger geen probleem was en of het nu Windows 10 was of dan nu 11, heb ik geen idee van eigenlijk.

Voor nu de rechten veranderd zodat ik wel op die share kan bewerken, ofwel bestanden kan kopiëren. Dat scheelt weer een stap.

[synoniem]

Arunia schreef op woensdag 1 juli 2026 @ 19:23:
[...]

Klopt volgens mij wel. Kwam er andersom wel achter dat in verkenner je geen rechten hebt.

Daarnaast draait het spul nu wel gelukkig en volgens mij zonder echte problemen. Enige is dat het geheugen gebruik toch nog steeds tegen de 99 procent aan blijft tikken.
Kan zomaar iets anders zijn, maar heb het geheugen gelimiteerd naar 1100MB. Zoveel draait er nog niet.
Je zou zeggen dat 16GB voldoende moet zijn, maar blijkbaar valt dat tegen, terwijl ik best een tijd gewoon geen problemen heb gehad. Anders in deze dure tijden toch maar een upgrade zien te vinden naar 32GB. Moet dan wel de oude vervangen dan omdat ik maar 2 slots heb.

Je kan ook het geheugengebruik per container beperken. Onder linux heb ik dat in de regel niet nodig maar onder Windows schijnt het wel te helpen. Kan overigens ook zijn dat je een container hebt met een geheugenlek waardoor die steeds meer geheugen neemt.

[Arunia]

synoniem schreef op vrijdag 3 juli 2026 @ 01:20:
[...]

Je kan ook het geheugengebruik per container beperken. Onder linux heb ik dat in de regel niet nodig maar onder Windows schijnt het wel te helpen. Kan overigens ook zijn dat je een container hebt met een geheugenlek waardoor die steeds meer geheugen neemt.

Op dit moment heb ik het maximum geheugen gebruik op net geen 1100MB staan in .wslconfig.
De kans is zeer groot dat dat nog best veel is, maar dan zou er heel veel geheugen standaard in gebruik zijn. Dat is iets wat ik wel raar vind.
Qua containers heb ik Portainer, Mealie en Rustdesk draaien. Daar komen er nog wel meer bij, maar ik moet even uit zien te vogelen of ik het geheugen gebruik van de containers kan zien. Dit bedenk ik me aan de hand van je bericht natuurlijk, dus nog niet gezocht hierop.
Heb al even gekeken en het lijkt nog ruim onder de 1100MB te zitten. Mealie verbruikt wel verreweg het meeste.
Ben nu Dozzle aan het instellen om zo grafische inzicht te krijgen.

[ Voor 22% gewijzigd door Arunia op 03-07-2026 09:38 ]

[Wienen]

Je kunt in Portainer toch gewoon zien hoeveel geheugen je containers per stuk gebruiken? Ik ben niet bekend met portainer dus weet niet wat er met gemiddeld geheugen bedoeld wordt maar deze zijn al zo laag dat ik me haast niet voor kan stellen dat je containers het probleem zijn van het verhoogde geheugengebruik.

Open eens gewoon je taakbeheer binnen Windows en filter daar op geheugen, dan zie je precies wat je grootverbruikers zijn.

[DjoeC]

Arunia schreef op vrijdag 3 juli 2026 @ 08:56:
[...]

Op dit moment heb ik het maximum geheugen gebruik op net geen 1100MB staan in .wslconfig.
De kans is zeer groot dat dat nog best veel is, maar dan zou er heel veel geheugen standaard in gebruik zijn. Dat is iets wat ik wel raar vind.
Qua containers heb ik Portainer, Mealie en Rustdesk draaien. Daar komen er nog wel meer bij, maar ik moet even uit zien te vogelen of ik het geheugen gebruik van de containers kan zien. Dit bedenk ik me aan de hand van je bericht natuurlijk, dus nog niet gezocht hierop.
Heb al even gekeken en het lijkt nog ruim onder de 1100MB te zitten. Mealie verbruikt wel verreweg het meeste.
Ben nu Dozzle aan het instellen om zo grafische inzicht te krijgen.
[Afbeelding]

In Portainer kun je geheugen gebruik bekijken via de "stats" (statistieken) vzv beschikbaar. Ik heb (o.a.) Dozzle amir20/dozzle:latest draaien waar je het (gemiddeld) geheugengebruik van alle containers gelijk kunt zien - naast dat je meteen de logging vzv beschikbaar kunt bekijken.

Opmerkelijk: Op mijn raspberry pi met OMV 7 laat Docker zelf (sudo docker stats) het geheugen gebruik niet zien....

[Arunia]

Wienen schreef op vrijdag 3 juli 2026 @ 10:04:
Je kunt in Portainer toch gewoon zien hoeveel geheugen je containers per stuk gebruiken? Ik ben niet bekend met portainer dus weet niet wat er met gemiddeld geheugen bedoeld wordt maar deze zijn al zo laag dat ik me haast niet voor kan stellen dat je containers het probleem zijn van het verhoogde geheugengebruik.

Open eens gewoon je taakbeheer binnen Windows en filter daar op geheugen, dan zie je precies wat je grootverbruikers zijn.

Ik heb hier al eens meer naar gekeken en lijkt ook niet alsof WSL2 en docker het probleem is, maar kom er ook niet achter wat nu precies zoveel verbruikt. Er zijn wat losse programma's die draaien. Deze wil ik langzaamaan verplaatsen naar Docker. Twijfel nog over Plex, maar wellicht die ook.
Crashplan, WSL, Zulu verbruiken wel het meeste. Waarom Edge erbij staat is mij een raadsel. Ja, die heb ik soms open voor uitleg en dergelijke, maar nu was deze afgesloten.
Los van elkaar lijkt het allemaal niet zo heel veel, maar opgeteld loopt het wel hard op denk ik.
Maar met 16GB aan ram zou ik toch wel voldoende moeten hebben. Hiervoor had ik 8GB enkele DIMM en eigenlijk geen problemen. Alles is wel standaard geupdate.

[DjoeC]

Arunia schreef op vrijdag 3 juli 2026 @ 13:33:
[...]

[Afbeelding]

Ik heb hier al eens meer naar gekeken en lijkt ook niet alsof WSL2 en docker het probleem is, maar kom er ook niet achter wat nu precies zoveel verbruikt. Er zijn wat losse programma's die draaien. Deze wil ik langzaamaan verplaatsen naar Docker. Twijfel nog over Plex, maar wellicht die ook.
Crashplan, WSL, Zulu verbruiken wel het meeste. Waarom Edge erbij staat is mij een raadsel. Ja, die heb ik soms open voor uitleg en dergelijke, maar nu was deze afgesloten.
Los van elkaar lijkt het allemaal niet zo heel veel, maar opgeteld loopt het wel hard op denk ik.
Maar met 16GB aan ram zou ik toch wel voldoende moeten hebben. Hiervoor had ik 8GB enkele DIMM en eigenlijk geen problemen. Alles is wel standaard geupdate.

Verkijk je je misschien op wat er voor cache en andere "gebruik geheugen als beschikbaar" taken gebruikt wordt? Ik heb eenzelfde soort actieve taken lijst die niet optelt tot mijn totale geheugengebruik.....

[Arunia]

DjoeC schreef op vrijdag 3 juli 2026 @ 13:59:
[...]

Verkijk je je misschien op wat er voor cache en andere "gebruik geheugen als beschikbaar" taken gebruikt wordt? Ik heb eenzelfde soort actieve taken lijst die niet optelt tot mijn totale geheugengebruik.....
[Afbeelding]

Dit heb ik zeg maar. Jij hebt ruim meer geheugen dan dat ik heb en qua in gebruik zitten we op hetzelfde. Alleen ik heb minder totaal geheugen.

[Wienen]

@Arunia jouw processen gebruiken helemaal niet zoveel geheugen, ik kan me ook haast niet voorstellen dat deze bij elkaar opgeteld 95% van je RAM geheugen verbruiken. Ik zit op mijn Windows laptop met 16GB op 85% en heb vele grotere processen/apps draaien die 1,5 tot 2GB per stuk in beslag nemen.

Ik zou daar toch eens verder induiken. Wellicht dat WSL onderwater toch meer geheugen gebruikt wat Windows niet goed laat zien.

[Arunia]

Wienen schreef op vrijdag 3 juli 2026 @ 14:32:
@Arunia jouw processen gebruiken helemaal niet zoveel geheugen, ik kan me ook haast niet voorstellen dat deze bij elkaar opgeteld 95% van je RAM geheugen verbruiken. Ik zit op mijn Windows laptop met 16GB op 85% en heb vele grotere processen/apps draaien die 1,5 tot 2GB per stuk in beslag nemen.

Ik zou daar toch eens verder induiken. Wellicht dat WSL onderwater toch meer geheugen gebruikt wat Windows niet goed laat zien.

Dat heb ik dus ook. Het is dat de CPU niet zo veel in gebruik is, anders zou ik denken dat ik gehacked ben en er een miner draait op de server. Maar ook daar heb ik al eens naar gezocht.
Na herstart zit ik vaak wel op 85%, maar dat loopt wel iets op. Blijf het apart vinden, mijn eigen pc staat ook veel lager, maar goed, potato, potato en niet echt te vergelijken. Of ik moet daar dezelfde dingen op draaien.

Sowieso wat ik al zei, vind ik het vreemd dat het een jaar of iets langer geleden niet zo was. Maar ja, wie weet dat het ergens een Windows update is geweest die het verbruik omhoog gooit.
Ik heb er al eens zo'n programma tegenaan gegooid, maar ook die gaf me niet echt de uitkomst.
WSL2 heb ik op max 1100MB gezet qua ram geheugen. Dus meer dan dat zal die niet moeten gebruiken en zo te zien gebeurd dat ook niet echt. Home Assistant verbruikt ook niet zoveel.

Weet niet echt hoe ik het moet troubleshooten eigenlijk. Ik weet dat het gewoon mogelijk moet zijn om ruim lager in verbruik te zitten.

[ Voor 11% gewijzigd door Arunia op 03-07-2026 15:51 ]

[DjoeC]

Arunia schreef op vrijdag 3 juli 2026 @ 15:50:
[...]

Dat heb ik dus ook. Het is dat de CPU niet zo veel in gebruik is, anders zou ik denken dat ik gehacked ben en er een miner draait op de server. Maar ook daar heb ik al eens naar gezocht.
Na herstart zit ik vaak wel op 85%, maar dat loopt wel iets op. Blijf het apart vinden, mijn eigen pc staat ook veel lager, maar goed, potato, potato en niet echt te vergelijken. Of ik moet daar dezelfde dingen op draaien.

Sowieso wat ik al zei, vind ik het vreemd dat het een jaar of iets langer geleden niet zo was. Maar ja, wie weet dat het ergens een Windows update is geweest die het verbruik omhoog gooit.
Ik heb er al eens zo'n programma tegenaan gegooid, maar ook die gaf me niet echt de uitkomst.
WSL2 heb ik op max 1100MB gezet qua ram geheugen. Dus meer dan dat zal die niet moeten gebruiken en zo te zien gebeurd dat ook niet echt. Home Assistant verbruikt ook niet zoveel.

Weet niet echt hoe ik het moet troubleshooten eigenlijk. Ik weet dat het gewoon mogelijk moet zijn om ruim lager in verbruik te zitten.

Misschien kun je hier iets mee? Je doet iig aan paging, het lijkt alsof je 16GB in je PC hebt met een 16GB paging file. Je hebt meer dan 16GB in gebruik en dus moet Windows ook paging gaan managen. Dan zit je ook nog met alle processen die filehandles hebben openstaan - vermoedelijk veel in R-W en niet read only waardoor ze niet vrijgegeven kunnen worden. En onder Docker zou het me niet verbazen als dat flink grotere aantallen zijn als je de Docker file structuren bekijkt......

Maar - dit is zeker niet mijn expertise, ik draai Docker juist onder Linux omdat ik over Linux veel makkelijker inhoudelijke informatie kan vinden (en omdat een Pi met SSD veel minder verbruik heeft bij 24/7), ook daar ben ik geen specialist in.....

O ja, voor de duidelijkheid: Windows pakt al het vrije geheugen voor filecaching en read-ahead. Ook daar zit misschien nog iets om uit te zoeken? Ik denk nu ook aan "uitgestelde writes" - dat kun je uitschakelen dan wordt die ruimte vrij gegeven. Even zoeken waar die optie zit...

Per disk instelbaar: https://help.2brightspark...rror-message-from-windows

[ Voor 9% gewijzigd door DjoeC op 03-07-2026 16:06 ]

[Arunia]

DjoeC schreef op vrijdag 3 juli 2026 @ 15:58:
[...]

Misschien kun je hier iets mee? Je doet iig aan paging, het lijkt alsof je 16GB in je PC hebt met een 16GB paging file. Je hebt meer dan 16GB in gebruik en dus moet Windows ook paging gaan managen. Dan zit je ook nog met alle processen die filehandles hebben openstaan - vermoedelijk veel in R-W en niet read only waardoor ze niet vrijgegeven kunnen worden. En onder Docker zou het me niet verbazen als dat flink grotere aantallen zijn als je de Docker file structuren bekijkt......

Maar - dit is zeker niet mijn expertise, ik draai Docker juist onder Linux omdat ik over Linux veel makkelijker inhoudelijke informatie kan vinden (en omdat een Pi met SSD veel minder verbruik heeft bij 24/7), ook daar ben ik geen specialist in.....

Thanks, ik zal daar ook eens in duiken. Uiteindelijk zal ik het wel vinden, dat weet ik zeker en voor nu draait het onder de 99% wat ook scheelt.
Maar wil er nog een stuk meer dingen onder draaien en dan voorkomen dat het wel weer tegen zijn max aan loopt.

[3DDude]

Taak beheer >> Performance tab >> rechts bovenin op de ... jes klikken en resource manager openen.
Kijken of je daar wat kan vinden.

en anders WSL tuning opzoeken.
https://devalice.jaceclub...slconfig--ramcpuswap-caps

Ik ben voor mijzelf ook is kijken, heb 100GB in cached staan dus vind het bij jou weinig...

[ Voor 16% gewijzigd door 3DDude op 03-07-2026 16:04 ]

[DjoeC]

Arunia schreef op vrijdag 3 juli 2026 @ 16:03:
[...]

Thanks, ik zal daar ook eens in duiken. Uiteindelijk zal ik het wel vinden, dat weet ik zeker en voor nu draait het onder de 99% wat ook scheelt.
Maar wil er nog een stuk meer dingen onder draaien en dan voorkomen dat het wel weer tegen zijn max aan loopt.

Aan Docker hoeft het niet te liggen... Ik draai 20+ containers op een 16GB Raspi 5 met 4TB SSD. Die deden t op een 8GB Pi4 met 2TB sata SSD ook zonder issues.

[Arunia]

@3DDude Ik zie heel veel Java er tussen staan qua 160.000KB per onderdeel als werkset en allemaal rond de 200.000KB als Toegewezen. Kan van alles zijn natuurlijk, maar als er 20 staan is het weinig, dan telt het wel op. Dus daar moet ik verder in gaan duiken. Alhoewel ze allemaal grijs zijn en af en toe opspringen naar zwart. Geen idee wat het verder betekent, maar ook daar zal ik eens naar kijken. Ik maar overigens gebruik van Zulu Java.
WSL lijkt toegewezen op 1.118.660KB en werkset is 360KB. Die zou ik omlaag kunnen gooien, maar dan moet ik daar goed op letten dat deze niet vol loopt en ik dat niet door heb.


Als ik kijk naar harde fouten, dan is dat bij memory compression vooral, maar loopt ook niet op andere vlakken hard omhoog. Maar met het geheugen wat vrij hoog ligt, is het geheugen op dit moment niet echt toereikend.

@DjoeC Ik denk inderdaad dat het ook niet aan WSL2 of Docker ligt.

[ Voor 3% gewijzigd door Arunia op 03-07-2026 16:22 ]

[3DDude]

je kan op kolom filteren he, van hoog naar laag enzo..

[Wienen]

Ik zou toch eens gaan onderzoeken waar die java.exe vandaan komen

[Mars Warrior]

Wienen schreef op vrijdag 3 juli 2026 @ 19:29:
Ik zou toch eens gaan onderzoeken waar die java.exe vandaan komen

Ach. Crashplan is in Java geschreven en heeft per TB aan backup weer x GB nodig aan RAM.

Ik heb slechts 2TB aan backups en de Crashplan docker container gebruikt 22GB RAM

[Wienen]

Mars Warrior schreef op vrijdag 3 juli 2026 @ 20:45:
[...]

Ach. Crashplan is in Java geschreven en heeft per TB aan backup weer x GB nodig aan RAM.

Ik heb slechts 2TB aan backups en de Crashplan docker container gebruikt 22GB RAM

Haha dan hebben we de boosdoener wellicht gevonden

Maar wat is er zo bijzonder aan Crashplan dat je daar aan vast blijft houden als deze zoveel geheugen vreet?

Ik heb m'n backup volledig ingericht met Rustic i.c.m. XyOps voor de backup workflows, en waar Rustic enkel tijdens de backup job even wat geheugen gebruikt draait er verder buiten de job om niks. Werkt als een zonnetje.

[Arunia]

@3DDude Dat sorteren had ik gedaan. Vandaar deze uitkomst. Ook op naam om te zien hoeveel Java.exe onderdelen er voorbij kwamen.
@Wienen Zeker. Het is denk ik met de uitleg van @Mars Warrior wel duidelijk wat er precies gebeurd.
Ik heb 16TB in mijn server zitten en nee, niet alles is vol en niet alles wordt gebackupped.
Waarom ik vast blijf houden aan Crashplan is denk ik het gemak en nog niet iets anders gevonden wat simpel werkt eigenlijk. Betaal er ook maandelijks voor en buiten dat het echt takken traag is (opnieuw backup gemaakt na aangevraagd te hebben over te laten zetten naar een datacenter in Ierland en deze 2 maanden bezig is geweest ), werkt het vrij simpel. Voor nu nog geen zin gehad om opnieuw iets uit te zoeken en gaan leren. Daarnaast is het meeste nog duurder per maand. Tja, komt vast nog wel een keer.
Maar zal eens kijken of real time naar alleen in de nacht overzetten het op zal lossen. In de nacht maakt het verbruik me sowieso weinig uit.

[DjoeC]

Arunia schreef op zaterdag 4 juli 2026 @ 01:33:
@3DDude Dat sorteren had ik gedaan. Vandaar deze uitkomst. Ook op naam om te zien hoeveel Java.exe onderdelen er voorbij kwamen.
@Wienen Zeker. Het is denk ik met de uitleg van @Mars Warrior wel duidelijk wat er precies gebeurd.
Ik heb 16TB in mijn server zitten en nee, niet alles is vol en niet alles wordt gebackupped.
Waarom ik vast blijf houden aan Crashplan is denk ik het gemak en nog niet iets anders gevonden wat simpel werkt eigenlijk. Betaal er ook maandelijks voor en buiten dat het echt takken traag is (opnieuw backup gemaakt na aangevraagd te hebben over te laten zetten naar een datacenter in Ierland en deze 2 maanden bezig is geweest ), werkt het vrij simpel. Voor nu nog geen zin gehad om opnieuw iets uit te zoeken en gaan leren. Daarnaast is het meeste nog duurder per maand. Tja, komt vast nog wel een keer.
Maar zal eens kijken of real time naar alleen in de nacht overzetten het op zal lossen. In de nacht maakt het verbruik me sowieso weinig uit.

Gebruik je het voor Windows of voor Linux? Ik gebruik Backblaze Personal met onbeperkte data. De agent werkt alleen onder Windows en dus heb ik wat ingericht om de relevante Linux meuk naar een Windows disk te backuppen. Momenteel > 20TB bij hen staan, in Amsterdam. In 2024 USD 229,- betaald voor 2 jaar (incl BTW). Zal dit jaar wel een paar tientjes meer worden maar ik kan er geen schijf voor kopen. 1e backup duurde wel een dikke week, nu blijft ie op de achtergrond prima bij. Maar, er zijn een paar grotere backup topics hier in het forum.

Aanvulling: Als je bij Backblaze eem vinkje zet bewaren ze "alle" file versies gedurende 1 jaar. Een aantal files zijn excluded maar mijn backups niet. Die bewaar ik dus een tijdje lokaal, daarna mag BB het voor mij doen. Dat scheelt bij volume backups (Acronis backup van C+D schijf) best een hoop lokale opslag.

[ Voor 8% gewijzigd door DjoeC op 04-07-2026 15:32 ]

[Arunia]

DjoeC schreef op zaterdag 4 juli 2026 @ 12:58:
[...]

Gebruik je het voor Windows of voor Linux? Ik gebruik Backblaze Personal met onbeperkte data. De agent werkt alleen onder Windows en dus heb ik wat ingericht om de relevante Linux meuk naar een Windows disk te backuppen. Momenteel > 20TB bij hen staan, in Amsterdam. In 2024 USD 229,- betaald voor 2 jaar (incl BTW). Zal dit jaar wel een paar tientjes meer worden maar ik kan er geen schijf voor kopen. 1e backup duurde wel een dikke week, nu blijft ie op de achtergrond prima bij. Maar, er zijn een paar grotere backup topics hier in het forum.

De backup topics ken ik inderdaad. Kom er zelf ook om zo nu en dan eens te kijken of er wat nieuws is.
Qua prijs zit ik nu aan de 13 euro of iets per maand.
Ik gebruik het voor Windows. Dus dat zeker een optie kunnen zijn.

[Mars Warrior]

Wienen schreef op vrijdag 3 juli 2026 @ 21:26:
[...]

Haha dan hebben we de boosdoener wellicht gevonden

Maar wat is er zo bijzonder aan Crashplan dat je daar aan vast blijft houden als deze zoveel geheugen vreet?

Ik heb m'n backup volledig ingericht met Rustic i.c.m. XyOps voor de backup workflows, en waar Rustic enkel tijdens de backup job even wat geheugen gebruikt draait er verder buiten de job om niks. Werkt als een zonnetje.

Dat heeft te maken met een stukje historie. Voorheen kon je met CrashPlan gratis naar een andere server back-uppen. Dus een Remote back-up. Dan hebben ze dat uitgesloopt en moest je gaan betalen. Dat was in het begin behoorlijk goedkoop. Ik meen iets van € 60 terwijl ik iets van 10 terabyte had als back-up.

Daarna is CP allerlei beperkingen in gaan voeren. En het is inderdaad zo traag als dikke stront. En het kost inderdaad veel ram geheugen. Maar mijn 128 GB ram stamt nog uit de tijd dat je daar € 300 voor betaalde 🫣

Dus ik zit wel naar een alternatief te kijken, maar dat heeft absoluut geen haast.

[tikkietrugjaap]

Ik loop tegen een probleem aan waarvan ik hoop dat jullie mij richting een oplossing kunnen wijzen.

Hier een deel van mijn compose file met één container als voorbeeld.

YAML:

networks:
  vadjnet:
    driver_opts:
      com.docker.network.bridge.name: vadjnet
    ipam:
      config:
        - subnet: 172.20.0.0/16
services:
  swag:
    image: lscr.io/linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
#    sysctls:
#      - net.ipv6.conf.all.disable_ipv6=1
    environment:
      - PUID=${PUID}
      - PGID=${PGID}
      - TZ=${TZ}
      - URL=${DUCKDNSURL}
      - SUBDOMAINS=wildcard
      - VALIDATION=duckdns
        #      - CERTPROVIDER= #optional
        #      - DNSPLUGIN=cloudflare #optional
      - DUCKDNSTOKEN=${DUCKDNSTOKEN}
        #      - EMAIL=<e-mail> #optional
        #      - ONLY_SUBDOMAINS=false #optional
        #      - EXTRA_DOMAINS=<extradomains> #optional
        #      - STAGING=false #optional
    volumes:
      - ${DATA}/swag/config:/config
    ports:
      - 0.0.0.0:443:443
#      - 80:80 #optional
    networks:
      vadjnet:
        ipv4_address: 172.20.0.2
#    dns:
#      - 192.168.41.1
    restart: unless-stopped

Ik heb een proxmoxserver waarop meerdere VM's draaien. Sommige VM's draaien Docker met een aantal containers. De containers draaien op een eigen dockernetwerk zodat de containers elkaar makkelijk kunnen vinden op slechts hun containernaam (bijvoorbeeld swag of qbittorrent).

Het fysieke netwerk bestaat uit een Opnsense router met DNSMasq en Unbound waardoor ik via DHCP IP-adressen uitdeel en de hostname van deze hosts FQDN zijn op het netwerk (bijvoorbeeld desk9800.home.internal).

Het probleem wat ik heb is dat hostnames van hosts op het fysieke netwerk niet op een gebruikelijke manier kunnen worden benaderd vanuit de containers. Wat ik daar mee bedoel is dat een standaard ping vanuit een container naar een host (bijvoorbeeld van de swag container naar desk9800.home.internal) resulteert in:

ping: bad address 'desk9800.home.internal' 

Aanvankelijk dacht ik dat er iets met DNS niet goed ging maar een nslookup vanuit de container resulteert in:

Server:         127.0.0.11
Address:        127.0.0.11:53
Non-authoritative answer:
Name:   desk9800.home.internal
Address: 192.168.10.103
** server can't find desk9800.home.internal: SERVFAIL

Het IP adres van de host wordt wel gevonden. De SERVFAIL komt vermoedelijk omdat nslookup ook ipv6 uitvraagt en er geen ipv6 op het netwerk word gebruikt.

Omdat nslookup laat zien dat DNS, ook binnen de container, lijkt te werken ging ik verder zoeken. Uiteindelijk ben ik op het idee gekomen om bij ping de "-4" optie te gebruiken. Hierdoor wordt ping gedwongen ipv4 te gebruiken. Dit resulteert in:

PING desk9800.home.internal (192.168.10.103): 56 data bytes

Mijn conclusie is daarom dat ik ergens iets niet goed heb ingesteld waardoor commando's zoals ping primair naar ipv6 kijken en vervolgens een error geven. In een poging om ipv6 zoveel mogelijk uit te schakelen binnen Docker heb ik het volgende geprobeerd, alles zonder succes.

1. "ipv6": false toevoegen aan /etc/docker/daemon.json.
2. sysctls:
   - net.ipv6.conf.all.disable_ipv6=1
   toevoegen aan de desbetreffende container in de compose file.

Mijn vraag aan jullie is daarom of jullie weten wat hier fout gaat en in welke richting ik moet denken voor een oplossing? Als er meer informatie nodig is dan hoor ik het uiteraard graag. Alvast bedankt.

[synoniem]

Je zou dit nog kunnen proberen:

YAML:

networks:
  vadjnet:
    ipv4_address: 172.20.0.2
    driver: bridge
    enable_ipv6: false

[tikkietrugjaap]

synoniem schreef op maandag 20 juli 2026 @ 23:07:
Je zou dit nog kunnen proberen:

YAML:

networks:
  vadjnet:
    ipv4_address: 172.20.0.2
    driver: bridge
    enable_ipv6: false

Ik zal dat eens proberen. Bedankt.

[edit]
Ik heb het bovenstaande toegevoegd aan het networks-deel:

networks:
  vadjnet:
    driver_opts:
      com.docker.network.bridge.name: vadjnet
    driver: bridge
    enable_ipv6: false
    ipam:
      config:
        - subnet: 172.20.0.0/16

Maar het resultaat is hetzelfde. Als ik "sudo docker exec -it swag ping desk9800.home.internal" uitvoer krijg ik weer:

ping: bad address 'desk9800.home.internal'

[ Voor 43% gewijzigd door tikkietrugjaap op 21-07-2026 10:29 ]

[Airw0lf]

@tikkietrugjaap - is er een externe dns server die dit kan resolven?

Start die container eens met: --dns <ip-adres van die dns server>. En probeer dan nog eens.

[tikkietrugjaap]

Airw0lf schreef op dinsdag 21 juli 2026 @ 10:49:
@tikkietrugjaap - is er een externe dns server die dit kan resolven?

Start die container eens met: --dns <ip-adres van die dns server>. En probeer dan nog eens.

Bedankt voor de tip maar dat had ik al geprobeerd. Dit is ook zichtbaar in de YAML code die ik aanvankelijk had gepost. Het staat daar nu als comment in omdat het niet leek te werken. Ik was alleen vergeten dit expliciet te melden.

Ik vraag me alleen af of dit wel een DNS kwestie is. Het pingen van de hostname lijkt wel goed te gaan als ik expliciet ipv4 gebruik bij ping.

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 11:38:
[...]

Bedankt voor de tip maar dat had ik al geprobeerd. Dit is ook zichtbaar in de YAML code die ik aanvankelijk had gepost. Het staat daar nu als comment in omdat het niet leek te werken. Ik was alleen vergeten dit expliciet te melden.

Ik vraag me alleen af of dit wel een DNS kwestie is. Het pingen van de hostname lijkt wel goed te gaan als ik expliciet ipv4 gebruik bij ping.

Lijkt me meer een ipv6 issue. Alpine maakt gebruik musl libc en musl is best streng qua ipv6. Je kan proberen dit in te stellen in OPNsense onder unbound dns. Verwacht dat het dan wel werkt.

local-zone: "home.internal." typetransparent

[ Voor 7% gewijzigd door Dracoz op 21-07-2026 12:05 ]

[tikkietrugjaap]

Dracoz schreef op dinsdag 21 juli 2026 @ 12:01:
[...]

Lijkt me meer een ipv6 issue. Alpine maakt gebruik musl libc en musl is best streng qua ipv6. Je kan proberen dit in te stellen in OPNsense onder unbound dns. Verwacht dat het dan wel werkt.

local-zone: "home.internal." typetransparent

Ik heb ook het vermoeden dat het ipv6 gerelateerd is maar ik begrijp alleen niet hoe dat kan als ik nergens ipv6 gebruik.

Dat gezegd hebbende, ik heb binnen Opnsense gezocht naar hetgeen jij voorstelt maar ik kan nergens een local-zone invullen. Bij de general options van Unbound vind ik wel instellingen voor "Local Zone Type" en die staat al op Transparent. Zoeken via Google/AI levert veel oude informatie op waarbij wordt gerefereerd naar een sectie 'Custom options' die niet meer lijken te bestaan.

Misschien ook handig om te weten is dat ik meerdere subdomains heb binnen .internal. De servers waar de VM's op draaien zitten bijvoorbeeld in servers.internal en die desktop die ik probeer te pingen zit in home.internal.

Als laatste, is dit nog een Docker-vraag of kan ik het beter gaan vragen in een Opnsense-thread?

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 12:22:
[...]

Ik heb ook het vermoeden dat het ipv6 gerelateerd is maar ik begrijp alleen niet hoe dat kan als ik nergens ipv6 gebruik.

Dat gezegd hebbende, ik heb binnen Opnsense gezocht naar hetgeen jij voorstelt maar ik kan nergens een local-zone invullen. Bij de general options van Unbound vind ik wel instellingen voor "Local Zone Type" en die staat al op Transparent. Zoeken via Google/AI levert veel oude informatie op waarbij wordt gerefereerd naar een sectie 'Custom options' die niet meer lijken te bestaan.

Misschien ook handig om te weten is dat ik meerdere subdomains heb binnen .internal. De servers waar de VM's op draaien zitten bijvoorbeeld in servers.internal en die desktop die ik probeer te pingen zit in home.internal.

Als laatste, is dit nog een Docker-vraag of kan ik het beter gaan vragen in een Opnsense-thread?

Meer OPNsense gerelateerd imho. Het probleem is dat alpine op dns niveau niet weet dat je netwerk geen ipv6 heeft.

Oja tegenwoordig is het inderdaad zelf via conf bestand in te stellen of via dns override in de webgui van OPNsense geloof ik. Kun je er ook direct meerdere in stellen en dan zou het moeten werken.

[tikkietrugjaap]

Dracoz schreef op dinsdag 21 juli 2026 @ 12:44:
[...]


Meer OPNsense gerelateerd imho. Het probleem is dat alpine op dns niveau niet weet dat je netwerk geen ipv6 heeft.

Oja tegenwoordig is het inderdaad zelf via conf bestand in te stellen of via dns override in de webgui van OPNsense geloof ik. Kun je er ook direct meerdere in stellen en dan zou het moeten werken.

Ok, dan ga ik de vraag stellen in de Opnsense-thread. Bedankt.

[edit]
Mm, er blijkt geen grote Opnsense-thread te zijn. Ik zal wel een eigen thread aanmaken in het Netwerken-forum.

[ Voor 11% gewijzigd door tikkietrugjaap op 21-07-2026 12:52 ]

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 12:50:
[...]

Ok, dan ga ik de vraag stellen in de Opnsense-thread. Bedankt.

[edit]
Mm, er blijkt geen grote Opnsense-thread te zijn. Ik zal wel een eigen thread aanmaken in het Netwerken-forum.

Je kan eventueel hier ff kijkje nemen staat exact uitgelegd wat je moet doen om alles le laten werken. https://homenetworkguy.com/how-to/create-unbound-dns-override-aliases-in-opnsense/

[tikkietrugjaap]

Dracoz schreef op dinsdag 21 juli 2026 @ 12:56:
[...]

Je kan eventueel hier ff kijkje nemen staat exact uitgelegd wat je moet doen om alles le laten werken. https://homenetworkguy.com/how-to/create-unbound-dns-override-aliases-in-opnsense/

Momenteel heb ik al een override voor mijn reverse-proxy dus het override scherm ken ik wel een beetje. Waar ik nu nog mee zit is dat ik niet goed begrijp wat ik zou moeten invullen om binnen Docker containers ook goede DNS te hebben. Ik merk dat ik nog niet helemaal begrijp waarom dit op deze manier gebeurt waardoor het zoeken naar een werkende oplossing een uitdaging is. Hopelijk dat een avondje online speuren mij daar verder in brengt.

Wederom bedankt.

[Mars Warrior]

Klinkt als foutieve AAAA records.

getent ahosts desk9800.home.internal

Of iets als

dig desk9800.home.internal A
dig desk9800.home.internal AAAA

Zou je ook verder moeten helpen.

[RobertMe]

Dracoz schreef op dinsdag 21 juli 2026 @ 12:44:
[...]


Meer OPNsense gerelateerd imho. Het probleem is dat alpine op dns niveau niet weet dat je netwerk geen ipv6 heeft.

Als je IPv6 uit zet hoort de lokale DNS resolver dat natuurlijk gewoon te weten en geen AAAA queries af te vuren. De DNS server aan de andere kant kan immers al helemaal niet weten of de client wel of geen IPv6 doet. Immers weet de DNS server al helemaal niks van het netwerk af. Die kan immers ook op een ander systeem dan de router draaien etc etc etc. Het is toch echt de verantwoordelijkheid van de lokale resolver / OS om de juiste queries te doen. En grote kans dat dat zelfs uit het OS komt en niet zozeer uit de lokale resolver. De applicatie zal immers zelf moeten kiezen of die een A, AAAA, TXT, MX, SOA, DS, ... wilt doen. En ja, applicaties kunnen ook zowel A als AAAA tegelijkertijd doen en de voorkeur geven aan het soort dat als eerste een werkende verbinding levert.

[Dracoz]

RobertMe schreef op dinsdag 21 juli 2026 @ 13:09:
[...]

Als je IPv6 uit zet hoort de lokale DNS resolver dat natuurlijk gewoon te weten en geen AAAA queries af te vuren. De DNS server aan de andere kant kan immers al helemaal niet weten of de client wel of geen IPv6 doet. Immers weet de DNS server al helemaal niks van het netwerk af. Die kan immers ook op een ander systeem dan de router draaien etc etc etc. Het is toch echt de verantwoordelijkheid van de lokale resolver / OS om de juiste queries te doen. En grote kans dat dat zelfs uit het OS komt en niet zozeer uit de lokale resolver. De applicatie zal immers zelf moeten kiezen of die een A, AAAA, TXT, MX, SOA, DS, ... wilt doen. En ja, applicaties kunnen ook zowel A als AAAA tegelijkertijd doen en de voorkeur geven aan het soort dat als eerste een werkende verbinding levert.

Zoals ik zei, Alpine gebruikt de musl libc en die blijft op dns niveau altijd AAAA records opvragen. OPNsense geeft een servfail en daardoor geeft de musl libc bad adress terug.

Een OS zoals bijvoorbeeld Ubuntu zal dit negeren omdat glibc de ipv6 foutmelding negeert en de ipv4 gewoon teruggeeft.

Dit komt dus allemaal omdat die zonetype binnen unbound niet op transparent staat en dus altijd een servfail op ipv6 teruggeeft.

[ Voor 5% gewijzigd door Dracoz op 21-07-2026 13:32 ]

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 13:04:
[...]

Momenteel heb ik al een override voor mijn reverse-proxy dus het override scherm ken ik wel een beetje. Waar ik nu nog mee zit is dat ik niet goed begrijp wat ik zou moeten invullen om binnen Docker containers ook goede DNS te hebben. Ik merk dat ik nog niet helemaal begrijp waarom dit op deze manier gebeurt waardoor het zoeken naar een werkende oplossing een uitdaging is. Hopelijk dat een avondje online speuren mij daar verder in brengt.

Wederom bedankt.

Zet eens een test vm op met bijvoorbeeld ubuntu. Grote kans dat het dan wel werkt omdat die dus glibc gebruiken. Wat je eigenlijk moet doen is zorgen dat je zonetype binnen unbound op transparent staat, dan werkt het ook gewoon binnen alpine etc. Die kun je doen via een .conf bestand

[RobertMe]

Dracoz schreef op dinsdag 21 juli 2026 @ 13:23:
[...]

Zoals ik zei, Alpine gebruikt de musl libc en die blijft op dns niveau altijd AAAA records opvragen. OPNsense geeft een servfail en daardoor geeft de musl libc bad adress terug.

Een OS zoals bijvoorbeeld Ubuntu zal dit negeren omdat glibc de ipv6 foutmelding negeert en de ipv4 gewoon teruggeeft.

Dat lijkt mij gewoon heel sterk. Zou immers betekenen dat Alpine nooit bruikbaar is in een IPv4 only netwerk. En nouja, Alpine is een "vrij populair" base image voor Docker containers en Docker ondersteund pas vrij recent IPv6 (by default). Dus als Alpine zich niks aantrekt van of het OS (/omgeving / container) IPv6 geschikt is dan zou je nooit Alpine als base image hebben kunnen gebruiken (en kan dat nog steeds niet) in een IPv4 omgeving. Waarbij een DNS resolver in het netwerk nog steeds prima op AAAA requests zal antwoorden ook al is die DNS resolver zelf niet via IPv6 met het internet verbonden.

Edit:

$ docker network create --ipv6=false noipv6
9026ff4a7819fcf904732a5a7e80a32b1886e79b3ef8087876ffc2d53ab9426b
$ docker run --rm --network noipv6 -it alpine ash
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
55afa1ecc21d: Already exists
Digest: sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
Status: Downloaded newer image for alpine:latest
/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if255: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:91:ac:5b:ca:58 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
/ # ping google.com
PING google.com (172.217.171.110): 56 data bytes
^C
--- google.com ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

Werkt dus prima. Ping gaat naar het IPv4 adres. Doe ik ping -6 google.com laat die wel het IP zien maar "Network unreachable". (Er komt geen antwoord omdat de boel in de firewall is dicht getimmerd. Containers mogen niet naar buiten babbelen tenzij expliciet toegestaan).

[ Voor 41% gewijzigd door RobertMe op 21-07-2026 13:42 ]

[synoniem]

RobertMe schreef op dinsdag 21 juli 2026 @ 13:35:
[...]

Dat lijkt mij gewoon heel sterk. Zou immers betekenen dat Alpine nooit bruikbaar is in een IPv4 only netwerk. En nouja, Alpine is een "vrij populair" base image voor Docker containers en Docker ondersteund pas vrij recent IPv6 (by default). Dus als Alpine zich niks aantrekt van of het OS (/omgeving / container) IPv6 geschikt is dan zou je nooit Alpine als base image hebben kunnen gebruiken (en kan dat nog steeds niet) in een IPv4 omgeving. Waarbij een DNS resolver in het netwerk nog steeds prima op AAAA requests zal antwoorden ook al is die DNS resolver zelf niet via IPv6 met het internet verbonden.

Edit:

$ docker network create --ipv6=false noipv6
9026ff4a7819fcf904732a5a7e80a32b1886e79b3ef8087876ffc2d53ab9426b
$ docker run --rm --network noipv6 -it alpine ash
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
55afa1ecc21d: Already exists
Digest: sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b
Status: Downloaded newer image for alpine:latest
/ # ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if255: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:91:ac:5b:ca:58 brd ff:ff:ff:ff:ff:ff
    inet 172.19.0.2/16 brd 172.19.255.255 scope global eth0
       valid_lft forever preferred_lft forever
/ # ping google.com
PING google.com (172.217.171.110): 56 data bytes
^C
--- google.com ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss

Werkt dus prima. Ping gaat naar het IPv4 adres. Doe ik ping -6 google.com laat die wel het IP zien maar "Network unreachable". (Er komt geen antwoord omdat de boel in de firewall is dicht getimmerd. Containers mogen niet naar buiten babbelen tenzij expliciet toegestaan).

Het ligt iets genuanceerder. Bij Alpine vuurt een nslookup voor tegelijkertijd ipv4 en ipv6 af en sommige DNS-servers reageren dan inderdaad met een SERVFAIL (waaronder kennelijk unbound zonder transparent zone). Je kunt dit mitigeren door aan resolv.conf (in de container) dit toe te voegen:

options single-request-reopen

Dan gebruikt nslookup 1 vraag per keer.

[Dracoz]

synoniem schreef op dinsdag 21 juli 2026 @ 13:49:
[...]


Het ligt iets genuanceerder. Bij Alpine vuurt een nslookup voor tegelijkertijd ipv4 en ipv6 af en sommige DNS-servers reageren dan inderdaad met een SERVFAIL (waaronder kennelijk unbound zonder transparent zone). Je kunt dit mitigeren door aan resolv.conf (in de container) dit toe te voegen:

options single-request-reopen

Dan gebruikt nslookup 1 vraag per keer.

Slimme oplossing, nog niet eens aan gedacht om dat toe te voegen. Dat scheelt weer sleutelen in OPNsense inderdaad. Uiteraard is op netwerkniveau de "mooiste" oplossing wel om het op de OPNsense goed in te stellen, dan is het overal in het vervolg opgelost.

[RobertMe]

synoniem schreef op dinsdag 21 juli 2026 @ 13:49:
[...]


Het ligt iets genuanceerder. Bij Alpine vuurt een nslookup voor tegelijkertijd ipv4 en ipv6 af en sommige DNS-servers reageren dan inderdaad met een SERVFAIL (waaronder kennelijk unbound zonder transparent zone). Je kunt dit mitigeren door aan resolv.conf (in de container) dit toe te voegen:

options single-request-reopen

Dan gebruikt nslookup 1 vraag per keer.

Ik draai Unbound, rechtstreeks als mijn DNS (als in: in het voorbeeld verbind de Alpine container direct met Unbound). Alleen heb ik mijn lokale DNS met RPZ gedaan, en niet met Unbounds custom format. Dan zou het issue echt al een niche in een niche in een niche moeten zijn wil je er tegenaan lopen. En ja, ook als ik een lokale naam laat resolven, met of zonder bestaand record van een ander type, krijg ik gewoon een NOERROR terug en geen SERVFAIL.

[synoniem]

RobertMe schreef op dinsdag 21 juli 2026 @ 14:31:
[...]

Ik draai Unbound, rechtstreeks als mijn DNS (als in: in het voorbeeld verbind de Alpine container direct met Unbound). Alleen heb ik mijn lokale DNS met RPZ gedaan, en niet met Unbounds custom format. Dan zou het issue echt al een niche in een niche in een niche moeten zijn wil je er tegenaan lopen. En ja, ook als ik een lokale naam laat resolven, met of zonder bestaand record van een ander type, krijg ik gewoon een NOERROR terug en geen SERVFAIL.

Ja ik zou verwachten dat de optie dns=unbound-ip het probleem ook zou oplossen. De vraagsteller geeft echter aan dat hij dat al geprobeerd heeft en ik heb geen idee hoe zijn verdere configuratie er uit ziet en hoe niche die configuratie is

Ik gebruik zelf pfSense en dat is tegenwoordig steeds minder goed te vergelijken met OPNsense. En het inregelen van ipv6 was nog een aardig klusje om het goed te doen i.c.m. PPPOE.

Maar het probleem dat niet alle dns-servers en m.n. bij consumentenhardware tegen een dubbele nslookup kan komt meer voor.

[tikkietrugjaap]

Even een bericht tussendoor. Ik zie allemaal hele goede informatie voorbij komen. Ik heb vanavond weer tijd om dit op te pakken en zal dan reageren op alles. Mits dit is toegestaan binnen deze thread want het lijkt erop dat dit niet aan Docker ligt.

[Dracoz]

RobertMe schreef op dinsdag 21 juli 2026 @ 14:31:
[...]

Ik draai Unbound, rechtstreeks als mijn DNS (als in: in het voorbeeld verbind de Alpine container direct met Unbound). Alleen heb ik mijn lokale DNS met RPZ gedaan, en niet met Unbounds custom format. Dan zou het issue echt al een niche in een niche in een niche moeten zijn wil je er tegenaan lopen. En ja, ook als ik een lokale naam laat resolven, met of zonder bestaand record van een ander type, krijg ik gewoon een NOERROR terug en geen SERVFAIL.

RPZ is bij jou exact de reden dat dit gedrag voorkomen wordt. ​Als je OPNsense gewoon standaard draait met 'register DHCP leases' in Unbound, krijg je precies die strikte local-zones. Combineer dat met Alpine-containers (die parallel A en AAAA-queries vuren) en je loopt hier dus direct tegenaan.

[tikkietrugjaap]

Ok. Ik heb de berichten gelezen en het lijkt er steeds meer op dat ik iets niet goed heb ingesteld bij DNSMasq en Unbound. Eens kijken of ik zoveel mogelijk antwoorden kan geven zonder een chaotische post te maken:

Mars Warrior schreef op dinsdag 21 juli 2026 @ 13:06:

getent ahosts desk9800.home.internal binnen de container levert niets op. Hij doet wel iets maar vervolgens zie ik gewoon weer de command prompt. Als ik het binnen de VM doe krijg ik:

192.168.10.103  STREAM desk9800.home.internal
192.168.10.103  DGRAM
192.168.10.103  RAW

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45044
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;desk9800.home.internal.                IN      A

;; ANSWER SECTION:
desk9800.home.internal. 1       IN      A       192.168.10.103

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:13 CEST 2026
;; MSG SIZE  rcvd: 67

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5375
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;desk9800.home.internal.                IN      AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:07 CEST 2026
;; MSG SIZE  rcvd: 40

In beide gevallen wordt de Docker DNS aangesproken (127.0.0.11) maar alleen bij ipv4 gaat het goed.

Dracoz schreef op dinsdag 21 juli 2026 @ 13:31:

Mijn VM's zijn allemaal Ubuntu Server (op Home Assistant na). Je bedoelde waarschijnlijk een docker container op basis van ubuntu dus die heb ik opgestart met "sudo docker run --rm --network noipv6 -it ubuntu". Daarna iputils geïnstalleerd en een ping naar desk9800 verliep inderdaad vlekkeloos.

RobertMe schreef op dinsdag 21 juli 2026 @ 13:35:

In jouw voorbeeld ping je google.com. Dat lukt bij mij, vanuit de container, wel. Hij pingt dan automatisch een ipv4 adres. Probeer ik echter jouw stappen maar ping ik mijn eigen host (desk9800) dan krijg ik hetzelfde resultaat.

synoniem schreef op dinsdag 21 juli 2026 @ 13:49:

Ik heb die regel nog niet geprobeerd, bedankt daarvoor. Echter ben ik het wel met @Dracoz eens dat dit beter geregeld kan worden op netwerkniveau. Ik heb iets niet goed ingesteld binnen Opnsense, lijkt het op. Mijn configuratie is, denk ik, niet heel niche. Opnsense router op een kleine PC, daarop DNSMasq voor DHCP en Unbound voor DNS zodat alle hosts middels FQDN kunnen worden gevonden. Een aantal VLANs maar op dit moment hebben die allemaal nog een allow all regel. Elke VLAN zijn eigen domain (home.internal, servers.internal, iot.internal, etc.).

Dracoz schreef op dinsdag 21 juli 2026 @ 16:43:

Ik heb inderdaad 'register DHCP leases' aanstaan binnen Unbound. Ook heb ik, bij Query Forwarding regels aangemaakt per DHCP range in de vorm van "10.168.192.in-addr.arpa" met een server IP van 127.0.0.1. Ook heb ik dergelijke regels per domain dus "servers.internal" met een server IP van 127.0.0.1. Dit scheen te moeten om DNSMasq en Unbound met elkaar te laten praten.

Zoals gezegd lijkt er iets niet goed te gaan binnen Opnsense. Maar waar is mij op dit moment nog niet duidelijk.

[Airw0lf]

@tikkietrugjaap - wat is de nood om met unbound te gaan werken?

Mijn inschatting is dat je er niet aan gaat ontkomen om dnsmasq ook in te zetten voor dns resolving. Waarbij dnsmasq de forwarder is voor unbound - zo heb ik het in ieder geval opgelost.

[Dracoz]

tikkietrugjaap schreef op dinsdag 21 juli 2026 @ 20:59:
Ok. Ik heb de berichten gelezen en het lijkt er steeds meer op dat ik iets niet goed heb ingesteld bij DNSMasq en Unbound. Eens kijken of ik zoveel mogelijk antwoorden kan geven zonder een chaotische post te maken:


[...]

getent ahosts desk9800.home.internal binnen de container levert niets op. Hij doet wel iets maar vervolgens zie ik gewoon weer de command prompt. Als ik het binnen de VM doe krijg ik:

192.168.10.103  STREAM desk9800.home.internal
192.168.10.103  DGRAM
192.168.10.103  RAW

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45044
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;desk9800.home.internal.                IN      A

;; ANSWER SECTION:
desk9800.home.internal. 1       IN      A       192.168.10.103

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:13 CEST 2026
;; MSG SIZE  rcvd: 67

dig desk9800.home.internal A binnen de container levert op:

; <<>> DiG 9.20.23 <<>> desk9800.home.internal AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5375
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;desk9800.home.internal.                IN      AAAA

;; Query time: 0 msec
;; SERVER: 127.0.0.11#53(127.0.0.11) (UDP)
;; WHEN: Tue Jul 21 20:08:07 CEST 2026
;; MSG SIZE  rcvd: 40

In beide gevallen wordt de Docker DNS aangesproken (127.0.0.11) maar alleen bij ipv4 gaat het goed.


[...]

Mijn VM's zijn allemaal Ubuntu Server (op Home Assistant na). Je bedoelde waarschijnlijk een docker container op basis van ubuntu dus die heb ik opgestart met "sudo docker run --rm --network noipv6 -it ubuntu". Daarna iputils geïnstalleerd en een ping naar desk9800 verliep inderdaad vlekkeloos.


[...]

In jouw voorbeeld ping je google.com. Dat lukt bij mij, vanuit de container, wel. Hij pingt dan automatisch een ipv4 adres. Probeer ik echter jouw stappen maar ping ik mijn eigen host (desk9800) dan krijg ik hetzelfde resultaat.


[...]

Ik heb die regel nog niet geprobeerd, bedankt daarvoor. Echter ben ik het wel met @Dracoz eens dat dit beter geregeld kan worden op netwerkniveau. Ik heb iets niet goed ingesteld binnen Opnsense, lijkt het op. Mijn configuratie is, denk ik, niet heel niche. Opnsense router op een kleine PC, daarop DNSMasq voor DHCP en Unbound voor DNS zodat alle hosts middels FQDN kunnen worden gevonden. Een aantal VLANs maar op dit moment hebben die allemaal nog een allow all regel. Elke VLAN zijn eigen domain (home.internal, servers.internal, iot.internal, etc.).


[...]

Ik heb inderdaad 'register DHCP leases' aanstaan binnen Unbound. Ook heb ik, bij Query Forwarding regels aangemaakt per DHCP range in de vorm van "10.168.192.in-addr.arpa" met een server IP van 127.0.0.1. Ook heb ik dergelijke regels per domain dus "servers.internal" met een server IP van 127.0.0.1. Dit scheen te moeten om DNSMasq en Unbound met elkaar te laten praten.

Zoals gezegd lijkt er iets niet goed te gaan binnen Opnsense. Maar waar is mij op dit moment nog niet duidelijk.

Ah top dat resultaat, hier zie je direct dat inderdaad glibc het niets boeit dat die op ipv6 een error terug krijgt maar dat de musl libc volledig kapot gaat daarop.

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill. Wat je beter kan doen is gewoon in de custom.d folder van unbound een .conf bestand aan te maken met het volgende:

server: 
     local-zone: "home.internal." transparent 
     local-zone: "servers.internal." transparent 
     local-zone: "iot.internal." transparent

Standaard behandelt unbound een lokaal domein vaak namelijk heel strikt of static of deny. Zodra Alpine dan om een AAAA record vraagt wat niet in Unbound staat denk denkt unbound dat het niet bestaat en geeft die een serverfail. Zodra je dit instelt op transparant dan verander je dit gedrag door aan te geven dat als de AAAA record niet bestaat hij gewoon een noerror teruggeeft.

Hoop dat het nu duidelijk is!

[Airw0lf]

Dracoz schreef op dinsdag 21 juli 2026 @ 23:15:
[...]

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill.

Hoop dat het nu duidelijk is!

Voor mij in ieder geval wel - dank je!

Kan je dan ook volstaan met één regel: local-zone: "internal." transparent? Met het idee dat dan alles wat eindigt op internal op die manier wordt afgehandeld?

Wat ik me ook nog afvraag is hoe unbound weet gaat krijgen van de door dnsmasq uitgegeven ip adressen en bijbehorende, geregistreerde systeemnamen? Hoe zou dat moeten werken?

[ Voor 20% gewijzigd door Airw0lf op 22-07-2026 07:47 ]

[tikkietrugjaap]

Airw0lf schreef op dinsdag 21 juli 2026 @ 21:45:
@tikkietrugjaap - wat is de nood om met unbound te gaan werken?

Mijn inschatting is dat je er niet aan gaat ontkomen om dnsmasq ook in te zetten voor dns resolving. Waarbij dnsmasq de forwarder is voor unbound - zo heb ik het in ieder geval opgelost.

Ik heb dat zo ingesteld nadat ik had gezocht naar oplossingen om hostnames van verschillende apparaten die via DNSMasq een IP krijgen vindbaar te maken. Dit om te voorkomen dat ik IP adressen moest gaan onthouden of teveel DHCP adressen static moest maken.

Dracoz schreef op dinsdag 21 juli 2026 @ 23:15:
[...]

Ah top dat resultaat, hier zie je direct dat inderdaad glibc het niets boeit dat die op ipv6 een error terug krijgt maar dat de musl libc volledig kapot gaat daarop.

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill. Wat je beter kan doen is gewoon in de custom.d folder van unbound een .conf bestand aan te maken met het volgende:

server: 
     local-zone: "home.internal." transparent 
     local-zone: "servers.internal." transparent 
     local-zone: "iot.internal." transparent

Standaard behandelt unbound een lokaal domein vaak namelijk heel strikt of static of deny. Zodra Alpine dan om een AAAA record vraagt wat niet in Unbound staat denk denkt unbound dat het niet bestaat en geeft die een serverfail. Zodra je dit instelt op transparant dan verander je dit gedrag door aan te geven dat als de AAAA record niet bestaat hij gewoon een noerror teruggeeft.

Hoop dat het nu duidelijk is!

Ik ga hier mee aan de slag. De gedachte erachter is mij helaas nog onduidelijk maar dat komt omdat ik simpelweg geen kaas heb gegeten van DNS. Ik zou niet eens weten wat het verschil is tussen een transparent local-zone en de andere opties. Moet toch maar eens op zoek naar wat meer achterliggende informatie m.b.t. dit onderwerp. Ik vind het wel opmerkelijk dat dit niet in de GUI van Unbound kan worden ingesteld. Maar wellicht is dat een keuze geweest van het Opnsense-team.
In ieder geval bedankt voor de informatie.

[tikkietrugjaap]

Dracoz schreef op dinsdag 21 juli 2026 @ 23:15:
[...]

Ah top dat resultaat, hier zie je direct dat inderdaad glibc het niets boeit dat die op ipv6 een error terug krijgt maar dat de musl libc volledig kapot gaat daarop.

Gelukkig is de oplossing erg simpel, je hoeft niet je hele keten om te gooien en Dnsmasq als forwarder voor unbound te zetten, dit kan uiteraard maar is imho beetje overkill. Wat je beter kan doen is gewoon in de custom.d folder van unbound een .conf bestand aan te maken met het volgende:

server: 
     local-zone: "home.internal." transparent 
     local-zone: "servers.internal." transparent 
     local-zone: "iot.internal." transparent

Standaard behandelt unbound een lokaal domein vaak namelijk heel strikt of static of deny. Zodra Alpine dan om een AAAA record vraagt wat niet in Unbound staat denk denkt unbound dat het niet bestaat en geeft die een serverfail. Zodra je dit instelt op transparant dan verander je dit gedrag door aan te geven dat als de AAAA record niet bestaat hij gewoon een noerror teruggeeft.

Hoop dat het nu duidelijk is!

Terugkoppeling over het bovenstaande.

Ik moest even opzoeken hoe het .conf bestand moest heten en dat was blijkbaar "custom-local-zones.conf". Ik heb dit gemaakt en de regels die jij aangaf erin gezet. Daarna zowel DNSMasq als Unbound opnieuw gestart. Het resultaat was helaas precies als voorheen.

Wat ik daarna heb gedaan is bij Query forwarding de regel voor het domein servers.internal, die naar server IP 127.0.0.1 port 53053 (wat DNSMasq is) verwees, gedisabled. Dat resulteerde in dezelfde foutmelding (Bad Address) maar die foutmelding kwam wel veel sneller. Dat deed me vermoeden dat de foutmelding voornamelijk vanuit DNSMasq kwam. Ik ben toen nog eens in de instelling van DNSMasq gaan zoeken en kwam de optie "DHCP local domain" tegen. De uitleg bij die optie is "Sets all DHCP domains as local. This will configure this DNS server as authoritative; it will not forward queries to any upstream servers for these domains". Dat leek mij een goede om te proberen en inderdaad, nadat ik die optie had aangevinkt, zowel DNSMasq als Unbound opnieuw had opgestart kon in normaal pingen vanuit mijn Docker containers.

Ik vermoed dat er mensen zullen zijn met kennis van DNS die nu vrij luid "duh" roepen maar ik ben vrij content met het resultaat.

Waar ik nog wel een beetje mee zit is dat ik niet uit kan leggen wat er voorheen fout ging en waarom het nu wel werkt. Voor zover ik het begrijp krijgt DNSMasq een DNS verzoek van Unbound voor een host op één van de lokale domeinen. Ik zou toch vermoeden dat hij daar dan gewoon een resultaat voor geeft zoals hij dat ook doet voor alle andere verzoeken maar blijkbaar werkt dat anders.
Ik ben online gaan zoeken naar lesmateriaal om meer over DNS te leren maar dat is een rabbit hole op zichzelf.

Anyway, iedereen bedankt voor het meedenken.

[Airw0lf]

@tikkietrugjaap - mijn 0,500 Euro:

De oorzaak ligt in beiden - unbound en dnsmasq.

Allereerst unbound - die lijkt vooral te zijn gebouwd rondom external DNS resolving bij de bron van het DNS domein. Waarbij af fabriek local resolving niet (goed) werkt. Om dit in goede banen te leiden heb ik in unbound onderstaande settings in een custom config bestand gestoken.

De twee server settings zorgen er voor dat reverse dns lookups goed werken - ook als er geen dnssec actief is (wat in de meeste thuis netwerkjes het geval is).

De eerste forward-zone vertellen unbound waar die terecht kan voor alle domains die eindigen op .lan - in mijn geval dus alle vlans. De tweede forward-zone doet hetzelfde voor alle reverse DNS lookups voor alle vlans. De derde forward-zone is voor external DNS lookups - die worden afgehandeld door bepaalde DNS servers van Cloudflare en KPN.

code:

server:
    insecure-lan-zones: yes
    local-zone: "168.192.in-addr.arpa." nodefault

forward-zone:
    name: "lan."
    forward-addr: 192.168.230.235

forward-zone:
    name: "168.192.in-addr.arpa."
    forward-addr: 192.168.230.235

forward-zone:
    name: "."
    forward-addr: 1.1.1.2
    forward-addr: 1.0.0.2
    forward-addr: 195.121.97.203
    forward-addr: 195.121.97.202

Dan dnsmasq - dat ligt wat ingewikkelder als je met vlans werkt.

Hieronder allereerst mijn aanpak voor vlans.

Via systemd-networkd heb ik de nodige vlan interfaces aangemaakt; waaronder eth0.210, eth0.220 en eth0.230. Het management "vlan" is bij mij altijd eth0. Vervolgens via een dnsmasq-config bestandje de vlans voorzien van dhcp en dns - hieronder een paar van die vlans. Je ziet dat elk vlan/domain aangemerkt is als local domain. Hierdoor blijven alle dns aanvragen lokaal.

code:

# Wired - vlan 210
domain=wired.lan,192.168.210.0/24,local
dhcp-range=set:vlan-210,192.168.210.11,192.168.210.99,168h
dhcp-option=tag:vlan-210,option:router,192.168.210.241
dhcp-option=tag:vlan-210,option:dns-server,192.168.210.235,192.168.100.234
dhcp-option=tag:vlan-210,option:ntp-server,192.168.210.235

# Binnenkant WiFi - vlan 220
domain=wifi.lan,192.168.220.0/24,local
dhcp-range=set:vlan-220,192.168.220.11,192.168.220.99,168h
dhcp-option=tag:vlan-220,option:router,192.168.220.241
dhcp-option=tag:vlan-220,option:dns-server,192.168.220.235,192.168.100.234
dhcp-option=tag:vlan-220,option:ntp-server,192.168.220.235

# Domotica & IoT - vlan 230 - dns forwarder is dnsmasq on homey-be
domain=domotica.lan,192.168.230.0/24,local
dhcp-range=set:vlan-230,192.168.230.11,192.168.230.99,168h
dhcp-option=tag:vlan-230,option:router,192.168.230.241
dhcp-option=tag:vlan-230,option:dns-server,192.168.230.209
dhcp-option=tag:vlan-230,option:ntp-server,192.168.230.235

Om het gedrag zo voorspelbaar mogelijk te krijgen zijn in een apart dnsmasq config bestandje onderstaande parameters opgenomen. Met bind-interfaces zorg je er voor dat dnsmasq alleen actief wordt op daadwerkelijk vooraf bepaalde, bestaande interfaces (versus 0.0.0.0). De no-dhcp zorgt er voor dnsmasq niks doet met dhcp aanvragen via docker.

De laatste 3 zorgen er voor het betreffende systeem gezien wordt als enige dhcp server die altijd zorgt voor een fqdn op basis van het mac-adres - dit laatste wordt afgedwongen via dhcp-ignore-clid.

code:

bind-interfaces
no-dhcp-interface=docker0

dhcp-fqdn
dhcp-authoritative
dhcp-ignore-clid

Er zijn ook nog een paar dns parameters die hier kunnen helpen - maar het voert te ver om die ook allemaal hier op te nemen en uit te leggen. Dit omdat ik dnsmasq gebruik op basis van pihole waardoor een aantal dingen automagically ingesteld worden.

Aangezien dit alles behoorlijk off-topic is wil ik voorstellen om vervolg vragen via een PM te doen.

[ Voor 3% gewijzigd door Airw0lf op 22-07-2026 23:28 ]

[DjoeC]

Gekke vraag misschien maar toch want ik zie vast ergens iets over het hoofd.....

Ik draai op een Pi 5 met veel tevredenheid OpenMediaVault. Nu staat OMV geen desktopomgeving toe op het basis OS, hun keuze en eigenlijk ook wel prima. Op OMV draai ik Docker dus mijn denken is: Waarom geen Raspi OS desktop in Docker, zeg maar: een Raspi in een VM achtige oplossing.

Zoeken heeft me nog niks opgeleverd en dus hier de vraag: Is dit een mogelijkheid en waar kan ik meer info vinden?

[Airw0lf]

DjoeC schreef op donderdag 23 juli 2026 @ 13:20:
Gekke vraag misschien maar toch want ik zie vast ergens iets over het hoofd.....

Ik draai op een Pi 5 met veel tevredenheid OpenMediaVault. Nu staat OMV geen desktopomgeving toe op het basis OS, hun keuze en eigenlijk ook wel prima. Op OMV draai ik Docker dus mijn denken is: Waarom geen Raspi OS desktop in Docker, zeg maar: een Raspi in een VM achtige oplossing.

Zoeken heeft me nog niks opgeleverd en dus hier de vraag: Is dit een mogelijkheid en waar kan ik meer info vinden?

Je kan in OMV - naast de Docker plugin - ook de KVM-plugin installeren. En dan een VM aanmaken met een RPI-OS-plus-desktop. Als ik vragen mag: waarom zou je dat willen doen?

[ Voor 5% gewijzigd door Airw0lf op 23-07-2026 13:38 ]

[DjoeC]

Airw0lf schreef op donderdag 23 juli 2026 @ 13:35:
[...]

Je kan in OMV - naast de Docker plugin - ook de KVM-plugin installeren. En dan een VM aanmaken met een RPI-OS-plus-desktop. Als ik vragen mag: waarom zou je dat willen doen?

Dank je, ik ga die optie eens goed doorlezen. Waarom? Ik wil continue een browserapplicatie met wat automatische acties op de achtergrond laten draaien en die remote kunnen benaderen. En nu bedenk ik me (...) de vraag had dus ook kunnen zijn: Een browser (FF, Chromium, whatever) in Docker. En ik zie nu dat er een Firefox container is voor ARM64, zie je wel: je hebt me getriggerd dat ik de simpele oplossing over t hoofd heb gezien.

Maar, ik ga me ook eens verdiepen in de KVM optie.

[Airw0lf]

DjoeC schreef op donderdag 23 juli 2026 @ 14:15:
[...]

Dank je, ik ga die optie eens goed doorlezen. Waarom? Ik wil continue een browserapplicatie met wat automatische acties op de achtergrond laten draaien en die remote kunnen benaderen. En nu bedenk ik me (...) de vraag had dus ook kunnen zijn: Een browser (FF, Chromium, whatever) in Docker. En ik zie nu dat er een Firefox container is voor ARM64, zie je wel: je hebt me getriggerd dat ik de simpele oplossing over t hoofd heb gezien.

Maar, ik ga me ook eens verdiepen in de KVM optie.

Ok - maar nog steeds... misschien mis ik iets... maar hoe zie je dat met die remote toegang? Want of je een browser gebruikt in een Docker container of in een VM maakt eigenlijk niet uit - remote toegang is nog steeds beperkt tot een CLI/SSH login - toch?

[DjoeC]

Airw0lf schreef op donderdag 23 juli 2026 @ 15:55:
[...]

Ok - maar nog steeds... misschien mis ik iets... maar hoe zie je dat met die remote toegang? Want of je een browser gebruikt in een Docker container of in een VM maakt eigenlijk niet uit - remote toegang is nog steeds beperkt tot een CLI/SSH login - toch?

Ik hoopte op browser in browser waarbij de onderliggende doorloopt als de wrapper afsluit (hopelijk snap je wat ik probeer te zeggen), en ik weer verder kan zodra ik de onderliggende opnieuw benader.

Vergelijk het met een duurtest van de onderliggende browser alleen moet er af en toe wat gewijzigd worden terwijl het draait. Ik kan natuurlijk een losse Pi inrichten, maar dat is nou net niet de bedoeling. Ik wil dus een browser draaien/kunnen benaderen op een headless machine zonder grafische interface omdat OMV dat niet geweldig vind maar mijn Pi5 nog meer dan voldoende capaciteit heeft.

[ Voor 26% gewijzigd door DjoeC op 24-07-2026 10:48 ]

[LEDfan]

Een browser in een Docker container wordt vaak gebruikt voor front-end testen of om automatisch screenshots te nemen. Dit is dan vaak een headless versie van Chrome aangestuurd met https://playwright.dev/ , https://www.selenium.dev/ etc.
Als je echt de browser UI wilt kunnen gebruiken, kan je X en VNC in een Docker container draaien. Bv met https://github.com/fcwu/docker-ubuntu-vnc-desktop , maar misschien zijn er wel meer up to date projecten.

[synoniem]

LEDfan schreef op zaterdag 25 juli 2026 @ 11:13:
Een browser in een Docker container wordt vaak gebruikt voor front-end testen of om automatisch screenshots te nemen. Dit is dan vaak een headless versie van Chrome aangestuurd met https://playwright.dev/ , https://www.selenium.dev/ etc.
Als je echt de browser UI wilt kunnen gebruiken, kan je X en VNC in een Docker container draaien. Bv met https://github.com/fcwu/docker-ubuntu-vnc-desktop , maar misschien zijn er wel meer up to date projecten.

Een meer recent voorbeeld is https://github.com/jlesage/docker-baseimage-gui.

[DjoeC]

@LEDfan @synoniem Komende week wordt t te heet voor de tuin dus ene moment om eens wat te stoeien.
En ja, ik wil echt de UI vanaf de voorgrond (andere browser) kunnen gebruiken en op de achtergrond als (pseudo full-screen) actief houden.

Selenium heb ik van gehoord als testtool. Dat zou voordelen kunnen hebben maar ik weet niet of je daar tijdens een run kunt wijzigen, extra klikken/invullen/etc. En da's geen docker discussie