Canonical neemt containerbeheertool LXD over en maakt het geen snap-exclusive

Ubuntu-ontwikkelaar Canonical heeft het LXD Project officieel overgenomen. Het project is opgericht door Canonical en werd al door Ubuntu ondersteund, maar was tot nu toe geen officieel onderdeel van het bedrijf.

Canonical schrijft in een nieuwsbrief dat het vindt dat het LXD Project beter af is als het direct onderdeel wordt van het bedrijf zelf. Zo zou het project beter schaalbaar zijn en zichtbaarder binnen de community. Canonical zegt onder andere de documentatie voor de tool te willen verbeteren.

Volgens Canonical verandert er in de praktijk niets voor de Linux Container Daemon. Wel betekent het dat de originele ontwikkelaars stoppen met het project en dat Canonical de ontwikkeling verder oppakt. Die ontwikkelaars zouden de beslissing 'jammer, maar begrijpelijk' vinden. Verder worden de GitHub-repo, de website en het YouTube-kanaal overgedragen aan Canonical.

De Apache 2-licentie blijft ook hetzelfde, schrijft Canonical in een faq. De tool blijft volgens het bedrijf gratis en als opensourcesoftware beschikbaar. Canonical zegt verder dat LXD ook onafhankelijk van Ubuntu beschikbaar blijft en niet exclusief als snap-package wordt aangeboden. Dat is volgens het bedrijf 'wel de makkelijkste installatiemethode', maar alternatieve downloadmethodes blijven volgens het bedrijf gewoon beschikbaar.

Canonical zette LXD, wat staat voor Linux Containers Daemon, acht jaar geleden op als een managementtool voor containers in Ubuntu. Hoewel het bedrijf zelf altijd de grootste bijdrage heeft geleverd aan de ontwikkeling ervan, was het officieel nooit van Canonical zelf.

Reacties (57)

[DaanHetEendje]

Wel betekent het dat de originele ontwikkelaars stoppen met het project en dat Canonical de ontwikkeling verder oppakt.

Dat is erg jammer om te horen. stgraber en tomponline kennen de code binnenste buiten. Bug reports hebben regelmatig uitgebreide comment met een PR binnen één uur. Het zijn super vriendelijke mensen die al jaren hun hart en ziel in het product stoppen. Ze bieden ook zeer goede support op de disquss fora.

LXD begon als simpelere frontend voor LXC. (LXC on acid.. LSD.. LXD.. )
Maar ondertussen is het uitgebreid tot een volwassen hypervisor en draai ik hier al jaren al mijn LXC en VMs mee. Een stuk makkelijker en netter te configureren dan bijv een proxmox. Ondertussen rijker in feature set en simpelweg een verademing.

[pvdspoel]

Het blijkt dat stgraber (die in dienst was van Canonical) ontslag heeft genomen en volledig stopt met LXD ondersteuning. Dat was de aanleiding voor Canonical om dan maar het hele project binnenboord te halen
https://stgraber.org/2023/07/10/time-to-move-on/

[DaanHetEendje]

Ah. Daar druipt het zuur van af..

Met het kwijtraken van je project lead is dit vanuit Caconicals opzicht geen gekke stap.

Bedankt voor de link!

[TumTum]

Erg jammer. Ik gebruik LXD al jaren op al mijn servers met ZFS. Heb veel getest en contact met ze gehad. Zal dit toch een soort van gaan missen. Ben ook bang dat het zonder stgraber gaat instorten. Komende tijd even goed in de gaten houden.

[rbr320]

Een stuk makkelijker en netter te configureren dan bijv een proxmox.

Ik heb geen ervaring met LXD maar inmiddels wel met Proxmox en vindt dat al een verademing ten opzichte van bijvoorbeeld VMware. Kan je eens onderbouwen wat LXD zoveel beter/netter maakt dan Proxmox?

[analog_]

Google zelf eens, overtuig jezelf.

[Vaudtje]

Ik vind het geen hele rare vraag en je opmerking onnodig afwijzend, aangezien Proxmox voor de containers gewoon LXD gebruikt en een handige user interface biedt.
En de persoonlijke mening van DaanHetEendje waar naar gevraagd werd is niet te DuckDG'en.

Wat ik me kan voorstellen, is dat je soms niet de overhead van Proxmox wil hebben, of dat je je erdoor beperkt voelt (Proxmox heeft bijvoorbeeld zijn eigen kernels, dus als je iets specifieks wil dat daar niet in zit, wordt alles moeilijk).

[Reactie gewijzigd door Vaudtje op 22 juli 2024 21:38]

[rbr320]

Kleine correctie: Proxmox gebruikt voor containers onder water LXC (LinuX Containers) en heeft daar zijn eigen tooling omheen in hun webGUI en op de command-line. LXD is een alternatieve manier van LXC beheren en tegenwoordig ook KVM-Qemu virtuele machines. In die zin zijn Proxmox en LXD dus concurrenten van elkaar die onder water dezelfde technologieën gebruiken.

De overhead van Proxmox is echt minimaal, het is een webservice maar dat gebruikt nauwelijks nog resources op moderne hardware. Het lijkt me dus niet dat @DaanHetEendje daar over valt, maar misschien heb ik het mis. Proxmox is verder gewoon Debian maar met een nieuwere kernel, waar ze de standaard Ubuntu kernels voor gebruiken. LXD was, zoals in dit nieuwsbericht naar voren komt, altijd al een project van Canonical en zal met deze verandering alleen nog maar nauwer verbonden raken met Ubuntu. Ik kan dus niets bedenken dat in Proxmox niet beschikbaar zou zijn via de kernel wat je wel hebt als je Ubuntu met LXD gebruikt. Nogmaals, ik ben nog steeds benieuwd naar @DaanHetEendje zijn visie op het geheel

[rbr320]

Dat heb ik uiteraard gedaan maar alle sites met vergelijkingen en pro/con lijstjes hebben mij er nog niet van kunnen overtuigen dat LXD "beter" is dan Proxmox, nog afgezien van dat beter behoorlijk subjectief is. Vandaar dat ik wel benieuwd was naar de mening van een ervaringsdeskundige en ook naar zijn definitie van "netter" in deze context.

[Verwijderd]

Is dit iets soortgelijks als docker? Wat is er beter /anders?

[Feni]

Het is een vorm van virtualisatie waarbij de container de kernel deelt met het host platform, maar geen volledige virtualisatie is. Dat biedt voordelen in gebruik van resources, maar kent ook beperkingen. Zo dient de LXC container passend bij de host kernel te zijn. Virtualisatie-light dus op OS-level. Docker is app-level virtualisatie. Grotendeels kwestie van voorkeur.

[Reactie gewijzigd door Feni op 22 juli 2024 21:38]

[icecreamfarmer]

Ja en dat is belangrijk om te weten want ik heb op proxmox nu mijn LXC;'s gemaakt met Ubuntu terwijl ik eigenlijk debian had moeten gebruiken.

Nu is er wel wat efficiëntie maar niet zo veel als nodig.

[d3burt]

I draai al jaren Ubuntu LXC containers in proxmox. Nooit iets gemerkt qua performance of betrouwbaarheid, alles is rock solid.

[icecreamfarmer]

Als ze zoveel mogelijk moeten delen qua kern zou Debian logischer zijn. Ik laat het zelf no ook nog zo draaien.

[Dorank]

In de container gebruik je aspecten van de kernel van de host. Er zijn maar zeer weinig userland utils die incompatible zijn met verschillende kernels, het enige wat ik me kan herinneren waar ik ooit ben tegenaangelopen was (g)libc in een ver verleden (bij kernel updates op bare metal).

[HollowGamer]

Volgens Canonical zelf is het meer te vergelijken met een VM: https://ubuntu.com/blog/lxd-vs-docker
Wat een beetje vaag is, want Arch Linux geeft aan dat het ook gebruikt kan worden voor LXC. Volgens mij is LXC/LXD meer gericht op meerdere OS-containers draaien op één machine, en Docker/Podman meer voor applicaties draaien in een container.

Persoonlijk heb ik er geen ervaring ermee, en blijf ik tegenwoordig weg bij tech. van Canonical. Niemand gebruikt/wil Snap, niemand gebruikt Mir, niemand gebruikte Upstart buiten hunzelf, niemand gebruikte Unity, ..

Red Hat en Oracle zijn misschien controversieel, maar ze doen wel bijdragen aan tech. die vrijwel iedereen gebruikt of wil gebruiken. Het verbaast mij echt nog dat Canonical nog bestaat, want alles wat ze aanraken, stort uiteindelijk in elkaar. Ze zijn een beetje als Google, hun basis product blijft, maar voor de rest heb je nooit zekerheid hoelang ze het ondersteunen.

Ik zie meer in Podman en Docker. Het zijn dan geen VMs, maar bij Podman hoef je niets in root te draaien, wat wel weer zo te zien geld voor LXD. Verder zijn (docker) containers heel flexibel en kan je die ook op productie prima draaien. Je hoeft ook niet Docker Hub te gebruiken, er zijn ook andere registry. Belangrijkste punt: LXD is Linux only. Als je het op macOS of Windows zou willen draaien, dan gaat dit bijvoorbeeld niet. Bij Docker is dit juist handig, zo kan je bijvoorbeeld prima applicaties delen met willekeurig elk OS als developer, zolang die maar de Docker-engine draaien.

[zenlord]

Ik zie meer in Podman en Docker. Het zijn dan geen VMs, maar bij Podman hoef je niets in root te draaien, wat wel weer zo te zien geld voor LXD. Verder zijn (docker) containers heel flexibel en kan je die ook op productie prima draaien.

LXD moet geinstalleerd en geconfigureerd worden door root en er draait een systemd service, maar de instances zijn standaard root-less en je kan LXD configureren in een cluster-setup. Als je geen service wilt opstarten, kan je ook low-level LXC gaan gebruiken om een (root-less, dan wel root-full) instance te maken en op te starten.
Ik ben er net zelf mee beginnen experimenteren (op Debian Bookworm) en ik heb er goede hoop op dat dit de juiste keuze is om applicaties te compartimenteren op mijn servers: Exim4 + Dovecot + Apache + Roundcube + Spamassassin + ... (alle benodigdheden voor een mailserver)

[HollowGamer]

Maar waarom zou je er voor kiezen? Hebben Docker/app containers niet gewoon zoveel voordelen?

Als eerste zijn voor de meeste images beschikbaar, en met iets als Docker-compose kan je deze relatief eenvoudig aan elkaar knopen (of juist niet). Verder delen ze de hardware anders, kan mij vergissen, maar bij LXD is het toch gewoon echt de core die wordt aangesproken i.p.v. virtueel?

[Verwijderd]

Voor 9/10 dingen zou je inderdaad gewoon Docker containers kiezen. Zeker als je professioneel ook iets met containerization doet ga je LXC niet tegenkomen, enkel Kubernetes/Docker. LXC is helemaal niet portable en Docker images zijn ook een stuk dunner over het algemeen. Daarnaast werkt Docker ook met Windows images, dus je zit niet per se vast aan Linux.

Wellicht dat LXC wat minimale performance-voordelen heeft, maar daar blijft het volgens mij wel bij. Het is meer aan alternatief voor VMs dan voor container workloads.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 21:38]

[Jerie]

OCI bedoel je, niet per definitie Docker. Podman is bijvoorbeeld user-space implementatie van Docker, en OCI-compatible.

Btw, als je Docker op Windows of macOS draait, dan gebruik je altijd een Linux kernel. Dus je zit wel 'vast aan Linux' in de letterlijke zin. Alleen heeft de gebruiker dat niet door. Dat is wat anders. Ik zelf had nogal wat I/O overhead toen ik dit gebruikte in ~2016 op Windows (macOS zullen we het maar niet over hebben ...)

[Verwijderd]

Btw, als je Docker op Windows

Dit is onjuist, Windows containers bestaan ook.

En voor het gemak van spreken koos ik het woord Docker container, omdat dat voor beginners duidelijker is dan OCI.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 21:38]

[Jerie]

Dit is onjuist, Windows containers bestaan ook.

Ja, toen ik dat destijds gebruikte was dat geen drop-in replacement en zat je met compatibility (de I/O was wel beter).

Voor Docker drop-in replacement die compatible is met OCI ken ik enkel Podman. Als Windows Containers (op Windows?) ook werken, leuk.

Maar je stelde:

Daarnaast werkt Docker ook met Windows images, dus je zit niet per se vast aan Linux.

Wat maakt dat uit? Je draait je server op bijvoorbeeld Proxmox dat al Linux is, of op een HVM als ESXi wat uiteindelijk ook Linux is. Windows op de server is tegenwoordig marginaal. Ik ga er opzeker geen rekening mee houden dat iets dat ik schrijf of gebruik compatible is met Windows op de server. Waarom zou ik? Je spint gewoon een extra VM op en klaar.

[Verwijderd]

Oke, je bent duidelijk onbekend met de materie, maar Docker en Kubernetes op Windows is een volwassen product waarmee je dus Windows-producten op Windows kunt (moet) draaien. Dat je dat verder niet interessant vind of dat de hypervisor niet op Windows draait, heeft hier natuurlijk geen zak mee te maken.

Er zijn nog voldoende (legacy) applicaties die enkel op Windows draaien en daar is nu (al een paar jaar) een methode voor om in containers te draaien en middels Kubernetes mee te schalen. Fijn dat -jij- er geen gebruik van gaat maken (omdat je het net 5 minuten kent) maar er zijn mensen en bedrijven die dit om verschillende redenen wel doen.

[Jerie]

Blijkbaar is het (volgens jou?) inmiddels wel OCI compatible. In 2016 was het dat in ieder geval zeer zeker niet. En op m'n werk zijn ook figuren die steeds op zo'n Windows machine allemaal Linux taken doen, ik heb medelijden met ze.

[Verwijderd]

In 2016 was dit zeer zeker wel het geval:

Windows Server 2016 features support for containers. These are not Linux-based, but containers that run on Windows and run Windows on the inside.

These conform to the Open Container Initiative (OCI). They allow you to run applications insulated from the rest of the system, within portable containers that include everything an application needs to be fully functional. As they did with Linux, containers will change the nature of the software supply chain for Windows users.

[Jerie]

Dus dat allerlei software op hub.docker.com zei van 'werkt niet met Windows containers' en 'zorg er voor dat Linux compatibility mode aan staat' zuig ik volgens jou uit m'n dikke duim het zal wel joh.

[Verwijderd]

Goed, je weet net 10 minuten dat het uberhaupt bestaat en begrijpt duidelijk niet hoe het werkt. Als die apps op Docker Hub met de Linux kernel werken, dan nogal wiedes dat het niet met de Windows kernel werkt. Volgens mij verwar je containers met VMs.

[Jerie]

Nee hoor, ik heb het de hele tijd over OCI containers. En ik weet helemaal niet pas 10 minuten dat het bestaat:

Jerie in 'Canonical neemt containerbeheertool LXD over en maakt het geen snap-exclusive'

Btw, als je Docker op Windows of macOS draait, dan gebruik je altijd een Linux kernel. Dus je zit wel 'vast aan Linux' in de letterlijke zin. Alleen heeft de gebruiker dat niet door. Dat is wat anders. Ik zelf had nogal wat I/O overhead toen ik dit gebruikte in ~2016 op Windows (macOS zullen we het maar niet over hebben ...)

De Windows mode werkte voor geen meter met allerlei containers en dus moest ik wel de Linux mode gebruiken (met alle overhead van dien).

[Verwijderd]

Je roept net zelf dat Windows-native containers in 2016 niet conform OCI waren, terwijl ze dat gewoon wel waren. Vervolgens begin je te wauwelen over images op Docker Hub, iets wat geen fluit met OCI spec te maken heeft maar de kernel en target arch waarvoor ze gebouwd zijn door de makers. Niets weerhoudt jou of die mensen ervan die images ook te bouwen voor Windows native containers, mits er binaries zijn voor die app voor Windows.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 21:38]

[Jerie]

Destijds was het zo dat als 1 van de applicaties niet met Windows mode werkt, je maar Linux mode moest gebruiken. Met alle performance loss van dien. Want de I/O was gigantisch. Dus ja dat was (misschien is) nogal problematisch. Op Linux heb ik die overhead niet. En ik hoef niet geen repo als hub.docker.com te gebruiken, Dockerfile en docker-compose.yml werken ook. Als ik dat op Windows containers zou willen draaien is het naar ik denk geen drop-in replacement. En jouw posts alhier lijken dat ook te bevestigen. Podman daarentegen is wel een drop-in replacement.

Dus ja superleuk voor jou dat het kan, Windows containers. Waarschijnlijk geen hond die het gebruikt.

[Verwijderd]

Een van de grootste websites in Nederland draait er in ieder geval gedeeltelijk op en vooral binnen enterprise is het redelijk populair.

Podman is een drop-in replacement voor Docker op Linux. We hebben het ook niet over drop-in replacements, maar containers op een andere kernel. OCI is niet kernel-specifiek, dus ik zie het probleem niet zo.

Destijds was het zo dat als 1 van de applicaties niet met Windows mode werkt, je maar Linux mode moest gebruiken. Met alle performance loss van dien.

Goed, het zijn dit soort zinnetjes die aantonen dat je eigenlijk geen idee hebt hoe het werkt. Er is geen "mode". ik weet niet of je met een of andere GUI tool aan het kloten bent geweest of WSL, maar dit is een native (native == geen virtualisatie) implementatie van OCI containers op Windows. Je installeert via PowerShell de MsftProvider en vervolgens kun je gewoon docker pull/run uitvoeren, inclusief Compose. De enige eis is dat je image voor de Windows kernel is geschreven, niet voor de Linux kernel. Elton Stoneman, een man waarmee ik heb samengewerkt aan Docker op Windows, heeft hier letterlijk het boek over geschreven.

- https://www.infoq.com/art...r-windows-second-edition/
- https://github.com/sixeye...ows/blob/master/README.md

Ga je anders eerst even inlezen over deze techniek en wat OCI betekent en kom dan terug met een passend antwoord.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 21:38]

[zenlord]

Vooraf even: ik ben niet erg vertrouwd met docker - ik gebruik sinds kort podman voor een aantal kleine taakjes (een begin van homeassistant en ubiquiti bvb). Zoals ik het begrijp, gebruik je docker principieel enkel voor containers waarin 1 proces actief is. Verschillende containers kan je in pods clusteren om deze beperking te omzeilen.
Een toepassing als een mailserver wordt al gauw een kluwen van containers/pods, en dan lijkt het mij fijner om alles in 1 omgeving die mooi afgescheiden is van eventuele andere omgevingen (bestands-server, webserver, etc.) te kunnen configureren en snapshotten. Integratie met ZFS waarbij je voor iedere instance een aparte ZFS dataset aanmaakt is mooi meegenomen. Ansible-integratie is er ook (maar die bestaat ook voor podman/docker/kubernetes).
Dit is mijn persoonlijke mening, meer niet.
Wat betreft de tegenargumenten van @Verwijderd:
1. Ik maal niet om portability - linux is mijn server-platform en dat zal niet gauw veranderen
2. Ik weet niet of 'over het algemeen' docker images dunner zijn. In mijn opstelling zal je 1 instance draaien met daarin de verschillende diensten die je nodig hebt voor een mailserver - geen idee of docker/podman het efficiënter zou kunnen uitvoeren
3. ik denk niet dat je kan stellen dat je LXD niet in professionele omgevingen zal tegenkomen. Het is een heel matuur platform en zou mij niet verbazen als het de basis is voor online hosters. Kubernetes is dan misschien wel 'the holy grail', maar voor mij was de leercurve te stijl.

[Verwijderd]

Ligt er nog even aan of we het over "rauw" Docker hebben of over containers icm een orchestrator. Dan zou je die componenten inderdaad opsplitsen in containers binnen een Pod. Zo draai ik zelf bvb. een bot die Python3 draait en MySQL gebruikt als backend. Ik heb een MySQL container en Python container samen in een pod, en daarmee delen ze een virtuele host. Ik kan via localhost:xxxx de database bereiken.

Docker is niet per se voor 1 process, maar 1 endpoint. Je kunt dus prima meerdere processen draaien, maar de container zal maar naar 1 proces kijken voor aliveness. Ik kan bvb. een main.py-bestand starten en die draaiende houden en niets stopt mij om vanuit dat bestand nog meer processen te genereren of in parallel te draaien. Zo roep ik vanuit mijn bot meerdere .py-bestanden aan en roep ik middels subprocess een binary aan die wat zooi uitvoert in een shell. Die extra processen mogen wel kapot, enkel mag main.py nooit stoppen (anders reboot de container)

Wat dat betreft niet heel anders dan een systemd service in uitvoering.

Het is een heel matuur platform en zou mij niet verbazen als het de basis is voor online hosters.

Uit ervaring weet ik dat het in Nederland zijn het in ieder geval 9/10 keer "gewoon" VMs op een hypervisor als VMware die je als klant krijgt.

ik denk niet dat je kan stellen dat je LXD niet in professionele omgevingen zal tegenkomen.

Er al vast een club zijn die het draait, maar merendeels kom je vacatures en bedrijven tegen die inzetten op OpenShift of Kubernetes of reguliere VMs draaien op een cloud naar keuze.

Ik maal niet om portability - linux is mijn server-platform en dat zal niet gauw veranderen

Precies, voor thuis zal het weinig uitmaken. VM, direct op de hardware, containers. Allemaal 1 pak nat over het algemeen als je 5 jaar+ dezelfde meuk draait. Mijn stelling waarom het in professionele omgevingen niet heel praktisch is of zelden tevoorschijn komt, is omdat de portability en schaalbaarheid ontbreekt die een Docker icm Kubernetes wel bied.

Juist in een omgeving met tientallen of honderden developers, is het gigantisch praktisch dat iedereen overal dezelfde resultaten krijgt onafhankelijk van de achtergrond. Of ik nu de frontend app van mijn werkgever op een 2015 Mac opstart, op een Jenkins agent met Ubuntu een test afvuur of deploy naar een server met RHEL, de applicatie werkt overal hetzelfde.

[zenlord]

Je hebt absoluut gelijk als je zegt dat gebruikers op hun desktop eenvoudigweg een gestandaardiseerde container kunnen draaien, in welke omgeving ze zich ook bevinden, dat dan docker/podman de juiste keuze is.
Je laat (mijns inziens onterecht) geen opening voor het bestaan van een systeem op server-niveau dat eenvoudigweg performanter is dan het draaien van een VM. Dat jan-met-de-pet het niet kent en 99/100 alles in een VM gooit, is geen argument om te stellen dat iemand het niet zou mogen proberen.

[Verwijderd]

Ik denk dat het over het algemeen gemak is en de performance loss voor lief wordt genomen als het geen tientallen procenten scheelt. Het is nou eenmaal kinderlijk simpel om een VM met alles erop en eraan draaiend te krijgen in Azure, AWS of VMWare. Opslag, authenticatie en zelfs basis-configuratie middels cloudinit is allemaal al geritseld. Donder daar nog even automatisch patchen, security scans en ander snufjes bovenop, en je zult bijna niemand overtuigen om lxc te gaan gebruiken in een enterprise-setting.

[Melones]

ga je daar ook een mooi stukje + voorbeeld + receptuur voor schrijven?

[dcm360]

Docker kan je ook niet direct draaien op MacOS of Windows, ook Docker-containers zijn gebouwd op de isolatie-mogelijkheden van de Linux-kernel. Docker is wel zo aardig en handig om op Windows of MacOS een VM met Linux voor je in te richten zodat het voor de gebruiker mooi weggewerkt zit.

[HollowGamer]

Is dat nog altijd zo? Als ik mij niet vergist, kunnen er al flink wat gedeeltes voor de Docker-engine op bijvoorbeeld macOS in hun eigen kernel/workspace worden gedraaid.

Op Windows 10/11 is het dacht ik ook niet meer een grote VM. Dacht dat stukken weer gaan via hun eigen kernel laag.

Beide zijn dan namelijk sneller en veiliger. Zo heb ik het ongeveer begrepen, je kunt die settings ook aanzetten om Docker zelf.

[Pinkys Brain]

Docker heeft nooit het Linux container ecosysteem gemonopoliseerd zoals systemd en Wayland dat hebben gedaan voor init en X11 opvolgers, het is een zee van concurrerende systemen. LXD is populair genoeg voor derden om er Mac tools voor te maken.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 21:38]

[Soldaatje]

LXD zijn systeem containers, en Docker app-containers.

[DeeD2k2]

Wat ik altijd als leidraad gebruik:

• Docker/Podman gebruik je als je een app nodig hebt,
• LXD/LXC als je een OS nodig hebt,
• en een VM als je een machine nodig hebt.

[jorisvergeerTBA]

Moet ik LXD dan een beetje zien als Microsofts WSL2?

[DeeD2k2]

Laat ik voorop stellen dat ik geen expert ben, maar zoals ik het interpreteer is het vergelijkbaar.

Bij de aankondiging van WSL2 schrijft Microsoft zelf:

WSL 2 uses the latest and greatest in virtualization technology to run its Linux kernel inside of a lightweight utility virtual machine (VM). (...) High levels of integration between Windows and Linux, extremely fast boot times, small resource footprint, and best of all will require no VM configuration or management.

In andere woorden: WSL2 is een tool om een zeer complete linux installatie te draaien met met weinig performance impact.

Dit doet LXD ook. Het zorgt ervoor dat je een zeer complete (bijna volwaardige) linux installatie kunt draaien als container. Ook dit heeft een stuk minder performance impact dan een VM. Zoals VMware, Hyper-V, KVM of Qemu software is om een VM te kunnen draaien, is LXD software om een Linux container te draaien.

Het grote verschil tussen een container en een VM is dat een VM eigen virtuele hardware heeft die los kunnen staan van de host. Voor het OS dat je erop draait is het net of het een echte machine is. Dit is bij een container niet zo; het deelt onderdelen met de host.

Een heel praktisch en concreet voordeel van een container is dat het geen geheugen reserveert waardoor dit beschikbaar blijft voor de host als het niet gebruikt wordt. Een VM reserveert wel geheugen wat meer impact geeft op de host.

Het verschil met de containers die je met bijvoorbeeld Docker start, is dat die eigenlijk altijd een programma draaien. Er wordt een eenmalige actie of (achtergrond) service gestart. Dit is waar dockerfiles op ingericht zijn.

[Reactie gewijzigd door DeeD2k2 op 22 juli 2024 21:38]

[The Zep Man]

Een heel praktisch en concreet voordeel van een container is dat het geen geheugen reserveert waardoor dit beschikbaar blijft voor de host als het niet gebruikt wordt. Een VM reserveert wel geheugen wat meer impact geeft op de host.

Moderne hypervisors met goed geconfigureerde VM's zorgen ervoor dat er niet onnodig geheugen gebruikt wordt. Qua dat is dit voordeel niet meer zo groot als dat het vroeger was.

[DeeD2k2]

Had ik niet anders verwacht. Dank voor de toevoeging!

Dit moet ook niet je motivatie zijn om voor een container te kiezen boven een VM.

In de notendop: bij een VM deel je hardware net de host. Bij een container deel je hard- én software. Dat heeft impact op performance, security/isolatie en mogelijkheden. De beste keuze is afhankelijk van je doel…

[Reactie gewijzigd door DeeD2k2 op 22 juli 2024 21:38]

[DaanHetEendje]

Meer als een VMWare, Hyper-V en Proxmox. Met support voor Linux Containers (LXC) en VMs (Qemu).

Een LXC is een lichtere vorm van een VM. Of een Docker container met een persistent root file system ipv ephemeral filesystem.

[daddyrazzy]

Bedankt!
Deze ga ik gebruiken!
Simpel maar duidelijk.

[Verwijderd]

Maar ik gebruik debian (systeem) Als basis voor mijn php spul in docker, doe ik het dan fout?

[Yggdrasil]

Nee, maar bij Docker images (net als bij alles) loont het zich om ze zo klein mogelijk te houden. Debian images bevatten relatief veel dingen die je nooit gebruikt. Wij gebruiken voor vrijwel alle apps Alpine als base image. Dat is erg minimaal, waardoor er minder libraries inzitten die elk hun eigen kwetsbaarheden kunnen hebben, waardoor hij sneller downloadt en opstart en waardoor hij minder geheugen en diskspace gebruikt. Andere minimale opties, elk met hun eigen voor- en naderen zijn Wolfi, Distroless.

[Verwijderd]

Heb jij bijvoorbeeld rsync aan de praat gekregen dan? Volgens mij is de basis redelijk veilig en kan ik makkelijk switchen naar Ubuntu met bijvoorbeeld ms sql. Wellicht dat het in debian, alpine ook werkt. Ik gebruikte al jaren debian in vm en ben toen in wsl verder gegaan te samen met vps. Die vps is ook debian, dus ik draai daar momenteel docker op, dus debian in debian. Maar heb nog geen werkende rsync of soortgelijk werkend in de container, dat zou wel fijn zijn voor backups bijvoorbeeld

[Yggdrasil]

Daar gebruiken we geen rsync voor. Onze applicatiecontainers zijn stateless dus bevatten geen data die gebackupped hoeft te worden. De meeste stateful informatie wordt opgeslagen in een MySQL database en we gebruiken daarvoor een managed database platform van Google (Cloud SQL) dat ook backups maakt. Andere data staat in Elasticsearch, dat we backuppen door de Persistent Volumes en Kubernetes resources te snapshotten via Velero (https://velero.io/). Uploads van gebruikers, zoals afbeeldingen en documenten, slaan we op in een object storage service (Google Cloud Storage, net zoiets als Amazon S3).

De applicatiecontainers zijn lichtgewicht en hebben een read-only filesystem, voor extra veiligheid. Sommigen containers hebben een wegwerpopslag (emptyDir in Kubernetes) voor bijv. cache data, maar die kan dus elk moment verwijderd worden.

[Verwijderd]

Hmm mijn configuratie heeft wel state en gebruikt standaard geen MySQL als state server. Dan zit je ook weer waar je je credentials bewaard van de server etc. ik ben nu bezig met een custom object store waarin ik de data bewaar. Ik kan natuurlijk nog een instance maken (backup of replica of keyserver) en dan zelf een upload / backup server maken . dit wordt voor het gemak dan een nieuwe docker image. Om rsync in de docker inage aan de praat te krijgen moet je volgens mij te veel capriolen uithalen.

[fastedje]

Dit linkje beschrijft in detail de versxhillen:
https://lwn.net/Articles/907613/

LXD gebruikt een compleet image, in tegenstelling tot docker en LXC. Je kan er complete vm images in draaien, maar is een stuk efficiënter dan een complete hypervisor. Helaas is het minder portable dan docker waar heel veel images voor beschikbaar zijn. De kans dat LXD dus docker of Kubernetes voorbij gaat streven is niet zo groot, maar het heeft zeker zijn voordelen tov een complete hypervisor.

[Sendy]

Dit is iets om je containers mee te managen. In de graphic zie je het ding dat storage, compute en network levert. Eerder vergelijkbaar met Redhat OpenShift of Suse rancher.

[mbo]

Canonical schrijft in een nieuwsbrief dat het vindt ...

Dit is niet correct, dit is niet geschreven door Canonical maar door het Linux Containers team. Zoals je kan afleiden uit de link zijn deze twee niet hetzelfde.

Wel betekent het dat de originele ontwikkelaars stoppen met het project en dat Canonical de ontwikkeling verder oppakt. Die ontwikkelaars zouden de beslissing 'jammer, maar begrijpelijk' vinden.

Dit is ook niet correct, het is 1 ontwikkelaar die stopt bij Canonical.

[Reactie gewijzigd door mbo op 22 juli 2024 21:38]

[MeneerGroot]

Het heet in het kort LXD, maar voluit noemen we het Linux Container Daemons? LCD?

Wat is het verschil tussen een container en een VM?
Run containers, VMs, or a combination of the two

[Reactie gewijzigd door MeneerGroot op 22 juli 2024 21:38]