En containerbaseret applikation har brug for en passende driftsmodel. Docker Compose kan være nok til en produktionsservice med overskuelig kompleksitet. Kubernetes bliver relevant, når applikationer skal køre på flere maskiner, og udrulningen kræver koordineret styring. Beslutningen begynder med applikationens krav.
En virksomhed driver en intern portal med webgrænseflade, database og baggrundsbehandling. Den har et servicevindue, en overskuelig belastning og en udpeget administrator. En anden virksomhed udgiver nye versioner af flere tjenester flere gange om ugen og skal forblive tilgængelig under planlagt vedligeholdelse. Begge bruger containere, men forskellige driftsmodeller kan passe til dem.
Docker, Compose og Kubernetes har forskellige opgaver
En containerruntime kører containerne. Docker Engine tilbyder en udbredt platform til det. Docker Compose beskriver en applikations tjenester i en YAML-fil. Her kan images, netværk, vedvarende volumener og konfiguration samles. Compose-værktøjerne opretter og administrerer applikationen på den Docker-vært, de er forbundet til.
Kubernetes styrer en ønsket tilstand for arbejdsbelastninger i en klynge. Det placerer Pods på egnede noder og kan erstatte administrerede instanser eller opdatere dem gradvist. Hver node har stadig brug for en egnet containerruntime. En Compose-fil og Kubernetes-ressourcer beskriver udrulning forskelligt, så migrering kræver mere end at omdøbe en fil.
Virksomhedens størrelse siger ikke meget om valget. Et lille softwareteam med hyppige udgivelser kan have gavn af orkestrering. En langt større virksomhed kan være godt tjent med én ordentligt vedligeholdt vært til en enkelt understøttet forretningsapplikation.
Docker Compose er også beregnet til produktion
Docker dokumenterer udtrykkeligt brug af Compose i produktion, især på én server. Udviklings- og produktionskonfigurationer kan holdes adskilt eller udvides til bestemte behov. Genstartspolitikker, offentliggjorte porte, logning og opdateringsprocessen skal passe til produktionsmiljøet.
For en intern dokumentportal kan det være en enkel løsning: et overskueligt sæt tjenester, dokumenterede versioner, beskyttede data og afprøvet gendannelse. Værtens nedbrud kræver stadig en særskilt plan. En genstartspolitik flytter ikke en applikation til en anden maskine. Redundans i en underliggende virtualiseringsplatform og applikationsbackup er også separate lag.
Den installationsmetode, softwareleverandøren understøtter, har også betydning. En officielt vedligeholdt Compose-installation kan være mere værd i driften end en specialbygget klyngeinstallation uden en pålidelig opdateringsvej.
En beslutningsmatrix for drift
| Spørgsmål | Docker Compose på én vært | Kubernetes |
|---|---|---|
| Hvor stort er miljøet? | Passer til enkelte applikationer med et overskueligt sæt tjenester. | Flere arbejdsbelastninger og noder kan styres gennem fælles platformspolitikker. |
| Hvad sker der, hvis en vært svigter? | Gendannelse eller infrastrukturredundans organiseres uden for Compose. | Erstatning på andre noder er mulig, når applikation, kapacitet, kontrolplan og dataadgang er forberedt til det. |
| Hvordan udrulles nye versioner? | De berørte tjenester erstattes gennem en dokumenteret og efter behov automatiseret proces. | Udrulningsregler understøtter kontrollerede rollouts. Dataændringer og funktionstest kræver stadig deres egen plan. |
| Hvor ligger forretningsdata? | I volumener eller eksterne tjenester med egne backup- og gendannelsesprocedurer. | I vedvarende lager eller eksterne tjenester, hvis robusthed og backup fortsat skal vurderes. |
| Hvem vedligeholder platformen? | Ansvaret omfatter vært, runtime, images og applikation. | Det omfatter også klynge, netværksintegration, lagerintegration og deres livscyklus. |
| Hvordan vurderes tjenestens tilstand? | Vært, tjenester og forretningsprocesser overvåges. | Klyngen og samspillet mellem platformskomponenter overvåges også; en kørende Pod er ikke nok. |
| Hvad understøtter leverandøren? | Den understøttede installation og dens opdateringsvej er afgørende. | En driftsklar Kubernetes-installation og passende leverandørsupport skal være til rådighed. |
Hvornår Kubernetes giver en konkret fordel
En god grund kan være behovet for ensartet styring af mange lignende udrulninger eller deling af ledig kapacitet mellem flere tjenester. Hyppige opdateringer med klare udrulningsregler og adskilte ansvarsområder kan også tale for det. Det kræver en applikation, der kan køre i flere instanser, og personer, der kan håndtere det ekstra platformsarbejde.
Før en tjeneste vælges, skal det afklares, om udbyderen administrerer kontrolplanet, hvilke komponenter man selv vedligeholder, og hvilke opgaver ved hændelser der bliver tilbage. En administreret klynge reducerer bestemte platformsopgaver. Ansvaret for applikationer, adgangsrettigheder, data og omkostninger består.
Antagelser om fælles data er en typisk faldgrube. Kan forretningsapplikationen arbejde med flere aktive instanser? Hvor skriver den filer? Hvor ligger sessionerne? Kan en baggrundsopgave gentages sikkert? Det skal afklares før migrering. En tilgængelig container beviser ikke, at ordrer bliver behandlet korrekt.
Arbejdet omfatter hele livscyklussen
Server- eller cloudregningen er ikke nok til en sammenligning. Implementering, dokumentation, opdateringer, overvågning, backup og tid brugt på hændelser tæller også. Kubernetes kræver desuden platformskompetence og koordinering mellem klynge, netværk og lager. Standardiseret drift kan mindske tilbagevendende arbejde, men standarden skal først etableres og vedligeholdes.
Tre scenarier giver en nyttig omkostningssammenligning: fortsætte en ordentlig drift af den eksisterende applikation, standardisere den på Compose eller indføre en Kubernetes-platform. Brug de samme forretningskrav i alle scenarier. Ellers kan man let sammenligne en enkel enkeltserver med et langt højere tilgængelighedsmål uden at gøre forskellen klar.
Sådan træffes en velbegrundet beslutning
- Definér driftskrav: beskriv acceptabel nedetid, servicevinduer, datatab og forventede ændringer.
- Vurdér applikationen: registrér understøttede installationer, flere instanser, filer, sessioner og eksterne grænseflader.
- Fordel ansvaret: udpeg ansvarlige for vedligeholdelse, alarmer, gendannelse og dækning ved fravær.
- Test én tjeneste: afprøv opdatering, nedbrud og gendannelse i det foreslåede miljø, og dokumentér arbejdet.
- Udvid derefter: vurdér flere applikationer efter de samme kriterier.
DAXS forbinder vurderingen af applikationen og dens grænseflader med infrastrukturplanlægning og en passende driftsmodel. En konkret tjeneste, dens afhængigheder og de ønskede driftsresultater er nok til en første vurdering. En personlig samtale begynder der.
Kilder: Docker: Compose-applikationsmodellen · Docker Compose i produktion · Kubernetes: komponenter og ansvar · Kubernetes: Deployments og rollouts · Planlægning af et Kubernetes-produktionsmiljø
