Konstruu vian unuan DevOps-ĉenon en kvin paŝoj por komencantoj.
DevOps fariĝis panaceo por tro malrapidaj, malkonektitaj kaj alie problemaj evoluaj procezoj. Sed vi bezonas minimuman scion en DevOps. Ĝi kovros konceptojn kiel la ĉeno DevOps kaj kiel krei unu el kvin paŝoj. Ĉi tio ne estas kompleta gvidilo, sed nur "fiŝo", kiu povas esti vastigita. Ni komencu per la historio.
Mia enkonduko al DevOps
Mi kutimis labori kun nuboj ĉe Citi Group kaj evoluigi IaaS TTT-aplikaĵon por administri la nuban infrastrukturon de Citi, sed mi ĉiam interesiĝis pri kiel optimumigi la evoluĉenon kaj plibonigi la kulturon inter programistoj. Greg Lavender, nia CTO por Nuba Arkitekturo kaj Infrastrukturo, rekomendis ĉi tiun libron al mi. . Ĝi bele klarigas principojn de DevOps kaj legas kiel romano.
La tablo sur la dorso montras kiom ofte kompanioj lanĉas novajn versiojn:
Kiel Amazon, Guglo kaj Netflix sukcesas tiom multe fari? Kaj ĝi estas simpla: ili eltrovis kiel krei preskaŭ perfektan DevOps-ĉenon.
Aferoj estis tre malsamaj por ni ĉe Citi ĝis ni ŝanĝis al DevOps. Tiam mia teamo havis malsamajn mediojn, sed ni faris la liveron al la evoluservilo permane. Ĉiuj programistoj havis aliron al nur unu evoluservilo bazita sur IBM WebSphere Application Server Community Edition. Kun samtempa provo liveri, la servilo "falis", kaj ĉiufoje ni devis "dolore" negoci inter ni mem. Ni ankaŭ havis nesufiĉan kodan kovradon kun testoj, tempopostulan manan liveran procezon, kaj neniun manieron spuri la liveron de kodo helpe de iu tasko aŭ klienta postulo.
Estis klare, ke io urĝe necesas fari, kaj mi trovis samideanon. Ni decidis krei la unuan DevOps-ĉenon kune - li starigis virtualan maŝinon kaj Tomcat-aplikservilon, kaj mi prizorgis Jenkins, integriĝon kun Atlassian Jira kaj BitBucket, same kiel kodan priraportadon per testoj. La projekto estis sukcesa: ni plene aŭtomatigis la disvolvan ĉenon, atingis preskaŭ 100% funkcian tempon sur la evoluservilo, povis monitori kaj plibonigi kodan kovradon per testoj, kaj Git-filio povus esti ligita al Jira-livero kaj afero. Kaj preskaŭ ĉiuj iloj, kiujn ni uzis por konstrui la ĉenon DevOps, estis malfermitaj fontoj.
Fakte, la ĉeno estis simpligita, ĉar ni eĉ ne aplikis altnivelajn agordojn uzante Jenkins aŭ Ansible. Sed ni sukcesis. Eble ĉi tio estas sekvo de la principo (alinome la regulo 80/20).
Mallonga Priskribo de la DevOps kaj CI/CD-Ĉeno
DevOps havas malsamajn difinojn. DevOps, kiel Agile, inkluzivas malsamajn disciplinojn. Sed plej multaj konsentos kun la sekva difino: DevOps estas metodo aŭ vivociklo de programaro, kies ĉefa principo estas krei kulturon, kie programistoj kaj aliaj dungitoj estas "sur la sama ondolongo", mana laboro estas aŭtomatigita, ĉiu faras tion, kion ili plej kapablas, la ofteco de liveraĵoj pliiĝas, la produktiveco de laboro pliiĝas, fleksebleco pliiĝas.
Dum iloj sole ne sufiĉas por krei DevOps-medion, ili estas nemalhaveblaj. La plej grava el tiuj estas kontinua integriĝo kaj kontinua livero (CI/KD). Estas malsamaj stadioj en la ĉeno por ĉiu medio (ekz. DEV (evoluo), INT (integriĝo), TST (testado), QA (kvalita certigo), UAT (uzantakceptotestado), STG (preparo), PROD (uzo)) , manaj taskoj estas aŭtomatigitaj, programistoj povas produkti kvalitan kodon, liveri ĝin kaj povas facile rekonstrui.
Ĉi tiu noto priskribas kiel krei DevOps-ĉenon en kvin paŝoj, kiel montrite en la suba bildo, uzante malfermfontajn ilojn.
Ni eklaboru.
Paŝo 1: CI/CD Platformo
Antaŭ ĉio, vi bezonas CI/KD-ilon. Jenkins estas MIT-licencita, malfermfonta CI/CD-ilo skribita en Java kiu popularigis la DevOps-movadon kaj fariĝis la fakta normo por CICD.
Kio estas Jenkins? Imagu, ke vi havas magian kontrolpanelon por diversaj servoj kaj iloj. Per si mem, CI/KD-ilo kiel Jenkins estas senutila, sed kun malsamaj iloj kaj servoj, ĝi fariĝas ĉiopova.
Krom Jenkins, ekzistas multaj aliaj malfermfontaj iloj, elektu iun ajn.
Jen kiel aspektas DevOps-procezo kun CI/CD-ilo
Vi havas CI/KD-ilon en localhost, sed ankoraŭ ne estas multe por fari. Ni transiru al la sekva paŝo.
Paŝo 2: Versia Kontrolo
La plej bona (kaj verŝajne plej facila) maniero testi la magion de CI/KD-ilo estas integri ĝin kun fontkontrola administrado (SCM). Kial vi bezonas version-kontrolon? Ni diru, ke vi faras kandidatiĝon. Vi skribas ĝin en Java, Python, C++, Go, Ruby, JavaScript aŭ ajna alia lingvo, kiu estas vagono kaj ĉareto. Kion vi skribas, oni nomas fontkodon. Komence, precipe se vi laboras sola, vi povas konservi ĉion en loka dosierujo. Sed dum la projekto kreskas kaj pli da homoj aliĝas, vi bezonas manieron dividi kodŝanĝojn sed eviti konfliktojn dum kunfandado de ŝanĝoj. Kaj vi ankaŭ devas iel restarigi antaŭajn versiojn sen uzi sekurkopiojn kaj uzante la kopi-alglui metodon por kodaj dosieroj.
Kaj ĉi tie sen SCM ie ajn. La SCM stokas kodon en deponejoj, administras versiojn de ĝi kaj kunordigas ĝin inter programistoj.
Estas multaj SCM-iloj, sed Git merite fariĝis la fakta normo. Mi konsilas al vi uzi ĝin, sed estas aliaj ebloj.
Jen kiel aspektas la dukto DevOps post aldoni la SCM.
La CI/KD-ilo povas aŭtomatigi fontkodon alŝuti kaj elŝuti kaj teamkunlaboron. Ne malbona? Sed nun kiel fari funkciantan aplikaĵon el ĉi tio, ŝatata de miliardoj da uzantoj?
Paŝo 3: Konstruu Aŭtomatan Ilon
Ĉio iras kiel ĝi devus. Vi povas alŝuti kodon kaj fari ŝanĝojn al fontkontrolo, kaj inviti amikojn labori kun vi. Sed vi ankoraŭ ne havas apon. Por ke ĉi tio estu TTT-aplikaĵo, ĝi devas esti kompilita kaj pakita por distribuo aŭ ruliĝi kiel rulebla. (Interpretita programlingvo kiel JavaScript aŭ PHP ne bezonas esti kompilita.)
Uzu konstruan aŭtomatigan ilon. Kiun ajn ilon vi elektos, ĝi kunigos la kodon en la ĝusta formato kaj aŭtomatigos purigadon, kompilon, testadon kaj liveron. Konstruaj iloj varias laŭ lingvo, sed la jenaj malfermfontaj opcioj estas ofte uzataj.
Perfekta! Nun ni enigu la agordajn dosierojn de konstrua aŭtomatiga ilo en fontkontrolon por ke la CI/CD-ilo konstruu ilin.
Ĝi sentas bone. Sed kie ĉio ĉi estas por ruliĝi nun?
Paŝo 4: Reta Aplika Servilo
Do, vi havas pakitan dosieron, kiu povas esti efektivigita aŭ eligita. Por ke aplikaĵo estu vere utila, ĝi devas havi ian servon aŭ interfacon, sed vi devas meti ĉion ien.
TTT-aplikaĵo povas esti gastigita sur ret-aplikservilo. La aplika servilo provizas medion, kie vi povas ekzekuti pakitan logikon, redoni interfacojn kaj elmontri retservojn per ingo. Vi bezonas HTTP-servilon kaj kelkajn aliajn mediojn (virtuala maŝino, ekzemple) por instali la aplikaĵoservilon. Nuntempe, ni ŝajnigu, ke vi traktas ĉion ĉi dum vi iras (kvankam mi parolos pri ujoj sube).
Estas pluraj malfermitaj TTT-aplikaj serviloj.
Ni jam havas preskaŭ funkciantan ĉenon DevOps. Bonega laboro!
Principe, vi povas ĉesi ĉi tie, tiam vi povas trakti ĝin mem, sed indas paroli pri la kvalito de la kodo.
Paŝo 5: Testa kovrado
Testado postulas multan tempon kaj penon, sed estas pli bone trovi cimojn tuj kaj plibonigi la kodon por plaĉi al finaj uzantoj. Por ĉi tiu celo, ekzistas multaj malfermitaj iloj, kiuj ne nur testos la kodon, sed ankaŭ konsilas pri kiel plibonigi ĝin. Plej multaj CI/KD-iloj povas konekti al ĉi tiuj iloj kaj aŭtomatigi la procezon.
Testado estas dividita en du partojn: testado de kadroj por skribi kaj efektivigi testojn, kaj iloj kun sugestoj por plibonigi kodkvaliton.
Testaj Kadroj
Iloj kun bonkvalitaj konsiletoj
La plej multaj el ĉi tiuj iloj kaj kadroj estas skribitaj por Java, Python kaj JavaScript ĉar C++ kaj C# estas proprietaj (kvankam GCC estas malferma fonto).
Ni aplikis la testajn priraportajn ilojn, kaj nun la dukto DevOps devus aspekti kiel la bildo ĉe la komenco de la lernilo.
Pliaj paŝoj
Ujoj
Kiel mi diris antaŭe, aplikaĵo servilo povas esti gastigita en virtuala maŝino aŭ servilo, sed ujoj estas pli popularaj.
? Resume, en virtuala maŝino, la operaciumo ofte okupas pli da spaco ol la aplikaĵo, kaj ujo kutime sufiĉas kun kelkaj bibliotekoj kaj agordo. En iuj kazoj, virtualaj maŝinoj estas nemalhaveblaj, sed la ujo povas akomodi la aplikaĵon kune kun la servilo sen ekstra kosto.
Por ujoj, Docker kaj Kubernetes estas kutime prenitaj, kvankam ekzistas aliaj opcioj.
Legu artikolojn pri Docker kaj Kubernetes ĉe :
Middleware-aŭtomatigaj iloj
Nia DevOps-ĉeno koncentriĝas pri kunlabora konstruado kaj livero de aplikaĵo, sed estas aliaj interesaj aferoj, kiujn vi povas fari per DevOps-iloj. Ekzemple, uzu Infrastrukturon kiel Kodo (IaC) iloj, ankaŭ konataj kiel mezvaraj aŭtomatigaj iloj. Ĉi tiuj iloj helpas aŭtomatigi instaladon, administradon kaj aliajn taskojn por mezvaro. Ekzemple, ilo de aŭtomatigo povas preni aplikaĵojn (servilo de retprogramoj, datumbazo, monitoraj iloj) kun la ĝustaj agordoj kaj puŝi ilin al la aplikaĵoservilo.
Jen kelkaj opcioj por malfermitaj mezvarmaj aŭtomatigaj iloj:
Detaloj en la artikoloj :
Nun kio?
Ĉi tio estas nur la pinto de la glacimonto. La ĉeno DevOps povas fari multe pli. Komencu per CI/KD-ilo kaj vidu kion alian vi povas aŭtomatigi por faciligi vian laboron. Ne forgesu pri por efika kunlaboro.
Jen kelkaj pli bonaj artikoloj pri DevOps por komencantoj:
Vi ankaŭ povas integri DevOps per malfermaj lertaj iloj:
fonto: www.habr.com