Nëse jeni i ri në DevOps, hidhini një sy këtij udhëzuesi me pesë hapa për të krijuar tubacionin tuaj të parë.
DevOps është bërë zgjidhja standarde për rregullimin e proceseve të zhvillimit të softuerit të ngadaltë, të shkëputur ose të prishur. Problemi është se nëse jeni i ri në DevOps dhe nuk dini nga të filloni, mund t'ju mungojë të kuptoni këto teknika. Ky artikull do të diskutojë përkufizimin e një tubacioni DevOps dhe gjithashtu do të ofrojë udhëzime me pesë hapa për krijimin e një të tillë. Ndërsa ky tutorial nuk është shterues, ai duhet t'ju japë një bazë për të filluar udhëtimin tuaj dhe për të zgjeruar njohuritë tuaja në të ardhmen. Por le të fillojmë me historinë.
Udhëtimi im DevOps
Më parë kam punuar në ekipin cloud të Citi Group duke zhvilluar një aplikacion ueb Infrastructure-as-a-Service (IaaS) për të menaxhuar infrastrukturën cloud të Citi, por gjithmonë kam qenë i interesuar se si ta bëj procesin e zhvillimit më efikas dhe të sjellë ndryshime pozitive kulturore në ekipi i zhvillimit. Përgjigjen e gjeta në një libër të rekomanduar nga Greg Lavender, CTO i Arkitekturës dhe Infrastrukturës së Reve në Citi. Libri u quajt Projekti Phoenix (), dhe shpjegon parimet e DevOps, por lexohet si një roman.
Tabela në fund të librit tregon se sa shpesh kompani të ndryshme vendosin sistemet e tyre në një mjedis lëshimi:
Amazon: 23 në ditë
Google: 5 në ditë
Netflix: 500 në ditë
Facebook: Një herë në ditë
Twitter: 3 herë në javë
Kompania tipike: Një herë në 9 muaj
Si janë madje të mundshme frekuencat e Amazon, Google dhe Netflix? Kjo për shkak se këto kompani kanë kuptuar se si të krijojnë një tubacion pothuajse të përsosur DevOps.
Ne ishim larg kësaj derisa implementuam DevOps në Citi. Në atë kohë, ekipi im kishte mjedise të ndryshme, por vendosja në serverin e zhvillimit ishte plotësisht manuale. Të gjithë zhvilluesit kishin akses në vetëm një server zhvillimi të bazuar në IBM WebSphere Application Server Community Edition. Problemi ishte se serveri do të mbyllej sa herë që shumë përdorues përpiqeshin të vendoseshin në të njëjtën kohë, kështu që zhvilluesit duhej t'i komunikonin qëllimet e tyre njëri-tjetrit, gjë që ishte shumë e dhimbshme. Për më tepër, kishte probleme me mbulimin e kodit të testimit të nivelit të ulët, proceset e vështira të vendosjes manuale dhe pamundësinë për të gjurmuar vendosjen e kodit të lidhur me një detyrë specifike ose histori të përdoruesit.
Kuptova se diçka duhej bërë dhe gjeta një koleg me të njëjtin mendim. Ne vendosëm të bashkëpunonim për ndërtimin e tubacionit fillestar të DevOps - ai krijoi një makinë virtuale Tomcat dhe server aplikacioni ndërsa unë punoja në Jenkins, integrova Atlassian Jira dhe BitBucket dhe punoja në mbulimin e kodit të testimit. Ky projekt anësor ishte shumë i suksesshëm: ne automatizuam pothuajse plotësisht shumë procese, arritëm pothuajse 100% kohë në punë në serverin tonë të zhvillimit, siguruam gjurmim dhe mbulim të përmirësuar të testit të kodit dhe shtuam aftësinë për të lidhur degët e Git me çështjet ose vendosjet e Jira. Shumica e mjeteve që përdorëm për të ndërtuar tubacionin tonë DevOps ishin me burim të hapur.
Tani e kuptoj se sa i thjeshtë ishte tubacioni ynë DevOps: ne nuk përdorëm shtesa si skedarët Jenkins ose Ansible. Megjithatë, ky tubacion i thjeshtë funksionoi mirë, ndoshta për shkak të parimit Pareto (i njohur gjithashtu si rregulli 80/20).
Një hyrje e shkurtër në DevOps dhe tubacioni CI/CD
Nëse pyet disa njerëz, "Çfarë është DevOps?", me siguri do të merrni disa përgjigje të ndryshme. DevOps, si Agile, ka evoluar për të shtrirë 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 cikli jetësor i zhvillimit të softuerit (SDLC), parimi qendror i të cilit është ndryshimi i kulturës në të cilën zhvilluesit dhe jo- zhvilluesit ekzistojnë në një mjedis në të cilin:
Operacionet që janë kryer më parë me dorë janë automatizuar;
Të gjithë bëjnë atë që bëjnë më mirë;
Numri i zbatimeve për një periudhë të caktuar kohore rritet; Rritja e xhiros;
Fleksibiliteti i rritur i zhvillimit.
Ndërsa të kesh mjetet e duhura softuerike nuk është e vetmja gjë që të nevojitet për të krijuar një mjedis DevOps, disa mjete janë thelbësore. Një mjet kyç është integrimi i vazhdueshëm dhe vendosja e vazhdueshme (CI/CD). Në këtë tubacion, mjediset kanë faza të ndryshme (p.sh. DEV, INT, TST, QA, UAT, STG, PROD), shumë operacione janë të automatizuara dhe zhvilluesit mund të shkruajnë kod me cilësi të lartë, të arrijnë gatishmërinë e zhvillimit dhe ritme të larta vendosjeje.
Ky artikull përshkruan një qasje me pesë hapa për të krijuar një tubacion DevOps si ai i paraqitur në diagramin e mëposhtëm duke përdorur mjete me burim të hapur.
Hapi 1: Metodat CI/CD
Gjëja e parë që ju nevojitet është një mjet CI/CD. Jenkins, një mjet me burim të hapur i bazuar në Java dhe i licencuar nën licencën MIT, është mjeti që popullarizoi DevOps dhe është bërë standardi de facto.
Pra, çfarë është Jenkins? Mendoni për atë si një lloj telekomandë magjike universale që mund të bisedojë dhe të organizojë shërbime dhe mjete të ndryshme. Më vete, një mjet CI/CD si Jenkins është i padobishëm, por bëhet më i fuqishëm pasi lidhet me mjete dhe shërbime të ndryshme.
Jenkins është vetëm një nga shumë mjete CI/CD me burim të hapur që mund të përdorni për të ndërtuar tubacionin tuaj 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:
Ju keni një mjet CI/CD që funksionon në hostin tuaj lokal, por nuk mund të bëni shumë për momentin. Le të kalojmë në fazën tjetër të udhëtimit DevOps.
Hapi 2: Menaxhoni sistemet e kontrollit të burimit
Mënyra më e mirë (dhe ndoshta më e lehtë) për të verifikuar që mjeti juaj CI/CD mund të bëjë magjinë e tij është të integrohet me një mjet kontrolli të kodit burimor (SCM). Pse keni nevojë për kontrollin e burimit? Le të themi se po zhvillon një aplikacion. Sa herë që krijoni një aplikacion, ju jeni duke programuar dhe nuk ka rëndësi nëse përdorni Java, Python, C++, Go, Ruby, JavaScript ose ndonjë nga mijëra gjuhë programimi. Kodi që shkruani quhet kod burim. Në fillim, veçanërisht kur jeni duke punuar vetëm, ndoshta është mirë të vendosni gjithçka në një drejtori lokale. Por ndërsa projekti bëhet më i madh dhe ju ftoni njerëz të tjerë të bashkëpunojnë, ju duhet një mënyrë për të parandaluar konfliktet duke ndarë në mënyrë efektive modifikimet. Ju gjithashtu duhet një mënyrë për të rivendosur versionet e mëparshme, sepse krijimi i kopjeve rezervë dhe kopjimi/ngjitja në to po bëhet i vjetëruar. Ju (dhe shokët tuaj të skuadrës) keni nevojë për diçka më të mirë.
Këtu kontrolli i kodit burimor bëhet pothuajse një domosdoshmëri. Ky mjet ruan kodin tuaj në depo, mban gjurmët e versioneve dhe koordinon punën e pjesëmarrësve të projektit.
Ndërsa ka shumë mjete të kontrollit të burimit atje, Git është standardi, dhe me të drejtë. Unë rekomandoj shumë përdorimin e Git, megjithëse ka opsione të tjera me burim të hapur nëse preferoni.
Git: GPLv2 dhe LGPL v2.1
Subversion: Apache 2.0
Sistemi i versioneve të njëkohshme (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Kështu duket një tubacion DevOps me shtimin e kontrolleve të kodit burimor.
Një mjet CI/CD mund të automatizojë proceset e rishikimit, marrjes së kodit burimor dhe bashkëpunimit ndërmjet anëtarëve. Jo keq? Por si ta ktheni atë në një aplikacion funksional në mënyrë që miliarda njerëz ta përdorin dhe ta vlerësojnë atë?
Hapi 3: Krijoni një Vegël Automatizimi Ndërtimi
E shkëlqyeshme! Mund të rishikoni kodin dhe të bëni ndryshime në kontrollin e burimit dhe të ftoni miqtë tuaj të bashkëpunojnë në zhvillimin. Por ju nuk keni krijuar ende një aplikacion. Për të krijuar një aplikacion në ueb, ai duhet të kompilohet dhe paketohet në një format grupi të dislokueshëm ose të ekzekutohet si një skedar i ekzekutueshëm. (Vini re se një gjuhë programimi e interpretuar si JavaScript ose PHP nuk ka nevojë të kompilohet).
Përdorni një mjet automatizimi ndërtimi. Pavarësisht se cilin mjet automatizimi ndërtimi vendosni të përdorni, ata të gjithë kanë të njëjtin qëllim: të ndërtojnë kodin burimor në një format të dëshiruar dhe të automatizojnë detyrën e pastrimit, përpilimit, testimit dhe vendosjes në një mjedis specifik. Veglat e ndërtimit do të ndryshojnë në varësi të gjuhës tuaj të programimit, por këtu janë disa opsione të zakonshme me burim të hapur.
Emër
leje
Gjuhë programimi
Maven
Apache 2.0
Java
Milingonë
Apache 2.0
Java
Gradle
Apache 2.0
Java
bazel
Apache 2.0
Java
Vendosini mbështetësit tuaj në qendër të vëmendjes, përmendni kontributin e të sapoardhurve dhe bëjeni të duket bukur! Mos u frikësoni nga bashkëpunimi dhe jepuni meritat grupeve të tjera që punojnë me tema të ngjashme. Merrni pjesë në kauzat e tyre, karma njëmend funksionon!
GNU
N / A
hungërimë
ME
JavaScript
gllënjkë
ME
JavaScript
Ndërtues
Apache
rubin
grabujë
ME
rubin
AAP
GNU
Piton
Scons
ME
Piton
BitBake
GPLv2
Piton
Tortë
ME
C#
asdf
Emigranti (MIT)
LISP
Saktë
BSD
Haskell
E shkëlqyeshme! Mund t'i vendosni skedarët e konfigurimit të veglave të automatizimit të ndërtimit në sistemin tuaj të kontrollit të burimit dhe të lini mjetin tuaj CI/CD të bashkojë gjithçka.
Gjithçka është në rregull, apo jo? Por ku ta vendosni aplikacionin tuaj?
Hapi 4: Serveri i aplikacionit në ueb
Tani për tani, ju keni një skedar të paketuar që mund të jetë ose i ekzekutueshëm ose i instalueshëm. Që çdo aplikacion të jetë vërtet i dobishëm, duhet të ofrojë një lloj shërbimi ose ndërfaqeje, por ju duhet një kontejner për të pritur aplikacionin tuaj.
Një server aplikacioni në internet është vetëm një kontejner i tillë. Serveri ofron një mjedis në të cilin mund të përcaktohet logjika e paketës që do të vendoset. Serveri gjithashtu ofron një ndërfaqe dhe ofron shërbime në internet duke ekspozuar bazat në botën e jashtme. Ju duhet një server HTTP, si dhe një mjedis (si një makinë virtuale) për ta instaluar atë. Tani për tani, le të supozojmë se do të mësoni më shumë për këtë (megjithëse unë do të mbuloj kontejnerët më poshtë).
Ka disa serverë të aplikacioneve në ueb me burim të hapur.
Emër
leje
Gjuhë programimi
Maçok
Apache 2.0
Java
bankinë
Apache 2.0
Java
Fushë e egër
GNU më e vogël publike
Java
Peshk qelqi
CDDL & GNU Më pak Publike
Java
Django
3-Klauzola BSD
Piton
Uragan
Apache 2.0
Piton
Bricjapi
ME
Piton
Piton
ME
Piton
Gardh
ME
rubin
Node.js
ME
Javascript
Tubacioni juaj DevOps është pothuajse gati për t'u përdorur. Punë e mirë!
Ndërsa mund të ndaleni këtu dhe ta trajtoni vetë integrimin, cilësia e kodit është një gjë e rëndësishme për një zhvillues aplikacioni për t'u shqetësuar.
Hapi 5: Mbulimi i testimit të kodit
Zbatimi i testeve mund të jetë një kërkesë tjetër e rëndë, por zhvilluesit duhet të kapin çdo gabim në aplikacion herët dhe të përmirësojnë cilësinë e kodit për të siguruar që përdoruesit përfundimtarë të jenë të kënaqur. Për fat të mirë, ka shumë mjete me burim të hapur për të testuar kodin tuaj dhe për të bërë rekomandime për përmirësimin e cilësisë së tij. Ajo që është edhe më e 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 e testimit të kodit që ju ndihmojnë të shkruani dhe ekzekutoni teste, dhe mjete sugjerimi që ju ndihmojnë të përmirësoni cilësinë e kodit tuaj.
Sistemet e testimit të kodeve
Emër
leje
Gjuhë programimi
JUnit
Licenca Publike Eclipse
Java
EasyMock
Apache
Java
mockito
ME
Java
PowerMock
Apache 2.0
Java
Pitest
ME
Piton
hipotezë
Mozilla
Piton
Toks
ME
Piton
Sisteme rekomandimi për përmirësimin e kodit
Emër
leje
Gjuhë programimi
Mbulim
GNU
Java
CodeCover
Eclipse Public (EPL)
Java
Mbulimi.py
Apache 2.0
Piton
Emma
Licenca e Përbashkët Publike
Java
JaCoCo
Licenca Publike Eclipse
Java
hipotezë
Mozilla
Piton
Toks
ME
Piton
jasemi
ME
JavaScript
Karma
ME
JavaScript
kafe moka
ME
JavaScript
ka
ME
JavaScript
Vini re se shumica e mjeteve dhe kornizave të përmendura më sipër janë shkruar për Java, Python dhe JavaScript, pasi C++ dhe C# janë gjuhë programimi të pronarit (megjithëse GCC është me burim të hapur).
Tani që keni zbatuar mjetet e mbulimit të testimit, tubacioni juaj DevOps duhet të duket i ngjashëm me diagramin e treguar në fillim të këtij tutoriali.
Hapat shtesë
Konteйnerы
Siç thashë, ju mund të prisni serverin tuaj në një makinë virtuale ose një server, por kontejnerët janë një zgjidhje popullore.
Çfarë janë kontejnerët? Shpjegimi i shkurtër është se një makinë virtuale ka nevojë për një sasi të madhe memorie të sistemit operativ, që tejkalon madhësinë e aplikacionit, ndërsa një kontejner ka nevojë vetëm për disa biblioteka dhe konfigurime për të ekzekutuar aplikacionin. Natyrisht, ka ende përdorime të rëndësishme për një makinë virtuale, por një kontejner është një zgjidhje e lehtë për të pritur një aplikacion, duke përfshirë një server aplikacioni.
Ndërsa ka opsione të tjera të kontejnerëve, më të njohurit janë Docker dhe Kubernetes.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Mjete të ndërmjetme automatizimi
Tubacioni ynë DevOps është i fokusuar kryesisht në krijimin dhe vendosjen e aplikacioneve bashkëpunuese, por ka shumë gjëra të tjera që mund të bëhen me mjetet DevOps. Një prej tyre është përdorimi i mjeteve Infrastructure as Code (IaC), të cilat njihen edhe si mjetet e automatizimit të programeve të mesme. Këto mjete ndihmojnë në automatizimin e instalimit, menaxhimit dhe detyrave të tjera për programin e mesëm. Kështu, për shembull, një mjet automatizimi mund të nxjerrë aplikacione si një server aplikacioni në internet, një bazë të dhënash dhe një mjet monitorimi me konfigurimet e duhura dhe t'i vendosë ato në serverin e aplikacionit.
Këtu janë disa mjete të automatizimit të programeve të mesme me burim të hapur:
Përgjegjës: GNU Public
SaltStack: Apache 2.0
Shefi: Apache 2.0
Kukulla: Apache ose GPL
Zbuloni detaje se si të merrni një profesion të kërkuar nga e para ose Level Up për sa i përket aftësive dhe pagës duke marrë kurse online me pagesë nga SkillFactory:
- (12 muaj)
më shumë kurse
- (12 javë)
- (12 muaj)
- (9 muaj)
- (9 muaj)
i dobishëm
Burimi: www.habr.com