Izveidojiet savu pirmo DevOps ķēdi piecos soļos iesācējiem.
DevOps ir kļuvis par panaceju pārāk lēniem, atvienotiem un citādi problemātiskiem izstrādes procesiem. Bet jums ir nepieciešamas minimālas zināšanas par DevOps. Tas aptvers tādus jēdzienus kā DevOps ķēde un to, kā izveidot vienu no piecām darbībām. Šī nav pilnīga rokasgrāmata, bet tikai "zivs", kuru var paplašināt. Sāksim ar vēsturi.
Mans ievads par DevOps
Es kādreiz strādāju ar mākoņiem uzņēmumā Citi Group un izstrādāju IaaS tīmekļa lietojumprogrammu, lai pārvaldītu Citi mākoņdatošanas infrastruktūru, taču mani vienmēr ir interesējis, kā optimizēt izstrādes ķēdi un uzlabot kultūru izstrādātāju vidū. Gregs Lavenders, mūsu mākoņu arhitektūras un infrastruktūras tehnoloģiju vadītājs, man ieteica šo grāmatu. . Tas lieliski izskaidro DevOps principus un lasāms kā romāns.
Tabula aizmugurē parāda, cik bieži uzņēmumi izlaiž jaunas versijas:
Kā Amazon, Google un Netflix izdodas tik daudz izplatīties? Un tas ir vienkārši: viņi izdomāja, kā izveidot gandrīz ideālu DevOps ķēdi.
Mums Citi bija ļoti atšķirīgi, līdz mēs pārgājām uz DevOps. Tad manai komandai bija dažādas vides, bet piegādi izstrādes serverim veicām manuāli. Visiem izstrādātājiem bija piekļuve tikai vienam izstrādes serverim, kura pamatā ir IBM WebSphere Application Server Community Edition. Vienlaicīgi mēģinot piegādāt, serveris “nokrita”, un katru reizi mums nācās “sāpīgi” sarunāties savā starpā. Mums bija arī nepietiekams koda pārklājums ar testiem, laikietilpīgs manuālas piegādes process un nebija iespējas izsekot koda piegādi, izmantojot kādu uzdevumu vai klienta prasības.
Bija skaidrs, ka kaut kas steidzami jādara, un es atradu līdzīgi domājošu kolēģi. Mēs nolēmām kopā izveidot pirmo DevOps ķēdi – viņš uzstādīja virtuālo mašīnu un Tomcat lietojumprogrammu serveri, un es parūpējos par Jenkins, integrāciju ar Atlassian Jira un BitBucket, kā arī par koda pārklājumu ar testiem. Projekts bija veiksmīgs: mēs pilnībā automatizējām izstrādes ķēdi, panācām gandrīz 100% darbspējas laiku izstrādes serverī, varējām pārraudzīt un uzlabot koda pārklājumu, izmantojot testus, un Git filiāli varēja piesaistīt Jira piegādei un izsniegšanai. Un gandrīz visi rīki, ko izmantojām, lai izveidotu DevOps ķēdi, bija atvērtā pirmkoda.
Faktiski ķēde tika vienkāršota, jo mēs pat neizmantojām uzlabotas konfigurācijas, izmantojot Jenkins vai Ansible. Bet mums izdevās. Varbūt tas ir principa sekas (pazīstams arī kā 80/20 noteikums).
Īss DevOps un CI/CD ķēdes apraksts
DevOps ir dažādas definīcijas. DevOps, tāpat kā Agile, ietver dažādas disciplīnas. Taču lielākā daļa piekritīs šādai definīcijai: DevOps ir programmatūras izstrādes metode jeb dzīves cikls, kuras galvenais princips ir radīt kultūru, kurā izstrādātāji un citi darbinieki atrodas “vienā viļņa garumā”, roku darbs ir automatizēts, katrs dara to, ko prot vislabāk, palielinās piegāžu biežums, palielinās darba produktivitāte, palielinās elastība.
Lai gan ar rīkiem vien nepietiek, lai izveidotu DevOps vidi, tie ir neaizstājami. Vissvarīgākais no tiem ir nepārtraukta integrācija un nepārtraukta piegāde (CI/CD). Katrai videi ķēdē ir dažādi posmi (piemēram, DEV (izstrāde), INT (integrācija), TST (testēšana), QA (kvalitātes nodrošināšana), UAT (lietotāja pieņemšanas pārbaude), STG (sagatavošana), PROD (lietošana)) , manuālie uzdevumi ir automatizēti, izstrādātāji var izveidot kvalitatīvu kodu, piegādāt to un var viegli atjaunot.
Šajā piezīmē ir aprakstīts, kā izveidot DevOps ķēdi piecās darbībās, kā parādīts attēlā zemāk, izmantojot atvērtā pirmkoda rīkus.
Sāksim pie lietas.
1. darbība: CI/CD platforma
Pirmkārt, jums ir nepieciešams CI/CD rīks. Jenkins ir MIT licencēts atvērtā pirmkoda CI/CD rīks, kas rakstīts Java, kas popularizēja DevOps kustību un ir kļuvis par de facto CICD standartu.
Kas ir Dženkinss? Iedomājieties, ka jums ir maģisks vadības panelis dažādiem pakalpojumiem un rīkiem. CI/CD rīks, piemēram, Jenkins, pats par sevi ir bezjēdzīgs, taču ar dažādiem rīkiem un pakalpojumiem tas kļūst visvarens.
Papildus Jenkins ir arī daudzi citi atvērtā pirmkoda rīki, izvēlieties jebkuru.
Lūk, kā izskatās DevOps process ar CI/CD rīku
Vietnē localhost jums ir CI/CD rīks, taču vēl nav daudz darāmā. Pāriesim pie nākamās darbības.
2. darbība. Versijas kontrole
Labākais (un neapšaubāmi vienkāršākais) veids, kā pārbaudīt CI/CD rīka burvību, ir integrēt to ar avotu kontroles pārvaldības (SCM) rīku. Kāpēc jums ir nepieciešama versiju kontrole? Pieņemsim, ka jūs iesniedzat pieteikumu. Jūs to rakstāt Java, Python, C++, Go, Ruby, JavaScript vai jebkurā citā valodā, kas ir vagons un mazs ratiņš. Tas, ko jūs rakstāt, tiek saukts par avota kodu. Sākumā, it īpaši, ja strādājat viens, varat visu saglabāt vietējā direktorijā. Taču, projektam augot un pievienojoties arvien vairāk cilvēku, jums ir nepieciešams veids, kā koplietot koda izmaiņas, bet, apvienojot izmaiņas, izvairīties no konfliktiem. Un jums ir arī kaut kā jāatjauno iepriekšējās versijas, neizmantojot dublējumus un izmantojot kopēšanas-ielīmēšanas metodi koda failiem.
Un šeit bez SCM nekur. SCM glabā kodu krātuvēs, pārvalda tā versijas un koordinē to starp izstrādātājiem.
Ir daudz SCM rīku, taču Git ir pelnīti kļuvis par de facto standartu. Iesaku to izmantot, bet ir arī citas iespējas.
Lūk, kā izskatās DevOps cauruļvads pēc SCM pievienošanas.
CI/CD rīks var automatizēt pirmkoda augšupielādi un lejupielādi, kā arī komandas sadarbību. Nav slikti? Bet tagad, kā izveidot funkcionējošu lietojumprogrammu no šīs, ko mīl miljardiem lietotāju?
3. darbība: izveidojiet automatizācijas rīku
Viss notiek kā nākas. Varat augšupielādēt kodu un veikt izmaiņas avota kontrolē, kā arī uzaicināt draugus sadarboties ar jums. Bet jums vēl nav lietotnes. Lai šī būtu tīmekļa lietojumprogramma, tā ir jāapkopo un jāiepako izplatīšanai vai jāpalaiž kā izpildāmā programma. (Interpretētā programmēšanas valoda, piemēram, JavaScript vai PHP, nav jākompilē.)
Izmantojiet būvniecības automatizācijas rīku. Neatkarīgi no tā, kuru rīku izvēlaties, tas apkopos kodu pareizajā formātā un automatizēs tīrīšanu, apkopošanu, testēšanu un piegādi. Veidošanas rīki atšķiras atkarībā no valodas, taču parasti tiek izmantotas tālāk norādītās atvērtā pirmkoda opcijas.
Perfekti! Tagad ievietosim veidošanas automatizācijas rīka konfigurācijas failus avota vadīklā, lai CI/CD rīks tos izveidotu.
Tas jūtas labi. Bet kur to visu tagad izvērst?
4. darbība: tīmekļa lietojumprogrammu serveris
Tātad jums ir iepakots fails, ko var izpildīt vai izvilkt. Lai lietojumprogramma patiešām būtu noderīga, tai ir jābūt kaut kādam pakalpojumam vai interfeisam, taču jums tas viss ir kaut kur jāievieto.
Tīmekļa lietojumprogrammu var mitināt tīmekļa lietojumprogrammu serverī. Lietojumprogrammu serveris nodrošina vidi, kurā varat izpildīt pakotnes loģiku, renderēt saskarnes un atklāt tīmekļa pakalpojumus, izmantojot ligzdu. Lai instalētu lietojumprogrammu serveri, ir nepieciešams HTTP serveris un dažas citas vides (piemēram, virtuālā mašīna). Pagaidām izliksimies, ka ar to visu saskaraties (lai gan tālāk es runāšu par konteineriem).
Ir vairāki atvērti tīmekļa lietojumprogrammu serveri.
Mums jau ir gandrīz strādājoša DevOps ķēde. Lielisks darbs!
Principā jūs varat apstāties šeit, pēc tam varat ar to tikt galā pats, taču ir vērts runāt par koda kvalitāti.
5. darbība: pārbaudiet pārklājumu
Testēšana prasa daudz laika un pūļu, taču labāk ir uzreiz atrast kļūdas un uzlabot kodu, lai iepriecinātu galalietotājus. Šim nolūkam ir daudz atvērtu rīku, kas ne tikai pārbaudīs kodu, bet arī ieteiks, kā to uzlabot. Lielāko daļu CI/CD rīku var pievienot šiem rīkiem un automatizēt procesu.
Testēšana ir sadalīta divās daļās: testēšanas ietvari testu rakstīšanai un izpildei un rīki ar padomiem koda kvalitātes uzlabošanai.
Testēšanas ietvari
Instrumenti ar kvalitatīviem padomiem
Lielākā daļa no šiem rīkiem un ietvariem ir rakstīti Java, Python un JavaScript, jo C++ un C# ir patentēti (lai gan GCC ir atvērtā koda).
Mēs esam izmantojuši testa pārklājuma rīkus, un tagad DevOps konveijeram vajadzētu izskatīties kā attēlā apmācības sākumā.
Papildu darbības
Konteineri
Kā jau teicu iepriekš, lietojumprogrammu serveri var mitināt virtuālajā mašīnā vai serverī, bet konteineri ir populārāki.
? Īsāk sakot, virtuālajā mašīnā operētājsistēma bieži aizņem vairāk vietas nekā lietojumprogramma, un parasti pietiek ar konteineru ar dažām bibliotēkām un konfigurāciju. Dažos gadījumos virtuālās mašīnas ir neaizstājamas, taču konteinerā var ievietot lietojumprogrammu kopā ar serveri bez papildu maksas.
Konteineriem parasti tiek ņemti Docker un Kubernetes, lai gan ir arī citas iespējas.
Lasiet rakstus par Docker un Kubernetes vietnē :
Starpprogrammatūras automatizācijas rīki
Mūsu DevOps ķēde ir vērsta uz kopīgu lietojumprogrammu veidošanu un piegādi, taču ir arī citas interesantas lietas, ko varat darīt, izmantojot DevOps rīkus. Piemēram, izmantojiet Infrastructure as Code (IaC) rīkus, kas pazīstami arī kā starpprogrammatūras automatizācijas rīki. Šie rīki palīdz automatizēt starpprogrammatūras instalēšanu, pārvaldību un citus uzdevumus. Piemēram, automatizācijas rīks var uzņemt lietojumprogrammas (tīmekļa lietojumprogrammu serveris, datubāze, uzraudzības rīki) ar pareizo konfigurāciju un nosūtīt tos lietojumprogrammu serverim.
Šeit ir dažas atvērtās starpprogrammatūras automatizācijas rīku iespējas:
Sīkāka informācija rakstos :
Un tagad ko?
Tā ir tikai aisberga redzamā daļa. DevOps ķēde var darīt daudz vairāk. Sāciet ar CI/CD rīku un uzziniet, ko vēl varat automatizēt, lai atvieglotu savu darbu. Neaizmirstiet par efektīvai sadarbībai.
Šeit ir vēl daži labi DevOps raksti iesācējiem:
Varat arī integrēt DevOps ar atvērtiem veikliem rīkiem:
Avots: www.habr.com