🥇Ceļvedis iesācējiem: veidojam DevOps cauruļvadu

Ja esat jauns DevOps jomā, apskatiet šo rokasgrāmatu, kas palīdzēs izveidot jūsu pirmo piecu posmu cauruli.

DevOps ir kļuvis par standarta risinājumu, lai labotu lēnus, izkliedētus vai neefektīvus programmatūras izstrādes procesus. Problēma ir tāda, ka, ja esat jauns DevOps jomā un nezināt, no kurienes sākt, jums var trūkt izpratnes par šiem paņēmieniem. Šajā rakstā tiks apspriesta DevOps caurules definīcija un sniegta rokasgrāmata tās izveidošanai piecos soļos. Lai gan šis mācību līdzeklis nav izsmeļošs, tam vajadzētu dot jums pamatu, lai uzsāktu savu ceļu un paplašinātu savas zināšanas nākotnē. Sāksim ar vēsturi.

Mana DevOps ceļojums

Agrāk es strādāju Citi Group mākonī, izstrādājot Infrastructure-as-a-Service (IaaS) tīmekļa lietotni Citi mākonis infrastruktūras pārvaldīšanai, taču man vienmēr bija interese par to, kā padarīt attīstības procesu efektīvāku un ieviest pozitīvas kultūras izmaiņas izstrādātāju komandā. Atbildi es atradu grāmatā, kas tika ieteikta Gregam Lavenderam, Citi mākonī arhitektūras un infrastruktūras tehniskajam direktoram. Grāmata saucās „Feniksa projekts“ (The Phoenix Project), un tajā skaidro DevOps principus, un tā tiek lasīta kā romāns.

Grāmatas aizmugurē redzamajā tabulā ir parādīts, cik bieži dažādas kompānijas izvērš savus sistēmas izlaidumu vidē:

Amazon: 23 000 dienā
Google: 5 500 dienā
Netflix: 500 dienā
Facebook: reizi dienā
Twitter: 3 reizes nedēļā
Tipiska kompānija: reizi 9 mēnešos

Kā vispār ir iespējamas tādas frekvences kā Amazon, Google un Netflix? Viss ir tādēļ, ka šīs kompānijas ir izdomājušas, kā izveidot gandrīz ideālu DevOps cauruli.

Mēs bijām tālu no tā, līdz ieviešam DevOps Citi. Tajā laikā manā komandā bija dažādas vides, bet izsniegšana izstrādes serverī bija pilnīgi manuāla. Visi izstrādātāji piekļuva tikai vienam izstrādes serverim, kas balstīts uz IBM WebSphere Application Server Community Edition. Problēma bija tāda, ka serveris izslēdzās, kad vairāki lietotāji vienlaikus mēģināja veikt izsniegšanu, tāpēc izstrādātājiem bija jāziņo viens otram par saviem nodomiem, kas bija diezgan sāpīgi. Turklāt pastāvēja problēmas ar zemu līmeņa koda testēšanas segumu, apjomīgajiem manuālās izsniegšanas procesiem un iespēju izsekot koda izsniegšanai, kas saistīta ar konkrētu uzdevumu vai lietotāja stāstu.

Es sapratu, ka jāveic kaut kas, un atradu kolēģi- līdzīgi domājošu partneri. Mēs nolēmām sadarboties, lai izveidotu pirmo DevOps konveijeru – viņš uzstādīja virtuālo mašīnu un Tomcat lietojumserveri, kamēr es strādāju pie Jenkins, integrēju Atlassian Jira un BitBucket, kā arī strādāju pie koda testēšanas seguma. Šis sānu projekts bija ļoti veiksmīgs: mēs gandrīz pilnībā automatizējām daudzas darbības, panācām gandrīz 100% mūsu izstrādes servera darbību, nodrošinājām izsekojamību un uzlabojām koda testēšanas segumu, kā arī pievienojām iespēju saistīt zarus Git ar uzdevumiem Jira vai izsniegšanu. Lielākā daļa rīku, ko mēs izmantojām, veidojot mūsu DevOps konveijeru, bija atvērta koda.

Tagad es saprotu, cik vienkāršs bija mūsu DevOps konveijers: mēs neizmantojām paplašinājumus, piemēram, Jenkins failus vai Ansible. Tomēr šis vienkāršais konveijers darbojās labi, iespējams, pateicoties Pareto principam (pazīstams arī kā 80/20 likums).

Īss ievads DevOps un CI/CD konveijerā

Ja, ja jautājat vairākiem cilvēkiem: „Kas ir DevOps?”, tad, visticamāk, jūs saņemsiet vairākas dažādas atbildes. DevOps, tāpat kā Agile, ir attīstījies, lai aptvertu daudz dažādu disciplīnu, bet lielākā daļa cilvēku piekritīs dažām lietām: DevOps ir programmatūras izstrādes prakse vai programmatūras izstrādes cikls (SDLC), kura centrālais princips ir kultūras maiņa, kurā izstrādātāji un neizstrādātāji pastāv vidē, kas:

Automatizē operācijas, kuras iepriekš veica manuāli;
Katrs dara to, kas viņam vislabāk padodas;
Ieviešanas skaits noteiktā laika periodā palielinās; caurlaidspēja palielinās;
Palielinās izstrādes elastība.

Lai arī pareizo programmatūras rīku esamība ir ne tikai tas, kas nepieciešams, lai izveidotu DevOps vidi, daži rīki ir nepieciešami. Galvenais rīks ir nepārtraukta integrācija un nepārtraukta izvietošana (CI/CD). Šajā konveijerī vidēm ir dažādas fāzes (piemēram, DEV, INT, TST, QA, UAT, STG, PROD), daudzas operācijas ir automatizētas, un izstrādātāji var rakstīt kvalitatīvu kodu, panākt izstrādes elastību un biežāku izvietošanu.

Šajā rakstā tiek aprakstīts piecu posmu pieejas izveidošanai DevOps konveijeram, kā parādīts nākamajā diagrammā, izmantojot atvērtā koda rīkus.

Posms 1: CI/CD metodes

Vispirms jums nepieciešams rīks CI/CD. Jenkins, atvērtā koda rīks, kas balstīts uz Java un tiek izplatīts saskaņā ar MIT licenci, ir tas instruments, kas popularizēja DevOps pieeju un kļuvis par de facto standartu.

Tātad, kas ir Jenkins? Uzskatiet to par kādu maģisku universālu tālvadības pulti, kas var runāt ar dažādām pakalpojumu un rīku sistēmām un organizēt tās. CI/CD rīks, piemēram, Jenkins, pats par sevi ir bezjēdzīgs, taču tas kļūst jaudīgāks, kad tas pievienojas dažādiem rīkiem un pakalpojumiem.

Jenkins ir tikai viens no daudziem atvērtā koda CI/CD rīkiem, ko varat izmantot, lai izveidotu DevOps cauruļu.

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

Tā izskatās DevOps procesi ar CI/CD rīku:

Jums ir CI/CD rīks, kas darbojas jūsu lokālajā tīklā, bet patlaban jūs varat darīt maz. Pāriesim pie nākamā soļa ceļojumā DevOps pasaulē.

2. solis: Koda versiju kontroles pārvaldība

Labākais (un, iespējams, visvienkāršākais) veids, kā pārbaudīt, vai jūsu CI/CD rīks spēj radīt maģiju – integrēties ar versiju kontroles rīku (SCM). Kāpēc jums nepieciešams kodu kontrole? Pieņemsim, ka izstrādājat lietotni. Kad jūs izstrādājat lietotni, jūs kodējat, un nav nozīmes, vai jūs izmantojat Java, Python, C++, Go, Ruby, JavaScript vai kādu no daudziem citiem programmēšanas valodām. Kods, ko jūs rakstāt, tiek saukts par avota kodu. Iesākumā, it īpaši, kad strādājat viens, iespējams, to varat ievietot visus lokālā direktorijā. Bet, kad projekts kļūst lielāks un jūs uzaicināt citus uz sadarbību, jums nepieciešams veids, kā novērst konfliktus efektīvas modifikāciju apmaiņas laikā. Jums arī nepieciešams veids, kā atjaunot iepriekšējās versijas, jo dublēšana un kopēšana/ielīmēšana jau ir novecojusi. Jums (un jūsu komandai) nepieciešams kaut kas labāks.

Tieši šeit koda versiju kontroles rīks kļūst praktiski neaizstājamība. Šis rīks saglabā jūsu kodu repozitorijos, uzskaita versijas un koordinē projekta dalībnieku darbu.

Lai gan pastāv daudzi koda versiju kontroles rīki, Git ir standarts, un tas ir taisnīgi. Es ļoti ieteiktu izmantot Git, lai gan, ja vēlaties, ir arī citi atvērtā koda varianti.

Git: GPLv2 un LGPL v2.1
Subversion: Apache 2.0
Concurrent Versions System (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Tā izskatās DevOps cauruļvads, pievienojot versiju kontroles rīkus.

CI/CD rīks var automatizēt pārbaudes, avota koda iegūšanas un sadarbības procesus starp dalībniekiem. Labi? Bet kā padarīt to par strādājošu lietotni, lai miljardiem cilvēku to varētu izmantot un novērtēt?

3. solis: Automatizācijas rīka izveide

Lieliski! Jūs varat pārbaudīt kodu un veikt izmaiņas versiju kontrolē, kā arī ielūgt savus draugus sadarboties izstrādē. Taču jūs vēl neesat izveidojis lietotni. Lai izveidotu tīmekļa lietotni, to jākompilē un jāpako izplatāmā pakotņu formātā vai jāpalaiž kā izpildāmu failu. (Lūdzu, ņemiet vērā, ka interpretējamai programmēšanas valodai, piemēram, JavaScript vai PHP, nav nepieciešama kompilācija).

Izmantojiet būvniecības automātizācijas rīku. Neatkarīgi no tā, kuru būvniecības automātizācijas rīku jūs izvēlēsities, visi tie tiecas uz vienu un to pašu mērķi: savākt avota kodu kādā vēlamajā formātā un automatizēt uzdevumus, piemēram, tīrīšanu, kompilēšanu, testēšanu un izvietošanu konkrētā vidē. Būvniecības rīki atšķirsies atkarībā no jūsu programmēšanas valodas, bet šeit ir daži vispārīgi atvērtā koda varianti.

Nosaukums
Licence
Programmēšanas valoda

Maven
Apache 2.0
Java

BIND
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

Forši! Jūs varat ievietot automātizācijas rīka konfigurācijas failus avota kontroles sistēmā un ļaut jūsu CI/CD rīkam savienot visu kopā.

Viss ir labi, vai ne? Bet kur izvietot jūsu lietotni?

4. solis: Tīmekļa lietotņu serveris

Pagājušajā laikā jums ir iepakots fails, kas var būt gan izpildāms, gan instalējams. Lai jebkura lietotne būtu patiešām noderīga, tai jāsniedz kāda pakalpojuma vai interfeisa funkcionalitāte, bet jums ir nepieciešams konteinera, kur ievietot jūsu lietotni.

Tīmekļa lietotņu serveris ir tieši tāds konteiners. Serveris nodrošina vidi, kurā var definēt izvietojamā pakotņa loģiku. Arī serveris nodrošina interfeisu un piedāvā tīmekļa pakalpojumus, atverot pieslēgumus ārējai pasaulei. Jums nepieciešams HTTP serveris, kā arī kāda vide (piemēram, virtuālā mašīna) tā instalēšanai. Bet pagaidām pieņemiet, ka jūs par to uzzināsiet tālāk (lai gan es zemāk runāšu par konteineriem).

Pastāv vairāki atvērtā koda tīmekļa lietotņu serveri.

Nosaukums
Licence
Programmēšanas valoda

Tomcat
Apache 2.0
Java

Jetty
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

GlassFish
CDDL & GNU Less Public
Java

Django
3-Clause BSD
Python

Tornado
Apache 2.0
Python

Gunicorn
MIT
Python

Python
MIT
Python

Rails
MIT
Ruby

Node.js
MIT
Javascript

Jūsu DevOps cauruļvads drīz būs gatavs lietošanai. Lielisks darbs!

Lai gan šeit varētu apstāties un veikt integrāciju patstāvīgi, koda kvalitāte ir svarīgs faktors lietojumprogrammu izstrādātājiem, un par to ir jārūpējas.

5. solis: Koda testēšanas segums

Testu īstenošana var būt vēl viens apgrūtinājums, taču izstrādātājiem ir jāatklāj jebkādas kļūdas lietojumprogrammā jau agri un jāuzlabo koda kvalitāte, lai garantētu, ka gala lietotāji būs apmierināti. Par laimi, pastāv daudz atvērtā koda rīku, lai testētu savu kodu un izveidotu ieteikumus tā kvalitātes uzlabošanai. Vēl labāk, ka vairums CI/CD rīku var pievienoties šiem rīkiem un automatizēt procesu.

Koda testēšana sastāv no divām daļām: koda testēšanas ietvariem, kas palīdz rakstīt un palaist testus, un ieteikumu veidošanas rīkiem, kas palīdz uzlabot koda kvalitāti.

Koda testēšanas sistēmas

Nosaukums
Licence
Programmēšanas valoda

JUnit
Eclipse Public License
Java

EasyMock
Apache
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Ieteikumu sistēmas koda uzlabošanai

Nosaukums
Licence
Programmēšanas valoda

Cobertura
GNU
Java

CodeCover
Eclipse Public (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Common Public License
Java

JaCoCo
Eclipse Public License
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Pievērsiet uzmanību, ka lielākā daļa iepriekš minēto rīku un ietvaru ir uzrakstīti Java, Python un JavaScript valodā, jo C++ un C# ir proprietāras programmēšanas valodas (lai gan GCC ir atvērtā koda).

Tagad, kad esat īstenojis koda pārklājuma rīkus, jūsu DevOps plūsmai būtu jāizskatās kā diagrammai, kas parādīta šī ceļveža sākumā.

Papildu soļi

Tvertnes

Kā jau teicu, jūs varat izvietot savu serveri virtuālā mašīnā vai serverī, bet konteineri ir populāra lieta.

Kas ir konteineri? Īss paskaidrojums ir tāds, ka virtuālajai mašīnai ir nepieciešams ievērojams operētājsistēmas atmiņas apjoms, kas pārsniedz lietojumprogrammas izmēru, savukārt konteineram nepieciešamas tikai dažas bibliotēkas un konfigurācijas, lai palaistu lietojumprogrammu. Acīmredzot virtuālajai mašīnai joprojām ir svarīgas pielietošanas jomas, taču konteiners ir viegla lietošanas risinājums, tostarp lietojumprogrammu serveriem.

Lai gan pastāv arī citi konteineru varianti, vispopulārākie ir Docker un Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Starpprogrammatūras automatizācijas rīki

Mūsu DevOps cauruļvads galvenokārt ir vērsts uz kopīgu lietojumprogrammu izstrādi un izvietošanu, taču ar DevOps rīkiem ir iespējams paveikt daudz citas lietas. Viens no veidiem ir infrastruktūras kā koda (IaC) rīku izmantošana, kas ir pazīstami arī kā starpprogrammatūras automatizācijas rīki. Šie rīki palīdz automatizēt instalāciju, pārvaldību un citas uzdevumu veikšanas funkcijas starpprogrammatūrai. Piemēram, automatizācijas rīks var iegūt lietojumprogrammas, piemēram, tīmekļa lietojumprogrammu serverus, datu bāzes un uzraudzības rīkus, ar pareizajām konfigurācijām un izvietot tās lietojumprogrammu serverī.

Šeit ir daži atvērtā koda starpprogrammatūras automatizācijas rīki:

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