The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long
GoT voor Behoud der Nederlandschen Taal [GvBdNT
Precies. In het bedrijf waar ik werkte was ik zeg maar de container guruGhoulli schreef op woensdag 24 juli 2024 @ 11:30:
[...]
@alex3305 Zo hé, dat klinkt eigenlijk ideeal. Ben ik ook meteen van het probleem af dat als ik de Gluetun container opnieuw opstart dat ik ook de ander opnieuw op moet starten. Dan doe ik ze met de docker compose gewoon in een keer. Ik heb hier inderdaad de ideale usecase voor om te testen hoe dat werkt.
Dat geldt hetzelfde voor NGINX Proxy Manager. Dat is een super mooie suggestie. Die gebruik ik zelf ook, ook al ben ik voldoende bekend met alternatieven zoals HAProxy, Caddy of Traefik. Om de doodeenvoudige reden dat het voor mij een mooi stuk gereedschap was (met gebreken!) die ik uit de kast kon trekken en direct kon gebruiken. Ik ben nu, na een jaartje of wat NGINX Proxy Manager, aan het kijken naar een alternatief. Of misschien niet. Maar doe dat rustig aan, het moet niet morgen 'af'
Dit is een top advies! Hier ben ik het 1000% procent mee eens. Zet bijvoorbeeld ook je eigen Git server op met Gitea (of Forgejo) zodat je je Compose bestanden onder versiebeheer hebt. Of begin eerst met GitHub en migreer daarna naar Gitea. Kan allemaal. Maar blijf het documenteren en het liefste onder versiebeheer houden. Momenteel gebruik ik daar trouwens (een self hosted) Outline voor. Maar daarvoor heb ik lang Obsidian met Git sync gebruikt.DjoeC schreef op woensdag 24 juli 2024 @ 12:12:
[...]
Tip: Documenteer alles wat je doet, inclusief de truukjes om het netjes te krijgen. Er komt een moment dat je het opnieuw wilt gaan doen ;-)
Ik documenteer momenteel in excel. Voldoende handig en versiebeheer via de versies die maximaal 1 jaar bij Backblaze staan, ik weet: da's houtje-touwtje maar voor mij voldoende. Ik ben geen enterprise organisatie.
Hier hebben we het volgens mij al een keer eerder over gehad. Maar ik kan mij hier dus niet in vinden. Ik heb per stack een database draaien. Die kosten zo weinig resources dat ik het onzin vind om daar op te bezuinigen. En daar ben ik heel erg bewust mee bezig omdat ik mijn server zo energiezuinig mogelijk wil houden. PostgreSQL databases gebruiken gemiddeld ~42MB RAM en 0% CPU. Mijn Redis instanties gebruiken zo'n 10MB RAM. En de Home Assistant MariaDB gebruikt 1GB RAM maar daar wordt constant naar geschreven, dus dat is niet zo gek.DjoeC schreef op woensdag 24 juli 2024 @ 12:12:
[...]
Als je bijvoorbeeld een database container meerdere keren definieerd in meerdere compose files krijg je ook meerdere database instanties. Ik houdt het liever bij 1 stuk.
Daarnaast wil ik dat de stacks onafhankelijk kunnen draaien. Een externe afhankelijkheid vind ik buiten de geest van Docker Compose gaan. Maar wellicht verschillen wij daar van inzicht.
Even voor de duidelijkheid, Dockge auto-update niets. Maar in Dockge heb ik, in tegenstelling tot Portainer, wel een update knop:DjoeC schreef op woensdag 24 juli 2024 @ 12:25:
[...]
Ik ben toch wat bewuster geworden met auto-update (of ongezien updaten) sinds ik een MariaDB instantie had die in maintenance mode bleef hangen. Kun je met Dockge sturen welke containers wel/niet geautoupdate mogen worden?
/f/image/IrM1tk9Eq8US7LNqyCm3o6RV.png?f=fotoalbum_large)
Databases pin ik op major of minor versies. Bij MariaDB bijvoorbeeld op 10.7 of 10.8 en bij PostgreSQL op 15 of 16. Wel update ik die gewoon met Watchtower met labels, zoals @Freee!! ook suggereert:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| watchtower: container_name: ${COMPOSE_PROJECT_NAME}-watchtower image: containrrr/watchtower restart: on-failure environment: TZ: ${TZ:-Europe/Amsterdam} WATCHTOWER_CLEANUP: true WATCHTOWER_LOG_LEVEL: error WATCHTOWER_SCHEDULE: '0 0 1 * * *' WATCHTOWER_SCOPE: ${COMPOSE_PROJECT_NAME} network_mode: bridge volumes: - /var/run/docker.sock:/var/run/docker.sock labels: 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' |
Bovenstaande is een snippet uit het template wat ik gebruik voor elke Compose stack. Wat ook niet helemaal waar is, want sommige stacks hebben vanwege het kritieke karakter geen Watchtower. Home Assistant wil ik bijvoorbeeld niet auto-updaten.
Mijn primaire en secundaire DNS update ik wel automatisch met Watchtower, maar dat doe ik op twee compleet verschillende tijdstippen. Dat verlaagt het risico van een slechte update enorm, maar neemt het uiteraard niet helemaal weg.
Het enige wat ik niet backup zijn Redis containers. Die slaan hun data zelfs op in memory door middel van een mount naar /dev/shm. Bijvoorbeeld zo: /dev/shm/cache/immich/redis:/data. Dat zorgt ervoor dat de SSD ontlast wordt voor deze soort caching.
Dit is tot nog toe niet hoe ik het voor ogen heb maar ik ben opgegroeid en gevormd in "een andere tijd" waar resources beperkt en vooral duur waren. Maar stilstand is achteruitgang, er is nog steeds veel te leren en dus ga ik over jouw methode eens goed nadenken.
Maar, sprekend over "hoe docker bedoeld is", in mijn beleving is het doel dat de container enkelvoudig of meervoudig draait op het moment dat er vraag is naar de functionaliteit van een container. Dat betekent (sutomatisch) starten bij vraag en stoppen als de vraag is afgehandeld. Zoals we hier bespreken staan containers vooral te wachten op werk. Het "op afroep" starten heb ik bij docker eigenlijk nog niet kunnen vinden. Voorbeeld: Een dagelijks MQTT bericht dat "beschikbaar" komt moet een container starten, een taak uitvoeren en de container daarna weer stoppen. Het stoppen is geen probleem, het starten nog wel. Heb je daar ook een oplossing voor?
Ho ho.DjoeC schreef op donderdag 25 juli 2024 @ 11:08:
@alex3305 AHA, ik begin te begrijpen hoe jij dat doet: Alles, inclusief Watchtower, in een stack.
Dit is tot nog toe niet hoe ik het voor ogen heb maar ik ben opgegroeid en gevormd in "een andere tijd" waar resources beperkt en vooral duur waren. Maar stilstand is achteruitgang, er is nog steeds veel te leren en dus ga ik over jouw methode eens goed nadenken.
Ook op het werk had ik altijd maar vaak een te beperkte bak resources beschikbaar. Daar was het ook de standaard om een monolithische applicatie opzet te hebben met een gedeelde database. Echter zorgde dat in die situatie ook vaak voor onvoorziene problemen. Waaronder rechten, beheer en onderhoud. Want je moest bijvoorbeeld updates afstemmen tussen klanten en dat gaf nogal eens wrijving.
Met containers zijn we toen eigenlijk relatief snel (<5 jaar) overgegaan naar containers per klant en per omgeving. Dat was qua resources iets duurder, want wij rekende altijd met een X-hoeveelheid geheugen en CPU per (database) container zodat we ook plek konden reserveren op (virtuele) servers. Wat we toen echter merkte is dat het werk vele malen eenvoudiger werd. Ook het beheer en onderhoud. En als er iets misging had je ook maar één klant en/of één omgeving waar je je druk over hoefde te maken. Ook was het met een OTAP straat ook een stuk eenvoudiger testen dan met een grote achterliggende en bijna black box database.
Als bijkomend voordeel hadden we ook plots portabiliteit, met uitzondering van een eventuele reverse proxy. Dit zorgde ervoor dat ontwikkelaars heel eenvoudig een stack op hun eigen machine konden deployen, maar dat ook een (extra) centrale omgeving in de lucht brengen kinderlijk eenvoudig werd. Of het downhalen hiervan. Dus als er geen ontwikkeltijd nodig is voor klant X kon je het OT of OTA-gedeelte eventueel down halen zodat je juist resources bespaard. Dit was zo krachtig, dat dit veel meer waard was dan die (zeg) 500MB RAM.
En uiteindelijk hielp het ook enorm om over te stappen naar een orchestration platform zoals Kubernetes. Dan kun je klant voor klant of applicatie voor applicatie migreren zonder rare (database) afhankelijkheden.
Hier wil ik graag een nuance in aanbrengen. Ik twijfelde ook enorm over mijn taalgebruik. Maar ik ben van mening dat Compose op deze manier bedoeld is of bedacht is. Daarmee zeg ik niet dat de andere manier met bijvoorbeeld centrale componenten of alles in 1 Compose bestand fout is. Ik denk alleen niet dat dat ooit de intentie is geweest. Ik vind het vooral prettig, en denk dus dat dat de intentie was, dat ik een Compose kan pakken van mijn systeem, jou door kan sturen en jij zonder aanpassingen kunt runnen. Zonder dat je daar nog ergens iets 'onbekends' moet hebben. En natuurlijk is dat onhaalbaar, maar even 'in de basis'.Maar, sprekend over "hoe docker bedoeld is", in mijn beleving is het doel dat de container enkelvoudig of meervoudig draait op het moment dat er vraag is naar de functionaliteit van een container.
Ja. Dit doe je in principe met orchestration, bijvoorbeeld Kubernetes. Dit kan met een kale Kubernetes, maar ook met een framework zoals Argo Events. Compose is hier niet geschikt voor omdat die een fout geeft als container(s) niet draaien. In Kubernetes kun je dit configureren.Dat betekent (sutomatisch) starten bij vraag en stoppen als de vraag is afgehandeld. Zoals we hier bespreken staan containers vooral te wachten op werk. Het "op afroep" starten heb ik bij docker eigenlijk nog niet kunnen vinden. Voorbeeld: Een dagelijks MQTT bericht dat "beschikbaar" komt moet een container starten, een taak uitvoeren en de container daarna weer stoppen. Het stoppen is geen probleem, het starten nog wel. Heb je daar ook een oplossing voor?
Overigens heb ik weleens iets vergelijkbaars met AMQP en Spring Integration geïmplementeerd. Maar daarbij bleef de container gewoon draaien, maar werden jobs ad hoc gestart. Na een job werd de applicatie herstart om het 'geheugen leeg te maken'. Dat was wel... interessant
Echter zou je een poor man's orchestration kunnen inrichten met een buildserver. Bijvoorbeeld Jenkins of TeamCity. Of met Gitea Actions. Bijvoorbeeld door iets te triggeren (ergens) met een webhook.
De RPi begaf het, dus ik ben de boel aan het overzetten naar een Ubuntu VM op Proxmox. Ik gebruik exact dezelfde container-config maar toch wil het niet werken.
Mijn compose-file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| services: mullvad: container_name: mullvad image: linuxserver/wireguard:latest cap_add: - NET_ADMIN - SYS_MODULE ports: - 8080:8080 volumes: - ${ROOTDIR}/mullvad/wg-de-fra:/config - /lib/modules:/lib/modules environment: - PUID=${PUID} - PGID=${PGID} - TZ=${TZ} - LOG_CONFS=true - KILL_SWITCH=ON sysctls: - net.ipv4.conf.all.src_valid_mark=1 - net.ipv6.conf.all.disable_ipv6=0 - net.ipv4.ip_forward=1 restart: unless-stopped |
In de container-logs staat dit:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| <knip> Uname info: Linux 6c77f957b15b 6.8.0-38-generic #38-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 7 15:25:01 UTC 2024 x86_64 GNU/Linux **** It seems the wireguard module is already active. Skipping kernel header install and module compilation. **** **** As the wireguard module is already active you can remove the SYS_MODULE capability from your container run/compose. **** **** If your host does not automatically load the iptables module, you may still need the SYS_MODULE capability. **** **** Client mode selected. **** [custom-init] No custom files found, skipping... **** Disabling CoreDNS **** **** Found WG conf /config/wg_confs/wg0.conf, adding to list **** **** Activating tunnel /config/wg_confs/wg0.conf **** Warning: `/config/wg_confs/wg0.conf' is world accessible [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.67.59.3 dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] resolvconf -a wg0 -m 0 -x s6-rc: fatal: unable to take locks: Resource busy [#] wg set wg0 fwmark 51820 [#] ip -6 route add ::/0 dev wg0 table 51820 [#] ip -6 rule add not fwmark 51820 table 51820 [#] ip -6 rule add table main suppress_prefixlength 0 [#] ip6tables-restore -n modprobe: can't load module ip6_tables (kernel/net/ipv6/netfilter/ip6_tables.ko.zst): invalid module format ip6tables-restore v1.8.10 (legacy): ip6tables-restore: unable to initialize table 'raw' Error occurred at line: 1 Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information. [#] resolvconf -d wg0 -f s6-rc: fatal: unable to take locks: Resource busy [#] ip -6 rule delete table 51820 [#] ip -6 rule delete table main suppress_prefixlength 0 [#] ip link delete dev wg0 **** Tunnel /config/wg_confs/wg0.conf failed, will stop all others! **** **** All tunnels are now down. Please fix the tunnel config /config/wg_confs/wg0.conf and restart the container **** [ls.io-init] done. |
Voor zover ik heb kunnen uitzoeken zou "s6-rc: fatal: unable to take locks: Resource busy" niet belemmerend moeten zijn.
Vanwege "modprobe: can't load module ip6_tables (kernel/net/ipv6/netfilter/ip6_tables.ko.zst): invalid module format" zoek ik dan naar op de docker-host, maar daar staat ip6_tables.ko.zst gewoon netjes in /lib/modules/6.8.0-38-generic/kernel/net/ipv6/netfilter . Ook vanuit de container zelf is dat pad, en de module-file, te zien.
Daarom zou ik concluderen dat deze oplossing niet van toepassing is. Is dat correct?
Zie ik iets over het hoofd, en/of is er een andere mogelijke oplossing?
Als een wireguard container niet gaat werken kan ik een openvpn-variant proberen maar dat is een last resort.
Ik gebruik wireguard-ui als container. Dan krijg je ook meteen een UI zodat je clients etc. kan aanmaken.WheeleE schreef op donderdag 25 juli 2024 @ 13:46:
Ik kom na een weekje puzzelen ook weereens buurten. Tot begin dit jaar draaide ik een linuxserver/wireguard container op een RPi om een mullvad tunnel op te zetten. Initieel wat issues met lekkende ip adressen maar met hulp van mensen hier in dit topic zoemde alles uiteindelijk prima.
De RPi begaf het, dus ik ben de boel aan het overzetten naar een Ubuntu VM op Proxmox. Ik gebruik exact dezelfde container-config maar toch wil het niet werken.
Mijn compose-file:
code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 services: mullvad: container_name: mullvad image: linuxserver/wireguard:latest cap_add: - NET_ADMIN - SYS_MODULE ports: - 8080:8080 volumes: - ${ROOTDIR}/mullvad/wg-de-fra:/config - /lib/modules:/lib/modules environment: - PUID=${PUID} - PGID=${PGID} - TZ=${TZ} - LOG_CONFS=true - KILL_SWITCH=ON sysctls: - net.ipv4.conf.all.src_valid_mark=1 - net.ipv6.conf.all.disable_ipv6=0 - net.ipv4.ip_forward=1 restart: unless-stopped
In de container-logs staat dit:
code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 <knip> Uname info: Linux 6c77f957b15b 6.8.0-38-generic #38-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 7 15:25:01 UTC 2024 x86_64 GNU/Linux **** It seems the wireguard module is already active. Skipping kernel header install and module compilation. **** **** As the wireguard module is already active you can remove the SYS_MODULE capability from your container run/compose. **** **** If your host does not automatically load the iptables module, you may still need the SYS_MODULE capability. **** **** Client mode selected. **** [custom-init] No custom files found, skipping... **** Disabling CoreDNS **** **** Found WG conf /config/wg_confs/wg0.conf, adding to list **** **** Activating tunnel /config/wg_confs/wg0.conf **** Warning: `/config/wg_confs/wg0.conf' is world accessible [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add 10.67.59.3 dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] resolvconf -a wg0 -m 0 -x s6-rc: fatal: unable to take locks: Resource busy [#] wg set wg0 fwmark 51820 [#] ip -6 route add ::/0 dev wg0 table 51820 [#] ip -6 rule add not fwmark 51820 table 51820 [#] ip -6 rule add table main suppress_prefixlength 0 [#] ip6tables-restore -n modprobe: can't load module ip6_tables (kernel/net/ipv6/netfilter/ip6_tables.ko.zst): invalid module format ip6tables-restore v1.8.10 (legacy): ip6tables-restore: unable to initialize table 'raw' Error occurred at line: 1 Try `ip6tables-restore -h' or 'ip6tables-restore --help' for more information. [#] resolvconf -d wg0 -f s6-rc: fatal: unable to take locks: Resource busy [#] ip -6 rule delete table 51820 [#] ip -6 rule delete table main suppress_prefixlength 0 [#] ip link delete dev wg0 **** Tunnel /config/wg_confs/wg0.conf failed, will stop all others! **** **** All tunnels are now down. Please fix the tunnel config /config/wg_confs/wg0.conf and restart the container **** [ls.io-init] done.
Voor zover ik heb kunnen uitzoeken zou "s6-rc: fatal: unable to take locks: Resource busy" niet belemmerend moeten zijn.
Vanwege "modprobe: can't load module ip6_tables (kernel/net/ipv6/netfilter/ip6_tables.ko.zst): invalid module format" zoek ik dan naar op de docker-host, maar daar staat ip6_tables.ko.zst gewoon netjes in /lib/modules/6.8.0-38-generic/kernel/net/ipv6/netfilter . Ook vanuit de container zelf is dat pad, en de module-file, te zien.
Daarom zou ik concluderen dat deze oplossing niet van toepassing is. Is dat correct?
Zie ik iets over het hoofd, en/of is er een andere mogelijke oplossing?
Als een wireguard container niet gaat werken kan ik een openvpn-variant proberen maar dat is een last resort.
Die werkt zonder problemen onder Ubuntu 24.04. Maar dan wel zonder Proxmox, dus bare-metal. Wie weet zit daar nog ergens een probleem?
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Hoe krijg je dat voor elkaar
The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long
GoT voor Behoud der Nederlandschen Taal [GvBdNT
Als ik wireguard-ui zo zie lijkt dat een server te zijn, geen client. Klopt dat?Mars Warrior schreef op donderdag 25 juli 2024 @ 13:57:
[...]
Ik gebruik wireguard-ui als container. Dan krijg je ook meteen een UI zodat je clients etc. kan aanmaken.
Die werkt zonder problemen onder Ubuntu 24.04. Maar dan wel zonder Proxmox, dus bare-metal. Wie weet zit daar nog ergens een probleem?
Mijn usecase is juist een container met een wireguard-client die verbinding maakt naar een externe wg-server.
Wel een mooie tool verder, dat wireguard-ui
Goeie vraag. Waarschijnlijk een rot boot-device (usb stick). Was niet de eerste keer dat dat gebeurde met van m'n RPi's, vandaar m'n overstap nu.
Ah! Klopt ja. Dan had ik jou config niet goed gelezen of begrepenWheeleE schreef op donderdag 25 juli 2024 @ 14:28:
[...]
Als ik wireguard-ui zo zie lijkt dat een server te zijn, geen client. Klopt dat?
Mijn usecase is juist een container met een wireguard-client die verbinding maakt naar een externe wg-server.
Wel een mooie tool verder, dat wireguard-ui
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Gisteren had ik wel een interessante gewaarwording. Momenteel draait mijn Jellyfin's webui achter een reverse proxy (Caddy). Ik had de portforwarding weer aangezet voor de poorten 80 en 443 en de caddyfile aangepast zodat deze werkt voor Jellyfin (hiervoor Traefik gebruikt). Ineens zag ik (ik had al een A-record staan bij Cloudflare) een geverifieerd TLS certificaat bij mijn webadres staan, Huh?! waar kom ik nou achter, Caddy regelt dat allemaal zelf. Nog nooit zo blij verast en in de war geweest op hetzelfde moment

Heb zelfs voor het opzetten van de Caddy container gebruik gemaakt van docker compose i.p.v. Portainer. Ik wilde het toch even proberen en dat ging eigenlijk best goed. Ik vond het vooral heel fijn dat ik error codes kreeg wanneer het niet goed ging met composen. Ik denk dat ik vanaf nu ga proberen om al mijn containers via docker compose op te zetten en via Portainer checken of alles goed gaat.
Tsja. Caddy is SSL by-default, vandaar dat ik die ook altijd aanbeveel.Ghoulli schreef op vrijdag 26 juli 2024 @ 08:30:
Zo, paar dagen verder en de omgeving is up-and-running. Ik ben inderdaad zoals jullie aangegeven hadden, @alex3305 en @DjoeC, gaan noteren wat ik nu gedaan heb om alles te laten draaien en waar mogelijk wat screenshotjes gemaakt van de huidige opstelling.
Gisteren had ik wel een interessante gewaarwording. Momenteel draait mijn Jellyfin's webui achter een reverse proxy (Caddy). Ik had de portforwarding weer aangezet voor de poorten 80 en 443 en de caddyfile aangepast zodat deze werkt voor Jellyfin (hiervoor Traefik gebruikt). Ineens zag ik (ik had al een A-record staan bij Cloudflare) een geverifieerd TLS certificaat bij mijn webadres staan, Huh?! waar kom ik nou achter, Caddy regelt dat allemaal zelf. Nog nooit zo blij verast en in de war geweest op hetzelfde moment.
En als je de Caddy docker proxy gebruikt kun je al je domeinen ook in je compose file zetten.Heb zelfs voor het opzetten van de Caddy container gebruik gemaakt van docker compose i.p.v. Portainer. Ik wilde het toch even proberen en dat ging eigenlijk best goed. Ik vond het vooral heel fijn dat ik error codes kreeg wanneer het niet goed ging met composen. Ik denk dat ik vanaf nu ga proberen om al mijn containers via docker compose op te zetten en via Portainer checken of alles goed gaat.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Durf ik nie zo te zeggen, maar zou heel goed kunnen natuurlijk. Het is alleen dat ik graag wat meer inzicht had over de foutcodes. De foutcodes die uit Portainer komen rollen zijn vaak nietszeggend dus moest weten wat er nou mis was met de /Caddyfile en de /site bij het opstarten.WheeleE schreef op vrijdag 26 juli 2024 @ 09:22:
Ik was in de veronderstelling dat stacks in Portainer ook van docker compose gebruik maakten? Althans, de yml-code die ik daar in plak is 1-op-1 gelijk aan de inhoud van docker-compose files.
Klopt. Als je naar de editor gaat staat er bovenaan ookWheeleE schreef op vrijdag 26 juli 2024 @ 09:22:
Ik was in de veronderstelling dat stacks in Portainer ook van docker compose gebruik maakten? Althans, de yml-code die ik daar in plak is 1-op-1 gelijk aan de inhoud van docker-compose files.
This stack will be deployed using docker compose.
This too shall pass
heb je al eens naar gluetun gekeken?WheeleE schreef op donderdag 25 juli 2024 @ 14:28:
[...]
Als ik wireguard-ui zo zie lijkt dat een server te zijn, geen client. Klopt dat?
Mijn usecase is juist een container met een wireguard-client die verbinding maakt naar een externe wg-server.
Wel een mooie tool verder, dat wireguard-ui![]()
[...]
offtopic:
Goeie vraag. Waarschijnlijk een rot boot-device (usb stick). Was niet de eerste keer dat dat gebeurde met van m'n RPi's, vandaar m'n overstap nu.
Ik gebruik deze om mijn torrent verkeer over een mullvad vpn te gooien
iPhone 15 Pro Max Titanium Black 256GB - iPad Pro 2018 12.9" Space Gray 64GB - AirPods Pro - Watch 5 Space Gray LTE - TV 4K 128GB - TV 4 64GB - Wireless CarPlay
Een hele lange en inhoudelijke post die eigenlijk een inhoudelijk antwoord verdient. Maar, dan ga ik richting methodieken van systeemontwikkeling en beheer, redenen voor al dan niet een bepaalde keuze die vooral gebaseerd zijn op eigen kennis en ervaring. Dat gaat te veel afwijken van het Docker topic....alex3305 schreef op donderdag 25 juli 2024 @ 11:37:
[...]
Ho ho., wellicht ben je iets ouder dan dat ik ben, maar ik heb die tijd nog zeker meegemaakt. Niet professioneel, maar wel als hobbyist. Vooral ook omdat ik tot een paar jaar geleden geen topsystemen heb gehad. Ik ben mezelf dan ook zeer bewust van resources. Sterker nog, tot aan een jaar geleden draaide ik mijn circa 50 containers op een Intel Celeron J4105 en Intel Celeron J1800. En sinds vorig jaar pas op de 10 keer snellere Intel Core i5 13500
. Ik weet echt wel wat resources besparen is
.
Ook op het werk had ik altijd maar vaak een te beperkte bak resources beschikbaar. Daar was het ook de standaard om een monolithische applicatie opzet te hebben met een gedeelde database. Echter zorgde dat in die situatie ook vaak voor onvoorziene problemen. Waaronder rechten, beheer en onderhoud. Want je moest bijvoorbeeld updates afstemmen tussen klanten en dat gaf nogal eens wrijving.
Met containers zijn we toen eigenlijk relatief snel (<5 jaar) overgegaan naar containers per klant en per omgeving. Dat was qua resources iets duurder, want wij rekende altijd met een X-hoeveelheid geheugen en CPU per (database) container zodat we ook plek konden reserveren op (virtuele) servers. Wat we toen echter merkte is dat het werk vele malen eenvoudiger werd. Ook het beheer en onderhoud. En als er iets misging had je ook maar één klant en/of één omgeving waar je je druk over hoefde te maken. Ook was het met een OTAP straat ook een stuk eenvoudiger testen dan met een grote achterliggende en bijna black box database.
Als bijkomend voordeel hadden we ook plots portabiliteit, met uitzondering van een eventuele reverse proxy. Dit zorgde ervoor dat ontwikkelaars heel eenvoudig een stack op hun eigen machine konden deployen, maar dat ook een (extra) centrale omgeving in de lucht brengen kinderlijk eenvoudig werd. Of het downhalen hiervan. Dus als er geen ontwikkeltijd nodig is voor klant X kon je het OT of OTA-gedeelte eventueel down halen zodat je juist resources bespaard. Dit was zo krachtig, dat dit veel meer waard was dan die (zeg) 500MB RAM.
En uiteindelijk hielp het ook enorm om over te stappen naar een orchestration platform zoals Kubernetes. Dan kun je klant voor klant of applicatie voor applicatie migreren zonder rare (database) afhankelijkheden.
[...]
Hier wil ik graag een nuance in aanbrengen. Ik twijfelde ook enorm over mijn taalgebruik. Maar ik ben van mening dat Compose op deze manier bedoeld is of bedacht is. Daarmee zeg ik niet dat de andere manier met bijvoorbeeld centrale componenten of alles in 1 Compose bestand fout is. Ik denk alleen niet dat dat ooit de intentie is geweest. Ik vind het vooral prettig, en denk dus dat dat de intentie was, dat ik een Compose kan pakken van mijn systeem, jou door kan sturen en jij zonder aanpassingen kunt runnen. Zonder dat je daar nog ergens iets 'onbekends' moet hebben. En natuurlijk is dat onhaalbaar, maar even 'in de basis'.
[...]
Ja. Dit doe je in principe met orchestration, bijvoorbeeld Kubernetes. Dit kan met een kale Kubernetes, maar ook met een framework zoals Argo Events. Compose is hier niet geschikt voor omdat die een fout geeft als container(s) niet draaien. In Kubernetes kun je dit configureren.
Overigens heb ik weleens iets vergelijkbaars met AMQP en Spring Integration geïmplementeerd. Maar daarbij bleef de container gewoon draaien, maar werden jobs ad hoc gestart. Na een job werd de applicatie herstart om het 'geheugen leeg te maken'. Dat was wel... interessant. Maar dan was ook hier de hoeveelheid geheugen bij idle verwaarloosbaar (<100MB).
Echter zou je een poor man's orchestration kunnen inrichten met een buildserver. Bijvoorbeeld Jenkins of TeamCity. Of met Gitea Actions. Bijvoorbeeld door iets te triggeren (ergens) met een webhook.
Laat ik dit zeggen: Er is altijd vooruitgang en vernieuwing. Als het zinvol is ga ik daar zeker in mee, het heeft geen zin om vastgeroest te raken en (ver)nieuwe(nde) dingen zijn altijd weer LEUK om mee kennis te maken. Aan de andere kant is er veel oude wijn in nieuwe zakken. Docker/Kubernetes/Swarm/Openshift, het is allemaal niet zo heel anders dan wat we al ministens 40 jaar in allerlei vormen onder allerlei namen kennen. Zaken als virtual machines, program isolation, (sys)plex, etc bestaan al heel lang.
Kubernetes, Argo, etc. Zaken om eens in te duiken. Alleen zitten er ook bij mij helaas maar 24 uur in een dag
Je zou nog naar Openfaas / faasd kunnen kijken. Dat zijn serverless functions. Voorheen was alles gratis, maar nu niet meer. Enkel faasd is dat nog.DjoeC schreef op vrijdag 26 juli 2024 @ 10:20:
[...]
Kubernetes, Argo, etc. Zaken om eens in te duiken. Alleen zitten er ook bij mij helaas maar 24 uur in een dagKubernetes spreekt me nog het minste aan maar stond al op m'n "mee te stoeien" lijstje. Wat ik wil bereiken krijg ik vast wel op eoa manier voor elkaar. Desnoods bouw ik een eigen "trigger" applicatie (in een losse container).
Daarmee kun je bijv. Github webhooks afvangen in je eigen applicatie, en daarop iets gaan doen. faasd start dan bijv. eenmalig een container...
Suc6!
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
In vond hier een beperkte verklaring. Zoals ik het lees: Ze zijn vrijwel hetzelfde maar compose is meer bedoeld voor Swarm en Stack voor single node. Compose is de "meest uitgebreide" versie gezien het commentaar:WheeleE schreef op vrijdag 26 juli 2024 @ 09:22:
Ik was in de veronderstelling dat stacks in Portainer ook van docker compose gebruik maakten? Althans, de yml-code die ik daar in plak is 1-op-1 gelijk aan de inhoud van docker-compose files.
"If you just need a tool to make it easier to handle running multiple containers at once, you can safely go ahead and stick with docker compose. It does everything you need, and you can still switch to docker stack later on if you want."
Portainer kan gebruik maken van Compose. Dat heten dan Stacks (weer ander jargon..). Je kunt ook losse containers deployen via een GUI. Dat maakt het aantrekkelijk voor de meeste nieuwelingen en die abstractie zorgt ook vaak voor (onverwachte) problemen.WheeleE schreef op vrijdag 26 juli 2024 @ 09:22:
Ik was in de veronderstelling dat stacks in Portainer ook van docker compose gebruik maakten? Althans, de yml-code die ik daar in plak is 1-op-1 gelijk aan de inhoud van docker-compose files.
Compose in Portainer vind ik overigens ook... bijzonder. Als je env_file's gebruikt moeten ze bijvoorbeeld stack.env heten anders werkt het niet. Bij andere, vergelijkbare applicaties is dat gewoon .env. Je kunt ook niet zomaar meerdere environment files gebruiken. Ook kan Portainer nog weleens de associatie met stacks kwijtraken. Dat is mij een aantal keer overkomen, bijvoorbeeld na een update. Dan moet je dus alles opnieuw deployen om weer het beheer te krijgen over stacks. Dat vond ik bijzonder irritant.
Op Linux en niet gratis heb ik voor prive gebruik een hekel aan. Ik ga ook die zeker s bekijken.Mars Warrior schreef op vrijdag 26 juli 2024 @ 10:30:
[...]
Je zou nog naar Openfaas / faasd kunnen kijken. Dat zijn serverless functions. Voorheen was alles gratis, maar nu niet meer. Enkel faasd is dat nog.
Daarmee kun je bijv. Github webhooks afvangen in je eigen applicatie, en daarop iets gaan doen. faasd start dan bijv. eenmalig een container...
Suc6!
Mijn docker-omgeving is relatief bescheiden, en single user. Tot op heden ben ik nog niet tegen beperkingen van Portainer aangelopen anders dan mijn eigen kennis.
Eergisteren werd in de selfhosted subreddit Beszel gepost. Ik ben meestal niet van de nieuwe dingen, maar dit was kinderlijk eenvoudig op te zetten. Met en zonder Docker. Mijn eerste indruk vooralsnog is goed. Het oogt erg aantrekkelijk:
/f/image/NJ81V64THfroQLjnYrkPHn5n.png?f=fotoalbum_large)
Mijn Compose met Hub en Agent ziet er dan zo uit:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
| --- services: hub: container_name: ${COMPOSE_PROJECT_NAME}-hub image: henrygd/beszel:${BESZEL_HUB_VERSION:-latest} restart: on-failure networks: br0: ipv4_address: 192.168.1.252 environment: TZ: ${TZ} DISABLE_PASSWORD_AUTH: ${DISABLE_PASSWORD_AUTH:-false} volumes: - ${APPDATA}/beszel:/beszel_data cpus: 0.25 labels: 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' agent: container_name: ${COMPOSE_PROJECT_NAME}-agent image: henrygd/beszel-agent:${BESZEL_AGENT_VERSION:-latest} restart: on-failure network_mode: host environment: TZ: ${TZ} PORT: 45876 KEY: ${BESZEL_KEY} volumes: - /var/run/docker.sock:/var/run/docker.sock:ro cpus: 0.1 labels: 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' watchtower: container_name: ${COMPOSE_PROJECT_NAME}-watchtower image: containrrr/watchtower restart: on-failure environment: TZ: ${TZ:-Europe/Amsterdam} WATCHTOWER_CLEANUP: true WATCHTOWER_LOG_LEVEL: error WATCHTOWER_SCHEDULE: '0 0 1 * * *' WATCHTOWER_SCOPE: ${COMPOSE_PROJECT_NAME} network_mode: bridge volumes: - /var/run/docker.sock:/var/run/docker.sock cpus: 0.1 labels: 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' networks: br0: name: br0 external: true |
En de bijbehorende env file:
1
2
3
4
| TZ=Europe/Amsterdam APPDATA=/opt/appdata/ DISABLE_PASSWORD_AUTH=true BESZEL_KEY=ssh-ed25519 KEY HERE |
De BESZEL_KEY krijg je van de Hub als je de eerste agent registreert.
En daarom ben ik wel blij met OMV-7 als basis. Zeker met de beschikbare variabelen, de overall en de compose specifieke .env mogelijkheden. Zo is het voor mij nu een fluitje van een cent om een 2e, 3e, n-de Joomla site te deployen. Voorbeeld:alex3305 schreef op vrijdag 26 juli 2024 @ 10:42:
[...]
Compose in Portainer vind ik overigens ook... bijzonder. Als je env_file's gebruikt moeten ze bijvoorbeeld stack.env heten anders werkt het niet. Bij andere, vergelijkbare applicaties is dat gewoon .env. Je kunt ook niet zomaar meerdere environment files gebruiken. Ook kan Portainer nog weleens de associatie met stacks kwijtraken. Dat is mij een aantal keer overkomen, bijvoorbeeld na een update. Dan moet je dus alles opnieuw deployen om weer het beheer te krijgen over stacks. Dat vond ik bijzonder irritant.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| services: CHANGE_TO_COMPOSE_NAME: hostname: "CHANGE_TO_COMPOSE_NAME" image: "joomla:5" container_name: "CHANGE_TO_COMPOSE_NAME" environment: - PUID=${PUID} - PGID=${PGID} - TZ=${TZ} - "JOOMLA_DB_HOST=${DDB_HOST}" - "JOOMLA_DB_NAME=CHANGE_TO_COMPOSE_NAME" - "JOOMLA_DB_USER=CHANGE_TO_COMPOSE_NAME" - "JOOMLA_DB_PASSWORD=CHANGE_TO_COMPOSE_NAME" networks: - user_bridge ports: - "85:80/tcp" restart: "unless-stopped" volumes: - ./html:/var/www/html - ./php_user.ini:/usr/local/etc/php/conf.d/user.ini networks: user_bridge: external: true name: "user_bridge" |
Ophalen, saven&opbrengen onder een nieuwe composefile naam en een nieuwe instantie draait.
<edit>
O ja, natuurlijk wel een ongebruikte poort aan toekennen (85 wijzigen in een andere).
Als je Caddy Docker Proxy zou gebruiken, dan hoef je geen aparte poorten toe te kennen. Alles mag lekker op dezelfde poort zitten. Je wijst gewoon een ander (sub)domein toe aan deze instantieDjoeC schreef op vrijdag 26 juli 2024 @ 10:51:
[...]
<edit>
O ja, natuurlijk wel een ongebruikte poort aan toekennen (85 wijzigen in een andere).
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Ben ik net een beetje gewend aan NPM en komt er weer een uitzoekklusje...... Heb overigens veel goeie dingen gelezen over Caddy maar vanwege veel meer (voor mij vindbare) info indertijd voor NPM gegaan.Mars Warrior schreef op vrijdag 26 juli 2024 @ 11:58:
[...]
Als je Caddy Docker Proxy zou gebruiken, dan hoef je geen aparte poorten toe te kennen. Alles mag lekker op dezelfde poort zitten. Je wijst gewoon een ander (sub)domein toe aan deze instantie
Voorheen gebruikte ik ook NPM, maar met inrichten nieuwe server in 2023 gekeken wat op dat moment het beste was. En dat was Caddy Docker Proxy. Een olugin op Caddy die docker instellingen kan inlezen en een Caddy file uitpoept.DjoeC schreef op vrijdag 26 juli 2024 @ 12:34:
[...]
Ben ik net een beetje gewend aan NPM en komt er weer een uitzoekklusje...... Heb overigens veel goeie dingen gelezen over Caddy maar vanwege veel meer (voor mij vindbare) info indertijd voor NPM gegaan.
Natuurlijk moet je ff leren hoe dat werkt met labels, maar daarna is het erg eenvoudig.
En oja. Ik gebruik Adguard als DNS. Daar pleur ik de (sub)domeinen in die ik voor Caddy gebruik.
Vanzelfsprekend kan ik later als ik thuis ben wat voorbeelden uit mijn compose file hier posten.
[ Voor 13% gewijzigd door Mars Warrior op 26-07-2024 13:19 ]
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Dit is echt de gouden tipYucko schreef op vrijdag 26 juli 2024 @ 10:12:
[...]
heb je al eens naar gluetun gekeken?
Ik gebruik deze om mijn torrent verkeer over een mullvad vpn te gooien(in mijn geval dan wel via openvpn, maar wireguard moet ook kunnen als ik de documentatie bekijk)
In een kwartiertje draait zowel de wireguardconnectie met Mullvad, als de container die er van gebruik maakt.
Deze opzet draait al vanaf april 2023 naar tevredenheid en nul onderhoud, anders dan af en toe een pull om de containers bij te werken...
Je hebt dus 2 labels nodig om een container publiek over SSL te ontsluiten, en 2 labels om iets lokaal over http te ontsluiten. Beide domeinen neem ik dan op in Adguard om een loopback te voorkomen (KPN Modems vinden het iha niet fijn om via een externe DNS weer terug bij zichzelf te komen).
Mijn Caddy definitie op basis van de plugin:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| infra-caddy: container_name: infra-caddy image: lucaslorentz/caddy-docker-proxy:ci-alpine restart: always networks: - web-proxy - infra environment: - CADDY_INGRESS_NETWORKS=web-proxy volumes: - /var/run/docker.sock:/var/run/docker.sock - $DOCKERDIR/infra/caddy/data:/data - $DOCKERDIR/infra/caddy/config:/config - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro extra_hosts: - host.docker.internal:host-gateway ports: - 443:443 - 80:80 labels: # # ===== Define global stuff for Caddy caddy.email: $EMAIL |
Lokale Portainer:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| mngt-portainer: container_name: mngt-portainer image: portainer/portainer-ce restart: always networks: - web-proxy volumes: - /var/run/docker.sock:/var/run/docker.sock - $DOCKERDIR/mngt/portainer/data:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro labels: caddy: http://portainer.home caddy.reverse_proxy: "{{upstreams 9000}}" |
En Immich op publiek domein:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| immich-server: container_name: immich_server image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} cpuset: $CPUSET_E_CORES_ALL volumes: - ${UPLOAD_LOCATION}:/usr/src/app/upload - ${EXTERNAL_ARCHIVE}:/usr/src/app/archive - /etc/localtime:/etc/localtime:ro networks: - web-proxy - immich env_file: - .env depends_on: - immich-redis - immich-database restart: always labels: caddy: immich.mijndomein.nl caddy.reverse_proxy: "{{upstreams 3001}}" |
En je kunt ook een externe webserver benaderen, die dus op een ander IP adres draait (Ik had voorheen 6 externe services toen ik Caddy aan het testen was...):
1
2
3
| labels: caddy_6: test.mijndomein.nl caddy_6.reverse_proxy: 192.168.8.100:6080 |
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Als ik diezelfde container met host network start werkt het wel.
Ik heb de DNS server al toegevoegd aan daemon.json.
En ook als parameter opgenomen bij het opstarten van de container.
Maar geen van twee hielp.
Iemand nog suggesties?
makes it run like clockwork
Het klinkt eerder dat je networking problemen hebt. Wat is de reeks aan IP-adressen die jij op jouw bridge network defined hebt? Is de DNS jouw router, een andere container of misschien die van Google? Mocht de het programma in de container een WebUI hebben, kun je daar wel bij?Airw0lf schreef op maandag 29 juli 2024 @ 23:21:
Als ik een container start met bridge network is er binnen de container geen DNS resolving.
Als ik diezelfde container met host network start werkt het wel.
Ik heb de DNS server al toegevoegd aan daemon.json.
En ook als parameter opgenomen bij het opstarten van de container.
Maar geen van twee hielp.
Iemand nog suggesties?
Verder heb ik hier geleerd dat de Docker Compose sturen erg handig kan zijn (deed ik ook niet
DNS resolving binnen de containers werkt prima - zolang de containers maar niet in bridge mode gestart worden.Ghoulli schreef op dinsdag 30 juli 2024 @ 08:26:
[...]
Het klinkt eerder dat je networking problemen hebt. Wat is de reeks aan IP-adressen die jij op jouw bridge network defined hebt? Is de DNS jouw router, een andere container of misschien die van Google? Mocht de het programma in de container een WebUI hebben, kun je daar wel bij?
Verder heb ik hier geleerd dat de Docker Compose sturen erg handig kan zijn (deed ik ook niet) om te helpen bij het troubleshooten. In de woorden van @alex3305, je geeft nog steeds weinig concrete informatie en ik hou niet zo van vissen
De Docker containers draaien op een Proxmox server met een LXC container.
Ik gebruik geen Docker Compose - enkel de CLI. Ik zal later vandaag het CLI commando posten.
makes it run like clockwork
Je hebt daarna wel docker opnieuw gestart?Airw0lf schreef op maandag 29 juli 2024 @ 23:21:
Als ik een container start met bridge network is er binnen de container geen DNS resolving.
Als ik diezelfde container met host network start werkt het wel.
Ik heb de DNS server al toegevoegd aan daemon.json.
En ook als parameter opgenomen bij het opstarten van de container.
Maar geen van twee hielp.
Iemand nog suggesties?
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Zelf vermoed ik dat het mogelijk iets te maken heeft met keep-alive over de GluetunVPN container. Hiervoor ben ik bezig om dus een nieuwe stack aan te maken via Docker Compose i.p.v. via Portainer twee aparte containers te gebruiken. Nu heb ik deze aangemaakt maar komt er geen data over de lijn heen, en ik begrijp niet helemaal waarom. Iemand een idee?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| version: "3" services: gluetun: image: qmcgaw/gluetun container_name: gluetun2 # line above must be uncommented to allow external containers to connect. # See https://github.com/qdm12/gluetun-wiki/blob/main/setup/connect-a-container-to-gluetun.md#external-container-to-gluetun cap_add: NET_ADMIN devices: /dev/net/tun:/dev/net/tun ports: 8888:8888/tcp # HTTP proxy 8388:8388/tcp # Shadowsocks 8388:8388/udp # Shadowsocks 6011:6011/tcp # qBittorrent WebUI 6887:6887/tcp # qBittorrent torrenting port 6887:6887/udp # qBittorrent torrenting port volumes: /gluetun:/gluetun environment:# See https://github.com/qdm12/gluetun-wiki/tree/main/setup#setup VPN_SERVICE_PROVIDER=custom VPN_TYPE=wireguard VPN_ENDPOINT_IP={Hier het endpoint adres} VPN_ENDPOINT_PORT=51820 WIREGUARD_PRIVATE_KEY={hier staat dan natuurlijk de Private Key} WIREGUARD_PUBLIC_KEY={Hier de public key} WIREGUARD_ALLOWED_IPS=0.0.0.0/0 WIREGUARD_ADDRESSES=10.2.0.2/32 DNS_ADDRESS=10.2.0.1 TZ= UPDATER_PERIOD=3h restart: unless-stopped qbittorrent: image: lscr.io/linuxserver/qbittorrent:latest container_name: qbittorrent2 network_mode: "service:gluetun" environment: PUID=1000 PGID=1000 TZ=Etc/UTC WEBUI_PORT=6011 TORRENTING_PORT=6887 volumes: /qbittorrent/config:/config /tempshows:/downloads #ports:# - 6011:6011# - 6887:6887# - 6887:6887/udp restart: unless-stopped |
Nu weet ik dat de private-public key combinatie werkt voor Wireguard. Deze heb ik even met de aparte gluetunvpn container getest en doet het daarna goed. Ik zou zo even niet weten wat er mis mee is.
Wanneer werkt het wel dan? Gezien bridge de default is is het IMO wel handig om er bii te vertellen in welk geval het dan wel werkt (host networking, waarbij Docker uberhaupt niks doet met netwerk gebeuren, of macvlan of ipvlan?).Airw0lf schreef op dinsdag 30 juli 2024 @ 08:34:
[...]
DNS resolving binnen de containers werkt prima - zolang de containers maar niet in bridge mode gestart worden.
Verder wat @Mars Warrior aangeeft, als je ee daemon.json aanpast Docker ook even opnieuw opstarten.
Daarnaast is er nog een hele lijst aan mogelijkheden om dingen te testen, maar eerst maar hier antwoorden op afwachten
Jawel - heb de LXC container opnieuw gestart.Mars Warrior schreef op dinsdag 30 juli 2024 @ 09:02:
[...]
Je hebt daarna wel docker opnieuw gestart?
Waaronder ook Docker en al zijn containers.
makes it run like clockwork
Even met een reverse proxy (aka SWAG) als voorbeeld:RobertMe schreef op dinsdag 30 juli 2024 @ 09:10:
[...]
Wanneer werkt het wel dan? Gezien bridge de default is is het IMO wel handig om er bii te vertellen in welk geval het dan wel werkt (host networking, waarbij Docker uberhaupt niks doet met netwerk gebeuren, of macvlan of ipvlan?).
Verder wat @Mars Warrior aangeeft, als je ee daemon.json aanpast Docker ook even opnieuw opstarten.
Daarnaast is er nog een hele lijst aan mogelijkheden om dingen te testen, maar eerst maar hier antwoorden op afwachten
Met onderstaande Docker-CLI werkt DNS resolving niet - ondanks de aanpassingen in daemon.json, Proxmox en de LXC container (steeds afgesloten met een reboot).
Als ik in de rev-proxy-settings de DNS naam vervang door het IP adres werkt het wel.
De DNS server is pihole - ook gestart als een Docker container met host als network parameter.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| #!/bin/sh docker stop swag docker rm swag docker pull linuxserver/swag:latest docker run -d \ --network bridge \ --name=swag \ --cap-add=NET_ADMIN \ -e TZ=Europe/Amsterdam \ -e URL=itv360.net \ -e VALIDATION=dns \ -e SUBDOMAINS=wildcard \ -e DNSPLUGIN=cloudflare \ -e PROPAGATION=60 \ -e EMAIL=support@itv360.net \ -e ONLY_SUBDOMAINS=false \ -e EXTRA_DOMAINS=it-visibility.net,*.it-visibility.net \ -e STAGING=false \ -p 192.168.139.235:443:443 \ -p 192.168.139.235:80:80 \ -v /opt/docker/swag/config:/config \ --restart unless-stopped \ linuxserver/swag:latest # Remove unused images docker image prune --all --force |
Met host als network parameter werkt SWAG wel goed via DNS resolving wel:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| #!/bin/sh docker stop swag docker rm swag docker pull linuxserver/swag:latest docker run -d \ --network host \ --name=swag \ --cap-add=NET_ADMIN \ -e TZ=Europe/Amsterdam \ -e URL=itv360.net \ -e VALIDATION=dns \ -e SUBDOMAINS=wildcard \ -e DNSPLUGIN=cloudflare \ -e PROPAGATION=60 \ -e EMAIL=support@itv360.net \ -e ONLY_SUBDOMAINS=false \ -e EXTRA_DOMAINS=it-visibility.net,*.it-visibility.net \ -e STAGING=false \ -v /opt/docker/swag/config:/config \ --restart unless-stopped \ linuxserver/swag:latest # Remove unused images docker image prune --all --force |
De Docker-CLI waarmee de pihole container gestart wordt:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
| #!/bin/sh docker stop pihole docker rm pihole docker pull pihole/pihole:latest docker run -d \ --name pihole \ --net host \ -v /opt/docker/pihole/etc-pihole:/etc/pihole \ -v /opt/docker/pihole/etc-dnsmasq.d:/etc/dnsmasq.d \ -e TZ=Europe/Amsterdam \ -e QUERY_LOGGING=false \ -e FTLCONF_LOCAL_IPV4=192.168.139.235 \ -e WEB_PORT=88 \ -e IPv6=false \ -e WEBTHEME=default-light \ -e DNSMASQ_USER=pihole \ --cap-add=NET_ADMIN \ --restart unless-stopped \ pihole/pihole:latest # Remove all unused images docker image prune --all --force |
makes it run like clockwork
$ docker run --rm -it --network bridge alpine cat /etc/resolv.conf # Generated by dhcpcd from br0.dhcp domain lan nameserver 192.168.1.1 $ docker run --rm -it --network proxy alpine cat /etc/resolv.conf nameserver 127.0.0.11 options ndots:0
Dan lijkt het erop dat jouw (systeem) DNS server ergens niet bereikt kan worden
Dat is het probleem. De pihole is nu dus eigenlijk een service die draait op de host. Je wil dus vanaf een bridge container verbinding maken met een service op de host. Dat gaat niet zomaar.Airw0lf schreef op dinsdag 30 juli 2024 @ 09:56:
[...]
De DNS server is pihole - ook gestart als een Docker container met host als network parameter.
Je zou kunnen overwegen om een extra bridge netwerk te maken waar je zowel de pihole als de container die je daar verbinding mee wil laten maken in stopt.
Of hier een kijkje nemen: https://docs.docker.com/d...use-cases-and-workarounds
Ben ff kwijt waar dit nu staat, maar dit klinkt als een kip-ei probleem: als de DNS niet geresolved kan worden, dan klinkt dit erg logisch om een IP adres in te voeren, immers wie zou de DNS moeten zijn?Airw0lf schreef op dinsdag 30 juli 2024 @ 09:56:
[...]
Als ik in de rev-proxy-settings de DNS naam vervang door het IP adres werkt het wel.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Mogelijk ligt daar het probleem? Default bridge gedrag vs verwacht gedrag? Dit is waarom ik (vrijwel) alles aan een user_bridge hang, pihole uitgezonderd - die heeft een eigen hostnetwerk adres via macvlan en is met een eigen hostnaam opgenomen in de pihole local DNS.
Alle apparatuur verwijst naar de DNS in een Fritzbox die doorverwijst naar pihole die vervolgens doorverwijst naar Cloudflare DNS.
Dat is een bridge netwerk - hoe zie je dat met vlans?Hathi schreef op dinsdag 30 juli 2024 @ 10:45:
[...]
Dat is het probleem. De pihole is nu dus eigenlijk een service die draait op de host. Je wil dus vanaf een bridge container verbinding maken met een service op de host. Dat gaat niet zomaar.
Je zou kunnen overwegen om een extra bridge netwerk te maken waar je zowel de pihole als de container die je daar verbinding mee wil laten maken in stopt.
Of hier een kijkje nemen: https://docs.docker.com/d...use-cases-and-workarounds
Waarom zou het niet gewoon via het IP adres van de DNS server kunnen lopen?
Het is immers allemaal op dezelfde host?
[ Voor 8% gewijzigd door Airw0lf op 30-07-2024 11:21 ]
makes it run like clockwork
Misschien niet goed gelezen, maar kun je niet de dns meegeven in het run script?Airw0lf schreef op dinsdag 30 juli 2024 @ 11:18:
[...]
Dat is een bridge netwerk - hoe zie je dat met vlans?
Waarom zou het niet gewoon via het IP adres van de DNS server kunnen lopen?
Het is immers allemaal op dezelfde host?
1
| --dns="192.168.x.x" |
Waarbij dit dan het ip-adres van de host is.
De pi-hole wordt dan gezien als een service op de host.
[ Voor 6% gewijzigd door ahbart op 30-07-2024 12:14 ]
Zojuist geprobeerd - geen verbetering.ahbart schreef op dinsdag 30 juli 2024 @ 12:13:
[...]
Misschien niet goed gelezen, maar kun je niet de dns meegeven in het run script?
code:
1 --dns="192.168.x.x"
Waarbij dit dan het ip-adres van de host is.
De pi-hole wordt dan gezien als een service op de host.
makes it run like clockwork
Op dit punt is de pihole container actief en resolved voor een stuk of 30 andere apparaten.Mars Warrior schreef op dinsdag 30 juli 2024 @ 11:00:
[...]
Ben ff kwijt waar dit nu staat, maar dit klinkt als een kip-ei probleem: als de DNS niet geresolved kan worden, dan klinkt dit erg logisch om een IP adres in te voeren, immers wie zou de DNS moeten zijn?
Als ik de pihole container (her)start krijg ik inderdaad (terecht!) een melding van iets wat niet geresolved kan worden.
makes it run like clockwork
En als je het docker adres 172.x.0.1 van je host gebruikt?
Dan lijkt er echt iets mis te zijn met je brdige netwerk. Kun je überhaupt wel naar buiten verbinden met het bridge netwerk? DNS wissel zou dit op moeten leveren:
$ docker run --rm -it --network bridge alpine cat /etc/resolv.conf # Generated by dhcpcd from br0.dhcp domain lan nameserver 192.168.1.1 $ docker run --rm -it --network bridge --dns 192.168.1.4 alpine cat /etc/resolv.conf nameserver 192.168.1.4
Opgelost!Airw0lf schreef op maandag 29 juli 2024 @ 23:21:
Als ik een container start met bridge network is er binnen de container geen DNS resolving.
Als ik diezelfde container met host network start werkt het wel.
Ik heb de DNS server al toegevoegd aan daemon.json.
En ook als parameter opgenomen bij het opstarten van de container.
Maar geen van twee hielp.
Iemand nog suggesties?
Er bleken uiteindelijk twee verschillende oorzaken te zijn.
Die op zichzelf niks met de werking van Docker en DNS te maken hadden.
Bij de reverse proxy container (d.w.z. SWAG) zat de oorzaak in resolver.conf.
Daar stond als DNS-server 127.0.0.1 - wat prima werkt in host mode.
Maar niet in bridge mode.
Ik werd die kant op gestuurd door in host en bridge mode dit CLI commando te gebruiken:
docker exec --privileged swag nslookup cisco.com
De tweede fout zat hem in de software binnen de container.
Normaliter neemt een container de inhoud van /etc/resolv.conf van de host over.
Dat lijkt deze niet te doen - maar was ook niet te controleren met het commando:
docker exec --privileged omada-controller cat /etc/resolv.conf
Hier heb ik bij het starten de optie dns en dns-search meegegeven.
Waarna die container werkt zoals verwacht.

Vervolgens heb ik deze twee parameters opgenomen in /etc/docker/daemon.json.
En dat in het kader "baat-het-niet-dan-schaad-het-niet".
Iedereen unne dikke merci voor het meedenken!
makes it run like clockwork
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| ARG CADDY_VERSION=2.8 FROM caddy:${CADDY_VERSION}-builder-alpine AS builder RUN xcaddy build \ --with github.com/caddy-dns/cloudflare \ --with github.com/lucaslorentz/caddy-docker-proxy/v2 FROM caddy:${CADDY_VERSION}-alpine COPY --from=builder /usr/bin/caddy /usr/bin/caddy COPY Caddyfile /etc/caddy/Caddyfile ENTRYPOINT ["/usr/bin/caddy"] CMD ["docker-proxy"] |
Meteen een base Caddyfile toegevoegd:
1
2
3
4
5
| {$DOMAIN:localhost} { tls { dns cloudflare {env.CF_API_TOKEN} } } |
En toen een deployment gemaakt met Compose en een voorbeeld met AdGuard Home:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| --- services: caddy: container_name: caddy image: git.example.com/alex/caddy:${CADDY_VERSION:-latest} restart: on-failure networks: br0: ipv4_address: 192.168.1.44 environment: CF_API_TOKEN: redacted-api-token DOMAIN: "*.example.com" CADDY_INGRESS_NETWORKS: ${INGRESS_NETWORK} volumes: - ${APPDATA}/caddy/config:/config - ${APPDATA}/caddy/data:/data - /var/run/docker.sock:/var/run/docker.sock:ro cap_add: - NET_ADMIN cpus: 1 labels: 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' 'net.unraid.docker.icon': 'https://avatars.githubusercontent.com/u/12955528?s=200&v=4' 'net.unraid.docker.managed': 'dockge' 'net.unraid.docker.shell': '/bin/sh' 'net.unraid.docker.webui': 'http://[IP]:[PORT:80]/' networks: br0: name: br0 external: true |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| services: adguardhome: container_name: ${COMPOSE_PROJECT_NAME} image: adguard/adguardhome:${ADGUARD_HOME_VERSION:-latest} restart: on-failure networks: private: br0: ipv4_address: 192.168.1.4 volumes: - ${APPDATA}/adguard/workingdir:/opt/adguardhome/work - ${APPDATA}/adguard/config:/opt/adguardhome/conf - ${APPDATA}/letsencrypt:/opt/letsencrypt:ro cpuset: '12-13' cpus: 1 labels: 'caddy': "*.example.com" 'caddy.@adguard': 'host dns.example.com' 'caddy.handle': '@adguard' 'caddy.handle.reverse_proxy': '{{ upstreams 3000 }}' 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' 'net.unraid.docker.icon': 'https://raw.githubusercontent.com/SiwatINC/unraid-ca-repository/master/icons/adguard.png' 'net.unraid.docker.managed': 'dockge' 'net.unraid.docker.shell': '/bin/sh' 'net.unraid.docker.webui': 'http://[IP]:[PORT:3000]/' networks: br0: name: br0 external: true |
Container wordt wel netjes gezien, maar ik krijg een foutmelding en het werkt niet
{"level":"info","ts":1722428349.0054665,"logger":"docker-proxy","msg":"Process Caddyfile","logs":"[ERROR] Removing invalid block: ambiguous site definition: *.example.com\n*.example.com {\n\t@adguard host dns.example.com\n\thandle @adguard {\n\t\treverse_proxy 192.168.1.4:3000\n\t}\n}\n\n"}
Ik wil wel echt enorm graag een wildcard domain gebruiken. Eigenlijk met meerdere domeinnamen, maar daar lijkt dit niet helemaal voor bedoeld te zijn. Jij gebruikt geen wildcards toch?
Je had die tijd beter kunnen steken in Traefik?alex3305 schreef op woensdag 31 juli 2024 @ 14:51:
@Mars Warrior Nav jouw post eerder deze week toch nog even gekeken naar Caddy icm Docker Proxy. Dus zelf een image gebouwd met Gitea Actions die ik sinds afgelopen week ook werkend heb:
Docker:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 ARG CADDY_VERSION=2.8 FROM caddy:${CADDY_VERSION}-builder-alpine AS builder RUN xcaddy build \ --with github.com/caddy-dns/cloudflare \ --with github.com/lucaslorentz/caddy-docker-proxy/v2 FROM caddy:${CADDY_VERSION}-alpine COPY --from=builder /usr/bin/caddy /usr/bin/caddy COPY Caddyfile /etc/caddy/Caddyfile ENTRYPOINT ["/usr/bin/caddy"] CMD ["docker-proxy"]
Meteen een base Caddyfile toegevoegd:
code:
1 2 3 4 5 {$DOMAIN:localhost} { tls { dns cloudflare {env.CF_API_TOKEN} } }
En toen een deployment gemaakt met Compose en een voorbeeld met AdGuard Home:
YAML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 --- services: caddy: container_name: caddy image: git.example.com/alex/caddy:${CADDY_VERSION:-latest} restart: on-failure networks: br0: ipv4_address: 192.168.1.44 environment: CF_API_TOKEN: redacted-api-token DOMAIN: "*.example.com" CADDY_INGRESS_NETWORKS: ${INGRESS_NETWORK} volumes: - ${APPDATA}/caddy/config:/config - ${APPDATA}/caddy/data:/data - /var/run/docker.sock:/var/run/docker.sock:ro cap_add: - NET_ADMIN cpus: 1 labels: 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' 'net.unraid.docker.icon': 'https://avatars.githubusercontent.com/u/12955528?s=200&v=4' 'net.unraid.docker.managed': 'dockge' 'net.unraid.docker.shell': '/bin/sh' 'net.unraid.docker.webui': 'http://[IP]:[PORT:80]/' networks: br0: name: br0 external: true
YAML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 services: adguardhome: container_name: ${COMPOSE_PROJECT_NAME} image: adguard/adguardhome:${ADGUARD_HOME_VERSION:-latest} restart: on-failure networks: private: br0: ipv4_address: 192.168.1.4 volumes: - ${APPDATA}/adguard/workingdir:/opt/adguardhome/work - ${APPDATA}/adguard/config:/opt/adguardhome/conf - ${APPDATA}/letsencrypt:/opt/letsencrypt:ro cpuset: '12-13' cpus: 1 labels: 'caddy': "*.example.com" 'caddy.@adguard': 'host dns.example.com' 'caddy.handle': '@adguard' 'caddy.handle.reverse_proxy': '{{ upstreams 3000 }}' 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' 'net.unraid.docker.icon': 'https://raw.githubusercontent.com/SiwatINC/unraid-ca-repository/master/icons/adguard.png' 'net.unraid.docker.managed': 'dockge' 'net.unraid.docker.shell': '/bin/sh' 'net.unraid.docker.webui': 'http://[IP]:[PORT:3000]/' networks: br0: name: br0 external: true
Container wordt wel netjes gezien, maar ik krijg een foutmelding en het werkt niet:
{"level":"info","ts":1722428349.0054665,"logger":"docker-proxy","msg":"Process Caddyfile","logs":"[ERROR] Removing invalid block: ambiguous site definition: *.example.com\n*.example.com {\n\t@adguard host dns.example.com\n\thandle @adguard {\n\t\treverse_proxy 192.168.1.4:3000\n\t}\n}\n\n"}
Ik wil wel echt enorm graag een wildcard domain gebruiken. Eigenlijk met meerdere domeinnamen, maar daar lijkt dit niet helemaal voor bedoeld te zijn. Jij gebruikt geen wildcards toch?
Het lijkt erop dat je de juiste stappen hebt genomen, dus proxy toevoegen en dns toevoegen.alex3305 schreef op woensdag 31 juli 2024 @ 14:51:
@Mars Warrior Nav jouw post eerder deze week toch nog even gekeken naar Caddy icm Docker Proxy. Dus zelf een image gebouwd met Gitea Actions die ik sinds afgelopen week ook werkend heb:
Docker:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 ARG CADDY_VERSION=2.8 FROM caddy:${CADDY_VERSION}-builder-alpine AS builder RUN xcaddy build \ --with github.com/caddy-dns/cloudflare \ --with github.com/lucaslorentz/caddy-docker-proxy/v2 FROM caddy:${CADDY_VERSION}-alpine COPY --from=builder /usr/bin/caddy /usr/bin/caddy COPY Caddyfile /etc/caddy/Caddyfile ENTRYPOINT ["/usr/bin/caddy"] CMD ["docker-proxy"]
Meteen een base Caddyfile toegevoegd:
code:
1 2 3 4 5 {$DOMAIN:localhost} { tls { dns cloudflare {env.CF_API_TOKEN} } }
En toen een deployment gemaakt met Compose en een voorbeeld met AdGuard Home:
YAML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 --- services: caddy: container_name: caddy image: git.example.com/alex/caddy:${CADDY_VERSION:-latest} restart: on-failure networks: br0: ipv4_address: 192.168.1.44 environment: CF_API_TOKEN: redacted-api-token DOMAIN: "*.example.com" CADDY_INGRESS_NETWORKS: ${INGRESS_NETWORK} volumes: - ${APPDATA}/caddy/config:/config - ${APPDATA}/caddy/data:/data - /var/run/docker.sock:/var/run/docker.sock:ro cap_add: - NET_ADMIN cpus: 1 labels: 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' 'net.unraid.docker.icon': 'https://avatars.githubusercontent.com/u/12955528?s=200&v=4' 'net.unraid.docker.managed': 'dockge' 'net.unraid.docker.shell': '/bin/sh' 'net.unraid.docker.webui': 'http://[IP]:[PORT:80]/' networks: br0: name: br0 external: true
YAML:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 services: adguardhome: container_name: ${COMPOSE_PROJECT_NAME} image: adguard/adguardhome:${ADGUARD_HOME_VERSION:-latest} restart: on-failure networks: private: br0: ipv4_address: 192.168.1.4 volumes: - ${APPDATA}/adguard/workingdir:/opt/adguardhome/work - ${APPDATA}/adguard/config:/opt/adguardhome/conf - ${APPDATA}/letsencrypt:/opt/letsencrypt:ro cpuset: '12-13' cpus: 1 labels: 'caddy': "*.example.com" 'caddy.@adguard': 'host dns.example.com' 'caddy.handle': '@adguard' 'caddy.handle.reverse_proxy': '{{ upstreams 3000 }}' 'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}' 'net.unraid.docker.icon': 'https://raw.githubusercontent.com/SiwatINC/unraid-ca-repository/master/icons/adguard.png' 'net.unraid.docker.managed': 'dockge' 'net.unraid.docker.shell': '/bin/sh' 'net.unraid.docker.webui': 'http://[IP]:[PORT:3000]/' networks: br0: name: br0 external: true
Container wordt wel netjes gezien, maar ik krijg een foutmelding en het werkt niet:
{"level":"info","ts":1722428349.0054665,"logger":"docker-proxy","msg":"Process Caddyfile","logs":"[ERROR] Removing invalid block: ambiguous site definition: *.example.com\n*.example.com {\n\t@adguard host dns.example.com\n\thandle @adguard {\n\t\treverse_proxy 192.168.1.4:3000\n\t}\n}\n\n"}
Ik wil wel echt enorm graag een wildcard domain gebruiken. Eigenlijk met meerdere domeinnamen, maar daar lijkt dit niet helemaal voor bedoeld te zijn. Jij gebruikt geen wildcards toch?
Wat ik ff niet zeker weet: de docker-proxy genereert een caddy file. Dus ik vraag me af of jou default instellingen overschreven worden.
Je kunt de gemaakte caddyfile zien als je bijv. portainer gebruikt, in de logging dus.
Ik gebruik al even geen cloudflare meer, dus ook geen wildcard certificaten.
Noot, jij gebruikt een andere CMD zie ik nu:
1
2
3
4
5
6
7
8
9
10
11
12
| ARG CADDY_VERSION=2.6.1 FROM caddy:${CADDY_VERSION}-builder AS builder RUN xcaddy build \ --with github.com/lucaslorentz/caddy-docker-proxy/v2 \ --with <additional-plugins> FROM caddy:${CADDY_VERSION}-alpine COPY --from=builder /usr/bin/caddy /usr/bin/caddy CMD ["caddy", "docker-proxy"] |
[ Voor 4% gewijzigd door Mars Warrior op 31-07-2024 15:34 ]
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Als je tijd over hebt, dan is Traefik ook wel leuk jaRobertMe schreef op woensdag 31 juli 2024 @ 15:16:
[...]
Je had die tijd beter kunnen steken in Traefik?Die heeft out of the box support voor Docker (als in, proxyen naar Docker services op geplaatste labels). Wildcard domains zullen daarin lijlt mij prima werken. Wildcard certificaten aanvragen bij Lets Encrypt op basis van de DNS challenge werkt in ieder geval dikke prima. En als een Host rule niet werkt met wildcards is er ook nog een variant die matcht op basis van een regular expression, daarmee kun je het dus sowieso voor elkaar krijgen.
Het is dat @alex3305 een extra plugin nodig heeft (config staat letterlijk op de github pagina), maar ik kon de standaard docker container gebruiken. En als je dan enkel 2 regels met labels hoeft toe te voegen - en dus geen basis config files - van een ander voorbeeld op de Github pagina en het werkt, dan draait alles dus binnen een paar minuten.
Aangezien ik maar af en toe wat wijzig, is het voor mij erg prettig dat ik dankzij de eenvoud nauwelijks iets hoef te onthouden. Bij Traefik is me dat nog nooit gelukt. Ik heb nog nachtmerries van de overgang van V1 naar V2 destijds op een aantal clusters op het werk

Een deel van de problemen kwamen door typefouten die gewoon door Traefik werden genegeerd, dus je zoekt je helemaal suf waarom het niet werkt. Of dat de ene service wel werkt, en de andere niet...
Met die hele lange labelnamen zit je zo aan een typefout
En certificaten die niet automatisch verversen omdat je ergens weer een parameter bent vergeten die nodig is als je CNAMES gebruikt. File providers om externe services te kunnen benaderen ipv simpele labels. Ach, de lijst van leermomenten is lang
Ik heb dus ervaring met beiden, en voor simpel docker compose werk is de caddy docker proxy gewoon zoveel sneller en eenvoudiger te configureren, zelfs als je de documentatie niet doorneemt, maar enkel de voorbeelden bekijkt.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Dat wil ik dus per domein kunnen aangeven.
1
2
3
4
5
6
| local-only-service: image: my-very-secret-image:latest labels: caddy: local-only.example.com caddy.@local.remote_ip: 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 caddy.reverse_proxy: "@local {{upstreams 80}}" |
Eén van de redenen om geen http te gebruiken voor lokale services is dat Safari bij http je wachtwoordmanager blokkeert, want vreselijk onveilig natuurlijk
Dus dan maar bovenstaande methode.
Maar omdat ik geen Cloudflare meer heb, heb ik dus ook niet gekeken of wildcard certificaten ook op deze manier enkel lokaal kunnen werken.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Heb ik al gehadRobertMe schreef op woensdag 31 juli 2024 @ 15:16:
[...]
Je had die tijd beter kunnen steken in Traefik?

Mijn meest recente wissel was wel alweer een tijdje terug, maar van Traefik v2 naar NPM omdat het echte IP vanuit Cloudflare niet goed doorgestuurd werd. Daar zijn ook wel plugins voor, maar die heb ik destijds ook niet fatsoenlijk werkend gekregen.
Misschien ga ik hier nog wel een keer naar kijken. Ook prima
Yes. Volgens de GitHub issues en documentatie zou het zo ook moeten werken. Maar dat doet het niet. Waarschijnlijk is het iets enorm simpels wat ik over het hoofd zie.Mars Warrior schreef op woensdag 31 juli 2024 @ 15:28:
[...]
Het lijkt erop dat je de juiste stappen hebt genomen, dus proxy toevoegen en dns toevoegen.
Dat zie ik gebeuren in de gegenereerde JSON. Ik had uiteraard ook zonder 'base' Caddyfile geprobeerd, maar ook dat werkte niet.Wat ik ff niet zeker weet: de docker-proxy genereert een caddy file. Dus ik vraag me af of jou default instellingen overschreven worden.'
Yes. Maar daar word dus mijn entry vanuit Docker labels weggehaald omdat deze dubbel zou zijn.Je kunt de gemaakte caddyfile zien als je bijv. portainer gebruikt, in de logging dus.
ENTRYPOINT word uitgevoegd en daarna het CMD, dat is het probleem niet. Anders zou Caddy helemaal niet gestart moeten worden. Maar goed opgemerktNoot, jij gebruikt een andere CMD zie ik nu:
code:
1 CMD ["caddy", "docker-proxy"]
Een extra repo aanmaken met een Dockerfile en Gitea Action configureren is nou ook de moeite niet. Dat heb ik namelijk afgelopen weekend getemplatet:Mars Warrior schreef op woensdag 31 juli 2024 @ 16:11:
[...]
Het is dat @alex3305 een extra plugin nodig heeft (config staat letterlijk op de github pagina), maar ik kon de standaard docker container gebruiken. En als je dan enkel 2 regels met labels hoeft toe te voegen - en dus geen basis config files - van een ander voorbeeld op de Github pagina en het werkt, dan draait alles dus binnen een paar minuten.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| name: Docker Build and Push run-name: ${{ gitea.actor }} is running Docker build and push on: push: jobs: build: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Login to local Gitea registry uses: docker/login-action@v3 with: registry: ${{ env.registry }} username: ${{ env.actions_user }} password: ${{ secrets.PACKAGES_TOKEN }} - name: Docker Build and push uses: docker/build-push-action@v6 with: context: . push: true tags: ${{ env.registry }}/${{ gitea.repository }}:latest |
Hierdoor kan ik ook mijn eigen OCI registry in Gitea gebruiken
Traefik is prima, totdat iets niet werkt. Waar ik knettertje gek van werd waren de backticks voor matchers. Dat is zo'n subtiel verschil dat het niet opvalt totdat het misgaat. Wat ik al zei, ik heb Cloudflare Real IP's nooit helemaal werkend gekregen. Dat werd voor me gedaan in NPM. NPM is ook een stukje brakke ellende, maar daar hoef ik in ieder geval niet na te denken over dat soort, voor mijn gevoel, simpele details.[...] Traefik rant [...]
Daarom dacht ik ook terug naar Caddy 'te gaan'. Weinig configuratie. Docker containertje bouwen, deployen, labels toevoegen en
Op de reverse proxy (momenteel dus NPM) controleer ik dan, afhankelijk van de service, twee dingen:
- ACL via IP
- SSO Authenticatie
Het enige waar ik met deze setup nog tegenaan loop zijn niet HTTP diensten. Bijvoorbeeld de SSH server van Gitea. Die gaat dan via een interne hostname, toegewezen via een statische DHCP lease. Dit zou met HAProxy wel kunnen, maar dat is een ander onderwerp. Voor nu wil ik binnenkort van de extra administratie interface af die NPM heet, vandaar dat ik naar Caddy aan het kijken was.
Dat was gewoon ervaring en leermomentjes hooralex3305 schreef op woensdag 31 juli 2024 @ 16:28:
[...] Traefik rant [...]

En als je echt wilt studeren dan pak je de volgende keer gewoon Istio. Daarbij vergeleken is Traefik een eitje.
Ik zie dat jij heel veel quotjes gebruikt in je label deel. Geen idee of dat gekke dingen doet.
Vanuit het verleden weet ik dat het volgende werkt met wildcard certificaten.
Die 1ste twee labels mogen als ik het goed heb maar 1 keer voorkomen in je compose file. Ik gooide dat soort algemene dingen altijd bij de caddy container zelf, net als het emailadres (caddy.email: $EMAIL)
1
2
3
4
5
6
| labels: caddy: "*.mijndomein.org" caddy.tls.dns: "duckdns myToken" caddy.@home: "host home.mijndomein.org" caddy.handle: "@home" caddy.handle.reverse_proxy: "{{upstreams 3000}}" |
En anders zou ik eerst ff proberen met 1 simpel subdomein.
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
I know. Idem voor Ceph. Dan smeek je om een simpel product zoals TraefikMars Warrior schreef op woensdag 31 juli 2024 @ 17:01:
[...]
En als je echt wilt studeren dan pak je de volgende keer gewoon Istio. Daarbij vergeleken is Traefik een eitje.
Nee. Dockge sloopt er dat bij het deployen ook allemaal uit.Ik zie dat jij heel veel quotjes gebruikt in je label deel. Geen idee of dat gekke dingen doet.
Maar ik heb het werkendVanuit het verleden weet ik dat het volgende werkt met wildcard certificaten.
[...]
En anders zou ik eerst ff proberen met 1 simpel subdomein.
Ik had een ingeving. Ik probeerde mijn domein én wildcard subdomain onder 1 blok te hebben, maar dat was natuurlijk niet hetzelfde als het wildcard subdomain

1
2
3
4
5
| services: caddy: labels: 'caddy_0': 'example.com' 'caddy_0.tls.dns': 'cloudflare {env.CF_API_TOKEN}' |
en
1
2
3
4
5
6
7
| services: adguardhome: labels: 'caddy': '*.example.com' 'caddy.@adguard': 'host dns.example.com' 'caddy.handle': '@adguard' 'caddy.handle.reverse_proxy': '{{upstreams 3000}}' |
is natuurlijk niet hetzelfde

Daarnaast had ik ook: 'caddy_0.tls': 'dns cloudflare {env.CF_API_TOKEN}' staan, wat blijkbaar dus niet klopt. Dus toen ik die andere notatie net bij jou zag viel het kwartje
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
| services: caddy: image: git.example.com/alex/caddy:${CADDY_VERSION:-latest} networks: br0: ipv4_address: 192.168.1.2 environment: CADDY_INGRESS_NETWORKS: br0 CF_API_TOKEN: ${CLOUDFLARE_API_TOKEN} volumes: - ${APPDATA}/caddy/config:/config - ${APPDATA}/caddy/data:/data - /var/run/docker.sock:/var/run/docker.sock:ro cap_add: - NET_ADMIN labels: 'caddy_0': 'example.com' 'caddy_0.tls.dns': 'cloudflare {env.CF_API_TOKEN}' 'caddy_1': '*.example.com' 'caddy_1.tls.dns': 'cloudflare {env.CF_API_TOKEN}' adguardhome: image: adguard/adguardhome:${ADGUARD_HOME_VERSION:-latest} networks: br0: ipv4_address: 192.168.1.4 labels: 'caddy': '*.example.com' 'caddy.@adguard': 'host dns.example' 'caddy.handle': '@adguard' 'caddy.handle.reverse_proxy': '{{upstreams 3000}}' networks: br0: name: br0 external: true |
Testen kan vervolgens met cURL met TLS SNI resolver:
curl https://dns.example.com --resolve dns.example.com:443:192.168.1.2
Volgende stappen is het toevoegen van mijn Docker services. En daarna eens kijken hoe ik OAuth2 Proxy er dan eenvoudig voor kan krijgen
Bedankt voor het meedenken
Ach. Helemaal overheen gekeken. Het is dan ook ff geleden. Maar fijn dat mijn voorbeeld het kwartje heeft doen vallen. Uiteindelijk worden al die labels, net als bij Traefik op één hoop gegooid om uiteindelijk te leiden tot een kloppende routering.alex3305 schreef op woensdag 31 juli 2024 @ 19:57:
[...]
Maar ik heb het werkend.
Ik had een ingeving. Ik probeerde mijn domein én wildcard subdomain onder 1 blok te hebben, maar dat was natuurlijk niet hetzelfde als het wildcard subdomain. Dus:
t. Dus toen ik die andere notatie net bij jou zag viel het kwartje. Een compleet voorbeeld:
Je weet dat Caddy zelf ook plugins heeft voor OAuth (security)?Volgende stappen is het toevoegen van mijn Docker services. En daarna eens kijken hoe ik OAuth2 Proxy er dan eenvoudig voor kan krijgen.
Verwijzen naar een externe service kan simpel door het IP adres bij de reverse proxy te zetten. Dat voorbeeld had ik eerder al gegeven in een post.En natuurlijk ook de diensten koppelen die geen (lokale) container hebben. Als laatste kan ik dan de ip toewijzingen uit Docker Compose gaan halen.
Bedankt voor het meedenken.
Verder is er ook een Layer 4 plugin/App waarmee je rare dingen als TCP, XMPP, TLS, RDP, Postgres, HAPROXY, SOCKS en SSH kunt afhandelen. Is nog wel in ontwikkeling volgens de Github pagina...
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Ja. Ik ben daar nog niet zo kapot van. Ik vind de documentatie onduidelijk. En ik wil dit eigenlijk liever buiten mijn Caddy / reverse proxy uithouden. Ik heb namelijk een relatief onconventionele setup met oauth2-proxy en Dex.Mars Warrior schreef op donderdag 1 augustus 2024 @ 10:35:
[...]
Je weet dat Caddy zelf ook plugins heeft voor OAuth (security)?
Het toestaan van lokale IP's in combinatie met Cloudflare werkt wel aardig eenvoudig trouwens:
Dockerfile
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| ARG CADDY_VERSION=2.8 FROM caddy:${CADDY_VERSION}-builder-alpine AS builder RUN xcaddy build \ --with github.com/caddy-dns/cloudflare \ --with github.com/WeidiDeng/caddy-cloudflare-ip \ --with github.com/lucaslorentz/caddy-docker-proxy/v2 FROM caddy:${CADDY_VERSION}-alpine COPY --from=builder /usr/bin/caddy /usr/bin/caddy COPY Caddyfile /etc/caddy/Caddyfile ENTRYPOINT ["/usr/bin/caddy"] CMD ["docker-proxy", "--caddyfile-path", "/etc/caddy/Caddyfile"] |
Caddyfile
1
2
3
4
5
6
7
8
9
10
11
12
| { admin off email {env.EMAIL} servers { trusted_proxies cloudflare } } (allow-local-ips) { client_ip 192.168.0.0/16 } |
Docker Compose
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| services: whoami: container_name: whoami image: traefik/whoami networks: br0: labels: - caddy=*.example.com - caddy.@whoami.host=whoami.example.com - caddy.handle=@whoami - caddy.handle.reverse_proxy={{upstreams 80}} networks: br0: name: br0 external: true |
Dat kan ik dan in ieder geval ook al oppakken voordat ik overal oauth2-proxy voor wil hebben. Ik bedoel, dit is dan al de helft
Wel ben ik naar een ander LABEL format geswitched omdat variable interpolation niet ondersteund word met key-value's. Dan kan ik namelijk dit doen:
1
2
3
4
5
6
7
8
9
10
11
| services: adguardhome: image: adguard/adguardhome:${ADGUARD_HOME_VERSION:-latest} networks: br0: labels: - caddy=*.${CADDY_DOMAINNAME} - caddy.@${COMPOSE_PROJECT_NAME}.import=allow-local-ips - caddy.@${COMPOSE_PROJECT_NAME}.host=dns.${CADDY_DOMAINNAME} - caddy.handle=@${COMPOSE_PROJECT_NAME} - caddy.handle.reverse_proxy={{upstreams 3000}} |
1
| CADDY_DOMAINNAME=example.com |
En dat vind ik wel enorm lekker voor mijn Docker Compose template
ik weet dat ik het eerder heb gehad in m'n testsetup, maar hoe ik het toen heb opgelost weet ik niet meer. Op de een of andere manier werkt het ook in m'n test niet meer.
Beide omgevingen draaien op dezelfde proxmost host. De test in een ubuntu-container, de productie in een ubuntu VM.
De compose-file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
| services: mealie: image: ghcr.io/mealie-recipes/mealie:latest # container_name: mealie ports: - "9925:9000" # #network_mode: host deploy: resources: limits: memory: 1000M # volumes: - ${ROOTDIR}/mealie:/app/data/ environment: # Set Backend ENV Variables Here - ALLOW_SIGNUP=true - PUID=${PUID} - PGID=${PGID} - TZ=${TZ} - MAX_WORKERS=1 - WEB_CONCURRENCY=1 #BASE_URL: https://mealie.yourdomain.com restart: unless-stopped freshrss: image: freshrss/freshrss:latest container_name: freshrss ports: - "8777:80" volumes: - ${ROOTDIR}/freshrss/data:/var/www/FreshRSS/data/ - ${ROOTDIR}/freshrss/extensions:/var/www/FreshRSS/extensions environment: PUID: ${PUID} PGID: ${PGID} TZ: ${TZ} CRON_MIN: '1,15' restart: unless-stopped |
Het vreemde is dat de FreshRSS-container wél naar buiten kan. Net als alle andere containers die op dezelfde host draaien. In /etc/resolv.conf staat de juiste nameserver, Zowel op de proxmox host als op de docker vm.
Misschien zit het probleem niet in het Dockerstuk maar dat is voor nu even mijn eerste zoekveld. Maarja...wáár moet ik zoeken? Ik voel me soms een echte newbie...
Ik ken Maelie verder niet, maar zelf komen ze met een basis container definitie aanzetten. Die heb ik nog ff verder gestript.WheeleE schreef op donderdag 1 augustus 2024 @ 13:26:
Heb ik weer. Na van scratch m'n dockerhost te hebben ingericht krijg ik geen connectie naar buiten vanuit m'n Mealie-container.
ik weet dat ik het eerder heb gehad in m'n testsetup, maar hoe ik het toen heb opgelost weet ik niet meer. Op de een of andere manier werkt het ook in m'n test niet meer.
Beide omgevingen draaien op dezelfde proxmost host. De test in een ubuntu-container, de productie in een ubuntu VM.
De compose-file:
code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 services: mealie: image: ghcr.io/mealie-recipes/mealie:latest # container_name: mealie ports: - "9925:9000" # #network_mode: host deploy: resources: limits: memory: 1000M # volumes: - ${ROOTDIR}/mealie:/app/data/ environment: # Set Backend ENV Variables Here - ALLOW_SIGNUP=true - PUID=${PUID} - PGID=${PGID} - TZ=${TZ} - MAX_WORKERS=1 - WEB_CONCURRENCY=1 #BASE_URL: https://mealie.yourdomain.com restart: unless-stopped freshrss: image: freshrss/freshrss:latest container_name: freshrss ports: - "8777:80" volumes: - ${ROOTDIR}/freshrss/data:/var/www/FreshRSS/data/ - ${ROOTDIR}/freshrss/extensions:/var/www/FreshRSS/extensions environment: PUID: ${PUID} PGID: ${PGID} TZ: ${TZ} CRON_MIN: '1,15' restart: unless-stopped
Het vreemde is dat de FreshRSS-container wél naar buiten kan. Net als alle andere containers die op dezelfde host draaien. In /etc/resolv.conf staat de juiste nameserver, Zowel op de proxmox host als op de docker vm.
Misschien zit het probleem niet in het Dockerstuk maar dat is voor nu even mijn eerste zoekveld. Maarja...wáár moet ik zoeken? Ik voel me soms een echte newbie...
Kijk eens of die werkt?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| version: "3.4" services: mealie: container_name: mealie image: ghcr.io/mealie-recipes/mealie:latest restart: always volumes: - mealie-data:/app/data/ ports: - 9925:9000 environment: ALLOW_SIGNUP: "true" LOG_LEVEL: "DEBUG" DB_ENGINE: sqlite volumes: mealie-data: driver: local |
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Recepten zijn niet te importeren/scrapen vanuit de applicatie. Ik dacht dat dat aan de internetconnectiviteit lag.
Maar als het vanaf 2 compleet verschillende machines niet lukt, en met de Pihole adblocker uit dan ligt het niet aan Mealie zelf lijkt me.
Met wat aanvullende test kom ik nu tot de conclusie dat het hoogstwaarschijnlijk aan de recepten-source ligt: ah.nl. Van een andere website kan ik namelijk wel scrapen.
Ik heb dit probleem ook (gehad). Maar in mijn herinnering gaf hij daar een redelijk duidelijke foutmelding over. Maar misschien was dat voor mij duidelijk omdat ik al wel meer met mealie gewerkt had. Maar mooi dat je er achter gekomen bent in ieder geval.WheeleE schreef op donderdag 1 augustus 2024 @ 15:09:
Met wat aanvullende test kom ik nu tot de conclusie dat het hoogstwaarschijnlijk aan de recepten-source ligt: ah.nl. Van een andere website kan ik namelijk wel scrapen.
De melding was iets in de trand van 'geen/onbekende opmaak gevonden'. Dat had ik de eerste keer in test ook. Toen werkte het voor geen enkele receptenwebsite en bleek het een dns achtig issue te zijn. Logisch, want als je de website niet kan vinden krijg je ook geen goede opmaak binnen.krijn1985 schreef op donderdag 1 augustus 2024 @ 20:12:
[...]
Ik heb dit probleem ook (gehad). Maar in mijn herinnering gaf hij daar een redelijk duidelijke foutmelding over. Maar misschien was dat voor mij duidelijk omdat ik al wel meer met mealie gewerkt had. Maar mooi dat je er achter gekomen bent in ieder geval.
Nu krijg ik dezelfde melding maar werkt AH.nl niet, en een andere receptenwebsite wel. Een andere oorzaak dus. Ik laat het voor nu ff, misschien is het een tijdelijk bugje in de ah.nl-scraper ofzo.
[ Voor 5% gewijzigd door WheeleE op 01-08-2024 20:33 ]
Ik had verwacht dat als hij geen website kon bereiken een andere foutmelding zou geven. Maar dan snap ik je gedachtegang.WheeleE schreef op donderdag 1 augustus 2024 @ 20:32:
[...]
De melding was iets in de trand van 'geen/onbekende opmaak gevonden'. Dat had ik de eerste keer in test ook. Toen werkte het voor geen enkele receptenwebsite en bleek het een dns achtig issue te zijn. Logisch, want als je de website niet kan vinden krijg je ook geen goede opmaak binnen.
Nu krijg ik dezelfde melding maar werkt AH.nl niet, en een andere receptenwebsite wel. Een andere oorzaak dus. Ik laat het voor nu ff, misschien is het een tijdelijk bugje in de ah.nl-scraper ofzo.
Ik dacht dat het probleem ook was opgelost, zie https://github.com/hhursev/recipe-scrapers/issues/990, ik kon laatst wel weer ah recept toevoegen.
Zou jij nog eens kunnen proberen om een nieuw AH.nl recept toe te voegen? Ik blijf een 403 Forbidden error krijgen. Alleen bij ah.nl, de jumbo.nl-recepten gaan wel goed.krijn1985 schreef op donderdag 1 augustus 2024 @ 20:42:
[...]
Ik had verwacht dat als hij geen website kon bereiken een andere foutmelding zou geven. Maar dan snap ik je gedachtegang.
Ik dacht dat het probleem ook was opgelost, zie https://github.com/hhursev/recipe-scrapers/issues/990, ik kon laatst wel weer ah recept toevoegen.
Misschien is de scraper weer stuk, of heeft Albert Heijn iets aangepast in hun code.
Ik krijg deze error:WheeleE schreef op zaterdag 3 augustus 2024 @ 17:21:
[...]
Zou jij nog eens kunnen proberen om een nieuw AH.nl recept toe te voegen? Ik blijf een 403 Forbidden error krijgen. Alleen bij ah.nl, de jumbo.nl-recepten gaan wel goed.
Misschien is de scraper weer stuk, of heeft Albert Heijn iets aangepast in hun code.
Met dit recept als test: https://www.ah.nl/allerha...otto-met-pesto-en-veldslaLooks Like We Couldn't Find Anything
Only websites containing ld+json or microdata can be imported by Mealie. Most major recipe websites support this data structure. If your site cannot be imported but there is json data in the log, please submit a github issue with the URL and data.
Draai op dit moment v1.9.0. Dus loop nog iets achter. Zit nu niet achter PC om even in de source van AH te kijken.
Dank! Dan weet ik in ieder geval dat het niet specifiek aan mijn configuratie ligt. AH.nl zal iets hebben aangepast in hun website config.krijn1985 schreef op zondag 4 augustus 2024 @ 12:52:
[...]
Ik krijg deze error:
[...]
Met dit recept als test: https://www.ah.nl/allerha...otto-met-pesto-en-veldsla
Draai op dit moment v1.9.0. Dus loop nog iets achter. Zit nu niet achter PC om even in de source van AH te kijken.
Dat is zeer waarschijnlijk ja. Dat hebben ze al eerder gedaan.WheeleE schreef op zondag 4 augustus 2024 @ 13:12:
[...]
Dank! Dan weet ik in ieder geval dat het niet specifiek aan mijn configuratie ligt. AH.nl zal iets hebben aangepast in hun website config.
De benodigde ld+json data (recept, stappen om recept te maken) zit namelijk gewoon in de website, dus ze volgen netjes de standaard:
1
2
3
4
5
6
7
8
9
10
11
12
13
| {"@context":"https://schema.org","@type":"Recipe","isPartOf":{"@id":"https://www.ah.nl/allerhande#website"},"author":{"@type":"Organization","@id":"https://www.ah.nl/allerhande#organization","name":"Albert Heijn"},"name":"Risotto pesto en veldsla","alternateName":"","URL":"https://www.ah.nl/allerhande/recept/R-R1200297/risotto-met-pesto-en-veldsla","totalTime":"PT30M","image":["","https://static.ah.nl/static/recepten/img_RAM_PRD191809_1224x900_JPG.jpg"],"description":"Mooi groen is niet lelijk! Deze risotto met pesto combineren we met groene groenten zoals veldsla en broccoli. Binnen 30 min. op tafel. ","keywords":"zonder vlees/vis, budget, rijst, hoofdgerecht, camping, wat eten we vandaag, zomer, koken","recipeYield":"4","recipeCategory":"hoofdgerecht","recipeCuisine":"","suitableForDiet":[],"nutrition": {"@type":"NutritionInformation","calories":"555 kcal energie","fatContent":"24 g vet","saturatedFatContent":"5 g waarvan verzadigd","carbohydrateContent":"64 g koolhydraten","proteinContent":"17 g eiwit"},"recipeIngredient":["1 l water","1 groentebouillonblokje","2 middelgrote uien","1 teen knoflook","400 g broccoli","3 el milde olijfolie","300 g risottorijst","200 g zuivelspread light","80 g koelverse pestospread","85 g veldsla"], ""recipeInstructions":[{"@type":"HowToStep","position":1,"name":"stap 1","text":"Breng het water met het bouillonblokje aan de kook en zet het vuur laag. \n"}, {"@type":"HowToStep","position":2,"name":"stap 2","text":"Snipper de uien en snijd de knoflook fijn. Snijd de broccoli in roosjes van 2 cm, schil de stronk en snijd fijn. "}, {"@type":"HowToStep","position":3,"name":"stap 3","text":"Verhit de olie in een pan met dikke bodem en bak de ui, knoflook en stukjes broccolisteel 3 min. op middelhoog vuur. \n"}, {"@type":"HowToStep","position":4,"name":"stap 4","text":"Voeg de risottorijst toe en bak al roerend 3 min. mee tot de korrels glazig zijn."}, {"@type":"HowToStep","position":5,"name":"stap 5","text":" Voeg een scheut hete bouillon toe en blijf roeren tot deze is opgenomen. "}, {"@type":"HowToStep","position":6,"name":"stap 6","text":"Herhaal dit tot de rijst gaar is, dit duurt ca. 20 min. Het kan zijn dat je wat bouillon overhoudt. "}, {"@type":"HowToStep","position":7,"name":"stap 7","text":"De risotto is klaar als het een romig geheel is, het mag zelfs nog een beetje nat zijn. "}, {"@type":"HowToStep","position":8,"name":"stap 8","text":"Roer halverwege het toevoegen van de bouillon de broccoliroosjes door de risotto. \n"}, {"@type":"HowToStep","position":9,"name":"stap 9","text":"Voeg de zuivelspread, de pestospread en de veldsla toe (hou wat achter ter garnering), roer door en verwarm nog 1 min. mee. "}, {"@type":"HowToStep","position":10,"name":"stap 10","text":"Breng op smaak met peper en eventueel zout en roer door. "}, {"@type":"HowToStep","position":11,"name":"stap 11","text":"Verdeel de risotto over diepe borden en verdeel de rest van de veldsla en de rest van de pestospread erover."}],"aggregateRating":{"ratingValue":4.32,"ratingCount":25},"datePublished":"2024-07-05"} |
Of de blokkering voor het scrapen in de website zelf zit, of in een firewall/proxy ervoor kan ik zo niet even achterhalen...
Ik vermoed als ik zo wat op internet zoek dat AH gebruik maakt van TLS fingerprinting via Cloudflare: daarmee kun je geheel automagich botjes identificeren en op een zwarte lijst zetten.
Mealie zal, net als andere bots, een unieke fingerprint hebben danzij de gebruikte Python libraries + TLS Hello string. De enige omweg is dan of elke keer Mealie wijzigen, of een TLS/SSL proxy gebruiken die elke keer een andere fingerprint oplevert of zich voordoet als een normale browser
[ Voor 6% gewijzigd door Mars Warrior op 04-08-2024 14:36 ]
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
Nu zou ik op dat moment graag een bash-script willen starten om wat bestandjes op te ruimen die tijdens het starten zijn aangemaakt. Maar eenmaal lopende niet meer nodig zijn.
Volgens mij is voor zoiets dockerfile bedoeld. Maar ik begrijp de docs niet - het lijkt te gaan met run, exec en (of?) shell. Maar hoe dan precies...
Het bash script wat ik zou willen starten heet cleanup.sh en ligt klaar in een folder van het config-volume.
De container wordt gestart met docker cli:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| docker run -d \ --network bridge \ --name swag \ --hostname swag \ --cap-add NET_ADMIN \ -e TZ=Europe/Amsterdam \ -e URL=itv360.net \ -e VALIDATION=dns \ -e SUBDOMAINS=wildcard \ -e DNSPLUGIN=cloudflare \ -e PROPAGATION=60 \ -e EMAIL=support@itv360.net \ -e ONLY_SUBDOMAINS=false \ -e EXTRA_DOMAINS=it-visibility.net,*.it-visibility.net \ -e STAGING=false \ -p 192.168.139.235:443:443 \ -p 192.168.139.235:80:80 \ -p 192.168.139.235:99:99 \ -v /opt/docker/swag/config:/config \ --restart unless-stopped \ linuxserver/swag |
Wat is hier handig?
makes it run like clockwork
Dank voor de tips. Ik ga misschien een keer in die tlsproxy duiken maar voor nu laat ik het ff voor wat het is. Dan maar geen AH-recepten importeren, er zijn genoeg andere bruikbare bronnen gelukkigMars Warrior schreef op zondag 4 augustus 2024 @ 14:02:
[...]
Dat is zeer waarschijnlijk ja. Dat hebben ze al eerder gedaan.
De benodigde ld+json data (recept, stappen om recept te maken) zit namelijk gewoon in de website, dus ze volgen netjes de standaard:
XML:
1 2 3 4 5 6 7 8 9 10 11 12 13 {"@context":"https://schema.org","@type":"Recipe","isPartOf":{"@id":"https://www.ah.nl/allerhande#website"},"author":{"@type":"Organization","@id":"https://www.ah.nl/allerhande#organization","name":"Albert Heijn"},"name":"Risotto pesto en veldsla","alternateName":"","URL":"https://www.ah.nl/allerhande/recept/R-R1200297/risotto-met-pesto-en-veldsla","totalTime":"PT30M","image":["","https://static.ah.nl/static/recepten/img_RAM_PRD191809_1224x900_JPG.jpg"],"description":"Mooi groen is niet lelijk! Deze risotto met pesto combineren we met groene groenten zoals veldsla en broccoli. Binnen 30 min. op tafel. ","keywords":"zonder vlees/vis, budget, rijst, hoofdgerecht, camping, wat eten we vandaag, zomer, koken","recipeYield":"4","recipeCategory":"hoofdgerecht","recipeCuisine":"","suitableForDiet":[],"nutrition": {"@type":"NutritionInformation","calories":"555 kcal energie","fatContent":"24 g vet","saturatedFatContent":"5 g waarvan verzadigd","carbohydrateContent":"64 g koolhydraten","proteinContent":"17 g eiwit"},"recipeIngredient":["1 l water","1 groentebouillonblokje","2 middelgrote uien","1 teen knoflook","400 g broccoli","3 el milde olijfolie","300 g risottorijst","200 g zuivelspread light","80 g koelverse pestospread","85 g veldsla"], ""recipeInstructions":[{"@type":"HowToStep","position":1,"name":"stap 1","text":"Breng het water met het bouillonblokje aan de kook en zet het vuur laag. \n"}, {"@type":"HowToStep","position":2,"name":"stap 2","text":"Snipper de uien en snijd de knoflook fijn. Snijd de broccoli in roosjes van 2 cm, schil de stronk en snijd fijn. "}, {"@type":"HowToStep","position":3,"name":"stap 3","text":"Verhit de olie in een pan met dikke bodem en bak de ui, knoflook en stukjes broccolisteel 3 min. op middelhoog vuur. \n"}, {"@type":"HowToStep","position":4,"name":"stap 4","text":"Voeg de risottorijst toe en bak al roerend 3 min. mee tot de korrels glazig zijn."}, {"@type":"HowToStep","position":5,"name":"stap 5","text":" Voeg een scheut hete bouillon toe en blijf roeren tot deze is opgenomen. "}, {"@type":"HowToStep","position":6,"name":"stap 6","text":"Herhaal dit tot de rijst gaar is, dit duurt ca. 20 min. Het kan zijn dat je wat bouillon overhoudt. "}, {"@type":"HowToStep","position":7,"name":"stap 7","text":"De risotto is klaar als het een romig geheel is, het mag zelfs nog een beetje nat zijn. "}, {"@type":"HowToStep","position":8,"name":"stap 8","text":"Roer halverwege het toevoegen van de bouillon de broccoliroosjes door de risotto. \n"}, {"@type":"HowToStep","position":9,"name":"stap 9","text":"Voeg de zuivelspread, de pestospread en de veldsla toe (hou wat achter ter garnering), roer door en verwarm nog 1 min. mee. "}, {"@type":"HowToStep","position":10,"name":"stap 10","text":"Breng op smaak met peper en eventueel zout en roer door. "}, {"@type":"HowToStep","position":11,"name":"stap 11","text":"Verdeel de risotto over diepe borden en verdeel de rest van de veldsla en de rest van de pestospread erover."}],"aggregateRating":{"ratingValue":4.32,"ratingCount":25},"datePublished":"2024-07-05"}
Of de blokkering voor het scrapen in de website zelf zit, of in een firewall/proxy ervoor kan ik zo niet even achterhalen...
Ik vermoed als ik zo wat op internet zoek dat AH gebruik maakt van TLS fingerprinting via Cloudflare: daarmee kun je geheel automagich botjes identificeren en op een zwarte lijst zetten.
Mealie zal, net als andere bots, een unieke fingerprint hebben danzij de gebruikte Python libraries + TLS Hello string. De enige omweg is dan of elke keer Mealie wijzigen, of een TLS/SSL proxy gebruiken die elke keer een andere fingerprint oplevert of zich voordoet als een normale browser
Ik quote je nog een keer selectief. Kleine update met mijn Caddy + Docker avontuur. Het was even wat uitzoekwerk met mijn setup en SSO, maar het e.e.a. lijkt nu prima te werken. Ik gebruik Dex als federated IdP en wilde dus oauth2-proxy gebruiken. Echter zat daar een nare bug in dat het OAuth2 consentscherm elke keer getoond werd. Ook leek forward_auth niet bijzonder straight forward. Dus daarom maar gewisseld naar Caddy Security. Het voorbeeld vond ik toch wat spartaans, maar was wel de basis die ik nodig had. Vooral samen met dit blog die het e.e.a. nog wat verder beschrijft.Mars Warrior schreef op donderdag 1 augustus 2024 @ 10:35:
[...]
Je weet dat Caddy zelf ook plugins heeft voor OAuth (security)?
Mijn Docker Compose template ziet er nu zo uit:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
| --- services: service: container_name: ${COMPOSE_PROJECT_NAME} image: ${_VERSION:-latest} restart: on-failure networks: br0: volumes: - ${APPDATA}/app:/config cpus: 1 labels: - caddy=*.${CADDY_DOMAIN} - caddy.@${COMPOSE_PROJECT_NAME}.import=local-ip-whitelist - caddy.@${COMPOSE_PROJECT_NAME}.host=${CADDY_SUBDOMAIN}.${CADDY_DOMAIN} - caddy.handle=@${COMPOSE_PROJECT_NAME} - caddy.handle.authorize=with securitypolicy - caddy.handle.reverse_proxy={{upstreams ${INGRESS_PORT:-80}}} - com.centurylinklabs.watchtower.scope=${COMPOSE_PROJECT_NAME} - net.unraid.docker.icon=${UNRAID_ICON:-https://avatars.githubusercontent.com/u/42099010?s=200&v=4} - net.unraid.docker.managed=dockge - net.unraid.docker.shell=/bin/sh - net.unraid.docker.webui=http://[IP]:[PORT:${INGRESS_PORT:-80}]/ watchtower: container_name: ${COMPOSE_PROJECT_NAME}-watchtower image: containrrr/watchtower restart: on-failure environment: TZ: ${TZ:-Europe/Amsterdam} WATCHTOWER_CLEANUP: true WATCHTOWER_LOG_LEVEL: error WATCHTOWER_SCHEDULE: '0 0 1 * * *' WATCHTOWER_SCOPE: ${COMPOSE_PROJECT_NAME} network_mode: bridge volumes: - /var/run/docker.sock:/var/run/docker.sock cpus: 0.1 labels: - com.centurylinklabs.watchtower.scope=${COMPOSE_PROJECT_NAME} - net.unraid.docker.icon=https://raw.githubusercontent.com/containrrr/watchtower/main/logo.png - net.unraid.docker.managed=dockge networks: internal: name: ${COMPOSE_PROJECT_NAME} br0: name: br0 external: true |
en de environment:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| # Global options TZ=Europe/Amsterdam APPDATA=/opt/appdata PUID=99 PGID=100 # Versions _VERSION=latest # Reverse proxy configuration CADDY_DOMAIN=example.com CADDY_SUBDOMAIN= INGRESS_PORT=80 UNRAID_ICON= # Application configuration |
Hier zit dan een ip whitelist op én SSO. Afhankelijk van de dienst schakel ik het een of de ander uit.
Externe diensten was inderdaad eenvoudig, maar eigenlijk wil ik daar nog iets op verzinnen. Misschien stub containers of environment variables. Want dit vind ik gewoon lelijk:
1
2
3
4
5
| - caddy_1.@dockge.host=docker.{env.DOMAIN} - caddy_1.@dockge.import=local-ip-whitelist - caddy_1.handle_3=@dockge - caddy_1.handle_3.authorize=with securitypolicy - caddy_1.handle_3.reverse_proxy=http://docker:5001 |
En dat dan maal 12

Anyway, in overig nieuws heb ik om mijn tweede node te koppelen ook gekeken naar Docker Swarm. Ik weet dat het niet het meest populaire project momenteel is, maar zou wellicht voor mijn doeleinden wel voldoen. Nu gebruik ik namelijk een ipvlan netwerk voor diensten, maar het zou natuurlijk fantastisch zijn als ik diensten op de swarm zou kunnen gebruiken vanuit Caddy. Mijn beheertool, Dockge werkt helaas niet met Docker Swarm, maar omdat alles toch in Compos zit is het eventueel wisselen appeltje-eitje.
Maar Docker Swarm activeren op Unraid was veel eenvoudiger dan ik had verwacht. Ik las immers overal dat dit zowat onmogelijk zou moeten zijn, maar:
docker swarm init --advertise-addr 192.168.1.2
werkte gewoon prima. Wel moest ik het adres van de machine expliciet meegeven, maar dat is geen probleem. Een netwerk aanmaken was eveneens eenvoudig:
docker network create --scope=swarm --attachable --driver overlay internal
en op de andere node een dienst aanmaken die vervolgens op de primaire nodie gewoon bereikbaar was, was wederom simpel:
docker run --rm -it --name test --network internal alpine /bin/sh
Dit is nog in de experimentele fase en ik ga uiteraard eerst mijn Caddy migratie afronden. Maar dit gaf mij wel hoop om een makkelijke (2 node) cluster te maken en Caddy Docker Proxy hiervoor te gebruiken.
Bijvoorbeeld om deze te syncen?
makes it run like clockwork
Ja dat zou kunnen, maar ik denk alleen dan via het pad waarop de bind mount staat in de container. Alles wat daar naartoe geschreven word is zover ik weet beschikbaar op de hostOS.Airw0lf schreef op donderdag 8 augustus 2024 @ 22:13:
Is er een manier om bepaalde folders van de host toegankelijk te maken vanuit een container?
Bijvoorbeeld om deze te syncen?
[ Voor 25% gewijzigd door Ghoulli op 08-08-2024 23:27 ]
Misschien is de betere vraag, wat wil je doen? Je kunt prima een folder door meerdere containers laten delen met volume mounts. Het is alleen niet altijd verstandig. Als bijvoorbeeld bestanden verdwijnen of verplaatsen.Airw0lf schreef op donderdag 8 augustus 2024 @ 22:13:
Is er een manier om bepaalde folders van de host toegankelijk te maken vanuit een container?
Bijvoorbeeld om deze te syncen?
(1) - via een Syncthing of Kopia container een backup maken van wat host-folders.
(2) - van een Docker container de bestanden in /var/log te kunnen inzien via de host.
makes it run like clockwork
Dat kan denk ik t makkelijkste door volumes te mappen in je container in de composefile.Airw0lf schreef op zondag 11 augustus 2024 @ 17:37:
Er zijn twee aanleidingen:
(1) - via een Syncthing of Kopia container een backup maken van wat host-folders.
(2) - van een Docker container de bestanden in /var/log te kunnen inzien via de host.
1)
1
2
3
4
5
6
7
8
9
10
| services: syncthing: image: syncthingimage container_name: syncthing-app volumes: - /<pad op host/<map die gesynct moet worden>:/<pad in container>/sync-source - /<pad op host/<map waar naartoe gesynct moet worden>:/<pad in container>/sync-destination # en dat voor elke map ddie gesynct moet worden ports: - 1234:1234 |
2)
1
2
3
4
5
6
7
8
| services: syncthing: image: <imagenaam> container_name: <containernaam> volumes: - /<pad naar directory op host>:/<pad in container>/logs ports: - 1234:1234 |
1
2
3
4
| services: kopia: volumes: - /<pad naar directory op host>:/appdata:ro |
Dan weet je ook zeker dat Kopia (of andere software) niet zomaar aanpassingen aan de brondata kan doen.
Ja, docker-compose is top. Gebruik zelf portainer omdat ik lui ben en wel van wat GUI hou op die vlakken.alex3305 schreef op woensdag 24 juli 2024 @ 10:18:
@Ghoulli Mocht alles nu werken na jouw migratie zou ik je willen aanraden om te kijken naar Docker Compose. Voorbeelden vind je alom, maar bijvoorbeeld ook in de blogpost die ik eerder linkte.
Met Compose ben je ook niet zo afhankelijk van Portainer (je hebt bijvoorbeeld ook Dockge of Dokémon) en daar kun je dergelijke afhankelijkheden ook eenvoudig in definiëren.
Enige waar ik wel tegenaan liep. Ik gebruik ubuntu server. En was portainer aan het testen op een vm bij TransIP en toen kreeg ik een mail van ze dat ik poorten had openstaan die exploited konden worden. En ik doe liever UFW dan iptables, maar UFW gaat niet goed om met die docker-proxy die nodig is om portainer te draaien. Die stond dus open voor de hele wereld. Dat is niet handig . Docker zegt het is UFW en Ubuntu zegt het is docker. Kortom 5 jaar verder en het is nog steeds een ding.
https://github.com/docker/for-linux/issues/690
In portainer is het handig dat je die compose files in een "stack" kan gooien en de hele handel in 1x kan updaten al dan niet via een webhook met een cron. En migreren tussen portainer instances is ook 1 druk op de knop. Eenvoud dient de mens lol.
Heb zelf een leipe compose gemaakt met gluetun, rtorrent, sonarr, radarr, jackett enz. port mappen voor de torrents door de vpn tunnel, altijd goed connectable. Gluetun is wel echt de bom voor dit soort toepassingen.
Het zal allicht aan mij liggen, maar ik heb dit 'probleem' nooit begrepen. Ik bedoel, ik snap wel hoe het werkt en wat er aan de hand is, maar nooit waarom men dit een probleem vind. Je laat twee compleet verschillende stukken software het beheer nemen over iptables om daarna te gaan klagen dat ze elkaar in de weg zittenbinbash. schreef op zaterdag 17 augustus 2024 @ 23:58:
[...]
En ik doe liever UFW dan iptables, maar UFW gaat niet goed om met die docker-proxy die nodig is om portainer te draaien. Die stond dus open voor de hele wereld. Dat is niet handig . Docker zegt het is UFW en Ubuntu zegt het is docker. Kortom 5 jaar verder en het is nog steeds een ding.
https://github.com/docker/for-linux/issues/690

In principe is de klassieke optie kinderlijk eenvoudig. Docker niet iptables laten aanpassen. Of poorten niet zomaar naar buiten openzetten. Of een reverse proxy gebruiken. Daarnaast zijn er ook nog wat complexere oplossingen voor dit probleem, maar die heb ik altijd onnodig ingewikkeld gevonden.
En natuurlijk dit soort zaken altijd zelf even testen. De verantwoordelijkheid van het inrichten van zulke complexe systemen hoort bij jezelf te zitten en niet bij Docker of Canonical. Je gaat toch ook niet Makita de schuld geven als je met de handcirkelzaag je pink eraf haalt omdat je de veiligheidsrichtlijnen niet in acht hebt genomen? Het staat per slot van rekening ook in de documentatie.
Dat doe ik met Watchtower die ik per compose stack deploy:In portainer is het handig dat je die compose files in een "stack" kan gooien en de hele handel in 1x kan updaten al dan niet via een webhook met een cron.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| services: watchtower: container_name: ${COMPOSE_PROJECT_NAME}-watchtower image: containrrr/watchtower restart: on-failure environment: TZ: ${TZ:-Europe/Amsterdam} WATCHTOWER_CLEANUP: true WATCHTOWER_LOG_LEVEL: error WATCHTOWER_SCHEDULE: '0 0 1 * * *' WATCHTOWER_SCOPE: ${COMPOSE_PROJECT_NAME} network_mode: bridge volumes: - /var/run/docker.sock:/var/run/docker.sock cpus: 0.1 labels: - com.centurylinklabs.watchtower.scope=${COMPOSE_PROJECT_NAME} |
Op andere containers hoef ik dan alleen maar het scope label mee te geven: com.centurylinklabs.watchtower.scope=${COMPOSE_PROJECT_NAME} om het eenvoudig per stack te scopen. Dan kan ik met o.a. het schedule enorm eenvoudig alternatieve schema's meegeven per stack.
Wel met de enorme disclaimer mits de omgeving gelijk isEn migreren tussen portainer instances is ook 1 druk op de knop.
lol ja dat is ook waar. Daarbij dom dat ik niet even kijk wat er luistert vanaf de buitenkant. Assumption is the mother of all zeg maar. Al hadden ze er wel even een zin over in een quick install tutorial kunnen zetten. Lees zelden direct de complete documentatie lol Ik zal niet de eerste en zeker niet de laatste zijn die dit gebeurt. Zeker met portainer, is wel voor de hobby bobber.alex3305 schreef op zondag 18 augustus 2024 @ 11:03:
[...]
Het zal allicht aan mij liggen, maar ik heb dit 'probleem' nooit begrepen. Ik bedoel, ik snap wel hoe het werkt en wat er aan de hand is, maar nooit waarom men dit een probleem vind. Je laat twee compleet verschillende stukken software het beheer nemen over iptables om daarna te gaan klagen dat ze elkaar in de weg zitten
Watchtower gebruik ik voor werk idd, mooi spul voor het lokale dev ding, maar voor thuis rommelen doe ik het prima met portainer.
[ Voor 3% gewijzigd door binbash. op 18-08-2024 12:33 ]
Zoals altijd "it depends". Met IPVLAN / MACVLAN koppel je de containers direct in je netwerk en zal elke container zijn eigen IP adres in jou netwerk krijgen. Zelf vind ik dat nogal overdreven, dus doe ik dat niet. Maar ik heb er dan weer een vrij complexe setup van gemaakt met bridges per VLAN waarbij de routering vanuit de containers over het bijbehorende VLAN gaat. Maar Docker zelf kent/snapt daar niks van. Ik heb dit zelf geregeld met ip rules (Linux utilities) om per bridge een andere routing tabel te hanteren.Shattering schreef op maandag 19 augustus 2024 @ 15:37:
Hey! Ik heb ondertussen een 10-tal docker containers draaien op mijn Intel NUC - verdeeld over twee Bridge netwerken. Omdat ik momenteel bezig ben met mijn thuisnetwerk te VLAN'en, was ik aan het onderzoeken of dit wel de beste oplossing is. Is het aangeraden om te migreren naar ipvlan of macvlan?
Inmiddels ben ik gewisseld naar Caddy als reverse proxy en gebruik ik Docker's labels om automatisch de containers te proxien via Caddy. Ik zit dus nu in de fase dat ik weer wegga van het ipvlan netwerk naar een of meerdere bridge netwerken om zoveel mogelijk intern te houden. Overigens zijn er wel applicaties die ik hoogstwaarschijnlijk wel via het ipvlan netwerk beschikbaar houdt. Bijvoorbeeld Home Assistant, zodat niet alles via de reverse proxy moet. Maar daar ben ik nog niet helemaal over uit. Dat ben ik ook nog aan het uitzoeken.
Besef je overigens wel dat er geen fout of goed is. Het zijn vooral voorkeuren. En het is ook allemaal later nog aan te passen
Hey, bedankt voor je reactie. Ik draai momenteel al m’n containers in Bridge, met daarvoor een Traefik Reverse Proxy. Al m’n containers zijn dan ook met een FQDN over HTTPS te bereiken, maar het enige waar ik niet zeker van ben is hoe ik dit kan integreren in m’n UniFI netwerk/VLAN set-up.alex3305 schreef op maandag 19 augustus 2024 @ 20:45:
@Shattering In tegenstelling tot @RobertMe heb ik wel alles op een ipvlan netwerk draaien. Dat bevalt prima en vond ik vooral erg eenvoudig met het opzetten. Ik gebruikte eerder Nginx Proxy Manager als reverse proxy en dan was het doorverwijzen appeltje-eitje.
Inmiddels ben ik gewisseld naar Caddy als reverse proxy en gebruik ik Docker's labels om automatisch de containers te proxien via Caddy. Ik zit dus nu in de fase dat ik weer wegga van het ipvlan netwerk naar een of meerdere bridge netwerken om zoveel mogelijk intern te houden. Overigens zijn er wel applicaties die ik hoogstwaarschijnlijk wel via het ipvlan netwerk beschikbaar houdt. Bijvoorbeeld Home Assistant, zodat niet alles via de reverse proxy moet. Maar daar ben ik nog niet helemaal over uit. Dat ben ik ook nog aan het uitzoeken.
Besef je overigens wel dat er geen fout of goed is. Het zijn vooral voorkeuren. En het is ook allemaal later nog aan te passen.
Het zou fijn zijn dat ik mijn containers als aparte ‘apparaten’ binnen UniFi Network kan zien (al is dat misschien helemaal niet mogelijk omdat ze niet rechtstreeks op de switch hangen)? Moest het wel gaan denk ik dat macvlan moet gebruiken, maar dat lijkt dan weer niet zo stabiel te zijn (volgens verschillende fora/postst - zelf geen ervaring mee).
Misschien moet ik het simpel houden en gewoon de bridge netwerken behouden. Uiteindelijk geeft het bridge netwerk ook gewoon segmentatie (iets wat ik wou bereiken via VLAN’s).
Mijn HA zit in zeker 4 netwerken. Macvlan zodat network discovery werkt, Traefik voor reverse proxy, "backend" met database, Mosquitto, ..., en dan ook nog eens in media VLAN (wederom, discovery etc voor communicatie met media spul (versterker, mediaspeler, ...)).alex3305 schreef op maandag 19 augustus 2024 @ 20:45:
Bijvoorbeeld Home Assistant, zodat niet alles via de reverse proxy moet. Maar daar ben ik nog niet helemaal over uit. Dat ben ik ook nog aan het uitzoeken.
Bij mij werkt dit dus ook met ipvlanShattering schreef op maandag 19 augustus 2024 @ 20:53:
[...]
Het zou fijn zijn dat ik mijn containers als aparte ‘apparaten’ binnen UniFi Network kan zien (al is dat misschien helemaal niet mogelijk omdat ze niet rechtstreeks op de switch hangen)? Moest het wel gaan denk ik dat macvlan moet gebruiken, maar dat lijkt dan weer niet zo stabiel te zijn (volgens verschillende fora/postst - zelf geen ervaring mee).

In mijn ervaring werkt macvlan prima. En ja, daarmee zijn die containers ook zichtbaar in de UniFi controller.Shattering schreef op maandag 19 augustus 2024 @ 20:53:
[...]
Hey, bedankt voor je reactie. Ik draai momenteel al m’n containers in Bridge, met daarvoor een Traefik Reverse Proxy. Al m’n containers zijn dan ook met een FQDN over HTTPS te bereiken, maar het enige waar ik niet zeker van ben is hoe ik dit kan integreren in m’n UniFI netwerk/VLAN set-up.
Het zou fijn zijn dat ik mijn containers als aparte ‘apparaten’ binnen UniFi Network kan zien (al is dat misschien helemaal niet mogelijk omdat ze niet rechtstreeks op de switch hangen)? Moest het wel gaan denk ik dat macvlan moet gebruiken, maar dat lijkt dan weer niet zo stabiel te zijn (volgens verschillende fora/postst - zelf geen ervaring mee).
Misschien moet ik het simpel houden en gewoon de bridge netwerken behouden. Uiteindelijk geeft het bridge netwerk ook gewoon segmentatie (iets wat ik wou bereiken via VLAN’s).
Nog één korte vraag voor de specialisten: splitsen jullie je docker-compose file op in meerdere files of alles in één grote file?
1 file per "wat bij elkaar hoort". Bv paperless heb ik 1 compose file met daarin de 3 componenten van paperless. Traefik is 1 container dus ook 1 file voor. Alleen bij Home Assistant heb ik nog individueel wat gesplitst. De database is gedeeld tussen HA en DSMR-Reader, maar staan in 3 losse files. In doe van de DB staat wel weer Influx erbij, terwijl alleen HA influx gebruikt, en Mosquitto staat er ook nog naast in dezelfde file. Daarnaast een file voor de coordinators (Zigbee2mqtt & ZWave JS UI).Shattering schreef op woensdag 21 augustus 2024 @ 17:37:
Ok, bedankt allemaal - dan ga ik eens beginnen spelen met macvlan!
Nog één korte vraag voor de specialisten: splitsen jullie je docker-compose file op in meerdere files of alles in één grote file?
Maar dat heb ik zo gedaan omdat het in totaal ook op misschien wel 10 containers gaat waarbij soms de relaties wat stricter zijn en soms wat losser. (Bv Zigbee2mqtt & HA draaien prima onafhankelijk van elkaar, maar de communicatie loopt over MQTT en daarmee Mosquitto als software. ZWave JS UI & HA zijn ook maar losjes gekoppeld, maar HA verbind wel rechtstreeks met ZWave JS UI).
Heb je toevallig een voorbeeld van hoe je dit doet? Ik probeer "trunked bridge" te gebruiken, maar mijn container (nginx test) blijft niet bereikbaar (vanaf andere toestellen van het netwerk - ik weet dat hij niet bereikbaar hoort te zijn van de docker host).RobertMe schreef op maandag 19 augustus 2024 @ 20:57:
[...]
In mijn ervaring werkt macvlan prima. En ja, daarmee zijn die containers ook zichtbaar in de UniFi controller.
:fill(white):strip_exif()/f/image/z41gSsC7Ju6X41RUz3zT7RuJ.png?f=user_large)
In elk mapje zit dan een compose.yml en een .env bestand.
i7 9700k + Be-Quiet Dark Rock 4 Pro | Gigabyte Z390 Aorus Ultra | Gigabyte Aorus GTX1080TI | Samsung 970 Pro 512GB + 860 EVO 1TB | 2x8GB DDR4 3000Mhz | Seasonic Platinum 660W | Fractal Design R6 | Acer Predator X34P | M-Audio AV40
Dat is op te lossen met een shim.Shattering schreef op woensdag 21 augustus 2024 @ 19:02:
[...]
ik weet dat hij niet bereikbaar hoort te zijn van de docker host).
Wat betreft compose, ik gebruik "docker run" commands, kan ik beter mee uit de voeten dan compose.
The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long
GoT voor Behoud der Nederlandschen Taal [GvBdNT
Dus als iemand zich geroepen voelt... :-)
makes it run like clockwork
Onder OMV 6 gebruikte ik vooral Portainer om nieuwe containers mee aan te maken maar met de overgang naar 7 kwam er flink verbeterde Docker ondersteuning en inmiddels wordt ook aan Kubernetes (ik meen K3S) gewerkt - voor mij nog niet relevant.
Het grrotste voordeel: ALS je je omgeving een beetje gestructureerd opzet komt al je container data ook gestructureerd terecht. Dat begint al bij de compose file met bijbehorende ENV. NB: Niet de global ENV dus. Er zijn ook wat ingebouwde variabelen die zaken "handig" maken en zoals eerder door <effe kwijt> al in dit topic opgemerkt kan de juiste proxy manager een bijdrage leveren aan verdere vereenvoudiging.
Voor mij is het een verademing om meteen te kunnen zien wat waar gebeurd, zeker een verbetering over het intypen in Portainer schermpjes.
Meerwaarde? Ik denk dus dat dat een Persoonlijke Smaak keuze is.
Hoe update je dan? Ik met docker compose up -d --pull always in de map (of een submap van) de compose.yaml. Met CLI moet je zeker stop + pull + run doen waarbij run weer het originele ellenlange commando is?Airw0lf schreef op donderdag 22 augustus 2024 @ 08:30:
Ik ben (soort-van) blijven hangen in docker run cli omdat ik de meerwaarde Docker Compose niet zie.
Dus als iemand zich geroepen voelt... :-)
Edit:
En daarnaast heb je met de composer.yaml het uberhaupt in een bestand staan, dat je kunt backuppen, of bijhouden in versiebeheer (/Git).
[ Voor 13% gewijzigd door RobertMe op 22-08-2024 09:38 ]