Ikke alt nytt er bra og ikke alt revolusjonerende er nødvendig. Med containerteknologier, som med alle andre "neste store ting", ser vi frodig oppfinnelse av abstraksjoner på høyere nivå etterfulgt av distribusjon i produksjonen, med hele CD/CI -infrastrukturen som er avhengig av det og DevOps ikke forstår hva den faktisk gjør.
La oss begynne med det containere faktisk var, historisk. På begynnelsen av 2000 -tallet introduserte FreeBSD konseptet "fengsler" som tilbød et nytt miljø, som en ny installasjon av operativsystemet som tilbyr alt FreeBSD -biblioteket og kjerneinfrastrukturen som allerede er på plass. En ren skifer for utviklere å teste ny programvare.
Dette står i sterk kontrast til VMware, KVM eller VirtualBox som teknologier der hele maskinvaren er virtualisert, hvor, verts OS -bestemmelsene et virtuelt sett med CPU, RAM og andre ressurser. Gjestoperativsystemet ditt sitter på toppen av de virtuelle maskinvareressursene. Nesten hvert lag av abstraksjon gjentas to ganger, og ressurser som RAM og CPU som en gang er tildelt gjesten, er ikke lenger tilgjengelig for verten (uavhengig av om gjesten bruker dem helt eller ikke).
Når operativsystemet blir virtualisert, kan containere bli spunnet opp med kvoter som er satt for ressursutnyttelsen. For eksempel, hvis vi setter opp en maksimal grense på 2 GB RAM -bruk for container, vil den ikke kunne overstige den. På den annen side, siden det bare er en kjerne i løkken, hvis beholderen ikke bruker hele RAM, kan kjernen legge den gjenværende ressursen som skal brukes andre steder.
Den første ulempen folk skjønte med containermodellen er at siden vi virtualiserer operativsystemet og ikke maskinvaren, kan du ha flere forekomster av det samme operativsystemet, og du mister muligheten til å snurre opp et vilkårlig OS.
Det er ikke noe som heter Windows -beholderen på Linux eller Linux -containere på Windows. Docker på Windows bruker for eksempel Moby Linux som faktisk kjører i en VM inne i Windows -boksen.
Når det gjelder en Linux -distribusjon, kan du imidlertid gjøre mange interessante ting. Siden det vi kaller Linux bare er kjernen og den trenger en GNU -bunke med biblioteker for å gi et komplett OS -miljø, kan du etterligne forskjellige distribusjoner som Centos, Ubuntu, Alpine i forskjellige containerforekomster.
Dette gjelder både LXD og Docker.
Docker vil gjøre med passende, hva passende gjorde med tjære. Det vil si at du fortsatt vil bruke APT, men med et ekstra lag med abstraksjon på toppen av det. For å forstå hvordan, bør du vurdere følgende eksempel.
Du har en forekomst av nettstedet ditt som kjører i en Php5.6 Og du må kjøre en annen webtjeneste på samme server ved hjelp av PHP7.0. Å nå to forskjellige versjoner av PHP i seg selv er en skummel idé, uten å vite hvilke konflikter som vil oppstå ut av dem. Oppdatering og oppgradering vil snart bli en håpløs innsats.
Men hva om vi hadde vår originale webforekomst som kjøres inne i en Docker -beholder? Nå, alt vi trenger er en ny Docker -container inne som vi kan installere Php7.0 og vår andre webtjeneste vil fungere fra denne nylig spunnet containeren. Vi vil fortsatt bruke Apt i bakgrunnen, akkurat som APT bruker tjære i bakgrunnen, men Docker vil sørge for at forskjellige applikasjoner fra forskjellige containere ikke er i konflikt med hverandre.
Docker er spesielt nyttig for å kjøre statsløse applikasjoner, og du vil høre folk si ofte at du ikke kan kjøre mer enn en prosess i en beholder. Selv om det er usant, kan det å drive flere statlige tjenester i en containerinstans ofte føre til at Docker gir inkonsekvente resultater. Du vil snart finne deg selv på nytt med det samme settet med containere om og om igjen.
Med LXD -containere er det du får mye nærmere et frittstående operativsystem enn det du får fra Docker. Docker Containers deler alle den samme nettverksstabelen og lagringsstabelen.
Dette betyr grunnleggende kommandoer som ping eller ifconfig er utilgjengelige fra en Docker -beholder. Faktisk kan du vite nesten ingenting om nettverket du er på, fra innsiden av den beholderen. Docker Nat som kjører på vertens nettverksstabel tilbyr det meste av tilkobling og fasiliteter som portvideresending.
LXD -containere er langt foran kurven, og støtter nettverksbroer, MacVlan og flere andre alternativer. LXD -containere og verten din danner alle et eget privat nettverk og kan kommunisere med hverandre som om de snakker med forskjellige datamaskiner over et nettverk.
Det samme er tilfelle med lagringsstabelen. Det er ofte mye mer praktisk å bruke LXD med ZFS -bassenger der du kan tildele datasett med kvoter som begrenser lagringsutnyttelsen. LXD er i direkte konkurranse med VMware, KVM og andre hypervisor -teknologier.
Ved å bruke den, kan skyleverandøren din nå tilby deg din personlige container som vil lukte og føles som et komplett operativsystem og fremdeles er billig og rask å snurre opp og drepe, sammen med alle ting med vedvarende data du forventer.
Fra leverandørens perspektiv er ting også økonomiske. Siden ikke alle bruker hele RAM som de ber om, kan du stappe mange flere containere på samme metall enn du kan VMS.
For sluttbrukere kan det høres ut som juks med det første, men de vinner på slutten også, LX -containere er raskere å snurre og drepe og gjøre prosessen mye mer glatt og "skalerbar" (som folk er glad i å si).
Du kan spinne opp containere på en beregningsnode der dataene dine ligger, gjør beregningen du vil gjøre og deretter ødelegge containeren og la dataene være intakt. Dette er mye raskere enn å hente relevante data helt til din virtuelle maskin som kjører på et annet datasenter. Dette fungerer spesielt bra med ZFS i løkken.
For å oppsummere alt vi vet, er både LXD og Docker containeriseringsteknologier. Docker er lett, forenklet og er godt egnet for å isolere applikasjoner fra hverandre, noe som gjør det populært blant både DevOps og utviklere. En app per docker container.
LXD derimot, er mye bedre utstyrt og er mye nærmere et komplett operativsystemmiljø med nettverks- og lagringsgrensesnitt. Du kan kjøre flere Docker -containere nestet inne i LXD, hvis du vil.