🥇Algajate juhend: loome DevOps-i torujuhe

Kui olete DevOpsi uus, vaadake seda juhendit oma esimese viie etapi toru loomiseks.

DevOps on muutunud standardlahenduseks, et parandada aeglaseid, killustatud või mittetöötavaid tarkvaraarenduse protsesse. Probleemiks on see, et kui olete DevOpsis uus ega tea, kust alustada, siis võib teil puududa arusaam nendest metodoloogiatest. Selles artiklis räägitakse DevOpsi torustiku määratlemisest ning antakse juhend selle loomiseks viie sammu abil. Kuigi see õpik ei ole ammendav, peaks see andma teile aluse, et alustada oma teed ja laiendada oma teadmisi tulevikus. Kuid alustame ajaloost.

Minu teekond DevOpsi poole

Varem töötasin Citi Groupi pilvemeeskonnas, arendades Infrastructure-as-a-Service (IaaS) veebirakendust Citi pilvainfrastruktuuri haldamiseks, kuid mind on alati huvitanud, kuidas muuta arendusprotsessi tõhusamaks ning tuua positiivseid kultuurilisi muutusi arendajate meeskonda. Vastuse leidsin Greg Lavenderi, Citi pilvearhitektuuri ja infrastruktuuri tehnilise direktori, soovitatud raamatust. Raamat kandis pealkirja „Phoenixi Projekt“ (The Phoenix Project), mis selgitab DevOpsi põhimõtteid, samas kui see loetakse nagu romaan.

Raamatukaane tagaküljel olevas tabelis on näidatud, kui sageli erinevad ettevõtted kasutusele võetakse oma süsteemid vabastamiskeskkonnas:

Amazon: 23 000 korda päevas
Google: 5 500 korda päevas
Netflix: 500 korda päevas
Facebook: 1 kord päevas
Twitter: 3 korda nädalas
Tüüpiline ettevõte: 1 kord 9 kuu jooksul

Kuidas on Amazon, Google ja Netflix niisuguste sagedustega üldse võimalikud? Selle kõik tõttu, et need ettevõtted on väljamõelnud peaaegu ideaalse DevOpsi toru.

Me olime sellest kaugel, kuni me Citi-s DevOps-i juurutama hakkasime. Tol hetkel olid minu meeskonnas erinevad keskkonnad, kuid arendusse serverisse juurutamine oli täiesti käsitsi tehtud. Kõik arendajad pääsesid vaid ühele IBM WebSphere Application Server Community Edition põhinevale arendusserverile. Probleem oli selles, et server lõpetas töötamise iga kord, kui mitu kasutajat üritasid samaaegselt juurutada, mistõttu pidid arendajad üksteisele oma kavatsustest teadma andma, mis oli üsna vaevaline. Lisaks olid probleemid madala taseme koodi testimise katvusega, tükkide käsitsi juurutamise keerukusega ja puudus võimalus jälgida koodi juurutamist, mis on seotud konkreetse ülesande või kasutajaloo kohta.

Mõistsin, et midagi tuleb ette võtta, ja leidsin endale mõttekaaslase. Otsustasime koostööd teha esialgse DevOps-i torujuhtme loomisel – tema seadistas virtuaalse masina ja Tomcat rakenduste serveri, samal ajal kui mina töötasin Jenkinsiga, integreerisin Atlassian Jira ja BitBucketit ning tegelesin koodi testimise kattega. See külgprojekt oli väga edukas: me automatiseerisime praktiliselt paljusid protsesse, saavutades peaaegu 100% meie arendusserveri töökindlusest, tagasime jälgimise ja parandasime koodi testimise katvust ning lisasime võimaluse siduda Git-i harud Jira ülesannete või juurutamisega. Enamik tööriistu, mida kasutasime oma DevOps-i torujuhtme koostamiseks, olid avatud lähtekoodiga.

Nüüd mõistan, kui lihtne oli meie DevOps-i torujuhe: me ei kasutanud laiendusi nagu Jenkins file või Ansible. Kuid see lihtne torujuhe töötas hästi, võib-olla tänu Pareto põhimõttele (tuntud ka kui 80/20 reegel).

Lühike sissejuhatus DevOpsi ja CI/CD torujuhtmesse

Kui küsida mitmelt inimeselt: "Mis on DevOps?", siis tõenäoliselt saadakse mitmeid erinevaid vastuseid. DevOps, nagu ka Agile, on arenenud mitmete erinevate distsipliinide katmiseks, kuid enamik inimesi on nõus teatavate asjadega: DevOps on tarkvaraarenduse tava või tarkvaraarenduse elutsükkel (SDLC), mille keskne põhimõte on kultuuri muutmine, kus arendajad ja mitte-arendajad eksisteerivad keskkonnas, kus:

Automatiseeritakse toimingud, mida varem tehti käsitsi;
Igaüks teeb seda, mis talle kõige paremini välja tuleb;
Väljamaksete arv kindla aja jooksul suureneb; Läbivõime suureneb;
Arenduse paindlikkus suureneb.

Kuigi õigete tarkvaratööriistade olemasolu ei ole ainus asi, mida vajatakse DevOps keskkonna loomisel, on mõned tööriistad hädavajalikud. Peamine tööriist on pidev integreerimine ja pidev juurutamine (CI/CD). Selle konveieril on keskkondadel erinevad etapid (nt DEV, INT, TST, QA, UAT, STG, PROD), paljusid toiminguid on automatiseeritud ja arendajad saavad kirjutada kvaliteetset koodi, saavutada arenduse paindlikkust ja suurendada juurutamiste sagedust.

Selles artiklis käsitletakse viieetapilist lähenemist DevOps konveieri loomisele, mis on sarnane järgmisel joonisel kajastatule, kasutades avatud lähtekoodiga tööriistu.

1. etapp: CI/CD meetodid

Esimene asi, mida vajate – CI/CD tööriist. Jenkins, avatud lähtekoodiga tööriist, mis põhineb Java-l ja levitatud MIT-litsentsi alusel, on see vahend, mis on populariseerinud DevOps suunda ja saanud de facto standardiks.

Mis siis on Jenkins? Peate seda vaatama kui mingit maagilist universaalset puldi, mis saab suhelda erinevate teenuste ja tööriistadega ning neid organiseerida. CI/CD tööriist nagu Jenkins iseenesest on kasututu, kuid see muutub võimsamaks, kui see on ühendatud erinevate tööriistade ja teenustega.

Jenkins on vaid üks paljusid avatud lähtekoodiga tööriistu CI/CD jaoks, mida saate kasutada DevOps-piiplaani ehitamiseks.

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

Näiteks kuidas näevad DevOps-protsessid välja CI/CD tööriistaga:

Teil on CI/CD tööriist, mis töötab teie localhostis, kuid praegu ei saa te palju teha. Liigume järgmisse etappi DevOpsi maailma.

Samm 2: Allika koodi haldamine

Parim (ja võib-olla lihtsaim) viis kontrollida, kas teie CI/CD tööriist suudab teha imesid - integreeruda allika koodi haldustööriistaga (SCM). Miks vajate allika koodi haldust? Oletame, et arendate rakendust. Iga kord, kui loote rakenduse, kodeerite, ja pole tähtis, kas kasutate Java, Python, C++, Go, Ruby, JavaScript või mõnda muud miljardit programmeerimiskeelt. Teie kirjutatud kood on allika kood. Alguses, eriti kui töötate üksi, on tõenäoliselt võimalik kõik paigutada kohalikku katalooge. Kuid kui projekt kasvab ja kutsute teisi koostööks, vajate viisi konfliktide vältimiseks ja muudatuste tõhusaks vahetamiseks. Te vajate ka viisi varasema versiooni taastamiseks, sest varundamine ja kopeerimine/kleepimine on juba vananenud. Te vajate (ja teie meeskonnakaaslased) midagi paremat.

Siin muutub allika koodi haldustööriist praktiliselt vajalikuks. See tööriist hoiab teie koodi hoidlas, jälgib versioone ja koordineerib projekti osalejate tööd.

Kuigi on palju allika koodi haldustööriistu, on Git standard ja see peab paika. Soovitan tungivalt kasutada Git'i, kuigi soovi korral on ka teisi avatud lähtekoodiga alternatiive.

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

Nii näeb DevOps'i torujuhe välja koos allika koodi haldustööriistade lisamisega.

CI/CD tööriist suudab automatiseerida kontrollimise, allika koodi hankimise ja meeskonnakaaslaste koostöö protsesse. Pole paha? Aga kuidas muuta see töötavaks rakenduseks, mida miljardid inimesed saaksid kasutada ja hinnata?

Samm 3: Automatiseerimise tööriista loomine

Suurepärane! Saate kontrollida koodi ja teha muudatusi allika juhtimissüsteemis ning kutsuda oma sõpru koostöösse arendusse. Kuid te pole veel rakendust loonud. Veebirakenduse loomiseks tuleks see kompileerida ja pakkida kasutamiseks valmis paketivormingusse või käivitada täitmisfailina. (Pange tähele, et tõlgendatud programmeerimiskeel, näiteks JavaScript või PHP, ei vaja kompileerimist).

Kasutage koostamise automatiseerimise tööriista. Sõltumata sellest, millisest koostamise automatiseerimise tööriistast otsustate kasutada, on nende peamine eesmärk üks ja sama: koguda allika kood soovitud vormingusse ning automatiseerida puhastamise, kompileerimise, testimise ja teatud keskkonda jagamise ülesanne. Koostamise tööriistad erinevad sõltuvalt teie programmeerimiskeelest, kuid siin on mõned üldised avatud lähtekoodiga variandid.

Nimi
Litsents
Programmeerimiskeel

Maven
Apache 2.0
Java

Ant
Apache 2.0
Java

Gradle
Apache 2.0
Java

Bazel
Apache 2.0
Java

Make
Gnu’s Not Unix), mille eesmärgiks on arendada süsteemikomponente, et luua vabalt kasutatav Unix'i analoog, mis võimaldab täielikult loobuda suletud tarkvarast. GNU juhtimisel on moodustatud vabade projektide kogukond, mis liiguvad ühise eesmärgi suunas ja arenevad ühtse ideoloogia ja filosoofia kohaselt. Alguses olid projekti keskseid elemente
N/A

Grunt
MIT
JavaScript

Gulp
MIT
JavaScript

Buildr
Apache
Ruby

Rake
MIT
Ruby

A-A-P
Gnu’s Not Unix), mille eesmärgiks on arendada süsteemikomponente, et luua vabalt kasutatav Unix'i analoog, mis võimaldab täielikult loobuda suletud tarkvarast. GNU juhtimisel on moodustatud vabade projektide kogukond, mis liiguvad ühise eesmärgi suunas ja arenevad ühtse ideoloogia ja filosoofia kohaselt. Alguses olid projekti keskseid elemente
Python

SCons
MIT
Python

BitBake
GPLv2
Python

Kook
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Suurepärane! Saate paigutada automatiseerimise tööriista konfiguratsioonifailid allika juhtimisse ja lasta oma CI/CD tööriistal kõik kokku panna.

Kõik on hästi, eks? Aga kuhu jagada oma rakendust?

Samm 4: Veebirakenduste server

Praegu on teil pakitud fail, mis võib olla nii täitmisfail kui ka installitav. Selleks, et rakendus oleks tõeliselt kasulik, peab see pakkuma mingit teenust või liidest, kuid teil on vaja konteinerit oma rakenduse hoidmiseks.

Veebirakenduste server on just selline konteiner. Server pakub keskkonda, kus saab määratleda jagatud paketi loogika. Samuti pakub server liidest ja pakub veebiteenuseid, avades pordid välismaailmale. Teil on vaja HTTP-serverit ja ka mingit keskkonda (nt virtuaalmasinat) selle installimiseks. Ja samas, oletame, et saate sellest hiljem teada (kuigi räägin konteineritest allpool).

On mitmeid avatud lähtekoodiga veebirakenduste servereid.

Nimi
Litsents
Programmeerimiskeel

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

Teie DevOps torujuhe on peaaegu valmis kasutamiseks. Hästi tehtud!

Kuigi sellel saab peatuda ja tegeleda integratsiooniga iseseisvalt, on koodikvaliteet rakenduste arendaja jaoks oluline asi ning sellega tuleb tegeleda.

Samm 5: Koodi testimise katmine

Testide rakendamine võib olla veel üks mahukas nõue, kuid arendajad peavad rakenduses varakult kinni püüdma kõik vead ning parandama koodi kvaliteeti, et tagada, et lõppkasutajad oleksid rahul. Õnneks on saadaval palju avatud lähtekoodiga tööriistu teie koodi testimiseks ja selle kvaliteedi parandamise soovituste koostamiseks. Veelgi parem on see, et enamik CI/CD tööriistu saavad nendega ühenduda ja protsessi automatiseerida.

Koodi testimine koosneb kahest osast: kooditestimise raamistike, mis aitavad testide kirjutamisel ja käivitamisel, ja soovituste koostamise tööriistadest, mis aitavad parandada koodi kvaliteeti.

Koodi testimissüsteemid

Nimi
Litsents
Programmeerimiskeel

JUnit
Eclipse'i avalik litsents
Java

EasyMock
Apache
Java

Mockito
MIT
Java

PowerMock
Apache 2.0
Java

Pytest
MIT
Python

Hypothesis
Mozilla
Python

Tox
MIT
Python

Koodi kvaliteedi parandamise soovitussüsteemid

Nimi
Litsents
Programmeerimiskeel

Cobertura
Gnu’s Not Unix), mille eesmärgiks on arendada süsteemikomponente, et luua vabalt kasutatav Unix'i analoog, mis võimaldab täielikult loobuda suletud tarkvarast. GNU juhtimisel on moodustatud vabade projektide kogukond, mis liiguvad ühise eesmärgi suunas ja arenevad ühtse ideoloogia ja filosoofia kohaselt. Alguses olid projekti keskseid elemente
Java

CodeCover
Eclipse'i avalik (EPL)
Java

Coverage.py
Apache 2.0
Python

Emma
Ühine avalik litsents
Java

JaCoCo
Eclipse'i avalik litsents
Java

Hypothesis
Mozilla
Python

Tox
MIT
Python

Jasmine
MIT
JavaScript

Karma
MIT
JavaScript

Mocha
MIT
JavaScript

Jest
MIT
JavaScript

Pange tähele, et enamiku ülalmainitud tööriistade ja raamistike kirjutamise keel on Java, Python ja JavaScript, kuna C++ ja C# on patenteeritud programmeerimiskeeled (kuigi GCC-l on avatud lähtekood).

Nüüd, kui olete rakendanud koodi katmise tööriistad, peaks teie DevOps-i torujuhe välja nägema nagu diagramm, mis on esitatud selle juhendi alguses.

Täiendavad sammud

Konteinerid

Nagu ma juba ütlesin, võite oma serveri paigutada virtuaalmasinale või serverisse, kuid konteinerid on populaarne lahendus.

Mis on konteinerid? Lühike seletus on see, et virtuaalmasin vajab operatsioonisüsteemi jaoks tohutut mälu, mis ületab rakenduse suuruse, samas kui konteiner vajab ainult mõningaid teeke ja seadistusi rakenduse käitamiseks. Ilmselt on virtuaalmasinal endiselt olulised kasutusvaldkonnad, kuid konteiner on kerge lahendus rakenduse, sealhulgas rakenduste serveri, majutamiseks.

Kuigi on ka teisi konteinerite valikuid, on kõige populaarsemad Docker ja Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Vaheautomationi vahendid

Meie DevOps-i torujuhe on peamiselt suunatud rakenduste ühisloomisele ja juurutamisele, kuid DevOps-i tööriistade abil on võimalik teha ka palju muid asju. Üks neist on infrastruktuuri koodi kaudu (IaC) tööriistade kasutamine, mida tuntakse ka vaheautomaatika vahenditena. Need tööriistad aitavad automatiseerida installatsiooni, haldamist ja muid ülesandeid vaheprogrammi jaoks. Näiteks võib automaatikatööriist ekstrakteerida rakendusi, nagu veebirakenduse server, andmebaas ja jälgimistööriist, koos õige konfiguratsiooniga ja juurutada need rakenduste serverisse.

Siin on mõned avatud lähtekoodiga vaheautomaatika tööriistad:

Ansible: GNU Public
SaltStack: Apache 2.0
Chef: Apache 2.0
Puppet: Apache või GPL