Mitkä ovat viisi parasta vaih­toeh­toa Doc­ke­ril­le?

Docker-kont­ti­tek­niik­ka on nykyään va­kiin­tu­nut käytäntö – mutta se ei aina ole paras vaih­toeh­to jokaiseen ti­lan­tee­seen. Podmanin tai Build­Ki­tin kaltaiset työkalut tarjoavat vahvoja vaih­toeh­to­ja, jotka tuovat etuja esi­mer­kik­si tie­to­tur­van, jatkuvan in­tegraa­tion ja jatkuvan toi­mi­tus­ket­jun (CI/CD) sekä suo­ri­tus­ky­vyn osalta. Tässä ar­tik­ke­lis­sa tar­kas­te­lem­me parhaita am­mat­ti­käyt­töön tar­koi­tet­tu­ja Docker-vaih­toeh­to­ja, vertaamme niiden keskeisiä omi­nai­suuk­sia ja autamme sinua päät­tä­mään, mikä ratkaisu sopii parhaiten juuri sinun käyt­tö­tar­koi­tuk­see­si.

Docker-vaih­toeh­to­jen vertailu yhdellä sil­mäyk­sel­lä

Miksi harkita Docker-vaih­toeh­to­ja?

Vaikka Docker on tehokas työkalu, se ei aina ole paras vaih­toeh­to. Docker-li­sen­soin­tiin tehdyt muutokset, kuten Docker Desktopin kau­pal­lis­ta­mi­nen, ovat vai­kut­ta­neet moniin yri­tyk­siin. Samalla Docker-oh­jel­mis­ton riip­pu­vuus pää­käyt­tä­jän oi­keuk­sis­ta ja kes­ki­tet­ty­jen taus­tapro­ses­sien käyttö voivat laajentaa po­ten­ti­aa­lis­ta hyök­käys­koh­det­ta, mikä herättää tur­val­li­suu­teen liittyviä huo­le­nai­hei­ta.

Lisäksi johtava konttien hal­lin­ta­työ­ka­lu Ku­ber­ne­tes on luopunut Doc­ke­ris­ta ole­tus­ajo­ym­pä­ris­tö­nään. Sen sijaan se käyttää nykyään con­tai­nerd- tai CRI-O-tyyppisiä ajo­ym­pä­ris­tö­jä. Monissa käyt­tö­ta­pauk­sis­sa – etenkin tie­to­tur­vak­riit­ti­sis­sä ym­pä­ris­töis­sä tai au­to­ma­ti­soi­duis­sa CI/CD-pro­ses­seis­sa – eri­kois­tu­neet työkalut voivat tarjota parempia rat­kai­su­ja.

Podman – Docker ilman taus­ta­pal­ve­lin­ta

Podman on tällä hetkellä tunnetuin ja suorin vaih­toeh­to Doc­ke­ril­le. Sen erityisen kiin­nos­ta­van piirteenä on se, että Podman toimii ilman kes­ki­tet­tyä taus­tapro­ses­sia, minkä ansiosta kont­tipro­ses­se­ja voi käyn­nis­tää suoraan ja tar­vit­taes­sa ilman pää­käyt­tä­jän oikeuksia. Tämä parantaa tur­val­li­suut­ta mer­kit­tä­väs­ti, etenkin tuo­tan­to­ym­pä­ris­töis­sä.

Toinen etu on erin­omai­nen yh­teen­so­pi­vuus: jos olet jo pe­reh­ty­nyt Docker-alustaan, Podmanin käyttö sujuu vai­vat­to­mas­ti, sillä niiden ko­men­to­jen rakenne on lähes ident­ti­nen. Se in­tegroi­tuu myös sau­mat­to­mas­ti systemd-palvelun ja Ku­ber­ne­te­sin kanssa.

Tähän liittyy kuitenkin myös hait­ta­puo­li: Podmanin graafiset käyt­tö­liit­ty­mät (GUI) tai GUI-työkalut eivät ole yhtä ke­hit­ty­nei­tä kuin Docker Desktopin vastaavat. Lisäksi mo­ni­mut­kai­sem­mis­sa mo­ni­kont­tipro­jek­teis­sa siir­ty­mi­nen Docker Compose -so­vel­luk­ses­ta voi vaatia joitakin muutoksia.

Joh­to­pää­tös: Podman on ihan­teel­li­nen ratkaisu ke­hit­tä­jil­le ja jär­jes­tel­män­val­vo­jil­le, jotka etsivät tur­val­lis­ta, ko­men­to­ri­vi­poh­jais­ta ja Docker-yh­teen­so­pi­vaa vaih­toeh­toa – etenkin tuo­tan­to­käy­tös­sä olevissa Linux-ym­pä­ris­töis­sä.

BuildKit – Moderni Docker-ra­ken­nus­työ­ka­lu

Docker-tiimi kehittiBuild­Ki­tin kor­vaa­maan pe­rin­tei­sen ”docker build” -komennon. Se erottuu edukseen erin­omai­sel­la no­peu­del­laan, älyk­kääl­lä vä­li­muis­ti­toi­min­nol­laan sekä kyvyllä hallita ra­ken­nus­sa­lai­suuk­sia, mikä on valtava etu mo­ni­mut­kai­sis­sa CI/CD-put­kis­tois­sa.

Myös rin­nak­kai­set ra­ken­nuk­set ovat tuettuja, mikä tekee Build­Ki­tis­tä erityisen tehokkaan. Sen voi ottaa käyttöön Doc­ke­ris­sa tai käyttää it­se­näi­se­nä so­vel­luk­se­na. Yh­dis­tet­ty­nä Docker- tai Podman-ym­pä­ris­töön se parantaa kuvien ra­ken­ta­mi­sen suo­ri­tus­ky­kyä huo­mat­ta­vas­ti. Hait­ta­puo­le­na on kuitenkin se, että BuildKit ei korvaa Dockeria kokonaan. Se keskittyy yk­si­no­maan ra­ken­nuspro­ses­siin. Jos haluaa hallita tai ottaa käyttöön kontteja, tarvitaan erillinen työkalu.

Joh­to­pää­tös: BuildKit sopii erin­omai­ses­ti DevOps-tiimeille ja ke­hit­tä­jil­le, joille nopeat ja tur­val­li­set ra­ken­nuk­set ovat etusi­jal­la – etenkin au­to­ma­ti­soi­duis­sa ym­pä­ris­töis­sä.

Kaniko – Konttien ra­ken­ta­mi­nen ilman Docker-oh­jel­mis­toa

Kaniko on Googlen työkalu, joka on suun­ni­tel­tu eri­tyi­ses­ti konttien ra­ken­ta­mi­seen Ku­ber­ne­tes-ym­pä­ris­töis­sä – ilman Dockeria tai pää­käyt­tä­jän oikeuksia. Se toimii kokonaan podin sisällä ja pystyy ra­ken­ta­maan kuvia suoraan pil­vi­pal­ve­lus­sa, kuten GitHub Ac­tion­sis­sa tai Google Cloud Buildissa.

Tämän ansiosta Kaniko sopii erin­omai­ses­ti au­to­ma­ti­soi­tui­hin CI/CD-pro­ses­sei­hin, joissa ei tarvitse asentaa erillistä suo­ri­tusym­pä­ris­töä. Tur­val­li­suu­den kannalta tärkeä etu on se, että Kaniko toimii ilman pää­käyt­tä­jän oikeuksia, minkä ansiosta sitä voidaan käyttää tur­val­li­ses­ti jaetuissa klus­te­riym­pä­ris­töis­sä. Kaniko ei kui­ten­kaan ole yleis­käyt­töi­nen työkalu. Se ei sovellu pai­kal­li­seen ke­hi­tys­työ­hön tai vuo­ro­vai­kut­tei­seen työs­ken­te­lyyn ko­men­to­ri­vil­tä – siitä puuttuvat ta­val­li­set omi­nai­suu­det, kuten pääsy ko­men­to­tul­kin ym­pä­ris­töön tai joustava konttien hallinta.

Joh­to­pää­tös: Kaniko sopii erin­omai­ses­ti pil­vi­poh­jai­sis­sa ym­pä­ris­töis­sä työs­ken­te­le­vil­le tiimeille, jotka haluavat au­to­ma­ti­soi­da kont­ti­tek­no­lo­gi­aan pe­rus­tu­vat ra­ken­nuspro­ses­sit tur­val­li­ses­ti – etenkin Ku­ber­ne­tes-ym­pä­ris­töis­sä.

LXC / LXD – Jär­jes­tel­mä­ta­son kon­ti­toin­ti

LXC (Linux Con­tai­ners) on Linux-käyt­tö­jär­jes­tel­män vir­tua­li­soin­tiin tar­koi­tet­tu matalan tason tekniikka, joka on ollut käytössä jo yli kymmenen vuotta. Sen avulla voi ajaa ja hallita ko­ko­nai­sia Linux-jär­jes­tel­miä kont­teis­sa – joita kutsutaan yleisesti jär­jes­tel­mä­kont­teik­si.

Ca­no­nica­lin vuonna 2015 kehittämä LXD tarjoaa käyt­tä­jäys­tä­väl­li­sen hal­lin­ta­ker­rok­sen LXC:n päälle. Se sisältää omi­nai­suuk­sia, kuten oman ko­men­to­ri­vi­liit­ty­män, REST-ra­ja­pin­nan, kuvien hallinnan ja ti­lan­ne­ku­vat, minkä ansiosta se on erityisen hyö­dyl­li­nen am­mat­ti­mai­sis­sa infra­struk­tuu­reis­sa.

LXC ja LXD – Miksi ne yh­dis­tet­tiin uudelleen

Vuonna 2023 Canonical luovutti LXD:n takaisin LXC-yh­tei­söl­le, ja siitä lähtien molempia pro­jek­te­ja on kehitetty yhdessä Linux Con­tai­ners Projectin puit­teis­sa. Yh­dis­ty­mi­sen ta­voit­tee­na on varmistaa entistä avoimempi, yh­tei­sö­läh­töi­nen ylläpito sekä molempien kom­po­nent­tien tiiviimpi in­tegroin­ti. LXC toimii edelleen teknisenä perustana, kun taas LXD toimii käyt­tä­jäys­tä­väl­li­se­nä käyt­tö­liit­ty­mä­nä.

Toi­min­nal­li­nen jako säilyy ennallaan:

• LXC toimii pe­rus­ta­son tek­niik­ka­na
• LXD on edelleen help­po­käyt­töi­nen hal­lin­ta­käyt­tö­liit­ty­mä

Tekninen luokitus

Dockeriin ver­rat­tu­na LXC ja LXD muis­tut­ta­vat paljon enemmän pe­rin­tei­siä vir­tu­aa­li­ko­nei­ta. Ne tarjoavat täy­del­li­siä jär­jes­tel­mäym­pä­ris­tö­jä, joihin kuuluvat init-jär­jes­tel­mät, käyt­tä­jä­hal­lin­ta, pa­ket­tien­hal­lin­ta ja paljon muuta – ne menevät paljon pi­dem­mäl­le kuin Docker tai Podman tarjoavat tyy­pil­li­set so­vel­lus­kon­tit. Koska niissä ei kui­ten­kaan käytetä hy­per­vi­sor-oh­jel­mis­toa, ne ovat silti kevyitä ja suo­ri­tus­ky­kyi­siä.

Ra­joi­tuk­set

Hait­ta­puo­le­na on, että LXC/LXD:tä ei ole optimoitu mik­ro­pal­ve­luil­le, pil­vi­poh­jai­sil­le käyt­töö­no­toil­le tai ny­ky­ai­kai­sil­le CI/CD-pro­ses­seil­le. Hallinta voi olla mo­ni­mut­kai­sem­paa, ja in­tegroin­ti Ku­ber­ne­te­sin kal­tai­siin kont­tie­ko­sys­tee­mei­hin on vähäistä.

Joh­to­pää­tös: LXC ja LXD sopivat erin­omai­ses­ti jär­jes­tel­män­val­vo­jil­le, pal­ve­lun­tar­joa­jil­le tai tiimeille, jotka haluavat eristää ko­ko­nai­sia Linux-jär­jes­tel­miä – ne toimivat kevyenä vaih­toeh­to­na vir­tu­aa­li­ko­neil­le. Yh­dis­ty­mi­nen Linux Con­tai­ners Project -hankkeen alai­suu­teen lupaa mo­lem­mil­le tek­no­lo­gioil­le vakaampaa, yhteisön yl­lä­pi­tä­mää tu­le­vai­suut­ta.

runC – Konttien ajo­ym­pä­ris­tö edis­ty­neil­le käyt­tä­jil­le

runC on OCI-mää­ri­tyk­sen (Open Container Ini­tia­ti­ve) vii­teimple­men­taa­tio, jota monet työkalut – kuten Docker, Podman tai con­tai­nerd – käyttävät taustalla. Jokainen, joka haluaa hallita kontteja alimmalla tasolla, joutuu to­den­nä­köi­ses­ti käyt­tä­mään runC:tä.

Sen suurin etu on keveys, sillä runC tarjoaa vain konttien käyn­nis­tä­mi­seen tar­vit­ta­vat pe­rus­o­mi­nai­suu­det, mikä tekee siitä erittäin joustavan. Se sopii erin­omai­ses­ti rää­tä­löi­tyi­hin kont­ti­rat­kai­sui­hin tai tur­val­li­suu­teen pai­not­tu­viin ym­pä­ris­töi­hin.

runC on kuitenkin tar­koi­tet­tu edis­ty­neil­le käyt­tä­jil­le. Siinä ei ole kätevää ko­men­to­ri­vi­liit­ty­mää konttien hal­lin­taan tai ra­ken­ta­mi­seen, ja sitä käytetään yleensä osana rää­tä­löi­ty­jä työ­ka­lu­ket­ju­ja tai sy­väl­li­seen jär­jes­tel­mäin­tegraa­tioon.

Joh­to­pää­tös: runC sopii erin­omai­ses­ti eri­kois­tu­nei­siin so­vel­luk­siin, tut­ki­muk­seen, tie­to­tur­vaan tai matalan tason kont­tiym­pä­ris­töi­hin – sitä ei ole tar­koi­tet­tu päi­vit­täi­seen ke­hi­tys­työ­hön.

Ku­ber­ne­tes – Ei Docker-vaih­toeh­to, vaan sen ylä­puo­lel­la oleva taso

Yleinen vää­rin­kä­si­tys on, että Ku­ber­ne­tes ei korvaa Dockeria. Sen sijaan se hyödyntää konttien suo­rit­ta­mi­seen konttien suo­ri­tusym­pä­ris­tö­jä. Vaikka Docker oli aikoinaan ole­tusar­voi­nen suo­ri­tusym­pä­ris­tö, Ku­ber­ne­tes on versiosta 1.20 lähtien ottanut käyttöön stan­dar­doi­tu­ja suo­ri­tusym­pä­ris­tö­jä, kuten con­tai­nerd tai CRI-O.

Nämä työkalut hoitavat konttien hallinnan, mutta niillä ei ole omaa rakennus- tai ko­men­to­ri­vi­toi­min­toa kuten Doc­ke­ril­la. Siksi Ku­ber­ne­tes ei sinänsä ole Docker-vaih­toeh­to, vaan or­ke­stroin­ti­työ­ka­lu – konttien ylä­puo­lel­la toimiva hal­lin­ta­ker­ros.

Käy­tän­nös­sä tämä tar­koit­taa, että kaikkien Ku­ber­ne­te­sin parissa työs­ken­te­le­vien tulisi ymmärtää, ettei Docker enää toimi teknisenä perustana – vaikka monia kuvia onkin edelleen Docker-muodossa.

Mikä Docker-vaih­toeh­to sopii sinulle parhaiten?

Oikea Docker-vaih­toeh­to riippuu pitkälti omista tar­peis­ta­si:

• Parhaan tie­to­tur­van ta­kaa­mi­sek­si Podman on paras valinta.
• Suo­ri­tus­ky­kyi­siin ra­ken­nuk­siin BuildKit erottuu edukseen, kun taas Kaniko on suo­si­tel­ta­va pil­viym­pä­ris­töis­sä.
• Koko jär­jes­tel­mien eris­tä­mi­seen LXC/LXD on parempi vaih­toeh­to.
• Täy­del­li­seen hal­lin­taan ajon aikana runC on kevyt ratkaisu am­mat­ti­lai­sil­le.

Loppujen lopuksi kannattaa katsoa Doc­ke­ris­ta pi­dem­mäl­le – konttien maailma on mo­ni­puo­li­sem­pi kuin koskaan aiemmin.