Ustvarjanje prve DevOps verige v petih korakih za začetnike.
DevOps je postal rešitev za prepočasen, razdrobljen in mnoge druge problematične razvojne procese. Vendar so potrebne osnovne informacije o DevOps. Opravljena bo razlaga pojmov, kot so DevOps veriga in kako jo ustvariti v petih korakih. To ni popoln vodnik, temveč le 'riba', ki jo lahko razširimo. Začnimo s zgodovino.
Moje srečanje z DevOps
Nekoč sem delal z oblačnimi rešitvami v Citi Group in razvijal IaaS spletno aplikacijo za upravljanje oblačne infrastrukture Citi, vendar me je vedno zanimalo, kako optimizirati razvojno verigo in izboljšati kulturo med razvijalci. Greg Lavender, naš tehnični direktor za oblačno arhitekturo in infrastrukturo, mi je priporočil knjigo . Odlično pojasnjuje načela DevOps, branje pa je kot roman.
V tabeli na zadnji strani je prikazano, kako pogosto podjetja sproščajo nove različice:
Kako Amazon, Google in Netflix uspejo tako pogosto sproščati? Vse je preprosto: spoznali so, kako ustvariti skoraj popolno DevOps verigo.
Pri nas v Citi je bilo vse povsem drugače, dokler se nismo preusmerili na DevOps. Takrat je imela moja ekipa različna okolja, a dobava na razvojni strežnik je potekala ročno. Vsi razvijalci so imeli dostop le do enega razvojnega strežnika, ki je temeljil na IBM WebSphere Application Server Community Edition. Ob poskusu hkratne dobave je strežnik 'padel', nato smo se morali vsakič 'težko' dogovoriti. Imeli smo tudi nezadostno testno pokritost kode, zamuden ročni proces dobave in nobeno možnost sledenja dobavi kode za določeno nalogo ali zahtevo stranke.
Bilo je jasno, da je potrebno hitro ukrepati, in našel sem kolega, ki se je strinjal z mano. Odločila sva se, da skupaj ustvariva prvo DevOps verigo - on je nastavil virtualni stroj in strežnik aplikacij Tomcat, jaz pa sem se ukvarjal z Jenkinsom, integracijo z Atlassian Jiro in BitBucket, kot tudi s testno pokritostjo kode. Projekt je bil uspešen: popolnoma smo avtomatizirali razvojno verigo, dosegli skoraj 100% neprekinjeno delovanje razvojnega strežnika, lahko smo spremljali in izboljšali testno pokritost kode, ter povezali Git vejo z dobavo in nalogo Jira. In skoraj vsi orodja, ki smo jih uporabili za izgradnjo DevOps verige, so bili odprtokodna.
V resnici je bil postopek poenostavljen, saj nismo uporabljali zapletenih konfiguracij s pomočjo Jenkins ali Ansible. Vseeno nam je uspelo. Morda je to posledica načela (tudi pravilo 80/20).
Kratka predstavitev DevOps in CI/CD procesa
DevOps ima različne definicije. Podobno kot Agile vključuje različne discipline. Večina se bo strinjala s to definicijo: DevOps je metoda oziroma življenjski cikel razvoja programske opreme, katerega glavno načelo je ustvarjanje kulture, v kateri so razvijalci in drugi zaposleni 'na isti valovni dolžini', je ročno delo avtomatizirano, vsak se ukvarja s tistim, kar najbolje obvlada, povečuje se pogostost dobav, večja je produktivnost dela in povečuje se prilagodljivost.
Čeprav orodja sama po sebi niso dovolj za ustvarjanje DevOps okolja, so nujna. Najpomembnejše med njimi sta neprekinjena integracija in neprekinjena dostava (CI/CD). V verigi za vsako okolje obstajajo različne faze (na primer, DEV (razvoj), INT (integracija), TST (testiranje), QA (nadzor kakovosti), UAT (sprejemno testiranje uporabnikov), STG (priprava), PROD (uporaba)), ročne naloge so avtomatizirane, razvijalci lahko pišejo kakovostno kodo, zagotavljajo jo in se enostavno prilagajajo.
Ta opomba opisuje, kako v petih korakih ustvariti DevOps verigo, kot je prikazano na spodnji sliki, s pomočjo orodij z odprtokodnim kodom.
Pojdimo k stvari.
Korak 1: CI/CD platforma
Najprej potrebujete orodje CI/CD. Jenkins je odprtokodno orodje CI/CD, napisano v Javi, s MIT licenco, ki je pripomoglo k popularizaciji gibanja DevOps in je de facto postalo standard za CI/CD.
Kaj je Jenkins? Predstavljajte si, da imate čarobni nadzornik za različne storitve in orodja. Samo orodje CI/CD, kot je Jenkins, je brez pomoči orodij in storitev neuporabno, a z njimi postane vsemogočno.
Poleg Jenkinsa obstaja še veliko drugih odprtokodnih orodij, izberite katerokoli.
Tako izgleda DevOps postopek z orodjem CI/CD
Na vašem localhostu imate orodje CI/CD, vendar zaenkrat ni prav veliko, kar bi lahko počeli. Pojdimo na naslednji korak.
Korak 2: upravljanje različic
Najbolji (i, verovatno, najjednostavniji) način za proveru magije CI/CD alata je integrisati ga s alatom za upravljanje verzijama (source control management, SCM). Zašto je potrebno upravljanje verzijama? Recimo da pravite aplikaciju. Pišete je u Javi, Pythonu, C++, Go, Ruby, JavaScriptu ili bilo kojem drugom jeziku, kojih ima na pretek. Ono što pišete zove se izvorni kod. U početku, posebno ako radite sami, možete sve sačuvati u lokalnom direktorijumu. Ali kada projekat poraste i pridruži mu se više ljudi, potreban vam je način da delite promene u kodu, a da pritom izbegnete konflikte prilikom spajanja izmena. Takođe, morate imati način da vraćate prethodne verzije bez korišćenja rezervnih kopija i primene metode copy-paste za fajlove sa kodom.
I tu je SCM neophodan. SCM čuva kod u repozitorijumima, upravlja njegovim verzijama i usklađuje ga među programerima.
Alata za SCM ima mnogo, ali de facto standard postao je Git. Preporučujem njegovu upotrebu, ali postoje i druge opcije.
Ovako izgleda DevOps pipeline nakon dodavanja SCM-a.
CI/CD alat može automatizovati učitavanje i preuzimanje izvornog koda i zajednički rad u timu. Dobro, zar ne? Ali kako sada od ovoga napraviti funkcionalnu aplikaciju koju vole milijarde korisnika?
Korak 3: alat za automatizaciju izgradnje
Sve ide kako treba. Možete preuzimati kod i evidentirati promene u sistemu kontrole verzija, kao i pozvati prijatelje da rade s vama. Međutim, aplikacija još uvek nije tu. Da bi to bio veb-aplikacija, potrebno ju je kompajlirati i staviti u pakovanje za isporuku ili pokrenuti kao izvršni fajl. (Interpretisani programski jezici, kao što su JavaScript ili PHP, ne trebaju kompajliranje.)
Primena alata za automatizaciju izgradnje. Bez obzira koji alat odaberete, on će sastaviti kod u potrebnom formatu i automatizovati čišćenje, kompajliranje, testiranje i isporuku. Alati za izgradnju variraju u zavisnosti od jezika, ali obično se koriste sledeće opcije otvorenog koda.
Odlično! Sada ćemo u sistem kontrole verzija dodati konfiguracione fajlove alata za automatizaciju izgradnje, kako bi CI/CD alat mogao da ih prikupi.
Izgleda da je sve u redu. Ali gde da sve to sada postavite?
Korak 4: server veb-aplikacija
Torej, imete pakirano datoteko, ki jo je mogoče izvajati ali distribuirati. Da bi aplikacija resnično koristila, mora imeti neko storitev ali vmesnik, vendar jo morate nekje postaviti.
Spletno aplikacijo lahko postavite na strežnik spletnih aplikacij. Strežnik aplikacij zagotavlja okolje, kjer lahko izvajate programsko logiko iz paketa, upravljate z izrisom vmesnika in odpirate spletne storitve prek soketov. Potrebujete HTTP strežnik in nekaj drugih okolij (na primer virtualno napravo), da nastavite strežnik aplikacij. Zaenkrat domnevamo, da se s tem ukvarjate med postopkom (čeprav bom o kontejnerjih govoril kasneje).
Obstaja nekaj odprtih strežnikov spletnih aplikacij.
Skoraj imamo delujočo DevOps verigo. Odlično delo!
Na tem mestu se lahko ustavite, naprej se boste spoprijeli sami, vendar se splača še govoriti o kakovosti napisa.
Korak 5: Testna pokritost
Testiranje zahteva veliko časa in truda, vendar je bolje, da takoj odkrijete napake in izboljšate kodo, da razveselite končne uporabnike. Za ta namen obstaja veliko odprtih orodij, ki ne le testirajo kodo, temveč tudi ponujajo nasvete, kako jo izboljšati. Večina orodij CI/CD se lahko poveže s temi orodji in avtomatizira proces.
Testiranje je razdeljeno na dva dela: okviri za testiranje za pisanje in izvajanje testov ter orodja s nasveti za izboljšanje kakovosti kode.
Okviri za testiranje
Orodja s nasveti za kakovost
Večina teh orodij in okvirov je napisanih za Java, Python in JavaScript, ker sta C++ in C# proprietary (kljub temu, da je GCC odprtokodni).
Uporabljena orodja za testno pokritost in zdaj bi moral DevOps pipeline izgledati, kot je na sliki na začetku priročnika.
Dodatni koraki
Kontejnerji
Kot sem že omenil, je strežnik aplikacij mogoče postaviti na virtualno napravo ali strežnik, vendar so kontejnerji bolj priljubljeni.
? Вкратце, в виртуальной машине операционная система чаще всего занимает больше места, чем приложение, а контейнеру обычно достаточно нескольких библиотек и конфигурации. В некоторых случаях без виртуальных машин не обойтись, но контейнер вмещает приложение вместе с сервером без лишних затрат.
Za kontejnerje običajno uporabljamo Docker in Kubernetes, čeprav obstajajo tudi druge možnosti.
Preberite članke o Dockerju in Kubernetesu na :
Orodja za avtomatizacijo vmesnika
Naša DevOps veriga je usmerjena na sodelovanje pri gradnji in dobavi aplikacij, vendar lahko z DevOps orodji počnete še veliko drugih zanimivih stvari. Na primer, uporabite orodja „infrastruktura kot koda“ (IaC), ki jih imenujemo tudi orodja za avtomatizacijo vmesnega programske opreme. Ta orodja pomagajo avtomatizirati namestitev, upravljanje in druge naloge za vmesno programsko opremo. Na primer, orodje za avtomatizacijo lahko vzame aplikacije (strežnik aplikacij, podatkovna baza, orodja za spremljanje) s pravimi konfiguracijami in jih razporedi na strežnik aplikacij.
Tukaj je nekaj odprtokodnih orodij za avtomatizacijo vmesnega programske opreme:
Podrobnosti v člankih na :
In kaj zdaj?
To je le vrh ledene gore. DevOps veriga lahko veliko več. Začnite z orodjem CI/CD in ugotovite, kaj še lahko avtomatizirate, da si olajšate delo. Ne pozabite na za učinkovito sodelovanje.
Tukaj je še nekaj dobrih člankov o DevOps za začetnike:
In DevOps lahko integrirate z odprtokodnimi orodji za agilno metodologijo:
Izvor: habr.com
