Kokios yra 5 ge­riau­sios „Docker“ al­ter­na­ty­vos?

Šiandien kon­t­ei­ne­rių nau­do­ji­mas su „Docker“ yra tapęs standartu, tačiau tai ne visada yra ge­riau­sias pa­si­rin­ki­mas kiek­vie­no­je si­tu­aci­jo­je. Tokios priemonės kaip „Podman“ ar „BuildKit“ siūlo puikias al­ter­na­ty­vas, kurios suteikia privalumų tokiose srityse kaip saugumas, CI/CD ir našumas. Šiame straips­ny­je aptarsime ge­riau­sias pro­fe­sio­na­lias „Docker“ al­ter­na­ty­vas, pa­ly­gin­si­me jų pag­rin­di­nes funkcijas ir padėsime jums nuspręsti, kuris spren­di­mas ge­riau­siai tinka jūsų konk­re­čiam naudojimo atvejui.

„Docker“ al­ter­na­ty­vų pa­ly­gi­ni­mas iš pirmo žvilgsnio

Kodėl verta ap­svars­ty­ti „Docker“ al­ter­na­ty­vas?

Nors „Docker“ yra galingas įrankis, jis ne visada yra ge­riau­sias pa­si­rin­ki­mas. „Docker“ li­cen­ci­ja­vi­mo pokyčiai, pa­vyz­džiui, „Docker Desktop“ ko­mer­cia­li­za­vi­mas, turėjo įtakos daugeliui įmonių. Be to, tai, kad „Docker“ rei­ka­lau­ja „root“ teisių ir naudoja centrinį demoną, gali padidinti po­ten­cia­lų atakų paviršių, o tai kelia su­si­rū­pi­ni­mą saugumo klau­si­mais.

Be to, „Ku­ber­ne­tes“ – pir­mau­jan­ti kon­t­ei­ne­rių ko­or­di­na­vi­mo priemonė – atsisakė „Docker“ kaip nu­ma­ty­to­sios vykdymo aplinkos. Vietoj to dabar ji naudoja tokias vykdymo aplinkas kaip „con­tai­nerd“ ar „CRI-O“. Daugeliu atvejų – ypač saugumo požiūriu jautriose aplinkose arba au­to­ma­ti­zuo­tuo­se CI/CD pro­ce­suo­se – spe­cia­li­zuo­tos priemonės gali būti geresnis spren­di­mas.

Podman – „Docker“ be demono

„Podman“ šiuo metu yra ge­riau­siai žinoma ir tie­sio­gi­nė „Docker“ al­ter­na­ty­va. Ypač įdomu tai, kad „Podman“ veikia be centrinio demono, todėl kon­t­ei­ne­rių procesus galima paleisti tie­sio­giai ir, jei reikia, net ne­rei­ka­lau­jant ad­mi­nist­ra­to­riaus teisių. Tai žymiai padidina saugumą, ypač ga­my­bi­nė­se aplinkose.

Dar vienas pri­va­lu­mas – puikus su­de­ri­na­mu­mas: jei jau esate su­si­pa­ži­nę su „Docker“, „Podman“ jums nesukels jokių sunkumų, nes jo komandų struktūra yra beveik identiška. Be to, jis puikiai in­te­gruo­ja­si su „systemd“ ir „Ku­ber­ne­tes“.

Tačiau yra ir neigiamas aspektas: „Podman“ grafinės vartotojo sąsajos (GUI) arba GUI įrankiai nėra tokie pažangūs kaip „Docker Desktop“ atveju. Be to, su­dė­tin­ges­nių projektų, apimančių kelis kon­t­ei­ne­rius, atveju perėjimas iš „Docker Compose“ gali pa­rei­ka­lau­ti tam tikrų pakeitimų.

Išvada: „Podman“ puikiai tinka prog­ra­muo­to­jams ir ad­mi­nist­ra­to­riams, ieš­kan­tiems saugios, ko­man­di­nės eilutės pagrindu vei­kian­čios ir su „Docker“ su­de­ri­na­mos al­ter­na­ty­vos – ypač ga­my­bi­nė­se „Linux“ aplinkose.

BuildKit – šiuo­lai­ki­nis „Docker“ kūrimo įrankis

„BuildKit“ sukūrė „Docker“ komanda, siekdama pakeisti klasikinę komandą „docker build“. Ji iš­si­ski­ria didesniu greičiu, pažangiu talpyklos naudojimu ir galimybe valdyti kom­pi­lia­ci­jos slap­ta­žo­džius, o tai yra didžiulis pri­va­lu­mas su­dė­tin­go­se CI/CD procesų gran­di­nė­se.

Taip pat palaikomi ly­gia­gre­tūs kūrimo procesai, todėl „BuildKit“ yra ypač efektyvus. Jį galima įjungti „Docker“ aplinkoje arba naudoti atskirai. Kartu su „Docker“ ar „Podman“ jis žymiai padidina atvaizdų kūrimo našumą. Tačiau trūkumas yra tas, kad „BuildKit“ visiškai ne­pa­kei­čia „Docker“. Jis skirtas tik kūrimo procesui. Norintys valdyti ar diegti kon­t­ei­ne­rius turės naudoti papildomą įrankį.

Išvada: „BuildKit“ puikiai tinka „DevOps“ komandoms ir prog­ra­muo­to­jams, kuriems svar­biau­sia yra greitas ir saugus programų su­rin­ki­mas – ypač au­to­ma­ti­zuo­to­se aplinkose.

Kaniko – Kon­t­ei­ne­rių kūrimas be „Docker“

„Kaniko“ – tai „Google“ sukurta priemonė, skirta kon­t­ei­ne­riams kurti „Ku­ber­ne­tes“ aplinkose be „Docker“ ar ad­mi­nist­ra­to­riaus teisių. Ji veikia iš­skir­ti­nai podo viduje ir gali kurti atvaizdus tie­sio­giai debesyje, pa­vyz­džiui, naudojant „GitHub Actions“ ar „Google Cloud Build“.

Dėl to „Kaniko“ idealiai tinka au­to­ma­ti­zuo­tiems CI/CD procesams, kuriuose nereikia diegti jokios pa­pil­do­mos vykdymo aplinkos. Svarbus pri­va­lu­mas saugumo požiūriu yra tai, kad „Kaniko“ veikia be „root“ teisių, o tai reiškia, kad jį galima saugiai naudoti bendrai nau­do­ja­mo­se klasterių aplinkose. Tačiau „Kaniko“ nėra uni­ver­sa­lus įrankis. Jis netinka vietinei prog­ra­ma­vi­mo veiklai ar in­te­rak­ty­viam darbui ko­man­di­nė­je eilutėje – trūksta tokių įprastų funkcijų kaip prieiga prie ko­man­di­nės eilutės ar lankstus kon­t­ei­ne­rių valdymas.

Išvada: „Kaniko“ puikiai tinka komandoms, dir­ban­čioms debesų aplinkose ir sie­kian­čioms saugiai au­to­ma­ti­zuo­ti kon­t­ei­ne­rių kūrimo procesus – ypač „Ku­ber­ne­tes“ aplinkose.

LXC / LXD – kon­t­ei­ne­rių tech­no­lo­gi­ja sistemos lygiu

LXC (Linux Con­tai­ners) – tai žemo lygio tech­no­lo­gi­ja, skirta ope­ra­ci­nės sistemos vir­tu­ali­za­vi­mui „Linux“ aplinkoje, kuri naudojama jau daugiau nei de­šimt­me­tį. Ji leidžia paleisti ir valdyti pilnas „Linux“ sistemas kon­t­ei­ne­riuo­se – daž­niau­siai va­di­na­muo­se sis­te­mi­niais kon­t­ei­ne­riais.

„LXD“, kurią 2015 m. sukūrė „Canonical“, suteikia patogų valdymo lygmenį, veikiantį virš „LXC“. Ji papildoma tokiomis funk­ci­jo­mis kaip nuosava ko­man­di­nės eilutės sąsaja (CLI), REST API, atvaizdų valdymas ir mo­men­ti­nės kopijos, todėl ypač praverčia pro­fe­sio­na­lio­se inf­rastruk­tū­ro­se.

LXC ir LXD – kodėl jos vėl sujungtos

2023 m. „Canonical“ grąžino LXD projektą LXC bend­ruo­me­nei, ir nuo tada abu projektai yra plėtojami kartu pagal „Linux Con­tai­ners Project“ ini­cia­ty­vą. Šio sujungimo tikslas – už­tik­rin­ti skaid­res­nę, bend­ruo­me­nės vykdomą priežiūrą ir glaudesnę abiejų kom­po­nen­tų in­te­g­ra­ci­ją. Nors LXC išlieka techniniu pagrindu, LXD ir toliau veikia kaip var­to­to­jui patogi sąsaja.

Funkcinis su­skirs­ty­mas išlieka toks:

• LXC veikia kaip žemo lygio tech­no­lo­gi­ja
• LXD išlieka patogiu valdymo sąsajos įrankiu

Techninė kla­si­fi­ka­ci­ja

Palyginti su „Docker“, „LXC“ ir „LXD“ yra daug artimesni tra­di­ci­nėms vir­tu­a­lio­sioms mašinoms. Jie teikia pilnas sistemos aplinkas su „init“ sis­te­mo­mis, vartotojų valdymu, paketų valdymu ir kitais ele­men­tais – tai gerokai pranoksta tipinius programų kon­t­ei­ne­rius, kuriuos siūlo „Docker“ ar „Podman“. Tačiau, ne­nau­do­da­mi hi­per­vi­zo­riaus, jie vis tiek išlieka lengvi ir našūs.

Ap­ri­bo­ji­mai

Trūkumas yra tas, kad LXC/LXD nėra pri­tai­ky­ta mikro pa­slau­goms, debesų aplinkai pri­tai­ky­tam diegimui ar šiuo­lai­ki­niams CI/CD procesams. Jos valdymas gali būti su­dė­tin­ges­nis, o in­te­g­ra­ci­ja į kon­t­ei­ne­rių eko­sis­te­mas, pa­vyz­džiui, „Ku­ber­ne­tes“, yra minimali.

Išvada: LXC ir LXD puikiai tinka ad­mi­nist­ra­to­riams, prie­glo­bos paslaugų teikėjams ar komandoms, no­rin­čioms izoliuoti pilnas „Linux“ sistemas – tai lengva virtualių mašinų al­ter­na­ty­va. Abiejų tech­no­lo­gi­jų su­jun­gi­mas į „Linux Con­tai­ners Project“ žada sta­bi­les­nę, bend­ruo­me­nės pri­žiū­ri­mą ateitį.

runC – Kon­t­ei­ne­rių vykdymo aplinka pa­žen­gu­siems var­to­to­jams

„runC“ yra OCI spe­ci­fi­ka­ci­jos (Open Container Ini­tia­ti­ve) etaloninė įgy­ven­di­ni­mo versija, kurią už­ku­li­siuo­se naudoja daugelis įrankių, pa­vyz­džiui, „Docker“, „Podman“ ar „con­tai­nerd“. Visiems, kurie nori valdyti kon­t­ei­ne­rius žemiausiu lygmeniu, grei­čiau­siai teks naudoti „runC“.

Di­džiau­sias jo pri­va­lu­mas – lengvumas, nes „runC“ teikia tik bū­ti­niau­sius elementus, rei­ka­lin­gus kon­t­ei­ne­riams paleisti, todėl jis yra labai lankstus. Tai idealus spren­di­mas in­di­vi­dua­liems kon­t­ei­ne­rių spren­di­mams arba aplinkoms, kuriose didelis dėmesys skiriamas saugumui.

Tačiau „runC“ skirta pa­žen­gu­siems var­to­to­jams. Jame nėra patogios ko­man­di­nės eilutės sąsajos (CLI) kon­t­ei­ne­rių valdymui ar kūrimui, todėl jis paprastai nau­do­ja­mas kaip in­di­vi­dua­lių įrankių rinkinių dalis arba giluminei sistemos in­te­g­ra­ci­jai.

Išvada: „runC“ puikiai tinka spe­cia­li­zuo­toms prog­ra­moms, moks­li­niams tyrimams, saugumo užduotims ar žemo lygio kon­t­ei­ne­rių aplinkoms – ji nėra skirta kas­die­niam prog­ra­ma­vi­mo darbui.

„Ku­ber­ne­tes“ – ne „Docker“ al­ter­na­ty­va, o aukš­tes­nis lygmuo

Dažnai klai­din­gai manoma, kad „Ku­ber­ne­tes“ ne­pa­kei­čia „Docker“. Iš tiesų, jis naudoja kon­t­ei­ne­rių vykdymo aplinkas, kad paleistų kon­t­ei­ne­rius. Nors anksčiau „Docker“ buvo nu­ma­ty­to­ji vykdymo aplinka, nuo 1.20 versijos „Ku­ber­ne­tes“ naudoja stan­dar­ti­zuo­tas vykdymo aplinkas, pa­vyz­džiui, „con­tai­nerd“ arba „CRI-O “.

Šios priemonės skirtos kon­t­ei­ne­rių valdymui, tačiau neturi savų kom­pi­lia­vi­mo ar ko­man­di­nės eilutės (CLI) funkcijų, kaip „Docker“. Todėl „Ku­ber­ne­tes“ savaime nėra „Docker“ al­ter­na­ty­va, o yra ko­or­di­na­vi­mo priemonė – valdymo lygmuo, esantis virš kon­t­ei­ne­rių.

Prak­tiš­kai tai reiškia, kad kiek­vie­nas, dirbantis su „Ku­ber­ne­tes“, turėtų suprasti, jog „Docker“ nebėra techninis pagrindas – nors daugelis vaizdų vis dar yra „Docker“ formatu.

Kokia „Docker“ al­ter­na­ty­va jums tinka?

Tin­ka­miau­sia „Docker“ al­ter­na­ty­va didžiąja dalimi priklauso nuo jūsų konkrečių poreikių:

• Jei norite už­tik­rin­ti maksimalų saugumą, „Podman“ yra ge­riau­sias pa­si­rin­ki­mas.
• Jei norite sukurti našias aplinkas, iš­si­ski­ria „BuildKit“, o debesų aplinkose labiau tinka „Kaniko “.
• Norint izoliuoti ištisus sistemas, geresnis pa­si­rin­ki­mas yra „LXC/LXD “.
• Norint visiškai kont­ro­liuo­ti vykdymo lygį, „runC“ yra paprastas spren­di­mas pro­fe­sio­na­lams.

Ga­liau­siai verta pažvelgti už „Docker“ ribų – kon­t­ei­ne­rių pasaulis yra įvai­res­nis nei bet kada anksčiau.