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

[CSB]

Dank voor de antwoorden. Ik ga me inlezen.

[RobertMe]

Als heads up. Docker 27 heeft schijnbaar by default IPv6 support enabled incl. het gebruik van ip6tables. An zich natuurlijk prima dat Docker nu by default IPv6 support heeft.

Maar... ik had iptables uit staan in Docker en beheer de firewall handmatig (met nft / nftables). En ik heb alles al ingericht op IPv6 (sterker nog, Docker containers zijn grotendeels alleen via IPv6 benaderbaar, al dan niet via een reverse proxy). En for some reason was na die update ineens "alles stuk". Reden weet ik (nog) niet, maar nu ik "ip6tables": false heb toegevoegd aan /etc/docker/daemon.json (waar ik ook al een regel voor iptables had dus) en ik gereboot heb (herstart Docker werkte vast niet doordat die firewall regels niet opruimde?) werkt alles weer zoals voorheen.

[Raven]

RobertMe schreef op vrijdag 28 juni 2024 @ 14:33:
Als heads up. Docker 27 heeft schijnbaar by default IPv6 support enabled incl. het gebruik van ip6tables. An zich natuurlijk prima dat Docker nu by default IPv6 support heeft.

.... zijn ze er daar niet van op de hoogte dat nftables al een aantal versies (in Debian) default is?

[RobertMe]

Raven schreef op vrijdag 28 juni 2024 @ 16:43:
[...]

.... zijn ze er daar niet van op de hoogte dat nftables al een aantal versies (in Debian) default is?

nftables is al heel lang de default op heel wat distos AFAIK. Maar in ieder geval is er een nftables compatible variant van de iptables tooling. En/dus werkt Docker prima met iptables.

Maar Docker heeft maar twee firewall implemtaties. Een voor iptables en een voor firewalld. Maar... ik vind het sowieso wel fijn om gewoon lekker zelf de firewall te beheren zonder allemaal magic van Docker. Dan weet ik ook daadwerkelijk wat open staat en niet dat "ineens" een poort is open gezet door Docker (sure, je moet alsnog de -p flag of port: in compose gebruiken, maar ook als je alleen op een bepaalde interface, of specifiek bron IP wilt filteren, etc).

[Raven]

RobertMe schreef op vrijdag 28 juni 2024 @ 17:04:
[...]

nftables is al heel lang de default op heel wat distos AFAIK. Maar in ieder geval is er een nftables compatible variant van de iptables tooling. En/dus werkt Docker prima met iptables.

Ik ben alleen met Debian-/Ubuntu-based distro's bekend, dus geen idee hoe het met de rest zit

Maar als je een zelf geschreven firewall hebt ( op mijn router-pc doe ik dat met https://wiki.nftables.org/wiki-nftables/index.php/Scripting ) dan heb je dus de eigen firewall en dat wat Docker via ip6tables heeft aangemaakt apart erbij. Dat is niet echt handig qua overzichtelijkheid.

Daarom gebruik ik PiVPN bijv. niet, die verwacht en gebruikt nog steeds iptables. Alternatieven ook en howto's die de oude manier gebruiken zijn ondergesneeuwd door verwijzingen naar PiVPN

[ Voor 10% gewijzigd door Raven op 28-06-2024 19:11 ]

[R.G]

alex3305 schreef op vrijdag 14 juni 2024 @ 11:19:
@CSB Ja dat kan. Ik heb bijvoorbeeld toen ik Home Assistant nog op een Pi draaide, had ik mijn Docker data op een externe USB staan zodat de SD kaart niet overbelast raakte. Bij IBM staat een aardige uitleg hoe je de data-root zoals dat heet kunt verplaatsen. In mijn notes had ik het verkort zo staan:

Bash:

sudo -s

# Stop all containers and Docker
docker stop $(docker ps -aq)
systemctl stop docker

# Create new directory and copy everything over
mkdir -p /var/data/usb/docker
cp -p -r /var/lib/docker/* /var/data/usb/docker/

# Add docker root to dameon config
vim /etc/docker/daemon.json
# Add -> "data-root": "/var/data/usb/docker/"

# Start Docker
systemctl start docker

Waarbij /var/data/usb/ uiteraard de andere partitie was.

Is dit een industrie oplossing doen alle bedrijven het zo? of ongeveer zo?

[RobertMe]

Raven schreef op vrijdag 28 juni 2024 @ 19:08:
Maar als je een zelf geschreven firewall hebt ( op mijn router-pc doe ik dat met https://wiki.nftables.org/wiki-nftables/index.php/Scripting ) dan heb je dus de eigen firewall en dat wat Docker via ip6tables heeft aangemaakt apart erbij. Dat is niet echt handig qua overzichtelijkheid.

Nouja, Docker doet met IPv6 / ip6tables niet veel anders dan met IPv / iptables. En beide kun je dus uitschakelen.

/etc/docker/daemon.json:

JSON:

{
  "iptables": false,
  "ip6tables": false
}

Bijkomend effect is dan wel dat als je port forwarding gebruikt (-p flag van Docker CLI of port: in compose) dat Docker een proxy executable start die op de host draait die op die poort luistert en het verkeer 1-op-1 doorzet naar de container. Dus port forwarding van Docker moet je dan "gewoon" niet meer gebruiken. Maar in de plaats dus zelf in de firewall de dnat rules aanmaken, verkeer accepteren, etc.

[alex3305]

R.G schreef op vrijdag 28 juni 2024 @ 19:23:
[...]

Is dit een industrie oplossing doen alle bedrijven het zo? of ongeveer zo?

Bij mijn werkgever deden we het op een vergelijkbare manier. Dit is namelijk ook een optie die Docker en OS updates overleeft.

[Airw0lf]

Kan je via die deamon.json ipv6 ook helemaal uitzetten? Wat is dat commando dan?

[RobertMe]

Airw0lf schreef op vrijdag 28 juni 2024 @ 21:51:
Kan je via die deamon.json ipv6 ook helemaal uitzetten? Wat is dat commando dan?

Yes, dat kan, "ipv6": false. Maar waarom zou je dat doen? Docker op zichzelf doet sowieso geen DHCP-PD of zo. Docker kiest zelf een ULA voor het default bridge netwerk (en ik meen ook voor zelf aangemaakte bridge netwerken) en that's it. De containers krijgen dus niet ineens een publiek IPv6 adres uit zichzelf. En als je geen IPv6 op de host hebt dan zijn de containers dus ook niet via IPv6 bereikbaar.

[ Voor 6% gewijzigd door RobertMe op 28-06-2024 21:55 ]

[alex3305]

RobertMe schreef op vrijdag 28 juni 2024 @ 21:54:
[...]

En als je geen IPv6 op de host hebt dan zijn de containers dus ook niet via IPv6 bereikbaar.

Dit zou mijn voorkeur sowieso hebben als je niet met IPv6 wilt werken.

[Airw0lf]

RobertMe schreef op vrijdag 28 juni 2024 @ 21:54:
[...]

Yes, dat kan, "ipv6": false. Maar waarom zou je dat doen? Docker op zichzelf doet sowieso geen DHCP-PD of zo. Docker kiest zelf een ULA voor het default bridge netwerk (en ik meen ook voor zelf aangemaakte bridge netwerken) en that's it. De containers krijgen dus niet ineens een publiek IPv6 adres uit zichzelf. En als je geen IPv6 op de host hebt dan zijn de containers dus ook niet via IPv6 bereikbaar.

Mijn default-mode-of-operations is zoiets als "alles wat niet gebruikt wordt kan net zo goed uitgeschakeld worden en behoeft daardoor geen aandacht".

[Airw0lf]

Op een LXC container krijg ik bij het ophalen van het swag-docker-image de volgende melding:

code:

docker: failed to register layer: failed to Lchown "/dev/console" for UID 0, GID 0: lchown /dev/console: no such file or directory.

Het ophalen gebeurd als sudo-er en zonder het aanmaken van de container.

Bij de 3 andere Docker containers krijg ik die melding niet.

De genoemde "folder" /dev/console is er wel.

Ik vindt wel vergelijkbare meldingen op internet. Maar dat gaat over Docker versie 27.0.
Ik maak gebruik van versie 27.0.2

Iemand enig idee wat hier aan de hand kan zijn?

[ Voor 15% gewijzigd door Airw0lf op 01-07-2024 18:56 ]

[DjoeC]

Ik ben op zoek naar een link/beschikbaarheids checker in een container. Doel: Kijken of specifieke pagina's op specifieke websites benaderbaar zijn en dat het liefst in een docker container die dat "regelmatig" checkt. Reden: Het spontaan ontdekken van een "403 not authorized" op een subdirectory na een update door een webhoster. Hoe lang dit al speelt is onbekend en ik wil dit in de toekomst voorkomen.

Ik vind eigenlijk alleen https://github.com/linkchecker/linkchecker (5 jaar oud) of https://hub.docker.com/r/dcycle/broken-link-checker/ die onderliggend blijkbaar de eerste weer aanroept (of ik zie het verkeerd).

Ik mis ook een beetje het "actief" waarschuwen (messaging) hoewel een .csv waarschijnlijk wel weer te parsen of te monitoren is - maar ja dan wordt het weer zo'n houtje-touwtje oplossing. Het gaat om een stuk of wat specifieke pagina's over verschillende sites.

Iemend een goed idee?

[RobertMe]

DjoeC schreef op maandag 1 juli 2024 @ 16:16:
Ik ben op zoek naar een link/beschikbaarheids checker in een container. Doel: Kijken of specifieke pagina's op specifieke websites benaderbaar zijn en dat het liefst in een docker container die dat "regelmatig" checkt. Reden: Het spontaan ontdekken van een "403 not authorized" op een subdirectory na een update door een webhoster. Hoe lang dit al speelt is onbekend en ik wil dit in de toekomst voorkomen.

Ik vind eigenlijk alleen https://github.com/linkchecker/linkchecker (5 jaar oud) of https://hub.docker.com/r/dcycle/broken-link-checker/ die onderliggend blijkbaar de eerste weer aanroept (of ik zie het verkeerd).

Ik mis ook een beetje het "actief" waarschuwen (messaging) hoewel een .csv waarschijnlijk wel weer te parsen of te monitoren is - maar ja dan wordt het weer zo'n houtje-touwtje oplossing. Het gaat om een stuk of wat specifieke pagina's over verschillende sites.

Iemend een goed idee?

Ik denk dat je meer uit de voeten kunt met "uptime (monitor)" als zoekterm? Waarmee je binnen no time zult uitkomen bij Uptime Kuma.

[DjoeC]

RobertMe schreef op maandag 1 juli 2024 @ 17:09:
[...]

Ik denk dat je meer uit de voeten kunt met "uptime (monitor)" als zoekterm? Waarmee je binnen no time zult uitkomen bij Uptime Kuma.

Tja, de zoekterm ;-) Dit ziet er goed uit, demo diet iig wat ik zoek. Zal m eens aanslingeren.

Aanvulling: Hij draait en doet wat ie moet doen...

[ Voor 7% gewijzigd door DjoeC op 01-07-2024 18:53 ]

[Airw0lf]

Airw0lf schreef op maandag 1 juli 2024 @ 15:41:
Op een LXC container krijg ik bij het ophalen van het swag-docker-image de volgende melding:
[code]docker: failed to register layer: failed to Lchown "/dev/console" for UID 0, GID 0: lchown /dev/console: no such file or directory.[/code]

Het ophalen gebeurd als sudo-er en zonder het aanmaken van de container.

Bij de 3 andere Docker containers krijg ik die melding niet.

De genoemde "folder" /dev/console is er wel.

Ik vindt wel vergelijkbare meldingen op internet. Maar dat gaat over Docker versie 7.0.
Ik maak gebruik van versie 27.0.2

Iemand enig idee wat hier aan de hand kan zijn?

Zojuist opgelost met een Docker update naar 27.0.3!

[ElCondor]

Een vraag, ik heb een aantal docker instances draaien met per instance verschillende services.
Nu zitten daar een aantal overkoepelende services tussen zoals Traefik en Authentik. Deze services gaan er, tijdens configuratie bijna altijd van uit dat de containers die ze bedienen direct via een docker proxy netwerk te bereiken zijn, maar zodra ik een container op een andere docker instance (dus ook op een andere 'fysieke' host) wil benaderen dan moet dat altijd met kunst en vliegwerk. Bij Traefk kun je met ynamic config files werken en die laten verwijzen naar 'externe' adressen (extern aan de locale docker instance) maar dan moet je zoiweso die docker containers op het normale fysieke lan ontsluiten omdat uberhaupt te kunnen doen.
Daarbij krijg ik het gevoel dat dergelijke configuraties welondersteund worden, maar altijd als een soort afterthougt geïmplementeerd zijn in Traefik of Authentik.

Ik heb zelf het idee dat ik hiermee een denkfout maak en eigenlijk een soort tunnel moet creëren tussen alle docker instances zodat er één groot virtueel proxy netwerk ontstaat waarop de containers vrijelijk met elkaar kunnen communiceren en alléén via de Traefik proxy van buiten bereikt kunnen worden.

Ik heb echter onvoldoende kennis van docker networking om dit goed in te richten en ik zou daarom graag willen polsen, zit ik hiermee in de goede richting of moet ik het helemaal over een andere boeg gooien?

Thx alvast voor het meedenken!

[ Voor 6% gewijzigd door ElCondor op 10-07-2024 10:58 ]

[RobertMe]

ElCondor schreef op woensdag 10 juli 2024 @ 10:56:
Een vraag, ik heb een aantal docker instances draaien met per instance verschillende services.
Nu zitten daar een aantal overkoepelende services tussen zoals Traefik en Authentik. Deze services gaan er, tijdens configuratie bijna altijd van uit dat de containers die ze bedienen direct via een docker proxy netwerk te bereiken zijn, maar zodra ik een container op een andere docker instance (dus ook op een andere 'fysieke' host) wil benaderen dan moet dat altijd met kunst en vliegwerk. Bij Traefk kun je met ynamic config files werken en die laten verwijzen naar 'externe' adressen (extern aan de locale docker instance) maar dan moet je zoiweso die docker containers op het normale fysieke lan ontsluiten omdat uberhaupt te kunnen doen.
Daarbij krijg ik het gevoel dat dergelijke configuraties welondersteund worden, maar altijd als een soort afterthougt geïmplementeerd zijn in Traefik of Authentik.

Ik heb zelf het idee dat ik hiermee een denkfout maak en eigenlijk een soort tunnel moet creëren tussen alle docker instances zodat er één groot virtueel proxy netwerk ontstaat waarop de containers vrijelijk met elkaar kunnen communiceren en alléén via de Traefik proxy van buiten bereikt kunnen worden.

Ik heb echter onvoldoende kennis van docker networking om dit goed in te richten en ik zou daarom graag willen polsen, zit ik hiermee in de goede richting of moet ik het helemaal over een andere boeg gooien?

Thx alvast voor het meedenken!

Geen ervaring mee, maar volgens mij kom je dan bij (bv?) Docker Swarm uit.
Waar je dan echt naar op zoek bent is een manier om een Docker (/container runtime?) cluster op te zetten. I.p.v. dus een willekeurige Docker instance te draaien op een standalone systeem.

[remyz]

ElCondor schreef op woensdag 10 juli 2024 @ 10:56:
Ik heb zelf het idee dat ik hiermee een denkfout maak en eigenlijk een soort tunnel moet creëren tussen alle docker instances zodat er één groot virtueel proxy netwerk ontstaat waarop de containers vrijelijk met elkaar kunnen communiceren en alléén via de Traefik proxy van buiten bereikt kunnen worden.

Je bent denk ik op zoek naar "overlay network": https://docs.docker.com/network/drivers/overlay/

[ElCondor]

remyz schreef op woensdag 10 juli 2024 @ 11:49:
[...]


Je bent denk ik op zoek naar "overlay network": https://docs.docker.com/network/drivers/overlay/

Dat klinkt inderdaad interessant. Maar, is dit alleen te bouwen mbh van Docker Swarm? Wellicht ter verduidelijking, ik heb op dit moment 3 docker instances draaien, één op een Hyper-V VM, voorzien van Ubuntu als host OS. Vervelend daaraan was dat die gebruik bleek te maken van de docker snap Dit heb ik kunnen vervangen door een gewonen install van Docker maar de containers staan nog in allerlei docker snap folders en dat is niet ideaal.
Daarnaast een fysieke host voorzien van OpenSUSE Tumbleweed
En dan nog een LXC Container op ProxMox gebaseerd op Alpine.
Deze drie instances worden beheerd door een portainer installatie op de Ubuntu host met agents deployed op beide andere hosts.
De bedoeling is dat alles naar het ProxMox cluster gaat waarna de Hyper-V fysieke machine afgebouwd wordt en ook voorzien wordt van ProxMox/LXC-Alpine/Docker

Kan Docker Swarm over bestaande containers worden heen gelegd, of ben je er meer mee gebaat om alles van de grond af aan te bouwen?

De volgende vraag die dan op komt is, hoe ga ik de huidge containers qua inhoud backuppen en restoren?

Zo veel vragen

[Airw0lf]

ElCondor schreef op woensdag 10 juli 2024 @ 11:59:

[...]

Zo veel vragen

Mijn complimenten met de resultaten tot nu toe (serieus!) - je hebt wel lef!

Maar ook: mijn telepatische gaven zijn niet meer wat ze geweest zijn... laat staan dat ik op een afstand kan zien hoe/waar alles ingesteld en opgeslagen is... nog maar los van een mogelijk migratie scenario...

En met passages als "een Hyper-V VM, voorzien van Ubuntu als host OS" gaat bij mij het licht uit...

Daarom hieronder mijn 0,500 Euro voor een mogelijk vervolg...

=====

Alle gegevens bestanden via sftp en SMB kopiëren naar een losse, externe disk.
Vervolgens instellingen overnemen in een tekst/Word/Writer-bestand; al dan niet in de vorm van screenshots.

Dan alles vanaf scratch uitzoeken, schemas maken, beschrijven en opbouwen.
Gaandeweg ga je andere inzichten krijgen. Pas hierop schemas en beschrijvingen aan.

Bij het opbouwen zoveel mogelijk plain Debian gebruiken (bij Proxmox kun je niet anders) - dus ook bij de VM's en LXC containers - dat maakt de leercurve minder steil. In dat kader lijkt me Linux Mint een mooi alternatief voor je Suse desktop.

Docker containers komen vaak met een voor-geconfigureerd mini-OS - daar aan gaan sleutelen lijkt me geen handige - laat staan eigen, custom Docker images maken.

Ik weet niet op welke schaalgrootte je uiteindelijk aan de slag wil met alles - maar afgaande op de staat van nu zal het niet zo heel groot zijn. Met die aanname lijkt me Portainer (zonder agents) prima voor Docker-beheer. In een (Proxmox?)-cluster opzet lijkt me Kubernetes een prima opzet.

Het aan elkaar knopen van Docker containers kan prima via het reguliere netwerk. Het Docker networking arsenaal van host, bridge en mac-vlan geeft hiervoor voldoende speelruimte. Een mac-vlan zie ik als een last-resort - voor als het echt niet anders meer kan. Bijvoorbeeld omdat je niet van overlappende TCP-poorten af kunt komen die via je LAN toegankelijk moeten zijn.

Het enige wat je hierbij in het oog moet houden zijn DNS-namen, IP subnets (vlans?), IP-adressen en TCP poorten. Misschien Pihole inzetten voor DNS, vlan en subnet beheer?

Waarschijnlijk ga je in dit proces gegevens en instellingen verliezen... maar goed - op die manier leer je wel waar en hoe "dingen" opgeslagen worden?! Zodat je ook weet hoe een backup eruit zou kunnen zien!?

[ Voor 29% gewijzigd door Airw0lf op 11-07-2024 07:24 ]

[ElCondor]

Airw0lf schreef op woensdag 10 juli 2024 @ 21:49:
[...]


Mijn complimenten met de resultaten tot nu toe (serieus!) - je hebt wel lef!

Maar ook: mijn telepatische gaven zijn niet meer wat ze geweest zijn... laat staan dat ik op een afstand kan zien hoe/waar alles ingesteld en opgeslagen is... nog maar los van een mogelijk migratie scenario...

En met passages als "een Hyper-V VM, voorzien van Ubuntu als host OS" gaat bij mij het licht uit...

Daarom hieronder mijn 0,500 Euro voor een mogelijk vervolg...

=====

Alle gegevens bestanden via sftp en SMB kopiëren naar een losse, externe disk.
Vervolgens instellingen overnemen in een tekst/Word/Writer-bestand; al dan niet in de vorm van screenshots.

Dan alles vanaf scratch uitzoeken, schemas maken, beschrijven en opbouwen.
Gaandeweg ga je andere inzichten krijgen. Pas hierop schemas en beschrijvingen aan.

Bij het opbouwen zoveel mogelijk plain Debian gebruiken (bij Proxmox kun je niet anders) - dus ook bij de VM's en LXC containers - dat maakt de leercurve minder steil. In dat kader lijkt me Linux Mint een mooi alternatief voor je Suse desktop.

Docker containers komen vaak met een voor-geconfigureerd mini-OS - daar aan gaan sleutelen lijkt me geen handige - laat staan eigen, custom Docker images maken.

Ik weet niet op welke schaalgrootte je uiteindelijk aan de slag wil met alles - maar afgaande op de staat van nu zal het niet zo heel groot zijn. Met die aanname lijkt me Portainer (zonder agents) prima voor Docker-beheer. In een (Proxmox?)-cluster opzet lijkt me Kubernetes een prima opzet.

Het aan elkaar knopen van Docker containers kan prima via het reguliere netwerk. Het Docker networking arsenaal van host, bridge en mac-vlan geeft hiervoor voldoende speelruimte. Een mac-vlan zie ik als een last-resort - voor als het echt niet anders meer kan. Bijvoorbeeld omdat je niet van overlappende TCP-poorten af kunt komen die via je LAN toegankelijk moeten zijn.

Het enige wat je hierbij in het oog moet houden zijn DNS-namen, IP subnets (vlans?), IP-adressen en TCP poorten. Misschien Pihole inzetten voor DNS, vlan en subnet beheer?

Waarschijnlijk ga je in dit proces gegevens en instellingen verliezen... maar goed - op die manier leer je wel waar en hoe "dingen" opgeslagen worden?! Zodat je ook weet hoe een backup eruit zou kunnen zien!?

Hahaha, ja, idd, organische groei, hè?

Je begint ergens mee, het bevalt, je voegt nog eens wat toe en dan hangt het al snel met touwtjes en plakband aan elkaar.
Het heeft een aardige historie. Ben van huis uit een Windows beheerder en heb daarmee een heel domein thuis draaien, DC's, file, db en web servers, the works. Sinds een paar jaar Linux ontdekt (via Raspberry Pi) en daarmee aan de slag gegaan, met als grote stok achter de deur de koers die MS de laatste jaren is gaan voeren.
Heb echter ook rekening te houden met mijn echtgenote die ook flink gebruik maakt van de infra meer niet zo van Linux en zo is.
Ik vond dat ik ook eens met Docker aan de slag moest, dus ik denk, om te testen trek ik een (Hyper-V) VM met Linux in de lucht en zet daar docker op. toen nog de keuze voor Ubuntu gemaakt (zonder GUI). And whaddayaknow, het werkt, eigenlijk best goed. Dus je plakt er nog een paar services naast.
Later kwam hier onder andere nog een oude desktop die ik geconverteerd heb naar linux server op basis van OpenSUSE (ook zonder GUI) bij. Daar na een tijdje ook weer even snel een docker install op om hier en daar een container te kunnen testen zonder daarmee de Ubuntu VM te moeten belasten.

Dan tot de conclusie gekomen dat ik de inmiddels her en der gehoste services wil gaan consolideren op een NUC clustertje met ProxMox als basis, daarop een Container met Alpine/Docker, omdat ik er nog niet aan toe ben om ook nog LCX containers in de mix te gooien. Die Alpine Docker combi kwam ik op YouTube tegen als lightweight oplossing om zowel van ProxMox gebruik te kunnen maken en daarnaast ook Docker containers zonder al te veel overhead.
Ik zou hier natuurlijk een Debian/Docker VM van kunnen maken op ProxMox, als dat meer aan te raden is en er verder geen risico is van een teveel aan overhead.
Rest nog steeds mijn netwerk probleem, maar daar ga ik me, naar aanleiding van de adviezen hier, nog eens goed in verdiepen. Waarvoor dank dus!

[Mars Warrior]

@ElCondor . Containers binnen Docker willen heel graag binnen hetzelfde netwerk draaien. Wil je externe services benaderen dan is dat altijd moeilijk. Dat heb je inmiddels gemerkt ook met Traefik.

Het probleem is dat alles tegen de Docker API aanlult, en daar dus zijn informatie (DNS, IP adres) vandaan haalt.

Wil je een systeem over meerdere instances, dan zul je bijv. Docker Swarm moeten nemen. Die vereist minimaal 1 master en een aantal workers. Zonder master doen ze niks.
Heb je de master aangemaakt, dan moeten de workers een "Join" doen om ze toe te voegen.

Ik heb hier ooit een berg aan RPI's gehad als Docker Swarm. Werkt wel goed. Het leuke is dat je op elke node kunt connecten (bijv op poort 80 als daar een webserver draait), en dat Docker Swarm intern uitzoekt op welke node deze poort actief is.

Docker Swarm is erg energie efficient. Dit in tegenstelling tot k*s. Die kan een RPI al aardig belasten zonder dat je ook maar 1 container hebt draaien.

Consolideren op 1 instance is het makkelijkst. En als je Docker Compose snapt zou dat voor mij de aangewezen weg zijn. Dat je dan nog met Portainer een stuk inzicht/overzicht hebt dat is fijn, maar alles in 1 echte compose file is toch wel het minste werk om een hele serie container aan te maken en te beheren.

De compose file kun je makkelijk in Git zetten bijv.

[ElCondor]

Mars Warrior schreef op donderdag 11 juli 2024 @ 10:41:
@ElCondor . ...

Consolideren op 1 instance is het makkelijkst. ...

Daar zit ik ook steeds meer aan te denken.
Docker swarm is inderdaad ook een optie, als zit ik dan nog wel met eventueel gedeelde storage in mijn maag. Daar heb ik op dit moment ook nog weinig kaas van gegeten.
Ik had Kubernetes inderdaad ook al een keer op 3 Pi's geprobeerd, maar om de een of andere manier vernaggelde na een reboot iedere keer het filesystem waardoor de Pi's niet meer bootten...
Vandaar dat ik voor nu nog even met losse instances aan de slag ben gegaan.

Consolideren op 1 instance introduceert natuurlijk ook nog een SPoF. Dus dan zou een Swarm/Kubernetes wel weer handig zijn.... maar... storage....

[Mars Warrior]

ElCondor schreef op donderdag 11 juli 2024 @ 10:47:
[...]

Daar zit ik ook steeds meer aan te denken.
Docker swarm is inderdaad ook een optie, als zit ik dan nog wel met eventueel gedeelde storage in mijn maag. Daar heb ik op dit moment ook nog weinig kaas van gegeten.
Ik had Kubernetes inderdaad ook al een keer op 3 Pi's geprobeerd, maar om de een of andere manier vernaggelde na een reboot iedere keer het filesystem waardoor de Pi's niet meer bootten...
Vandaar dat ik voor nu nog even met losse instances aan de slag ben gegaan.

Consolideren op 1 instance introduceert natuurlijk ook nog een SPoF. Dus dan zou een Swarm/Kubernetes wel weer handig zijn.... maar... storage....

Swarm doet vziw niet aan gedeelde storage. Een failover van een service moet dus eigenlijk gebruik maken van een gedeelde share (NFS). Dat werkte wel, maar niet altijd even lekker.

K*s heeft daar wel keuze in, maar kan erg complex zijn om goed op te zetten. Daarnaast is het nogal een load op al je nodes en kun je last krijgen van het split brain syndroom: dan synced er niks meer...

[ElCondor]

Mars Warrior schreef op donderdag 11 juli 2024 @ 11:10:
[...]

Swarm doet vziw niet aan gedeelde storage. Een failover van een service moet dus eigenlijk gebruik maken van een gedeelde share (NFS). Dat werkte wel, maar niet altijd even lekker.

K*s heeft daar wel keuze in, maar kan erg complex zijn om goed op te zetten. Daarnaast is het nogal een load op al je nodes en kun je last krijgen van het split brain syndroom: dan synced er niks meer...

Ah, te ingewikkeld, ik hoor het al
Destijds met die Pi's dus toch begonnen met rennen terwijl ik nog moest leren kruipen.

[Mars Warrior]

ElCondor schreef op donderdag 11 juli 2024 @ 11:12:
[...]


Ah, te ingewikkeld, ik hoor het al
Destijds met die Pi's dus toch begonnen met rennen terwijl ik nog moest leren kruipen.

Een multi node k*s systeem heeft ook een control plane/master nodig om te draaien. Iemand moet immers alles in de gaten houden (fail-over) en pods deployen op de nodes waar nog ruimte is (mem/cpu etc).

Er is niks eenvoudigers als een docker compose file deployen op een single node.

En wat betreft de SPoF: hoevaak is bij jou hardware kapot gegaan? Mijn vorige server was 11 jaar oud, en die is vervangen door een server die weer hopelijk 10 jaar of langer meegaat...

Je moet dus wel een off-site backup hebben van al je spulletjes, want je weet nooit natuurlijk!

[DjoeC]

@ElCondor Wat ik (probeer) te doen maar disclaimer - ik ben beginnend Dockeraar, gebruik momenteel 1 (ben de 2e aan het uitschakelen) Pi4 met 2TB SSD, mogelijk komt er nog een 14TB HDD bij voor media, volgende fase.

1. Basis is voor mij OMV 7. Waarom? Handig om folders te sharen zonder zelf te klooien. Leercurve, lezen, fouten maken en opnieuw beginnen, daarom gaat het nu bij de 2e Pi een stuk beter. De 1e Pi was ingericht met containers via Portainer (create new container). Deze keer ALLES met Compose onder OMV-extras (services -> compose) met gebruik van beschikbare variabelen. Lees en leer ;-) Ik gebruik GEEN stacks (meerdere containers/services in 1 compose).
2. Portainer geinstalleerd (compose file). Waarom? Inzicht is eenvoudiger onder Portainer dan onder OMV. GEEN containers oid aangemaakt onder Portainer.
3. Pihole geinstalleerd via Compose met gebruik van een macvlan. Pihole krijgt dan een primair netwerk adres en valt buiten het interne docker netwerk. Kun je gebruiken om ook andere containers op het externe netwerk te krijgen, maar goed...
4. Containers (services) aangemaakt in een user-bridge netwerk. Standaard docker bridge netwerk staat geen onderlinge communicatie toe (don't ask...). Krijgen allemaal eigen poorten in het (bij mij) 170.20.0.0/16 netwerk.
5. Containers die ik bij naam wil benaderen (mosquitto.example.thuis, mariadb.example.thuis) en die de "standaard" poort gebruiken (1883, 3306) opgenomen als hostnaam in de PiHole DNS. Een koppeling met mariadb kan dan als DBHOST=mariadb of DBHOST=pinaam, beiden hebben hetzelfde IP adres en pihole zal dat resolven.
6. Containers op macvlan hebben direct een eigen IP en zijn dus in het netwerk al als hostnaam "bekend", opnemen inde DNS zou denk ik niet nodig zijn maar ik doe het wel.
7. Zou je nog een stap verder willen gaan dan kun je NGINX Proxy Manager in een container draaien. Daarbij zou ik dan ook ddns-updater in een container zetten. Maak een account aan bij Duckdns en/of zet een domein (een .nl bijvoorbeeld via Namecheap, kun je meteen voor 8 jaar vastleggen voor weinig geld) via DNS doorverwijzing bij Cloudflare. Laat elk subdomein doorverwijzen naar je NPM, zet er Letsencrypt en evt access lists op (lees en leer...) en je kunt al je webinterfaces met een echte URL benaderen. Wel via de buitenwereld maar het werkt heerlijk bij bijvoorbeeld mijn Nextcloud calenders, weerstation pagina en een paar websites (ander domeinnamen).

Voordeel gebruik Pihole: Gaat je container/applicatie naar een andere server: alleen het IP adres in Pihole aanpassen. Idem bij NPM, verandert er iets: alleen de forwarding aanpassen. Ik vermoed (...) dat je op NPM ook niet webapplicaties/poorten kunt rerouten maar dat heb ik nog niet geprobeerd.

Alles momenteel op 1 Pi4 (24 containers), daar komt nog iets bij. De voorgaande Pi draaide ongeveer hetzelfde maar was veel "rommeliger" opgezet omdat alles nieuw was. Afgelopen 1-2 jaar veel bij geleerd en nu ben ik er (bijna) tevreden mee.

[Airw0lf]

Ik gebruik Docker containers meestal tegen de host adapter.
Die host adapter heeft ook een aantal (logische) vlan-adapters.
Met als eindresultaat dat een container gekoppeld wordt met alle adapters.

Is er een manier om een container bij het opstarten iets mee te geven zodat ie maar één van die adapters gebruikt? En wat zou dat kunnen zijn?

[alex3305]

@Airw0lf Kun je een voorbeeld geven hoe je het nu doet?

Ik gebruik geen host adapters maar een ipvlan zodat ik ook een apart ip toe kan wijzen aan de containers. Op die manier kun je ze ook scheiden.

[Airw0lf]

alex3305 schreef op zondag 14 juli 2024 @ 13:34:
@Airw0lf Kun je een voorbeeld geven hoe je het nu doet?

Ik gebruik geen host adapters maar een ipvlan zodat ik ook een apart ip toe kan wijzen aan de containers. Op die manier kun je ze ook scheiden.

Klopt - ik zou hiervoor gebruik kunnen maken van een mac-vlan.
Alleen dan met een ander IP adres als de host - wat het weer onnodig complex maakt.

Op dit moment is het zo dat een Docker container zich bind aan alle interfaces.
Dat lijkt te komen door bij het opstarten 0.0.0.0 te gebruiken.

Ik zoek een manier om dit te vervangen door (bijvoorbeeld) eth0.
Maar zowel bij de host als in de container kan ik daar niks over vinden.

[ Voor 14% gewijzigd door Airw0lf op 14-07-2024 13:43 ]

[alex3305]

@Airw0lf Je kunt poorten binden naar een specifieke extern ip, maar dat is met een bridge en geen host. Per container lijkt mij dit sowieso niet haalbaar, wellicht voor heel de daemon.

Alleen dan met een ander IP adres als de host - wat het weer onnodig complex maakt.

Ik vind het binden van meerdere diensten aan 1 ip adres juist onnodig complex. Dan moet je o.a. rekening houden met poort reserveringen, wat bij aparte adressen of een bridge netwerk niet hoeft.

[Mars Warrior]

Ik gebruikte voorheen ook mcvlans om de verschillende containers apart te kunnen benaderen.

Met de inrichting van de nieuwe server ben ik hier volledig van afgestapt op de Adguard container na die ook de DNS verzorgt van de server (en het netwerk).

Voor alles wat via het web ontsloten kan worden gebruik ik nu Caddy met Docker proxy.

Daarmee kun je alles via een publieke of locale URL benaderen, en dat zonder poort conflicten omdat de Caddy container direct met Docker praat, en dus het interne docker IP adres van de container kan benaderen.

Je hebt dus GEEN problemen meer als meer containers op poort 80 zitten. Je moet die poort ook niet meer exposen via een port: mapping.

Dus:

• Caddy + Proxy voor het web. Caddy doet automatisch SSL. Daar hoef je helemaal niets voor in te richten. Sterker nog, je moet extra dingen doen om enkel HTTP te gebruiken...
• Caddy + Proxy is declaratief: alles staat in je docker compose file. Het domein waarop de service benaderd moet worden en de (proxy) poort dus. Geen gekloot meer met dingen in een NPM bestand oid.
• In Adguard voer ik de lokale en publieke domeinen in.
• Klaar.

[RobertMe]

Mars Warrior schreef op zondag 14 juli 2024 @ 13:50:
Ik gebruikte voorheen ook mcvlans om de verschillende containers apart te kunnen benaderen.

Met de inrichting van de nieuwe server ben ik hier volledig van afgestapt op de Adguard container na die ook de DNS verzorgt van de server (en het netwerk).

Voor alles wat via het web ontsloten kan worden gebruik ik nu Caddy met Docker proxy.

Daarmee kun je alles via een publieke of locale URL benaderen, en dat zonder poort conflicten omdat de Caddy container direct met Docker praat, en dus het interne docker IP adres van de container kan benaderen.

Je hebt dus GEEN problemen meer als meer containers op poort 80 zitten. Je moet die poort ook niet meer exposen via een port: mapping.

Dus:

• Caddy + Proxy voor het web. Caddy doet automatisch SSL. Daar hoef je helemaal niets voor in te richten. Sterker nog, je moet extra dingen doen om enkel HTTP te gebruiken...
• Caddy + Proxy is declaratief: alles staat in je docker compose file. Het domein waarop de service benaderd moet worden en de (proxy) poort dus. Geen gekloot meer met dingen in een NPM bestand oid.
• In Adguard voer ik de lokale en publieke domeinen in.
• Klaar.

Er kunnen natuurlijk ook andere redenen zijn om een container aan het netwerk te exposen En een DNS server hoeft niet via macvlan. Immers is DNS gewoon singlecast etc. Als je AdGuard ook als DHCP server kunt gebruiken, en dat ook doet (PiHole kan dit, AdGuard weet ik niet) is macvlan wel een vereiste, omdat DHCP multicast / broadcast gebruikt en dat uiteraard niet over subnets heen gaat.

* RobertMe gebruikt tegenwoordig nog alleen IPv6. En voor de VLANs op mijn netwerk heb ik individuele bridges gemaakt die dan gekoppeld zijn aan de "fysieke" VLANs. Dus bv een "br-prive" Docker (bridge) netwerk dat gekoppeld is aan de "prive" netwerk interface (netwerk interfaces een eigen naam geven , anders zou dat bv een eth0.10 zijn). Het "fysieke" VLAN gebruikt vervolgens als subnet fd00:10::/64, (met de :10: van het VLAN ID). De Docker bridge gebruikt vervolgens per host systeem (zelfbouw router vs server vs zelfbouw NAS) fd00:10:x::/64 (met x = 1 voor router, 2 voor server of 3 voor NAS). Het host systeem publiceert vervolgens zelf ook IPv6 router advertisements voor deze Docker subnets. Dus alle systemen (PCs, laptops, tablets, telefoons, ...) in bv het prive VLAN weten dan ook dat ze om fd00:10:::/64 te bereiken dit verkeer moeten sturen naar het ULA adres van de router, fd00:10:2::64 naar het ULA adres van de server, etc..
Dus alle Docker containers hebben een direct routeerbaar adres (geen NAT) en in en uitgaand verkeer loopt over het VLAN. Enige "restricties" komen dan uit de firewall op de host waar ik het forwarden naar containers dus wel of niet toe sta. Port forwards van Docker gebruik ik dus ook expliciet niet ("iptables" en "ip6tables" staan verder ook uit in Docker, waardoor Docker ook van de firewall af blijft).

Edit:
Ter aanvulling / voor de duidelijkheid. Ik heb wel gewoon Traefik als reverse proxy draaien voor HTTP verkeer. Echter heeft Traefik intussen wel pootjes in meerdere Docker bridges/netwerken. Waarbij bepaalde services alleen bereikbaar zijn via een specifiek netwerk / inkomend IP adres. (Bv Gitea is via Traefik bereikbaar vanuit 2 VLANs, prive en een ander, maar SSH direct naar de Gitea container is alleen bereikbaar vanuit het prive VLAN. En de containers in de Gitea stack zitten op een eigen bridge network, en de webserver/main container dan ook in het traefik network zodat Traefik wel met de webserver van Gitea kan babbelen).

[ Voor 9% gewijzigd door RobertMe op 14-07-2024 14:30 ]

[Airw0lf]

alex3305 schreef op zondag 14 juli 2024 @ 13:49:
@Airw0lf Je kunt poorten binden naar een specifieke extern ip, maar dat is met een bridge en geen host. Per container lijkt mij dit sowieso niet haalbaar, wellicht voor heel de daemon.


[...]

Ik vind het binden van meerdere diensten aan 1 ip adres juist onnodig complex. Dan moet je o.a. rekening houden met poort reserveringen, wat bij aparte adressen of een bridge netwerk niet hoeft.

Hoe helpt dat IPvlan dan?
Ik heb het nooit gebruikt en begrijp ook niet goed wat het doet?

[alex3305]

@Mars Warrior Ik snap jouw oplossing / setup compleet en ben zelfs ook nog aan het kijken om naar iets soortgelijks over te stappen. Echter dan in combinatie met ipvlan (of macvlan) zodat ik containers toch nog op hostname niveau kan benaderen wanneer nodig. Sowieso voor een transitieperiode. Ik heb namelijk (voor buiten) een SSO setup voor mijn containers zitten en daar wil ik soms nog eens omheen .

Ik heb sowieso op mijn lijstje staan om uit te zoeken hoe Caddy forward auth en wildcard certificaten doet voordat ik eventueel over kan stappen.

@RobertMe Intern IPv6 heb ik ook nog naar zitten kijken maar heeft momenteel niet mijn voorkeur. Ik draai Docker met name op Unraid en de laatste keer dat ik dat testte (een half jaar geleden) kwamen containers niet altijd online wanneer ik ipvlan icm IPv6 probeerde . Die bug is als het goed is opgelost, maar ben niet meer aan testen toegekomen .

@Airw0lf ipvlan of macvlan drivers zorgen ervoor dat je dus losse IP adressen kunt toewijzen aan containers. Die zitten dan als host gekoppeld. Dus je hoeft geen aparte poort mappings toe te wijzen. Bijvoorbeeld mijn (geknipte) AdGuard Home setup:

YAML:

services:
  adguardhome:
    container_name: adguardhome
    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
    labels:
      'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}'
  
  unbound:
    container_name: ${COMPOSE_PROJECT_NAME}-unbound
    image: klutchell/unbound:${UNBOUND_VERSION:-latest}
    restart: on-failure
    networks:
      private:
        ipv4_address: 10.100.100.20
    labels:
      'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}'

  watchtower:
    container_name: ${COMPOSE_PROJECT_NAME}-watchtower
    image: containrrr/watchtower
    environment:
      TZ: ${TZ:-Europe/Amsterdam}
      WATCHTOWER_CLEANUP: true
      WATCHTOWER_LOG_LEVEL: error
      WATCHTOWER_SCHEDULE: '0 59 23 * * *'
      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}'

networks:
  br0:
    name: br0
    external: true
  private:
    name: ${COMPOSE_PROJECT_NAME}
    ipam:
      driver: default
      config:
        - subnet: 10.100.100.0/24

De AdGuard Home container zit aan twee netwerken gekoppeld en is op 192.168.1.4 bereikbaar. Ook kan deze container bij Unbound via het private netwerk met een statisch IP adres. Tot slot zit Watchtower aan het bridge netwerk zodat deze updates kan binnen hengelen.

Naar buiten heb ik (uiteraard) alleen mijn reverse proxy op poort 443 openstaan. Dit is vooralsnog voor mij een mooie tussenweg tussen veiligheid met expliciete poort mapping en network host mode.

[deHakkelaar]

Airw0lf schreef op zondag 14 juli 2024 @ 13:39:
Op dit moment is het zo dat een Docker container zich bind aan alle interfaces.
Dat lijkt te komen door bij het opstarten 0.0.0.0 te gebruiken.

Ik dacht dat de default voor een container de bridge mode/driver was.
Dus een container interface (virtueel) is dan een slaaf van een lostaande virtuele bridge die gecreeerd is en met niks is verbonden.
Je kunt dan met de ports directive poortjes in de container NATen naar buiten toe.
Zo kun je dus verschillende containers met elkaar laten praten over dezelfde bridge.
En alleen de poortjes die je publiekelijk wilt blootstellen NATen/forwarden naar buiten toe.
De container zelf bind dan toch alleen aan z'n eigen virtuele interface en niet de fysieke vd host zelf .... toch???

Ben nog een groentje wbt Docker maar ik lees graag
https://docs.docker.com/network/drivers/

[Airw0lf]

@alex3305 - top - bedankt voor de uitgebreide toelichting.

Ah - ok - dus samengevat:
Als ik het dan goed begrijp is 192.168.1.0/24 het subnet van je gebruikers.
Die krijgen via DHCP de Adguard DNS server (d.w.z. 192.168.1.4 ) toegespeeld.
Waarbij de opgestarte container dezelfde poorten heeft open staan als wanneer het via de host zou gaan (dus port mappings aanmaken is niet nodig).

[deHakkelaar]

@airwolf , of bedoel je met "interfaces" de virtuele interfaces vd de container zelf (EDIT: als deze er meerdere heeft) ?

[ Voor 33% gewijzigd door deHakkelaar op 14-07-2024 20:55 ]

[Airw0lf]

deHakkelaar schreef op zondag 14 juli 2024 @ 20:51:
[...]

Ik dacht dat de default voor een container de bridge mode/driver was.
Dus een container interface (virtueel) is dan een slaaf van een lostaande virtuele bridge die gecreeerd is en met niks is verbonden.
Je kunt dan met de ports directive poortjes in de container NATen naar buiten toe.
Zo kun je dus verschillende containers met elkaar laten praten over dezelfde bridge.
En alleen de poortjes die je publiekelijk wilt blootstellen NATen/forwarden naar buiten toe.
De container zelf bind dan toch alleen aan z'n eigen virtuele interface en niet de fysieke vd host zelf .... toch???

Ben nog een groentje wbt Docker maar ik lees graag
https://docs.docker.com/network/drivers/

De default is inderdaad bridge-mode. En in dat geval moet je zelf zorgen voor de juiste (TCP/UDP) poort mappings omdat de container werkt met een eigen private IP adres ruimte.

Je kan een container ook opstarten in host-mode. Dan gebruikt die container dezelfde ethernet poorten en IP adressen als de host - in mijn geval dus inclusief een aantal vlan-interfaces. Met als bijkomend na- en voordeel dat er geen poort mappings aangemaakt kunnen worden - alles is voorgeconfigureerd en wordt een-op-een doorgegeven.

De vlan-interfaces beginnen allemaal met eth0.<getal>. Terwijl alleen eth0 (dus zonder de vlan-interfaces voldoende is).

[ Voor 12% gewijzigd door Airw0lf op 14-07-2024 21:06 ]

[Mars Warrior]

RobertMe schreef op zondag 14 juli 2024 @ 14:25:
[...]

Er kunnen natuurlijk ook andere redenen zijn om een container aan het netwerk te exposen En een DNS server hoeft niet via macvlan. Immers is DNS gewoon singlecast etc. Als je AdGuard ook als DHCP server kunt gebruiken, en dat ook doet (PiHole kan dit, AdGuard weet ik niet) is macvlan wel een vereiste, omdat DHCP multicast / broadcast gebruikt en dat uiteraard niet over subnets heen gaat.

Ik ben niet helemaal wakker. Ik draai AdGuard in hostmode en heb de default DnS server van Ubuntu uitgeschakeld. AdGuard kan ook DHCP doen, maar dat doet een oude RPI2 bij mij.

De rest is dus bereikbaar via een lokaal domein (dus nooit van buitenaf) of een extern domein en dus SSL.

[deHakkelaar]

Airw0lf schreef op zondag 14 juli 2024 @ 20:56:
De vlan-interfaces beginnen allemaal met eth0.<getal>. Terwijl alleen eth0 (dus zonder de vlan-interfaces voldoende is).

Zoiets?

$ ip -br l
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             00:16:3e:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>

$ ip -br -4 a
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.0.145/24

$ sudo ip address add 192.168.10.10/32 dev eth0
$

$ ip -br l
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             00:16:3e:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>

$ ip -br -4 a
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.0.145/24 192.168.10.10/32

[Airw0lf]

deHakkelaar schreef op zondag 14 juli 2024 @ 21:05:
[...]

Zoiets?

$ ip -br l
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             00:16:3e:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>

$ ip -br -4 a
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.0.145/24

$ sudo ip address add 192.168.10.10/32 dev eth0
$

$ ip -br l
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             00:16:3e:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>

$ ip -br -4 a
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.0.145/24 192.168.10.10/32

Zou kunnen - maar ik (her)ken dit niet.

Ik gebruik overal ifup. En op een van de VM's staat in /etc/network/interfaces het volgende:

code:

# The physical NIC and management vlan
auto eth0
iface eth0 inet dhcp

# IoT vlan
auto eth0.230
iface eth0.230 inet dhcp

# Staging vlan
auto eth0.110
iface eth0.110 inet dhcp

Wat het subnet is voor elk van deze interfaces wordt bepaald door dnsmaq (als onderdeel van pihole).

[deHakkelaar]

@Airw0lf , VM?
Ik dacht dat je het over de Docker host had
EDIT: Met ik neem aan maar 1 fysieke interface.

[ Voor 27% gewijzigd door deHakkelaar op 14-07-2024 21:23 ]

[Airw0lf]

deHakkelaar schreef op zondag 14 juli 2024 @ 21:21:
@Airw0lf , VM?
Ik dacht dat je het over de Docker host had
EDIT: Met ik neem aan maar 1 fysieke interface.

Nee - een LCX container die fungeert als Docker host.
En ja - deze heeft maar een fysieke interface.

Ik heb ook een fysieke Docker host met twee fysieke poorten.
Dan ziet het er bij mij ongeveer zo uit:

code:

# Add eth0 to bond0
auto eth0
iface eth0 inet manual
   bond-master bond0
   bond-primary eth0

# Dito for eth1
auto eth1
iface eth1 inet manual
   bond-master bond0

# The bonding network interface
# The default (legacy) vlan 1
auto bond0
iface bond0 inet dhcp
   bond-slaves eth0 eth1
   bond-mode 5
# Mode 5 of 6 - Adaptive loadbalancing - LACP werkt niet goed - veel TCP fouten

# Staging vlan 110 | subnet 192.168.110.0/24
auto bond0.110
iface bond0.110 inet dhcp

# IoT/Domotica vlan 230 | subnet 192.168.230.0/24
auto bond0.230
iface bond0.230 inet dhcp

De Docker container aanmaken en opstarten is in beide gevallen hetzelfde:

code:

docker run \
  --name omada \
  --net=host \
  -v /opt/docker/omada/data:/opt/tplink/EAPController/data \
  -v /opt/docker/omada/logs:/opt/tplink/EAPController/logs \
  -e PORTAL_HTTP_PORT=8888 \
  -d \
  --restart=unless-stopped \
  mbentley/omada-controller:latest

[alex3305]

@deHakkelaar @Airw0lf Jullie hebben het volgens mij over hetzelfde. Alleen is de manier van @deHakkelaar moderner . Als @Airw0lf ip a doet dan krijgt het op die manier ook z'n aangemaakte netwerken te zien.

Airw0lf schreef op zondag 14 juli 2024 @ 20:51:
Als ik het dan goed begrijp is 192.168.1.0/24 het subnet van je gebruikers.

Juist.

Mijn Asus router ondersteund standaard geen tagged vlan's op de LAN poorten. Er is wel een manier via een extensie, maar ik heb nog geen noodzaak gehad om hier verder in te duiken.

Die krijgen via DHCP de Adguard DNS server (d.w.z. 192.168.1.4 ) toegespeeld.

Ja. Mijn DHCP server is mijn router en die adverteert inderdaad mijn twee AdGuard Home instanties als primaire en secondaire DNS.

Waarbij de opgestarte container dezelfde poorten heeft open staan als wanneer het via de host zou gaan (dus port mappings aanmaken is niet nodig).

Bingo!

Maar je zou uiteraard ook Docker containers in een andere range kunnen deployen. Het ipvlan netwerk maak je overigens ook heel eenvoudig aan:

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

En jij zou dit dan (waarschijnlijk) voor jouw vlan-interfaces kunnen doen. Ik kies hier voor de naam br0, maar die kun je uiteraard zelf kiezen.

[deHakkelaar]

Airw0lf schreef op zondag 14 juli 2024 @ 21:34:
[code]# Mode 5 of 6 - Adaptive loadbalancing - LACP werkt niet goed - veel TCP fouten

Je switch moet wel LACP ondersteunen en je moet de switch poortjes daarvoor configureren?

[RobertMe]

Airw0lf schreef op zondag 14 juli 2024 @ 20:56:
Je kan een container ook opstarten in host-mode. Dan gebruikt die container dezelfde ethernet poorten en IP adressen als de host - in mijn geval dus inclusief een aantal vlan-interfaces. Met als bijkomend na- en voordeel dat er geen poort mappings aangemaakt kunnen worden - alles is voorgeconfigureerd en wordt een-op-een doorgegeven.

Voor de duidelijkheid, in network_mode: host wordt niet het verkeer 1 op 1 door gezet of zo. In dit geval zeg je gewoon tegen Docker "dat ding wat je normaliter doet v.w.b. netwerk isolatie, wil ik dat je nu niet doet (voor deze container)". Dat levert dus weer een hele berg potentiele andere problemen op. Als in: elke poort die open staat op de host kun je dus niet meer gebruiken in de container (immers is de poort al in gebruik). En de container kan dus ook (zonder jou weten?) bv lekker een tcpdump draaien en die ziet dan ook alle netwerkverkeer wat op de fysieke interface(s) binnen komt. network_mode: host is dus op zijn minst een bad practice, als niet ronduit een veiligheidsrisico. Je gebruikt Docker juist om zaken geisoleerd te draaien op het systeem, en juist met network_mode: host verwijder je deze isolatie volledig (voor die container).

[RobertMe]

alex3305 schreef op zondag 14 juli 2024 @ 20:29:
@Airw0lf ipvlan of macvlan drivers zorgen ervoor dat je dus losse IP adressen kunt toewijzen aan containers. Die zitten dan als host gekoppeld. Dus je hoeft geen aparte poort mappings toe te wijzen. Bijvoorbeeld mijn (geknipte) AdGuard Home setup:

YAML:

services:
  adguardhome:
    container_name: adguardhome
    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
    labels:
      'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}'
  
  unbound:
    container_name: ${COMPOSE_PROJECT_NAME}-unbound
    image: klutchell/unbound:${UNBOUND_VERSION:-latest}
    restart: on-failure
    networks:
      private:
        ipv4_address: 10.100.100.20
    labels:
      'com.centurylinklabs.watchtower.scope': '${COMPOSE_PROJECT_NAME}'

  watchtower:
    container_name: ${COMPOSE_PROJECT_NAME}-watchtower
    image: containrrr/watchtower
    environment:
      TZ: ${TZ:-Europe/Amsterdam}
      WATCHTOWER_CLEANUP: true
      WATCHTOWER_LOG_LEVEL: error
      WATCHTOWER_SCHEDULE: '0 59 23 * * *'
      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}'

networks:
  br0:
    name: br0
    external: true
  private:
    name: ${COMPOSE_PROJECT_NAME}
    ipam:
      driver: default
      config:
        - subnet: 10.100.100.0/24

De AdGuard Home container zit aan twee netwerken gekoppeld en is op 192.168.1.4 bereikbaar. Ook kan deze container bij Unbound via het private netwerk met een statisch IP adres. Tot slot zit Watchtower aan het bridge netwerk zodat deze updates kan binnen hengelen.

Ik weet niet hoeveel je geknipt hebt, maar hier zit dus lekkerlijk geen ipvlan of macvlan in Mogelijk dat je br0 als ipvlan netwerk hebt aangemaakt, maar dat zien we hier niet (die is immers external).

[Airw0lf]

@RobertMe - misschien een bad practive - maar toch:
De enige reden om virtualisatie in te zetten is meerdere applicaties op één fysieke host zonder dat ze elkaar op een of andere manier gaan bijten. Het liefst zou ik een fysiek systeem voorzien van plain Debian. En via Docker containers applicaties en hun middleware/databases starten in host networking mode.

Mochten er overlappende UDP/TCP-poorten zijn dan wordt per geval bekeken wat te doen. Met als voorkeur via env variabelen de UDP/TCP poorten omleggen binnen de container.

Dat kan helaas niet altijd omdat er software bakkers zijn die een applicatie leveren via een eigen VM met allerhande Docker containers - Home Assistant is daar een voorbeeld van.

Beveiliging doe ik het liefst op host nivo. Op die manier heb ik maar één plek om open poorten en verkeersstromen te monitoren. En bij afwijkende verkeersstromen is er ook maar een punt voor een effectief ingrijpen - het houdt de zaken simpel en overzichtelijk.

[ Voor 20% gewijzigd door Airw0lf op 14-07-2024 22:23 ]

[RobertMe]

@Airw0lf, en daarom ben ik van Proxmox af gestapt. Voegde voor mij niks (meer) toe toen ik met wat trucjes de boel zo aan de praat had dat ik containers in VLANs kon hangen zonder maar direct alles met macvlan te doen. In eerste instantie 4 jaar terug wel voor Proxmox gedaan zodat ik LXC containers aan specifieke VLANs kon hangen en dan per LXC Docker draaien met de containers die ik in dat VLAN wilde hebben (en evt gekoppeld aan die LXC, kon best dat ik 2 of 3 LXC containers had in hetzelfde VLAN).

Maar nu heb ik de boel met Docker etc zo op gezet dat ik een "bridge" per VLAN heb en het verkeer komende vanaf die bridge (dus Docker container naar buiten toe) ook gerouteerd wordt over de bijbehorende (VLAN) interface.

En daarnaast dan ook Docker geconfigureerd om van de firewall af te blijven. Zodat ik dus ook 100% in controle ben van de firewall en weet wat er in staat. I.p.v. dat Docker stiekem wat poorten open zet terwijl ik dat wellicht niet wil. Immers zijn Docker port forwards ook maar gewoon DNAT rules (of in de volksmond "gewoon port forwards", als op poort X verkeer binnen komt dan herschrijf dat / forward dat naar IP adres X dezelfde poort (of zelfs een andere poort)), gecombineerd met NAT / masquarading op zichzelf uiteraard. En bij IPv6 als je de bridge gewoon een eigen subnet geeft dan zijn het nog puur forward rules ook. "Verkeer naar <IPv6 adres van container> met poort X is toegestaan". Zonder dat er DNAT rules of NAT / masquarading aan te pas komt.

[alex3305]

RobertMe schreef op zondag 14 juli 2024 @ 21:44:
[...]

Ik weet niet hoeveel je geknipt hebt, maar hier zit dus lekkerlijk geen ipvlan of macvlan in Mogelijk dat je br0 als ipvlan netwerk hebt aangemaakt, maar dat zien we hier niet (die is immers external).

br0 is inderdaad een ipvlan netwerk. Die maak ik niet via Compose aan omdat ik die deel tussen Compose stacks.

Ik wilde met name de verschillende netwerk configuraties illustreren .

[Airw0lf]

alex3305 schreef op zondag 14 juli 2024 @ 22:24:
[...]

br0 is inderdaad een ipvlan netwerk. Die maak ik niet via Compose aan omdat ik die deel tussen Compose stacks.

Ik wilde met name de verschillende netwerk configuraties illustreren .

Waarvoor dank - maar blijkbaar is er meer nodig om iets werkend te krijgen.
Waaruit bestaat dat meer bij het gegeven het AdGuard voorbeeld?
Oftewel - hoe ziet de aanmaak van dat ipvlan er dan uit?

[Airw0lf]

RobertMe schreef op zondag 14 juli 2024 @ 22:21:

[...]

Maar nu heb ik de boel met Docker etc zo op gezet dat ik een "bridge" per VLAN heb en het verkeer komende vanaf die bridge (dus Docker container naar buiten toe) ook gerouteerd wordt over de bijbehorende (VLAN) interface.

[...]

Hoe heb je dit gedaan? Kan/wil je een voorbeeld geven?

[alex3305]

Airw0lf schreef op zondag 14 juli 2024 @ 22:29:
[...]


Waarvoor dank - maar blijkbaar is er meer nodig om iets werkend te krijgen.
Waaruit bestaat dat meer bij het gegeven het AdGuard voorbeeld?
Oftewel - hoe ziet de aanmaak van dat ipvlan er dan uit?

Dat had ik in mijn vorige post beschreven: alex3305 in "[Docker] [alle OS] Het grote Docker ervaringen en tips topic"

[RobertMe]

Airw0lf schreef op zondag 14 juli 2024 @ 22:33:
[...]


Hoe heb je dit gedaan? Kan/wil je een voorbeeld geven?

In short:
Docker netwerk aanmaken met docker network create ... incl de optie om zelf de naam van de bridge (de "echte" bridge, die je ook met ip link / ip addr etc ziet), zodat ik een "stabiele" / herkenbare naam heb om mee te werken. Dit heb ik dan per VLAN gedaan. Vervolgens heb ik "gewoon" in Linux per VLAN ook een routing tabel gedefinieerd met daarin in ieder geval de route voor het eigen subnet (dus subnet X zit op device Y) en de default route/gateway (wat dus gewoon het IP van de router is / de gateway zoals deze ook via DHCP wordt toegekend). En dan nog routing rules dat verkeer afkomstig van device X (zijde de bridge zoals aangemaakt in "stap 1") gebruik moet maken van routing tabel Y. Dus bv " als inkomende interface br-prive is dan gebruik routing tabel 510" (5(00) heeft geen reden, de 10 matcht VLAN ID 10 van het prive VLAN).

In principe hier grotendeels offtopic En hoe je allemaal die routing stuff regelt is dus sterk afhankelijk van welke tooling je (op de host) gebruikt om het netwerk te beheren/configureren. Zelf gebruik ik hiervoor systemd-networkd die dit allemaal als configuratie optiea heeft. Zou je de standaard tooling van Debian gebruiken (ifup/ifdown?) dan zal veel uitlopen in het zelf uitvoeren van de shell commando's en mogelijk ook weer zelf moeten achterhalen van bepaalde zaken (in systemd-networkd is het bv prima mogelijk om een via DHCP ontvangen gateway toe te voegen aan meerdere routing tabellen. Of andere tooling dat ook kan durf ik niet te zeggen).

[deHakkelaar]

RobertMe schreef op zondag 14 juli 2024 @ 23:36:
(de "echte" bridge, die je ook met ip link / ip addr etc ziet)

$ ip -br link
[..]
xenbr0           UP             2e:5e:fe:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>

$ ip -br link show master xenbr0
eth0             UP             54:b2:03:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>
vif1.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>
vif3.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>
vif5.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

$ sudo ip link set vif1.0 nomaster
$

$ ip -br link show master xenbr0
eth0             UP             54:b2:03:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>
vif3.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>
vif5.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

EDIT: "ip -br " inkloppen en veel dubbeltab
EDIT2: Tenminste dat is als onder is geinstalleerd:

$ apt show bash-completion
[..]
Description: programmable completion for the bash shell
 bash completion extends bash's standard completion behavior to achieve
 complex command lines with just a few keystrokes.  This project was
 conceived to produce programmable completion routines for the most
 common Linux/UNIX commands, reducing the amount of typing sysadmins
 and programmers need to do on a daily basis.

[ Voor 43% gewijzigd door deHakkelaar op 16-07-2024 16:56 . Reden: + bridge mdb ]

[RobertMe]

deHakkelaar schreef op zondag 14 juli 2024 @ 23:51:
[...]

$ ip -br link
[..]
xenbr0           UP             2e:5e:fe:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>

$ ip -br link show master xenbr0
eth0             UP             54:b2:03:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>
vif1.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>
vif3.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>
vif5.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

$ sudo ip link set dev vif1.0 nomaster
$

$ ip -br link show master xenbr0
eth0             UP             54:b2:03:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>
vif3.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>
vif5.0           UP             fe:ff:ff:ff:ff:ff <BROADCAST,MULTICAST,UP,LOWER_UP>

EDIT: "ip -br " inkloppen en veel dubbeltab

Wat wil je hier mee zeggen?

ip --help
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
       ip [ -force ] -batch filename
where  OBJECT := { address | addrlabel | amt | fou | help | ila | ioam | l2tp |
                   link | macsec | maddress | monitor | mptcp | mroute | mrule |
                   neighbor | neighbour | netconf | netns | nexthop | ntable |
                   ntbl | route | rule | sr | tap | tcpmetrics |
                   token | tunnel | tuntap | vrf | xfrm }
       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
                    -h[uman-readable] | -iec | -j[son] | -p[retty] |
                    -f[amily] { inet | inet6 | mpls | bridge | link } |
                    -4 | -6 | -M | -B | -0 |
                    -l[oops] { maximum-addr-flush-attempts } | -br[ief] |
                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] [filename] |
                    -rc[vbuf] [size] | -n[etns] name | -N[umeric] | -a[ll] |
                    -c[olor]}

"-br[ief]", dus het heeft verder vrij weinig met bridges te maken.
Waar ik in ieder geval op doelde is in ieder geval dat bridge die Docker aanmaakt een hash als naam hebben, bv "br-6e91c1b200b0". Terwijl bridges ik zelf heb aangemaakt namen hebben als "br-lan", "br-prive", etc. Dit door gebruik te maken van de option "com.docker.network.bridge.name", uit mijn hoofd iets als docker network create -o com.docker.network.bridge.name=br-prive [...] br-prive.

EDIT2: Tenminste dat is als onder is geinstalleerd:

$ apt show bash-completion
[..]
Description: programmable completion for the bash shell
 bash completion extends bash's standard completion behavior to achieve
 complex command lines with just a few keystrokes.  This project was
 conceived to produce programmable completion routines for the most
 common Linux/UNIX commands, reducing the amount of typing sysadmins
 and programmers need to do on a daily basis.

Nice try, maar ik gebruik zsh (maar ook die doet gewoon auto completion )

[Airw0lf]

@RobertMe - de vraag van een voorbeeld had alleen betrekking op het Docker deel.
Routing is inderdaad off-topic => zonder verder veel in details te gaan: ik gebruik daar een Omada switch voor.

[RobertMe]

Airw0lf schreef op maandag 15 juli 2024 @ 07:12:
@RobertMe - de vraag van een voorbeeld had alleen betrekking op het Docker deel.

Nah, het was ook half een grapje. Het hoort natuurlijk nogal bij elkaar en is het antwoord op de vraag "hoe doe je dat?". Alleen kan ik dus ook geen volledig antwoord geven. Ik weet hoe het in mijn netwerk setup te doen. Alleen is die setup niet perse "standaard".

Routing is inderdaad off-topic => zonder verder veel in details te gaan: ik gebruik daar een Omada switch voor.

offtopic:
Een switch doet switchen, en een router doet routing Tenzij het een layer 3 switch is, die kan ook routen.

En een OS / server / ... kan ook routen. Wat ook exact is wat er gebeurt als je Docker gebruikt. Linux zorgt er dan voor dat verkeer gerouteerd wordt van en naar de Docker containers. Dus in de kernel ip forwarding aanzetten (al dan niet op specifieke interfaces), routing tabel die een hele lijst aan routeerbare / bekende subnets bevat incl op welke interface verkeer te sturen, firewall regels voor masquarading / NAT, port forwarding, .... Dat zijn allemaal dingen die een consumenten router ook doet (en een echte router zou alleen de eerste twee dingetjes doen. Weten hoe verkeer tussen verschillende netwerken heen en weer te sturen, zonder firewalling etc).

[Airw0lf]

@RobertMe - klinkt als een ingewikkelde operatie waardoor een grote(re) kans op fouten/problemen.
Immers - een ongeluk (tikfout) zit in een klein hoekje...

Doe me dan toch maar "iets" waarmee een Docker container gestart kan worden in host network mode en alleen "luistert" naar een opgegeven interface. En als interface niet kan dan een opgegeven IP subnet. Waarbij een subnet ook een /32 "netwerk" mag zijn.

[ Voor 6% gewijzigd door Airw0lf op 15-07-2024 08:19 ]

[RobertMe]

Airw0lf schreef op maandag 15 juli 2024 @ 08:10:
Doe me dan toch maar "iets" waarmee een Docker container gestart kan worden in host network mode en alleen "luistert" naar een opgegeven interface. En als interface niet kan dan een opgegeven IP subnet. Waarbij een subnet ook een /32 "netwerk" mag zijn.

Als je daadwerkelijk network_mode: host wilt gebruiken dan moet je gewoon de software in de container instellen om alleen op een bepaald IP adres of bepaalde interface te luisteren. Immers heeft dat dan niks meer met Docker te maken, want host network

Maar, als je bridge network gebruikt (of de prefefined bridge of een eigen aangemaakt Docker netwerk in bridge of het bridge netwerk dat Compose automatisch voor je aanmaakt), dan kun je in de port forwards (in Docker / Compose) vastleggen op welk IP adres die moet "luisteren" (/welk destination IP adres aan de DNAT firewall regel toegevoegd moet worden).

[Airw0lf]

alex3305 schreef op zondag 14 juli 2024 @ 23:11:
[...]

Dat had ik in mijn vorige post beschreven: alex3305 in "[Docker] [alle OS] Het grote Docker ervaringen en tips topic"

Aja - was ik even vergeten.

Straks eens even proberen met een /32 "subnet"...

[DjoeC]

Tijd voor een nieuwe vraag... Ik ben op zoek naar een lokale registry om mijn zelfgemaakte images (en mogelijk ander spul) in op te slaan. Gaat vooral om kleine Python dingen. Ik zie door de bomen het bos even niet: Distribution, Registry, Harbor, Quay, Gitea, etc, etc.....

Sommigen hebben geen echte interface om even een index of de tags te bekijken, sommigen zijn erg uitgebreid. Doelplatform: Raspberry. Ik kan ook niet echt een goeie vergelijking vinden - of ik zoek verkeerd.

Tips, hints, suggesties?

[RobertMe]

DjoeC schreef op maandag 15 juli 2024 @ 16:11:
Tijd voor een nieuwe vraag... Ik ben op zoek naar een lokale registry om mijn zelfgemaakte images (en mogelijk ander spul) in op te slaan. Gaat vooral om kleine Python dingen. Ik zie door de bomen het bos even niet: Distribution, Registry, Harbor, Quay, Gitea, etc, etc.....

Sommigen hebben geen echte interface om even een index of de tags te bekijken, sommigen zijn erg uitgebreid. Doelplatform: Raspberry. Ik kan ook niet echt een goeie vergelijking vinden - of ik zoek verkeerd.

Tips, hints, suggesties?

Het ligt natuurlijk ook nogal aan wat je wilt. Registry & Harbour zijn AFAIK puur OCI compliant registries (waar je dus OCI compliant images, aka Docker images, in kunt zetten, maar bv ook Helm charts). Gitea is een Git frontend (zoals GitHub), waar ook een package registry, met OCI support, in zit ingebakken. Registry & Harbour zijn dus kinda one trick ponies, Gitea is 1 pony die heel veel trucjes kan (Git frontend, issue tracker, collaboration tool (pull requests etc), package registry, (build) automation, ...).

Zelf heb ik een paar maanden terug Gitea op gezet (ook omdat "Git server" zit ingebakken etc). En dat werkt prima op een licht Intel N5105 gebaseerd systeem dat veel meer taken doet. Maar waarschijnlijk had ik "beter" voor Forgejo kunnen gaan. Gitea is namelijk relatief recent een wat meer commerciële weg ingeslagen (wel nog steeds open source), waarbij Forgejo eerst een soft fork was (dus zeg maar dezelfde code onder een andere naam) maar recentelijker een hard fork (dus meer eigen ontwikkeling en minder 1-op-1 alles van Gitea over nemen).

[Sp33dFr34k]

DjoeC schreef op maandag 15 juli 2024 @ 16:11:
Tijd voor een nieuwe vraag... Ik ben op zoek naar een lokale registry om mijn zelfgemaakte images (en mogelijk ander spul) in op te slaan. Gaat vooral om kleine Python dingen. Ik zie door de bomen het bos even niet: Distribution, Registry, Harbor, Quay, Gitea, etc, etc.....

Sommigen hebben geen echte interface om even een index of de tags te bekijken, sommigen zijn erg uitgebreid. Doelplatform: Raspberry. Ik kan ook niet echt een goeie vergelijking vinden - of ik zoek verkeerd.

Tips, hints, suggesties?

Hoezo überhaupt Docker images? Python heeft toch gewoon virtual environments om e.e.a. gescheiden te houden? Ben even benieuwd naar je motivatie.

[Airw0lf]

Airw0lf schreef op maandag 15 juli 2024 @ 09:21:
[...]

Aja - was ik even vergeten.

Straks eens even proberen met een /32 "subnet"...

@alex3305 en @RobertMe
Ik heb verschillende pogingen gedaan met ipvlan.

Een /32 "subnet" struikelt over het IP adres bij het aanmaken van de container - dit gaat nooit werken...

Daarom maar netjes een netwerk aangemaakt met:

code:

docker network create -d ipvlan \
  --subnet=192.168.139.0/24 \
  --gateway=192.168.139.241 \
  -o parent=eth0 tech

Dan de container aangemaakt met:

code:

docker run -d \
  --name omada-controller \
  --net tech --ip 192.168.139.234 --dns 192.168.139.235 \
  --domainname tech.itv.lan --dns-search tech.itv.lan \
  -v /opt/docker/omada/data:/opt/tplink/EAPController/data \
  -v /opt/docker/omada/logs:/opt/tplink/EAPController/logs \
  -e PORTAL_HTTP_PORT=8888 \
  --restart=unless-stopped

De container start netjes op - geen foutmeldingen in de log.

Maar toch werkt dit niet - als ik met "ss -tulpn" kijk zijn er geen poorten bijgekomen.
Een ping naar het IP adres geeft geen antwoord.

Suggesties?

[ Voor 11% gewijzigd door Airw0lf op 15-07-2024 17:56 ]

[deHakkelaar]

RobertMe schreef op maandag 15 juli 2024 @ 06:27:
Wat wil je hier mee zeggen?

Mijn reactie was niet specifiek naar jou gericht maar meer algemeen.
Ik liet alleen zien hoe je die door Docker aangemaakte bridges handmatig kan manipuleren ... voor diagnose doeleinde etc.

En ja als je bekend bent met de ip toolstack dan weet je dat het -br argument helemaal niks met bridges heeft te maken:

$ man ip
[..]
       -br, -brief
              Print only basic information in a tabular format for better
              readability. This option is currently only supported by ip addr
              show , ip link show & ip neigh show commands.

RobertMe schreef op maandag 15 juli 2024 @ 06:27:
Nice try, maar ik gebruik zsh (maar ook die doet gewoon auto completion )

Die bash-completion package is een toevoeging aan de al aanwezige bash completion:

bash completion extends bash's standard completion behavior

Als jij ip plus een spatie inklopt en dubbeltabt, krijg je dan onder te zien?

$ ip
address     ioam        mptcp       netns       sr          vrf
addrlabel   l2tp        mroute      nexthop     tap         xfrm
amt         link        mrule       ntable      tcpmetrics
fou         macsec      neighbor    ntbl        token
help        maddress    neighbour   route       tunnel
ila         monitor     netconf     rule        tuntap

Ter info:

$ dpkg -L bash-completion
[..]
/usr/share/bash-completion/completions/interdiff
/usr/share/bash-completion/completions/invoke-rc.d
/usr/share/bash-completion/completions/ip
/usr/share/bash-completion/completions/ipcalc
/usr/share/bash-completion/completions/iperf
[..]

$ head /usr/share/bash-completion/completions/ip
# ip(8) completion                                         -*- shell-script -*-

_iproute2_etc()
{
    COMPREPLY+=($(compgen -W \
        "$(awk '!/#/ { print $2 }' /etc/iproute2/$1 2>/dev/null)" \
        -- "$cur"))
}

_ip()

[ Voor 15% gewijzigd door deHakkelaar op 16-07-2024 15:25 . Reden: nog duidelijker ]

[DjoeC]

RobertMe schreef op maandag 15 juli 2024 @ 16:34:
[...]

Het ligt natuurlijk ook nogal aan wat je wilt. Registry & Harbour zijn AFAIK puur OCI compliant registries (waar je dus OCI compliant images, aka Docker images, in kunt zetten, maar bv ook Helm charts). Gitea is een Git frontend (zoals GitHub), waar ook een package registry, met OCI support, in zit ingebakken. Registry & Harbour zijn dus kinda one trick ponies, Gitea is 1 pony die heel veel trucjes kan (Git frontend, issue tracker, collaboration tool (pull requests etc), package registry, (build) automation, ...).

Zelf heb ik een paar maanden terug Gitea op gezet (ook omdat "Git server" zit ingebakken etc). En dat werkt prima op een licht Intel N5105 gebaseerd systeem dat veel meer taken doet. Maar waarschijnlijk had ik "beter" voor Forgejo kunnen gaan. Gitea is namelijk relatief recent een wat meer commerciële weg ingeslagen (wel nog steeds open source), waarbij Forgejo eerst een soft fork was (dus zeg maar dezelfde code onder een andere naam) maar recentelijker een hard fork (dus meer eigen ontwikkeling en minder 1-op-1 alles van Gitea over nemen).

Het is voor prive & hoeft dus niet heel zwaar te zijn maar een paar opties zijn natuurlijk wel handig. Misschien is een git-achtig iets dus niet verkeerd, Dan kan (moet?) ik me ook meteen wat versiebeheer aamleren/toepassen op m'n projectjes. En omdat ik wel van "vrijheid" (open source) houdt zal ik eens naar Forgejo kijken.

[DjoeC]

Sp33dFr34k schreef op maandag 15 juli 2024 @ 16:37:
[...]


Hoezo überhaupt Docker images? Python heeft toch gewoon virtual environments om e.e.a. gescheiden te houden? Ben even benieuwd naar je motivatie.

Ik ben bezig met meerdere projectjes die ik het liefst gescheiden wil houden, naar believen wil kunnen starten, stoppen, wijzgingen inclusief andere Python en andere infra stukjes en willekeurig weer kan poetsen. Daarnaast staat het meerdere vormen van Python omgevingen toe. In mijn beleving zijn containertjes die getriggerd starten en bij beeindigen zichzelf stoppen het meest geisoleerd - naast echte VM's natuurlijk - en ze passen in de huidige opzet van m'n andere > 20 containers die permanent draaien. Gewoon, een systeem kiezen.

[ Voor 4% gewijzigd door DjoeC op 15-07-2024 22:09 ]

[deHakkelaar]

@RobertMe , en heb je extra completion in die zsh shell van jouw?
Ben wel benieuwd
Ook handig voor bv:

$ docker
attach     diff       info       node       rm         stats      version
build      events     inspect    pause      rmi        stop       volume
builder    exec       kill       plugin     run        swarm      wait
commit     export     load       port       save       system
config     help       login      ps         search     tag
container  history    logout     pull       secret     top
context    image      logs       push       service    trust
cp         images     manifest   rename     stack      unpause
create     import     network    restart    start      update

$ sudo journalctl --
--after-cursor    --flush           --no-full         --sync
--all             --follow          --no-hostname     --system
--boot            --force           --no-pager        --unit
--case-sensitive  --full            --no-tail         --until
--catalog         --grep            --output          --update-catalog
--cursor          --header          --output-fields   --user
--cursor-file     --help            --pager-end       --user-unit
--directory       --identifier      --priority        --utc
--disk-usage      --interval        --quiet           --vacuum-files
--dmesg           --lines           --reverse         --vacuum-size
--dump-catalog    --list-boots      --root            --vacuum-time
--facility        --list-catalog    --rotate          --verify
--field           --local           --setup-keys      --verify-key
--fields          --machine         --show-cursor     --version
--file            --merge           --since

[ Voor 85% gewijzigd door deHakkelaar op 17-07-2024 22:39 . Reden: prutsen ]

[RobertMe]

deHakkelaar schreef op woensdag 17 juli 2024 @ 22:36:
@RobertMe , en heb je extra completion in die zsh shell van jouw?
Ben wel benieuwd

offtopic:
It was a joke ZSH heeft AFAIK completion ingebakken, hoef je geen extra packages voor te installeren. "It just works (TM)".

[deHakkelaar]

@RobertMe , wel m'n Syno NAS die op dit moment als Docker host functioneert helaas niet

$ printenv SHELL
/bin/sh

$ readlink -f /bin/sh
/usr/bin/bash

Dus ik zit elke keer in een Debian VM de docker syntax na te bootsen

[RobertMe]

deHakkelaar schreef op woensdag 17 juli 2024 @ 22:59:
@RobertMe , wel m'n Syno NAS die op dit moment als Docker host functioneert helaas niet

$ printenv SHELL
/bin/sh

$ readlink -f /bin/sh
/usr/bin/bash

Dus ik zit elke keer in een Debian VM de docker syntax na te bootsen

Tsja, Syno. Daarom koop ik zo min mogelijk kant en klaar spul. Router heb ik nu iets meer dan een jaar volledig zelfbouw (lees: Debian geïnstalleerd, en vervolgens geconfigureerd als router) en draaien ook wat containers op. Server(tje) is ook gewoon Debian, met Docker. Oude server, nu (on demand) NAS is Proxmox maar vond ik niet je van het (daarom dat later gekochte / vervangende server geen Proxmox heeft). Mijn eerste smartphone was de Nokia N9 met Maemo MeeGo (MeeGo naam op wat effectief nog Maemo was), wat een Debian base had en gewoon via apt-get geupdate kon worden en op zijn minst terminal toegang gaf (volledig root weet ik niet zeker). Mijn tweede telefoon was een Jolla, dat IIRC weer een voortzetting was van de "echte" MeeGo. RPM based en ook daar terminal toegang incl mogelijkheid tot installeren RPMs. Durf dus te wedden dat je heden ten dagen op beide Docker gedraaid zou kunnen hebben. En de shell kon je vast ook wel aanpassen.

[deHakkelaar]

RobertMe schreef op woensdag 17 juli 2024 @ 23:35:
[...]
Nokia N9
[..]
Durf dus te wedden dat je heden ten dagen op beide Docker gedraaid zou kunnen hebben.

Dat wordt kielekiele (EDIT: toen) als onder de minimale kernel versie 3.10 vereist is met een release datum van:
"Sat Jul 13":

Correct; in general, kernel 3.10 is the absolute minimum kernel version that supports the features that Docker requires to run stable (newer versions are preferred though).

However, some Linux distro's back-port features to older kernels so that they are still able to run Docker. Red Hat Enterprise Linux 6.5, for example, is able to run Docker on a kernel 2.6 (it's still a 12 year old kernel, though....)

https://stackoverflow.com...el-version-3-8-13-or-3-10

EDIT: Toen

[Sp33dFr34k]

RobertMe schreef op woensdag 17 juli 2024 @ 23:35:
[...]

Tsja, Syno. Daarom koop ik zo min mogelijk kant en klaar spul. Router heb ik nu iets meer dan een jaar volledig zelfbouw (lees: Debian geïnstalleerd, en vervolgens geconfigureerd als router) en draaien ook wat containers op. Server(tje) is ook gewoon Debian, met Docker. Oude server, nu (on demand) NAS is Proxmox maar vond ik niet je van het (daarom dat later gekochte / vervangende server geen Proxmox heeft). Mijn eerste smartphone was de Nokia N9 met Maemo MeeGo (MeeGo naam op wat effectief nog Maemo was), wat een Debian base had en gewoon via apt-get geupdate kon worden en op zijn minst terminal toegang gaf (volledig root weet ik niet zeker). Mijn tweede telefoon was een Jolla, dat IIRC weer een voortzetting was van de "echte" MeeGo. RPM based en ook daar terminal toegang incl mogelijkheid tot installeren RPMs. Durf dus te wedden dat je heden ten dagen op beide Docker gedraaid zou kunnen hebben. En de shell kon je vast ook wel aanpassen.

Prima dingen als je ze gewoon gebruikt voor hun core functionaliteiten (imo), als fileserver dus. Docker host moet je er niet van willen maken, virtualiseren ook niet. Allemaal te lomp, outdated en traag. Heb hem gewoon in gebruik als fileserver, op mijn docker host (VM) koppel ik dan gewoon via NFS de schijven van de NAS en dat werkt verder prima. Valt er een schijf uit, dan gaat de Syno software prima om met het herbouwen van het array. Meer doe ik er niet meer mee.

[deHakkelaar]

Ik ben helemaal tevreden met m'n Docker op een Syno NAS plus een aantal apps via de app store waaronder MariaDB als centrale dbase.
Tevreden op bash completion na
Omdat ik toch voor Docker een 24/7 apparaat nodig heb is die Syno NAS daar perfect geschikt voor.
Het is ook een wat zwaardere rack versie.

Voor VM's heb ik een oude Intel NUC met Xen ingericht.
Data via NFS naar de NAS en die NAS kan ook iSCSI LUN's adverteren naar m'n VM's.
Pruttelt ook als een zonnetje.

Voor produktie/enterprise zou ik een NAS niet met Docker inzetten maar alleen voor file sharing, iSCSI etc.
Misschien alleen MariaDB/Postgres omdat deze toch in de app store zit.

[Ghoulli]

Beste Allen,

Voorheen heb ik mijn eigen media server, Jellyfin, Sonarr, Radarr ,Qbit de hele rataplan, gedraaid op TrueNAS Scale en lekker alles met Truecharts geregeld. Nu is Truecharts ermee opgehouden met het supporten van de images op TrueNAS Scale en ben ik bezig met alles weer draaiend te krijgen op Docker m.b.v. Portainer als GUI (ben natuurlijk geen 'echte' techneut zo maar ja, boeie) aangezien ik een noob ben. Nu loop ik alleen tegen een probleem aan waar ik niet zo een antwoord op kan vinden.

Momenteel heb ik een QBittorrent container die als hoofdnetwerk de service van mijn Gluetun container heeft (torrenten zonder VPN doe ik liever niet). Hierdoor ben ik toegang tot de WebUI van Qbittorrent verloren. Ik zou graag een tweede NIC hebben o.i.d. zodat ik intern nog bij de WebUI kan. Ik heb al geprobeerd om het standaard bridge netwerk te joinen maar daarvan krijgt de QBit container geen IP-adres, dus kan ik daar ook niet bij. Ik heb ook geprobeerd om de poort 8080 op beide de Gluetun en de QBit container te openen maar dit heeft ook niet opgeleverd.

Iemand enig idee voor een oplossing? Als het ergens anders al uitgelegd staat dan zoek ik het natuurlijk graag uit maar ik kwam er via Google (en DuckDuckGo) niet uit.

[alex3305]

@Ghoulli Je geeft wel een accurate probleemomschrijving, maar het zou enorm helpen als je ook wat meer details zou geven. Bijvoorbeeld hoe je deployed en welk image / containers je gebruikt. In deze blogpost staan wat voorbeelden omtrent VPN en qBittorrent. Daar wordt echter gesproken dat je de poorten dus moet benaderen via de VPN container en niet meer via de qBittorrent container. Misschien gaat het daar mis of moet je daar nog expliciet poorten openen?

[Ghoulli]

@alex3305 bedankt voor je antwoord. Ik gebruik dezelfde twee images die gebruikt worden in de blogpost die jij stuurde, qBittorrent via Linuxserver en Gluetun van gmcgaw. Wel enigzins interessant, want ik meende al de juiste poorten (8080 voor de webui zover ik lees op de Linuxserver docker image page) open te hebben staan. Voor beide containers gebruik ik de nieuwste versie gepulled vanaf hub.docker.com. Misschien benader ik de pages wel fout?

Momenteel heb ik de qBittorrent alleen verbonden door de Gluetun container heen. Hierdoor heeft de qBittorrent container geen eigen adres meer in het netwerk (172.16.0.X subnet). Moet ik dan het IP-adres van de VPN container op poort 8080 benaderen of zou de qBittorrent container wel een ip-adres uit de netwerkreeks moeten hebben?

Misschien heeft dit ook meerwaarde: Ik gebruik momenteel de systeem eigen bridge als netwerk voor al mijn containers waardoor ik het ip-adres van mijn server (192.168.2.175) op de juiste poort benader voor de WebUI's. Het docker-eigen bridgenetwerk gebruikt een ander subnet (172.2.0.0/16 volgensmij) dan dat ik gebruik op mijn LAN (192.168.2.0/24). Zou ik dit gelijk moeten trekken door een aparte, eigen bridge netwerk aan te maken met als subnet bijvoorbeeld 192.168.2.208/28?

Links naar de exacte images die ik gebruik:
https://hub.docker.com/r/linuxserver/qbittorrent
https://hub.docker.com/r/qmcgaw/gluetun

[alex3305]

@Ghoulli Dat interne netwerk kun je (als het goed is) niet van buiten benaderen. Als je poorten exposed, zoals in dat blogpost, zou je die poorten op dat adres kunnen benaderen. Maar je geeft nog steeds weinig concrete informatie en ik hou niet zo van vissen . Deel bijvoorbeeld jouw Compose setup of screenshots van de deployment(s).

Moet ik dan het IP-adres van de VPN container op poort 8080 benaderen of zou de qBittorrent container wel een ip-adres uit de netwerkreeks moeten hebben?

Je zult dus qBittorrent moeten benaderen op 192.168.2.175 met poort 8080 mits je die ook als environment variable hebt meegegeven: WEBUI_PORT=8080 anders is het op poort 6011 denk ik.

Zou ik dit gelijk moeten trekken door een aparte, eigen bridge netwerk aan te maken met als subnet bijvoorbeeld 192.168.2.208/28?

Nee dan krijg je collissions. Docker maakt een eigen bridge netwerk aan met een eigen IP range. Dat is dan alleen voor de containers om naar buiten te verbinden. Zo zorgt Docker o.a. voor de scheiding tussen containers en hosts.

[Ghoulli]

Hoi @alex3305, sorry voor de verlate reactie maar ik moest werken. Om toch de juiste informatie door te geven dacht effe alle informatie verzamelen en doorsturen met wat screenshot. Ik ging een screenshot maken van de WebUI dat 'ie het dus niet deed met het web-adres. Je raadt het al, hij doet het. Ik heb niks anders gedaan dan de containers effe een restart gegeven (wat ik gisteren ook al tich keer gedaan heb...). Soms blijft het magie....

Ik wil je toch hartelijk bedanken voor de moeite. Je hebt andere vragen wel fijn voor me beantwoord bijvoorbeeld van het netwerk.

[alex3305]

Hey @Ghoulli GoT is geen verplichting. Het is ook geen tijd kritische operatie . Ik vind het vooral fijn dat het werkt. Alleen was het voor mij een beetje koffiedik kijken. Docker is Docker net zoals een auto een auto is. Vier wielen en een stuur, maar allemaal toch nét ff anders. En ik kan helaas niet zomaar meekijken . En wat voor jou dan super duidelijk is, hoeft dat aan de andere kant van de lijn helaas niet te zijn.

Maar wel interessant waarom het nu wel werkt. Misschien dat er toch iets in de volgorde zit wat belangrijk is? Bijvoorbeeld eerst de VPN container en dan de Torrent container? Of dat er toch nog iets in de cache van je browser zat? Wellicht ook nog iets om (voor de volgende keer) te testen.

[Ghoulli]

Ik heb het even uitbunding getest, ik had namelijk nog andere netwerk problemen die nu opgelost zijn, en het is inderdaad de volgorde van opstarten van de containers. Als ik de Gluetun container restart, of opstart nadat ik de qBittorrent container start, dan heeft de qBittorrent geen container om verkeer doorheen te routen. Hierdoor werkt natuurlijk de webinterface ook niet. Aangezien ik maandag vrij veel bezig ben geweest met het testen van de configuratie van de VPN is deze een aantal keer opnieuw opgestart terwijl de qBittorrent container up bleef .

[alex3305]

@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.

[Ghoulli]

@alex3305 Bedankt voor de tip. Is er een specifieke reden voor behalve dat het veel gebruikt word? Ik lees namelijk online wel vrij veel goede dingen over Portainer maar in de Linuxserver discord hebben ze het ook een soort afgunst van Portainer. Ik ben totaal niet tegen het gebruiken van Docker Compose, vooral niet nu dat ik pas net begonnen ben met het gebruiken van Docker en liever de 'goede manier' aanleer dan afhankelijk te worden van Portainer.

De hoofdreden waarom ik Portainer gebruik is omdat het makkelijk en snel inzichtelijk is wat de status is van de containers. Ik heb namelijk graag een dashboard beschikbaar om snel een inzichtelijke weergave te hebben van de status van dingen. Nu zien beide Dockge en Dokemon er wel erg goed uit in dat aspect.

[Hathi]

Je kan als je compose gebruikt natuurlijk alsnog ook gewoon een portainer container draaien voor het dashboard. Inrichten doe je dan via compose, maar daarnaast kan je de status van de containters etc. gewoon bekijken in een portainer dashboard.

[DjoeC]

Ghoulli schreef op woensdag 24 juli 2024 @ 10:36:
@alex3305 Bedankt voor de tip. Is er een specifieke reden voor behalve dat het veel gebruikt word? Ik lees namelijk online wel vrij veel goede dingen over Portainer maar in de Linuxserver discord hebben ze het ook een soort afgunst van Portainer. Ik ben totaal niet tegen het gebruiken van Docker Compose, vooral niet nu dat ik pas net begonnen ben met het gebruiken van Docker en liever de 'goede manier' aanleer dan afhankelijk te worden van Portainer.

De hoofdreden waarom ik Portainer gebruik is omdat het makkelijk en snel inzichtelijk is wat de status is van de containers. Ik heb namelijk graag een dashboard beschikbaar om snel een inzichtelijke weergave te hebben van de status van dingen. Nu zien beide Dockge en Dokemon er wel erg goed uit in dat aspect.

Ik ben dit jaar overgestapt van "alles" in portainer te definieeren naar gebruik van Docker compose (Raspberry Bookworm met OMV-7 daarover heen). Die combinatie werkt voor mij heel prettig en stukken beter dan meteen containers definieeren in Portainer. Wel heb ik portainer om makkelijk containers te bekijken, te starten en te stoppen en eventueel te updaten nadat Watchtower een nieuw image heeft binnengehaald - maar dat laatste werkt eigenlijk ook prima in OMV.

Qua netwerken heb ik eigenlijk maar 2 stuks: user_bridge waarmee containers onderling communiceren en waarop je poorten naar extern kunt open stellen en eventueel via NGINX Proxy Manager als (sub)domein kunt benaderen (zie ook een eerdere post in dit topic) en macvlan voor containers die ik een vast IP adres in het "normale" netwerk wil geven zoals pihole.

[alex3305]

Ghoulli schreef op woensdag 24 juli 2024 @ 10:36:
@alex3305 Bedankt voor de tip. Is er een specifieke reden voor behalve dat het veel gebruikt word?

Ja, precies vanwege het probleem wat jij hebt . Het is nogal irritant dat als ik 3 (losse) containers heb en ik reboot mijn server, dat ik dan container A eerst moet opstarten, dan B en dan C. Sterker nog, in een productieomgeving accepteert een klant dat niet. Want stel de server crasht, moet dan poppetje X die server handmatig gaan opstarten? Dat lijkt mij nogal irritant .

Met Compose kun je meerdere containers in één bestand componeren waardoor je ook koppelingen kunt plaatsen tussen containers. Daarbij kun je bijvoorbeeld ook netwerken en volumes definiëren zodat je een bestand hebt wat je eenvoudig kunt uitrollen op meerdere servers.

Ik lees namelijk online wel vrij veel goede dingen over Portainer maar in de Linuxserver discord hebben ze het ook een soort afgunst van Portainer. Ik ben totaal niet tegen het gebruiken van Docker Compose, vooral niet nu dat ik pas net begonnen ben met het gebruiken van Docker en liever de 'goede manier' aanleer dan afhankelijk te worden van Portainer.

Portainer is helemaal niet slecht. Maar de afgunst is 100% terecht. Het probleem dat Portainer geeft is dat Portainer net andere jargon hanteert dan dat Docker doet. Dat geeft soms wrijvingen, want wat bedoelt user X nu precies met een vraag? Daarnaast maakt Portainer het e.e.a. zo eenvoudig dat soms users totaal niet meer weten wat ze aan het doen zijn en daardoor problemen krijgen die kinderlijk eenvoudig op te lossen zijn.

Een mooi voorbeeld vond ik bijvoorbeeld een tijdje terug dat ze bij de Servarr Discord aangaven dat Portainer unsupported was. Daar werd een heel stuk in de FAQ over geschreven. Toen ik nieuwsgierig was waarom dit was gedaan, bleek dat dit kwam door een user die met zijn Synology (en aangepaste Docker install!) en Portainer een of ander rechten issue had omdat Synology niet standaard Linux users gebruikt. Tja dat zijn natuurlijk situaties die enorm kut zijn om te ondersteunen. Maar aan de andere kant is dat geen probleem van Portainer. Dat is een probleem van een systeem dat op 101 besturingssystemen draait met 2002 soorten smaakjes . Alleen omdat Portainer het 'zo makkelijk' had gemaakt wist deze user het probleem niet op te lossen en wist deze user ook niet wat permissies waren. Want hé in Windows is het ook allemaal een admin gebruiker .

De hoofdreden waarom ik Portainer gebruik is omdat het makkelijk en snel inzichtelijk is wat de status is van de containers. Ik heb namelijk graag een dashboard beschikbaar om snel een inzichtelijke weergave te hebben van de status van dingen. Nu zien beide Dockge en Dokemon er wel erg goed uit in dat aspect.

Voor zo'n overzicht is het echt . Maar ik heb ook het idee dat jij wil snappen waar je mee bezig bent en dan ben je lekker onderweg. Dat is ook waarom ik zei dat dit een mooie volgende stap is. Die hoef je niet nu te maken, niet morgen en ook niet volgende week. Maar wanneer jij er aan toe bent. En de Bittorrent + VPN container is direct een mooie usecase om dit uit te gaan proberen. Immers heb je namelijk een probleem wat je voor jezelf kunt oplossen. Dat is toch mooi?

Ik zelf gebruik Dockge omdat ik daar eenvoudig kan auto-updaten . Maar tegelijkertijd draait mijn Docker host Unraid en gebruik ik ook weleens het Unraid dashboard om mijn containers te bekijken. Een GUI hoeft niet verkeerd of vies te zijn, maar blijf vooral bewust bezig.

[Ghoulli]

Met Compose kun je meerdere containers in één bestand componeren waardoor je ook koppelingen kunt plaatsen tussen containers. Daarbij kun je bijvoorbeeld ook netwerken en volumes definiëren zodat je een bestand hebt wat je eenvoudig kunt uitrollen op meerdere servers.

@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.

je poorten naar extern kunt open stellen en eventueel via NGINX Proxy Manager als (sub)domein kunt benaderen (zie ook een eerdere post in dit topic) en macvlan voor containers die ik een vast IP adres in het "normale" netwerk wil geven zoals pihole.

@DjoeC Nu heb jij me meteen mooi in de richting geduwd over wat ik moet gaan doen voor mijn PiHole, ik was me net aan het bedenken hoe dat zou werken als ik dit zou willen draaien. Ik word een beetje moe van de reclames in apps

[DjoeC]

Ghoulli 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.


[...]


@DjoeC Nu heb jij me meteen mooi in de richting geduwd over wat ik moet gaan doen voor mijn PiHole, ik was me net aan het bedenken hoe dat zou werken als ik dit zou willen draaien. Ik word een beetje moe van de reclames in apps

Ik gebruik Docker compose (nog) niet om meerdere containers in 1 compose file te definieeren. Tot heden lijkt dat met afhankelijkheden (Mosquitto, MariaDB) nog goed te gaan. Ook Home-assistant die onder portainer na een reboot nooit goed opkwam doet dat nu wel. Mogelijk ligt dat aan de Healthchecks die in sommige compose files zitten.

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.

Enneh, ik ben zeker GEEN docker specialist maar heb geleerd van veel fouten over de afgelopen 1-2 jaar.

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 ;-)

[DjoeC]

alex3305 schreef op woensdag 24 juli 2024 @ 11:17:
[...]
Ik zelf gebruik Dockge omdat ik daar eenvoudig kan auto-updaten .

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?

[Freee!!]

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?

Met Watchtower (een autoupdate container) kan het in ieder geval met een label bij de betreffende container.

[lolgast]

Daarbij is het in mijn ogen bij database containers verstandig om niet met het label ‘latest’ te werken maar met een versienummer. Dan update je nooit zomaar ineens naar een nieuwe major versie.

[DjoeC]

lolgast schreef op woensdag 24 juli 2024 @ 15:05:
Daarbij is het in mijn ogen bij database containers verstandig om niet met het label ‘latest’ te werken maar met een versienummer. Dan update je nooit zomaar ineens naar een nieuwe major versie.

Ook dat heb ik dus geleerd In de huidige opzet gebruik ik vooral major en soms minor release nummers EN ik ben wat kritischer geworden bij updaten van belangrijke containers. Het hoeft niet altijd ook al kan het, toch eerst even releasenotes bekijken op breaking changes. Maar dingen als sabnzbd of spotweb, gaan die kapot dan: zij het zo.

[Freee!!]

DjoeC schreef op woensdag 24 juli 2024 @ 15:38:
[...]
Ook dat heb ik dus geleerd In de huidige opzet gebruik ik vooral major en soms minor release nummers EN ik ben wat kritischer geworden bij updaten van belangrijke containers. Het hoeft niet altijd ook al kan het, toch eerst even releasenotes bekijken op breaking changes. Maar dingen als sabnzbd of spotweb, gaan die kapot dan: zij het zo.

Ik heb twee RPi's met Docker en allebei draaien ze twee Pi-Holes, één op "last" en één op een vastgezette versie. De "last" worden automatisch bijgewerkt en als dat goed gaat, werk ik de andere twee handmatig (via Portainer) bij naar dezelfde versie.

[DjoeC]

Freee!! schreef op woensdag 24 juli 2024 @ 15:59:
[...]

Ik heb twee RPi's met Docker en allebei draaien ze twee Pi-Holes, één op "last" en één op een vastgezette versie. De "last" worden automatisch bijgewerkt en als dat goed gaat, werk ik de andere twee handmatig (via Portainer) bij naar dezelfde versie.

Interessant. Ik vraag me af of dat bijvoorbeeld bij MariaDB ook zinvol zou zijn? Wat daar een rol speelt is dat de "latest" in zo'n geval geen serieuze data zou krijgen als die niet (ook, eventueel duplicaat) gevoed wordt en dus ook geen symptomen kan vertonen.... Hmm, misschien als replica server.

Ik had 2x actieve Pihole containers op 2 Pi's maar dat werkte bij mij niet lekker. Zo'n 30% van de niet in cache webstes gaf 1x een not-found..... Moet er wel bijzeggen dat het de DNS servers van de Fritzbox waren en niet rechtstreeks van de clients. Dat heb ik nu met 1x pihole nog steeds om die app er in noodgevallen snel tussenuit te kunnen halen. DNS is best wel belangrijk....

In z'n algemeenheid wil ik me nog gaan verdiepen in Healthchecks en misschien op die basis de boel bewaken.

[Airw0lf]

Freee!! schreef op woensdag 24 juli 2024 @ 15:59:
[...]

Ik heb twee RPi's met Docker en allebei draaien ze twee Pi-Holes, één op "last" en één op een vastgezette versie. De "last" worden automatisch bijgewerkt en als dat goed gaat, werk ik de andere twee handmatig (via Portainer) bij naar dezelfde versie.

Mmm - zoiets kan je beter via de CLI doen.
Portainer heeft bij mij eens een container (d.w.z. swag) een beetje stuk gemaakt.
Wat rare af-en-toe problemen - kunnen herstellen via een CLI update actie.

[Freee!!]

Airw0lf schreef op woensdag 24 juli 2024 @ 22:41:
[...]
Mmm - zoiets kan je beter via de CLI doen.

In geval van nood kan en doe ik dat ook wel, maar gemak dient de mens.

Portainer heeft bij mij eens een container (d.w.z. swag) een beetje stuk gemaakt.
Wat rare af-en-toe problemen - kunnen herstellen via een CLI update actie.

De container waar ik de meeste problemen mee heb is Portainer. En ik heb drie scripts om problemen ermee op te lossen, waarbij de derde gewoon Portainer compleet verwijdert en herinstalleert.