Docker vai Podman? Suorituskykyero jäi pieneksi, arkkitehtuuri ratkaisi

Dockerin ja Podmanin valintaa ei kannata ratkaista oletetulla nopeusedulla: Tampereen yliopiston vuoden 2024 opinnäyte referoi erillistä neljän levytyökuorman mittausta, jossa suorituskykyero jäi pieneksi, ja dokumentoi omissa kokeissaan yhteensopivuusongelmia. Nopeusmittaus ja opinnäytteen yhteensopivuuskokeet ovat siis eri tutkimuksia.

Docker sopii yleensä helpoimmin ympäristöön, jonka rakentaminen, Compose-kokoonpanot ja kehittäjien työkalut on jo tehty Dockerille. Podman on vahva vaihtoehto Linuxissa, kun kontteja halutaan hallita käyttäjäkohtaisesti ilman jatkuvasti toimivaa keskitettyä taustapalvelua. Molempia voi käyttää ilman isäntäkoneen pääkäyttäjän oikeuksia; ratkaiseva ero on siinä, miten palvelu, sen oikeudet ja sitä käyttävät työkalut järjestetään.

Pieni mittausero ei ennusta oman sovelluksen nopeutta

Referoidussa mittauksessa verrattiin tiedostopalvelimen, verkkopalvelimen, sähköpostityökuorman ja satunnaisen tiedostokäytön levysuorituskykyä. Tulosta voi käyttää vastapainona väitteelle, että daemoniton rakenne tekisi Podmanista automaattisesti selvästi nopeamman. Se ei kuitenkaan mittaa jokaisen sovelluksen käynnistystä, verkkoliikennettä tai macOS:n virtuaalikoneen yli kulkevia hakemistoliitoksia.

Suorituskyvyn kannalta moottorin nimi on vain osa kokoonpanoa. Myös käytetty levyjärjestelmä, kontti-image, ajotapa ja rootless-asetukset voivat muuttaa tulosta. Jos valinta koskee levyintensiivistä palvelua, mielekäs vertailu tehdään saman sovelluksen ja samanlaisten asetusten välillä. Muussa tapauksessa mitattua pientä eroa painavampi peruste on se, käynnistyykö ja pysyykö oma palvelukokonaisuus kunnossa valitulla moottorilla.

Daemon ratkaisee, mitä palvelimella ylläpidetään

Dockerin komentorivi pyytää taustalla toimivaa Docker-daemonia rakentamaan ja hallitsemaan kontteja. Sen käynnistyminen, käyttöoikeudet ja rajapintaan pääsy ovat osa palvelimen ylläpitoa. Podmanissa tavalliset paikalliset konttikomennot eivät tarvitse vastaavaa jatkuvasti toimivaa keskitettyä daemonia. Tämä tekee käyttäjäkohtaisesta ajosta luontevan, mutta ei poista tarvetta järjestää palvelun automaattinen käynnistys ja valvonta.

Yksittäisen kontin käynnistäminen näyttää komentorivillä usein samalta kummassakin. Ero tulee näkyviin, kun palvelua käyttää useampi ylläpitäjä tai jokin toinen ohjelma odottaa Dockerin rajapintaa. Silloin on päätettävä, kenen käyttäjätunnuksella kontit ja imaget sijaitsevat, mikä käynnistää palvelun uudelleen ja mihin työkalut ottavat yhteyden. Olemassa oleva Docker-riippuvainen automaatio puoltaa Dockeria; käyttäjäkohtaisesti hallittu Linux-palvelu voi puoltaa Podmania.

Rootless onnistuu molemmilla, mutta ei samalla rakenteella

Podmanin daemonittomuus ja rootless-käyttö ovat eri asioita. Tavallinen käyttäjä voi hallita omia konttejaan, ja käyttäjän nimiavaruus erottaa kontin pääkäyttäjän isäntäkoneen pääkäyttäjästä. Käytännössä hakemistojen omistajuus ja käyttäjätunnusten vastaavuus vaikuttavat siihen, voiko kontti lukea tai kirjoittaa isännältä liitettyjä tiedostoja.

Dockerin rootless-ohje määrittelee tilan, jossa sekä daemon että kontit toimivat käyttäjän nimiavaruudessa ilman isäntäkoneen pääkäyttäjän oikeuksia. Daemon kuuluu siis edelleen Dockerin rakenteeseen, vaikka se toimisi tavallisen käyttäjän oikeuksin. Käyttöönotto edellyttää muun muassa käyttäjä- ja ryhmätunnusten alialueita sekä niitä käsitteleviä apuohjelmia. Rootless-vaatimus yksin ei siksi valitse moottoria: olennaista on myös, sopiiko käyttäjäkohtainen daemon vai daemoniton paikallinen käyttö ympäristön ylläpitomalliin.

Verkkoportit ja sidotut hakemistot kannattaa arvioida samassa yhteydessä kuin käyttöoikeudet. Etuoikeutettua porttia tarvitseva palvelu tai isännän tiedostoja kirjoittava kontti voi vaatia eri järjestelyt kuin pääkäyttäjän oikeuksin ajettu vanha kokoonpano. Nämä ovat sovelluksen käyttöönottoon liittyviä kysymyksiä kummallakin moottorilla, eivät yleinen lupaus siitä, että toinen olisi kaikissa oloissa turvallisempi.

Dockerfile-yhteensopivuus riippuu myös rakentajan versiosta

Podman pystyy rakentamaan imageja Dockerfile-tiedostosta, joten tavallinen rakennus ei yleensä vaadi tiedoston vaihtamista. Vuoden 2024 opinnäytteen kokeessa Dockerin hyväksymä COPY --link kuitenkin pysäytti Podman-rakennuksen. Samassa koesarjassa OCI-muotoiseen imageen kirjoitettu HEALTHCHECK jäi Podmanissa huomiotta varoituksen kanssa. Havainnot koskevat testattua kokoonpanoa, eivät kaikkia myöhempiä julkaisuja.

Juuri COPY --link osoittaa, miksi vanhaa yhteensopivuushavaintoa ei pidä lukea nykyiseksi ominaisuusluetteloksi. Buildahin muutosloki kirjaa ADD- ja COPY-käskyjen --link-tuen lisätyksi versioon 1.41.0 vuonna 2025. Podmanin rakennus käyttää Buildahia, mutta tuen käytännön toiminta riippuu asennetusta versiosta ja rakennusasetuksista. Dockerfile-erikoisominaisuuksiin nojaavassa julkaisuketjussa ratkaisevaa on onnistunut rakennus ja syntyvän imagen toiminta juuri niillä versioilla, joita ketju käyttää.

Imagen rakentaminen ja sen ajaminen ovat erillisiä yhteensopivuuskysymyksiä. Komennon hyväksyminen ei vielä kerro, tulkitaanko terveystarkistus odotetulla tavalla tai löytyvätkö imagen sisällöt oikeasta paikasta käynnistyvässä kontissa. Tämä ero on tärkeä erityisesti silloin, kun julkaisuputki käyttää rakentajan välimuistia tai sovelluksen valvonta perustuu imagen terveystietoon.

Compose tuo Podmaniin toisen toteuttajan

Docker Compose -tiedosto kuvaa usean palvelun kokonaisuuden, mutta tiedoston olemassaolo ei tee moottorien toteutuksesta identtistä. Podmanin Compose-ohjeen mukaan podman compose on kääre ulkoiselle toteuttajalle, kuten docker-compose- tai podman-compose-ohjelmalle. Komento välittää pyynnön tälle ohjelmalle ja järjestää sen yhteyden Podmaniin.

Podman-ympäristössä lopputulokseen vaikuttaa siten myös se, kumpi Compose-toteuttaja on asennettu ja valittu. Kehittäjän koneella toimiva tiedosto voi käyttäytyä eri tavoin CI-ympäristössä, jos toteuttaja tai sen versio vaihtuu. Monikonttisessa sovelluksessa huomio kohdistuu erityisesti palvelujen verkkoihin, levyliitoksiin ja käynnistysriippuvuuksiin. Jos nämä ovat projektin päivittäisen työn perusta, Dockerista siirtymisen vaiva määräytyy koko sovelluspinon eikä yhden podman run -komennon perusteella.

Mac-kehityksessä tiedostoliitos voi ratkaista valinnan

Macilla Podmanin kontit kulkevat Linux-virtuaalikoneen kautta: Podman machine -ohje kuvaa virtuaalikoneen macOS-käytön edellytykseksi. Kun paikallinen projektihakemisto liitetään konttiin, tiedostot ylittävät tämän rajan. Se tekee hakemistoliitoksesta oman yhteensopivuuskysymyksensä Linux-palvelimella tehdyn kokeen rinnalle.

Opinnäytteen macOS-kokeessa Dockerin kontissa näkyi liitetty näytetiedosto, mutta Podmanin kontissa samaa tiedostoa ei löytynyt. Tulos koskee kyseistä testiasetelmaa eikä osoita, että Podmanin nykyiset Mac-liitokset yleensä epäonnistuisivat. Se kertoo silti olennaisen valintakriteerin kehittäjälle, jonka työ perustuu lähdekoodihakemiston välittömään näkymiseen kontissa: toimiva Linux-palvelin ei yksin takaa sujuvaa Mac-työnkulkua.

Valinta tiiviisti työnkulun mukaan

• Dockerfile: Molemmat rakentavat tavallisia Dockerfile-imageja. Erikoiskäskyjen ja terveystarkistusten käytös riippuu rakentajasta, imagen muodosta ja versiosta.
• Compose: Dockerille tehty monipalveluinen työ perustuu Docker Composeen. Podmanin compose-komento tarvitsee ulkoisen toteuttajan.
• Rootless ja daemon: Molemmat voivat toimia ilman isäntäkoneen pääkäyttäjän oikeuksia. Dockerissa myös rootless-käytössä on daemon; Podmanin paikallinen käyttö on daemonitonta.
• Linux-palvelin: Nykyiset Dockerin rajapintaan kytkeytyvät työkalut puoltavat Dockeria. Käyttäjäkohtainen, daemoniton hallinta puoltaa Podmania, kun palvelun käynnistys ja valvonta on järjestetty.
• macOS: Podman käyttää Linux-virtuaalikonetta, joten paikallisten kehityshakemistojen liitokset ovat osa valintaa.

Jos nykyinen sovellus toimii Dockerin rakentajan, Composen ja työkalujen varassa, Docker säästää todennäköisesti siirtymätyötä. Jos ensisijainen tavoite on käyttäjäkohtainen Linux-käyttö ilman keskitettyä konttidaemonia, Podman vastaa siihen suoremmin. Rajatussa levymittauksessa pieni nopeusero antaa vain vähän syytä ohittaa näitä käytännön eroja.

Lue myös:

• Docker vai Podman? Käynnistysnopeus ei ratkaise, käyttöoikeudet ratkaisevat
• Business Finland vai kehittämisavustus? Hankkeen sisältö ratkaisee rahoittajan
• Claude Code vai Codex? Valinta ratkeaa työnkulkuun, ei yhteen testiin