Hvis du er til virtualiserings- og containeriseringsverdenen, har du sandsynligvis stødt på Podman og Docker, og du undrer dig måske over, hvordan de adskiller sig fra hinanden.
I dette indlæg vil vi udforske forskellene mellem Docker og Podman og prøve at finde, hvilken der vil være det rigtige valg for dig!
Indholdsfortegnelse
Docker
Docker er en containeriseringsteknologi, der letter afhængighedsstyring inden for et projekt på alle niveauer (udvikling og implementering).
Dockers mekanisme, som er tilgængelig på Linux, Windows og Mac OS, er centreret omkring containere og deres orkestrering, og det er her containerisering adskiller sig fra virtualisering.
Docker har to hovedbyggeblokke: Docker CLI og Docker Daemon.
Docker Daemon:
Det er en konstant baggrundsproces, der hjælper med at administrere Docker-billeder, containere, netværk og lagervolumener. Docker bruger sin Docker Engine REST API til at interagere med Docker-dæmonen, der tilgås via HTTP-protokol.
Docker CLI:
Billedkredit: Redhat
Det er Docker-kommandolinjeklienten til at interagere med Docker-dæmonen. Det er det, du bruger, når du kører enhver Docker-kommando.
Driften af Docker er baseret på Linux-kernen og funktionerne i denne kerne, såsom cgroups og navnerum. Disse funktioner adskiller processerne, så de kan køre uafhængigt, da formålet med containere er at køre flere processer og applikationer separat.
Det er det, der gør det muligt at optimere brugen af infrastrukturen uden at reducere sikkerhedsniveauet i forhold til de separate systemer.
Alle containerværktøjer som Docker kommer med en billedbaseret implementeringsmodel. Denne model forenkler deling af en applikation eller et sæt tjenester på tværs af flere miljøer.
Derudover hjælper Docker med at automatisere implementeringen af applikationer i et containermiljø. Med disse forskellige værktøjer får brugerne fuld adgang til applikationer og kan accelerere implementeringen, kontrollere versioner og tildele dem.
Podman
Podman (POD MANageren) bygger, kører og administrerer OCI-containere og containerbilleder. Det blev udviklet af Red Hat og oprindeligt beregnet til virksomhedens Linux 8. Det bruges til containerstyring og fungerer som den officielle efterfølger til Docker.
Red Hat stoppede derfor supporten til Docker, men forsikrede, at skiftet ville være let for brugerne, da Podman er baseret på Docker, selvom det oprindeligt kun var tænkt som et fejlfindingsværktøj.
Det styrer hele container-økosystemet ved hjælp af libpod-biblioteket. Da Podman kun fungerer på Linux-platforme, er en REST API og klienter i øjeblikket under udvikling for at tillade Mac- og Windows-systemer at kalde tjenesten.
Der er dog i øjeblikket en Varlink-baseret fjernklient, der fungerer på Mac- eller Windows-platforme, som tillader fjernkommunikation med en Linux-baseret Podman-server. Libpod-biblioteket understøtter flere metoder til at uploade billeder sikkert, inklusive tillid og billedbekræftelse.
Det understøtter også pods til at administrere grupper af containere sammen og flere billedformater, inklusive OCI- og Docker-billedformater.
I meget små og overskuelige miljøer kan Podman endda fungere som en forløber for Kubernetes. Det bygger bro mellem den enestående styring af individuelle instanser fra de tidlige år af containerhypen og moderne orkestrering med Kubernetes.
Ambitiøse containerbrugere kan allerede nyde det næste niveau med pods. Konstruktion og drift af en Kubernetes-klynge er ikke længere nødvendig. I det enkleste tilfælde kan nydesignede pods testes og forbedres i individuelle operationer. Selv en efterfølgende overførsel til Kubernetes er mulig.
Kommandoen podman generer kube leverer de tilsvarende konfigurationsfiler. Disse tjener derefter en-til-en som input til Kubernetes-værktøjet kubectl.
Nuværende versioner af Podman kan endda oprette konfigurationsfiler til systemd – en godbid for alle, der bruger den allestedsnærværende init-efterfølger til containerorkestrering.
Podman vs Docker: Forskelle
Docker har hurtigt etableret sig som hobbyhesten til håndtering af containere. Docker har dog mange fordele og frem for alt det hastigt voksende repertoire af billeder, samt ulemper og mulige sikkerhedsrisici. Desuden understøttes Docker ikke længere som en container til Kubernetes.
At containere i modsætning til virtuelle systemer ikke kræver deres kerne, ses normalt som en af de helt store fordele. Det udgør dog en stor sikkerhedsrisiko med Docker, fordi Docker-containere kun kan køres med root-rettigheder.
Det tillader processer, der kører i containerne, at få adgang til kernen med root-privilegier og dermed angribe værtssystemet.
Den første forskel er tydelig, når du bruger den første gang. Mens Docker kræver, at Docker-dæmonen startes først, kan en Podman-beholder startes direkte fra kommandolinjen. Så der er ingen baggrundsproces, og applikationen udføres kun, når det er nødvendigt.
Fra et sikkerhedsperspektiv er dette godt, fordi Podman er mindre sårbar over for angreb, hvis dæmonen ikke skal køre 24/7 med superbrugerrettigheder. Podman kræver ikke en baggrundsproces på grund af arkitekturen, som adskiller sig fundamentalt fra Docker.
Mens Docker følger klient-server-modellen, hvor Docker-klienten kommunikerer med Docker-dæmonen via en API, følger Podman fork-exec-modellen. Hver container kører som en underordnet proces af Podman.
Et brugernavneområde oprettes ved første brug, når Podman køres med normale brugerrettigheder. I brugernavnerummet kører Podman med root-privilegier og har rettighederne til at montere filsystemer og oprette containere.
Derfor har Podman-beholderen kun de rettigheder, som den udførende bruger har. Brug af brugernavneområder betyder, at hver bruger kan oprette og administrere deres egne containere, men disse er ikke synlige for andre brugere og superbrugeren.
Fordi Podman drives uafhængigt af Docker, har udviklerne et stort spillerum og kan reagere på fællesskabets ønsker. Interessante tilføjelser til Podman inkluderer mount/unmount kommandoen og systemd integration.
Værten kan bruge kommandoen mount/unmount til at montere containerens filsystem, for eksempel for at få adgang til eller ændre filer og derefter afmontere dem igen.
Mens overvågning af containerne ved hjælp af systemd ikke virker på grund af dæmonen i Docker med Podman, kan containere startes, overvåges og endda genstartes via systemd.
Derudover leverer Podman kommandoen podman generer systemd, som genererer en tilsvarende systemd service til den respektive container og dermed fritager brugeren for oprettelsen af systemd tjenesterne, hvilket betyder at integrationen på værtssystemet er tilgængelig.
En anden afgørende forskel mellem Podman og Docker er, at sidstnævnte ikke ændrer firewall-reglerne eller den aktuelle dnsmasq-installation på grund af dens evne til at skabe et internt netværk. I modsætning hertil er Docker nødt til at overskrive firewall-reglerne for at muliggøre inter-container-kommunikation.
PodmanDockerArchitecture DaemonDaemon lessServices Management SystemdDocker EngineFirewall-kompatibilitet Overskriver firewallregler Overholder firewallreglerPlatformNative support til linuxLinux, Windows og Mac
Hvornår skal du migrere fra Docker til Podman
Hvis du implementerer containere i et RHEL-baseret miljø, har du i så fald ikke mange muligheder bortset fra at bruge Podman, da det er RHEL-native. Du kan også migrere til eller vælge Podman frem for Docker, hvis du har små implementeringer med få containere.
Men hvis du ønsker at blive mere kompleks end det, skal du have flere containere og en stak af koordinerende containere med docker-compose/podman-compose over et netværk. Det er bedre at bruge Docker, da det håndterer netværk meget bedre.
Tilsvarende, hvis du lige er begyndt at komme ind i containerverdenen, er Docker i så fald en bedre mulighed, da den er stabil, veletableret med ordentlig dokumentation og har en overfladisk indlæringskurve sammenlignet med Podman, som stadig mangler stabilitet og ikke har veldefineret dokumentation.
Migration fra Podman til Docker
Hvis du er på kommandolinjen, er det ret nemt at skifte fra Docker Engine til Podman. På det enkleste fungerer et $-alias docker=podman-kommando det meste af tiden.
Dette forudsætter naturligvis, at den relevante software er installeret på systemet. I tilfælde af Linux er dette heller ikke et problem; færdiglavede softwarepakker er tilgængelige for kommercielt tilgængelige distributioner.
Windows eller macOS er ikke blandt de understøttede operativsystemer. Alias-tilgangen fungerer, fordi mange Docker-kommandoer har en Podman-ækvivalent.
Men der er også undtagelser, da nogle Docker-kommandoer ikke har nogen pendant i Podman-verdenen. På samme måde opfører nogle kommandoer sig anderledes i Docker end i Podman-universet. På nuværende tidspunkt påvirker dette kun håndteringen af mængder, der allerede er opsat.
Skiftet er lidt sværere, når grafiske værktøjer såsom Docker Desktop er i brug. Det bør især påvirke de udviklere, der arbejder med Windows eller macOS.
Docker Desktop-brugere skal vænne sig til kommandolinjen, og det samme gælder for Docker compose. Der er dog podman-compose-projektet. Skrevet i Python fungerer softwaren som en erstatning for Docker compose.
Afsluttende ord
Udskiftningen af Docker af Podman kan anses for næsten færdig. For brugere og administratorer er de fleste aspekter af denne ændring nemme. Mange Docker-funktioner har identiske ækvivalenter i Podman.
En reel fordel er manglen på en enestående dæmonproces og root-privilegier, for ikke at nævne den naturlige brug af containergrupper. Det er dog værd at nævne, at Docker forbliver hovedteknologien vedrørende containere, men det vil højst sandsynligt ændre sig i det lange løb.
Du kan også udforske nogle Docker-kommandoer til at administrere containere.