As jy nuut is by DevOps, kyk gerus na hierdie gids om jou eerste vyf-stap pyplyn te bou.
DevOps het die standaardoplossing geword om stadige, ontkoppelde of stukkende sagteware-ontwikkelingsprosesse reg te stel. Die probleem is dat as jy nuut is by DevOps en nie weet waar om te begin nie, jy dalk 'n gebrek aan begrip van hierdie tegnieke het. Hierdie artikel sal fokus op die definisie van 'n DevOps-pyplyn, en sal ook instruksies gee oor hoe om dit in vyf stappe te skep. Alhoewel hierdie tutoriaal nie volledig is nie, behoort dit jou 'n grondslag te gee om aan die gang te kom en jou kennis in die toekoms uit te brei. Maar kom ons begin by die geskiedenis.
My DevOps-reis
Ek het voorheen vir die Citi Group-wolkspan gewerk om 'n Infrastruktuur-as-'n-diens (IaaS)-webtoepassing te ontwikkel om Citi se wolkinfrastruktuur te bestuur, maar ek was nog altyd geïnteresseerd in hoe om die ontwikkelingsproses doeltreffender te maak en positiewe kulturele verandering te bring aan die ontwikkelingspan. Ek het die antwoord gevind in 'n boek wat aanbeveel is deur Greg Lavender, Citi se CTO vir Wolkargitektuur en Infrastruktuur. Die boek is genoem "The Phoenix Project" () en verduidelik DevOps-beginsels terwyl jy soos 'n roman lees.
Die tabel op die agterkant van die boek wys hoe gereeld verskillende maatskappye hul stelsels in 'n vrystellingsomgewing ontplooi:
Amazon: 23 000 per dag
Google: 5 500 per dag
Netflix: 500 per dag
Facebook: Een keer per dag
Twitter: 3 keer per week
Tipiese maatskappy: Een keer elke 9 maande
Hoe is die frekwensies van Amazon, Google en Netflix selfs moontlik? Dit is omdat hierdie maatskappye uitgevind het hoe om 'n byna perfekte DevOps-pyplyn te maak.
Ons was ver daarvan af totdat ons DevOps by Citi geïmplementeer het. Op daardie tydstip het my span verskillende omgewings gehad, maar die ontplooiing na die ontwikkelingsbediener was heeltemal handmatig. Alle ontwikkelaars het toegang gehad tot slegs een ontwikkelingsbediener gebaseer op IBM WebSphere Application Server Community Edition. Die probleem was dat die bediener sou afskakel wanneer verskeie gebruikers gelyktydig probeer ontplooi het, so die ontwikkelaars moes mekaar hul bedoelings laat weet, wat redelik pynlik was. Daarbenewens was daar probleme met laevlak-kode-toetsdekking, omslagtige handmatige ontplooiingsprosesse en die onvermoë om die ontplooiing van kode wat met 'n spesifieke taak of gebruikerverhaal geassosieer word, op te spoor.
Ek het besef dat iets gedoen moet word, en ek het 'n eendersdenkende kollega gekry. Ons het besluit om saam te werk aan die bou van die aanvanklike DevOps-pyplyn - hy het 'n Tomcat virtuele masjien en toepassingsbediener opgestel terwyl ek aan Jenkins gewerk het, Atlassian Jira en BitBucket geïntegreer het, en aan kodetoetsdekking gewerk het. Hierdie syprojek was baie suksesvol: ons het baie prosesse byna heeltemal geoutomatiseer, byna 100% uptyd op ons ontwikkelingsbediener bereik, nasporing en verbeterde kodetoetsdekking verskaf, en die vermoë bygevoeg om takke in Git aan kwessies in Jira of ontplooiing te koppel. Die meeste van die gereedskap wat ons gebruik het om ons DevOps-pyplyn te bou, was oopbron.
Nou verstaan ek hoe eenvoudig ons DevOps-pyplyn was: ons het nie uitbreidings soos Jenkins-lêers of Ansible gebruik nie. Hierdie eenvoudige pyplyn het egter goed gewerk, miskien danksy die Pareto-beginsel (ook bekend as die 80/20-reël).
'n Kort inleiding tot DevOps en die CI/CD-pyplyn
As jy 'n paar mense vra "Wat is DevOps?" sal jy waarskynlik 'n paar verskillende antwoorde kry. DevOps, soos Agile, het ontwikkel om baie verskillende dissiplines te omvat, maar die meeste mense sal oor 'n paar dinge saamstem: DevOps is 'n sagteware-ontwikkelingspraktyk of sagteware-ontwikkelingslewensiklus (SDLC) wie se sentrale beginsel is om die kultuur waarin ontwikkelaars en nie -ontwikkelaars bestaan in 'n omgewing waar:
Outomatiese bewerkings wat voorheen met die hand uitgevoer is;
Elkeen doen wat hy die beste doen;
Die aantal implementerings vir 'n sekere tydperk neem toe; Verhoogde deurset;
Verhoogde ontwikkelingsbuigsaamheid.
Alhoewel die regte sagteware-nutsmiddels nie die enigste ding is wat jy nodig het om 'n DevOps-omgewing te skep nie, is sommige gereedskap noodsaaklik. Die sleutelinstrument is deurlopende integrasie en deurlopende ontplooiing (CI/CD). In hierdie pyplyn het omgewings verskillende stadiums (bv. DEV, INT, TST, QA, UAT, STG, PROD), baie bedrywighede is geoutomatiseer, en ontwikkelaars kan kode van hoë gehalte skryf, ontwikkelingsbehendigheid en hoë ontplooiingsfrekwensie bereik.
Hierdie artikel beskryf 'n vyf-stap-benadering om 'n DevOps-pyplyn te bou soortgelyk aan die een wat in die volgende diagram getoon word met behulp van oopbronnutsgoed.
Stap 1: CI/CD Metodes
Die eerste ding wat jy nodig het, is 'n CI/CD-instrument. Jenkins, 'n oopbron-instrument gebaseer op Java en gelisensieer onder die MIT-lisensie, is die instrument wat DevOps gewild gemaak het en die de facto-standaard geword het.
So wat is Jenkins? Dink daaraan as 'n soort magiese universele afstandbeheer wat met verskillende dienste en gereedskap kan praat en organiseer. Op sy eie is 'n CI/CD-instrument soos Jenkins nutteloos, maar dit word kragtiger namate dit aan verskillende gereedskap en dienste koppel.
Jenkins is net een van vele oopbron CI/CD-nutsmiddels wat jy kan gebruik om jou DevOps-pyplyn te bou.
Jenkins: Creative Commons en MIT
Travis CI: MIT
Cruise Control: BSD
Boubot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Hier is hoe DevOps-prosesse lyk met 'n CI/CD-instrument:
Jy het 'n CI/CD-instrument wat op jou plaaslike gasheer loop, maar daar is nie veel wat jy op die oomblik kan doen nie. Kom ons gaan aan na die volgende stap in ons DevOps-reis.
Stap 2: Bestuur van bronkodebeheerstelsels
Die beste (en moontlik maklikste) manier om te toets dat jou CI/CD-instrument towerkuns kan doen, is om te integreer met 'n bronkodebeheer-instrument (SCM). Hoekom het jy bronbeheer nodig? Kom ons sê jy ontwikkel 'n toepassing. Wanneer jy 'n toepassing skep, programmeer jy, of jy Java, Python, C++, Go, Ruby, JavaScript of enige van 'n miljoen programmeertale gebruik. Die kode wat jy skryf word bronkode genoem. In die begin, veral as jy alleen werk, is dit waarskynlik goed om alles in 'n plaaslike gids te plaas. Maar soos die projek groter word en jy ander mense nooi om by te dra, het jy 'n manier nodig om konflikte te vermy terwyl jy wysigings effektief deel. Jy het ook 'n manier nodig om vorige weergawes te herstel, want die skep van rugsteun en kopieer/plak daarin is reeds verouderd. Jy (en jou spanmaats) het iets beters nodig.
Dit is waar bronkodebeheer amper 'n noodsaaklikheid word. Hierdie instrument hou jou kode in bewaarplekke, hou boek van weergawes en koördineer die werk van projekdeelnemers.
Alhoewel daar baie bronkodebeheerinstrumente daar buite is, is Git die standaard, en met reg. Ek beveel sterk aan om Git te gebruik, alhoewel daar ander oopbronopsies is as jy wil.
Git: GPLv2 en LGPL v2.1
Subversion: Apache 2.0
Gelyktydige weergawes-stelsel (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Dit is hoe 'n DevOps-pyplyn lyk met die byvoeging van bronkodekontroles.
'n CI/CD-instrument kan die prosesse van verifikasie, bronkode-verkryging en samewerking tussen lede outomatiseer. Nie sleg nie? Maar hoe maak jy dit in 'n werkende toepassing sodat miljarde mense dit kan gebruik en waardeer?
Stap 3: Skep 'n Bou-outomatiseringsinstrument
Puik! Jy kan die kode nagaan en veranderinge aan die bronkodebeheerstelsel aanbring, asook jou vriende nooi om by te dra tot die ontwikkeling. Maar jy het nog nie 'n toepassing geskep nie. Om 'n webtoepassing te maak, moet dit saamgestel en verpak word in 'n ontplooibare pakketformaat of as 'n uitvoerbare lêer uitgevoer word. (Let daarop dat 'n geïnterpreteerde programmeertaal soos JavaScript of PHP nie saamgestel hoef te word nie.)
Gebruik 'n bou-outomatiseringsinstrument. Ongeag watter bou-outomatiseringsinstrument jy kies om te gebruik, hulle deel almal dieselfde doel: om bronkode in een of ander gewenste formaat in te bou en die taak om skoon te maak, saam te stel, te toets en te ontplooi na 'n spesifieke omgewing te outomatiseer. Bou-nutsgoed sal wissel na gelang van jou programmeertaal, maar hier is 'n paar algemene oopbron-opsies.
Naam
lisensie
Programmeringstaal
Maven
Apache 2.0
Java
Ant
Apache 2.0
Java
graad
Apache 2.0
Java
Bazel
Apache 2.0
Java
maak
GNU
N / A
swaar
MIT
JavaScript
Sluk
MIT
JavaScript
Bouer
Apache
Ruby
hark
MIT
Ruby
AAP
GNU
Python
SKons
MIT
Python
bitbake
GPLv2
Python
koek
MIT
C#
asdf
Expat (MIT)
LISP
Cabal
BSD
Haskell
Puik! U kan die konfigurasielêers vir die bou-outomatiseringsinstrument in bronbeheer plaas en u CI/CD-instrument alles saamstel.
Dit is alles goed, is dit nie? Maar waar om jou aansoek te ontplooi?
Stap 4: Webtoepassingsbediener
Tot dusver het jy 'n verpakte lêer wat óf uitvoerbaar óf installeerbaar kan wees. Vir enige toepassing om werklik bruikbaar te wees, moet dit 'n soort diens of koppelvlak bied, maar jy het 'n houer nodig om jou toepassing te huisves.
Die webtoepassingsbediener is net so 'n houer. Die bediener verskaf 'n omgewing waarin die logika van die pakket wat ontplooi word, gedefinieer kan word. Die bediener bied ook 'n koppelvlak en bied webdienste aan deur voetstukke na die buitewêreld oop te maak. Jy benodig 'n HTTP-bediener sowel as 'n omgewing (soos 'n virtuele masjien) om dit op te stel. Kom ons neem vir eers aan dat jy meer hieroor leer (hoewel ek houers hieronder sal dek).
Daar is verskeie oopbron-webtoepassingsbedieners.
Naam
lisensie
Programmeringstaal
Tomcat
Apache 2.0
Java
kaai
Apache 2.0
Java
Wildvlieg
GNU Lesser Public
Java
Glas
CDDL & GNU Minder Publiek
Java
Django
3-klousuleBSD
Python
Tornado
Apache 2.0
Python
geweerhoring
MIT
Python
Python
MIT
Python
Rails
MIT
Ruby
Node.js
MIT
Javascript
Jou DevOps-pyplyn is amper gereed om te gebruik. Goeie werk!
Alhoewel u daar kan stop en self die integrasie doen, is kodekwaliteit 'n belangrike ding vir 'n toepassingsontwikkelaar om oor bekommerd te wees.
Stap 5: Kodetoetsdekking
Die implementering van toetse kan nog 'n omslagtige vereiste wees, maar ontwikkelaars moet enige foute in die toepassing vroeg opspoor en kodekwaliteit verbeter om te verseker dat eindgebruikers tevrede is. Gelukkig is daar baie oopbronnutsgoed beskikbaar om u kode te toets en aanbevelings te maak om die kwaliteit daarvan te verbeter. Nog beter, die meeste CI/CD-instrumente kan by hierdie gereedskap aansluit en die proses outomatiseer.
Kodetoetsing bestaan uit twee dele: kodetoetsraamwerke wat jou help om toetse te skryf en uit te voer, en voorstellenutsmiddels wat help om kodekwaliteit te verbeter.
Kode toets stelsels
Naam
lisensie
Programmeringstaal
JUnit
Eclipse Public License
Java
Maklik Mock
Apache
Java
mockito
MIT
Java
powermock
Apache 2.0
Java
Pytest
MIT
Python
hipotese
Mozilla
Python
Gif
MIT
Python
Kode verbetering aanbeveling stelsels
Naam
lisensie
Programmeringstaal
Dekking
GNU
Java
kodeomslag
Eclipse Public (EPL)
Java
Coverage.py
Apache 2.0
Python
Emma
Algemene publieke lisensie
Java
JaCoCo
Eclipse Public License
Java
hipotese
Mozilla
Python
Gif
MIT
Python
Jasmine
MIT
JavaScript
Karma
MIT
JavaScript
mokka
MIT
JavaScript
daar is
MIT
JavaScript
Let daarop dat die meeste van die gereedskap en raamwerke hierbo genoem is vir Java, Python en JavaScript geskryf, aangesien C++ en C# eie programmeertale is (al is GCC oopbron).
Noudat jy kodedekkingnutsmiddels geïmplementeer het, behoort jou DevOps-pyplyn soortgelyk te lyk aan die diagram wat aan die begin van hierdie tutoriaal gewys word.
Bykomende stappe
Houers
Soos ek voorheen gesê het, kan u u bediener in 'n virtuele masjien of bediener huisves, maar houers is 'n gewilde oplossing.
Wat is houers? Die kort verduideliking is dat 'n virtuele masjien 'n groot hoeveelheid bedryfstelselgeheue benodig, meer as die grootte van 'n toepassing, terwyl 'n houer slegs 'n paar biblioteke en konfigurasies benodig om 'n toepassing te laat loop. Natuurlik is daar steeds belangrike gebruike vir 'n virtuele masjien, maar 'n houer is 'n liggewig oplossing om 'n toepassing te huisves, insluitend 'n toepassingsbediener.
Terwyl daar ander houeropsies bestaan, is Docker en Kubernetes die gewildste.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Intermediêre outomatisering gereedskap
Ons DevOps-pyplyn is hoofsaaklik daarop gefokus om toepassings saam te skep en te ontplooi, maar daar is baie ander dinge wat jy met DevOps-nutsgoed kan doen. Een hiervan is die gebruik van Infrastruktuur as Kode (IaC) gereedskap, wat ook bekend staan as middelware outomatisering gereedskap. Hierdie instrumente help om installasie, bestuur en ander take vir middelware te outomatiseer. So, byvoorbeeld, kan 'n outomatiseringsinstrument toepassings soos 'n webtoepassingsbediener, 'n databasis en 'n moniteringsinstrument met die regte konfigurasies onttrek en dit na 'n toepassingsbediener ontplooi.
Hier is 'n paar oopbronmiddelware-outomatiseringsinstrumente:
Ansible: GNU Public
SaltStack: Apache 2.0
Sjef: Apache 2.0
Poppie: Apache of GPL
Vind die besonderhede uit van hoe om 'n gesogte beroep van nuuts af te kry of Level Up in terme van vaardighede en salaris deur SkillFactory betaalde aanlynkursusse te voltooi:
- (12 maande)
meer kursusse
- (12 weke)
- (12 maande)
- (9 maande)
- (9 maande)
nuttige
Bron: will.com