Containers
Podman: Containers zonder de Daemon
Podman is de containerengine van Red Hat, gebouwd op het no-daemon-antwoord op de grootste architecturale zwakte van Docker: containers draaien als kinderen van het aanroepproces, standaard rootless, met een Docker-compatibele CLI, zodat bestaande workflows grotendeels overleven. Het is de standaard containerengine op systemen uit de RHEL-familie en het eerlijke antwoord voor 2026 voor hosts waar de beveiligingsgrens ertoe doet.
Kernpunten
- De architectuur is fork-exec, geen daemon: elke container is een onderliggend proces van het podman-commando (containers/opslag opgesplitst in bibliotheken), waardoor de enige bevoorrechte luisteraar van de Docker-daemon en het aanvalsoppervlak voor het delen van sockets worden verwijderd; een gecrashte CLI neemt de containers nooit mee.
- Standaard rootless: gebruikers zonder rechten voeren echte werklasten uit via gebruikersnaamruimten (gebruikers worden toegewezen aan UID-bereiken op de host), waardoor vragen over 'container-escape' worden omgezet in gewone vragen over bestandsrechten; de handel is opslag/driver-nuances (fuse-overlayfs-klasse) en poortlimieten onder 1024 zonder aanpassingen.
- Docker-compatibiliteit is het migratiepad: de CLI is grotendeels drop-in (uitvoeren, bouwen, componeren via podman-compose of compose plug-ins), docker.sock-emulatie bestaat voor tooling die aandringt, en afbeeldingen pushen/pull uit dezelfde registers; CI-systemen en tools die op Docker aansluiten, blijven meestal onveranderd bestaan.
- Pods en infracontainers: podman groepeert containers in pods (gedeelde netwerknaamruimte), waar het Kubernetes-DNA te zien is (podman speelt goed met kube YAML voor lokale ontwikkelaar via podman play kube); kleine landgoederen krijgen een orkestrerende groepering zonder orkestrerende operaties.
- Systemd-integratie is de stille superkracht: quadlets (systemd-generatoren voor containers) drukken uit 'deze container is een service' met herstartbeleid, socket-activering en native afhankelijkheden, ter vervanging van de puinhoop van aangepaste eenheidsbestanden die Docker raw-implementaties altijd maakten; voor servers die op systemd staan, is dit het schoonste antwoord in de categorie.
- Eerlijke limieten: het gewicht van het ecosysteem (documenten, tools van derden, tutorials) leunt nog steeds op Docker, sommige tools gaan uit van docker.sock-paden, en Mac/Windows-desktops draaien in een machine-VM (hetzelfde als het Docker Desktop-model); op Linux-servers is de kloof vooral cultureel en niet technisch.
Notitie uit de praktijk
De versterkte gedeelde host van een klant draaide Docker met socket-gebonden beheertools; we hebben de werklast in een langzame week verplaatst naar rootless podman. De beveiligingsbeoordeling die volgde was de kortste ooit, en het operationele team merkte alleen de systemd quadlets op, die ze beter vonden dan de oude eenheidsbestanden.
Veelgestelde vragen
Kan ik gewoon een alias docker naar podman maken?
Grotendeels wel: het CLI-oppervlak en de registers zijn compatibel, en aliasing dekt het spiergeheugen; randgevallen leven in docker.sock-afhankelijke tooling en enkele minder gebruikelijke vlaggen, waarvoor de docker.sock-emulatie en documentatielacunes bestaan.
Is rootless echt een overwinning op het gebied van veiligheid?
Ja: de containerprocessen leven onder een onbevoegde hostgebruiker met gebruikersnaamruimtetoewijzing, dus zelfs een volledige container-escape stopt bij normale Unix-rechten in plaats van daemon-oppervlakken op rootniveau te bereiken; het verwijdert een volledige geprivilegieerde daemon-bedreigingsklasse.
Wat vervangt docker-compose-bestanden?
podman-compose of de compose-plug-in voeren dezelfde compose YAML in grote lijnen uit; voor systemd-native servers drukken quadlets de service-semantiek beter uit, dus kies compose parity voor dev-pariteit en quadlets voor prod-eenheden.
Wanneer is Docker nog steeds de betere keuze?
Wanneer uw landgoed standaardiseert op Docker-ecosysteemtools (CI-runners, registers met beleid, GPU-tools) en het daemon-bedreigingsmodel al is beperkt; beide motoren bestaan naast elkaar, kies per host in plaats van per campagne.
Hoe Kinetikatech helpt bij containers
U hoeft geen expert te worden in containers: Management, orchestration and security of containers in production environments. Precies daarvoor bestaat Serverbeheer en Linux-serverbeveiliging: setup, hardening, monitoring en een engineer met bereikbaarheidsdienst, dag en nacht.