🥇 Mannekeenide juhend: DevOpsi torujuhtmete loomine avatud lähtekoodiga tööriistadega

Algajatele mõeldud esimese DevOpsi ahela loomine viie sammuga.

DevOpsist on saanud imerohi liiga aeglaste, lahtiühendatud ja muidu probleemsete arendusprotsesside jaoks. Kuid teil on DevOpsis vaja minimaalseid teadmisi. See hõlmab selliseid kontseptsioone nagu DevOpsi kett ja viis, kuidas seda luua. See ei ole täielik juhend, vaid ainult "kala", mida saab laiendada. Alustame ajaloost.

Minu tutvustus DevOpsiga

Varem töötasin Citi Groupis pilvedega ja arendasin Citi pilvetaristu haldamiseks IaaS-i veebirakendust, kuid mind on alati huvitanud, kuidas optimeerida arendusahelat ja parandada arendajate seas kultuuri. Meie pilvarhitektuuri ja -taristu tehnoloogiadirektor Greg Lavender soovitas mulle seda raamatut. Projekt "Phoenix". See selgitab kaunilt DevOpsi põhimõtteid ja loeb nagu romaan.

Tagaküljel olev tabel näitab, kui sageli ettevõtted uusi versioone välja lasevad:

Kuidas õnnestub Amazonil, Google'il ja Netflixil nii palju levitada? Ja see on lihtne: nad leidsid, kuidas luua peaaegu täiuslik DevOpsi kett.

Kuni DevOpsile üleminekuni olid Citi asjad meie jaoks väga erinevad. Siis olid minu meeskonnal erinevad keskkonnad, kuid arendusserverisse toimetasime käsitsi. Kõigil arendajatel oli juurdepääs ainult ühele IBM WebSphere Application Server Community Editionil põhinevale arendusserverile. Samaaegse toimetamise katsega server "kukkus" ja iga kord pidime "valulikult" omavahel läbi rääkima. Meil oli ka ebapiisav koodi katvus testidega, aeganõudev käsitsi edastamise protsess ja meil ei olnud mingit võimalust jälgida koodi edastamist mõne ülesande või kliendi nõude abil.

Oli selge, et midagi on kiiresti vaja ette võtta ja leidsin endale mõttekaaslase. Otsustasime koos luua esimese DevOpsi keti – tema seadistas virtuaalmasina ja Tomcati rakendusserveri ning mina hoolitsesin Jenkinsi, Atlassian Jira ja BitBucketiga integreerimise ning ka koodide katmise eest testidega. Projekt oli edukas: automatiseerisime arendusahela täielikult, saavutasime arendusserveris peaaegu 100% tööaja, saime jälgida ja testidega koodi katvust parandada ning Giti haru sai siduda Jira tarne ja väljastamisega. Ja peaaegu kõik tööriistad, mida kasutasime DevOpsi keti koostamiseks, olid avatud lähtekoodiga.

Tegelikult oli kett lihtsustatud, sest me ei rakendanud isegi Jenkinsi või Ansible'i abil täpsemaid konfiguratsioone. Aga meil õnnestus. Võib-olla on see põhimõtte tagajärg Pareto (teise nimega 80/20 reegel).

DevOpsi ja CI/CD ahela lühikirjeldus

DevOpsil on erinevad määratlused. DevOps, nagu ka Agile, sisaldab erinevaid erialasid. Kuid enamik nõustub järgmise definitsiooniga: DevOps on tarkvaraarenduse meetod või elutsükkel, mille põhiprintsiip on luua kultuur, kus arendajad ja teised töötajad on "samal lainepikkusel", käsitsitöö on automatiseeritud, igaüks teeb seda, mida oskab, tarnete sagedus suureneb, töö produktiivsus suureneb, paindlikkus suureneb.

Kuigi tööriistadest üksi DevOpsi keskkonna loomiseks ei piisa, on need asendamatud. Kõige olulisem neist on pidev integreerimine ja pidev tarnimine (CI/CD). Iga keskkonna jaoks on ahelas erinevad etapid (nt DEV (arendus), INT (integreerimine), TST (testimine), QA (kvaliteedi tagamine), UAT (kasutaja aktsepteerimise testimine), STG (ettevalmistus), PROD (kasutus)) , käsitsi toimingud on automatiseeritud, arendajad saavad kvaliteetset koodi koostada, selle kohale toimetada ja hõlpsasti ümber ehitada.

See märkus kirjeldab, kuidas luua DevOpsi kett viies etapis, nagu on näidatud alloleval pildil, kasutades avatud lähtekoodiga tööriistu.

Asume asja kallale.

1. samm: CI/CD platvorm

Kõigepealt vajate CI/CD tööriista. Jenkins on MIT-i litsentsiga avatud lähtekoodiga CI/CD tööriist, mis on kirjutatud Java keeles, mis populariseeris DevOpsi liikumist ja millest on saanud CICD de facto standard.

Mis on Jenkins? Kujutage ette, et teil on maagiline juhtpaneel mitmesuguste teenuste ja tööriistade jaoks. Ainuüksi selline CI/CD tööriist nagu Jenkins on kasutu, kuid erinevate tööriistade ja teenustega muutub see kõikvõimsaks.

Lisaks Jenkinsile on palju muid avatud lähtekoodiga tööriistu, valige ükskõik milline.

Siit saate teada, kuidas DevOpsi protsess CI/CD tööriistaga välja näeb

Sul on localhostis CI/CD tööriist, kuid teha pole veel palju. Liigume edasi järgmise sammu juurde.

2. samm: versioonide loomine

Parim (ja vaieldamatult lihtsaim) viis CI/CD tööriista võlu testimiseks on selle integreerimine allika juhtimise (SCM) tööriistaga. Miks on vaja versioonikontrolli? Oletame, et esitate avalduse. Kirjutate selle Java, Python, C++, Go, Ruby, JavaScripti või mõnes muus keeles, mis on vagun ja väike käru. Seda, mida sa kirjutad, nimetatakse lähtekoodiks. Alguses, eriti kui töötate üksi, saate kõik salvestada kohalikku kataloogi. Kuid projekti kasvades ja rohkem inimesi liitudes on teil vaja viisi koodimuudatuste jagamiseks, kuid muudatuste liitmisel konfliktide vältimiseks. Samuti peate kuidagi taastama varasemad versioonid ilma varukoopiaid kasutamata ja koodifailide jaoks kopeerimis-kleebi meetodit kasutamata.

Ja siin ilma SCM-ita kuskil. SCM salvestab koodi hoidlates, haldab selle versioone ja koordineerib seda arendajate vahel.

SCM-i tööriistu on palju, kuid Gitist on teenitult saanud de facto standard. Soovitan teil seda kasutada, kuid on ka teisi võimalusi.

Nii näeb DevOpsi torujuhe pärast SCM-i lisamist välja.

CI/CD tööriist võib automatiseerida lähtekoodi üles- ja allalaadimist ning meeskonna koostööd. Pole paha? Aga kuidas teha sellest miljardite kasutajate poolt armastatud rakendus?

3. samm: looge automatiseerimistööriist

Kõik läheb nii nagu peab. Saate koodi üles laadida ja allika juhtimises muudatusi teha ning sõpru endaga koostööd tegema kutsuda. Kuid teil pole veel rakendust. Selleks, et see oleks veebirakendus, tuleb see levitamiseks kompileerida ja pakendada või käivitada käivitatava failina. (Tõlgendatud programmeerimiskeelt, nagu JavaScript või PHP, ei ole vaja kompileerida.)

Kasutage ehitamise automatiseerimise tööriista. Ükskõik millise tööriista valite, koostab see koodi õiges vormingus ning automatiseerib puhastamise, kompileerimise, testimise ja kohaletoimetamise. Koostamistööriistad on keeleti erinevad, kuid tavaliselt kasutatakse järgmisi avatud lähtekoodiga valikuid.

Täiuslik! Nüüd sisestame koostamise automatiseerimise tööriista konfiguratsioonifailid allika juhtimisse, nii et CI/CD tööriist loob need.

See on hea tunne. Aga kuhu see kõik nüüd välja tuleb?

4. samm: veebirakenduste server

Seega on teil pakitud fail, mida saab käivitada või välja panna. Selleks, et rakendus oleks tõesti kasulik, peab sellel olema mingi teenus või liides, kuid peate selle kõik kuhugi paigutama.

Veebirakendust saab majutada veebirakenduste serveris. Rakendusserver pakub keskkonda, kus saate pesa kaudu käivitada pakitud loogikat, renderdada liideseid ja paljastada veebiteenuseid. Rakendusserveri installimiseks vajate HTTP-serverit ja mõnda muud keskkonda (näiteks virtuaalmasinat). Praegu kujutame ette, et tegelete selle kõigega edasi (kuigi ma räägin allpool konteineritest).

Avatud veebirakenduste serverid on mitu.

Meil on juba peaaegu töötav DevOpsi kett. Suurepärane töö!

Põhimõtteliselt võite siin peatuda, siis saate sellega ise hakkama, kuid tasub rääkida koodi kvaliteedist.

5. samm: testige katvust

Testimine võtab palju aega ja vaeva, kuid parem on vead kohe üles leida ja koodi täiustada, et lõppkasutajatele meeldida. Selleks on palju avatud tööriistu, mis mitte ainult ei testi koodi, vaid annavad nõu ka selle täiustamiseks. Enamik CI/CD tööriistu saab nende tööriistadega ühendada ja protsessi automatiseerida.

Testimine jaguneb kaheks osaks: testimisraamistikud testide kirjutamiseks ja täitmiseks ning vihjetega tööriistad koodi kvaliteedi parandamiseks.

Testimisraamistikud

Tööriistad kvaliteetsete näpunäidetega

Enamik neist tööriistadest ja raamistikest on kirjutatud Java, Pythoni ja JavaScripti jaoks, kuna C++ ja C# on patenteeritud (kuigi GCC on avatud lähtekoodiga).

Oleme rakendanud testkatte tööriistad ja nüüd peaks DevOpsi torujuhe välja nägema nagu õpetuse alguses oleval pildil.

Täiendavad sammud

Konteinerid

Nagu ma varem ütlesin, saab rakendusserverit majutada virtuaalmasinas või serveris, kuid konteinerid on populaarsemad.

Mis on konteinerid? Lühidalt, virtuaalses masinas võtab operatsioonisüsteem sageli rohkem ruumi kui rakendus ning tavaliselt piisab mõne teegi ja konfiguratsiooniga konteinerist. Mõnel juhul on virtuaalmasinad asendamatud, kuid konteiner mahutab rakenduse koos serveriga ilma lisatasuta.

Konteinerite jaoks võetakse tavaliselt Docker ja Kubernetes, kuigi on ka muid võimalusi.

Lugege artikleid Dockeri ja Kubernetese kohta aadressil opensource.com:

Vahevara automatiseerimise tööriistad

Meie DevOpsi kett on keskendunud koostööl põhinevale rakenduse loomisele ja tarnimisele, kuid DevOpsi tööriistadega saate teha ka muid huvitavaid asju. Näiteks kasutage Infrastructure as Code (IaC) tööriistu, mida tuntakse ka vahevara automatiseerimise tööriistadena. Need tööriistad aitavad automatiseerida vahevara installimist, haldamist ja muid ülesandeid. Näiteks võib automatiseerimistööriist võtta õigete konfiguratsioonidega rakendused (veebirakendusserver, andmebaas, jälgimistööriistad) ja lükata need rakendusserverisse.

Siin on mõned avatud vahevara automatiseerimistööriistade võimalused.

Üksikasjad artiklites opensource.com:

Ja nüüd, mis?

See on vaid jäämäe tipp. DevOpsi kett suudab palju enamat. Alustage CI/CD tööriistaga ja vaadake, mida veel saate oma töö hõlbustamiseks automatiseerida. Ärge unustage avatud suhtlusvahendid tõhusaks koostööks.

Siin on veel mõned head DevOpsi artiklid algajatele:

DevOpsi saate integreerida ka avatud agiilsete tööriistadega:

Allikas: www.habr.com