🥇Begynderguide: Opret en DevOps-pipeline

Hvis du er ny inden for DevOps, så se denne vejledning til at oprette din første pipeline i fem trin.

DevOps er blevet den standardløsning til at rette langsomme, fragmenterede eller ikke-fungerende softwareudviklingsprocesser. Problemet er, at hvis du er ny inden for DevOps og ikke ved, hvor du skal starte, kan du mangle forståelse for disse metoder. I denne artikel vil vi definere DevOps-pipelinen og give en vejledning til at oprette den i fem trin. Selvom denne vejledning ikke er udtømmende, bør den give dig et fundament til at starte din rejse og udvide din viden i fremtiden. Men lad os begynde med historien.

Min rejse inden for DevOps

Tidligere arbejdede jeg i Citi Groups cloud-team med at udvikle en Infrastructure-as-a-Service (IaaS) webapplikation til at styre Citi's cloud-infrastruktur, men jeg har altid været interesseret i, hvordan man kan gøre udviklingsprocessen mere effektiv og bringe positive kulturforandringer til udviklingsteamet. Svaret fandt jeg i en bog, anbefalet af Greg Lavender, Citis tekniske direktør for cloud-arkitektur og -infrastruktur. Bogen hedder "The Phoenix Project" (The Phoenix Project), og den forklarer DevOps-principper, mens den læses som en roman.

I tabellen på bagsiden af bogen vises, hvor ofte forskellige virksomheder implementerer deres systemer i release-miljøer:

Amazon: 23.000 om dagen
Google: 5.500 om dagen
Netflix: 500 om dagen
Facebook: Én gang om dagen
Twitter: 3 gange om ugen
Typisk virksomhed: Én gang hvert 9. måned

Hvordan er det overhovedet muligt for Amazon, Google og Netflix at have så høje frekvenser? Alt sammen fordi disse virksomheder har fundet ud af, hvordan man skaber næsten den perfekte DevOps-pipeline.

Vi var langt fra det, indtil vi implementerede DevOps hos Citi. På det tidspunkt havde mit team forskellige miljøer, men implementeringen på udviklingsserveren var helt manuel. Alle udviklere havde kun adgang til én udviklingsserver baseret på IBM WebSphere Application Server Community Edition. Problemet var, at serveren lukkede hver gang, flere brugere forsøgte at udføre implementeringen samtidigt, hvilket betød, at udviklerne måtte informere hinanden om deres hensigter, hvilket var ret besværligt. Desuden var der problemer med lavt testdækning af koden, besværlige manuelle implementeringsprocesser og manglen på mulighed for at spore implementeringen af kode relateret til en bestemt opgave eller brugerhistorie.

Jeg indså, at vi var nødt til at gøre noget, og jeg fandt en kollega med samme tanker. Vi besluttede at samarbejde om at skabe den oprindelige DevOps-pipeline – han satte en virtuel maskine og en Tomcat-applikationsserver op, mens jeg arbejdede på Jenkins, integrerede Atlassian Jira og BitBucket, samt arbejdede på testdækning af koden. Dette sideprojekt var meget succesfuldt: vi næsten helt automatiserede mange processer, nåede praktisk talt 100% driftssikkerhed på vores udviklingsserver, sikrede sporing og forbedrede testdækningen af koden samt tilføjede muligheden for at knytte grene i Git til opgaver i Jira eller implementeringen. De fleste værktøjer, vi brugte til at opbygge vores DevOps-pipeline, havde open source.

Nu forstår jeg, hvor simpelt vores DevOps-pipeline var: vi brugte ikke udvidelser som Jenkins-filer eller Ansible. Alligevel fungerede denne enkle pipeline godt, muligvis takket være Pareto-princippet (også kendt som 80/20-reglen).

En kort introduktion til DevOps og CI/CD pipeline

Hvis du spørger flere personer: 'Hvad er DevOps?', får du sikkert flere forskellige svar. DevOps, ligesom Agile, har udviklet sig til at omfatte mange forskellige discipliner, men de fleste mennesker vil enige om nogle ting: DevOps er en praksis inden for softwareudvikling eller softwareudviklingslivscyklussen (SDLC), hvis centrale princip er at ændre kulturen, hvor udviklere og ikke-udviklere eksisterer i et miljø, hvor:

Driftsopgaver, der tidligere blev udført manuelt, er automatiseret;
Alle gør det, de gør bedst;
Antallet af deployment i en bestemt tidsramme stiger; Igennemstrømningen øges;
Udviklingsfleksibiliteten forbedres.

Selvom de rigtige softwareværktøjer ikke er det eneste, der er nødvendigt for at oprette et DevOps-miljø, er visse værktøjer essentielle. Et nøgleværktøj er Continous Integration og Continuous Deployment (CI/CD). I denne pipeline har miljøerne forskellige faser (f.eks. DEV, INT, TST, QA, UAT, STG, PROD), mange operationer er automatiseret, og udviklerne kan skrive kvalitetskoder, opnå fleksibilitet i udviklingen og høj deployeringsfrekvens.

I denne artikel beskrives en fem-trins tilgang til oprettelse af en DevOps-pipeline, som den der er vist i det følgende diagram, ved hjælp af open-source værktøjer.

Trin 1: CI/CD metoder

Det første, du har brug for, er et værktøj til CI/CD. Jenkins, et open-source værktøj baseret på Java og distribueret under MIT-licensen, er det middel, der populariserede DevOps-retningen og er blevet de facto-standarden.

Hvad er Jenkins så? Tæskt det som en slags magisk universel fjernbetjening, der kan kommunikere med forskellige tjenester og værktøjer og organisere dem. CI/CD-værktøjer som Jenkins er værdiløse i sig selv, men de bliver mere kraftfulde, når de forbindes til forskellige værktøjer og tjenester.

Jenkins er blot et af mange open-source værktøjer til CI/CD, som du kan bruge til at opbygge en DevOps-pipeline.

Jenkins: Creative Commons og MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Sådan ser DevOps-processerne ud med et CI/CD-værktøj:

Du har et CI/CD-værktøj, der kører på din localhost, men lige nu kan du ikke gøre meget med det. Lad os gå videre til det næste trin i rejsen ind i DevOps-verdenen.

Trin 2: Håndtering af versionskontrolsystemer

Den bedste (og muligvis nemmeste) måde at teste, om dit CI/CD-værktøj kan udføre magi på, er at integrere det med et versionskontrolsystem (VCS). Hvorfor har du brug for versionskontrol? Antag, at du udvikler en applikation. Hver gang du bygger en applikation, programmerer du, og det er ligegyldigt, om du bruger Java, Python, C++, Go, Ruby, JavaScript eller en hvilken som helst af de mange programmeringssprog. Koden, du skriver, kaldes kildekode. I starten, især når du arbejder alene, kan du sandsynligvis placere alt i et lokalt bibliotek. Men når projektet vokser, og du inviterer andre til at samarbejde, har du brug for en måde at undgå konflikter ved effektivt at dele modifikationer. Du har også brug for en måde at gendanne tidligere versioner på, fordi sikkerhedskopiering og kopiering/indsætning i dem er forældet. Du (og dit team) har brug for noget bedre.

Det er her, et versionskontrolværktøj bliver nærmest en nødvendighed. Dette værktøj gemmer din kode i repositories, holder styr på versioner og koordinerer arbejdet mellem projektets deltagere.

Selvom der findes mange versionskontrolværktøjer, er Git standarden, og det er sandt. Jeg anbefaler kraftigt at bruge Git, selvom der også er andre open source-muligheder, hvis du ønsker det.

Git: GPLv2 og LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Sådan ser et DevOps-pipeline ud med tilføjelsen af versionskontrolværktøjer.

Et CI/CD-værktøj kan automatisere processerne for kontrol, indhentning af kildekode og samarbejde mellem medlemmerne. Ikke dårligt? Men hvordan gør man dette til en fungerende applikation, så milliarder af mennesker kan bruge og værdsætte den?

Trin 3: Oprettelse af et automatiseringsværktøj til bygning

Fremragende! Du kan kontrollere koden og foretage ændringer i versionskontrolsystemet samt invitere dine venner til at samarbejde om udviklingen. Men du har endnu ikke oprettet en applikation. For at lave et webapplikation skal det kompilere og pakkes i et deployerbart format eller køres som en eksekverbar fil. (Bemærk, at et fortolket programmeringssprog som JavaScript eller PHP ikke har brug for at blive kompileret).

Brug automatiseringsværktøjet til bygning. Uanset hvilket automatiseringsværktøj til bygning du vælger at bruge, har de alle det samme mål: at samle kildekoden i et ønsket format og automatisere opgaven med rengøring, kompilering, test og deployment i et bestemt miljø. Byggeværktøjer vil variere afhængigt af dit programmeringssprog, men her er nogle almindelige open source muligheder.

Navn
Licens
Programmeringssprog

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

Gradle
Apache 2.0
Java

Bazel
Apache 2.0
Java

Make
GNU
N/A

Grunt
MIT
JavaScript

Gulp
MIT
JavaScript

Buildr
«Ressourcen kan være sårbar overfor DROWN, hvis dens nøgler bruges af en ekstern server med SSLv2, for eksempel en mailserver», bemærker lederen af udviklingsafdelingen
Ruby

Rake
MIT
Ruby

A-A-P
GNU
Python

SCons
MIT
Python

BitBake
GPLv2
Python

Cake
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Super! Du kan placere konfigurationsfilerne for dit automatiseringsværktøj i versionskontrolsystemet og lade dit CI/CD-værktøj samle alt.

Alt er godt, ikke? Men hvor skal du implementere din applikation?

Trin 4: Server til webapplikationer

Indtil videre har du en pakket fil, der kan være enten eksekverbar eller installationsbar. For at enhver applikation kan være virkelig nyttig, skal den tilbyde en eller anden service eller interface, men du har brug for en container til at hoste din applikation.

En server til webapplikationer fungerer som den container. Serveren leverer et miljø, hvor logikken for det implementerbare pakke kan defineres. Serveren tilbyder også et interface og tilbyder webtjenester ved at åbne sockets til den ydre verden. Du har brug for en HTTP-server samt et eller andet miljø (som en virtuel maskine) til at installere den. Og indtil da, lad os antage, at du vil lære om dette senere (selvom jeg vil tale om containere nedenfor).

Der findes flere open source-servere til webapplikationer.

Navn
Licens
Programmeringssprog

Tomcat
Apache 2.0
Java

Jetty
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

GlassFish
CDDL & GNU Less Public
Java

Django
3-Clause BSD
Python

Tornado
Apache 2.0
Python

Gunicorn
MIT
Python

Python
MIT
Python

Rails
MIT
Ruby

Node.js
MIT
Javascript

Din DevOps-pipeline er næsten klar til brug. Godt arbejde!

Selv om man kunne stoppe her og håndtere integrationen selv, er kodekvalitet en vigtig ting for applikationsudviklere, og det er noget, man skal tage sig af.

Trin 5: Dækning af testning af koden

Implementering af tests kan være et yderligere tungt krav, men udviklere skal fange eventuelle fejl i applikationen tidligt og forbedre kodekvaliteten for at sikre, at de endelige brugere er tilfredse. Heldigvis findes der mange open source-værktøjer til at teste din kode og generere anbefalinger til forbedring af dens kvalitet. Endnu bedre er det, at de fleste CI/CD-værktøjer kan integreres med disse værktøjer og automatisere processen.

Testning af kode består af to dele: testframeworks, der hjælper med at skrive og køre tests, samt værktøjer til generering af forslag, der hjælper med at forbedre kodekvaliteten.

Testningssystemer til kode

Navn
Licens
Programmeringssprog

JUnit
Eclipse Public License
Java

EasyMock
«Ressourcen kan være sårbar overfor DROWN, hvis dens nøgler bruges af en ekstern server med SSLv2, for eksempel en mailserver», bemærker lederen af udviklingsafdelingen
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Forslagsystemer til forbedring af koden

Navn
Licens
Programmeringssprog

Cobertura
GNU
Java

CodeCover
Eclipse Public (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Common Public License
Java

JaCoCo
Eclipse Public License
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Vær opmærksom på, at de fleste værktøjer og frameworks nævnt ovenfor er skrevet til Java, Python og JavaScript, da C++ og C# er proprietære programmeringssprog (selvom GCC er open source).

Nu hvor du har implementeret værktøjerne til testdækning af koden, skal din DevOps-pipeline se ud som diagrammet vist i begyndelsen af denne vejledning.

Yderligere trin

Containere

Som jeg nævnte tidligere, kan du hoste din server på en virtuel maskine eller server, men containere er en populær løsning.

Hvad er containere? En kort forklaring er, at en virtuel maskine kræver et stort antal ressourcer fra operativsystemet, der overstiger størrelsen af applikationen, mens en container kun har brug for nogle få biblioteker og konfigurationer for at køre applikationen. Det er tydeligt, at der stadig findes vigtige anvendelsesområder for virtuelle maskiner, men en container er en letvægtsløsning til hosting af applikationer, herunder applikationsservere.

Selv om der findes andre containerløsninger, er de mest populære Docker og Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Mellemsoftwareautomatiseringsværktøjer

Vores DevOps-pipeline er primært fokuseret på samarbejdsskabende og implementering af applikationer, men der er mange andre ting, der kan gøres med DevOps-værktøjer. En af dem er brugen af Infrastructure as Code (IaC) værktøjer, som også kendes som mellemsoftwareautomatiseringsværktøjer. Disse værktøjer hjælper med at automatisere installation, administration og andre opgaver for mellemsoftware. For eksempel kan et automatiseringsværktøj hente applikationer som webapplikationsservere, databaser og overvågningsværktøjer med de rette konfigurationer og implementere dem på applikationsserveren.

Her er nogle open source mellemsoftwareautomatiseringsværktøjer:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache eller GPL

Få detaljer om, hvordan du kan få en eftertragtet profession fra bunden eller level up dine færdigheder og løn ved at tage betalte onlinekurser fra SkillFactory: