{"id":87467,"date":"2020-07-08T13:42:11","date_gmt":"2020-07-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn"},"modified":"2020-07-08T13:42:11","modified_gmt":"2020-07-08T11:42:11","slug":"rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Algajate juhend: loome DevOps torustiku","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Kui olete DevOpsi algaja, siis vaadake seda juhendit, kuidas luua oma esimest viie etapi konveierit.<\/i><\/p>\n

\"Algajate<\/p>\n

DevOps on saanud standardlahenduseks aeglaste, killustatud v\u00f5i mittet\u00f6\u00f6tavate tarkvaraarenduse protsesside parandamiseks. Probleem on aga see, et kui olete DevOpsi uus ja ei tea, kust alustada, siis v\u00f5ib teil puududa arusaam nendest meetoditest. Selles artiklis k\u00e4sitletakse DevOpsi konveieri m\u00e4\u00e4ratlemist ning pakutakse juhendit, kuidas seda luua viie lihtsa sammuga. Kuigi see \u00f5pik ei ole ammendav, peaks see andma teile aluse, et alustada oma teekonda ja laiendada oma teadmisi tulevikus. Aga alustame ajaloost.<\/p>\n

Minu teekond DevOpsis<\/h3>\n

\nVarem t\u00f6\u00f6tasin Citi Groupi pilve meeskonnas, arendades Infrastructure-as-a-Service (IaaS) veebirakendust Citi pilveinfrastruktuuri haldamiseks, kuid mind on alati huvitanud, kuidas muuta arendusprotsessi t\u00f5husamaks ja tuua positiivseid kultuurilisi muudatusi arendajate meeskonda. Vastuse leidsin raamatust, mille soovitas Greg Lavender, Citi tehniline direktor pilvearhitektuuri ja infrastruktuuri alal. Raamat kandis pealkirja \u201eThe Phoenix Project\u201cThe Phoenix Project<\/a><\/noindex>), ja seal selgitatakse DevOpsi p\u00f5him\u00f5tteid, olles samas ka romaanina meeldiv lugeda.<\/p>\n

Raamatukaane tagak\u00fcljel olevas tabelis on n\u00e4idatud, kui sageli erinevad ettev\u00f5tted juurutavad oma s\u00fcsteeme v\u00e4ljaandearvestuses:<\/p>\n

Amazon: 23 000 p\u00e4evas
\nGoogle: 5 500 p\u00e4evas
\nNetflix: 500 p\u00e4evas
\nFacebook: Korra p\u00e4evas
\nTwitter: 3 korda n\u00e4dalas
\nT\u00fc\u00fcpiline ettev\u00f5te: Kord 9 kuu jooksul<\/p>\n

Kuidas on Amazon, Google ja Netflix suudavad saavutada selliseid sagedusi? K\u00f5ik see on v\u00f5imalik, kuna need ettev\u00f5tted on leidnud, kuidas luua peaaegu ideaalne DevOps konveier.
\n<\/a><\/noindex>
\nMe olime sellest kaugel, kuni h\u00e4lbisime DevOpsi Citi-s. Sel ajal olid minu meeskonnas erinevad keskkonnad, kuid arendusserverisse toodud juurutamine oli t\u00e4ielikult k\u00e4sitsi. K\u00f5ik arendajad p\u00e4\u00e4sesid ainult \u00fchele IBM WebSphere Application Server Community Editioni p\u00f5hisele arendusserverile. Probleem seisnes selles, et server kustus iga kord, kui mitu kasutajat \u00fcheaegselt juurutamist tegema p\u00fc\u00fcdsid, seega pidid arendajad \u00fcksteisele oma kavatsustest teatama, mis oli \u00fcsna vaevaline. Lisaks esines madala taseme testimise katvuse, kohmakate k\u00e4sit\u00f6\u00f6juurutamisprotsesside ja v\u00f5imaluste puudumisega j\u00e4lgida koodijuurutamist, mis on seotud konkreetse \u00fclesande v\u00f5i kasutajalooga.<\/p>\n

M\u00f5istsin, et peab midagi tegema, ja leidsin kaaskodaniku. Otsustasime koost\u00f6\u00f6d teha algse DevOps-voo loomisel \u2013 tema seadistas virtuaalmasina ja Tomcat rakendusserveri, samas kui mina tegelesin Jenkinsiga, integreerisin Atlassian Jira ja BitBucket'i, samuti t\u00f6\u00f6tasin koodikatte testimise kallal. See k\u00f5rvalprojekt oli v\u00e4ga edukas: automatiseerisime peaaegu t\u00e4ielikult mitmeid protsesse, saavutasime peaaegu 100% katvuse meie arendusserveris, tagasime j\u00e4lgimise ja parandasime koodikatte testimise, samas lisasime v\u00f5imaluse linkida Git'i harud Jira \u00fclesannete v\u00f5i juurutamistega. Enamik t\u00f6\u00f6riistu, mida kasutasime meie DevOps-voo ehitamiseks, olid avatud l\u00e4htekoodiga.<\/p>\n

N\u00fc\u00fcd m\u00f5istan, kui lihtne oli meie DevOps-pipeline: me ei kasutanud laiendusi nagu Jenkins files v\u00f5i Ansible. Kuid see lihtne voog t\u00f6\u00f6tas h\u00e4sti, v\u00f5imalikult t\u00e4nu Pareto p\u00f5him\u00f5ttele (tuntud ka kui 80\/20 reegel).<\/p>\n

L\u00fchike \u00fclevaade DevOps-ist ja CI\/CD voost<\/h3>\n

\nKui te k\u00fcsiksite mitmelt inimeselt: \u201eMis on DevOps?\u201c, saaksite t\u00f5en\u00e4oliselt mitu erinevat vastust. DevOps, nagu Agile, on arenenud mitmete erinevate valdkondade katmiseks, kuid enamik inimesi n\u00f5ustub m\u00f5ne asja \u00fcle: DevOps on tarkvaraarenduse praktika v\u00f5i tarkvaraarenduse eluts\u00fckkel (SDLC), mille keskne p\u00f5him\u00f5te on kultuuri muutmine, kus arendajad ja mitte-arendajad eksisteerivad keskkonnas, kus:<\/p>\n

Automatiseeritud on tegevused, mida varem tehti k\u00e4sitsi;
\nIga\u00fcks teeb seda, mis tal k\u00f5ige paremini v\u00e4lja tuleb;
\nTeatud ajavahemiku jooksul toimuvate v\u00e4ljalaskete arv suureneb; Suureneb l\u00e4bilaskev\u00f5ime;
\nArenduse paindlikkus t\u00f5useb.<\/p>\n

Kuigi \u00f5ige tarkvarat\u00f6\u00f6riistade olemasolu ei ole ainus, mis on vajalik DevOpsi keskkonna loomiseks, on m\u00f5ned t\u00f6\u00f6riistad h\u00e4davajalikud. Peamine t\u00f6\u00f6riist on pidev integreerimine ja pidev juurutamine (CI\/CD). Selles konveieris on erinevad etapid (nt DEV, INT, TST, QA, UAT, STG, PROD), paljusid toiminguid automatiseeritakse ja arendajad saavad kirjutada kvaliteetset koodi, saavutades arenduse paindlikkuse ja suure juurutamis sageduse.<\/p>\n

Selles artiklis k\u00e4sitletakse viieastmelist l\u00e4henemist DevOps konveieri loomisele, mis sarnaneb j\u00e4rgmise diagrammiga, kasutades avatud l\u00e4htekoodiga t\u00f6\u00f6riistu.<\/p>\n

Samm 1: CI\/CD meetodid<\/h3>\n

\nEsimene asi, mida vajate, on CI\/CD t\u00f6\u00f6riist. Jenkins, avatud l\u00e4htekoodiga t\u00f6\u00f6riist, mis p\u00f5hineb java-l ja mille litsents on MIT, on see vahend, mis populariseeris DevOpsi suunda ja sai de facto standardiks.<\/p>\n

Nii et mis on Jenkins? M\u00f5elge sellele kui maagilisele universaalsele kaugjuhtimispuldile, mis suudab suhelda erinevate teenuste ja t\u00f6\u00f6riistadega ning organiseerida neid. CI\/CD t\u00f6\u00f6riist ise, nagu Jenkins, ei ole v\u00e4ga kasulik, kuid muutub v\u00f5imsamaks, kui see on \u00fchendatud erinevate t\u00f6\u00f6riistade ja teenustega.<\/p>\n

Jenkins on vaid \u00fcks paljusid avatud l\u00e4htekoodiga CI\/CD t\u00f6\u00f6riistu, mida saate kasutada DevOps torujuhtme loomiseks.<\/p>\n

Jenkins: Creative Commons ja MIT
\nTravis CI: MIT
\nCruiseControl: BSD
\nBuildbot: GPL
\nApache Gump: Apache 2.0
\nCabie: GNU<\/p>\n

Nii n\u00e4evad DevOps protsessid v\u00e4lja CI\/CD t\u00f6\u00f6riistaga:<\/p>\n

\"Algajate<\/p>\n

Teil on CI\/CD t\u00f6\u00f6riist, mis t\u00f6\u00f6tab teie localhostis, kuid praegu ei saa te palju teha. Liigume j\u00e4rgmisele sammule DevOps maailmas.<\/p>\n

Samm 2: Allika juhtimiss\u00fcsteemide haldamine<\/h3>\n

\nParim (ja v\u00f5ib-olla ka k\u00f5ige lihtsam) viis kontrollida, kas teie CI\/CD t\u00f6\u00f6riist suudab ime teha, on integreerimine l\u00e4htekoodi halduse t\u00f6\u00f6riistaga (SCM). Miks on teil vajalik l\u00e4htekoodi haldus? Oletame, et arendate rakendust. Iga kord, kui loote rakendust, programmeerite te, ja ei ole vahet, kas kasutate Java't, Pythonit, C++'t, Go't, Ruby't, JavaScripti v\u00f5i m\u00f5nda muud miljonit programmeerimiskeelt. Kood, mille kirjutate, nimetatakse l\u00e4htekoodiks. Alguses, eriti kui t\u00f6\u00f6tate \u00fcksi, on t\u00f5en\u00e4oliselt v\u00f5imalik k\u00f5ik asetada kohalikku kaustasse. Kuid kui projekt kasvab ja kutsute teisi inimesi koost\u00f6\u00f6le, vajate viisi konfliktide ennetamiseks t\u00f5husas muudatuste jagamises. Teil on samuti vaja v\u00f5imalust eelmisi versioone taastada, sest varukoopiate loomine ja nende kopeerimine\/kleepimine on juba vananenud. Teile (ja teie meeskonnakaaslastele) on midagi paremat vaja.<\/p>\n

Just siin muutub l\u00e4htekoodi kontrolldus praktiliselt h\u00e4davajalikuks. See t\u00f6\u00f6riist salvestab teie koodi hoidlatele, j\u00e4lgib versioone ja koordineerib projekti osalejate t\u00f6\u00f6d.<\/p>\n

Kuigi on palju l\u00e4htekoodi kontrolle, on Git standard ja see on t\u00f5si. Soovitan tungivalt kasutada Git'i, kuigi soovi korral on olemas ka muid avatud l\u00e4htekoodi valikuid.<\/p>\n

Git: GPLv2 ja LGPL v2.1
\nSubversion: Apache 2.0
\nConcurrent Versions System (CVS): GNU
\nVesta: LGPL
\nMercurial: GNU GPL v2+<\/p>\n

Selline v\u00e4lja n\u00e4eb DevOps torustik koos l\u00e4htekoodi kontrollivahenditega.<\/p>\n

\"Algajate<\/p>\n

CI\/CD t\u00f6\u00f6riist v\u00f5ib automatiseerida kontrollimise, l\u00e4htekoodi saamise ja koost\u00f6\u00f6 protsessid liikmete vahel. Pole paha? Kuid kuidas teha sellest toimiv rakendus, et miljardid inimesed saaksid seda kasutada ja hinnata?<\/p>\n

Samm 3: Automaatika kogumise t\u00f6\u00f6riista loomine<\/h3>\n

\nSuurep\u00e4rane! Saate kontrollida koodi ja teha muudatusi versioonihalduss\u00fcsteemis ning kutsuda oma s\u00f5pru arendusse osalema. Kuid olete ikka veel oma rakendust loonud. Veebirakenduse loomiseks tuleb see kompileerida ja pakkida kasutatavasse paketivormingusse v\u00f5i k\u00e4ivitada t\u00e4itmisfailina. (Pange t\u00e4hele, et t\u00f5lgendatavad programmeerimiskeeled, nagu JavaScript v\u00f5i PHP, ei vaja kompileerimist).<\/p>\n

Kasutage ehituse automatiseerimise t\u00f6\u00f6riista. \u00dcksk\u00f5ik, millist ehituse automatiseerimise t\u00f6\u00f6riista otsustate kasutada, on nende \u00fchine eesm\u00e4rk: koguda l\u00e4htekood soovitud vormingusse ja automatiseerida puhastamise, kompileerimise, testimise ja juurutamise \u00fclesanne kindlas keskkonnas. Ehitust\u00f6\u00f6riistad s\u00f5ltuvad teie programmeerimiskeelest, kuid siin on m\u00f5ned levinud avatud l\u00e4htekoodiga variandid.<\/p>\n

Nimi
\nLitsents
\nProgrammeerkiel<\/p>\n

Maven
\nApache 2.0
\n Java<\/p>\n

Ant
\nApache 2.0
\nJava<\/p>\n

Gradle
\nApache 2.0
\nJava<\/p>\n

Bazel
\nApache 2.0
\nJava<\/p>\n

Make
\nGNU
\nN\/A<\/p>\n

Grunt
\nMIT
\nJavaScript<\/p>\n

Gulp
\nMIT
\nJavaScript<\/p>\n

Buildr
\nApache
\nRuby<\/p>\n

Rake
\nMIT
\nRuby<\/p>\n

A-A-P
\nGNU
\nPython<\/p>\n

SCons
\nMIT
\nPython<\/p>\n

BitBake
\nGPLv2
\nPython<\/p>\n

Kook
\nMIT
\nC#<\/p>\n

ASDF
\nExpat (MIT)
\nLISP<\/p>\n

Cabal
\nBSD
\nHaskell<\/p>\n

Tere! Saate oma koostamisautomaadi seadistuses olevad failid paigutada allika juhtimisse ja lasta oma CI\/CD t\u00f6\u00f6riistal k\u00f5ik kokku panna.<\/p>\n

\"Algajate<\/p>\n

K\u00f5ik on h\u00e4sti, eks? Kuid kus on v\u00f5imalik teie rakendust juurutada?<\/p>\n

Samm 4: Veebirakenduste server<\/h3>\n

\nPraegu on teil pakitud fail, mis v\u00f5ib olla kas k\u00e4ivitatav v\u00f5i installitav. Selleks, et mis tahes rakendus oleks t\u00f5eliselt kasulik, peab see pakkuma mingit teenust v\u00f5i liidest, kuid vajate konteinerit oma rakenduse mahutamiseks.<\/p>\n

Veebirakenduste server on just selline konteiner. Server loob keskkonna, kus saad m\u00e4\u00e4ratleda juurutatava paketi loogika. Samuti annab server liidese ja pakub veebiteenuseid, avades v\u00e4lismaailmale pordid. Teil on vaja HTTP-serverit ja m\u00f5nda keskkonda (nt virtuaalmasin) selle k\u00e4itamiseks. Eeldame seni, et te \u00f5pite selle kohta rohkem (kuigi r\u00e4\u00e4gin konteineritest allpool).<\/p>\n

On mitmeid avatud l\u00e4htekoodiga veebirakenduste servereid.<\/p>\n

Nimi
\nLitsents
\nProgrammeerkiel<\/p>\n

Tomcat
\nApache 2.0
\nJava<\/p>\n

Jetty
\nApache 2.0
\nJava<\/p>\n

WildFly
\nGNU Lesser Public
\nJava<\/p>\n

GlassFish
\nCDDL ja GNU Less Public
\nJava<\/p>\n

Django
\n3-Clause BSD
\nPython<\/p>\n

Tornado
\nApache 2.0
\nPython<\/p>\n

Gunicorn
\nMIT
\nPython<\/p>\n

Python
\nMIT
\nPython<\/p>\n

Rails
\nMIT
\nRuby<\/p>\n

Node.js
\nMIT
\nJavascript<\/p>\n

Teie DevOps toru on peaaegu kasutamiseks valmis. H\u00e4sti tehtud!<\/p>\n

\"Algajate<\/p>\n

Kuigi v\u00f5ib peatuda ja hakata integreerimisega iseseisvalt tegelema, on koodikvaliteet rakenduse arendajate jaoks oluline ning sellega tuleb tegeleda.<\/p>\n

Samm 5: Koodi testimise katmine<\/h3>\n

\nTestide rakendamine v\u00f5ib olla veel \u00fcks t\u00fclikas n\u00f5ue, kuid arendajad peavad rakenduses t\u00f5rkeid varakult tabama ja koodikvaliteeti parandama, et tagada l\u00f5ppkasutajate rahulolu. \u00d5nneks on olemas palju avatud l\u00e4htekoodiga t\u00f6\u00f6riistu teie koodi testimiseks ja kvaliteedi parandamise soovituste genereerimiseks. Veelgi parem on see, et enamik CI\/CD t\u00f6\u00f6riistu saavad nendele t\u00f6\u00f6riistadele \u00fchenduda ja protsessi automatiseerida.<\/p>\n

Koodi testimine koosneb kahest osast: koodi testimise raamistikud, mis aitavad testide kirjutamisel ja k\u00e4itamisel, ning soovituste genereerimise t\u00f6\u00f6riistad, mis aitavad koodikvaliteeti parandada.<\/p>\n

Koodi testimise s\u00fcsteemid<\/b><\/p>\n

Nimi
\nLitsents
\nProgrammeerkiel<\/p>\n

JUnit
\nEclipse\u2019i avalik litsents
\nJava<\/p>\n

EasyMock
\nApache
\nJava<\/p>\n

Mockito
\nMIT
\nJava<\/p>\n

PowerMock
\nApache 2.0
\nJava<\/p>\n

Pytest
\n MIT
\nPython<\/p>\n

Hypothesis
\nMozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Koodiv\u00f5imaluste parandamise s\u00fcsteemid<\/b><\/p>\n

Nimi
\nLitsents
\nProgrammeerkiel<\/p>\n

Cobertura
\nGNU
\nJava<\/p>\n

CodeCover
\nEclipse Public (EPL)
\nJava<\/p>\n

Coverage.py
\n Apache 2.0
\nPython<\/p>\n

Emma
\n\u00dchine avalik litsents
\nJava<\/p>\n

JaCoCo
\n Eclipse\u2019i avalik litsents
\nJava<\/p>\n

Hypothesis
\n Mozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Jasmine
\nMIT
\nJavaScript<\/p>\n

Karma
\nMIT
\nJavaScript<\/p>\n

Mocha
\n MIT
\nJavaScript<\/p>\n

Jest
\nMIT
\nJavaScript<\/p>\n

Pange t\u00e4hele, et enamik \u00fclaltoodud t\u00f6\u00f6riistu ja raamistikke on kirjutatud Java, Python ja JavaScript jaoks, kuna C++ ja C# on omandi \u00f5igustega programmeerimiskeeled (kuigi GCC on avatud l\u00e4htekoodiga).<\/p>\n

N\u00fc\u00fcd, kui olete rakendanud koodikattete t\u00f6\u00f6riistu, peaks teie DevOps torujuhe olema sarnane alguses esitatud diagrammiga.<\/p>\n

T\u00e4iendavad sammud<\/h3>\n

\nKonteinerid<\/b><\/p>\n

Nagu juba mainisin, saate oma serveri paigutada virtuaalmasinale v\u00f5i serverisse, kuid konteinerid on populaarsed lahendused.<\/p>\n

Mis on konteinerid? L\u00fchi\u00fclevaade on see, et virtuaalmasin vajab oma operatsioonis\u00fcsteemi jaoks suurt m\u00e4lu, mis \u00fcletab rakenduse suuruse, samas kui konteiner vajab ainult m\u00f5ningaid teeke ja konfiguratsioone rakenduse k\u00e4ivitamiseks. Ilmselgelt on virtuaalmasinal endiselt olulised rakendusalad, kuid konteiner on kerge lahendus rakenduse, sealhulgas rakenduste serverite hostimiseks.<\/p>\n

Kuigi on ka teisi konteinerite variante, on k\u00f5ige populaarsemad Docker ja Kubernetes.<\/p>\n

Docker: Apache 2.0
\nKubernetes: Apache 2.0<\/p>\n

Vahe-automatiseerimise t\u00f6\u00f6riistad<\/b><\/p>\n

Meie DevOps-toru on peamiselt suunatud rakenduste koostootmisele ja juurutamisele, kuid DevOps-t\u00f6\u00f6riistade abil on v\u00f5imalik teha palju muud. \u00dcks neist on Infrastructure as Code (IaC) t\u00f6\u00f6riistade kasutamine, mida tuntakse ka vahe-automatiseerimise t\u00f6\u00f6riistadena. Need t\u00f6\u00f6riistad aitavad automatiseerida installimist, haldamist ja muid \u00fclesandeid vaheprogrammi jaoks. N\u00e4iteks v\u00f5ib automatiseerimist\u00f6\u00f6riist hankida rakendusi nagu veebirakenduse server, andmebaas ja j\u00e4lgimist\u00f6\u00f6riist, koos \u00f5ige konfigureerimisega ja juurutada need rakenduste serverisse.<\/p>\n

Siin on m\u00f5ned avatud l\u00e4htekoodiga vahe-automatiseerimise t\u00f6\u00f6riistad:<\/p>\n

Ansible: GNU Public
\nSaltStack: Apache 2.0
\nChef: Apache 2.0
\nPuppet: Apache v\u00f5i GPL<\/p>\n

\"Algajate<\/p>\n

Tutvuge, kuidas omandada n\u00f5utud amet nullist v\u00f5i t\u00f5sta oma oskusi ja palka, osaledes SkillFactory tasulistel veebikursustel:<\/p>\n