🥇Nybegynnerguide: Lage en DevOps-pipeline

Er du ny innen DevOps, kan du se på denne veiledningen for å opprette din første fem-trinns pipeline.

DevOps har blitt den standard løsningen for å fikse langsomme, fragmenterte eller ikke-fungerende programvareutviklingsprosesser. Problemet er at hvis du er ny innen DevOps og ikke vet hvor du skal starte, kan det hende du mangler forståelse av disse metodene. I denne artikkelen vil vi definere hva en DevOps-pipeline er, og vi vil gi en veiledning for å lage en i fem trinn. Selv om denne guiden ikke er uttømmende, skal den gi deg et grunnlag for å begynne reisen din og utvide din kunnskap i fremtiden. Men først, la oss begynne med historien.

Min reise med DevOps

Tidligere jobbet jeg i skyteamet til Citi Group, og utviklet en Infrastructure-as-a-Service (IaaS) webapplikasjon for å administrere Citis skyinfrastruktur, men jeg har alltid vært interessert i hvordan man kan gjøre utviklingsprosessen mer effektiv og skape positive kulturelle endringer i utviklerteamet. Svaret fant jeg i en bok anbefalt av Greg Lavender, teknisk direktør for skyarkitektur og infrastruktur hos Citi. Boken het "The Phoenix Project" (The Phoenix Project), og den forklarer prinsippene bak DevOps, i en lettlest romanform.

I tabellen på baksiden av boken vises hvor ofte ulike selskaper distribuerer systemene sine i produksjonsmiljøer for release:

Amazon: 23 000 per dag
Google: 5 500 per dag
Netflix: 500 per dag
Facebook: En gang per dag
Twitter: Tre ganger per uke
Typisk selskap: En gang hver 9. måned

Hvordan er det i det hele tatt mulig å oppnå frekvenser som Amazon, Google og Netflix? Det er fordi disse selskapene har funnet ut hvordan man lager nesten perfekte DevOps-pipelines.

Vi var langt fra dette, inntil vi implementerte DevOps i Citi. Da var det forskjellige miljøer i teamet mitt, men distribusjonen på utviklingsserveren var helt manuell. Alle utviklere hadde bare tilgang til én utviklingsserver basert på IBM WebSphere Application Server Community Edition. Problemet var at serveren ble slått av hver gang flere brukere prøvde å utføre distribusjonen samtidig, så utviklerne måtte informere hverandre om intensjonene sine, noe som var ganske smertefullt. I tillegg var det problemer med lavt testdekning av koden, klønete manuelle distribusjonsprosesser, og en mangel på muligheter for å spore distribusjon av kode knyttet til en spesifikk oppgave eller brukerhistorie.

Jeg innså at vi måtte gjøre noe, og fant en kollega som delte mine tanker. Vi bestemte oss for å samarbeide om å lage den første DevOps-pipelinen – han installerte en virtuell maskin og Tomcat-applikasjonsserver, mens jeg jobbet med Jenkins, integrerte Atlassian Jira og BitBucket, samt arbeidet med testdekning av koden. Dette sideprosjektet ble veldig vellykket: vi nesten fullstendig automatiserte mange prosesser, oppnådde nesten 100% tilgjengelighet på utviklingsserveren vår, sørget for sporing, forbedret testdekning av koden, og la til muligheten til å knytte grener i Git med oppgaver i Jira eller distribusjoner. De fleste verktøy vi brukte for å bygge DevOps-pipelinen vår hadde åpen kildekode.

Nå forstår jeg hvor enkelt DevOps-pipelinen vår var: vi brukte ikke utvidelser som Jenkins-filer eller Ansible. Men denne enkle pipelinen fungerte bra, kanskje takket være Pareto-prinsippet (også kjent som 80/20-regelen).

En kort introduksjon til DevOps og CI/CD-pipelines

Hvis du spør flere personer: «Hva er DevOps?», vil du sannsynligvis få flere forskjellige svar. DevOps, som Agile, har utviklet seg for å omfatte mange forskjellige disipliner, men de fleste mennesker vil være enige om noen ting: DevOps er en programvareutviklingspraksis eller programvareutviklingslivssyklus (SDLC), hvor den sentrale prinsippet er kulturell endring, der utviklere og ikke-utviklere eksisterer i et miljø som:

Automatiserer operasjoner som tidligere ble utført manuelt;
Alle gjør det de kan best;
Antallet implementeringer over en viss tidsperiode øker; Gjennomstrømningen øker;
Fleksibiliteten i utviklingen øker.

Selv om det å ha de riktige programvareverktøyene ikke er den eneste nødvendigheten for å skape et DevOps-miljø, er noen verktøy essensielle. Et nøkkelverktøy er kontinuerlig integrasjon og kontinuerlig distribusjon (CI/CD). I denne rørledningen har miljøene forskjellige stadier (for eksempel DEV, INT, TST, QA, UAT, STG, PROD), mange operasjoner er automatisert, og utviklere kan skrive høyverdig kode, oppnå utviklingsfleksibilitet og høy distribusjonsfrekvens.

Denne artikkelen beskriver en fem-trinns tilnærming til å bygge en DevOps-rørledning som ligner den vist i det følgende diagrammet, ved hjelp av åpne kildeverktøy.

Trinn 1: CI/CD-metoder

Det første du trenger er et verktøy for CI/CD. Jenkins, et verktøy med åpen kilde basert på Java og distribuert under MIT-lisensen, er det middelet som populariserte DevOps-retningen og ble de facto-standarden.

Så hva er Jenkins? Tenk på det som en slags magisk universell fjernkontroll som kan kommunisere med forskjellige tjenester og verktøy og organisere dem. CI/CD-verktøyet, som Jenkins, er ubrukelig i seg selv, men det blir mer kraftfullt jo flere verktøy og tjenester det kobles til.

Jenkins er bare ett av mange åpne kildeverktøy for CI/CD som du kan bruke til å bygge en DevOps-pipeline.

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

Slik ser DevOps-prosesser ut med et CI/CD-verktøy:

Du har et CI/CD-verktøy som kjører på din localhost, men for øyeblikket kan du ikke gjøre mye. La oss gå videre til neste trinn i reisen inn i DevOps-verdenen.

Trinn 2: Håndtering av kildekontrollsystemer

Den beste (og kanskje enkleste) måten å sjekke om CI/CD-verktøyet ditt kan gjøre magi, er å integrere det med et kildekontrollverktøy (SCM). Hvorfor trenger du kildekontroll? La oss si at du utvikler en applikasjon. Hver gang du lager en applikasjon, programmerer du, og det spiller ingen rolle om du bruker Java, Python, C++, Go, Ruby, JavaScript eller et av de mange programmeringsspråkene. Koden du skriver kalles kildekode. I begynnelsen, spesielt når du jobber alene, kan det være greit å lagre alt i en lokal mappe. Men når prosjektet vokser, og du inviterer andre til å samarbeide, trenger du en måte å forhindre konflikter ved effektiv deling av modifikasjoner. Du trenger også en måte å gjenopprette tidligere versjoner, fordi det å opprette sikkerhetskopier og kopiere/klipse i dem allerede er utdatert. Du (og teamet ditt) trenger noe bedre.

Det er her kildekontrollverktøyet blir praktisk talt nødvendig. Dette verktøyet lagrer koden din i depoter, holder styr på versjoner og koordinerer arbeidet til prosjektmedlemmene.

Selv om det finnes mange kildekontrollverktøy, er Git standarden, og det er sant. Jeg anbefaler sterkt å bruke Git, selv om det finnes andre åpen kildekode-alternativer.

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

Slik ser DevOps-pipeline ut med tillegget av kildekontrollverktøy.

Et CI/CD-verktøy kan automatisere prosessene for å teste, hente kildekode og samarbeide mellom medlemmene. Ikkeno dårlig? Men hvordan lager man en fungerende applikasjon av dette, slik at milliarder av mennesker kan bruke og vurdere den?

Trinn 3: Oppretting av et byggeverktøy for automatisering

Flott! Du kan sjekke koden og gjøre endringer i kildekontrollsystemet, samt invitere vennene dine til samarbeid i utviklingen. Men du har ennå ikke opprettet en applikasjon. For å lage et nettapplikasjon må den kompileres og pakkes i et distribuert pakkeformat eller kjøres som en kjørbar fil. (Merk at et tolket programmeringsspråk, som JavaScript eller PHP, ikke trenger å kompilere).

Bruk byggautomatiseringsverktøyet. Uansett hvilket byggautomatiseringsverktøy du velger å bruke, har de alle ett felles mål: å samle kildekoden i ønsket format og automatisere oppgavene med opprydning, kompilering, testing og distribusjon i et spesifisert miljø. Byggeverktøy vil variere avhengig av programmeringsspråket ditt, men her er noen vanlige alternativer med åpen kildekode.

Navn
Lisens
Programmeringsspråk

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
Apache.
Ruby

Rake
MIT
Ruby

A-A-P
GNU
Python

SCons.
MIT
Python

BitBake
GPLv2
Python

Kake
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Bra! Du kan legge konfigurasjonsfilene til byggautomatiseringsverktøyet inn i kildekontrollsystemet og la CI/CD-verktøyet ditt samle alt på en gang.

Alt er bra, ikke sant? Men hvor skal du distribuere applikasjonen din?

Trinn 4: Server for webapplikasjoner

Så langt har du en pakket fil som kan være både kjørbar og installasjonsbar. For at en applikasjon skal være virkelig nyttig, må den tilby en eller annen tjeneste eller grensesnitt, men du trenger en container for å plassere applikasjonen din.

Serveren for webapplikasjoner fungerer som nettopp en slik container. Serveren gir et miljø der logikken til den distribuerte pakken kan defineres. I tillegg gir serveren et grensesnitt og tilbyr nettjenester, og åpner sokler for den ytre verden. Du trenger en HTTP-server, samt en eller annen miljø (for eksempel en virtuell maskin) for å installere den. La oss anta at du lærer om dette senere (selv om jeg vil fortelle om containere nedenfor).

Det finnes flere servere for webapplikasjoner med åpen kildekode.

Navn
Lisens
Programmeringsspråk

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 nesten klar til bruk. God jobb!

Selv om man kan stoppe her og integrere selv, er kodekvalitet en viktig faktor for applikasjonsutviklere, og dette bør man ta vare på.

Trinn 5: Dekning av kode-testing

Implementeringen av tester kan være en annen tidkrevende oppgave, men utviklere må oppdage eventuelle feil i applikasjonen tidlig og forbedre kodekvaliteten for å sikre at sluttbrukerne er fornøyde. Heldigvis finnes det mange verktøy med åpen kildekode for å teste koden din og gi anbefalinger for forbedring av kvaliteten. Enda bedre er det at de fleste CI/CD-verktøy kan kobles til disse verktøyene og automatisere prosessen.

Kode-testing består av to deler: test-rammeverk som hjelper med å skrive og kjøre tester, samt verktøy for å gi forslag som hjelper med å forbedre kodekvaliteten.

Kode-testingsystemer

Navn
Lisens
Programmeringsspråk

JUnit
Eclipse Public License
Java

EasyMock
Apache.
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Anbefalingssystemer for kodeforbedring

Navn
Lisens
Programmeringsspråk

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

Merk at de fleste verktøyene og rammeverkene nevnt ovenfor er skrevet for Java, Python og JavaScript, ettersom C++ og C# er proprietære programmeringsspråk (selv om GCC har åpen kildekode).

Nå som du har implementert verktøy for kode-dekking med tester, bør DevOps-pipelinen din se ut som diagrammet vist i begynnelsen av denne veiledningen.

Ytterligere trinn

Containere

Som jeg allerede har nevnt, kan du hoste serveren din på en virtuell maskin eller server, men containere er en populær løsning.

Hva er containere? En kort forklaring er at en virtuell maskin trenger en betydelig mengde minne fra operativsystemet, som overstiger størrelsen på applikasjonen, mens en container kun trenger noen få biblioteker og konfigurasjoner for å kjøre applikasjonen. Det er åpenbart at virtuelle maskiner fortsatt har viktige bruksområder, men en container er en lettvektsløsning for hosting av applikasjonen, inkludert applikasjonsservere.

Selv om det finnes andre container-alternativer, er de mest populære Docker og Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Mellomliggende automatiseringsverktøy

Vår DevOps-pipeline er primært fokusert på samarbeid om utvikling og distribusjon av applikasjoner, men det er mange andre ting man kan gjøre med DevOps-verktøy. En av dem er bruken av Infrastructure as Code (IaC) verktøy, som også er kjent som mellomliggende automatiseringsverktøy. Disse verktøyene hjelper til med å automatisere installasjon, administrasjon og andre oppgaver for mellomprogramvare. For eksempel kan et automatiseringsverktøy hente applikasjoner som webapplikasjonsservere, databaser og overvåkingsverktøy, med riktige konfigurasjoner og distribuere dem på applikasjonsserveren.

Her er noen mellomliggende automatiseringsverktøy med åpen kildekode:

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