LXC vs Docker - overstappen nuttig?

[mdbraber]

Hoi,

Sinds een paar maanden heb ik met veel plezier een homeserver opgezet met Proxmox en unprivileged LXC containers. De containers zijn allemaal voor een afzonderlijke toepassing (PiHole, CUPS, Sonarr, Radarr, Transmission, SMTP, TimeMachine etc)

Op de homeserver draait daarnaast 1 VM voor pfSense waar een DHCP server draait die de individuele hosts voorziet van een IP. Iedere host heeft dus een eigen IP / domeinnaam en met behulp van o.a. Caddy hoef ik geen portnummers te onthouden omdat alle hosts op 'normale' poorten, zoals 80 (http) en 443 (https) bereikbaar zijn waar mogelijk. Iedere hosts kan normale poorten gebruiken per host (zoals bijv. 53 bij Pihole). Dit omdat ik afzonderlijke hostnames wil (pihole.mdbraber.net) ipv iets als (homeserver:5353).

Qua resources wordt er op verschillende punten verwezen naar het feit dat Docker mogelijk minder resources gebruikt. Daarnaast is het (afhankelijk van hoe je het bekijkt) beter te managen door een single config file. Ik heb besloten me daarom eens te verdiepen of een 'overgang' naar Docker ipv LXC nuttig is.

Waar ik tegen aanloop is de networking stack van Docker die vooral lijkt te werken met een soort interne netwerken met bridged modus, dus als je niet macvlan wilt gebruiken). Het effect dat ik zie:

- Geen DHCP voor het uitdelen van IP adressen (maar gaat via Docker)
- Docker hosts zijn niet direct bereikbaar onder een eigen IP
- Omdat hosts geen eigen IP hebben niet makkelijk te integreren met interne DNS zodat ook externe clients ze kunnen bereiken.

Het lijkt dat alle problemen met verschillende scripts / hacks op te lossen zijn. Een andere optie is om Traefik te gebruiken voor de HTTP(S) routing - maar het nadeel is dat je dan in de problemen komt als je voor dezelfde hostname ook *niet* HTTP(S) verkeer wilt routen en het A record in de DNS verwijst naar Traefik... maar wellicht zie ik hier iets over het hoofd?

Kortom - het enige qua oplossing is Docker containers met de macvlan interface, waarbij het grotendeels lijkt op LXC containers met een andere manier van onderhoud (Dockerfile ipv via de shell). Bij LXC is het noodzakelijk het onderhoud goed te regelen met bijv. unattended-upgrades bij Debian wat meer werk kan zijn dan Docker.

Zijn er andere voordelen van Docker waarom dit te verkiezen kan zijn boven LXC? Iemand ervaringen met de overstap van de een naar de ander? So far kom ik tot de volgende afwegingen:

Docker
+ Manageable met Dockerfile
+ Lichter qua resources dan LXC
- Complexer om op te zetten (maken Dockerfile ipv installeren via shell)
- Complexere networking stack, tenzij gebruik van macvlan

LXC
+ Makkelijk / dynamisch te onderhouden via shell
+ Direct netwerk (gebruik DHCP, hostnames)
+ Beter isolatie host/container
- Iets zwaarder in resources dan Docker
- Meer onderhoud nodig (upgrades, Caddy)

Benieuwd naar jullie ervaringen!

P.S. ik tag @FireDrunk hier even omdat die volgens mij ooit aangaf in een ander topic veel met Docker te doen.

[FireDrunk]

Tja, het simpele antwoord is: Gebruik wat je het makkelijkst vindt. Als jij makkelijker werkt met LXC, vooral gebruiken, het verschil in resource gebruik is verwaarloosbaar. Het is vooral meer configuratie werk. LXC containers moet je bij houden, en updaten. Het process om een nieuwe te maken automatiseer je niet super makkelijk. Bij docker is het zo simpel als, flikker container weg, en bouw een nieuwe.

Even een aantal dingen op een rij:

Docker:

+ Manageable met Dockerfile

Klopt, en dit beaamt precies wat ik hierboven zeg. Je kunt vanaf scratch je complete configuratie maken. Waarbij je met LXC dus eerst je container moet maken, en daarna nog je applicatie moet installeren met iets van shell scripts ofzo (of Ansible, Salt of een ander Desired State Configuratie Management tooltje). Groot voordeel van Docker is dus de herhaalbaarheid. En de eenvoud om die herhaalbaarheid te bewerkstelligen.

+ Lichter qua resources dan LXC

Zou ik niet zo zwaar aan tillen. Volgens mij gebruikt LXC ook cgroups voor scheiding, dezelfde techniek als Docker. Verschil zit hem vooral in de netwerkstack dacht ik. Verder zitten er meer files in LXC containers, waardoor je wat grotere images hebt, dus misschien wel de grootste resource verliezen krijg je op disk niveau. Maar hoe duur is storage nou echt tegenwoordig...

- Complexer om op te zetten (maken Dockerfile ipv installeren via shell)

Dat ligt er dus maar aan wat je gewend bent. Ik kan blind Dockerfiles maken, en vind ze extreem simpel te begrijpen. Voor LXC daarentegen moet je zelf iets maken. Als je dat nu al hebt, is dat voor jou makkelijk, maar geen absoluut (en objectief) voordeel van LXC.

- Complexere networking stack, tenzij gebruik van macvlan

Netwerkstack is niet complex, het is juist simpel. By default share je het Host IP, en krijgt elke container een unieke poort. Het feit dat jij unieke IP's wil per service maakt het complex. Je kan prima al die diensten dus via 1 IP benaderen. De verschillende poorten landen gewoon in verschillende containers.

LXC

+ Makkelijk / dynamisch te onderhouden via shell

Objectief gezien dus niet mee eens. Je moet zelf Shell scripts maken om LXC te beheren, of terugvallen op extra tooling als Ansible, Salt, Puppet of Shell. Bij Docker zit het maken, opstarten, stoppen, verwijderen etc allemaal in 1 tool.

+ Direct netwerk (gebruik DHCP, hostnames)

DHCP is geen voordeel of nadeel, het is gewoon anders. Hostnames komen uit een tijd waar het belangrijk was om die dingen te scheiden. In de moderne wereld kan je dat prima oplossen met andere technieken. Waar traefik er 1 van is, maar absoluut niet verplicht.

+ Beter isolatie host/container

Dat is gewoon niet waar. LXC en Docker gebruiken beide cgroups, dus de process scheidingstechnieken zijn gewoon hetzelfde.

- Iets zwaarder in resources dan Docker

Mja, alleen op storage gebied dan, en misschien om dat er enkele processen meer draaien (zoals eventueel een SSH daemon).

- Meer onderhoud nodig (upgrades, Caddy)

En dat is misschien wel het grootste argument om eventueel Docker te gaan gebruiken. Het is klein, licht, simpel, en doeltreffend, daarom gebruikt de rest van de wereld het ook.

Stack Overflow heeft recentelijk nog een onderzoek gepubliceerd, waarin stond dat Docker op veel vlakken het meest gewilde en meest geliefde platform is.

Dat zegt wel iets

[Yarisken]

Mijn server thuis die 24/7 aanstaat gebruikte ik eerst esx, daarna proxmox en nu staat er gewoon centos 7 op en docker containers.
Het enige wat niet draait in docker is transmission omdat ik hier geen risico wilde nemen :-).

Ik gebruik voor al mijn containers docker-compose en dit werkt toch wel heel makkelijk. Wil ik een container opstarten is het snel docker-compose up -d en terug down is docker-compose down.
Niet meer een vm in webinterface opstarten en de vm voorzien van updates etc...
Ik gebruik wel aparte poorten voor elke container maar deze links staan in chrome opgeslagen dus dat is snel opgestart.

[mdbraber]

Dank @FireDrunk en @Yarisken voor jullie antwoorden. Ik heb afgelopen weekend een heleboel documentatie gelezen over LXC, Docker, Proxmox, VM en netwerken :-) Een interessante resource om bijv. met Docker een HA omgeving te creeeren kan je hier vinden: https://geek-cookbook.funkypenguin.co.nz

Ik heb op dit moment geen Ansible of andere DSCM tool voor het inrichten van mijn containers. Ik doe het meest eenmalig en handmatig. Dat betekent echter wel dat je een redelijke technical debt opbouwt over de tijd als je meerdere LXC containers moet onderhouden, SSH keys, upgrades - etc. Hoewel het prima mogelijk is voor een overzichtelijke setup, is het ook weer niet ideaal.

Tegelijker tijd heb ik geen HA / failover nodig voor mijn homelab, dus een Docker Swarm voor HA is niet direct nodig. Ik wil wel Proxmox houden omdat ik ook andere VMs draai (oa macOS en pfSense) en het een prettig idee is dat ik mijn containers / VMs makkelijk kan porteren naar andere systemen of kan backupen.

In de uitgebreidere setups heb je een boel extra lagen, o.a. voor shared storage (bijv. Ceph) en failover IP (bijv. keepalived) etc. die ik niet direct nodig heb.

Zoals ik het nu zie is het voor mij het efficiëntst om LXC containers (weinig overhead, directe I/O, meest flexibele resources) gebruiken waarbij ik op een LXC instance een (of meerdere) Docker Swarms kan draaien die vervolgens met een overlay netwerk verbonden worden. Docker is dus vnml. een tool om 'easy config' te bereiken waarbij ik de persistent data kan scheiden van de rest en makkelijk kan backup of meenemen. Daarnaast houd ik de mogelijkheid om ook evt. 'bare' LXC containers (zonder Docker) in de configuratie op te nemen.

[FireDrunk]

Als je al Docker gaat draaien, zou ik dat sowieso buiten LXC om doen. LXC gebruikt wat custom networking, welke niet perse goed zijn icm Docker. (Docker wil graag een bridge, LXC doet iets met veth netwerkkaarten).

Je voordelen van LXC zijn ook incorrect, Docker heeft niet meer overhead, en LXC heeft ook niet 'directere I/O', beide hebben een (dunne) virtualisatie laag er tussen zitten, en beide hebben 'flexibele' resources.

De grootste reden voor jou om voor LXC te gaan die ik zie, is dat je alles met het handje doet, en dat (blijkbaar) graag wil blijven doen. Docker vereist een automatiseert proces, in tegenstelling tot LXC, waar je inderdaad via SSH alles lekker zelf kan doen.

Het is maar hoe je zelf het liefst werkt. Je moet zelf blij zijn met de keuze, wij niet

[mdbraber]

@FireDrunk tnx voor je feedback! Wat ik niet duidelijk heb gemaakt in mijn vorige post is dat ik het vnml. heb over de voordeel van Docker op *LXC* vs Docker op *VM* - dus minder overhead, snellere I/O, meest flexibele resources). Niet het verschil tussen Docker en LXC.

Ik wil niets anders dan Proxmox op mijn base system hebben - zodat ik wel in staat ben om de resources te managen (hoeveel cores, geheugen en opslag ik toe ken aan een container of VM). So far zie ik dat het gewoon mogelijk is om Docker in een unprivileged LXC te draaien, maar ik nog een keer kijken of dat klopt en wat de netwerk overhead is.

[Kek]

Ik zelf draai Docker in een VM op proxmox, ook omdat ik docker niet direct op de proxmox install wil hebben.
Ik heb gekeken of dit ook in een LXC kon, maar in een VM is handiger, veiliger en voor mij bekender.

lees ook: https://forum.proxmox.com...r-in-lxc-container.45204/
en https://discuss.linuxcont...container-in-proxmox/3828

Edit:
bij nader inzien ga ik het nog eens bekijken, en achterhalen wat de voor en nadelen zijn.

[ Voor 42% gewijzigd door Kek op 20-05-2019 14:14 ]

[FireDrunk]

mdbraber schreef op maandag 20 mei 2019 @ 13:13:
@FireDrunk tnx voor je feedback! Wat ik niet duidelijk heb gemaakt in mijn vorige post is dat ik het vnml. heb over de voordeel van Docker op *LXC* vs Docker op *VM* - dus minder overhead, snellere I/O, meest flexibele resources). Niet het verschil tussen Docker en LXC.

Ik wil niets anders dan Proxmox op mijn base system hebben - zodat ik wel in staat ben om de resources te managen (hoeveel cores, geheugen en opslag ik toe ken aan een container of VM). So far zie ik dat het gewoon mogelijk is om Docker in een unprivileged LXC te draaien, maar ik nog een keer kijken of dat klopt en wat de netwerk overhead is.

Unprivileged LXC is natuurlijk best vies. Dat is gewoon alle rechten aan Docker geven.
Het enige voordeel dat je dan hebt is dat je geen 'package' verwatering hebt van je host OS.

Aan de andere kant is de hoeveelheid dependencies van Docker echt wel te behappen.
Ik zou me persoonlijk niet zo druk maken over die paar packages, maar dat is subjectief.

[mdbraber]

FireDrunk schreef op maandag 20 mei 2019 @ 14:21:
[...]

Unprivileged LXC is natuurlijk best vies. Dat is gewoon alle rechten aan Docker geven.
Het enige voordeel dat je dan hebt is dat je geen 'package' verwatering hebt van je host OS.

Kan het zijn dat je unprivileged en privileged door elkaar haalt? Unprivileged betekent juist dat je de rechten beperkt, terwijl het met privileged zo is dat je alle rechten hebt die je op de host ook zou hebben.

Aan de andere kant is de hoeveelheid dependencies van Docker echt wel te behappen.
Ik zou me persoonlijk niet zo druk maken over die paar packages, maar dat is subjectief.

Package 'verwatering' is niet echt een concern - wel het kunnen toekennen van resources, zou kan ik zorgen dat ik bijv. altijd een stuk geheugen vrij houd voor mjn andere VMs in plaats van dat Docker daar zonder limiet toegang toe heeft omdat het op de host draait.

[Kek]

FireDrunk schreef op maandag 20 mei 2019 @ 14:21:
[...]

Unprivileged LXC

Priveleged bedoel je denk ik

[FireDrunk]

Ja sorry, ik was in de war inderdaad.
@mdbraber Je kan (in) Docker prima limieten meegeven.

[mdbraber]

@FireDrunk tnx voor de tip over limieten. Je hebt helemaal gelijk - het is gewoon gelijk aan LXC containers qua CPU / memory resources. Dat maakt ook dat ik nog eens heroverweeg of het niet gewoon goed is qua performance en energy management om Docker op de (Proxmox) host te draaien - waar Docker in principe een serie van containers is (zoals ik dat nu heb met LXC).

Het vergrote risico dat ik zie is het concept van Docker daemon als root: https://docs.docker.com/e...ker-daemon-attack-surface - dat voornamelijk te maken heeft met de eigen hygiene (geen volume mounts van het root filesystem etc). Ik heb nu een test setup waar ik het in een aparte VM draai, wat op zich prima werkt, maar ik het qua energy management nog 'jammer' vind dat ik daar een extra laag voor maak, terwijl ik het idee heb dat qua security er weinig extra benefits zijn...

[FireDrunk]

Docker draait zelf onder root om andere containers rechten te geven. LXC doet dit exact hetzelfde.
LXC privileged containers zijn hetzelfde als Docker Privileged containers die als root draaien.

Qua security leunt Docker gewoon op Cgroups, evenals LXC.

Enige uitzondering op het security model is het builden van containers. Dat moet helaas (nog) onder root.
Maar met de nieuwe buildx engine van Docker zit rootless bouwen er wel aan te komen.

[mdbraber]

Helemaal ben ik er nog niet uit - maar qua efficiency ben ik er wel uit dat ik voor Docker (bare metal) naast Proxmox ga. Wat ik nog probeer te begrijpen is wat de best practices zijn qua Docker security. In LXC draaide ik alles in unprivileged containers en dat lijkt me hier ook het beste (https://docs.docker.com/engine/security/userns-remap/) - zijn er hier mensen die tips hebben voor goede security practices in het runnen van Docker (Swarm) services? @FireDrunk

[Zjemm]

ook goed om rekening mee te houden is dat met docker je allerhande linux os-en en versies gaat draaien. waar je met LXC hoogstwaarschijnlijk 1 base image gebruikt (bv ubuntu of debian)

ik zit zelf ook te dubben om op docker (eigenlijk podman) over te stappen, maar ik vind het juist wel fijn dat ik nu alles op debian heb draaien.

en als je die lijn gaat door trekken naar docker, kom het er al gauw op neer (denk ik) dat je zelf docker images moet maken.
dus bijvoorbeeld debian base image, met daarop x applicatie/config

maar dan ben je dus weer alles zelf aan het doen, en is het voordeel tov lxc ook weer weg lijkt me

of niet?

[janvv]

Twee jaar na dato, maar toch nog een interessante discussie, omdat ik me hetzelfde zat af te vragen.
Eigenlijk omdat ik mijn proxmox server ga upgraden van 6 naar 7, en dat moment gebruik om een en ander helemaal opnieuw te configureren.
Ik zie ook wel het fijne van aparte LXC's per service. Ik gebruik Ansible om de LXC container te maken, en ook om vervolgens de betreffende service te installeren en configureren. Dat is dus een kwestie van de playbooks runnen. Weinig handmatig werk, en elke service heeft zijn eigen dedicated OS en ip adres.
Ik heb ook wel met Docker dingen gedaan, maar dan gebruik ik daarvoor een VM als Docker host. Dat is een extra laag, maar daar heb ik niet zoveel last van. Het voordeel is dat ik nu gewoon die VM backuppen kan, en straks in Proxmox 7 weer terugzetten. Via Traefik kun je al die Docker containers wel een eigen DNS naam geven, maar het ip adres wijst naar Traefik, dat vind ik onhandig.

Wat mij betreft run ik geen Docker NAAST proxmox. Dat voelt gewoon niet goed.

Het wordt als nadeel aangegeven dat je zelf die LXC's up to date moet houden. Dat kun je natuurlijk automatiseren met een cron jobje, maar je kunt het ook gewoon achterwege laten. Waarom moet ik mijn Plex service op de laatste versie van een OS draaien? Als het goed draait, dan heb ik eerder de neiging om er daarna af te blijven.

Mijn Homelab server heeft een 24 core cpu met 64Gb ram. Daar kan ik heel wat LXC's op draaien voordat er rook en stoom uit komt....

[amx]

Docker niet naast LXC willen draaien is een door jezelf opgelegde beperking. Dat het gevoelsmatig niet klopt, betekent niet dat je het jezelf moeilijker maakt.

Dat gezegd hebbende: LXC heeft een lagere learning curve als je al gewend bent een Linux server te beheren. Je behoudt ook meer controle over wat je installeert en hoe je het configureert.Als je een setting wil wijzigen in een container, is dat zeer eenvoudig. Wil je die setting op alle containers toepassen, ben je afhankelijk van of dat via LXC eenvoudig gaat. Je kan een profiel aanmaken met bepaalde settings, bijvoorbeeld om macvlans te gebruiken. Ga je veel containers gebruiken en regelmatig wijzigingen doen, moet je inderdaad al een configuration management oplossing gaan gebruiken, wil je veel terugkerend werk voorkomen. Updates kun je eenvoudig via cronjobs per container instellen.

Docker is vind ik persoonlijk lastig te leren als je via youtube de handleidingen volgt. Daarnaast betekent Docker voor mij Docker Compose. Met het materiaal op Youtube of van die handleidingen om iets te installeren kwam ik nooit echt wijs uit. Wat me in letterlijk 1 dag van onwetend naar redelijk bedreven heeft gemaakt, is de cursus Docker Compose in depth, van Stone River eLearning. Ten tijde van schrijven voor €13,99 op Udemy te krijgen. Sindsdien heb ik meerdere compose files aangemaakt en snap nu ook redelijk waarom iets wel of niet werkt in een compose file. Zodra je dit snapt, is het inderdaad retesimpel om een container aan te maken. De schaalbaarheid van Docker is ongekend en ook het verwijderen en opnieuw aanmaken is letterlijk een enkele regel op de command line door 2 commando's achter elkaar uit te voeren. Mijn belangrijkste twijfel bij Docker, is dat je feitelijk een soort curl doet naar een install script dat iemand anders in elkaar heeft gestoken. En dan bedoel ik niet hetzelfde als een package manager, waar wel enige controle is op wat wel of niet kan worden geinstalleerd. Net als Github of, erger , pip of npm, is er eigenlijk geen controle op wat er wordt aangeboden. Daardoor is het toch weer een black box waar je niet direct kan zien wat er zich afspeelt tenzij je redelijke Docker skills hebt. Wat dan weer tegenstrijdig is met de eenvoud van de yaml file.

Ik zie daarom Docker als meer een means to an end dan LXC. LXC voelt als een beheergebied dat extra veiligheid biedt en voorkomt dat dependencies elkaar gaan bijten. Docker is een methode om heel snel je applicatie draaiend te hebben zonder de beheerlast.

[Krilo_89]

Nog een jaar later is dit nog steeds wel actueel .

@FireDrunk, hoe heb je Docker en Proxmox draaien? Zit dit naast elkaar of staat Docker in proxmox?

LXC's zag ik voorbij komen en deze persoon heeft eigenlijk alle containers met oneliners op github staan: https://github.com/tteck/Proxmox
Daarmee zou ik prima uit de voeten kunnen. Maarr.. ik ben software engineer en werk dus ook met docker. Wellicht niet met zeer uitgebreide compose files, maar puur voor mijzelf is het dan verstandiger om volledig me Docker containers te gaan werken en niet met LXC containers, omdat ik dat nooit buiten een hobby om zou gebruiken.
Jij geeft aan dat je geen Docker in een LXC wilt installeren, is die mening er nog steeds? Zou je persoonlijk gewoon 2 vm's draaien op Proxmox; een voor Homeassistant en een voor Docker, waar ik dan allerlei andere tools in kan draaien en managen (dat lijkt mij namelijk ook het grootste voordeel ten opzichte van losse lxc containers).

@Kek en @amx , welke kant zijn jullie uiteindelijk opgegaan met dit issue?

[amx]

Vrijwel hetzelfde.

Snap dat containervirtualisatie neerkomt op een unix socket. Docker is daarnaast multiplatform en vind ik nog steeds niet transparant in wat het doet.

Alternatief is er trouwens ook: systemd-nspawn van Leonard Poetting. Vanuit die Unix socket gedachte blijft het host systeem belangrijk aangezien, vrij vertaald, de container een systemd unit is die een container aanmaakt en waar systemd de communicatie met de socket afhandelt. Het zit afhankelijk van je perspectief net tussen LXD en Docker in.

[amx]

FireDrunk schreef op maandag 20 mei 2019 @ 11:55:
Als je al Docker gaat draaien, zou ik dat sowieso buiten LXC om doen. LXC gebruikt wat custom networking, welke niet perse goed zijn icm Docker. (Docker wil graag een bridge, LXC doet iets met veth netwerkkaarten).

Je voordelen van LXC zijn ook incorrect, Docker heeft niet meer overhead, en LXC heeft ook niet 'directere I/O', beide hebben een (dunne) virtualisatie laag er tussen zitten, en beide hebben 'flexibele' resources.

De grootste reden voor jou om voor LXC te gaan die ik zie, is dat je alles met het handje doet, en dat (blijkbaar) graag wil blijven doen. Docker vereist een automatiseert proces, in tegenstelling tot LXC, waar je inderdaad via SSH alles lekker zelf kan doen.

Het is maar hoe je zelf het liefst werkt. Je moet zelf blij zijn met de keuze, wij niet

Nog even: SSH maakt gebruik van een netwerk socket. Vanaf de host kun je makkelijk met de unix socket communiceren middels "lxc exec". Ook bij docker doe je dit middels een "docker exec -it"

[FireDrunk]

Krilo_89 schreef op woensdag 29 juni 2022 @ 23:28:
Nog een jaar later is dit nog steeds wel actueel .

@FireDrunk, hoe heb je Docker en Proxmox draaien? Zit dit naast elkaar of staat Docker in proxmox?

LXC's zag ik voorbij komen en deze persoon heeft eigenlijk alle containers met oneliners op github staan: https://github.com/tteck/Proxmox
Daarmee zou ik prima uit de voeten kunnen. Maarr.. ik ben software engineer en werk dus ook met docker. Wellicht niet met zeer uitgebreide compose files, maar puur voor mijzelf is het dan verstandiger om volledig me Docker containers te gaan werken en niet met LXC containers, omdat ik dat nooit buiten een hobby om zou gebruiken.
Jij geeft aan dat je geen Docker in een LXC wilt installeren, is die mening er nog steeds? Zou je persoonlijk gewoon 2 vm's draaien op Proxmox; een voor Homeassistant en een voor Docker, waar ik dan allerlei andere tools in kan draaien en managen (dat lijkt mij namelijk ook het grootste voordeel ten opzichte van losse lxc containers).

@Kek en @amx , welke kant zijn jullie uiteindelijk opgegaan met dit issue?

Al heel lang niet meer. Ik draai Debian met daarop Docker. Vrijwel alle services die ik er op draai heb ik via Docker Swarm Stacks draaien.
Enige uitzonderingen zijn Netdata (monitoring), mail daemon (dient als smarthost voor mijn printer), NFS, en Samba.

Ik kan gerust een keer mijn Composefiles delen, maar dan moet ik ze denk ik wat opschonen.

Momenteel heb ik als services:
- Radarr
- Sonarr
- Transmission
- Sabnzbd
- HomeAssistant
- Plex
- MQTT server (tbv HA)
- Spotweb (+db)
- Traefik

[Krilo_89]

FireDrunk schreef op maandag 4 juli 2022 @ 16:34:
[...]

Al heel lang niet meer. Ik draai Debian met daarop Docker. Vrijwel alle services die ik er op draai heb ik via Docker Swarm Stacks draaien.
Enige uitzonderingen zijn Netdata (monitoring), mail daemon (dient als smarthost voor mijn printer), NFS, en Samba.

Ik kan gerust een keer mijn Composefiles delen, maar dan moet ik ze denk ik wat opschonen.

Momenteel heb ik als services:
- Radarr
- Sonarr
- Transmission
- Sabnzbd
- HomeAssistant
- Plex
- MQTT server (tbv HA)
- Spotweb (+db)
- Traefik

Ah okey! En de reden dat je geen Proxmox meer hebt, is omdat je eigenlijk alles af kan doen met Docker?
De reden dat ik nu voor Proxmox gekozen heb is vanwege de Supervised Hass, maar dat doe jij ook anders begrijp ik.

Voor nu twijfel ik alleen of ik simpel LXC containers ga draaien: https://github.com/tteck/Proxmox en misschien helemaal geen Docker. Of wel Docker maar dan ook in een LXC container (why not?).
Ik zie nu nog niet helemaal in waarom ik bijv. de Unifi controller in een LXC container zou draaien of in Docker (en docker in een Debian 11 VM of bijv. ook een LXC).
-edit-
Ik ben nog startende en heb nog geen externe tools draaien, maar wil dat wel gaan doen. Als iets een keer omvalt (door eigen gepiel) maakt me dat ook nog niet zoveel uit. Ik wil gewoon wat dingen kunnen experimenteren en voornamelijk dat als ik even geen tijd heb, het wel blijft draaien (dus stabiel).

Docker heeft puur mijn voorkeur boven LXC omdat ik als Software engineer meer met Docker doe. Al heb ik geen ervaring met Docker Swarm Stacks, maar opzich kan het geen kwaad om hier wat meer over te leren.

[ Voor 17% gewijzigd door Krilo_89 op 04-07-2022 18:26 ]

[Lethalis]

En hoe maken jullie backups van Docker? Ik heb momenteel alle Docker rommel op een btrfs volume draaien en maak met een script snapshots, waar ik vervolgens weer tar.gz archives van maak. Services die ik niet vertrouw qua consistentie worden tijdelijk gestopt voor de snapshot.

Al met al denk ik juist erover na om LXC op Proxmox te gebruiken, vanwege de geïntegreerde backup oplossing ipv mijn zelfbouw.

Natuurlijk zou je ook de volledige Docker host als VM kunnen backuppen, maar ik ben dus bang dat bepaalde diensten die bijvoorbeeld sqlite gebruiken hun data niet netjes opslaan en de standaard fsfreeze dan het "de stekker er uitgetrokken" effect geeft.

Deel ik het op in losse LXC containers, kan ik in Proxmox zelf kiezen wat ik met elke container doe. Sommige hebben genoeg aan een shapshot backup, andere zal ik tijdelijk laten stoppen. Maar het is juist dit beheeraspect dat mij richting Proxmox en LXC trekt

PS
Dit is overigens op mijn werk, als accidental systeembeheerder (ik ben software developer, maar doe wat beheertaken ernaast... bij gebrek aan een systeembeheerder backups bezorgen mij regelmatig hoofdpijn en hoe meer ik kant en klare tools daarvoor gebruik, hoe beter denk ik). Ik zit ook te kijken naar Proxmox Backup Server.

PPS
De meeste applicaties die we zelf hebben ontwikkeld kunnen op zich prima in Docker blijven, maar database servers e.d. wil ik dus liever in LXC (denk ik).

[ Voor 20% gewijzigd door Lethalis op 18-07-2022 17:53 ]

[FireDrunk]

@Krilo_89 Ja, ik kan alles af met Docker en/of tools op de host.

@Lethalis
Ik share alle data die mijn Containers gebruiken terug naar mijn Host systeem. Die wordt daar op een ZFS Pool van SSD's gezet, welke in een automatisch snapshot rooster zit.

Het probleem dat containers niet met echte 'fsfreeze' werken, is in Docker en LXC exact even groot, dus dat zou geen reden moeten zijn om voor 1 van beide te kiezen.
De meeste Database systemen ondersteunen via SQL commando's (mits je als admin user inlogt), een freeze en flush van de database. Als je die draait voordat je een snapshot maakt, heb je gegarandeerd een consistente backup.

Andere kant van het verhaal is, een thuis databaseje is natuurlijk nooit zo druk als een enterprise database.
Stel je database doet 1 query per minuut van 25ms, dan is hij dus bezig 1/40e van de tijd. En precies op dat moment moet de stroom er af vallen.

Het wordt pas eng als de database echt druk is, tot die tijd is de kans dat je een query hebt die daadwerkelijk corruptie veroorzaakt echt heul heul klein (,maar niet nul).

Databases in Docker kan technisch gezien prima, maar ik zal niet ontkennen dat het niet de beste match is.
Als je er rekening mee houdt zal het voor thuisgebruik prima zijn.

[ Voor 11% gewijzigd door FireDrunk op 20-07-2022 10:01 ]

[Accretion]

Wel een goede discussie.

Met LXC lijk je meer een omgeving in een container op te bouwen, waar je bij docker een applicatie op zichzelf in een container doet (en daar naast zet). Functioneel lijkt het dus een beetje app vs environment; alhoewel ze technisch hetzelfde inhouden.

Het opzetten van een LXC container lijkt meer op hoe je een VM opzet, bij Docker kun je iets vergelijkbaars doen in een 'Dockerfile', maar veelal met een compose.yml kun je kant&klaar dingen inladen.

Het updaten van een LXC container kan direct in de container zelf, bij Docker flikker je de omgeving weg en pak je een geupdate omgeving. Dat eerste klinkt fijn, maar het tweede zorgt wel voor consistentie en dat je makkelijk ook een versie terug kan; maar soms ben je afhankelijk van andere voor updates?

Of updates wel/niet automatisch gaan, hangt af van de toolset die je gebruikt. Proxmox heeft heel wat tools, maar ook voor docker is genoeg te vinden zoals Portainer of Kubernetes.

Een backup van een docker container kan efficient door enkel de 'persistent storage' te backuppen. Bij LXC kun je 'makkelijker' de gehele container backuppen.
Voor beide geldt eigenlijk dat je voor een fatsoenlijke backup eigenlijk afhankelijk bent van iets externs (cloud opslag of off-site NAS)?

[Leaplasher]

Interessant topic. Heb 't gelezen en ook wat links doorgenomen.
Zou best wel eens willen pielen met LXC.
Echter waar ik niet achter ben is hoe ik de commando's die ik nu op docker afvuur richting LXC kan sturen.

Voorbeeld van Portainer, deze ga ik dan uiteraard niet in LXC stoppen, omdat ik daar de Proxmox UI voor heb:

code:

docker run -d -p 9000:9000  -v /var/run/docker.sock:/var/run/docker.sock -v /dockervolumes/portainer_data:/data -v /etc/timezone:/etc/timezone:ro -v /etc/localtime:/etc/localtime:ro --restart always portainer/portainer-ce:latest

Wat is een vergelijkbare syntax voor LXC?

[icecreamfarmer]

Afgelopen zaterdag bezig geweest om dit werkend te krijgen via dockercompose op openmediavault:
https://github.com/boredazfcuk/docker-icloudpd
of deze
https://github.com/AirswitchAsa/icloudpd-web

Na 6 uur had ik het draaien en wist ik eindelijk waar ik de config files kon editen.
Kon echter nog steeds niet inloggen dus toen maar een ubuntu lxc gemaakt en na wat gekloot met python versies had ik het in een uur werkend.

Alle youtube tutorials lijken niet op wat ik nodig had daar is het altijd even klikken en 2 dingen in de config aanpassen en gaan. En ondanks dat ik een gruwelijke hekel heb aan CLI is dat voor mij vele malen makkelijker dan een docker opstarten en configureren.

Dit was al de derde keer dat ik iets simpels probeerde met docker en het maar opgegeven heb.

[icecreamfarmer]

Leaplasher schreef op vrijdag 25 april 2025 @ 08:13:
Interessant topic. Heb 't gelezen en ook wat links doorgenomen.
Zou best wel eens willen pielen met LXC.
Echter waar ik niet achter ben is hoe ik de commando's die ik nu op docker afvuur richting LXC kan sturen.

Voorbeeld van Portainer, deze ga ik dan uiteraard niet in LXC stoppen, omdat ik daar de Proxmox UI voor heb:

code:

docker run -d -p 9000:9000  -v /var/run/docker.sock:/var/run/docker.sock -v /dockervolumes/portainer_data:/data -v /etc/timezone:/etc/timezone:ro -v /etc/localtime:/etc/localtime:ro --restart always portainer/portainer-ce:latest

Wat is een vergelijkbare syntax voor LXC?

Je opent de shell van de betreffende lxc.