Esimese DevOpsi ahela loomine viies sammus algajatele.
DevOps on muutunud lahenduseks liiga aeglastele, killustatud ja muudele murettekitavatele arendusprotsessidele. Kuid vajatakse minimaalset arusaamist DevOps-ist. Siin käsitletakse selliseid mõisteid nagu DevOpsi ahel ja selle loomine viie sammu abil. See ei ole täielik juhend, vaid ainult „kala”, mida on võimalik laiendada. Alustame ajalooga.
Minu tutvus DevOps-iga
Kuna töötasin kunagi Citi Groupis pilveteenuste vallas ja arendasin IaaS veebirakendust, et hallata Citi pilveinfrastruktuuri, oli mul alati huvi leida viise arendusprotsessi optimeerimiseks ja arendajate vahelise kultuuri parandamiseks. Meie tehnoloogia direktor, Greg Lavender, soovitas mulle raamatut . See selgitab suurepäraselt DevOpsi põhimõtteid ning lugemine on kui romaan.
Tabeli tagaküljel on näidatud, kui sageli ettevõtted uusi versioone väljastavad:
Kuidas Amazon, Google ja Netflix suudavad nii palju versioone väljastada? Kõik on lihtne: nad on aru saanud, kuidas luua peaaegu ideaalne DevOpsi ahel.
Citi-s oli kõik hoopis teistsugune, kuni me DevOps'i peale üle läksime. Sel ajal oli minu meeskonnal erinevad keskkonnad, kuid arendusse serverisse toimestamine toimus käsitsi. Kõigil arendajatel oli juurdepääs ainult ühele IBM WebSphere Application Server Community Edition'i baasil olevatele arendusserverile. Kui kõik püüdsid samal ajal toimetada, „kukutas” server ja pidime iga kord „valusalt” omavahel kokkuleppele jõudma. Lisaks puudus meil piisav testikattete katmine, töömahukas käsitsi toimetamise protsess ja ei olnud võimalust jälgida koodi toimetamist teatud ülesande või kliendi nõude järgi.
Olukord oli selge, et midagi tuleb kiiresti ette võtta, ja ma leidsin kolleegi, kes jagas mu mõtteid. Otsustasime koos luua esimese DevOps ahela — tema seadis üles virtuaalse masina ja Tomcat rakendusserveri, samas kui mina keskendusin Jenkinsile, integreerimisele Atlassian Jira ja BitBucketiga ning koodi katmise testimisele. Projekt osutus edukaks: me automatiseerisime täielikult arendusahela, saavutasime peaaegu 100% töökindluse arendusseerveris, suutsime jälgida ja parandada koodi katmist testidega ning Git haru sai siduda tarnimise ja Jira ülesandega. Ja peaaegu kõik tööriistad, millega me DevOps ahela ehitasime, olid avatud lähtekoodiga.
Tegelikult oli ahel lihtsustatud, kuna me ei kasutanud isegi ulatuslikke konfiguratsioone Jenkinsis või Ansible'is. Kuid meil läks kõik korda. Võib-olla on see tagajärg põhimõttele (tuntud ka kui 80/20 reegel).
Lühike ülevaade DevOps ahelast ja CI/CD-st
DevOps'il on erinevaid määratlusi. Nagu Agile, hõlmab DevOps ka erinevaid distsipliine. Siiski nõustuvad enamik inimesi järgmise määratlemisega: DevOps on meetod või tarkvaraarenduse elutsükkel, mille peamine põhimõte on luua kultuur, kus arendajad ja teised töötajad on "ühel lainel", käsitsi töö on automatiseeritud, igaüks tegeleb sellega, milles ta on parim, tarnete sagedus suureneb, töö tootlikkus kasvab ning paindlikkus suureneb.
Kuigi pelgalt tööriistadest ei piisa DevOps'i keskkonna loomiseks, on need hädavajalikud. Kõige olulisem neist on pidev integreerimine ja pidev tarnimine (CI/CD). Iga keskkonna tarneprotsessis on erinevad etapid (näiteks DEV (arendus), INT (integreerimine), TST (testimine), QA (kvaliteedikontroll), UAT (kasutajate vastuvõtutestimine), STG (ettevalmistus), PROD (kasutamine)), käsitsi ülesanded on automatiseeritud, arendajad saavad kirjutada kvaliteetset koodi, teevad selle tarnimise ja saavad lihtsalt ümber ehitada.
See note describes how to create a DevOps chain in five steps, as shown in the picture below, using open-source tools.
Let’s get to the point.
Step 1: CI/CD Platform
First, you need a CI/CD tool. Jenkins is an open-source CI/CD tool written in Java under the MIT license, which initiated the popularization of the DevOps movement and has become the de facto standard for CI/CD.
So, what is Jenkins? Imagine having a magic remote control for various services and tools. The CI/CD tool itself, like Jenkins, is useless, but when combined with different tools and services, it becomes all-powerful.
Besides Jenkins, there are many other open-source tools; choose any.
Here’s how the DevOps process looks with a CI/CD tool.
You have a CI/CD tool on localhost, but there's not much to do yet. Let's move to the next step.
Step 2: Version Control
Parim ja arvatavasti kõige lihtsam viis CI/CD tööriista võlu testimiseks on selle integreerimine versioonihaldustööriistaga (source control management, SCM). Miks on versioonihaldus vajalik? Kujutage ette, et loote rakendust. Te kirjutate seda Java, Python, C++, Go, Ruby, JavaScriptis või mõnes muus keeles, millel on palju variante. Seda, mida te kirjutate, nimetatakse allikakoodiks. Alguses, eriti kui töötate üksi, saate kõik salvestada kohalikku kataloogi. Kuid kui projekt kasvab ja rohkem inimesi liitub, vajate viisi, kuidas jagada koodimuudatusi, vältides samas muudatuste ühinemise konflikte. Ja teil on vaja ka mingit viisi varasemate versioonide taastamiseks ilma varukoopiateta ja faile käsitsi kopeerimata.
Ja siinkohal ei saa SCM-st üle ega ümber. SCM säilitab 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, kuigi olemas on ka teisi variante.
Nii näeb välja DevOps pipeline pärast SCM-i lisamist.
CI/CD tööriist võib automatiseerida lähtekoodi üleslaadimise ja allalaadimise ning meeskonnatöö. Pole paha? Aga kuidas nüüd selle pealt töötav rakendus luua, mis on miljardite kasutajate lemmik?
Samm 3: ehituse automatiseerimise tööriist
Kõik läheb nagu peab. Saate koodi allalaadida ja muudatusi versioonihaldussüsteemis registreerida ning kutsuda sõpru koos töötama. Kuid rakendust teil veel pole. Et sellest veebirakendus saada, tuleb see kompileerida ja pakkida tarnimiseks või käivitada täitmisfailina. (Tõlgitavat programmeerimiskeelt, nagu JavaScript või PHP, ei pea kompileerima.)
Kasutage ehituse automatiseerimise tööriista. Ükskõik, millist tööriista te valite, kogub see koodi vajaliku vormingusse ja automatiseerib puhastamise, kompileerimise, testimise ja tarnimise. Ehitustööriistu on erinevaid, sõltuvalt keelest, kuid tavaliselt kasutatakse järgmisi avatud lähtekoodiga variante.
Suurepärane! Nüüd lisame ehituse automatiseerimise tööriista konfigureerimise failid versioonihaldussüsteemi, et CI/CD tööriist need kokku koguks.
Noh, kõik näib normaalne. Aga kuhu nüüd kõik see tõugata?
Samm 4: veebirakenduste server
Niisiis, teil on pakitud fail, mida saab kasutada või juurutada. Et rakendus tõeliselt kasulikuks osutuks, peab tal olema mingi teenus või liides, kuid peate selle kuskile paigutama.
Veebirakendust saab majutada veebirakenduste serveris. Rakenduste server loob keskkonna, kus saab täita paketi programmiloogikat, luua liidese joonistamise ja avada veebiteenuseid pordi kaudu. Teil on vaja HTTP-serverit ja mitmeid teisi keskkondi (näiteks virtuaalmasinat), et rakenduste server paigaldada. Praegu kujutame ette, et te olete kõik selle protsessi ajal rehkendanud (kuigi konteineritest räägin allpool).
On mitu avatud veebirakenduste serverit.
Meil on juba peaaegu toimiv DevOpsi ahel. Suurepärane töö!
Põhimõtteliselt saate siin peatuda, edasise osaga saate ise hakkama, kuid tasub veel rääkida koodi kvaliteedist.
Samm 5: Testimise katvus
Testimine võtab palju aega ja vaeva, kuid parem on kohe leida vead ja parandada koodi, et rahuldada lõppkasutajaid. Selle eesmärgiga on saadaval palju avatud tööriistu, mis mitte ainult ei testi koodi, vaid pakuvad ka soovitusi selle parendamiseks. Enamik CI/CD tööriistu saavad nende tööriistadega ühenduda ja automatiseerida protsessi.
Testimine on jagatud kaheks osaks: testimisraamistikeks, et kirjutada ja käivitada teste, ning tööriistadeks, mis annavad soovitusi koodi kvaliteedi tõstmiseks.
Testimisraamistikud
Kvaliteedi soovitustega tööriistad
Enamik neist tööriistadest ja raamistikest on kirjutatud Java, Python ja JavaScripti jaoks, kuna C++ ja C# on patenteeritud (kuigi GCC-l on avatud lähtekood).
Oleme rakendanud testikatte tööriistu ning nüüd peaks DevOpsi pipeline välja nägema nagu juhendi alguses oleval pildil.
Täiendavad sammud
Konteinerid
Kuidas ma juba ütlesin, saab rakendusserveri paigutada virtuaalmasinale või serverisse, kuid konteinerid on populaarsemad.
? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
Konteinerite jaoks kasutatakse tavaliselt Dockerit ja Kubernetes'i, kuigi ka teisi valikuid on.
Lugege artikleid Dockerist ja Kubernetesest saidil :
Vahekihtide automatiseerimise tööriistad
Meie DevOps ahel on suunatud rakenduste koostööle ja tarnimisele, kuid DevOps tööriistadega saab teha ka palju muud huvitavat. Näiteks kasutatakse tööriistu „infrastruktuur kui kood“ (IaC), mida nimetatakse ka vahekihtide automatiseerimise tööriistadeks. Need tööriistad aitavad automatiseerida installatsiooni, haldamist ja muid ülesandeid vahekihtide jaoks. Näiteks võib automatiseerimise tööriist võtta rakendusi (veebirakenduste server, andmebaas, jälgimistööriistad) õige konfiguratsiooniga ja jagada neid rakenduste serverisse.
Siin on mõned avatud vahekihtide automatiseerimise tööriistade variandid:
Lisainfot leiate artiklitest :
Ja mis nüüd?
See on alles jäämäe tipp. DevOps-ahel suudab palju rohkem. Alustage CI/CD tööriistast ja avastage, mida veel saaksite automatiseerida, et oma tööd lihtsustada. Ärge unustage efektiivseks koostööks.
Siin on veel mõned head artiklid DevOpsist alustamiseks:
Ja DevOpsi saab integreerida avatud tööriistadega agile'i jaoks:
Allikas: habr.com
