Jos olet uusi DevOps-käyttäjä, tutustu tähän oppaaseen ensimmäisen viisivaiheisen putkilinjan rakentamiseksi.
DevOpsista on tullut vakioratkaisu hitaiden, hajanaisten tai rikkinäisten ohjelmistokehitysprosessien korjaamiseen. Ongelmana on, että jos olet uusi DevOps-käyttäjä etkä tiedä mistä aloittaa, et ehkä ymmärrä näitä tekniikoita. Tässä artikkelissa käsitellään DevOps-putkilinjan määritelmää ja annetaan myös viisivaiheiset ohjeet sellaisen luomiseen. Vaikka tämä opetusohjelma ei ole tyhjentävä, sen pitäisi antaa sinulle perusta aloittaaksesi matkasi ja laajentaa tietämystäsi tulevaisuudessa. Mutta aloitetaan historiasta.
DevOps-matkani
Työskentelin aiemmin Citi Groupin pilvitiimissä kehittämässä Infrastructure-as-a-Service (IaaS) -verkkosovellusta Citin pilviinfrastruktuurin hallintaan, mutta olin aina kiinnostunut siitä, miten kehitysprosessia voitaisiin tehostaa ja tuoda positiivista kulttuurista muutosta kehitystiimi. Löysin vastauksen kirjasta, jota suosittelee Greg Lavender, Citin Cloud Architecture and Infrastructure -teknologiajohtaja. Kirjan nimi oli The Phoenix Project (), ja se selittää DevOpsin periaatteet, mutta se on kuin romaani.
Kirjan takaosassa oleva taulukko näyttää, kuinka usein eri yritykset ottavat järjestelmiään käyttöön julkaisuympäristössä:
Amazon: 23 000 päivässä
Google: 5 500 per päivä
Netflix: 500 per päivä
Facebook: Kerran päivässä
Twitter: 3 kertaa viikossa
Tyypillinen yritys: Kerran 9 kuukauden välein
Miten Amazonin, Googlen ja Netflixin taajuudet ovat edes mahdollisia? Tämä johtuu siitä, että nämä yritykset ovat keksineet, kuinka luoda lähes täydellinen DevOps-putki.
Olimme kaukana tästä, kunnes otimme DevOpsin käyttöön Citissä. Tuolloin tiimilläni oli erilaisia ympäristöjä, mutta käyttöönotto kehityspalvelimella oli täysin manuaalista. Kaikilla kehittäjillä oli pääsy vain yhteen IBM WebSphere Application Server Community Editioniin perustuvaan kehityspalvelimeen. Ongelmana oli, että palvelin sammui aina, kun useat käyttäjät yrittivät ottaa käyttöön samaan aikaan, joten kehittäjien piti viestiä aikeistaan toisilleen, mikä oli melko tuskaa. Lisäksi ongelmia oli matalan tason testikoodin kattavuudessa, raskaissa manuaalisissa käyttöönottoprosesseissa ja kyvyttömyys seurata tiettyyn tehtävään tai käyttäjätarinaan liittyvän koodin käyttöönottoa.
Tajusin, että jotain oli tehtävä, ja löysin samanmielisen kollegan. Päätimme tehdä yhteistyötä alkuperäisen DevOps-putkilinjan rakentamisessa – hän perusti Tomcat-virtuaalikoneen ja sovelluspalvelimen, kun minä työskentelin Jenkinsin parissa, integroi Atlassian Jiran ja BitBucketin sekä työskenteli testikoodin kattavuuden parissa. Tämä sivuprojekti oli erittäin onnistunut: automatisoimme lähes täysin monet prosessit, saavutimme lähes 100 %:n käyttöajan kehityspalvelimellamme, tarjosimme koodin seurannan ja parannetun testikattavuuden ja lisäsimme mahdollisuuden linkittää Git-haaroja Jira-ongelmiin tai -asetuksiin. Suurin osa DevOps-putkistomme rakentamiseen käyttämistämme työkaluista oli avoimen lähdekoodin.
Nyt ymmärrän, kuinka yksinkertainen DevOps-putkistomme oli: emme käyttäneet laajennuksia, kuten Jenkins-tiedostoja tai Ansible. Tämä yksinkertainen putki toimi kuitenkin hyvin, ehkä johtuen Pareto-periaatteesta (tunnetaan myös nimellä 80/20-sääntö).
Lyhyt johdatus DevOpsiin ja CI/CD-putkilinjaan
Jos kysyt useilta ihmisiltä: "Mikä on DevOps?", saat todennäköisesti useita erilaisia vastauksia. DevOps, kuten Agile, on kehittynyt kattamaan monia eri tieteenaloja, mutta useimmat ihmiset ovat samaa mieltä muutamasta asiasta: DevOps on ohjelmistokehityskäytäntö tai ohjelmistokehityksen elinkaari (SDLC), jonka keskeinen periaate on muuttaa kulttuuria, jossa kehittäjät ja muut kehittäjät ovat ympäristössä, jossa:
Aiemmin manuaalisesti suoritetut toiminnot on automatisoitu;
Jokainen tekee mitä osaa parhaiten;
Toteutusten määrä tietyn ajanjakson aikana kasvaa; Lisääntynyt suorituskyky;
Lisää kehitysjoustavuutta.
Vaikka oikeat ohjelmistotyökalut eivät ole ainoa asia, jonka tarvitset DevOps-ympäristön luomiseen, jotkin työkalut ovat välttämättömiä. Keskeinen työkalu on jatkuva integrointi ja jatkuva käyttöönotto (CI/CD). Tässä putkistossa ympäristöillä on eri vaiheita (esim. DEV, INT, TST, QA, UAT, STG, PROD), monet toiminnot ovat automatisoituja ja kehittäjät voivat kirjoittaa korkealaatuista koodia, saavuttaa kehitysketteryyden ja korkean käyttöönottotiheyden.
Tässä artikkelissa kuvataan viisivaiheinen lähestymistapa DevOps-putkilinjan luomiseen, kuten seuraavassa kaaviossa on esitetty avoimen lähdekoodin työkaluilla.
Vaihe 1: CI/CD-menetelmät
Ensimmäinen asia, jonka tarvitset, on CI/CD-työkalu. Jenkins, Java-pohjainen avoimen lähdekoodin työkalu, joka on lisensoitu MIT-lisenssillä, on työkalu, joka teki DevOpsin suosituksi ja siitä on tullut de facto standardi.
Joten mikä on Jenkins? Ajattele sitä jonkinlaisena maagisena yleiskaukosäätimenä, joka voi puhua ja järjestää erilaisia palveluita ja työkaluja. Pelkästään Jenkinsin kaltainen CI/CD-työkalu on hyödytön, mutta siitä tulee tehokkaampi, kun se yhdistetään eri työkaluihin ja palveluihin.
Jenkins on vain yksi monista avoimen lähdekoodin CI/CD-työkaluista, joita voit käyttää DevOps-putkilinjasi rakentamiseen.
Jenkins: Creative Commons ja MIT
Travis CI: MIT
Vakionopeudensäädin: BSD
Buildbot: GPL
Apache Gump: Apache 2.0
Cabie: GNU
Tältä DevOps-prosessit näyttävät CI/CD-työkalulla:
Sinulla on CI/CD-työkalu käynnissä localhostissasi, mutta et voi tehdä paljoa tällä hetkellä. Siirrytään DevOps-matkan seuraavaan vaiheeseen.
Vaihe 2: Hallinnoi lähteen ohjausjärjestelmiä
Paras (ja ehkä helpoin) tapa varmistaa, että CI/CD-työkalusi voi tehdä taikansa, on integroida lähdekoodin ohjaustyökalu (SCM). Miksi tarvitset lähteen hallintaa? Oletetaan, että olet kehittämässä sovellusta. Aina kun luot sovelluksen, ohjelmoit, eikä sillä ole väliä, käytätkö Javaa, Pythonia, C++:aa, Goa, Rubyä, JavaScriptiä vai mitä tahansa lukuisista ohjelmointikielistä. Kirjoittamasi koodia kutsutaan lähdekoodiksi. Alussa, varsinkin kun työskentelet yksin, on luultavasti ok laittaa kaikki paikalliseen hakemistoon. Mutta kun projekti laajenee ja kutsut muita ihmisiä yhteistyöhön, tarvitset tavan estää konflikteja ja jakaa samalla tehokkaasti muutoksia. Tarvitset myös tavan palauttaa aiemmat versiot, koska varmuuskopioiden luominen ja niihin kopioiminen/liittäminen on vanhentumassa. Sinä (ja joukkuetoverisi) tarvitset jotain parempaa.
Tässä lähdekoodin hallinnasta tulee melkein välttämättömyys. Tämä työkalu tallentaa koodisi arkistoihin, pitää kirjaa versioista ja koordinoi projektiin osallistujien työtä.
Vaikka siellä on monia lähdekoodin ohjaustyökaluja, Git on standardi, ja oikeutetusti. Suosittelen Gitin käyttöä, vaikka on muitakin avoimen lähdekoodin vaihtoehtoja, jos haluat.
Git: GPLv2 ja LGPL v2.1
Subversion: Apache 2.0
Samanaikaisten versioiden järjestelmä (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+
Tältä DevOps-putki näyttää lähdekoodiohjaimien lisättynä.
CI/CD-työkalu voi automatisoida tarkistusprosesseja, lähdekoodin hankintaa ja yhteistyötä jäsenten välillä. Ei paha? Mutta miten se tehdään toimivaksi sovellukseksi, jotta miljardit ihmiset voivat käyttää ja arvostaa sitä?
Vaihe 3: Luo rakennusautomaatiotyökalu
Loistava! Voit tarkastella koodia ja tehdä muutoksia lähteen hallintaan ja kutsua ystäviäsi kehittämään yhteistyötä. Mutta et ole vielä luonut sovellusta. Verkkosovelluksen tekemiseksi se on käännettävä ja pakattava käyttöönotettavissa olevaan erämuotoon tai ajettava suoritettavana tiedostona. (Huomaa, että tulkittua ohjelmointikieltä, kuten JavaScript tai PHP, ei tarvitse kääntää).
Käytä rakennusautomaatiotyökalua. Riippumatta siitä, mitä rakennusautomaatiotyökalua päätät käyttää, niillä kaikilla on sama tavoite: rakentaa lähdekoodi johonkin haluttuun muotoon ja automatisoida puhdistus, kääntäminen, testaus ja käyttöönotto tietyssä ympäristössä. Rakennustyökalut vaihtelevat ohjelmointikielestäsi riippuen, mutta tässä on joitain yleisiä avoimen lähdekoodin vaihtoehtoja.
Nimi
lisenssi
Ohjelmointikieli
Maven
Apache 2.0
Jaava
Muurahainen
Apache 2.0
Jaava
Gradle
Apache 2.0
Jaava
Bazel
Apache 2.0
Jaava
Tehdä
GNU
N / A
Murahdus
MIT
JavaScript
Kulaus
MIT
JavaScript
Rakentaja
Apache
Rubiini
harava
MIT
Rubiini
AAP
GNU
Python
SCons
MIT
Python
bitbake
GPLv2
Python
Kakku
MIT
C#
ASDF
Expat (MIT)
LISP
täydellinen
BSD
Haskell
Loistava! Voit laittaa rakennusautomaatiotyökalun määritystiedostot lähdehallintaan ja antaa CI/CD-työkalusi koota kaiken.
Kaikki on hyvin, eikö? Mutta missä otat sovelluksesi käyttöön?
Vaihe 4: Verkkosovelluspalvelin
Toistaiseksi sinulla on pakattu tiedosto, joka voi olla joko suoritettava tai asennettava. Jotta mikä tahansa sovellus olisi todella hyödyllinen, sen on tarjottava jonkinlainen palvelu tai käyttöliittymä, mutta tarvitset säilön sovelluksesi isännöintiä varten.
Verkkosovelluspalvelin on juuri tällainen säilö. Palvelin tarjoaa ympäristön, jossa käyttöön otettavan paketin logiikka voidaan määrittää. Palvelin tarjoaa myös käyttöliittymän ja tarjoaa verkkopalveluita paljastamalla pistorasiat ulkomaailmalle. Tarvitset HTTP-palvelimen sekä jonkin ympäristön (kuten virtuaalikoneen) sen asentamiseen. Oletetaan toistaiseksi, että opit tästä lisää (vaikka käsittelen säiliöitä alla).
On olemassa useita avoimen lähdekoodin verkkosovelluspalvelimia.
Nimi
lisenssi
Ohjelmointikieli
kollikissa
Apache 2.0
Jaava
aallonmurtaja
Apache 2.0
Jaava
wildfly
GNU Lesser Public
Jaava
GlassFish
CDDL & GNU vähemmän julkinen
Jaava
Django
3-lauseke BSD
Python
Tornado
Apache 2.0
Python
Gunicorn
MIT
Python
Python
MIT
Python
Raiteet
MIT
Rubiini
Node.js
MIT
Javascript
DevOps-putkisi on melkein käyttövalmis. Hyvää työtä!
Vaikka voit pysähtyä tähän ja hoitaa integroinnin itse, koodin laatu on tärkeä asia, josta sovelluskehittäjän on huolehdittava.
Vaihe 5: Kooditestauksen kattavuus
Testien toteuttaminen voi olla toinen hankala vaatimus, mutta kehittäjien on löydettävä sovelluksen virheet ajoissa ja parannettava koodin laatua varmistaakseen, että loppukäyttäjät ovat tyytyväisiä. Onneksi on olemassa monia avoimen lähdekoodin työkaluja koodin testaamiseen ja suositusten tekemiseen sen laadun parantamiseksi. Vielä parempaa on, että useimmat CI/CD-työkalut voivat muodostaa yhteyden näihin työkaluihin ja automatisoida prosessin.
Kooditestaus koostuu kahdesta osasta: koodin testauskehykset, jotka auttavat sinua kirjoittamaan ja suorittamaan testejä, ja ehdotustyökalut, jotka auttavat parantamaan koodin laatua.
Koodin testausjärjestelmät
Nimi
lisenssi
Ohjelmointikieli
JUnit
Eclipse julkinen lisenssi
Jaava
EasyMock
Apache
Jaava
mockito
MIT
Jaava
PowerMock
Apache 2.0
Jaava
Pytest
MIT
Python
Hypoteesi
mozilla
Python
Tox
MIT
Python
Suositusjärjestelmät koodin parantamiseksi
Nimi
lisenssi
Ohjelmointikieli
Kattavuus
GNU
Jaava
CodeCover
Eclipse Public (EPL)
Jaava
Coverage.py
Apache 2.0
Python
Emma
Yhteinen julkinen lisenssi
Jaava
JaCoCo
Eclipse julkinen lisenssi
Jaava
Hypoteesi
mozilla
Python
Tox
MIT
Python
Jasmiini
MIT
JavaScript
Karma
MIT
JavaScript
mokkakahvi
MIT
JavaScript
on
MIT
JavaScript
Huomaa, että suurin osa yllä mainituista työkaluista ja kehyksistä on kirjoitettu Javalle, Pythonille ja JavaScriptille, koska C++ ja C# ovat patentoituja ohjelmointikieliä (vaikka GCC on avoimen lähdekoodin kieli).
Nyt kun olet ottanut käyttöön testikattavuustyökalut, DevOps-putkilinjasi pitäisi näyttää samanlaiselta kuin tämän opetusohjelman alussa näkyvä kaavio.
Lisävaiheet
kontit
Kuten sanoin, voit isännöidä palvelintasi virtuaalikoneella tai palvelimella, mutta säiliöt ovat suosittu ratkaisu.
Mitä ovat kontit? Lyhyt selitys on, että virtuaalikone tarvitsee valtavan määrän käyttöjärjestelmämuistia, joka ylittää sovelluksen koon, kun taas kontti tarvitsee vain muutaman kirjaston ja kokoonpanon sovelluksen suorittamiseen. On selvää, että virtuaalikoneen on edelleen tärkeitä käyttötarkoituksia, mutta kontti on kevyt ratkaisu sovelluksen, mukaan lukien sovelluspalvelimen, isännöintiin.
Vaikka muitakin konttivaihtoehtoja on, suosituimmat ovat Docker ja Kubernetes.
Docker: Apache 2.0
Kubernetes: Apache 2.0
Keskitason automaatiotyökalut
DevOps-putkistomme keskittyy ensisijaisesti yhteiskäyttöön sovellusten luomiseen ja käyttöönottoon, mutta DevOps-työkaluilla voidaan tehdä monia muita asioita. Yksi niistä on Infrastructure as Code (IaC) -työkalujen käyttö, jotka tunnetaan myös väliohjelmiston automaatiotyökaluina. Nämä työkalut auttavat automatisoimaan väliohjelmiston asennuksen, hallinnan ja muut tehtävät. Joten esimerkiksi automaatiotyökalu voi poimia sovelluksia, kuten verkkosovelluspalvelimen, tietokannan ja valvontatyökalun oikeilla kokoonpanoilla, ja ottaa ne käyttöön sovelluspalvelimelle.
Tässä on joitain avoimen lähdekoodin väliohjelmiston automatisointityökaluja:
Mahdollisuus: GNU Public
SaltStack: Apache 2.0
Kokki: Apache 2.0
Nukke: Apache tai GPL
Ota selvää kuinka saada haluttu ammatti tyhjästä tai Level Up taitojen ja palkan suhteen suorittamalla SkillFactoryn maksullisia verkkokursseja:
- (12 kuukautta)
lisää kursseja
- (12 viikkoa)
- (12 kuukautta)
- (9 kuukautta)
- (9 kuukautta)
hyödyllinen
Lähde: will.com