Oprettelse af den første DevOps-kæde på fem trin for begyndere.
DevOps er blevet en kur mod for langsomme, fragmenterede og andre problematiske udviklingsprocesser. Men der kræves minimale kendskaber til DevOps. Her vil der blive set på begreber som DevOps-kæden og hvordan man opretter den på fem trin. Dette er ikke en fuldstændig guide, men blot en 'skitse', som kan udvides. Lad os starte med historien.
Mit møde med DevOps
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æret interesseret i, hvordan man kan optimere udviklingskæden og forbedre kulturen blandt udviklerne. Greg Lavender, vores tekniske direktør for cloud-arkitektur og infrastruktur, anbefalede mig en bog . Den forklarer DevOps-principperne fantastisk og læses som en roman.
I tabellen på bagsiden vises, hvor ofte virksomheder lancerer nye versioner:
Hvordan får Amazon, Google og Netflix tid til at lancere så meget? Svaret er enkelt: de har forstået, hvordan man skaber en næsten perfekt DevOps-kæde.
Hos Citi var det slet ikke sådan, indtil vi skiftede til DevOps. Dengang havde mit team forskellige miljøer, men vi leverede til udviklingsserveren manuelt. Alle udviklere havde adgang til kun én udviklingsserver baseret på IBM WebSphere Application Server Community Edition. Når vi forsøgte at levere samtidig, 'hævede' serveren, og vi måtte hver gang 'smertefuldt' forhandle med hinanden. Derudover havde vi utilstrækkelig testdækning af koden, en besværlig manuel leveringsproces, og ingen måde at spore kodeleverancen via en bestemt opgave eller kundekrav.
Det var klart, at der var behov for hurtigt at gøre noget, og jeg fandt en kollega, der tænkte ligesom mig. Vi besluttede sammen at oprette den første DevOps-kæde - han satte en virtuel maskine og Tomcat-applikationsserver op, mens jeg arbejdede med Jenkins, integration med Atlassian Jira og BitBucket samt testdækningen af koden. Projektet var en succes: vi automatiserede helt udviklingskæden, opnåede næsten 100% oppetid på udviklingsserveren, kunne spore og forbedre testdækningen af koden, og Git-grenen kunne knyttes til leverancens og Jira-opgavens. Og næsten alle de værktøjer, som vi byggede DevOps-kæden med, var open source.
Faktisk var kæden forenklet, da vi ikke engang anvendte avancerede konfigurationer ved hjælp af Jenkins eller Ansible. Men vi klarede det. Måske er det et resultat af princippet (også kendt som 80/20-reglen).
Kort beskrivelse af DevOps og CI/CD kæden
Der er forskellige definitioner af DevOps. Ligesom Agile inkluderer DevOps forskellige discipliner. Men de fleste vil enige i følgende definition: DevOps er en metode eller livscyklus for softwareudvikling, hvis hovedprincip er at skabe en kultur, hvor udviklere og andre medarbejdere er "på en bølgelængde", manuelt arbejde automatik er automatiseret, alle beskæftiger sig med det, de er bedst til, leveringsfrekvensen stiger, produktiviteten øges, fleksibiliteten forbedres.
Og selvom kun værktøjer ikke er nok til at skabe et DevOps-miljø, er de uundgåelige. Det vigtigste er kontinuerlig integration og kontinuerlig levering (CI/CD). I kæden er der forskellige trin for hvert miljø (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.
Denne note beskriver, hvordan man i fem trin kan oprette en DevOps-kæde, som vist på billedet nedenfor, ved hjælp af open source værktøjer.
Lad os komme til sagen.
Trin 1: CI/CD-platformen
Først og fremmest har du brug for et CI/CD værktøj. Jenkins er et open source CI/CD værktøj skrevet i Java med MIT-licens, som satte gang i populariseringen af DevOps-bevægelsen og som de facto er blevet standarden for CICD.
Hvad er Jenkins? Forestil dig, at du har en magisk kontrolpanel til forskellige tjenester og værktøjer. Selve CI/CD-værktøjet, som Jenkins, er ubrugeligt, men sammen med forskellige værktøjer og tjenester bliver det almægtigt.
Udover Jenkins findes der mange andre open source værktøjer, vælg hvilket som helst.
Sådan ser DevOps-processen ud med et CI/CD-værktøj.
Du har et CI/CD værktøj på localhost, men der er ikke meget at lave endnu. Lad os gå videre til næste trin.
Trin 2: Versionshåndtering
Den bedste (og muligvis den nemmeste) måde at teste magien i CI/CD-værktøjet på, er at integrere det med et versioneringsværktøj (source control management, SCM). Hvorfor er versionering nødvendig? 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ær hvis du arbejder alene, kan du gemme alt i en lokal mappe. Men når projektet vokser, og flere personer tilslutter sig, har du brug for en måde at dele ændringer i koden, uden at der opstår konflikter ved sammenfletninger af ændringer. Og du skal også kunne gendanne tidligere versioner uden at bruge sikkerhedskopier og anvende copy-paste metoden på kodefiler.
Og her er SCM uundgåeligt. SCM gemmer koden i repositors, håndterer dens versioner og koordinerer den blandt udviklere.
Der findes mange SCM-værktøjer, men de facto-standarden er fortjent blevet Git. Jeg anbefaler at bruge netop det, men der er også andre muligheder.
Her ser pipelinen DevOps ud efter at have tilføjet SCM.
CI/CD-værktøjet kan automatisere upload og download af kildekode og samarbejde i teamet. Ikke dårligt? Men hvordan laver man nu en fungerende applikation, der elskes af milliarder af brugere?
Trin 3: værktøj til automatisering af bygning
Alt går som det skal. Du kan uploade koden og registrere ændringer 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øres som en eksekverbar fil. (Et fortolket programmeringssprog som JavaScript eller PHP behøver ikke at blive kompileret.)
Anvend værktøjet til automatisering af bygning. Uanset hvilket værktøj du vælger, vil det samle koden i det nødvendige format og automatisere rengøring, kompilering, testning og distribution. Byggeværktøjer varierer afhængigt af sproget, men der anvendes normalt følgende åbne kilder.
Fremragende! Nu indsætter vi konfigurationsfilerne til automatiseringsværktøjet i versioneringssystemet, så CI/CD-værktøjet kan samle dem.
Det ser tilsyneladende fint ud. Men hvor skal vi nu udrulle det hele?
Trin 4: webapplikationsserver
Så, du har en pakket fil, som kan køres eller implementeres. For at applikationen virkelig er nyttig, skal den have en slags service eller grænseflade, men du har brug for et sted at placere det hele.
Webapplikationen kan placeres på en applikationsserver. Applikationsserveren tilbyder et miljø, hvor den programmeringslogik, der er i pakken, kan udføres, grænsefladen kan tegnes, og webtjenester kan åbnes via en socket. Du har brug for en HTTP-server og flere andre miljøer (en virtuel maskine, for eksempel), for at installere applikationsserveren. Lad os i mellemtiden forestille os, at du har styr på alt dette undervejs (selvom jeg senere vil fortælle om containere).
Der er flere åbne applikationsservere.
Vi har allerede fået næsten en fungerende DevOps-kæde. Godt arbejde!
I princippet kan vi stoppe her, du klarer resten selv, men det er også værd at tale om kodekvalitet.
Trin 5: Testdækning
Testning tager meget tid og kræfter, men det er bedre at finde fejl og forbedre koden med det samme for at glæde slutbrugerne. Til dette formål findes der mange åbne værktøjer, der ikke kun tester koden, men også giver forslag til, hvordan den kan forbedres. De fleste CI/CD-værktøjer kan integreres med disse værktøjer og automatisere processen.
Testning er opdelt i to dele: testframeworks til at skrive og udføre tests, og værktøjer med forslag til at forbedre kodekvaliteten.
Testframeworks
Værktøjer med kvalitetsforslag
De fleste af disse værktøjer og frameworks er skrevet til Java, Python og JavaScript, fordi C++ og C# er proprietære (selvom GCC har åben kildekode).
Vi har anvendt testdækningsværktøjerne, og nu bør DevOps-pipelines se ud som i billedet i starten af vejledningen.
Yderligere trin
Containere
Som jeg allerede har nævnt, kan applikationsserveren placeres på en virtuel maskine eller server, men containere er mere populære.
? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
Til containere bruges normalt Docker og Kubernetes, selvom der også er andre muligheder.
Læs artikler om Docker og Kubernetes på :
Værktøjer til automatisering af middleware
Vores DevOps-kæde er fokuseret på samarbejdende opbygning og levering af applikationer, men med DevOps-værktøjer kan man også gøre mange andre interessante ting. For eksempel kan man bruge værktøjer til "infrastruktur som kode" (IaC), som også kaldes middleware-automatiseringsværktøjer. Disse værktøjer hjælper med at automatisere installation, administration og andre opgaver for middleware. For eksempel kan et automatiseringsværktøj tage applikationer (webapplikationsserver, database, overvågningsværktøjer) med de rette konfigurationer og implementere dem på applikationsserveren.
Her er nogle åbne værktøjer til middleware-automatisering:
Læs videre i artiklerne på :
Og hvad nu?
Dette er kun toppen af isbjerget. DevOps-kæden kan meget mere. Start med et CI/CD-værktøj og find ud af, hvad der ellers kan automatiseres for at gøre dit arbejde lettere. Glem ikke til effektivt samarbejde.
Her er nogle flere gode artikler om DevOps for begyndere:
Man kan også integrere DevOps med åbne værktøjer til agile:
Kilde: habr.com
