{"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\/da\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Begynderguide: opret DevOps-pipeline","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hvis du er ny inden for DevOps, s\u00e5 se denne vejledning til at oprette din f\u00f8rste pipeline i fem trin.<\/i><\/p>\n

\"Begynderguide:<\/p>\n

DevOps er blevet den standardl\u00f8sning 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\u00e5else 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\u00f8mmende, b\u00f8r den give dig et fundament til at starte din rejse og udvide din viden i fremtiden. Men lad os begynde med historien.<\/p>\n

Min rejse inden for DevOps<\/h3>\n

\nTidligere 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\u00e6ret interesseret i, hvordan man kan g\u00f8re udviklingsprocessen mere effektiv og bringe positive kulturforandringer til udviklingsteamet. Svaret fandt jeg i en bog, anbefalet af Greg Lavender, Citis tekniske direkt\u00f8r for cloud-arkitektur og -infrastruktur. Bogen hedder \"The Phoenix Project\" (The Phoenix Project<\/a><\/noindex>), og den forklarer DevOps-principper, mens den l\u00e6ses som en roman.<\/p>\n

I tabellen p\u00e5 bagsiden af bogen vises, hvor ofte forskellige virksomheder implementerer deres systemer i release-milj\u00f8er:<\/p>\n

Amazon: 23.000 om dagen
\nGoogle: 5.500 om dagen
\nNetflix: 500 om dagen
\nFacebook: \u00c9n gang om dagen
\nTwitter: 3 gange om ugen
\nTypisk virksomhed: \u00c9n gang hvert 9. m\u00e5ned<\/p>\n

Hvordan er det overhovedet muligt for Amazon, Google og Netflix at have s\u00e5 h\u00f8je frekvenser? Alt sammen fordi disse virksomheder har fundet ud af, hvordan man skaber n\u00e6sten den perfekte DevOps-pipeline.
\n<\/a><\/noindex>
\nVi var langt fra det, indtil vi implementerede DevOps hos Citi. P\u00e5 det tidspunkt havde mit team forskellige milj\u00f8er, men implementeringen p\u00e5 udviklingsserveren var helt manuel. Alle udviklere havde kun adgang til \u00e9n udviklingsserver baseret p\u00e5 IBM WebSphere Application Server Community Edition. Problemet var, at serveren lukkede hver gang, flere brugere fors\u00f8gte at udf\u00f8re implementeringen samtidigt, hvilket bet\u00f8d, at udviklerne m\u00e5tte informere hinanden om deres hensigter, hvilket var ret besv\u00e6rligt. Desuden var der problemer med lavt testd\u00e6kning af koden, besv\u00e6rlige manuelle implementeringsprocesser og manglen p\u00e5 mulighed for at spore implementeringen af kode relateret til en bestemt opgave eller brugerhistorie.<\/p>\n

Jeg inds\u00e5, at vi var n\u00f8dt til at g\u00f8re noget, og jeg fandt en kollega med samme tanker. Vi besluttede at samarbejde om at skabe den oprindelige DevOps-pipeline \u2013 han satte en virtuel maskine og en Tomcat-applikationsserver op, mens jeg arbejdede p\u00e5 Jenkins, integrerede Atlassian Jira og BitBucket, samt arbejdede p\u00e5 testd\u00e6kning af koden. Dette sideprojekt var meget succesfuldt: vi n\u00e6sten helt automatiserede mange processer, n\u00e5ede praktisk talt 100% driftssikkerhed p\u00e5 vores udviklingsserver, sikrede sporing og forbedrede testd\u00e6kningen af koden samt tilf\u00f8jede muligheden for at knytte grene i Git til opgaver i Jira eller implementeringen. De fleste v\u00e6rkt\u00f8jer, vi brugte til at opbygge vores DevOps-pipeline, havde open source.<\/p>\n

Nu forst\u00e5r 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\u00e6re Pareto-princippet (ogs\u00e5 kendt som 80\/20-reglen).<\/p>\n

En kort introduktion til DevOps og CI\/CD pipeline<\/h3>\n

\nHvis du sp\u00f8rger flere personer: 'Hvad er DevOps?', f\u00e5r 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 \u00e6ndre kulturen, hvor udviklere og ikke-udviklere eksisterer i et milj\u00f8, hvor:<\/p>\n

Driftsopgaver, der tidligere blev udf\u00f8rt manuelt, er automatiseret;
\nAlle g\u00f8r det, de g\u00f8r bedst;
\nAntallet af deployment i en bestemt tidsramme stiger; Igennemstr\u00f8mningen \u00f8ges;
\nUdviklingsfleksibiliteten forbedres.<\/p>\n

Selvom de rigtige softwarev\u00e6rkt\u00f8jer ikke er det eneste, der er n\u00f8dvendigt for at oprette et DevOps-milj\u00f8, er visse v\u00e6rkt\u00f8jer essentielle. Et n\u00f8glev\u00e6rkt\u00f8j er Continous Integration og Continuous Deployment (CI\/CD). I denne pipeline har milj\u00f8erne forskellige faser (f.eks. DEV, INT, TST, QA, UAT, STG, PROD), mange operationer er automatiseret, og udviklerne kan skrive kvalitetskoder, opn\u00e5 fleksibilitet i udviklingen og h\u00f8j deployeringsfrekvens.<\/p>\n

I denne artikel beskrives en fem-trins tilgang til oprettelse af en DevOps-pipeline, som den der er vist i det f\u00f8lgende diagram, ved hj\u00e6lp af open-source v\u00e6rkt\u00f8jer.<\/p>\n

Trin 1: CI\/CD metoder<\/h3>\n

\nDet f\u00f8rste, du har brug for, er et v\u00e6rkt\u00f8j til CI\/CD. Jenkins, et open-source v\u00e6rkt\u00f8j baseret p\u00e5 Java og distribueret under MIT-licensen, er det middel, der populariserede DevOps-retningen og er blevet de facto-standarden.<\/p>\n

Hvad er Jenkins s\u00e5? T\u00e6skt det som en slags magisk universel fjernbetjening, der kan kommunikere med forskellige tjenester og v\u00e6rkt\u00f8jer og organisere dem. CI\/CD-v\u00e6rkt\u00f8jer som Jenkins er v\u00e6rdil\u00f8se i sig selv, men de bliver mere kraftfulde, n\u00e5r de forbindes til forskellige v\u00e6rkt\u00f8jer og tjenester.<\/p>\n

Jenkins er blot et af mange open-source v\u00e6rkt\u00f8jer til CI\/CD, som du kan bruge til at opbygge 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

S\u00e5dan ser DevOps-processerne ud med et CI\/CD-v\u00e6rkt\u00f8j:<\/p>\n

\"Begynderguide:<\/p>\n

Du har et CI\/CD-v\u00e6rkt\u00f8j, der k\u00f8rer p\u00e5 din localhost, men lige nu kan du ikke g\u00f8re meget med det. Lad os g\u00e5 videre til det n\u00e6ste trin i rejsen ind i DevOps-verdenen.<\/p>\n

Trin 2: H\u00e5ndtering af versionskontrolsystemer<\/h3>\n

\nDen bedste (og muligvis nemmeste) m\u00e5de at teste, om dit CI\/CD-v\u00e6rkt\u00f8j kan udf\u00f8re magi p\u00e5, 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\u00e6r n\u00e5r du arbejder alene, kan du sandsynligvis placere alt i et lokalt bibliotek. Men n\u00e5r projektet vokser, og du inviterer andre til at samarbejde, har du brug for en m\u00e5de at undg\u00e5 konflikter ved effektivt at dele modifikationer. Du har ogs\u00e5 brug for en m\u00e5de at gendanne tidligere versioner p\u00e5, fordi sikkerhedskopiering og kopiering\/inds\u00e6tning i dem er for\u00e6ldet. Du (og dit team) har brug for noget bedre.<\/p>\n

Det er her, et versionskontrolv\u00e6rkt\u00f8j bliver n\u00e6rmest en n\u00f8dvendighed. Dette v\u00e6rkt\u00f8j gemmer din kode i repositories, holder styr p\u00e5 versioner og koordinerer arbejdet mellem projektets deltagere.<\/p>\n

Selvom der findes mange versionskontrolv\u00e6rkt\u00f8jer, er Git standarden, og det er sandt. Jeg anbefaler kraftigt at bruge Git, selvom der ogs\u00e5 er andre open source-muligheder, hvis du \u00f8nsker det.<\/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

S\u00e5dan ser et DevOps-pipeline ud med tilf\u00f8jelsen af versionskontrolv\u00e6rkt\u00f8jer.<\/p>\n

\"Begynderguide:<\/p>\n

Et CI\/CD-v\u00e6rkt\u00f8j kan automatisere processerne for kontrol, indhentning af kildekode og samarbejde mellem medlemmerne. Ikke d\u00e5rligt? Men hvordan g\u00f8r man dette til en fungerende applikation, s\u00e5 milliarder af mennesker kan bruge og v\u00e6rds\u00e6tte den?<\/p>\n

Trin 3: Oprettelse af et automatiseringsv\u00e6rkt\u00f8j til bygning<\/h3>\n

\nFremragende! Du kan kontrollere koden og foretage \u00e6ndringer 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\u00f8res som en eksekverbar fil. (Bem\u00e6rk, at et fortolket programmeringssprog som JavaScript eller PHP ikke har brug for at blive kompileret).<\/p>\n

Brug automatiseringsv\u00e6rkt\u00f8jet til bygning. Uanset hvilket automatiseringsv\u00e6rkt\u00f8j til bygning du v\u00e6lger at bruge, har de alle det samme m\u00e5l: at samle kildekoden i et \u00f8nsket format og automatisere opgaven med reng\u00f8ring, kompilering, test og deployment i et bestemt milj\u00f8. Byggev\u00e6rkt\u00f8jer vil variere afh\u00e6ngigt af dit programmeringssprog, men her er nogle almindelige open source muligheder.<\/p>\n

Navn
\nLicens
\nProgrammeringssprog<\/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
\n\u00abRessourcen kan v\u00e6re s\u00e5rbar overfor DROWN, hvis dens n\u00f8gler bruges af en ekstern server med SSLv2, for eksempel en mailserver\u00bb, bem\u00e6rker lederen af udviklingsafdelingen
\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

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

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

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

Super! Du kan placere konfigurationsfilerne for dit automatiseringsv\u00e6rkt\u00f8j i versionskontrolsystemet og lade dit CI\/CD-v\u00e6rkt\u00f8j samle alt.<\/p>\n

\"Begynderguide:<\/p>\n

Alt er godt, ikke? Men hvor skal du implementere din applikation?<\/p>\n

Trin 4: Server til webapplikationer<\/h3>\n

\nIndtil videre har du en pakket fil, der kan v\u00e6re enten eksekverbar eller installationsbar. For at enhver applikation kan v\u00e6re virkelig nyttig, skal den tilbyde en eller anden service eller interface, men du har brug for en container til at hoste din applikation.<\/p>\n

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

Der findes flere open source-servere til webapplikationer.<\/p>\n

Navn
\nLicens
\nProgrammeringssprog<\/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 n\u00e6sten klar til brug. Godt arbejde!<\/p>\n

\"Begynderguide:<\/p>\n

Selv om man kunne stoppe her og h\u00e5ndtere integrationen selv, er kodekvalitet en vigtig ting for applikationsudviklere, og det er noget, man skal tage sig af.<\/p>\n

Trin 5: D\u00e6kning af testning af koden<\/h3>\n

\nImplementering af tests kan v\u00e6re 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\u00e6rkt\u00f8jer til at teste din kode og generere anbefalinger til forbedring af dens kvalitet. Endnu bedre er det, at de fleste CI\/CD-v\u00e6rkt\u00f8jer kan integreres med disse v\u00e6rkt\u00f8jer og automatisere processen.<\/p>\n

Testning af kode best\u00e5r af to dele: testframeworks, der hj\u00e6lper med at skrive og k\u00f8re tests, samt v\u00e6rkt\u00f8jer til generering af forslag, der hj\u00e6lper med at forbedre kodekvaliteten.<\/p>\n

Testningssystemer til kode<\/b><\/p>\n

Navn
\nLicens
\nProgrammeringssprog<\/p>\n

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

EasyMock
\n\u00abRessourcen kan v\u00e6re s\u00e5rbar overfor DROWN, hvis dens n\u00f8gler bruges af en ekstern server med SSLv2, for eksempel en mailserver\u00bb, bem\u00e6rker lederen af udviklingsafdelingen
\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

Forslagsystemer til forbedring af koden<\/b><\/p>\n

Navn
\nLicens
\nProgrammeringssprog<\/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

V\u00e6r opm\u00e6rksom p\u00e5, at de fleste v\u00e6rkt\u00f8jer og frameworks n\u00e6vnt ovenfor er skrevet til Java, Python og JavaScript, da C++ og C# er propriet\u00e6re programmeringssprog (selvom GCC er open source).<\/p>\n

Nu hvor du har implementeret v\u00e6rkt\u00f8jerne til testd\u00e6kning af koden, skal din DevOps-pipeline se ud som diagrammet vist i begyndelsen af denne vejledning.<\/p>\n

Yderligere trin<\/h3>\n

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

Som jeg n\u00e6vnte tidligere, kan du hoste din server p\u00e5 en virtuel maskine eller server, men containere er en popul\u00e6r l\u00f8sning.<\/p>\n

Hvad er containere? En kort forklaring er, at en virtuel maskine kr\u00e6ver et stort antal ressourcer fra operativsystemet, der overstiger st\u00f8rrelsen af applikationen, mens en container kun har brug for nogle f\u00e5 biblioteker og konfigurationer for at k\u00f8re applikationen. Det er tydeligt, at der stadig findes vigtige anvendelsesomr\u00e5der for virtuelle maskiner, men en container er en letv\u00e6gtsl\u00f8sning til hosting af applikationer, herunder applikationsservere.<\/p>\n

Selv om der findes andre containerl\u00f8sninger, er de mest popul\u00e6re Docker og Kubernetes.<\/p>\n

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

Mellemsoftwareautomatiseringsv\u00e6rkt\u00f8jer<\/b><\/p>\n

Vores DevOps-pipeline er prim\u00e6rt fokuseret p\u00e5 samarbejdsskabende og implementering af applikationer, men der er mange andre ting, der kan g\u00f8res med DevOps-v\u00e6rkt\u00f8jer. En af dem er brugen af Infrastructure as Code (IaC) v\u00e6rkt\u00f8jer, som ogs\u00e5 kendes som mellemsoftwareautomatiseringsv\u00e6rkt\u00f8jer. Disse v\u00e6rkt\u00f8jer hj\u00e6lper med at automatisere installation, administration og andre opgaver for mellemsoftware. For eksempel kan et automatiseringsv\u00e6rkt\u00f8j hente applikationer som webapplikationsservere, databaser og overv\u00e5gningsv\u00e6rkt\u00f8jer med de rette konfigurationer og implementere dem p\u00e5 applikationsserveren.<\/p>\n

Her er nogle open source mellemsoftwareautomatiseringsv\u00e6rkt\u00f8jer:<\/p>\n

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

\"Begynderguide:<\/p>\n

F\u00e5 detaljer om, hvordan du kan f\u00e5 en eftertragtet profession fra bunden eller level up dine f\u00e6rdigheder og l\u00f8n ved at tage betalte onlinekurser fra SkillFactory:<\/p>\n