Bygg din første DevOps-kjede i fem trinn for nybegynnere.
DevOps har blitt et universalmiddel for for langsomme, frakoblede og ellers problematiske utviklingsprosesser. Men du trenger minimal kunnskap i DevOps. Den vil dekke konsepter som DevOps-kjeden og hvordan lage en i fem trinn. Dette er ikke en komplett guide, men kun en "fisk" som kan utvides. La oss starte med historien.
Min introduksjon til DevOps
Jeg pleide å jobbe med skyer hos Citi Group og utvikle en IaaS-webapplikasjon for å administrere Citis skyinfrastruktur, men jeg har alltid vært interessert i hvordan man kan optimalisere utviklingskjeden og forbedre kulturen blant utviklere. Greg Lavender, vår CTO for Cloud Architecture and Infrastructure, anbefalte denne boken til meg. . Den forklarer DevOps-prinsippene vakkert og leser som en roman.
Tabellen på baksiden viser hvor ofte selskaper ruller ut nye versjoner:
Hvordan klarer Amazon, Google og Netflix å rulle ut så mye? Og det er enkelt: de fant ut hvordan de skulle lage en nesten perfekt DevOps-kjede.
Ting var veldig annerledes for oss på Citi før vi byttet til DevOps. Da hadde teamet mitt forskjellige miljøer, men vi gjorde leveringen til utviklingsserveren manuelt. Alle utviklere hadde tilgang til kun én utviklingsserver basert på IBM WebSphere Application Server Community Edition. Med et samtidig forsøk på å levere "falt" serveren, og hver gang måtte vi "smertefullt" forhandle oss imellom. Vi hadde også utilstrekkelig kodedekning med tester, en tidkrevende manuell leveringsprosess, og ingen måte å spore levering av kode ved hjelp av en oppgave eller klientkrav.
Det var tydelig at noe akutt måtte gjøres, og jeg fant en likesinnet kollega. Vi bestemte oss for å lage den første DevOps-kjeden sammen – han satte opp en virtuell maskin og en Tomcat-applikasjonsserver, og jeg tok meg av Jenkins, integrasjon med Atlassian Jira og BitBucket, samt kodedekning med tester. Prosjektet var vellykket: vi fullautomatiserte utviklingskjeden, oppnådde nesten 100 % oppetid på utviklingsserveren, var i stand til å overvåke og forbedre kodedekningen med tester, og en Git-gren kunne knyttes til en Jira-leveranse og problem. Og nesten alle verktøyene vi brukte til å bygge DevOps-kjeden var åpen kildekode.
Faktisk ble kjeden forenklet, fordi vi ikke engang brukte avanserte konfigurasjoner med Jenkins eller Ansible. Men vi lyktes. Kanskje er dette en konsekvens av prinsippet (aka 80/20-regelen).
En kort beskrivelse av DevOps og CI/CD-kjeden
DevOps har forskjellige definisjoner. DevOps, som Agile, inkluderer forskjellige disipliner. Men de fleste vil være enige i følgende definisjon: DevOps er en metode, eller livssyklus, for programvareutvikling, hvor hovedprinsippet er å skape en kultur der utviklere og andre ansatte er «på samme bølgelengde», manuelt arbeid er automatisert, alle gjør det de er best på, leveringsfrekvensen øker, produktiviteten i arbeidet øker, fleksibiliteten øker.
Selv om verktøy alene ikke er nok til å lage et DevOps-miljø, er de uunnværlige. Den viktigste av disse er kontinuerlig integrasjon og kontinuerlig levering (CI/CD). Det er forskjellige stadier i kjeden for hvert miljø (f.eks. DEV (utvikling), INT (integrasjon), TST (testing), QA (kvalitetssikring), UAT (testing av brukeraksept), STG (forberedelse), PROD (bruk)) , manuelle oppgaver er automatisert, utviklere kan lage kvalitetskode, levere den og enkelt bygge om.
Dette notatet beskriver hvordan du oppretter en DevOps-kjede i fem trinn, som vist på bildet nedenfor, ved å bruke åpen kildekode-verktøy.
La oss komme i gang.
Trinn 1: CI/CD-plattform
Først av alt trenger du et CI/CD-verktøy. Jenkins er et MIT-lisensiert, åpen kildekode CI/CD-verktøy skrevet i Java som populariserte DevOps-bevegelsen og har blitt de facto-standarden for CICD.
Hva er Jenkins? Tenk deg at du har et magisk kontrollpanel for en rekke tjenester og verktøy. I seg selv er et CI/CD-verktøy som Jenkins ubrukelig, men med forskjellige verktøy og tjenester blir det allmektig.
I tillegg til Jenkins er det mange andre åpen kildekode-verktøy, velg hvilket som helst.
Slik ser en DevOps-prosess ut med et CI/CD-verktøy
Du har et CI/CD-verktøy i localhost, men det er ikke mye å gjøre ennå. La oss gå videre til neste trinn.
Trinn 2: Versjonskontroll
Den beste (og uten tvil enkleste) måten å teste magien til et CI/CD-verktøy er å integrere det med et verktøy for kildekontrollstyring (SCM). Hvorfor trenger du versjonskontroll? La oss si at du lager en søknad. Du skriver det på Java, Python, C++, Go, Ruby, JavaScript eller et hvilket som helst annet språk som er en vogn og en liten vogn. Det du skriver kalles kildekode. Til å begynne med, spesielt hvis du jobber alene, kan du lagre alt i en lokal katalog. Men etter hvert som prosjektet vokser og flere blir med, trenger du en måte å dele kodeendringer på, men unngå konflikter når du slår sammen endringer. Og du må også på en eller annen måte gjenopprette tidligere versjoner uten å bruke sikkerhetskopier og bruke kopier-lim-metoden for kodefiler.
Og her uten SCM noe sted. SCM lagrer kode i repositories, administrerer versjoner av den og koordinerer den blant utviklere.
Det er mange SCM-verktøy, men Git har fortjent blitt de facto-standarden. Jeg anbefaler deg å bruke den, men det finnes andre alternativer.
Slik ser DevOps-pipelinen ut etter å ha lagt til SCM.
CI/CD-verktøyet kan automatisere opplasting og nedlasting av kildekode og teamsamarbeid. Ikke verst? Men hvordan lage en fungerende applikasjon fra dette, elsket av milliarder av brukere?
Trinn 3: Bygg automatiseringsverktøy
Alt går som det skal. Du kan laste opp kode og foreta endringer i kildekontroll, og invitere venner til å samarbeide med deg. Men du har ikke en app ennå. For at dette skal være en nettapplikasjon, må den være kompilert og pakket for distribusjon eller kjøres som en kjørbar fil. (Et tolket programmeringsspråk som JavaScript eller PHP trenger ikke å bli kompilert.)
Bruk et byggeautomatiseringsverktøy. Uansett hvilket verktøy du velger, vil det sette sammen koden i riktig format og automatisere opprydding, kompilering, testing og levering. Byggeverktøy varierer etter språk, men følgende åpen kildekode-alternativer brukes ofte.
Perfekt! La oss nå sette inn konfigurasjonsfilene for byggeautomatiseringsverktøyet i kildekontrollen slik at CI/CD-verktøyet bygger dem.
Det føles godt. Men hvor skal alt dette rulles ut nå?
Trinn 4: Web Application Server
Så du har en pakket fil som kan kjøres eller rulles ut. For at en applikasjon skal være virkelig nyttig, må den ha en slags tjeneste eller grensesnitt, men du må legge alt et sted.
En webapplikasjon kan hostes på en webapplikasjonsserver. Applikasjonsserveren gir et miljø der du kan utføre pakket logikk, gjengi grensesnitt og eksponere webtjenester over en socket. Du trenger en HTTP-server og noen få andre miljøer (for eksempel en virtuell maskin) for å installere applikasjonsserveren. La oss foreløpig late som om du takler alt dette mens du går (selv om jeg skal snakke om containere nedenfor).
Det er flere åpne webapplikasjonsservere.
Vi har allerede en nesten fungerende DevOps-kjede. Flott jobb!
I prinsippet kan du stoppe her, så kan du håndtere det selv, men det er verdt å snakke om kvaliteten på koden.
Trinn 5: Testdekning
Testing tar mye tid og krefter, men det er bedre å finne feil med en gang og forbedre koden for å glede sluttbrukerne. For dette formålet er det mange åpne verktøy som ikke bare vil teste koden, men også gi råd om hvordan den kan forbedres. De fleste CI/CD-verktøy kan plugges inn i disse verktøyene og automatisere prosessen.
Testing er delt inn i to deler: testrammeverk for å skrive og utføre tester, og verktøy med hint for å forbedre kodekvaliteten.
Testing Rammer
Verktøy med kvalitetstips
De fleste av disse verktøyene og rammeverkene er skrevet for Java, Python og JavaScript fordi C++ og C# er proprietære (selv om GCC er åpen kildekode).
Vi har brukt testdekningsverktøyene, og nå skal DevOps-pipelinen se ut som bildet i begynnelsen av opplæringen.
Ytterligere trinn
containere
Som jeg sa før, kan en applikasjonsserver være vert for en virtuell maskin eller en server, men containere er mer populære.
? Kort sagt, i en virtuell maskin tar operativsystemet ofte opp mer plass enn applikasjonen, og en beholder er vanligvis tilstrekkelig med noen få biblioteker og konfigurasjon. I noen tilfeller er virtuelle maskiner uunnværlige, men beholderen kan romme applikasjonen sammen med serveren uten ekstra kostnad.
For containere tas Docker og Kubernetes vanligvis, selv om det finnes andre alternativer.
Les artikler om Docker og Kubernetes på :
Mellomvare-automatiseringsverktøy
Vår DevOps-kjede er fokusert på samarbeidsbygging og levering av en applikasjon, men det er andre interessante ting du kan gjøre med DevOps-verktøy. Bruk for eksempel Infrastructure as Code (IaC)-verktøy, også kjent som automatiseringsverktøy for mellomvare. Disse verktøyene hjelper til med å automatisere installasjon, administrasjon og andre oppgaver for mellomvare. For eksempel kan et automatiseringsverktøy ta applikasjoner (webapplikasjonsserver, database, overvåkingsverktøy) med riktige konfigurasjoner og skyve dem til applikasjonsserveren.
Her er noen alternativer for åpne automatiseringsverktøy for mellomvare:
Detaljer i artiklene :
Hva nå?
Dette er bare toppen av isfjellet. DevOps-kjeden kan mye mer. Start med et CI/CD-verktøy og se hva annet du kan automatisere for å gjøre jobben din enklere. Ikke glem for effektivt samarbeid.
Her er noen flere gode DevOps-artikler for nybegynnere:
Du kan også integrere DevOps med åpne smidige verktøy:
Kilde: www.habr.com