DevOps - vad är det och hur funkar det?

Namnet DevOps härstammar från orden ”development” och ”operations”. Många misstolkar denna sammanslagning och tror att om man driftar och utvecklar så använder man sig av DevOps-flödet. Men DevOps innebär så mycket mer än bara utveckling och drift. Grovt sett så innebär det att ett team utvecklar, driftar, testar, integrerar och övervakar applikationen i ett automatiserat flöde. Det är ett sätt att utveckla mjukvara/system. Det innebär egentligen en full livscykelhantering av en applikation.

Med DevOps-principen kan ett team släppa nya versioner samt göra buggrättningar och där efter distribuera applikationen till produktionsmiljö med bibehållet god kvalité utan att involvera flera avdelningar och andra team. Att ofta släppa nya versioner och rättningar medför att man kan både lita på och känna sig trygg med sin produktionsmiljö eftersom man berör den ofta. Om man istället rör produktionsmiljön sällan blir det större risk att något går fel när man väl ska släppa en ny version, vilket kan bero på dåligt uppdaterad miljö, osäkerhet hur miljön fungerar och så vidare.

Tanken med att utveckla enligt DevOps-principen är att nå ut snabbare till marknaden, snabbare release-cykler, högre grad av test, snabbare distribuering och snabba felrättningar. Tanken är även att man ska enkelt kunna rulla tillbaka efter release ifall något kritiskt fel upptäcks efter man släppt senaste versionen. DevOps är även tänkt att minska missförstånd mellan olika delar i en organisation då alla är inblandade i samma kedja och det finns inte längre några tydliga avskärmningar mellan driftpersonal, testarna och utvecklarna.

 

DEVOPS PÅ TECH DAYS

Vill du veta mer om devops, microservices, containers och hur de hänger ihop samt hur man bygger säkerhet för dem? Besök Tech Days i april där Magnus B. Persson från Cygate kommer att prata om just detta.

Läs mer om Tech Days

DevOps-metodologin brukar delas upp i följande delar:

  1. Utveckling
  2. Bygga applikationen (automatiserat)
  3. Testa (automatiserat)
  4. Paketera (versionshanteras automatiskt)
  5. Distribuera till produktion/staging/test
  6. Konfiguration av infrastruktur (manifest som beskriver miljön)
  7. Monitorering (prestanda, resursutnyttjande, skalning, användarupplevelse etc.)

För varje steg i DevOps-principen finns det ofta verktyg som hjälper till att skapa ett automatiserat flöde och hantering för att underlätta varje steg. Nedan beskrivs varje del i DevOps-metodologin och ett antal exempel på verktyg ges.

Utveckling

För utveckling spelar det ingen större roll vilken editor man använder, det viktigaste är att man använder en versionshanterare som t.ex. Git. Det är viktigt att ha ett spikat flöde hur gruppen använder versionshanteringen. Det kan betyda att olika grenar ska användas. Det vill säga grenar för release, staging, test, nya funktioner och buggrättningar. Man vill helst undvika för många merge-konflikter om flera i gruppen jobbar samtidigt i samma grenar. Det finns många best practices man kan följa eller ta lärdom av.

Bygge

Att bygga applikationen ska med fördel ske automatiskt via ett byggsystem. Byggsystemet kan direkt hämta från versionshanteringssystemet och bygga för både test, staging och release. Det kan vara så att man vill bygga varje natt eller kanske vid varje förändring i källkodsträdet. Det medför att man snabbt upptäcker förändringar som leder till problem.

Verktyg som till exempel Jenkins är bra alternativ för att automatisera byggen.

Test

Automatiserade tester är viktigt då det medför att de körs oftare än om någon manuellt skulle utföra dem. Så att automatisera så mycket som möjligt är viktigt. Att köra grundläggande-tester och integrations-tester efter varje bygge med automationsverktyg så som Jenkins medför hög grad av testning. Helst ska systemtester också automatiseras och köras, men kanske inte behöver köras lika ofta.

Viktigt är att utvecklare får återkoppling på när tester går fel så att man snabbt kan åtgärda problemen och låta bygg/test-system köra nya tester.

Paketering

Paketering av leverabler i ett versionshanterat format behövs för att enkelt kunna skapa stage och testmiljöer samt göra tillbakarullningar av releaser som skapat problem. Det finns system som är designade att hantera detta. Men det kan egentligen vara en lagringsyta eller vanligt versionshanteringssystem. Det viktigaste är att man har kvar paketerade byggen så man kan gå tillbaka till tidigare versioner.

Distribution (release)

Även distribueringen bör ske automatiskt. Det finns många verktyg för att göra det. Kör man sin applikation i containers så kan man ta hjälp av färdiga cloud-tjänster för hantering av omstarter/uppdateringar av containers. Men det går självklart bygga egna system där man kan nyttja API:er mot diverse IaaS och PaaS tjänster. För många programspråk finns även automatiserade verktyg för att hantera distribuering. Exempel på ett sådant verktyg är Capistrano för Ruby. Man kan även ta nytta av automatiseringssystem som Ansible, Chef eller Puppet som går att scripta för att hantera sin miljö. Mer om det i nästa steg.

Konfiguration av infrastruktur

Infrastruktur som kod är ett numera populärt begrepp. Vad det innebär är egentligen att man specificerar sin driftsmiljö med hjälp av manifest eller konfigurationsfiler. Det kan vara med hjälp av Ansible, Chef eller Puppet som nämndes tidigare. Det kan även vara manifest i form av Docker Compose, Kubernetes manifest eller YAML-konfigurationsmanifest i OpenShift. Ett manifest i OpenShift och Kubernetes dikterar hur många instanser av en viss container det ska få finnas, om en container får köras på samma som en annan typ av container, vilken hårdvara en viss container ska köras på, vart applikationen finns etc.

Ansible, Chef och Puppet har konfigurationsfiler som dikterar hur en viss typ av server ska konfigureras. Det kan vara en dedikerad, virtuell eller container som agerar server. Konfigurationsfilerna (kallas playbooks i Ansible) beskriver hur en server ska sättas upp och vad som ska vara installerat på den, hur applikationen ska exekveras etc. Verktyget ser sedan till att servern håller samma uppsättning vid efterföljande körningar.

Monitorering

Den sista delen i DevOps flödet är monitorering. Det finns många verktyg som hjälper till med det. Beroende på applikation så passar olika verktyg olika bra. Använder man t.ex. Kubernetes eller OpenShift så kan man via deras gränssnitt se hälsostatus på sina applikationer/containers. Man kan även följa dess last och historik. Det finns även stöd för autoskalning baserat på lasten för applikationen.

För att hantera loggar så kan man använda sig av log-drains där alla loggar lagras och kan processas/göras sökbara. Det finns både verktyg (Splunk) och tjänster för det ändamålet (Fluentd, LogStash, Papertrail).

Det är också viktigt att övervaka sin applikation ur ett användarperspektiv. Fungerar applikationen? Fungerar websidan från alla delar av världen? Är det några DNS problem? Kan man lägga ordrar? Går databasen att nå?

Devops och Microservices

DevOps och microservices kan ofta höras i samma sammanhang. DevOps passar nämligen väldigt bra ihop med microservices där varje team har hand om en modul/tjänst i microservices strukturen. Varje team utvecklar, testar och levererar efter DevOps-principen. Det medför snabba rättningar/uppdateringar per tjänst utan att skapa en stor sammanslagen leverabel som en monolitisk applikation skulle medföra.

Missa inte vår artikel om just microservices här.

Men även tvärtom, microservices passar väldigt bra för DevOps. Microservices medför mindre applikationsdelar (tjänster) med väldefinierade interface som är enklare att testa. Även bygg- och test-tid blir troligtvis kortare då varje tjänst är en liten del av hela applikationen. Om en tjänst uppdateras med ny version medför det (förhoppningsvis) inte att hela applikationen behöver startas om, utan endast den specifika tjänsten (vilket kan lösas med blue/green eller canary deployments).

DevOps och OpenShift

OpenShift är en Platform as a Service (PaaS) mjukvara som Red Hat ligger bakom. OpenShift bygger på Kubernetes i botten och kan agera som ett bra verktyg i DevOps flödet via containers och infrastruktur-manifest. OpenShift har stöd för att t.ex. bygga container-images direkt från källkod (”Source to Image”) som sedan kan automatiskt deployas som containers. Det finns både monitoreringsmöjligheter via API, CLI och ett grafiskt gränssnitt. Man kan sätta upp olika namespaces för test, staging och produktion.

Man kan i YAML-format specificera hela sin miljö i OpenShift som manifest så att man enkelt kan spara undan sin miljö och flytta mellan olika service-providers som tillhandahåller en OpenShift plattform (eller Kubernetes). Då OpenShift är open-source i form av projektet OpenShift Origin så kan man även föra över sin infrastruktur via kod till sin egen plattform från en provider. Det tar bort inlåsningseffekten.

Slutsats

Förhoppningsvis har den här lilla introduktionen till DevOps visat att DevOps är så mycket mer än bara utveckling och drift av servrar. DevOps-metodologin är inget som passar rakt in på alla företag eller projekt utan något man behöver se över om det verkligen passar in för det specifika ändamålet. Det är viktigt att få till ett bra automatiserat flöde för att undvika att få flaskhalsar i DevOps-kedjan. Vilket inte alltid är så lätt om man vill flytta över ett existerande projekt till att utvecklas via DevOps-principen.

Kommunikation i ett DevOps-team är också en nyckel till framgång. Det är viktigt att alla är med i kedjan och förstår hur allt fungerar. Det medför att infrastrukturen stämmer överens med utvecklarnas behov om samspelet fungerar bra mellan de som skriver infrastrukturkoden och de som skriver applikationskoden (om de nu inte är samma personer). Alla ska även ha tillgång till allt för att se förändringar och få en översikt av applikationens livscykel. Det vill säga byggsystem, paket, övervakningsdata, loggar etc.

Många av dagens cloud-tjänster passar bra ihop med DevOps.  PaaS, IaaS, logg-uppsamlare, databas, objektlagring för att nämna några.

Länkar