🥇Algajatele mõeldud juhend: loome DevOpsi konveieri

Kui olete DevOpsi algaja, siis vaadake seda juhendit, kuidas luua oma esimest viie etapi konveierit.

DevOps on saanud standardlahenduseks aeglaste, killustatud või mittetöötavate tarkvaraarenduse protsesside parandamiseks. Probleem on aga see, et kui olete DevOpsi uus ja ei tea, kust alustada, siis võib teil puududa arusaam nendest meetoditest. Selles artiklis käsitletakse DevOpsi konveieri määratlemist ning pakutakse juhendit, kuidas seda luua viie lihtsa sammuga. Kuigi see õpik ei ole ammendav, peaks see andma teile aluse, et alustada oma teekonda ja laiendada oma teadmisi tulevikus. Aga alustame ajaloost.

Minu teekond DevOpsis

Varem töötasin Citi Groupi pilve meeskonnas, arendades Infrastructure-as-a-Service (IaaS) veebirakendust Citi pilveinfrastruktuuri haldamiseks, kuid mind on alati huvitanud, kuidas muuta arendusprotsessi tõhusamaks ja tuua positiivseid kultuurilisi muudatusi arendajate meeskonda. Vastuse leidsin raamatust, mille soovitas Greg Lavender, Citi tehniline direktor pilvearhitektuuri ja infrastruktuuri alal. Raamat kandis pealkirja „The Phoenix Project“The Phoenix Project), ja seal selgitatakse DevOpsi põhimõtteid, olles samas ka romaanina meeldiv lugeda.

Raamatukaane tagaküljel olevas tabelis on näidatud, kui sageli erinevad ettevõtted juurutavad oma süsteeme väljaandearvestuses:

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

Kuidas on Amazon, Google ja Netflix suudavad saavutada selliseid sagedusi? Kõik see on võimalik, kuna need ettevõtted on leidnud, kuidas luua peaaegu ideaalne DevOps konveier.

Me olime sellest kaugel, kuni hälbisime DevOpsi Citi-s. Sel ajal olid minu meeskonnas erinevad keskkonnad, kuid arendusserverisse toodud juurutamine oli täielikult käsitsi. Kõik arendajad pääsesid ainult ühele IBM WebSphere Application Server Community Editioni põhisele arendusserverile. Probleem seisnes selles, et server kustus iga kord, kui mitu kasutajat üheaegselt juurutamist tegema püüdsid, seega pidid arendajad üksteisele oma kavatsustest teatama, mis oli üsna vaevaline. Lisaks esines madala taseme testimise katvuse, kohmakate käsitööjuurutamisprotsesside ja võimaluste puudumisega jälgida koodijuurutamist, mis on seotud konkreetse ülesande või kasutajalooga.

Mõistsin, et peab midagi tegema, ja leidsin kaaskodaniku. Otsustasime koostööd teha algse DevOps-voo loomisel – tema seadistas virtuaalmasina ja Tomcat rakendusserveri, samas kui mina tegelesin Jenkinsiga, integreerisin Atlassian Jira ja BitBucket'i, samuti töötasin koodikatte testimise kallal. See kõrvalprojekt oli väga edukas: automatiseerisime peaaegu täielikult mitmeid protsesse, saavutasime peaaegu 100% katvuse meie arendusserveris, tagasime jälgimise ja parandasime koodikatte testimise, samas lisasime võimaluse linkida Git'i harud Jira ülesannete või juurutamistega. Enamik tööriistu, mida kasutasime meie DevOps-voo ehitamiseks, olid avatud lähtekoodiga.

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

Lühike ülevaade DevOps-ist ja CI/CD voost

Kui te küsiksite mitmelt inimeselt: „Mis on DevOps?“, saaksite tõenäoliselt mitu erinevat vastust. DevOps, nagu Agile, on arenenud mitmete erinevate valdkondade katmiseks, kuid enamik inimesi nõustub mõne asja üle: DevOps on tarkvaraarenduse praktika või tarkvaraarenduse elutsükkel (SDLC), mille keskne põhimõte on kultuuri muutmine, kus arendajad ja mitte-arendajad eksisteerivad keskkonnas, kus:

Automatiseeritud on tegevused, mida varem tehti käsitsi;
Igaüks teeb seda, mis tal kõige paremini välja tuleb;
Teatud ajavahemiku jooksul toimuvate väljalaskete arv suureneb; Suureneb läbilaskevõime;
Arenduse paindlikkus tõuseb.

Kuigi õige tarkvaratööriistade olemasolu ei ole ainus, mis on vajalik DevOpsi keskkonna loomiseks, on mõned tööriistad hädavajalikud. Peamine tööriist on pidev integreerimine ja pidev juurutamine (CI/CD). Selles konveieris on erinevad etapid (nt DEV, INT, TST, QA, UAT, STG, PROD), paljusid toiminguid automatiseeritakse ja arendajad saavad kirjutada kvaliteetset koodi, saavutades arenduse paindlikkuse ja suure juurutamis sageduse.

Selles artiklis käsitletakse viieastmelist lähenemist DevOps konveieri loomisele, mis sarnaneb järgmise diagrammiga, kasutades avatud lähtekoodiga tööriistu.

Samm 1: CI/CD meetodid

Esimene asi, mida vajate, on CI/CD tööriist. Jenkins, avatud lähtekoodiga tööriist, mis põhineb java-l ja mille litsents on MIT, on see vahend, mis populariseeris DevOpsi suunda ja sai de facto standardiks.

Nii et mis on Jenkins? Mõelge sellele kui maagilisele universaalsele kaugjuhtimispuldile, mis suudab suhelda erinevate teenuste ja tööriistadega ning organiseerida neid. CI/CD tööriist ise, nagu Jenkins, ei ole väga kasulik, kuid muutub võimsamaks, kui see on ühendatud erinevate tööriistade ja teenustega.

Jenkins on vaid üks paljusid avatud lähtekoodiga CI/CD tööriistu, mida saate kasutada DevOps torujuhtme loomiseks.

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

Nii 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ärgmisele sammule DevOps maailmas.

Samm 2: Allika juhtimissüsteemide haldamine

Parim (ja võib-olla ka kõige lihtsam) viis kontrollida, kas teie CI/CD tööriist suudab ime teha, on integreerimine lähtekoodi halduse tööriistaga (SCM). Miks on teil vajalik lähtekoodi haldus? Oletame, et arendate rakendust. Iga kord, kui loote rakendust, programmeerite te, ja ei ole vahet, kas kasutate Java't, Pythonit, C++'t, Go't, Ruby't, JavaScripti või mõnda muud miljonit programmeerimiskeelt. Kood, mille kirjutate, nimetatakse lähtekoodiks. Alguses, eriti kui töötate üksi, on tõenäoliselt võimalik kõik asetada kohalikku kaustasse. Kuid kui projekt kasvab ja kutsute teisi inimesi koostööle, vajate viisi konfliktide ennetamiseks tõhusas muudatuste jagamises. Teil on samuti vaja võimalust eelmisi versioone taastada, sest varukoopiate loomine ja nende kopeerimine/kleepimine on juba vananenud. Teile (ja teie meeskonnakaaslastele) on midagi paremat vaja.

Just siin muutub lähtekoodi kontrolldus praktiliselt hädavajalikuks. See tööriist salvestab teie koodi hoidlatele, jälgib versioone ja koordineerib projekti osalejate tööd.

Kuigi on palju lähtekoodi kontrolle, on Git standard ja see on tõsi. Soovitan tungivalt kasutada Git'i, kuigi soovi korral on olemas ka muid avatud lähtekoodi valikuid.

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

Selline välja näeb DevOps torustik koos lähtekoodi kontrollivahenditega.

CI/CD tööriist võib automatiseerida kontrollimise, lähtekoodi saamise ja koostöö protsessid liikmete vahel. Pole paha? Kuid kuidas teha sellest toimiv rakendus, et miljardid inimesed saaksid seda kasutada ja hinnata?

Samm 3: Automaatika kogumise tööriista loomine

Suurepärane! Saate kontrollida koodi ja teha muudatusi versioonihaldussüsteemis ning kutsuda oma sõpru arendusse osalema. Kuid olete ikka veel oma rakendust loonud. Veebirakenduse loomiseks tuleb see kompileerida ja pakkida kasutatavasse paketivormingusse või käivitada täitmisfailina. (Pange tähele, et tõlgendatavad programmeerimiskeeled, nagu JavaScript või PHP, ei vaja kompileerimist).

Kasutage ehituse automatiseerimise tööriista. Ükskõik, millist ehituse automatiseerimise tööriista otsustate kasutada, on nende ühine eesmärk: koguda lähtekood soovitud vormingusse ja automatiseerida puhastamise, kompileerimise, testimise ja juurutamise ülesanne kindlas keskkonnas. Ehitustööriistad sõltuvad teie programmeerimiskeelest, kuid siin on mõned levinud avatud lähtekoodiga variandid.

Nimi
Litsents
Programmeerkiel

Maven
Apache 2.0
Java

Ant
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

Kook
MIT
C#

ASDF
Expat (MIT)
LISP

Cabal
BSD
Haskell

Tere! Saate oma koostamisautomaadi seadistuses olevad failid paigutada allika juhtimisse ja lasta oma CI/CD tööriistal kõik kokku panna.

Kõik on hästi, eks? Kuid kus on võimalik teie rakendust juurutada?

Samm 4: Veebirakenduste server

Praegu on teil pakitud fail, mis võib olla kas käivitatav või installitav. Selleks, et mis tahes rakendus oleks tõeliselt kasulik, peab see pakkuma mingit teenust või liidest, kuid vajate konteinerit oma rakenduse mahutamiseks.

Veebirakenduste server on just selline konteiner. Server loob keskkonna, kus saad määratleda juurutatava paketi loogika. Samuti annab server liidese ja pakub veebiteenuseid, avades välismaailmale pordid. Teil on vaja HTTP-serverit ja mõnda keskkonda (nt virtuaalmasin) selle käitamiseks. Eeldame seni, et te õpite selle kohta rohkem (kuigi räägin konteineritest allpool).

On mitmeid avatud lähtekoodiga veebirakenduste servereid.

Nimi
Litsents
Programmeerkiel

Tomcat
Apache 2.0
Java

Jetty
Apache 2.0
Java

WildFly
GNU Lesser Public
Java

GlassFish
CDDL ja 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 toru on peaaegu kasutamiseks valmis. Hästi tehtud!

Kuigi võib peatuda ja hakata integreerimisega iseseisvalt tegelema, on koodikvaliteet rakenduse arendajate jaoks oluline ning sellega tuleb tegeleda.

Samm 5: Koodi testimise katmine

Testide rakendamine võib olla veel üks tülikas nõue, kuid arendajad peavad rakenduses tõrkeid varakult tabama ja koodikvaliteeti parandama, et tagada lõppkasutajate rahulolu. Õnneks on olemas palju avatud lähtekoodiga tööriistu teie koodi testimiseks ja kvaliteedi parandamise soovituste genereerimiseks. Veelgi parem on see, et enamik CI/CD tööriistu saavad nendele tööriistadele ühenduda ja protsessi automatiseerida.

Koodi testimine koosneb kahest osast: koodi testimise raamistikud, mis aitavad testide kirjutamisel ja käitamisel, ning soovituste genereerimise tööriistad, mis aitavad koodikvaliteeti parandada.

Koodi testimise süsteemid

Nimi
Litsents
Programmeerkiel

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

Koodivõimaluste parandamise süsteemid

Nimi
Litsents
Programmeerkiel

Cobertura
GNU
Java

CodeCover
Eclipse Public (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 enamik ülaltoodud tööriistu ja raamistikke on kirjutatud Java, Python ja JavaScript jaoks, kuna C++ ja C# on omandi õigustega programmeerimiskeeled (kuigi GCC on avatud lähtekoodiga).

Nüüd, kui olete rakendanud koodikattete tööriistu, peaks teie DevOps torujuhe olema sarnane alguses esitatud diagrammiga.

Täiendavad sammud

Konteinerid

Nagu juba mainisin, saate oma serveri paigutada virtuaalmasinale või serverisse, kuid konteinerid on populaarsed lahendused.

Mis on konteinerid? Lühiülevaade on see, et virtuaalmasin vajab oma operatsioonisüsteemi jaoks suurt mälu, mis ületab rakenduse suuruse, samas kui konteiner vajab ainult mõningaid teeke ja konfiguratsioone rakenduse käivitamiseks. Ilmselgelt on virtuaalmasinal endiselt olulised rakendusalad, kuid konteiner on kerge lahendus rakenduse, sealhulgas rakenduste serverite hostimiseks.

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

Docker: Apache 2.0
Kubernetes: Apache 2.0

Vahe-automatiseerimise tööriistad

Meie DevOps-toru on peamiselt suunatud rakenduste koostootmisele ja juurutamisele, kuid DevOps-tööriistade abil on võimalik teha palju muud. Üks neist on Infrastructure as Code (IaC) tööriistade kasutamine, mida tuntakse ka vahe-automatiseerimise tööriistadena. Need tööriistad aitavad automatiseerida installimist, haldamist ja muid ülesandeid vaheprogrammi jaoks. Näiteks võib automatiseerimistööriist hankida rakendusi nagu veebirakenduse server, andmebaas ja jälgimistööriist, koos õige konfigureerimisega ja juurutada need rakenduste serverisse.

Siin on mõned avatud lähtekoodiga vahe-automatiseerimise tööriistad:

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