Byg din første DevOps-kæde i fem trin for begyndere.
DevOps er blevet et universalmiddel for for langsomme, afbrudte og ellers problematiske udviklingsprocesser. Men du har brug for minimal viden i DevOps. Det vil dække begreber som DevOps-kæden og hvordan man opretter en i fem trin. Dette er ikke en komplet guide, men kun en "fisk", der kan udvides. Lad os starte med historien.
Min introduktion til DevOps
Jeg har tidligere arbejdet med clouds hos Citi Group og udviklet en IaaS-webapplikation til at administrere Citis cloud-infrastruktur, men jeg har altid været interesseret i, hvordan man optimerer udviklingskæden og forbedrer kulturen blandt udviklere. Greg Lavender, vores CTO for Cloud Architecture and Infrastructure, anbefalede denne bog til mig. . Den forklarer DevOps-principperne smukt og læser som en roman.
Tabellen på bagsiden viser, hvor ofte virksomheder udruller nye versioner:
Hvordan formår Amazon, Google og Netflix at rulle så meget ud? Og det er enkelt: de fandt ud af, hvordan man skaber en næsten perfekt DevOps-kæde.
Tingene var meget anderledes for os hos Citi, indtil vi skiftede til DevOps. Så havde mit team forskellige miljøer, men vi foretog leveringen til udviklingsserveren manuelt. Alle udviklere havde kun adgang til én udviklingsserver baseret på IBM WebSphere Application Server Community Edition. Med et samtidig forsøg på at levere "faldt" serveren, og hver gang måtte vi "smerteligt" forhandle indbyrdes. Vi havde også utilstrækkelig kodedækning med test, en tidskrævende manuel leveringsproces og ingen måde at spore leveringen af kode ved hjælp af en opgave eller klientkrav.
Det var tydeligt, at noget akut skulle gøres, og jeg fandt en ligesindet kollega. Vi besluttede os for at skabe den første DevOps-kæde sammen – han satte en virtuel maskine og en Tomcat-applikationsserver op, og jeg tog mig af Jenkins, integration med Atlassian Jira og BitBucket, samt kodedækning med test. Projektet var vellykket: vi fuldautomatiserede udviklingskæden, opnåede næsten 100 % oppetid på udviklingsserveren, var i stand til at overvåge og forbedre kodedækningen med test, og en Git-gren kunne knyttes til en Jira-levering og -problem. Og næsten alle de værktøjer, vi brugte til at bygge DevOps-kæden, var open source.
Faktisk blev kæden forenklet, fordi vi ikke engang anvendte avancerede konfigurationer ved hjælp af Jenkins eller Ansible. Men det lykkedes. Måske er dette en konsekvens af princippet (alias 80/20-reglen).
En kort beskrivelse af DevOps og CI/CD-kæden
DevOps har forskellige definitioner. DevOps omfatter ligesom Agile forskellige discipliner. Men de fleste vil være enige i følgende definition: DevOps er en metode, eller livscyklus, til softwareudvikling, hvis hovedprincip er at skabe en kultur, hvor udviklere og andre medarbejdere er "på samme bølgelængde", manuelt arbejde er automatiseret, alle gør det, de er bedst til, leveringshyppigheden øges, produktiviteten i arbejdet øges, fleksibiliteten øges.
Selvom værktøjer alene ikke er nok til at skabe et DevOps-miljø, er de uundværlige. Den vigtigste af disse er kontinuerlig integration og kontinuerlig levering (CI/CD). Der er forskellige stadier i kæden for hvert miljø (fx DEV (udvikling), INT (integration), TST (test), QA (kvalitetssikring), UAT (brugeraccepttest), STG (forberedelse), PROD (brug)) , manuelle opgaver automatiseres, udviklere kan lave kvalitetskode, levere den og kan nemt genopbygge.
Denne note beskriver, hvordan du opretter en DevOps-kæde i fem trin, som vist på billedet nedenfor, ved hjælp af open source-værktøjer.
Lad os komme i gang.
Trin 1: CI/CD-platform
Først og fremmest skal du bruge et CI/CD-værktøj. Jenkins er et MIT-licenseret, open source CI/CD-værktøj skrevet i Java, som populariserede DevOps-bevægelsen og er blevet de facto-standarden for CICD.
Hvad er Jenkins? Forestil dig, at du har et magisk kontrolpanel til en række tjenester og værktøjer. I sig selv er et CI/CD-værktøj som Jenkins ubrugeligt, men med forskellige værktøjer og tjenester bliver det almægtigt.
Ud over Jenkins er der mange andre open source-værktøjer, vælg evt.
Sådan ser en DevOps-proces ud med et CI/CD-værktøj
Du har et CI/CD-værktøj i localhost, men der er ikke meget at gøre endnu. Lad os gå videre til næste trin.
Trin 2: Versionering
Den bedste (og uden tvivl nemmeste) måde at teste magien ved et CI/CD-værktøj på er at integrere det med et kildekontrolstyringsværktøj (SCM). Hvorfor har du brug for versionskontrol? Lad os sige, at du laver en ansøgning. Du skriver det på Java, Python, C++, Go, Ruby, JavaScript eller et hvilket som helst andet sprog, der er en vogn og en lille vogn. Det du skriver kaldes kildekode. I starten, især hvis du arbejder alene, kan du gemme alt i en lokal mappe. Men efterhånden som projektet vokser, og flere mennesker slutter sig til, har du brug for en måde at dele kodeændringer på, men undgå konflikter ved sammenlægning af ændringer. Og du skal også på en eller anden måde gendanne tidligere versioner uden at bruge sikkerhedskopier og bruge copy-paste-metoden til kodefiler.
Og her uden SCM nogen steder. SCM gemmer kode i repositories, administrerer versioner af den og koordinerer den blandt udviklere.
Der er mange SCM-værktøjer, men Git er fortjent blevet de facto-standarden. Jeg råder dig til at bruge det, men der er andre muligheder.
Sådan ser DevOps-pipelinen ud efter tilføjelse af SCM.
CI/CD-værktøjet kan automatisere upload og download af kildekode og teamsamarbejde. Ikke dårligt? Men hvordan laver man nu en fungerende applikation ud fra dette, elsket af milliarder af brugere?
Trin 3: Byg automatiseringsværktøj
Alt går som det skal. Du kan uploade kode og foretage ændringer til kildekontrol og invitere venner til at arbejde sammen med dig. Men du har ikke en app endnu. For at dette skal være en webapplikation, skal det være kompileret og pakket til distribution eller køre som en eksekverbar. (Et fortolket programmeringssprog som JavaScript eller PHP behøver ikke at blive kompileret.)
Brug et byggeautomatiseringsværktøj. Uanset hvilket værktøj du vælger, vil det samle koden i det rigtige format og automatisere oprydning, kompilering, test og levering. Byggeværktøjer varierer efter sprog, men følgende open source-indstillinger er almindeligt anvendte.
Perfekt! Lad os nu indsætte byggeautomatiseringsværktøjets konfigurationsfiler i kildekontrol, så CI/CD-værktøjet bygger dem.
Det føles godt. Men hvor skal alt dette rulles ud nu?
Trin 4: Webapplikationsserver
Så du har en pakket fil, der kan udføres eller rulles ud. For at en applikation skal være virkelig nyttig, skal den have en form for tjeneste eller grænseflade, men du skal placere det hele et sted.
En webapplikation kan hostes på en webapplikationsserver. Applikationsserveren giver et miljø, hvor du kan udføre pakket logik, gengive grænseflader og eksponere webtjenester over en socket. Du skal bruge en HTTP-server og et par andre miljøer (f.eks. en virtuel maskine) for at installere applikationsserveren. Lad os indtil videre lade som om, du beskæftiger dig med alt dette, mens du går (selvom jeg vil tale om containere nedenfor).
Der er flere åbne webapplikationsservere.
Vi har allerede en næsten fungerende DevOps-kæde. Godt arbejde!
I princippet kan du stoppe her, så kan du klare det selv, men det er værd at tale om kodens kvalitet.
Trin 5: Testdækning
Testning tager meget tid og kræfter, men det er bedre at finde fejl med det samme og forbedre koden for at behage slutbrugerne. Til dette formål er der mange åbne værktøjer, som ikke kun vil teste koden, men også rådgive om, hvordan den kan forbedres. De fleste CI/CD-værktøjer kan tilsluttes disse værktøjer og automatisere processen.
Test er opdelt i to dele: testrammer til at skrive og udføre tests og værktøjer med tips til at forbedre kodekvaliteten.
Testrammer
Værktøjer med kvalitetstips
De fleste af disse værktøjer og rammer er skrevet til Java, Python og JavaScript, fordi C++ og C# er proprietære (selvom GCC er open source).
Vi har anvendt testdækningsværktøjerne, og nu skulle DevOps-pipelinen se ud som billedet i begyndelsen af selvstudiet.
Yderligere trin
Containere
Som jeg sagde før, kan en applikationsserver hostes i en virtuel maskine eller en server, men containere er mere populære.
? Kort sagt, i en virtuel maskine fylder operativsystemet ofte mere end applikationen, og en container rækker normalt med nogle få biblioteker og konfiguration. I nogle tilfælde er virtuelle maskiner uundværlige, men containeren kan rumme applikationen sammen med serveren uden ekstra omkostninger.
For containere tages normalt Docker og Kubernetes, selvom der er andre muligheder.
Læs artikler om Docker og Kubernetes på :
Middleware automatiseringsværktøjer
Vores DevOps-kæde er fokuseret på kollaborativ opbygning og levering af en applikation, men der er andre interessante ting, du kan gøre med DevOps-værktøjer. Brug for eksempel Infrastructure as Code (IaC) værktøjer, også kendt som middleware-automatiseringsværktøjer. Disse værktøjer hjælper med at automatisere installation, administration og andre opgaver til middleware. For eksempel kan et automatiseringsværktøj tage applikationer (webapplikationsserver, database, overvågningsværktøjer) med de korrekte konfigurationer og skubbe dem til applikationsserveren.
Her er nogle muligheder for åbne middleware-automatiseringsværktøjer:
Detaljer i artiklerne :
Og hvad nu?
Dette er kun toppen af isbjerget. DevOps-kæden kan meget mere. Start med et CI/CD-værktøj og se, hvad du ellers kan automatisere for at gøre dit arbejde lettere. Glem det ikke for effektivt samarbejde.
Her er nogle flere gode DevOps-artikler til begyndere:
Du kan også integrere DevOps med åbne agile værktøjer:
Kilde: www.habr.com