{"id":33504,"date":"2019-10-31T21:52:58","date_gmt":"2019-10-31T18:52:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom\/"},"modified":"2019-10-31T21:52:58","modified_gmt":"2019-10-31T18:52:58","slug":"rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/rukovodstvo-dlya-chajnikov-sozdanie-tsepochek-devops-s-pomoshhyu-instrumentov-s-otkrytym-ishodnym-kodom","title":{"rendered":"Guide til begyndere: Oprettelse af DevOps-k\u00e6der ved hj\u00e6lp af open source-v\u00e6rkt\u00f8jer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Guide
\nOprettelse af den f\u00f8rste DevOps-k\u00e6de p\u00e5 fem trin for begyndere.<\/em><\/p>\n

<\/p>\n

DevOps er blevet en kur mod for langsomme, fragmenterede og andre problematiske udviklingsprocesser. Men der kr\u00e6ves minimale kendskaber til DevOps. Her vil der blive set p\u00e5 begreber som DevOps-k\u00e6den og hvordan man opretter den p\u00e5 fem trin. Dette er ikke en fuldst\u00e6ndig guide, men blot en 'skitse', som kan udvides. Lad os starte med historien.<\/p>\n

<\/p>\n

Mit m\u00f8de med DevOps<\/h3>\n

<\/p>\n

Engang arbejdede jeg med skyer hos Citi Group og udviklede en IaaS-webapplikation til at administrere Citigroup's cloud-infrastruktur, men jeg har altid v\u00e6ret interesseret i, hvordan man kan optimere udviklingsk\u00e6den og forbedre kulturen blandt udviklerne. Greg Lavender, vores tekniske direkt\u00f8r for cloud-arkitektur og infrastruktur, anbefalede mig en bog Projekt \u00abF\u00f8niks\u00bb<\/a><\/noindex>. Den forklarer DevOps-principperne fantastisk og l\u00e6ses som en roman.<\/p>\n

<\/a><\/noindex><\/p>\n

I tabellen p\u00e5 bagsiden vises, hvor ofte virksomheder lancerer nye versioner:<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Hvordan f\u00e5r Amazon, Google og Netflix tid til at lancere s\u00e5 meget? Svaret er enkelt: de har forst\u00e5et, hvordan man skaber en n\u00e6sten perfekt DevOps-k\u00e6de.<\/p>\n

<\/p>\n

Hos Citi var det slet ikke s\u00e5dan, indtil vi skiftede til DevOps. Dengang havde mit team forskellige milj\u00f8er, men vi leverede til udviklingsserveren manuelt. Alle udviklere havde adgang til kun \u00e9n udviklingsserver baseret p\u00e5 IBM WebSphere Application Server Community Edition. N\u00e5r vi fors\u00f8gte at levere samtidig, 'h\u00e6vede' serveren, og vi m\u00e5tte hver gang 'smertefuldt' forhandle med hinanden. Derudover havde vi utilstr\u00e6kkelig testd\u00e6kning af koden, en besv\u00e6rlig manuel leveringsproces, og ingen m\u00e5de at spore kodeleverancen via en bestemt opgave eller kundekrav.<\/p>\n

<\/p>\n

Det var klart, at der var behov for hurtigt at g\u00f8re noget, og jeg fandt en kollega, der t\u00e6nkte ligesom mig. Vi besluttede sammen at oprette den f\u00f8rste DevOps-k\u00e6de - han satte en virtuel maskine og Tomcat-applikationsserver op, mens jeg arbejdede med Jenkins, integration med Atlassian Jira og BitBucket samt testd\u00e6kningen af koden. Projektet var en succes: vi automatiserede helt udviklingsk\u00e6den, opn\u00e5ede n\u00e6sten 100% oppetid p\u00e5 udviklingsserveren, kunne spore og forbedre testd\u00e6kningen af koden, og Git-grenen kunne knyttes til leverancens og Jira-opgavens. Og n\u00e6sten alle de v\u00e6rkt\u00f8jer, som vi byggede DevOps-k\u00e6den med, var open source.<\/p>\n

<\/p>\n

Faktisk var k\u00e6den forenklet, da vi ikke engang anvendte avancerede konfigurationer ved hj\u00e6lp af Jenkins eller Ansible. Men vi klarede det. M\u00e5ske er det et resultat af princippet Pareto<\/a><\/noindex> (ogs\u00e5 kendt som 80\/20-reglen).<\/p>\n

<\/p>\n

Kort beskrivelse af DevOps og CI\/CD k\u00e6den<\/h3>\n

<\/p>\n

Der er forskellige definitioner af DevOps. Ligesom Agile inkluderer DevOps forskellige discipliner. Men de fleste vil enige i f\u00f8lgende definition: DevOps er en metode eller livscyklus for softwareudvikling, hvis hovedprincip er at skabe en kultur, hvor udviklere og andre medarbejdere er \"p\u00e5 en b\u00f8lgel\u00e6ngde\", manuelt arbejde automatik er automatiseret, alle besk\u00e6ftiger sig med det, de er bedst til, leveringsfrekvensen stiger, produktiviteten \u00f8ges, fleksibiliteten forbedres.<\/p>\n

<\/p>\n

Og selvom kun v\u00e6rkt\u00f8jer ikke er nok til at skabe et DevOps-milj\u00f8, er de uundg\u00e5elige. Det vigtigste er kontinuerlig integration og kontinuerlig levering (CI\/CD). I k\u00e6den er der forskellige trin for hvert milj\u00f8 (f.eks. DEV (udvikling), INT (integration), TST (test), QA (kvalitetskontrol), UAT (brugertest), STG (forberedelse), PROD (produktion)), manuelle opgaver er automatiserede, udviklere kan skrive kvalitetskode, levere den, og de kan nemt omstille sig.<\/p>\n

<\/p>\n

Denne note beskriver, hvordan man i fem trin kan oprette en DevOps-k\u00e6de, som vist p\u00e5 billedet nedenfor, ved hj\u00e6lp af open source v\u00e6rkt\u00f8jer.<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Lad os komme til sagen.<\/p>\n

<\/p>\n

Trin 1: CI\/CD-platformen<\/h3>\n

<\/p>\n

F\u00f8rst og fremmest har du brug for et CI\/CD v\u00e6rkt\u00f8j. Jenkins er et open source CI\/CD v\u00e6rkt\u00f8j skrevet i Java med MIT-licens, som satte gang i populariseringen af DevOps-bev\u00e6gelsen og som de facto er blevet standarden for CICD.<\/p>\n

<\/p>\n

Hvad er Jenkins? Forestil dig, at du har en magisk kontrolpanel til forskellige tjenester og v\u00e6rkt\u00f8jer. Selve CI\/CD-v\u00e6rkt\u00f8jet, som Jenkins, er ubrugeligt, men sammen med forskellige v\u00e6rkt\u00f8jer og tjenester bliver det alm\u00e6gtigt.<\/p>\n

<\/p>\n

Udover Jenkins findes der mange andre open source v\u00e6rkt\u00f8jer, v\u00e6lg hvilket som helst. <\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

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

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Du har et CI\/CD v\u00e6rkt\u00f8j p\u00e5 localhost, men der er ikke meget at lave endnu. Lad os g\u00e5 videre til n\u00e6ste trin.<\/p>\n

<\/p>\n

Trin 2: Versionsh\u00e5ndtering<\/h3>\n

<\/p>\n

Den bedste (og muligvis den nemmeste) m\u00e5de at teste magien i CI\/CD-v\u00e6rkt\u00f8jet p\u00e5, er at integrere det med et versioneringsv\u00e6rkt\u00f8j (source control management, SCM). Hvorfor er versionering n\u00f8dvendig? Antag, at du laver en applikation. Du skriver den i Java, Python, C++, Go, Ruby, JavaScript eller et andet sprog. Det, du skriver, kaldes kildekode. I starten, is\u00e6r hvis du arbejder alene, kan du gemme alt i en lokal mappe. Men n\u00e5r projektet vokser, og flere personer tilslutter sig, har du brug for en m\u00e5de at dele \u00e6ndringer i koden, uden at der opst\u00e5r konflikter ved sammenfletninger af \u00e6ndringer. Og du skal ogs\u00e5 kunne gendanne tidligere versioner uden at bruge sikkerhedskopier og anvende copy-paste metoden p\u00e5 kodefiler.<\/p>\n

<\/p>\n

Og her er SCM uundg\u00e5eligt. SCM gemmer koden i repositors, h\u00e5ndterer dens versioner og koordinerer den blandt udviklere.<\/p>\n

<\/p>\n

Der findes mange SCM-v\u00e6rkt\u00f8jer, men de facto-standarden er fortjent blevet Git. Jeg anbefaler at bruge netop det, men der er ogs\u00e5 andre muligheder.<\/p>\n

<\/p>\n

\"Guide<\/p>\n

<\/p>\n

Her ser pipelinen DevOps ud efter at have tilf\u00f8jet SCM.<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

CI\/CD-v\u00e6rkt\u00f8jet kan automatisere upload og download af kildekode og samarbejde i teamet. Ikke d\u00e5rligt? Men hvordan laver man nu en fungerende applikation, der elskes af milliarder af brugere?<\/p>\n

<\/p>\n

Trin 3: v\u00e6rkt\u00f8j til automatisering af bygning<\/h3>\n

<\/p>\n

Alt g\u00e5r som det skal. Du kan uploade koden og registrere \u00e6ndringer i versioneringssystemet og invitere venner til at arbejde sammen med dig. Men du har stadig ikke nogen applikation. For at det skal blive en webapplikation, skal det kompileres og pakkes til distribution eller k\u00f8res som en eksekverbar fil. (Et fortolket programmeringssprog som JavaScript eller PHP beh\u00f8ver ikke at blive kompileret.)<\/p>\n

<\/p>\n

Anvend v\u00e6rkt\u00f8jet til automatisering af bygning. Uanset hvilket v\u00e6rkt\u00f8j du v\u00e6lger, vil det samle koden i det n\u00f8dvendige format og automatisere reng\u00f8ring, kompilering, testning og distribution. Byggev\u00e6rkt\u00f8jer varierer afh\u00e6ngigt af sproget, men der anvendes normalt f\u00f8lgende \u00e5bne kilder.<\/p>\n

<\/p>\n

\"Guide<\/p>\n

<\/p>\n

Fremragende! Nu inds\u00e6tter vi konfigurationsfilerne til automatiseringsv\u00e6rkt\u00f8jet i versioneringssystemet, s\u00e5 CI\/CD-v\u00e6rkt\u00f8jet kan samle dem.<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Det ser tilsyneladende fint ud. Men hvor skal vi nu udrulle det hele?<\/p>\n

<\/p>\n

Trin 4: webapplikationsserver<\/h3>\n

<\/p>\n

S\u00e5, du har en pakket fil, som kan k\u00f8res eller implementeres. For at applikationen virkelig er nyttig, skal den have en slags service eller gr\u00e6nseflade, men du har brug for et sted at placere det hele.<\/p>\n

<\/p>\n

Webapplikationen kan placeres p\u00e5 en applikationsserver. Applikationsserveren tilbyder et milj\u00f8, hvor den programmeringslogik, der er i pakken, kan udf\u00f8res, gr\u00e6nsefladen kan tegnes, og webtjenester kan \u00e5bnes via en socket. Du har brug for en HTTP-server og flere andre milj\u00f8er (en virtuel maskine, for eksempel), for at installere applikationsserveren. Lad os i mellemtiden forestille os, at du har styr p\u00e5 alt dette undervejs (selvom jeg senere vil fort\u00e6lle om containere).<\/p>\n

<\/p>\n

Der er flere \u00e5bne applikationsservere.<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

Vi har allerede f\u00e5et n\u00e6sten en fungerende DevOps-k\u00e6de. Godt arbejde!<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

I princippet kan vi stoppe her, du klarer resten selv, men det er ogs\u00e5 v\u00e6rd at tale om kodekvalitet.<\/p>\n

<\/p>\n

Trin 5: Testd\u00e6kning<\/h3>\n

<\/p>\n

Testning tager meget tid og kr\u00e6fter, men det er bedre at finde fejl og forbedre koden med det samme for at gl\u00e6de slutbrugerne. Til dette form\u00e5l findes der mange \u00e5bne v\u00e6rkt\u00f8jer, der ikke kun tester koden, men ogs\u00e5 giver forslag til, hvordan den kan forbedres. De fleste CI\/CD-v\u00e6rkt\u00f8jer kan integreres med disse v\u00e6rkt\u00f8jer og automatisere processen.<\/p>\n

<\/p>\n

Testning er opdelt i to dele: testframeworks til at skrive og udf\u00f8re tests, og v\u00e6rkt\u00f8jer med forslag til at forbedre kodekvaliteten.<\/p>\n

<\/p>\n

Testframeworks<\/h3>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

V\u00e6rkt\u00f8jer med kvalitetsforslag<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

De fleste af disse v\u00e6rkt\u00f8jer og frameworks er skrevet til Java, Python og JavaScript, fordi C++ og C# er propriet\u00e6re (selvom GCC har \u00e5ben kildekode).<\/p>\n

<\/p>\n

Vi har anvendt testd\u00e6kningsv\u00e6rkt\u00f8jerne, og nu b\u00f8r DevOps-pipelines se ud som i billedet i starten af vejledningen.<\/p>\n

<\/p>\n

Yderligere trin<\/h2>\n

<\/p>\n

Containere<\/h3>\n

<\/p>\n

Som jeg allerede har n\u00e6vnt, kan applikationsserveren placeres p\u00e5 en virtuel maskine eller server, men containere er mere popul\u00e6re.<\/p>\n

<\/p>\n

Hvad er containere<\/a><\/noindex>? \u0412\u043a\u0440\u0430\u0442\u0446\u0435, \u0432 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u043e\u0439 \u043c\u0430\u0448\u0438\u043d\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0447\u0430\u0449\u0435 \u0432\u0441\u0435\u0433\u043e \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u0435 \u043c\u0435\u0441\u0442\u0430, \u0447\u0435\u043c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435, \u0430 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0443 \u043e\u0431\u044b\u0447\u043d\u043e \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0431\u0438\u0431\u043b\u0438\u043e\u0442\u0435\u043a \u0438 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438. \u0412 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u0441\u043b\u0443\u0447\u0430\u044f\u0445 \u0431\u0435\u0437 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u0445 \u043c\u0430\u0448\u0438\u043d \u043d\u0435 \u043e\u0431\u043e\u0439\u0442\u0438\u0441\u044c, \u043d\u043e \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440 \u0432\u043c\u0435\u0449\u0430\u0435\u0442 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0432\u043c\u0435\u0441\u0442\u0435 \u0441 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u043c \u0431\u0435\u0437 \u043b\u0438\u0448\u043d\u0438\u0445 \u0437\u0430\u0442\u0440\u0430\u0442.<\/p>\n

<\/p>\n

Til containere bruges normalt Docker og Kubernetes, selvom der ogs\u00e5 er andre muligheder.<\/p>\n

<\/p>\n

\"Guide<\/a><\/noindex><\/p>\n

<\/p>\n

L\u00e6s artikler om Docker og Kubernetes p\u00e5 Opensource.com<\/a><\/noindex>:<\/p>\n

<\/p>\n