Dette er en relativt kjapp oversikt over hvordan vi bruker Kubernetes og skyen for å drifte Craft CMS og WordPress. Sett fra et drifts perspektiv fungerer de stort sett likt. Begge er PHP CMS-er med en database. Relatert til Kubernetes trenger de tre ting som skiller de fra f.eks en typisk stateless Node.js tjeneste:
- Jevnlig oppdateringer
- Permanent lagring
- En database
Container imager, poder og oppdateringer
For WordPress bruker vi enkelt å greit dockers offisielle image. Vår erfaring med den er utelukkende positiv og vi har ennå til gode å oppleve problemer med det. I tillegg har poden en SFTP container for redigering av innhold, mer om dette senere.
For Craft CMS som er en langt mindre utbredt CMS har vi sett oss nødt til å lage et eget image. Det er basert på det offisielle docker php imaget. Foruten diverse biblioteker og verktøy for Craft har containeren også Nginx og SSH server.
STFP og SSH serverene tjener samme todelte formål: Å effektivt kunne kjøre oppdateringer og effektivt utføre mindre endringer på nettsiden. Vi prøvde et par piloter der Craft kjørte stateless å det fungerte bra i drift, men vedlikeholdet ble fort krevende da vi måtte gjennom mange steg for å gjøre rutine oppdateringene på hver side:
- Klone live databasen og git repoet
- Kjøre oppdateringen,
- Bygge og pushe container imaget til repoet
- Bytte ut live databasen med klonen vi nettopp kjørte oppdateringen på
- Starte om poden og pulle det nye imaget
Det hadde latt seg gjøre, å vi har gjort det, men sammenlignet med å kjøre sidene med permanent lagring var det ikke verdt det for oss. Vi mister også tilgangen til et helt økosystem med verktøy for å automatisere oppdateringer og vedlikehold.
Lagring
Her benytter vi to forskjellige løsninger. For persistent volume i Kubernetes bruker vi Block Storage fra samme datasenter som drifter Kubernetes. Block storages blir brukt for backend filene til CMS-en og templatene vi bygger på de. For media og filer lastet opp fra redaktørene benytter vi S3-kompatibel lagring med CDN. Fordelen er kjappere levering og et logisk skille mellom systemfiler og de redaktørene har lastet opp.
Database
Det finnes løsninger for å drifte egne databaser internt i clusteret og hybrider, men for vår bruk er det ikke formålstjenlig. Så vi benytter heller databaser driftet av skyleverandøren vår (Digital Ocean) utenfor clusteret. For vår del er det en mindre tjeneste vi trenge å vedlikeholde og bruke tid på. Siden vi opererer på en såpass liten skalaen blir tiden brukt uforholdsmessig stor i forhold til påslaget vi betaler for noen andre tar jobben.
Helm
Slik oppsettet er i dag har vi laget egne Helm charts for begge CMS-ene som deployes ved hjelp av Kubeapps. Det er et webgrensesnitt som er koblet opp mot det interne Helm repoet vårt (Chartmuseum) og snakker med clusteret. Her kan vi se og gjøre endringer på eksistrende utgivelser og lansere nye med å fylle ut et enkelt skjema generert fra charten. Etterpå går resten av seg selv og nettsiden er oppe å går iløpet av 4-5 minutter. Illøpet av den tiden har poden lastet ned og startet opp containerne, Certbot har satt opp SSL sertifikater for en eller flere domener, det er allokert permanent lagring og poden har fått tilhørende ingresser og servicer. For å flytte en nettside fra utvikling til produksjon er det så enkelt som å klikke på den i Kubeapps og endre URL-feltet til live domenet så oppdateres ingressen og SSL sertifikate seg selv å nettsiden er ute i produksjon.
Siden utvikling og drift av nettsider er det vi primært lever av blir det en del nye nettsider i løpet av et år, så denne effektiviseringen har vært kjærkommen. Tidligere hadde vi en liste med punkter vi måtte huske å utføre for at en nettside skulle være oppe å gå, nå fyller vi bare ut en bestilling på en nettside å resten går av seg selv.
Marius Stenbakk
Marius er drifter og web utvikler. Han tar gjerne en prat om web apps, nettsider eller Kubernetes!