Hvis du er ny til DevOps, så tag et kig på denne guide til at bygge din første fem-trins pipeline.
DevOps er blevet standardløsningen til at reparere langsomme, afbrudte eller ødelagte softwareudviklingsprocesser. Problemet er, at hvis du er ny til DevOps og ikke ved, hvor du skal starte, så mangler du måske forståelse for disse teknikker. Denne artikel vil fokusere på at definere en DevOps-pipeline og vil også tilbyde instruktioner om, hvordan man opretter den i fem trin. Selvom denne vejledning ikke er udtømmende, bør den give dig et grundlag for at komme i gang og udvide din viden i fremtiden. Men lad os starte med historien.
Min DevOps-rejse
Jeg har tidligere arbejdet for Citi Groups cloud-team med at udvikle en Infrastructure-as-a-Service (IaaS) webapplikation til at administrere Citis cloud-infrastruktur, men jeg har altid været interesseret i, hvordan man kan gøre udviklingsprocessen mere effektiv og bringe positiv kulturel forandring til udviklingsteamet. Jeg fandt svaret i en bog anbefalet af Greg Lavender, Citis CTO for Cloud Architecture and Infrastructure. Bogen hed "The Phoenix Project" () og forklarer DevOps-principperne, mens du læser som en roman.
Tabellen på bagsiden af bogen viser, hvor ofte forskellige virksomheder implementerer deres systemer i et udgivelsesmiljø:
Amazon: 23 om dagen
Google: 5 pr. dag
Netflix: 500 pr. dag
Facebook: En gang om dagen
Twitter: 3 gange om ugen
Typisk virksomhed: En gang hver 9. måned
Hvordan er frekvenserne for Amazon, Google og Netflix overhovedet mulige? Dette skyldes, at disse virksomheder fandt ud af, hvordan man laver en næsten perfekt DevOps-pipeline.
Det var vi langt fra, før vi implementerede DevOps hos Citi. På det tidspunkt havde mit team forskellige miljøer, men udrulningen til udviklingsserveren var fuldstændig manuel. Alle udviklere havde kun adgang til én udviklingsserver baseret på IBM WebSphere Application Server Community Edition. Problemet var, at serveren ville lukke ned, når flere brugere forsøgte at implementere på samme tid, så udviklerne var nødt til at fortælle hinanden deres hensigter, hvilket var ret smertefuldt. Derudover var der problemer med kodetestdækning på lavt niveau, besværlige manuelle implementeringsprocesser og manglende evne til at spore implementeringen af kode forbundet med en bestemt opgave eller brugerhistorie.
Jeg indså, at der skulle gøres noget, og jeg fandt en ligesindet kollega. Vi besluttede at samarbejde om at bygge den indledende DevOps-pipeline - han satte en Tomcat virtuel maskine og applikationsserver op, mens jeg arbejdede på Jenkins, integrerede Atlassian Jira og BitBucket og arbejdede med kodetestdækning. Dette sideprojekt var meget vellykket: vi automatiserede næsten fuldstændig mange processer, nåede næsten 100 % oppetid på vores udviklingsserver, sørgede for sporing og forbedret kodetestdækning og tilføjede muligheden for at linke filialer i Git til problemer i Jira eller implementering. De fleste af de værktøjer, vi brugte til at bygge vores DevOps-pipeline, var open source.
Nu forstår jeg, hvor enkel vores DevOps-pipeline var: vi brugte ikke udvidelser som Jenkins-filer eller Ansible. Denne simple pipeline fungerede dog godt, måske takket være Pareto-princippet (også kendt som 80/20-reglen).
En kort introduktion til DevOps og CI/CD-pipeline
Hvis du spørger nogle få personer "Hvad er DevOps?" vil du sandsynligvis få et par forskellige svar. DevOps har ligesom Agile udviklet sig til at omfatte mange forskellige discipliner, men de fleste vil være enige om et par ting: DevOps er en softwareudviklingspraksis eller softwareudviklingslivscyklus (SDLC), hvis centrale princip er at ændre den kultur, hvori udviklere og ikke-udviklere eksisterer i et miljø, hvor:
Automatiserede operationer, der tidligere blev udført manuelt;
Enhver gør det, han er bedst til;
Antallet af implementeringer i en vis periode stiger; Øget gennemløb;
Øget udviklingsfleksibilitet.
Selvom det ikke er det eneste, du behøver for at skabe et DevOps-miljø at have de rigtige softwareværktøjer, er nogle værktøjer essentielle. Nøgleværktøjet er kontinuerlig integration og kontinuerlig implementering (CI/CD). I denne pipeline har miljøer forskellige stadier (f.eks. DEV, INT, TST, QA, UAT, STG, PROD), mange operationer er automatiserede, og udviklere kan skrive kode af høj kvalitet, opnå agilitet i udvikling og høj implementeringsfrekvens.
Denne artikel beskriver en fem-trins tilgang til at bygge en DevOps-pipeline svarende til den, der er vist i det følgende diagram, ved hjælp af open source-værktøjer.
Trin 1: CI/CD-metoder
Det første du skal bruge er et CI/CD-værktøj. Jenkins, et open source-værktøj baseret på Java og licenseret under MIT-licensen, er det værktøj, der populariserede DevOps og blev de facto-standarden.
Så hvad er Jenkins? Tænk på det som en slags magisk universel fjernbetjening, der kan tale med og organisere forskellige tjenester og værktøjer. I sig selv er et CI/CD-værktøj som Jenkins ubrugeligt, men det bliver mere kraftfuldt, da det forbinder til forskellige værktøjer og tjenester.
Jenkins er blot et af mange open source CI/CD-værktøjer, som du kan bruge til at bygge din DevOps-pipeline.
Jenkins: Creative Commons og MIT
Travis CI: MIT
CruiseControl:BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Sådan ser DevOps-processer ud med et CI/CD-værktøj:
Du har et CI/CD-værktøj kørende på din lokale vært, men der er ikke meget du kan gøre i øjeblikket. Lad os gå videre til næste trin i vores DevOps-rejse.
Trin 2: Håndtering af kildekodekontrolsystemer
Den bedste (og muligvis nemmeste) måde at teste, at dit CI/CD-værktøj kan magi, er at integrere med et kildekodekontrolværktøj (SCM). Hvorfor har du brug for kildekontrol? Lad os sige, at du er ved at udvikle en applikation. Når du opretter en applikation, programmerer du, uanset om du bruger Java, Python, C++, Go, Ruby, JavaScript eller et hvilket som helst af en gazillion programmeringssprog. Den kode du skriver kaldes kildekode. I begyndelsen, især når du arbejder alene, er det sikkert fint at lægge alt i en lokal mappe. Men efterhånden som projektet bliver større, og du inviterer andre mennesker til at bidrage, har du brug for en måde at undgå konflikter på, mens du deler ændringer effektivt. Du har også brug for en måde at gendanne tidligere versioner på, fordi oprettelse af sikkerhedskopier og kopiering/indsættelse i dem allerede er forældet. Du (og dine holdkammerater) har brug for noget bedre.
Det er her kildekodekontrol bliver nærmest en nødvendighed. Dette værktøj opbevarer din kode i arkiver, holder styr på versioner og koordinerer projektdeltagernes arbejde.
Selvom der er mange kildekodekontrolværktøjer derude, er Git standarden, og det med rette. Jeg anbefaler stærkt at bruge Git, selvom der er andre open source-muligheder, hvis du vil.
Git: GPLv2 og LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Sådan ser en DevOps-pipeline ud med tilføjelsen af kildekodekontroller.
Et CI/CD-værktøj kan automatisere processerne for verifikation, kildekodeanskaffelse og samarbejde mellem medlemmer. Ikke dårligt? Men hvordan gør man det til en fungerende applikation, så milliarder af mennesker kan bruge og værdsætte det?
Trin 3: Opret et Build Automation Tool
Store! Du kan tjekke koden og foretage ændringer i kildekodekontrolsystemet, samt invitere dine venner til at bidrage til udviklingen. Men du har ikke oprettet en applikation endnu. For at lave en webapplikation skal den kompileres og pakkes i et deployerbart pakkeformat eller køres som en eksekverbar fil. (Bemærk, at et fortolket programmeringssprog såsom JavaScript eller PHP ikke behøver at blive kompileret.)
Brug et byggeautomatiseringsværktøj. Uanset hvilket byggeautomatiseringsværktøj du vælger at bruge, deler de alle det samme mål: at bygge kildekode i et ønsket format og automatisere opgaven med at rense, kompilere, teste og implementere til et specifikt miljø. Byggeværktøjer vil variere afhængigt af dit programmeringssprog, men her er nogle almindelige open source-muligheder.
Navn
Licens
Programmeringssprog
Maven
Apache 2.0
Java
Ant
Apache 2.0
Java
Gradle
Apache 2.0
Java
Bazel
Apache 2.0
Java
Lave
GNU
N / A
Grunt
MIT
JavaScript
Gulp
MIT
JavaScript
Bygger
Apache
Rubin
Rive
MIT
Rubin
AAP
GNU
Python
SCons
MIT
Python
bitbake
GPLv2
Python
Kage
MIT
C#
asdf
Expat (MIT)
lisp
Cabal
BSD
Haskell
Store! Du kan sætte konfigurationsfilerne til byggeautomatiseringsværktøjet i kildestyring og lade dit CI/CD-værktøj sætte alt sammen.
Det er alt sammen godt, ikke? Men hvor skal du implementere din applikation?
Trin 4: Webapplikationsserver
Indtil videre har du en pakket fil, der enten kan eksekveres eller installeres. For at enhver applikation virkelig kan være nyttig, skal den give en form for service eller grænseflade, men du har brug for en container til at være vært for din applikation.
Webapplikationsserveren er netop sådan en container. Serveren giver et miljø, hvor logikken for den pakke, der implementeres, kan defineres. Serveren giver også en grænseflade og tilbyder webtjenester ved at åbne stikkontakter til omverdenen. Du skal bruge en HTTP-server samt et eller andet miljø (som en virtuel maskine) for at konfigurere den. Indtil videre, lad os antage, at du lærer mere om dette yderligere (selvom jeg vil dække beholdere nedenfor).
Der er flere open source webapplikationsservere.
Navn
Licens
Programmeringssprog
Tomcat
Apache 2.0
Java
Anløbsbro
Apache 2.0
Java
WildFly
GNU Lesser Public
Java
Glasfisk
CDDL & GNU Mindre offentligt
Java
Django
3-klausul BSD
Python
Tornado
Apache 2.0
Python
kanonhjørning
MIT
Python
Python
MIT
Python
Skinner
MIT
Rubin
node.js
MIT
Javascript
Din DevOps-pipeline er næsten klar til brug. Godt arbejde!
Selvom du kan stoppe der og selv udføre integrationen, er kodekvalitet en vigtig ting for en applikationsudvikler at bekymre sig om.
Trin 5: Kodetestdækning
Implementering af test kan være et andet besværligt krav, men udviklere skal fange eventuelle fejl i applikationen tidligt og forbedre kodekvaliteten for at sikre, at slutbrugerne er tilfredse. Heldigvis er der mange open source-værktøjer tilgængelige til at teste din kode og komme med anbefalinger til at forbedre dens kvalitet. Endnu bedre, de fleste CI/CD-værktøjer kan tilsluttes disse værktøjer og automatisere processen.
Kodetest kommer i to dele: Kodetestrammer, der hjælper dig med at skrive og køre test, og forslagsværktøjer, der hjælper med at forbedre kodekvaliteten.
Kode test systemer
Navn
Licens
Programmeringssprog
JUnit
Eclipse Public License
Java
Nem Mock
Apache
Java
mockito
MIT
Java
powermock
Apache 2.0
Java
Pytest
MIT
Python
Hypotese
Mozilla
Python
Tox
MIT
Python
Kodeforbedringsanbefalingssystemer
Navn
Licens
Programmeringssprog
Dækning
GNU
Java
kodecover
Eclipse Public (EPL)
Java
Coverage.py
Apache 2.0
Python
Emma
Fælles offentlig licens
Java
JaCoCo
Eclipse Public License
Java
Hypotese
Mozilla
Python
Tox
MIT
Python
Jasmine
MIT
JavaScript
Karma
MIT
JavaScript
mokka
MIT
JavaScript
der er
MIT
JavaScript
Bemærk, at de fleste af værktøjerne og rammerne nævnt ovenfor er skrevet til Java, Python og JavaScript, da C++ og C# er proprietære programmeringssprog (selvom GCC er open source).
Nu hvor du har implementeret kodedækningsværktøjer, bør din DevOps-pipeline ligne diagrammet vist i begyndelsen af denne øvelse.
Yderligere trin
Containere
Som jeg sagde før, kan du hoste din server i en virtuel maskine eller server, men containere er en populær løsning.
Hvad er containere? Den korte forklaring er, at en virtuel maskine har brug for en enorm mængde operativsystemhukommelse, mere end størrelsen af en applikation, mens en container kun behøver nogle få biblioteker og konfigurationer for at køre en applikation. Naturligvis er der stadig vigtige anvendelser for en virtuel maskine, men en container er en letvægtsløsning til at hoste en applikation, herunder en applikationsserver.
Mens der findes andre containermuligheder, er Docker og Kubernetes de mest populære.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Mellemliggende automatiseringsværktøjer
Vores DevOps-pipeline er primært fokuseret på samskabelse og implementering af applikationer, men der er mange andre ting, du kan gøre med DevOps-værktøjer. En af disse er brugen af Infrastructure as Code (IaC) værktøjer, som også er kendt som middleware automatiseringsværktøjer. Disse værktøjer hjælper med at automatisere installation, administration og andre opgaver til middleware. Så for eksempel kan et automatiseringsværktøj udtrække applikationer som en webapplikationsserver, en database og et overvågningsværktøj med de rigtige konfigurationer og implementere dem til en applikationsserver.
Her er nogle open source middleware automatiseringsværktøjer:
Ansible: GNU Public
SaltStack: Apache 2.0
Kok: Apache 2.0
Dukke: Apache eller GPL
Find ud af detaljerne om, hvordan du får et efterspurgt erhverv fra bunden eller Level Up med hensyn til færdigheder og løn ved at gennemføre SkillFactory betalte onlinekurser:
- (12 måneder)
flere kurser
- (12 uger)
- (12 måneder)
- (9 måneder)
- (9 måneder)
nyttig
Kilde: www.habr.com