Esimese DevOpsi ahela loomine viies etapis algajatele.
DevOps on saanud lahenduseks aeglastele, ääretult killustatutele ja teistele probleemsetele arendusprotsessidele. Kuid DevOpsi mõistmiseks on vajalikud minimaalsete teadmiste olemasolu. Siin käsitleme mõisteid nagu DevOpsi ahel ja kuidas see viies etapis luua. See ei ole täielik juhend, vaid lihtsalt „kalastamine”, mille abil saab edastada. Alustame ajaloost.
Minu tutvus DevOpsiga
Kunagi töötasin ma Citi Groupis pilveteenuste kallal ja arendasin IaaSi veebirakendust, et hallata Citi pilvainfrastruktuuri, kuid mind on alati huvitanud, kuidas arendusprotsessi optimeerida ja arendajate seas kultuuri parandada. Meie pilvearhitektuuri ja infrastruktuuri tehnilise direktori Greg Lavenderi soovitusel lugesin ma raamatut . Raamat selgitab DevOpsi põhimõtteid suurepäraselt ja loetav nagu romaan.
Tabeli tagaküljel on näidatud, kui tihti ettevõtted uusi versioone välja annavad:
Kuidas saavad Amazon, Google ja Netflix nii palju uusi versioone välja anda? Kõik on lihtne: nad mõistsid, kuidas luua peaaegu ideaalne DevOpsi ahel.
Meie Citi-s oli kõik täiesti teisiti, kuni me DevOpsile üle läksime. Siis olid mu meeskonnal erinevad keskkonnad, kuid arendusserverisse toimetamine toimus käsitsi. Kõigil arendajatel oli juurdepääs ainult ühele IBM WebSphere Application Server Community Editioni arendusserverile. Kui kõik proovisid samal ajal toimetada, „langes” server ja meil tuli iga kord „valusalt” omavahel kokku leppida. Lisaks oli meil koodikatte testidega ebapiisav, töömahukas käsitsi toimetamisprotsess ja puudusid võimalused koodi toimetamist jälgida mõne ülesande või kliendi nõude alusel.
Oli selge, et midagi tuleb kiiresti ette võtta, ja leidsin kolleegi, kellel oli sama mõtteviis. Otsustasime koos luua esimese DevOpsi ahela — tema seadistas virtuaalmasina ja Tomcat serveri, mina lõin Jenkinsit, integreerisin Atlassian Jira ja BitBucket ning tegelesin koodi katmise testimisega. Projekt oli edukas: automatiseerisime täielikult arendusprotsessi ahela, saavutasime peaaegu 100% katkematu arendusserveri töö, suutsime jälgida ja parandada koodi katmist testidega ning Git haru sai siduda toimetamise ja Jira ülesandega. Peaaegu kõik tööriistad, millega DevOpsi ahelat ehitasime, olid avatud lähtekoodiga.
Tegelikult oli ahel lihtsustatud, kuna me ei kasutanud isegi laienenud konfiguratsioone Jenkins'i või Ansible'i abil. Aga meil õnnestus see. Võib-olla on see põhimõtte tulem. (ka 80/20 reegel).
DevOpsi ja CI/CD ahela lühike ülevaade
DevOpsil on erinevad määratlused. DevOps hõlmab nagu Agile erinevaid distsipliine. Kuid enamik nõustuks järgmise määratlusega: DevOps on meetod või tarkvaraarenduse elutsükkel, mille peamine põhimõte on kultuuri loomine, kus arendajad ja teised töötajad on "ühel lainel", käsitsi töö on automatiseeritud, igaüks tegeleb sellega, mis tal kõige paremini välja tuleb, suurendatakse tarnete sagedust, tõstetakse töö produktiivsust ja suureneb paindlikkus.
Ja kuigi ainuüksi tööriistadest ei piisa DevOps'i keskkonna loomiseks, on neid hädavajalik. Kõige tähtsam neist on pidev integreerimine ja pidev kohaletoimetamine (CI/CD). Igas keskkonnas on ahelas erinevad etapid (näiteks DEV (arendus), INT (integreerimine), TST (testimine), QA (kvaliteedikontroll), UAT (kasutajakontroll), STG (ettevalmistus), PROD (kasutamine)), käsitsi ülesanded on automatiseeritud, arendajad saavad luua kvaliteetset koodi, tarnida seda ja saavad kergesti ümber ehitada.
See märkus kirjeldab, kuidas viie sammuga luua DevOps'i ahel, nagu on näidatud alloleval pildil, kasutades avatud lähtekoodiga tööriistu.
Liigume asja juurde.
Samm 1: CI/CD platvorm
Esmalt vajate CI/CD tööriista. Jenkins on avatud lähtekoodiga CI/CD tööriist, mis on kirjutatud Java's ja millel on MIT litsents, kust sai alguse DevOps'i liikumise populariseerimine ja mis on de facto CICD standardiks.
Mis on Jenkins? Kujutage ette, et teil on maagiline juhtpult erinevate teenuste ja tööriistade jaoks. CI/CD tööriist nagu Jenkins iseenesest on kasutu, kuid erinevate tööriistade ja teenustega muutub see kõikvõimsaks.
Lisaks Jenkins'ile on palju teisi avatud lähtekoodiga tööriistu, valige ükskõik milline.
Nii näeb välja DevOps'i protsess CI/CD tööriistaga
Teie localhost'is on CI/CD tööriist, kuid veel pole midagi teha. Liigume järgmise sammu juurde.
Samm 2: versioonihalduse süsteem
Parim (ja ilmselt kõige lihtsam) viis CI/CD tööriista maagia kontrollimiseks on integreerida see versioonihalduse tööriistaga (source control management, SCM). Miks on versioonihaldus vajalik? Oletame, et teete rakendust. Kirjutate selle Java, Python, C++, Go, Ruby, JavaScripti või mõnes muus keeles, millest on tõeliselt palju. Seda, mida te kirjutate, nimetatakse lähtekoodiks. Alguses, eriti kui töötate üksi, saate kõik salvestada kohalikku katalooge. Kuid kui projekt kasvab ja üha rohkem inimesi liitub, vajate viisi, kuidas jagada koodimuudatusi, vältides samas konfliktide tekkimist muudatuste liitmisel. Ja teil on ka vaja eelnevaid versioone taastada ilma varukoopiateta ja faili koodi kopeerimise ja kleepimise meetodit rakendamata.
Selles osas ei saa SCM'ist mööda. SCM salvestab koodi hoidlates, haldab selle versioone ja koordineerib seda arendajate vahel.
SCM tööriistu on palju, kuid de facto standardiks on õigustatult saanud Git. Soovitan kasutada just seda, kuid olemas on ka teisi variante.
Nii näeb välja DevOpsi torustik pärast SCM-i lisamist.
CI/CD tööriista abil saab automatiseerida lähtekoodi laadimist ja väljalaadimist ning meeskonnas koostööd. Pole paha? Kuid kuidas muuta see nüüd rakenduseks, mis on miljardite kasutajate lemmik?
Samm 3: kogumise automatiseerimise tööriist
Kõik sujub nagu peab. Saate koodi välja laadida ja muudatused versioonihaldussüsteemis fikseerida, samuti võite kutsuda sõpru teiega koostööd tegema. Kuid teil pole veel rakendust. Et see oleks veebirakendus, tuleb see kompileerida ja pakendada tarneks või käivitada täidetava failina. (Interpretatiivset programmeerimiskeelt, nagu JavaScript või PHP, ei ole vaja kompileerida.)
Kasutage kogumise automatiseerimise tööriista. Olenemata valitud tööriistast kogub see koodi soovitud formaadis ja automatiseerib puhastamise, kompileerimise, testimise ja tarnimise. Kogumise tööriistade valik sõltub keelest, kuid tavaliselt kasutatakse järgmisi avatud koodiga variante.
Suurepärane! Nüüd lisame kogumise automatiseerimise tööriista konfiguratsioonifailid versioonihaldussüsteemi, et CI/CD tööriist need kokku paneks.
Tundub, et kõik on korras. Kuid kuhu nüüd kõik see välja lasta?
Samm 4: veebirakenduse server
Niisiis, teil on pakitud fail, mida saab käivitada või välja lasta. Et rakendus tõeliselt kasu tooks, peab sellel olema teenus või liides, kuid peate selle kuskile paigutama.
Veebirakendust saab paigutada veebirakenduste serverisse. Rakenduste server pakub keskkonda, kus saab käivitada paketi programmiloogika, teostada liidese renderdamist ja avada veebiteenuseid soketi kaudu. Te vajate HTTP-serverit ja mitmeid teisi keskkondi (nt virtuaalmasinat), et rakenduste server paika panna. Seni kujutame ette, et te valdava nende asjadega (kuigi ma räägin allpool konteineritest).
On mitmeid avatud veebirakenduste servereid.
Meil on juba peaaegu töötav DevOpsi ahel. Suurepärane töö!
Põhimõtteliselt võiks siinkohal peatuda, edasi saate ise hakkama, kuid tasub rääkida ka koodi kvaliteedist.
Samm 5: Testimise katvus
Testimine on aeganõiav ja vaevarikas, kuid parem on vead kohe üles leida ja koodi parandada, et lõppkasutajaid rõõmustada. Selleks on palju avatud tööriistu, mis mitte ainult ei testi koodi, vaid annavad ka soovitusi, kuidas seda parandada. Enamik CI/CD tööriistu saavad nende tööriistadega integreeruda ja protsessi automatiseerida.
Testimine jaguneb kaheks osaks: testimisraamistikud, et kirjutada ja teha teste, ning tööriistad koodi kvaliteedi parandamise soovituste jaoks.
Testimisraamistikud
Kvaliteedi näpunäidete tööriistad
Enamik neist tööriistadest ja raamistikest on kirjutatud Java, Python ja JavaScripti jaoks, kuna C++ ja C# on omandiõigusega (kuigi GCC-l on avatud lähtekood).
Kasutame katvuse tööriistu ja nüüd peaks DevOpsi töövoog välja nägema nagu juhendi alguses olevas joonises.
Täiendavad sammud
Konteinerid
Nagu ma juba ütlesin, saab rakenduste serverit paigutada virtuaalmasinasse või serverisse, kuid konteinerid on populaarsemad.
? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
Konteinerite jaoks kasutatakse tavaliselt Dockerit ja Kuberneteset, kuigi on ka teisi võimalusi.
Lugege artikleid Dockerist ja Kubernetesest aadressil :
Vahekihiautomatisatsiooni tööriistad
Meie DevOps ahel on suunatud rakenduse koostöisele koostamisele ja tarnimisele, kuid DevOps tööriistadega on võimalik teha ka palju muid huvitavaid asju. Näiteks saab kasutada tööriistu, mida tuntakse kui "infrastruktuur kui kood" (IaC), mis on samuti tuntud kui vahekihitöötluse automatiseerimise tööriistad. Need tööriistad aitavad automatiseerida vahekihtide installatsiooni, haldamist ja muid ülesandeid. Näiteks võib automatiseerimistööriist võtta rakendusi (veebirakenduse server, andmebaas, jälgimistööriistad) koos õige konfiguratsiooniga ja väljastada need rakenduste serverisse.
Siin on mõned avatud vahekihtide automatiseerimise tööriistade valikud:
Lisainfot leiate artiklitest :
Ja mis nüüd?
See on vaid jäämäe tipp. DevOps ahel suudab palju enamat. Alustage CI/CD tööriistaga ja uurige, mida veel saab automatiseerida, et enda tööd lihtsustada. Ära unusta efektiivseks koostööks.
Siin on veel mõned head artiklid DevOpsi kohta algajatele:
Ja veel on võimalik integreerida DevOps avatud tööriistadega agiilseks:
Allikas: habr.com
