Bou jou eerste DevOps-ketting in vyf stappe vir beginners.
DevOps het 'n wondermiddel geword vir te stadige, ontkoppelde en andersins problematiese ontwikkelingsprosesse. Maar jy het minimale kennis in DevOps nodig. Dit sal konsepte soos die DevOps-ketting dek en hoe om een in vyf stappe te skep. Hierdie is nie 'n volledige gids nie, maar slegs 'n "vis" wat uitgebrei kan word. Kom ons begin met geskiedenis.
My inleiding tot DevOps
Ek het vroeër met wolke by Citi Group gewerk en 'n IaaS-webtoepassing ontwikkel om Citi se wolkinfrastruktuur te bestuur, maar ek was nog altyd geïnteresseerd in hoe om die ontwikkelingsketting te optimaliseer en die kultuur onder ontwikkelaars te verbeter. Greg Lavender, ons CTO vir wolkargitektuur en -infrastruktuur, het hierdie boek vir my aanbeveel. . Dit verduidelik DevOps-beginsels pragtig en lees soos 'n roman.
Die tabel op die agterkant wys hoe gereeld maatskappye nuwe weergawes bekendstel:
Hoe kry Amazon, Google en Netflix dit reg om soveel uit te rol? En dit is eenvoudig: hulle het uitgevind hoe om 'n byna perfekte DevOps-ketting te skep.
Dinge was baie anders vir ons by Citi totdat ons na DevOps oorgeskakel het. Toe het my span verskillende omgewings gehad, maar ons het die aflewering aan die ontwikkelingsbediener met die hand gedoen. Alle ontwikkelaars het toegang gehad tot slegs een ontwikkelingsbediener gebaseer op IBM WebSphere Application Server Community Edition. Met 'n gelyktydige poging om af te lewer, het die bediener "geval", en elke keer moes ons "pynlik" onder mekaar onderhandel. Ons het ook onvoldoende kodedekking met toetse gehad, 'n tydrowende handmatige afleweringsproses, en geen manier om die aflewering van kode met behulp van een of ander taak of kliëntvereiste op te spoor nie.
Dit was duidelik dat iets dringend gedoen moes word, en ek het 'n eendersdenkende kollega gekry. Ons het besluit om die eerste DevOps-ketting saam te skep - hy het 'n virtuele masjien en 'n Tomcat-toepassingsbediener opgestel, en ek het gesorg vir Jenkins, integrasie met Atlassian Jira en BitBucket, sowel as kodedekking met toetse. Die projek was suksesvol: ons het die ontwikkelingsketting ten volle geoutomatiseer, byna 100% uptyd op die ontwikkelingsbediener behaal, kon kodedekking met toetse monitor en verbeter, en 'n Git-tak kon aan 'n Jira-aflewering en -uitreiking gekoppel word. En byna al die gereedskap wat ons gebruik het om die DevOps-ketting te bou, was oopbron.
Trouens, die ketting is vereenvoudig, want ons het nie eens gevorderde konfigurasies met Jenkins of Ansible toegepas nie. Maar ons het daarin geslaag. Miskien is dit 'n gevolg van die beginsel (ook bekend as die 80/20-reël).
'n Kort beskrywing van die DevOps- en CI/CD-ketting
DevOps het verskillende definisies. DevOps, soos Agile, sluit verskillende dissiplines in. Maar die meeste sal saamstem met die volgende definisie: DevOps is 'n metode, of lewensiklus, van sagteware-ontwikkeling, waarvan die hoofbeginsel is om 'n kultuur te skep waar ontwikkelaars en ander werknemers "op dieselfde golflengte" is, handearbeid word geoutomatiseer, almal doen waarin hulle die beste is, die frekwensie van aflewerings neem toe, die produktiwiteit van werk verhoog, buigsaamheid neem toe.
Alhoewel gereedskap alleen nie genoeg is om 'n DevOps-omgewing te skep nie, is dit onontbeerlik. Die belangrikste hiervan is deurlopende integrasie en deurlopende aflewering (CI/CD). Daar is verskillende stadiums in die ketting vir elke omgewing (bv. DEV (ontwikkeling), INT (integrasie), TST (toetsing), QA (gehalteversekering), UAT (gebruikersaanvaardingstoetsing), STG (voorbereiding), PROD (gebruik)) , handtake word geoutomatiseer, ontwikkelaars kan kwaliteitkode produseer, dit lewer en kan maklik herbou.
Hierdie nota beskryf hoe om 'n DevOps-ketting in vyf stappe te skep, soos in die prentjie hieronder getoon, met behulp van oopbronnutsgoed.
Kom ons begin sake doen.
Stap 1: CI/CD-platform
Eerstens het jy 'n CI/CD-instrument nodig. Jenkins is 'n MIT-gelisensieerde, oopbron CI/CD-instrument wat in Java geskryf is wat die DevOps-beweging gewild gemaak het en die de facto-standaard vir CICD geword het.
Wat is Jenkins? Stel jou voor dat jy 'n magiese beheerpaneel het vir 'n verskeidenheid dienste en gereedskap. Op sy eie is 'n CI/CD-instrument soos Jenkins nutteloos, maar met verskillende gereedskap en dienste word dit almagtig.
Benewens Jenkins, is daar baie ander oopbronhulpmiddels, kies enige.
Hier is hoe 'n DevOps-proses lyk met 'n CI/CD-instrument
Jy het 'n CI/CD-instrument in localhost, maar daar is nog nie veel om te doen nie. Kom ons gaan aan na die volgende stap.
Stap 2: Weergawebeheer
Die beste (en waarskynlik maklikste) manier om die towerkrag van 'n CI/CD-instrument te toets, is om dit te integreer met 'n bronbeheerbestuur-instrument (SCM). Hoekom het jy weergawebeheer nodig? Kom ons sê jy doen 'n aansoek. Jy skryf dit in Java, Python, C++, Go, Ruby, JavaScript, of enige ander taal wat 'n wa en 'n klein karretjie is. Wat jy skryf word bronkode genoem. Aanvanklik, veral as jy alleen werk, kan jy alles in 'n plaaslike gids stoor. Maar soos die projek groei en meer mense aansluit, het jy 'n manier nodig om kodeveranderinge te deel, maar konflikte te vermy wanneer veranderinge saamgevoeg word. En jy moet ook op een of ander manier vorige weergawes herstel sonder om rugsteun te gebruik en die kopieer-plak-metode vir kodelêers te gebruik.
En hier sonder SCM iewers. Die SCM stoor kode in bewaarplekke, bestuur weergawes daarvan en koördineer dit onder ontwikkelaars.
Daar is baie SCM-instrumente, maar Git het welverdiend die de facto-standaard geword. Ek raai jou aan om dit te gebruik, maar daar is ander opsies.
Hier is hoe die DevOps-pyplyn lyk nadat die SCM bygevoeg is.
Die CI/CD-instrument kan bronkode-oplaai en -aflaai en spansamewerking outomatiseer. Nie sleg nie? Maar nou hoe om 'n werkende toepassing hiervan te maak, geliefd deur miljarde gebruikers?
Stap 3: Bou outomatiseringsinstrument
Alles verloop soos dit moet. Jy kan kode oplaai en veranderinge aan bronbeheer aanbring, en vriende nooi om saam met jou te werk. Maar jy het nog nie 'n toepassing nie. Vir hierdie om 'n webtoepassing te wees, moet dit saamgestel en verpak word vir verspreiding of as 'n uitvoerbare lêer uitgevoer word. ('n Geïnterpreteerde programmeertaal soos JavaScript of PHP hoef nie saamgestel te word nie.)
Gebruik 'n bou-outomatiseringsinstrument. Watter instrument jy ook al kies, dit sal die kode in die regte formaat saamstel en opruiming, samestelling, toetsing en aflewering outomatiseer. Bounutsgoed verskil volgens taal, maar die volgende oopbronopsies word algemeen gebruik.
Perfek! Laat ons nou die bou-outomatiseringsinstrument-konfigurasielêers in bronbeheer invoeg sodat die CI/CD-instrument hulle bou.
Dit voel goed. Maar waar moet dit alles nou uitgerol word?
Stap 4: Webtoepassingsbediener
So, jy het 'n verpakte lêer wat uitgevoer of uitgerol kan word. Vir 'n toepassing om regtig bruikbaar te wees, moet dit 'n soort diens of koppelvlak hê, maar jy moet dit alles iewers plaas.
'n Webtoepassing kan op 'n webtoepassingsbediener gehuisves word. Die toepassingsbediener bied 'n omgewing waar u verpakte logika kan uitvoer, koppelvlakke kan lewer en webdienste oor 'n sok kan blootstel. Jy benodig 'n HTTP-bediener en 'n paar ander omgewings (byvoorbeeld 'n virtuele masjien) om die toepassingbediener te installeer. Kom ons maak vir eers asof jy met al hierdie dinge te doen het soos jy gaan (hoewel ek hieronder oor houers sal praat).
Daar is verskeie oop webtoepassingsbedieners.
Ons het reeds 'n amper werkende DevOps-ketting. Goeie werk!
In beginsel kan jy hier stop, dan kan jy dit self hanteer, maar dit is die moeite werd om oor die kwaliteit van die kode te praat.
Stap 5: Toetsdekking
Toets verg baie tyd en moeite, maar dit is beter om foute dadelik te vind en die kode te verbeter om eindgebruikers tevrede te stel. Vir hierdie doel is daar baie oop gereedskap wat nie net die kode sal toets nie, maar ook raad gee oor hoe om dit te verbeter. Die meeste CI/CD-instrumente kan by hierdie gereedskap inprop en die proses outomatiseer.
Toetsing word in twee dele verdeel: toetsraamwerke vir die skryf en uitvoer van toetse, en gereedskap met wenke om kodekwaliteit te verbeter.
Toetsraamwerke
Gereedskap met kwaliteit wenke
Die meeste van hierdie gereedskap en raamwerke is vir Java, Python en JavaScript geskryf omdat C++ en C# eie is (alhoewel GCC oopbron is).
Ons het die toetsdekkingsinstrumente toegepas, en nou moet die DevOps-pyplyn soos die prentjie aan die begin van die tutoriaal lyk.
Bykomende stappe
Houers
Soos ek voorheen gesê het, kan 'n toepassingsbediener in 'n virtuele masjien of 'n bediener gehuisves word, maar houers is meer gewild.
? Kortom, in 'n virtuele masjien neem die bedryfstelsel dikwels meer spasie op as die toepassing, en 'n houer volstaan gewoonlik met 'n paar biblioteke en konfigurasie. In sommige gevalle is virtuele masjiene onontbeerlik, maar die houer kan die toepassing saam met die bediener teen geen ekstra koste akkommodeer nie.
Vir houers word Docker en Kubernetes gewoonlik geneem, hoewel daar ander opsies is.
Lees artikels oor Docker en Kubernetes by :
Middelware outomatisering gereedskap
Ons DevOps-ketting is gefokus op samewerkende bou en aflewering van 'n toepassing, maar daar is ander interessante dinge wat jy met DevOps-nutsgoed kan doen. Gebruik byvoorbeeld Infrastruktuur as Kode (IaC) gereedskap, ook bekend as middelware outomatisering gereedskap. Hierdie instrumente help om installasie, bestuur en ander take vir middelware te outomatiseer. Byvoorbeeld, 'n outomatiseringsinstrument kan toepassings (webtoepassingsbediener, databasis, moniteringsinstrumente) met die korrekte konfigurasies neem en dit na die toepassingsbediener stoot.
Hier is 'n paar opsies vir oop middelware-outomatiseringsinstrumente:
Besonderhede in die artikels :
Nou wat?
Dit is net die punt van die ysberg. Die DevOps-ketting kan baie meer doen. Begin met 'n CI/CD-instrument en kyk wat jy nog kan outomatiseer om jou werk makliker te maak. Moenie vergeet van vir effektiewe samewerking.
Hier is nog 'n paar goeie DevOps-artikels vir beginners:
U kan ook DevOps integreer met oop ratse nutsgoed:
Bron: will.com