🥇Udhëzues për fillestarët: krijimi i konvejerit DevOps

Nëse jeni një fillestar në DevOps, shikoni këtë udhëzues për krijimin e tubacionit tuaj të parë në pesë hapa.

DevOps është bërë zgjidhja standarde për të rregulluar proceset e ngadalta, të ndara ose të papërshtatshme të zhvillimit të softuerit. Problemi është se, nëse jeni një fillestar në DevOps dhe nuk dini nga të filloni, mund t'ju mungojë kuptimi i këtyre metodave. Në këtë artikull do të flasim për përcaktimin e tubacionit DevOps dhe do të ofrojmë një udhëzim për krijimin e tij në pesë hapa. Edhe pse ky udhëzues nuk është përmbledhës, duhet të ju japë një bazë për të filluar rrugëtimin tuaj dhe për të zgjeruar njohuritë tuaja në të ardhmen. Por le të fillojmë me historinë.

Udhëtimi im në DevOps

Në të kaluarën punoja në ekipin e cloud-it të Citi Group, duke zhvilluar një aplikacion web Infrastructure-as-a-Service (IaaS) për menaxhimin e infrastrukturës cloud të Citi, por gjithmonë kam qenë i interesuar se si ta bëja procesin e zhvillimit më efikas dhe të sjell ndryshime kulturore pozitive në ekipin e zhvilluesve. Përgjigjen e gjeta në një libër të rekomanduar nga Greg Lavender, CTO i Citi për arkitekturën dhe infrastrukturën në cloud. Libri quhej "Projekti Feniks"Projekti Feniks", dhe aty shpjegohen parimet e DevOps-it, duke u lexuar si një roman.

Në tabelën në anën e pasme të librit tregohet se sa shpesh kompanitë e ndryshme dislokojnë sistemet e tyre në një mjedis për lëshimin e versioneve:

Amazon: 23,000 në ditë
Google: 5,500 në ditë
Netflix: 500 në ditë
Facebook: Një herë në ditë
Twitter: 3 herë në javë
Kompanitë tipike: Një herë në 9 muaj

Si është e mundur që Amazon, Google dhe Netflix të kenë këto frekuenca? E gjitha sepse këto kompani kanë menduar se si të krijojnë një pipeline pothuajse të përsosur DevOps.

Ishimim çfarë ka ndodhur me ne derisa nuk bëmë implementimin e DevOps në Citi. Atëherë, ekipi im kishte mjedise të ndryshme, por vendosja në serverin e zhvillimit ishte plotësisht manuale. Të gjithë zhvilluesit kishin akses vetëm në një server zhvillimi që bazohej në IBM WebSphere Application Server Community Edition. Problemi ishte se serveri fikej çdo herë që disa përdorues përpiqeshin të bënin vendosje në të njëjtën kohë, prandaj zhvilluesit duhet të shpallin njëri-tjetrit qëllimet e tyre, gjë që ishte mjaft e dhimbshme. Për më tepër, kishte probleme me mbulimin e ulët të testeve të kodit, procese të ngarkuara manuale dhe mungesën e mundësisë për të ndjekur vendosjen e kodit të lidhur me një detyrë ose histori përdoruesi të caktuar.

E kuptova që duhej të bëja diçka dhe gjeta një koleg me të njëjtin mendim. Ne vendosëm të bashkëpunojmë për të krijuar një konvjerë DevOps fillestar - ai vendosi një makinë virtuale dhe një server aplikacionesh Tomcat, ndërsa unë punoja mbi Jenkins, integrova Atlassian Jira dhe BitBucket, si dhe punova mbi mbulimin e testeve të kodit. Ky projekt anësor ishte shumë i suksesshëm: ne automatizuam pothuajse plotësisht shumë procese, arritëm praktikisht 100% funksionalitet të serverit tanë të zhvillimit, siguruam monitorimin dhe përmirësuam mbulimin e testeve të kodit, si dhe shtuam mundësinë për të lidhur degët në Git me detyrat në Jira ose me shpërndarjen. Shumica e mjeteve që përdorëm për të ndërtuar konvjerin tonë DevOps ishin me burim të hapur.

Tani kuptoj sa i thjeshtë ishte konvjeri ynë DevOps: ne nuk përdorëm zgjerime si Jenkins files ose Ansible. Megjithatë, ky konvjer i thjeshtë funksionoi mirë, ndoshta falë parimit të Pareto (i njohur gjithashtu si rregulli 80/20).

Një hyrje e shkurtër në DevOps dhe konvjerin CI/CD

Nëse pyesni disa njerëz: "Çfarë është DevOps?", ka shumë mundësi që të merrni disa përgjigje të ndryshme. DevOps, ashtu si Agile, ka evoluar për të përfshirë shumë disiplina të ndryshme, por shumica e njerëzve do të bien dakord për disa gjëra: DevOps është një praktikë e zhvillimit të softuerit ose një cikël jetësor i zhvillimit të softuerit (SDLC), me parimin qendror të ndryshimit të kulturës, në të cilën zhvilluesit dhe ata që nuk janë zhvillues ekzistojnë në një mjedis ku:

Operacionet që më parë bëheshin manualisht janë automatizuar;
Çdo kush bën atë që di më mirë;
Numri i implementimeve në një periudhë të caktuar kohore rritet; Rritet kapaciteti;
Rritet fleksibiliteti i zhvillimit.

Megjithëse disponimi i mjeteve të duhura softuerike nuk është e vetmja gjë e nevojshme për të krijuar një ambient DevOps, disa mjete janë thelbësore. Mjeti kyç është integrimi dhe shpërndarja e vazhdueshme (CI/CD). Në këtë konvej, ambientet kanë faza të ndryshme (p.sh. DEV, INT, TST, QA, UAT, STG, PROD), shumë operacione janë të automatizuara, dhe zhvilluesit mund të shkruajnë kod të lartë cilësie, të arrijnë fleksibilitet në zhvillim dhe një frekuencë të lartë shpërndarjesh.

Ky artikull përshkruan një qasje me pesë hapa për të ndërtuar një konvej DevOps, si ai i ilustruar në diagramin e mëposhtëm, duke përdorur mjete me kod të hapur.

Hapi 1: Metodat CI/CD

Gjëja e parë që ju nevojitet është një mjet për CI/CD. Jenkins, një mjet me kod të hapur, i ndërtuar në Java dhe i shpërndarë nën licencën MIT, është mjeti që ka popullarizuar drejtimin DevOps dhe është bërë standardi de facto.

Pra ndaj, çfarë është Jenkins? Mendoni për të si një pult magjik universali që mund të flasë me shërbime dhe mjete të ndryshme dhe t'i organizojë ato. Një mjet CI/CD si Jenkins është i padobishëm vetë, por bëhet më i fuqishëm ndërsa lidhet me mjete dhe shërbime të ndryshme.

Jenkins është vetëm një nga shumë mjetet me kod të hapur për CI/CD që mund të përdorni për të ndërtuar një pipeline DevOps.

Jenkins: Creative Commons dhe MIT
Travis CI: MIT
CruiseControl: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Ja se si duken proceset DevOps me një mjet CI/CD:

Keni një mjet CI/CD që punon në localhost tuaj, por për momentin nuk mund të bëni shumë. Le të kalojmë në fazën tjetër të udhëtimit në botën DevOps.

Hapi 2: Menaxhimi i sistemeve të kontrollit të burimeve

Mënyra më e mirë (dhe ndoshta më e thjeshtë) për të kontrolluar nëse mjeti juaj CI/CD mund të krijojë magji – është integrimi me mjetin e kontrollit të kodit burimor (SCM). Pse keni nevojë për kontroll mbi kodin burimor? Imagjinoni se po zhvilloni një aplikacion. Sa herë që krijoni një aplikacion, ju programoni, dhe nuk ka rëndësi nëse po përdorni Java, Python, C++, Go, Ruby, JavaScript, apo ndonjë nga gjuhët e shumta të programimit. Kodi që shkruani quhet kod burimor. Në fillim, veçanërisht kur punoni vetëm, ka shumë gjasa që të gjitha t’i vendosni në një direktore lokale. Por kur projekti bëhet më i madh dhe ftoni njerëz të tjerë për të bashkëpunuar, ju nevojitet një mënyrë për të parandaluar konfliktet gjatë ndarjes efektive të modifikimeve. Ju gjithashtu keni nevojë për një mënyrë për të rikuperuar versionet e mëparshme, sepse krijimi i kopjeve rezervë dhe kopjimi/ngjitja në to tashmë është bërë i tejkaluar. Ju (dhe shokët tuaj në ekip) ju nevojitet diçka më të mirë.

Këtu, mjetet për kontrollin e kodit burimor bëhen praktikisht të domosdoshme. Ky mjet ruan kodin tuaj në depo, mbahet ecuria e versioneve dhe koordinon punën e pjesëmarrësve në projekt.

Megjithëse ekzistojnë shumë mjete për kontrollin e kodit burimor, Git është standardi, dhe kjo është e vërtetë. Unë rekomandoj me ngulm përdorimin e Git, pavarësisht se ka edhe mundësi të tjera me kod burimor të hapur.

Git: GPLv2 dhe LGPL v2.1
Subversion: Apache 2.0
Sistemi i Versioneve të Përsëritura (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Kështu duket një pipeline DevOps me përfshirjen e mjeteve për kontrollin e kodit burimor.

Një mjet CI/CD mund të automatizojë proceset e verifikimit, marrjes së kodit burimor dhe bashkëpunimit mes anëtarëve. Jo keq? Por si ta kthejmë këtë në një aplikacion funksional që miliarda njerëz mund ta përdorin dhe vlerësojnë?

Hapi 3: Krijimi i një mjeti për automatizimin e ndërtimit

Super! Ju mund të kontrolloni kodin dhe të bëni ndryshime në sistemin e kontrollit të burimeve, si dhe të ftoni miqtë tuaj të bashkëpunojnë në zhvillim. Por ende nuk keni krijuar një aplikacion. Për të bërë një aplikacion web, duhet të kompilohet dhe të paketojë në një format të shpërndarjes ose të startohet si një skedë ekzekutiv. (Kujtoni se një gjuhë programimi interpretuese si JavaScript ose PHP nuk ka nevojë për kompilim).

Përdorni një mjet për automatizimin e ndërtimit. Pavarësisht se cili mjet për automatizimin e ndërtimit vendosni të përdorni, të gjithë ndjekin një qëllim të njëjtë: të mbledhin kodin burimor në një format të dëshiruar dhe të automatizojnë detyrën e pastrimit, kompilimit, testimit dhe shpërndarjes në një mjedis të caktuar. Mjetet për ndërtim do të ndryshojnë në varësi të gjuhës suaj të programimit, por këtu janë disa mundësi të zakonshme me burim të hapur.

Emri
Licenca
Gjuha e programimit

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

Gradle
Apache 2.0
Java

Bazel
Apache 2.0
Java

Make
GNU
N/A

Grunt
MIT
JavaScript

Gulp
MIT
JavaScript

Buildr
Apache
Ruby

Rake
MIT
Ruby

A-A-P
GNU
Python

SCons
MIT
Python

BitBake
GPLv2
Python

Cake
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Shumë mirë! Ju mund të vendosni skedarët e konfigurimit të instrumentit të automatizimit të ndërtimit në sistemin e menaxhimit të burimeve dhe t'i lejoni mjetit tuaj CI/CD të bashkojë gjithçka.

Të gjithë janë mirë, apo jo? Por ku do ta vendosni aplikacionin tuaj?

Hapi 4: Serveri për aplikacione web

Për momentin, keni një skedh të paketuar, i cili mund të jetë ose ekzekutues ose instalues. Për të bërë që çdo aplikacion të jetë vërtet i dobishëm, ai duhet të ofrojë ndonjë shërbim ose ndërfaqe, por ju nevojitet një kontejner për të pritur aplikacionin tuaj.

Serveri për aplikacione web është pikërisht një kontejner i tillë. Serveri siguron një mjedis ku mund të përcaktohet logjika e paketës që po zbatohet. Gjithashtu, serveri ofron ndërfaqe dhe ofron shërbime web, duke hapur socket-e për botën e jashtme. Ju nevojitet një server HTTP, si dhe ndonjë mjedis (për shembull, një makinë virtuale) për ta instaluar atë. Ndërkohë, le të supozojmë që ju do të mësoni më shumë për këtë më vonë (pavarësisht se unë do të flas për kontejnerët më poshtë).

Ekzistojnë disa serverë për aplikacione web me kod të hapur.

Emri
Licenca
Gjuha e programimit

Tomcat
Apache 2.0
Java

Jetty
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

GlassFish
CDDL & GNU Less Public
Java

Django
Licenca BSD me 3 Klauzola
Python

Tornado
Apache 2.0
Python

Gunicorn
MIT
Python

Python
MIT
Python

Rails
MIT
Ruby

Node.js
MIT
Javascript

DevOps pipeline-i juaj pothuajse është gati për t'u përdorur. Punë e mrekullueshme!

Megjithëse mund të ndaloni këtu dhe të angazhoheni në integrim vetë, cilësia e kodit është një çështje e rëndësishme për zhvilluesit e aplikacioneve dhe duhet t’i kushtohet vëmendje.

Hapi 5: Mbulimi i testimit të kodit

Implementimi i testeve mund të jetë një kërkesë tjetër voluminoze, por zhvilluesit duhet të kapin çfarëdo gabimesh në aplikacion në një fazë të hershme dhe të përmirësojnë cilësinë e kodit për të siguruar kënaqësinë e përdoruesve përfundimtarë. Me fat, ka shumë mjete me kod të hapur për të testuar kodin tuaj dhe për të formuar rekomandime për përmirësimin e cilësisë së tij. Akoma më mirë është se shumica e mjeteve CI/CD mund të lidhen me këto mjete dhe të automatizojnë procesin.

Testimi i kodit përbëhet nga dy pjesë: kornizat për testimin e kodit, të cilat ndihmojnë në shk writing dhe ekzekutimin e testeve, si dhe mjetet për formimin e sugjerimeve, që ndihmojnë në përmirësimin e cilësisë së kodit.

Sistemet e testimit të kodit

Emri
Licenca
Gjuha e programimit

JUnit
Licenca Publike Eclipse
Java

EasyMock
Apache
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Sistemet e rekomandimeve për përmirësimin e kodit

Emri
Licenca
Gjuha e programimit

Cobertura
GNU
Java

CodeCover
Licenca Publike Eclipse (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Licenca e Përbashkët Publike
Java

JaCoCo
Licenca Publike Eclipse
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Kujdes: shumica e mjeteve dhe strukturave të përmendura më sipër janë shkruar për Java, Python dhe JavaScript, ndërsa C++ dhe C# janë gjuhë programimi të pronarit (ndërsa GCC ka kod burimor të hapur).

Tani që keni implementuar mjetet e mbulimit të kodit me teste, pipeline juaj DevOps duhet të duket si diagrami që u shfaq në fillim të këtij udhëzuesi.

Hapat shtesë

Kontejnerët

Siç e thashë më parë, mund të hostoni serverin tuaj në një makinë virtuale ose server, por kontejnerët janë një zgjidhje popullore.

Çfarë janë kontejnerët? Shpjegimi i shkurtër është se një makinë virtuale kërkon një sasi të madhe memorie të sistemit operativ, më shumë se madhësia e aplikacionit, ndërsa një kontejner ka nevojë vetëm për disa biblioteka dhe konfigurime për të ekzekutuar aplikacionin. Natyrisht, një makinë virtuale ka ende fusha të rëndësishme përdorimi, por kontejneri është një zgjidhje e lehtë për hostimin e aplikacionit, përfshirë serverin e aplikacioneve.

Megjithëse ka dhe opsione të tjera kontejnerësh, më të popullarizuarit janë Docker dhe Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Mjetet e automatizimit ndërmjetës

Pipeline ynë DevOps është kryesisht e orientuar drejt krijimit dhe shpërndarjes së aplikacioneve, por ka shumë gjëra të tjera që mund të bëhen me mjete DevOps. Njëra prej tyre është përdorimi i mjeteve Infrastructure as Code (IaC), të njohura gjithashtu si mjete ndërmjetësimi të automatizimit. Këto mjete ndihmojnë në automatizimin e instalimit, menaxhimit dhe detyrave të tjera për programin ndërmjetës. Për shembull, një mjet automatizimi mund të nxjerrë aplikacione si serverë për aplikacione web, baza të dhënash dhe mjete monitorimi, me konfigurime të sakta dhe t'i shpërndajë ato në serverin e aplikacioneve.

Ja disa mjete ndërmjetësimi të automatizimit me burim të hapur:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache ose GPL

Mësoni më shumë se si të merrni një profesion të kërkuar nga zero ose Level Up në aftësi dhe pagë, duke ndjekur kurse online me pagesë në SkillFactory: