Docker vai Podman? Käynnistysnopeus ei ratkaise, käyttöoikeudet ratkaisevat

29. syyskuuta 2026 klo 23.00|Kirjoittaja: QUASAn toimitus|4 min lukuaika| 1

Valitse Podman, jos ylläpidät Linux-palveluja tavallisena käyttäjänä ja haluat systemd:n hallitsevan niitä. Valitse Docker, jos kehitys ja CI-työ rakentuvat jo Docker Composen ja Dockerin rajapintaa käyttävien työkalujen varaan. Myös Dockerin voi ajaa juurettomana. Silloin valintaa ohjaavat ennen kaikkea käyttöoikeudet, tallennus ja nykyisen työnkulun yhteensopivuus.

Yksi julkaistu käynnistysmittaus ei anna kummallekaan yleistä nopeusvoittoa. Siinä verrattiin eri oikeuksilla ajettuja kokoonpanoja, ja valmiiksi ladatun testikontin käynnistysajat olivat lähellä toisiaan. Palvelimen valinnassa olennaisempaa on, kuka saa hallita kontteja ja niiden tiedostoja sekä mitä nykyiset työkalut odottavat konttimoottorilta.

Juureton ajo muuttaa oikeuksia, mutta asettaa tallennukselle ehdot

Podmanin käyttöohje kuvaa sen daemonittomaksi konttimoottoriksi: tavallisena käyttäjänä ajettaessa käyttäjän nimiavaruus luodaan automaattisesti, kun tarvittavat alisteiset käyttäjä- ja ryhmätunnisteet on määritetty. Saman ohjeen mukaan NFS:n kaltaiset hajautetut tiedostojärjestelmät eivät tue juurettoman Podmanin tarvitsemaa käyttäjän nimiavaruutta. NFS:llä sijaitseva kotihakemisto on silti mahdollinen, jos konttien graphroot-tallennusalue ohjataan paikalliselle levylle.

Tämä tallennusraja on konkreettinen itse ylläpidetyssä palvelussa. Jos käyttäjien kotihakemistot tulevat verkosta, Podmanin oletuksena käyttämä konttien tallennuspaikka voi osua väärälle tiedostojärjestelmälle. Konttien kuvien ja kerrosten sijainti on eri kysymys kuin sovellukselle liitettävän datan sijainti; myös liitettyjen hakemistojen omistus ja kirjoitusoikeudet on sovitettava palvelun käyttäjälle.

Dockerin juurettoman tilan ohjeen mukaan sekä daemon että kontit toimivat tavallisen käyttäjän nimiavaruudessa. Tämä eroaa Dockerin userns-remap-asetuksesta, jossa daemon toimii edelleen pääkäyttäjän oikeuksilla. Juureton Docker vaatii oman käyttöönottonsa ja alisteiset tunnistealueet, mutta daemon pysyy sen arkkitehtuurissa. Jos tavoitteena on rajata myös daemonin oikeuksia, Dockeria ei siis tarvitse sulkea pois.

Juurettomuus ei yksin kerro, saako palvelu tarvitsemansa käyttöoikeudet. Konttiin liitetty hakemisto voi edelleen olla väärän käyttäjän omistuksessa, ja verkkoon julkaistavat portit on sovitettava valittuun oikeusmalliin. Podmanin daemonittomuus vähentää pysyviä taustaprosesseja; Dockerin juureton tila puolestaan säilyttää Dockerin daemonia käyttävän työnkulun ilman pääkäyttäjänä toimivaa daemonia.

Compose-yhteensopivuus painaa kehityksessä ja CI:ssä

Docker on vaivattomin jatko, jos sama Compose-määritys kulkee kehittäjän koneelta CI-putkeen ja palvelimelle. Podman osaa käyttää Compose-työnkulkuja, mutta Podmanin Compose-ohjeen mukaan sen komento on ohut kääre ulkoisen toteuttajan, kuten docker-composen tai podman-composen, ympärillä. Komento välittää työn tälle ohjelmalle ja järjestää yhteyden Podmanin paikalliseen socketiin.

Se tarkoittaa, että samannäköinen komentorivi ei takaa koko putken toimivan sellaisenaan. Erityisesti Dockerin socketia käyttävät testaus- ja kehitystyökalut sekä Compose-toteutuksen erityisominaisuuksiin nojaavat määritykset on arvioitava kyseisessä työnkulussa. Jos työ on lähinnä yksittäisten kuvien rakentamista ja konttien ajoa, riippuvuus voi olla pieni. Monipalveluisessa Compose-pinossa yhteensopivuus voi painaa enemmän kuin konttimoottorin oma toimintamalli.

Quadlet tekee Podman-konteista systemd-palveluja

Podmanin Quadlet sopii pitkäikäisiin Linux-palveluihin, kun ylläpito on jo rakennettu systemd:n ympärille. Quadletin ohje kertoo, että esimerkiksi konttia kuvaavasta .container-tiedostosta luodaan tavallinen systemd-palveluyksikkö. Sen käynnistystä ja riippuvuuksia voidaan hallita systemd:n keinoin, ja määritys voi olla käyttäjäkohtainen tai järjestelmänlaajuinen.

Juureton Quadlet-tiedosto kuuluu käyttäjäpalvelujen hakupolkuun, esimerkiksi käyttäjän containers/systemd-hakemistoon. Pelkkä systemd-yksikön User-asetus ei tee Quadletista juuretonta. Käynnistyksessä on lisäksi huomioitava kuvan haku tai rakentaminen: se voi kestää pidempään kuin systemd:n palvelulle oletuksena sallima käynnistysaika. Dockerin juuretonta daemonia voi myös hallita käyttäjän systemd-palveluna, mutta Quadletilla yksittäinen kontti määritetään suoraan systemd:n hallittavaksi palveluksi.

Mittaus erottaa käynnistyksen, muistin ja verkon

Botmonsterin yhdellä Linux-koneella tekemässä 20 ajon kokeessa valmiiksi ladatun Alpine-kuvan käynnistys vei Dockerilta keskimäärin 352 millisekuntia ja juurettomalta Podmanilta 342 millisekuntia. Mittaaja piti eroa mittauskohinan sisään jäävänä. Kokeen Docker toimi pääkäyttäjän oikeuksilla, Podman juurettomana, joten tulos kuvaa juuri näitä kokoonpanoja eikä samalla oikeustasolla tehtyä vertailua.

Samassa kokeessa Dockerin taustaprosessit käyttivät muistia myös ilman käynnissä olevia kontteja, kun taas Podmanilla ei ollut vastaavaa pysyvää daemonia. Siitä ei seuraa, että käynnissä oleva Podman-palvelu olisi kuluton: juureton verkkoyhteys voi tarvita oman apuprosessinsa. Muistin tarve riippuu myös siitä, kuinka monta konttia ajetaan ja jaetaanko niiden verkkoympäristö.

Julkaistuun porttiin suuntautuvassa latauksessa Podmanin pasta-verkkotapa pärjäsi kokeessa Dockerin bridge-verkkoa paremmin. Vertailu koski näitä verkkopolkuja yhdellä koneella; se ei osoita kaikkien Podman-verkkojen olevan kaikkia Docker-verkkoja nopeampia. Pitkäikäisessä palvelussa tallennuksen ja verkon toiminta omalla kuormalla kertoo enemmän kuin nopeasti päättyvän testikontin käynnistysaika.

Valinta käyttötavan mukaan

Podman sopii käyttäjäkohtaisiin Linux-palveluihin, kun konttien tallennus saadaan paikalliselle levylle ja palveluja halutaan hallita Quadletin kautta systemd:llä.
Docker sopii työnkulkuun, jossa Compose-määritykset ja Dockerin rajapintaa käyttävät työkalut ovat jo keskeisiä. Juureton tila on mahdollinen myös siinä, jos daemonin oikeuksia halutaan rajata.
NFS:llä sijaitseva kotihakemisto tekee Podmanin graphroot-sijainnista valintakysymyksen. Dockerin socketiin sidottu CI-putki tekee puolestaan yhteensopivuudesta valintakysymyksen.

Käynnistysmittauksen pieni ero ei poista näitä käyttöehtoja. Sopiva konttimoottori on se, jonka oikeudet, tallennuspaikat ja palvelujen hallintatapa sopivat kyseiseen Linux-ympäristöön.

Lue myös:

Jaa: