{"id":87467,"date":"2020-07-08T13:42:11","date_gmt":"2020-07-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn"},"modified":"2020-07-08T13:42:11","modified_gmt":"2020-07-08T11:42:11","slug":"rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Veiledning for nybegynnere: lage en DevOps-pipeline","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Er du ny innen DevOps, kan du se p\u00e5 denne veiledningen for \u00e5 opprette din f\u00f8rste fem-trinns pipeline.<\/i><\/p>\n

\"Veiledning<\/p>\n

DevOps har blitt den standard l\u00f8sningen for \u00e5 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\u00e5else av disse metodene. I denne artikkelen vil vi definere hva en DevOps-pipeline er, og vi vil gi en veiledning for \u00e5 lage en i fem trinn. Selv om denne guiden ikke er utt\u00f8mmende, skal den gi deg et grunnlag for \u00e5 begynne reisen din og utvide din kunnskap i fremtiden. Men f\u00f8rst, la oss begynne med historien.<\/p>\n

Min reise med DevOps<\/h3>\n

\nTidligere jobbet jeg i skyteamet til Citi Group, og utviklet en Infrastructure-as-a-Service (IaaS) webapplikasjon for \u00e5 administrere Citis skyinfrastruktur, men jeg har alltid v\u00e6rt interessert i hvordan man kan gj\u00f8re utviklingsprosessen mer effektiv og skape positive kulturelle endringer i utviklerteamet. Svaret fant jeg i en bok anbefalt av Greg Lavender, teknisk direkt\u00f8r for skyarkitektur og infrastruktur hos Citi. Boken het \"The Phoenix Project\" (The Phoenix Project<\/a><\/noindex>), og den forklarer prinsippene bak DevOps, i en lettlest romanform.<\/p>\n

I tabellen p\u00e5 baksiden av boken vises hvor ofte ulike selskaper distribuerer systemene sine i produksjonsmilj\u00f8er for release:<\/p>\n

Amazon: 23 000 per dag
\nGoogle: 5 500 per dag
\nNetflix: 500 per dag
\nFacebook: En gang per dag
\nTwitter: Tre ganger per uke
\nTypisk selskap: En gang hver 9. m\u00e5ned<\/p>\n

Hvordan er det i det hele tatt mulig \u00e5 oppn\u00e5 frekvenser som Amazon, Google og Netflix? Det er fordi disse selskapene har funnet ut hvordan man lager nesten perfekte DevOps-pipelines.
\n<\/a><\/noindex>
\nVi var langt fra dette, inntil vi implementerte DevOps i Citi. Da var det forskjellige milj\u00f8er i teamet mitt, men distribusjonen p\u00e5 utviklingsserveren var helt manuell. Alle utviklere hadde bare tilgang til \u00e9n utviklingsserver basert p\u00e5 IBM WebSphere Application Server Community Edition. Problemet var at serveren ble sl\u00e5tt av hver gang flere brukere pr\u00f8vde \u00e5 utf\u00f8re distribusjonen samtidig, s\u00e5 utviklerne m\u00e5tte informere hverandre om intensjonene sine, noe som var ganske smertefullt. I tillegg var det problemer med lavt testdekning av koden, kl\u00f8nete manuelle distribusjonsprosesser, og en mangel p\u00e5 muligheter for \u00e5 spore distribusjon av kode knyttet til en spesifikk oppgave eller brukerhistorie.<\/p>\n

Jeg inns\u00e5 at vi m\u00e5tte gj\u00f8re noe, og fant en kollega som delte mine tanker. Vi bestemte oss for \u00e5 samarbeide om \u00e5 lage den f\u00f8rste DevOps-pipelinen \u2013 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\u00e5dde nesten 100% tilgjengelighet p\u00e5 utviklingsserveren v\u00e5r, s\u00f8rget for sporing, forbedret testdekning av koden, og la til muligheten til \u00e5 knytte grener i Git med oppgaver i Jira eller distribusjoner. De fleste verkt\u00f8y vi brukte for \u00e5 bygge DevOps-pipelinen v\u00e5r hadde \u00e5pen kildekode.<\/p>\n

N\u00e5 forst\u00e5r jeg hvor enkelt DevOps-pipelinen v\u00e5r var: vi brukte ikke utvidelser som Jenkins-filer eller Ansible. Men denne enkle pipelinen fungerte bra, kanskje takket v\u00e6re Pareto-prinsippet (ogs\u00e5 kjent som 80\/20-regelen).<\/p>\n

En kort introduksjon til DevOps og CI\/CD-pipelines<\/h3>\n

\nHvis du sp\u00f8r flere personer: \u00abHva er DevOps?\u00bb, vil du sannsynligvis f\u00e5 flere forskjellige svar. DevOps, som Agile, har utviklet seg for \u00e5 omfatte mange forskjellige disipliner, men de fleste mennesker vil v\u00e6re 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\u00f8 som:<\/p>\n

Automatiserer operasjoner som tidligere ble utf\u00f8rt manuelt;
\nAlle gj\u00f8r det de kan best;
\nAntallet implementeringer over en viss tidsperiode \u00f8ker; Gjennomstr\u00f8mningen \u00f8ker;
\nFleksibiliteten i utviklingen \u00f8ker.<\/p>\n

Selv om det \u00e5 ha de riktige programvareverkt\u00f8yene ikke er den eneste n\u00f8dvendigheten for \u00e5 skape et DevOps-milj\u00f8, er noen verkt\u00f8y essensielle. Et n\u00f8kkelverkt\u00f8y er kontinuerlig integrasjon og kontinuerlig distribusjon (CI\/CD). I denne r\u00f8rledningen har milj\u00f8ene forskjellige stadier (for eksempel DEV, INT, TST, QA, UAT, STG, PROD), mange operasjoner er automatisert, og utviklere kan skrive h\u00f8yverdig kode, oppn\u00e5 utviklingsfleksibilitet og h\u00f8y distribusjonsfrekvens.<\/p>\n

Denne artikkelen beskriver en fem-trinns tiln\u00e6rming til \u00e5 bygge en DevOps-r\u00f8rledning som ligner den vist i det f\u00f8lgende diagrammet, ved hjelp av \u00e5pne kildeverkt\u00f8y.<\/p>\n

Trinn 1: CI\/CD-metoder<\/h3>\n

\nDet f\u00f8rste du trenger er et verkt\u00f8y for CI\/CD. Jenkins, et verkt\u00f8y med \u00e5pen kilde basert p\u00e5 Java og distribuert under MIT-lisensen, er det middelet som populariserte DevOps-retningen og ble de facto-standarden.<\/p>\n

S\u00e5 hva er Jenkins? Tenk p\u00e5 det som en slags magisk universell fjernkontroll som kan kommunisere med forskjellige tjenester og verkt\u00f8y og organisere dem. CI\/CD-verkt\u00f8yet, som Jenkins, er ubrukelig i seg selv, men det blir mer kraftfullt jo flere verkt\u00f8y og tjenester det kobles til.<\/p>\n

Jenkins er bare ett av mange \u00e5pne kildeverkt\u00f8y for CI\/CD som du kan bruke til \u00e5 bygge en DevOps-pipeline.<\/p>\n

Jenkins: Creative Commons og MIT
\nTravis CI: MIT
\nCruiseControl: BSD
\nBuildbot: GPL
\nApache Gump: Apache 2.0
\nCabie: GNU<\/p>\n

Slik ser DevOps-prosesser ut med et CI\/CD-verkt\u00f8y:<\/p>\n

\"Veiledning<\/p>\n

Du har et CI\/CD-verkt\u00f8y som kj\u00f8rer p\u00e5 din localhost, men for \u00f8yeblikket kan du ikke gj\u00f8re mye. La oss g\u00e5 videre til neste trinn i reisen inn i DevOps-verdenen.<\/p>\n

Trinn 2: H\u00e5ndtering av kildekontrollsystemer<\/h3>\n

\nDen beste (og kanskje enkleste) m\u00e5ten \u00e5 sjekke om CI\/CD-verkt\u00f8yet ditt kan gj\u00f8re magi, er \u00e5 integrere det med et kildekontrollverkt\u00f8y (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\u00e5kene. Koden du skriver kalles kildekode. I begynnelsen, spesielt n\u00e5r du jobber alene, kan det v\u00e6re greit \u00e5 lagre alt i en lokal mappe. Men n\u00e5r prosjektet vokser, og du inviterer andre til \u00e5 samarbeide, trenger du en m\u00e5te \u00e5 forhindre konflikter ved effektiv deling av modifikasjoner. Du trenger ogs\u00e5 en m\u00e5te \u00e5 gjenopprette tidligere versjoner, fordi det \u00e5 opprette sikkerhetskopier og kopiere\/klipse i dem allerede er utdatert. Du (og teamet ditt) trenger noe bedre.<\/p>\n

Det er her kildekontrollverkt\u00f8yet blir praktisk talt n\u00f8dvendig. Dette verkt\u00f8yet lagrer koden din i depoter, holder styr p\u00e5 versjoner og koordinerer arbeidet til prosjektmedlemmene.<\/p>\n

Selv om det finnes mange kildekontrollverkt\u00f8y, er Git standarden, og det er sant. Jeg anbefaler sterkt \u00e5 bruke Git, selv om det finnes andre \u00e5pen kildekode-alternativer.<\/p>\n

Git: GPLv2 og LGPL v2.1
\nSubversion: Apache 2.0
\nConcurrent Versions System (CVS): GNU
\nVesta: LGPL
\nMercurial: GNU GPL v2+<\/p>\n

Slik ser DevOps-pipeline ut med tillegget av kildekontrollverkt\u00f8y.<\/p>\n

\"Veiledning<\/p>\n

Et CI\/CD-verkt\u00f8y kan automatisere prosessene for \u00e5 teste, hente kildekode og samarbeide mellom medlemmene. Ikkeno d\u00e5rlig? Men hvordan lager man en fungerende applikasjon av dette, slik at milliarder av mennesker kan bruke og vurdere den?<\/p>\n

Trinn 3: Oppretting av et byggeverkt\u00f8y for automatisering<\/h3>\n

\nFlott! Du kan sjekke koden og gj\u00f8re endringer i kildekontrollsystemet, samt invitere vennene dine til samarbeid i utviklingen. Men du har enn\u00e5 ikke opprettet en applikasjon. For \u00e5 lage et nettapplikasjon m\u00e5 den kompileres og pakkes i et distribuert pakkeformat eller kj\u00f8res som en kj\u00f8rbar fil. (Merk at et tolket programmeringsspr\u00e5k, som JavaScript eller PHP, ikke trenger \u00e5 kompilere).<\/p>\n

Bruk byggautomatiseringsverkt\u00f8yet. Uansett hvilket byggautomatiseringsverkt\u00f8y du velger \u00e5 bruke, har de alle ett felles m\u00e5l: \u00e5 samle kildekoden i \u00f8nsket format og automatisere oppgavene med opprydning, kompilering, testing og distribusjon i et spesifisert milj\u00f8. Byggeverkt\u00f8y vil variere avhengig av programmeringsspr\u00e5ket ditt, men her er noen vanlige alternativer med \u00e5pen kildekode.<\/p>\n

Navn
\nLisens
\nProgrammeringsspr\u00e5k<\/p>\n

Maven
\nApache 2.0
\n Java<\/p>\n

Ant.
\nApache 2.0
\nJava<\/p>\n

Gradle
\nApache 2.0
\nJava<\/p>\n

Bazel
\nApache 2.0
\nJava<\/p>\n

Make
\nGNU
\nN\/A<\/p>\n

Grunt
\nMIT
\nJavaScript<\/p>\n

Gulp
\nMIT
\nJavaScript<\/p>\n

Buildr
\nApache.
\nRuby<\/p>\n

Rake
\nMIT
\nRuby<\/p>\n

A-A-P
\nGNU
\nPython<\/p>\n

SCons.
\nMIT
\nPython<\/p>\n

BitBake
\nGPLv2
\nPython<\/p>\n

Kake
\nMIT
\nC#<\/p>\n

ASDF
\nExpat (MIT)
\nLISP<\/p>\n

Cabal
\nBSD
\nHaskell<\/p>\n

Bra! Du kan legge konfigurasjonsfilene til byggautomatiseringsverkt\u00f8yet inn i kildekontrollsystemet og la CI\/CD-verkt\u00f8yet ditt samle alt p\u00e5 en gang.<\/p>\n

\"Veiledning<\/p>\n

Alt er bra, ikke sant? Men hvor skal du distribuere applikasjonen din?<\/p>\n

Trinn 4: Server for webapplikasjoner<\/h3>\n

\nS\u00e5 langt har du en pakket fil som kan v\u00e6re b\u00e5de kj\u00f8rbar og installasjonsbar. For at en applikasjon skal v\u00e6re virkelig nyttig, m\u00e5 den tilby en eller annen tjeneste eller grensesnitt, men du trenger en container for \u00e5 plassere applikasjonen din.<\/p>\n

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

Det finnes flere servere for webapplikasjoner med \u00e5pen kildekode.<\/p>\n

Navn
\nLisens
\nProgrammeringsspr\u00e5k<\/p>\n

Tomcat
\nApache 2.0
\nJava<\/p>\n

Jetty
\nApache 2.0
\nJava<\/p>\n

WildFly
\nGNU Lesser Public
\nJava<\/p>\n

GlassFish
\nCDDL & GNU Less Public
\nJava<\/p>\n

Django
\n3-Clause BSD
\nPython<\/p>\n

Tornado
\nApache 2.0
\nPython<\/p>\n

Gunicorn
\nMIT
\nPython<\/p>\n

Python
\nMIT
\nPython<\/p>\n

Rails
\nMIT
\nRuby<\/p>\n

Node.js
\nMIT
\nJavascript<\/p>\n

Din DevOps-pipeline er nesten klar til bruk. God jobb!<\/p>\n

\"Veiledning<\/p>\n

Selv om man kan stoppe her og integrere selv, er kodekvalitet en viktig faktor for applikasjonsutviklere, og dette b\u00f8r man ta vare p\u00e5.<\/p>\n

Trinn 5: Dekning av kode-testing<\/h3>\n

\nImplementeringen av tester kan v\u00e6re en annen tidkrevende oppgave, men utviklere m\u00e5 oppdage eventuelle feil i applikasjonen tidlig og forbedre kodekvaliteten for \u00e5 sikre at sluttbrukerne er forn\u00f8yde. Heldigvis finnes det mange verkt\u00f8y med \u00e5pen kildekode for \u00e5 teste koden din og gi anbefalinger for forbedring av kvaliteten. Enda bedre er det at de fleste CI\/CD-verkt\u00f8y kan kobles til disse verkt\u00f8yene og automatisere prosessen.<\/p>\n

Kode-testing best\u00e5r av to deler: test-rammeverk som hjelper med \u00e5 skrive og kj\u00f8re tester, samt verkt\u00f8y for \u00e5 gi forslag som hjelper med \u00e5 forbedre kodekvaliteten.<\/p>\n

Kode-testingsystemer<\/b><\/p>\n

Navn
\nLisens
\nProgrammeringsspr\u00e5k<\/p>\n

JUnit
\nEclipse Public License
\nJava<\/p>\n

EasyMock
\nApache.
\nJava<\/p>\n

Mockito
\nMIT
\nJava<\/p>\n

PowerMock
\nApache 2.0
\nJava<\/p>\n

Pytest
\n MIT
\nPython<\/p>\n

Hypothesis
\nMozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Anbefalingssystemer for kodeforbedring<\/b><\/p>\n

Navn
\nLisens
\nProgrammeringsspr\u00e5k<\/p>\n

Cobertura
\nGNU
\nJava<\/p>\n

CodeCover
\nEclipse Public (EPL)
\nJava<\/p>\n

Coverage.py
\n Apache 2.0
\nPython<\/p>\n

Emma
\nCommon Public License
\nJava<\/p>\n

JaCoCo
\n Eclipse Public License
\nJava<\/p>\n

Hypothesis
\n Mozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Jasmine
\nMIT
\nJavaScript<\/p>\n

Karma
\nMIT
\nJavaScript<\/p>\n

Mocha
\n MIT
\nJavaScript<\/p>\n

Jest
\nMIT
\nJavaScript<\/p>\n

Merk at de fleste verkt\u00f8yene og rammeverkene nevnt ovenfor er skrevet for Java, Python og JavaScript, ettersom C++ og C# er propriet\u00e6re programmeringsspr\u00e5k (selv om GCC har \u00e5pen kildekode).<\/p>\n

N\u00e5 som du har implementert verkt\u00f8y for kode-dekking med tester, b\u00f8r DevOps-pipelinen din se ut som diagrammet vist i begynnelsen av denne veiledningen.<\/p>\n

Ytterligere trinn<\/h3>\n

\nContainere<\/b><\/p>\n

Som jeg allerede har nevnt, kan du hoste serveren din p\u00e5 en virtuell maskin eller server, men containere er en popul\u00e6r l\u00f8sning.<\/p>\n

Hva er containere? En kort forklaring er at en virtuell maskin trenger en betydelig mengde minne fra operativsystemet, som overstiger st\u00f8rrelsen p\u00e5 applikasjonen, mens en container kun trenger noen f\u00e5 biblioteker og konfigurasjoner for \u00e5 kj\u00f8re applikasjonen. Det er \u00e5penbart at virtuelle maskiner fortsatt har viktige bruksomr\u00e5der, men en container er en lettvektsl\u00f8sning for hosting av applikasjonen, inkludert applikasjonsservere.<\/p>\n

Selv om det finnes andre container-alternativer, er de mest popul\u00e6re Docker og Kubernetes.<\/p>\n

Docker: Apache 2.0
\nKubernetes: Apache 2.0<\/p>\n

Mellomliggende automatiseringsverkt\u00f8y<\/b><\/p>\n

V\u00e5r DevOps-pipeline er prim\u00e6rt fokusert p\u00e5 samarbeid om utvikling og distribusjon av applikasjoner, men det er mange andre ting man kan gj\u00f8re med DevOps-verkt\u00f8y. En av dem er bruken av Infrastructure as Code (IaC) verkt\u00f8y, som ogs\u00e5 er kjent som mellomliggende automatiseringsverkt\u00f8y. Disse verkt\u00f8yene hjelper til med \u00e5 automatisere installasjon, administrasjon og andre oppgaver for mellomprogramvare. For eksempel kan et automatiseringsverkt\u00f8y hente applikasjoner som webapplikasjonsservere, databaser og overv\u00e5kingsverkt\u00f8y, med riktige konfigurasjoner og distribuere dem p\u00e5 applikasjonsserveren.<\/p>\n

Her er noen mellomliggende automatiseringsverkt\u00f8y med \u00e5pen kildekode:<\/p>\n

Ansible: GNU Public
\nSaltStack: Apache 2.0
\nChef: Apache 2.0
\nPuppet: Apache eller GPL<\/p>\n

\"Veiledning<\/p>\n

F\u00e1\u00f0u frekari uppl\u00fdsingar um hvernig \u00e1 a\u00f0 \u00f6\u00f0last eftirs\u00f3tta starf me\u00f0 \u00fev\u00ed a\u00f0 fara \u00ed grei\u00f0slukennslu \u00e1 netinu hj\u00e1 SkillFactory:<\/p>\n