Ndërtimi i zinxhirit tuaj të parë DevOps në pesë hapa për fillestarët.
DevOps është bërë një ilaç për proceset e zhvillimit shumë të ngadalshëm, të shkëputur dhe ndryshe problematik. Por keni nevojë për njohuri minimale në DevOps. Ai do të mbulojë koncepte të tilla si zinxhiri DevOps dhe si të krijoni një në pesë hapa. Ky nuk është një udhëzues i plotë, por vetëm një "peshk" që mund të zgjerohet. Le të fillojmë me historinë.
Prezantimi im në DevOps
Dikur punoja me cloud në Citi Group dhe zhvilloja një aplikacion ueb IaaS për të menaxhuar infrastrukturën cloud të Citi, por gjithmonë kam qenë i interesuar se si të optimizoja zinxhirin e zhvillimit dhe të përmirësoja kulturën midis zhvilluesve. Greg Lavender, CTO-ja jonë për Arkitekturën dhe Infrastrukturën e Reve, ma rekomandoi këtë libër. . Shpjegon bukur parimet e DevOps dhe lexohet si një roman.
Tabela në anën e pasme tregon se sa shpesh kompanitë nxjerrin versione të reja:
Si arrijnë të shpërndahen kaq shumë Amazon, Google dhe Netflix? Dhe është e thjeshtë: ata kuptuan se si të krijonin një zinxhir pothuajse të përsosur DevOps.
Gjërat ishin shumë të ndryshme për ne në Citi derisa kaluam në DevOps. Pastaj ekipi im kishte mjedise të ndryshme, por ne e bëmë dorëzimin në serverin e zhvillimit manualisht. Të gjithë zhvilluesit kishin akses në vetëm një server zhvillimi të bazuar në IBM WebSphere Application Server Community Edition. Me një përpjekje të njëkohshme për të ofruar, serveri "ra", dhe çdo herë ne duhej të negocionim "me dhimbje" mes vete. Ne kishim gjithashtu mbulim të pamjaftueshëm të kodit me teste, një proces dorëzimi manual që kërkon shumë kohë dhe asnjë mënyrë për të gjurmuar dërgimin e kodit me ndihmën e disa detyrave ose kërkesave të klientit.
Ishte e qartë se diçka duhej bërë urgjentisht dhe gjeta një koleg me të njëjtin mendim. Ne vendosëm të krijonim së bashku zinxhirin e parë DevOps - ai krijoi një makinë virtuale dhe një server aplikacioni Tomcat, dhe unë u kujdesa për Jenkins, integrimin me Atlassian Jira dhe BitBucket, si dhe mbulimin e kodit me teste. Projekti ishte i suksesshëm: ne automatizuam plotësisht zinxhirin e zhvillimit, arritëm pothuajse 100% kohën e funksionimit në serverin e zhvillimit, ishim në gjendje të monitoronim dhe përmirësonim mbulimin e kodit me teste dhe një degë Git mund të lidhej me një dërgim dhe problem Jira. Dhe pothuajse të gjitha mjetet që përdorëm për të ndërtuar zinxhirin DevOps ishin me burim të hapur.
Në fakt, zinxhiri u thjeshtua, sepse ne nuk aplikuam as konfigurime të avancuara duke përdorur Jenkins ose Ansible. Por ia dolëm. Ndoshta kjo është pasojë e parimit (aka rregulli 80/20).
Një përshkrim i shkurtër i zinxhirit DevOps dhe CI/CD
DevOps ka përkufizime të ndryshme. DevOps, si Agile, përfshin disiplina të ndryshme. Por shumica do të pajtohen me përkufizimin e mëposhtëm: DevOps është një metodë, ose cikël jetësor, i zhvillimit të softuerit, parimi kryesor i së cilës është krijimi i një kulture ku zhvilluesit dhe punonjësit e tjerë janë "në të njëjtën gjatësi vale", puna manuale është e automatizuar, secili bën atë që është më i miri, frekuenca e dërgesave rritet, produktiviteti i punës rritet, fleksibiliteti rritet.
Ndërsa vetëm mjetet nuk janë të mjaftueshme për të krijuar një mjedis DevOps, ato janë të domosdoshme. Më e rëndësishmja prej tyre është integrimi i vazhdueshëm dhe shpërndarja e vazhdueshme (CI/CD). Ekzistojnë faza të ndryshme në zinxhir për çdo mjedis (p.sh. DEV (zhvillimi), INT (integrimi), TST (testimi), QA (sigurimi i cilësisë), UAT (testimi i pranimit të përdoruesit), STG (përgatitja), PROD (përdorimi)) , detyrat manuale janë të automatizuara, zhvilluesit mund të prodhojnë kod cilësor, ta dorëzojnë atë dhe mund ta rindërtojnë lehtësisht.
Ky shënim përshkruan se si të krijoni një zinxhir DevOps në pesë hapa, siç tregohet në foton më poshtë, duke përdorur mjete me burim të hapur.
Le të merremi me biznesin.
Hapi 1: Platforma CI/CD
Para së gjithash, ju nevojitet një mjet CI/CD. Jenkins është një mjet CI/CD i licencuar nga MIT, me burim të hapur i shkruar në Java, i cili popullarizoi lëvizjen DevOps dhe është bërë standardi de fakto për CICD.
Çfarë është Jenkins? Imagjinoni që keni një panel kontrolli magjik për një sërë shërbimesh dhe mjetesh. Në vetvete, një mjet CI/CD si Jenkins është i padobishëm, por me mjete dhe shërbime të ndryshme, ai bëhet i plotfuqishëm.
Përveç Jenkins, ka shumë mjete të tjera me burim të hapur, zgjidhni cilindo.
Ja se si duket një proces DevOps me një mjet CI/CD
Ju keni një mjet CI / CD në localhost, por nuk ka ende shumë për të bërë. Le të kalojmë në hapin tjetër.
Hapi 2: Versionimi
Mënyra më e mirë (dhe ndoshta më e lehtë) për të testuar magjinë e një mjeti CI/CD është ta integroni atë me një mjet të menaxhimit të kontrollit të burimit (SCM). Pse keni nevojë për kontrollin e versionit? Le të themi se po bëni një aplikim. Ju e shkruani atë në Java, Python, C++, Go, Ruby, JavaScript ose ndonjë gjuhë tjetër që është një karrocë dhe një karrocë e vogël. Ajo që shkruani quhet kod burim. Në fillim, veçanërisht nëse jeni duke punuar vetëm, mund të ruani gjithçka në një drejtori lokale. Por ndërsa projekti rritet dhe më shumë njerëz bashkohen, ju duhet një mënyrë për të ndarë ndryshimet e kodit, por për të shmangur konfliktet kur bashkohen ndryshimet. Dhe gjithashtu duhet të rivendosni disi versionet e mëparshme pa përdorur kopje rezervë dhe duke përdorur metodën e kopjimit-ngjitjes për skedarët e kodit.
Dhe këtu pa SCM askund. SCM ruan kodin në depo, menaxhon versionet e tij dhe e koordinon atë midis zhvilluesve.
Ka shumë mjete SCM, por Git me meritë është bërë standardi de fakto. Unë ju këshilloj ta përdorni, por ka mundësi të tjera.
Ja se si duket tubacioni DevOps pas shtimit të SCM.
Mjeti CI/CD mund të automatizojë ngarkimin dhe shkarkimin e kodit burimor dhe bashkëpunimin në ekip. Jo keq? Por tani si të bëni një aplikacion funksional nga kjo, i dashur nga miliarda përdorues?
Hapi 3: Ndërtoni mjetin e automatizimit
Gjithçka po shkon ashtu siç duhet. Mund të ngarkoni kodin dhe të kryeni ndryshime në kontrollin e burimit dhe të ftoni miqtë të punojnë me ju. Por ju nuk keni ende një aplikacion. Që ky të jetë një aplikacion ueb, ai duhet të kompilohet dhe paketohet për shpërndarje ose të ekzekutohet si një i ekzekutueshëm. (Një gjuhë programimi e interpretuar si JavaScript ose PHP nuk ka nevojë të kompilohet.)
Përdorni një mjet automatizimi ndërtimi. Cilido mjet që zgjidhni, ai do të mbledhë kodin në formatin e duhur dhe do të automatizojë pastrimin, përpilimin, testimin dhe dorëzimin. Veglat e ndërtimit ndryshojnë sipas gjuhës, por zakonisht përdoren opsionet e mëposhtme me burim të hapur.
Perfekte! Tani le t'i fusim skedarët e konfigurimit të mjetit të automatizimit të ndërtimit në kontrollin e burimit në mënyrë që mjeti CI/CD t'i ndërtojë ato.
Ndihet mire. Por ku është e gjithë kjo për të dalë tani?
Hapi 4: Serveri i aplikacionit në ueb
Pra, ju keni një skedar të paketuar që mund të ekzekutohet ose hapet. Që një aplikacion të jetë vërtet i dobishëm, duhet të ketë një lloj shërbimi ose ndërfaqe, por duhet t'i vendosni të gjitha diku.
Një aplikacion ueb mund të strehohet në një server aplikacioni ueb. Serveri i aplikacionit ofron një mjedis ku mund të ekzekutoni logjikën e paketuar, të jepni ndërfaqe dhe të ekspozoni shërbimet e uebit mbi një prizë. Ju duhet një server HTTP dhe disa mjedise të tjera (për shembull, një makinë virtuale) për të instaluar serverin e aplikacionit. Tani për tani, le të pretendojmë se po merreni me të gjitha këto ndërsa shkoni (edhe pse unë do të flas për kontejnerët më poshtë).
Ka disa serverë të hapur të aplikacioneve në ueb.
Ne tashmë kemi një zinxhir pothuajse funksional DevOps. Punë e mrekullueshme!
Në parim, mund të ndaleni këtu, atëherë mund ta trajtoni vetë, por ia vlen të flasim për cilësinë e kodit.
Hapi 5: Mbulimi i testit
Testimi kërkon shumë kohë dhe përpjekje, por është më mirë të gjesh menjëherë gabimet dhe të përmirësosh kodin për të kënaqur përdoruesit përfundimtarë. Për këtë qëllim, ka shumë mjete të hapura që jo vetëm do të testojnë kodin, por edhe do të këshillojnë se si ta përmirësoni atë. Shumica e mjeteve CI/CD mund të futen në këto mjete dhe të automatizojnë procesin.
Testimi është i ndarë në dy pjesë: kornizat e testimit për shkrimin dhe ekzekutimin e testeve, dhe mjetet me sugjerime për të përmirësuar cilësinë e kodit.
Kornizat e Testimit
Mjete me këshilla cilësore
Shumica e këtyre mjeteve dhe kornizave janë shkruar për Java, Python dhe JavaScript sepse C++ dhe C# janë të pronarit (megjithëse GCC është me burim të hapur).
Ne kemi aplikuar mjetet e mbulimit të testimit dhe tani tubacioni DevOps duhet të duket si fotografia në fillim të tutorialit.
Hapat shtesë
Konteйnerы
Siç thashë më parë, një server aplikacioni mund të mbahet në një makinë virtuale ose një server, por kontejnerët janë më të njohur.
? Shkurtimisht, në një makinë virtuale, sistemi operativ shpesh merr më shumë hapësirë sesa aplikacioni dhe një kontejner zakonisht mjafton me disa biblioteka dhe konfigurim. Në disa raste, makinat virtuale janë të domosdoshme, por kontejneri mund të akomodojë aplikacionin së bashku me serverin pa kosto shtesë.
Për kontejnerët, zakonisht merren Docker dhe Kubernetes, megjithëse ka mundësi të tjera.
Lexoni artikuj rreth Docker dhe Kubernetes në :
Mjetet e automatizimit të programeve të mesme
Zinxhiri ynë DevOps është i fokusuar në ndërtimin e bashkëpunimit dhe shpërndarjen e një aplikacioni, por ka gjëra të tjera interesante që mund të bëni me mjetet DevOps. Për shembull, përdorni mjetet Infrastructure as Code (IaC), të njohura gjithashtu 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. Për shembull, një mjet automatizimi mund të marrë aplikacione (server aplikacioni në internet, bazë të dhënash, mjete monitorimi) me konfigurimet e duhura dhe t'i shtyjë ato në serverin e aplikacionit.
Këtu janë disa opsione për mjetet e hapura të automatizimit të programeve të mesme:
Detajet në artikuj :
Tani Cfare?
Kjo është vetëm maja e ajsbergut. Zinxhiri DevOps mund të bëjë shumë më tepër. Filloni me një mjet CI/CD dhe shikoni se çfarë tjetër mund të automatizoni për ta bërë punën tuaj më të lehtë. Mos harroni për për një bashkëpunim efektiv.
Këtu janë disa artikuj më të mirë DevOps për fillestarët:
Ju gjithashtu mund të integroni DevOps me mjete të hapura të shkathët:
Burimi: www.habr.com