Ensimmäisen DevOps-ketjun rakentaminen viidessä vaiheessa aloittelijoille.
DevOpsista on tullut ihmelääke liian hitaille, katkeamattomille ja muuten ongelmallisille kehitysprosesseille. Mutta tarvitset vain vähän tietoa DevOpsista. Se kattaa konseptit, kuten DevOps-ketjun ja kuinka luoda yksi viidestä vaiheesta. Tämä ei ole täydellinen opas, vaan vain "kala", jota voidaan laajentaa. Aloitetaan historiasta.
Esittelyni DevOpsiin
Työskentelin aiemmin Pilvien parissa Citi Groupissa ja kehitin IaaS-verkkosovellusta Citin pilviinfrastruktuurin hallintaan, mutta olen aina ollut kiinnostunut kehitysketjun optimoinnista ja kehittäjien kulttuurin parantamisesta. Greg Lavender, pilviarkkitehtuurin ja -infrastruktuurin teknologiajohtajamme, suositteli tätä kirjaa minulle. . Se selittää DevOps-periaatteet kauniisti ja lukee kuin romaani.
Takana oleva taulukko näyttää, kuinka usein yritykset julkaisevat uusia versioita:
Kuinka Amazon, Google ja Netflix onnistuvat levittämään niin paljon? Ja se on yksinkertaista: he keksivät, kuinka luoda melkein täydellinen DevOps-ketju.
Asiat olivat hyvin erilaisia meille Citissä, kunnes vaihdoimme DevOpsiin. Sitten tiimilläni oli erilaisia ympäristöjä, mutta teimme toimituksen kehityspalvelimelle manuaalisesti. Kaikilla kehittäjillä oli pääsy vain yhteen IBM WebSphere Application Server Community Editioniin perustuvaan kehityspalvelimeen. Samanaikaisessa toimitusyrityksessä palvelin "kaatui", ja joka kerta jouduimme "tuskallisesti" neuvottelemaan keskenämme. Meillä oli myös riittämätön koodikattavuus testeillä, aikaa vievä manuaalinen toimitusprosessi, eikä meillä ollut mahdollisuutta seurata koodin toimittamista jonkin tehtävän tai asiakkaan vaatimuksen avulla.
Oli selvää, että jotain oli tehtävä kiireesti, ja löysin samanhenkisen kollegan. Päätimme luoda ensimmäisen DevOps-ketjun yhdessä - hän perusti virtuaalikoneen ja Tomcat-sovelluspalvelimen, ja minä huolehdin Jenkinsistä, integroinnista Atlassian Jiran ja BitBucketin kanssa sekä koodin kattavuuden testeillä. Projekti onnistui: automatisoimme kehitysketjun täysin, saavutimme kehityspalvelimen lähes 100 % käytettävyyden, pystyimme valvomaan ja parantamaan koodin kattavuutta testeillä ja Git-haara voitiin yhdistää Jiran toimitukseen ja ongelmaan. Ja lähes kaikki työkalut, joita käytimme DevOps-ketjun rakentamiseen, olivat avoimen lähdekoodin.
Itse asiassa ketju yksinkertaistui, koska emme edes käyttäneet edistyneitä kokoonpanoja Jenkinsin tai Ansiblen avulla. Mutta onnistuimme. Ehkä tämä on seurausta periaatteesta (eli 80/20-sääntö).
Lyhyt kuvaus DevOpsista ja CI/CD-ketjusta
DevOpsilla on erilaisia määritelmiä. DevOps, kuten Agile, sisältää erilaisia tieteenaloja. Mutta useimmat ovat samaa mieltä seuraavan määritelmän kanssa: DevOps on ohjelmistokehityksen menetelmä tai elinkaari, jonka pääperiaate on luoda kulttuuri, jossa kehittäjät ja muut työntekijät ovat "samalla aaltopituudella", käsityö on automatisoitua, jokainen tekee mitä osaa parhaiten, toimitustiheys kasvaa, työn tuottavuus kasvaa, joustavuus lisääntyy.
Vaikka työkalut eivät yksin riitä luomaan DevOps-ympäristöä, ne ovat välttämättömiä. Näistä tärkein on jatkuva integrointi ja jatkuva toimitus (CI/CD). Ketjussa on eri vaiheita kullekin ympäristölle (esim. DEV (kehitys), INT (integrointi), TST (testaus), QA (laadunvarmistus), UAT (käyttäjien hyväksyntätestaus), STG (valmistelu), PROD (käyttö) , manuaaliset tehtävät ovat automatisoituja, kehittäjät voivat tuottaa laadukasta koodia, toimittaa sen ja rakentaa sen helposti uudelleen.
Tässä huomautuksessa kuvataan DevOps-ketjun luominen viidessä vaiheessa, kuten alla olevassa kuvassa näkyy avoimen lähdekoodin työkaluilla.
Ryhdytään hommiin.
Vaihe 1: CI/CD-alusta
Ensinnäkin tarvitset CI/CD-työkalun. Jenkins on MIT-lisensoitu, Java-kielellä kirjoitettu avoimen lähdekoodin CI/CD-työkalu, joka popularisoi DevOps-liikettä ja josta on tullut CICD:n tosiasiallinen standardi.
Mikä on Jenkins? Kuvittele, että sinulla on maaginen ohjauspaneeli erilaisille palveluille ja työkaluille. Pelkästään Jenkinsin kaltainen CI/CD-työkalu on hyödytön, mutta eri työkaluilla ja palveluilla siitä tulee kaikkivoipa.
Jenkinsin lisäksi on monia muita avoimen lähdekoodin työkaluja, valitse mikä tahansa.
Tältä DevOps-prosessi näyttää CI/CD-työkalulla
Sinulla on CI/CD-työkalu localhostissa, mutta tekemistä ei ole vielä paljon. Siirrytään seuraavaan vaiheeseen.
Vaihe 2: Versiointi
Paras (ja luultavasti helpoin) tapa testata CI/CD-työkalun taikuutta on integroida se SCM (Source Control Management) -työkaluun. Miksi tarvitset versionhallintaa? Oletetaan, että teet hakemuksen. Kirjoitat sen Java-, Python-, C++-, Go-, Ruby-, JavaScript- tai millä tahansa muulla kielellä, joka on vaunu ja pieni kärry. Mitä kirjoitat, kutsutaan lähdekoodiksi. Aluksi, varsinkin jos työskentelet yksin, voit tallentaa kaiken paikalliseen hakemistoon. Mutta kun projekti kasvaa ja siihen liittyy enemmän ihmisiä, tarvitset tavan jakaa koodimuutokset, mutta välttää ristiriidat muutosten yhdistämisessä. Ja sinun on myös palautettava jotenkin aiemmat versiot ilman varmuuskopioita ja kopioi-liitä-menetelmää kooditiedostoille.
Ja täällä ilman SCM:ää missään. SCM tallentaa koodin arkistoihin, hallitsee sen versioita ja koordinoi sitä kehittäjien kesken.
SCM-työkaluja on monia, mutta Gitistä on ansaitusti tullut de facto standardi. Suosittelen käyttämään sitä, mutta on muitakin vaihtoehtoja.
Tältä DevOps-putki näyttää SCM:n lisäämisen jälkeen.
CI/CD-työkalu voi automatisoida lähdekoodin lataamisen ja latauksen sekä tiimiyhteistyön. Ei paha? Mutta kuinka tehdä tästä toimiva sovellus, jota miljardit käyttäjät rakastavat?
Vaihe 3: Rakenna automaatiotyökalu
Kaikki menee niin kuin pitääkin. Voit ladata koodin ja tehdä muutoksia lähteen hallintaan ja kutsua ystäviä työskentelemään kanssasi. Mutta sinulla ei ole vielä sovellusta. Jotta tämä olisi verkkosovellus, se on käännetty ja pakattava jakelua varten tai ajettava suoritettavana tiedostona. (Tulkittua ohjelmointikieltä, kuten JavaScriptiä tai PHP:tä, ei tarvitse kääntää.)
Käytä rakennusautomaatiotyökalua. Minkä työkalun valitsetkin, se kokoaa koodin oikeaan muotoon ja automatisoi siivouksen, kokoamisen, testauksen ja toimituksen. Rakennustyökalut vaihtelevat kielen mukaan, mutta seuraavat avoimen lähdekoodin vaihtoehdot ovat yleisesti käytössä.
Täydellinen! Lisätään nyt koontiautomaatiotyökalun määritystiedostot lähdehallintaan, jotta CI/CD-työkalu rakentaa ne.
Se tuntuu hyvältä. Mutta missä tämä kaikki on nyt levitettävä?
Vaihe 4: Verkkosovelluspalvelin
Joten sinulla on pakattu tiedosto, joka voidaan suorittaa tai ottaa käyttöön. Jotta sovellus olisi todella hyödyllinen, sillä on oltava jonkinlainen palvelu tai käyttöliittymä, mutta sinun on laitettava se kaikki jonnekin.
Verkkosovellusta voidaan isännöidä verkkosovelluspalvelimella. Sovelluspalvelin tarjoaa ympäristön, jossa voit suorittaa paketoitua logiikkaa, renderöidä käyttöliittymiä ja paljastaa verkkopalveluita socketin kautta. Tarvitset HTTP-palvelimen ja muutaman muun ympäristön (esimerkiksi virtuaalikoneen) sovelluspalvelimen asentamiseen. Oletetaan toistaiseksi, että olet tekemisissä tämän kaiken kanssa (vaikka puhun konteista alla).
On olemassa useita avoimia verkkosovelluspalvelimia.
Meillä on jo lähes toimiva DevOps-ketju. Hyvää työtä!
Periaatteessa voit lopettaa tähän, sitten voit hoitaa sen itse, mutta koodin laadusta kannattaa puhua.
Vaihe 5: Testaa kattavuus
Testaaminen vie paljon aikaa ja vaivaa, mutta on parempi löytää virheet heti ja parantaa koodia loppukäyttäjien miellyttämiseksi. Tätä tarkoitusta varten on olemassa monia avoimia työkaluja, jotka eivät vain testaa koodia, vaan myös neuvovat sen parantamisessa. Useimmat CI/CD-työkalut voidaan liittää näihin työkaluihin ja automatisoida prosessin.
Testaus on jaettu kahteen osaan: testauskehykset testien kirjoittamiseen ja suorittamiseen sekä työkalut, joissa on vinkkejä koodin laadun parantamiseen.
Testauskehykset
Työkaluja laadukkailla vinkeillä
Suurin osa näistä työkaluista ja kehyksistä on kirjoitettu Javalle, Pythonille ja JavaScriptille, koska C++ ja C# ovat omaisuutta (vaikka GCC on avoin lähdekoodi).
Olemme ottaneet käyttöön testikattavuustyökalut, ja nyt DevOps-putkilinjan pitäisi näyttää opetusohjelman alussa olevalta kuvalta.
Lisävaiheet
kontit
Kuten aiemmin sanoin, sovelluspalvelinta voidaan isännöidä virtuaalikoneessa tai palvelimessa, mutta säiliöt ovat suositumpia.
? Lyhyesti sanottuna virtuaalikoneessa käyttöjärjestelmä vie usein enemmän tilaa kuin sovellus, ja kontti riittää yleensä muutamalla kirjastolla ja konfiguraatiolla. Joissakin tapauksissa virtuaalikoneet ovat välttämättömiä, mutta kontti voi sijoittaa sovelluksen yhdessä palvelimen kanssa ilman lisäkustannuksia.
Konteissa käytetään yleensä Dockeria ja Kubernetesia, vaikka muitakin vaihtoehtoja on.
Lue artikkeleita Dockerista ja Kubernetesista osoitteessa :
Väliohjelmiston automaatiotyökalut
DevOps-ketjumme on keskittynyt yhteistyöhön sovelluksen rakentamiseen ja toimittamiseen, mutta DevOps-työkaluilla voit tehdä muitakin mielenkiintoisia asioita. Käytä esimerkiksi Infrastructure as Code (IaC) -työkaluja, jotka tunnetaan myös väliohjelmiston automaatiotyökaluina. Nämä työkalut auttavat automatisoimaan väliohjelmiston asennuksen, hallinnan ja muut tehtävät. Esimerkiksi automaatiotyökalu voi ottaa sovelluksia (verkkosovelluspalvelin, tietokanta, valvontatyökalut) oikeilla kokoonpanoilla ja työntää ne sovelluspalvelimelle.
Tässä on joitain vaihtoehtoja avoimille väliohjelmiston automaatiotyökaluille:
Yksityiskohdat artikkeleissa :
Ja mitä nyt?
Tämä on vain jäävuoren huippu. DevOps-ketju voi tehdä paljon enemmän. Aloita CI/CD-työkalulla ja katso, mitä muuta voit automatisoida työsi helpottamiseksi. Älä unohda tehokkaaseen yhteistyöhön.
Tässä on muita hyviä DevOps-artikkeleita aloittelijoille:
Voit myös integroida DevOpsin avoimiin kettereihin työkaluihin:
Lähde: will.com