Gvidilo por Komencantoj: Konstruado de DevOps Dukto

Se vi estas nova en DevOps, rigardu ĉi tiun kvin-paŝan gvidilon por krei vian unuan dukton.

Gvidilo por Komencantoj: Konstruado de DevOps Dukto

DevOps fariĝis la norma solvo por ripari malrapidajn, disajn aŭ rompitajn programajn evoluajn procezojn. La problemo estas, ke se vi estas nova en DevOps kaj ne scias kie komenci, eble vi mankas kompreno pri ĉi tiuj teknikoj. Ĉi tiu artikolo diskutos pri la difino de DevOps-dukto kaj ankaŭ provizos kvin-paŝajn instrukciojn por krei unu. Kvankam ĉi tiu lernilo ne estas ĝisfunda, ĝi devus doni al vi fundamenton por komenci vian vojaĝon kaj pligrandigi viajn sciojn en la estonteco. Sed ni komencu per la historio.

Mia DevOps Vojaĝo

Mi antaŭe laboris en la nuba teamo de Citi Group disvolvante TTT-aplikaĵon Infrastructure-as-a-Service (IaaS) por administri la nuban infrastrukturon de Citi, sed mi ĉiam interesiĝis pri kiel fari la disvolvan procezon pli efika kaj alporti pozitivan kulturan ŝanĝon al la evolua teamo. Mi trovis la respondon en libro rekomendita de Greg Lavender, CTO de Cloud Architecture and Infrastructure ĉe Citi. La libro estis nomita La Fenikso-Projekto (La Fenikso-Projekto), kaj ĝi klarigas la principojn de DevOps, sed ĝi legas kiel romano.

La tablo ĉe la malantaŭo de la libro montras kiom ofte malsamaj kompanioj deplojas siajn sistemojn en liberiga medio:

Amazono: 23 tage
Guglo: 5 tage
Netflix: 500 tage
Fejsbuko: Unufoje tage
Twitter: 3 fojojn semajne
Tipa firmao: Unufoje ĉiun 9 monatojn

Kiel Amazon, Google kaj Netflix-frekvencoj eĉ eblas? Ĉi tio estas ĉar ĉi tiuj kompanioj eltrovis kiel krei preskaŭ perfektan DevOps-dukton.

Ni estis malproksimaj de ĉi tio ĝis ni efektivigis DevOps ĉe Citi. Tiam mia teamo havis malsamajn mediojn, sed la deplojo sur la evoluservilo estis tute mana. Ĉiuj programistoj havis aliron al nur unu evoluservilo bazita sur IBM WebSphere Application Server Community Edition. La problemo estis, ke la servilo malŝaltus kiam pluraj uzantoj provas disfaldi samtempe, do la programistoj devis komuniki siajn intencojn unu al la alia, kio estis sufiĉe doloro. Plie, ekzistis problemoj kun malaltnivela testkodpriraportado, maloportunaj manaj deplojprocezoj, kaj la malkapablo spuri la deplojon de kodo asociita kun specifa tasko aŭ uzantrakonto.

Mi konstatis, ke io necesas fari kaj trovis samideanan kolegon. Ni decidis kunlabori pri konstruado de la komenca DevOps-dukto - li starigis Tomcat virtualan maŝinon kaj aplikaĵservilon dum mi laboris pri Jenkins, integris Atlassian Jira kaj BitBucket, kaj laboris pri testa koda priraportado. Ĉi tiu flankprojekto estis tre sukcesa: ni preskaŭ tute aŭtomatigis multajn procezojn, atingis preskaŭ 100% funkcian tempon en nia evoluservilo, disponigis spuradon kaj plibonigitan testan priraportadon de la kodo, kaj aldonis la kapablon ligi Git-branĉojn al Jira-problemoj aŭ deplojoj. Plej multaj iloj, kiujn ni uzis por konstrui nian DevOps-dukton, estis malfermfontaj.

Nun mi komprenas kiom simpla estis nia DevOps-dukto: ni ne uzis etendaĵojn kiel Jenkins-dosierojn aŭ Ansible. Tamen, ĉi tiu simpla dukto funkciis bone, eble pro la Pareto-principo (ankaŭ konata kiel la 80/20 regulo).

Mallonga Enkonduko al DevOps kaj la CI/CD Pipeline

Se vi demandas plurajn homojn, "Kio estas DevOps?", vi verŝajne ricevos plurajn malsamajn respondojn. DevOps, kiel Agile, evoluis por ampleksi multajn malsamajn disciplinojn, sed la plej multaj homoj konsentos pri kelkaj aferoj: DevOps estas programaro disvolva praktiko aŭ programaro evolua vivociklo (SDLC) kies centra dogmo ŝanĝas la kulturon en kiu programistoj kaj ne- programistoj ekzistas en medio en kiu:

Operacioj kiuj antaŭe estis faritaj mane estis aŭtomatigitaj;
Ĉiu faras tion, kion ili plej bone faras;
La nombro da efektivigoj dum certa tempodaŭro pliiĝas; Trapaso pliiĝas;
Pliigita disvolva fleksebleco.

Kvankam havi la ĝustajn programarajn ilojn ne estas la sola afero, kiun vi bezonas por krei DevOps-medion, iuj iloj estas esencaj. Ŝlosila ilo estas kontinua integriĝo kaj kontinua deplojo (CI/KD). En ĉi tiu dukto, medioj havas malsamajn stadiojn (ekz. DEV, INT, TST, QA, UAT, STG, PROD), multaj operacioj estas aŭtomatigitaj, kaj programistoj povas skribi altkvalitan kodon, atingi disvolvan lertecon kaj altajn deplojprocentojn.

Ĉi tiu artikolo priskribas kvin-ŝtupan aliron por krei DevOps-dukton kiel tiu montrita en la sekva diagramo uzante malfermfontajn ilojn.

Paŝo 1: CI/CD-Metodoj

La unua afero, kiun vi bezonas, estas CI/KD-ilo. Jenkins, malfermkoda ilo bazita sur Java kaj licencita sub la MIT-licenco, estas la ilo kiu popularigis DevOps kaj fariĝis la fakta normo.

Do kio estas Jenkins? Pensu pri ĝi kiel ia magia universala teleregilo, kiu povas paroli kaj organizi diversajn servojn kaj ilojn. Per si mem, CI/KD-ilo kiel Jenkins estas senutila, sed ĝi fariĝas pli potenca ĉar ĝi konektas al malsamaj iloj kaj servoj.

Jenkins estas nur unu el multaj malfermfontaj CI/KD-iloj, kiujn vi povas uzi por konstrui vian DevOps-dukton.

Jenkins: Krea Komunaĵo kaj MIT
Travis CI: MIT
Krozkontrolo:BSD
Konstruboto: GPL
Apache Gump: Apache 2.0
Cabie: GNU

Jen kiel aspektas DevOps-procezoj kun CI/CD-ilo:

Gvidilo por Komencantoj: Konstruado de DevOps Dukto

Vi havas CI/KD-ilon funkciantan sur via loka gastiganto, sed ne multe vi povas fari nuntempe. Ni transiru al la sekva etapo de la vojaĝo DevOps.

Paŝo 2: Administri Font-Kontrolsistemojn

La plej bona (kaj eble plej facila) maniero por kontroli, ke via CI/KD-ilo povas fari sian magion, estas integriĝi kun fontkoda kontrolo (SCM). Kial vi bezonas fontkontrolon? Ni diru, ke vi disvolvas aplikaĵon. Kiam ajn vi kreas aplikaĵon, vi programas, kaj ne gravas ĉu vi uzas Java, Python, C++, Go, Ruby, JavaScript aŭ iun el la miliardoj da programlingvoj. La kodo, kiun vi skribas, nomiĝas fontkodo. Komence, precipe kiam vi laboras sole, verŝajne estas bone meti ĉion en lokan dosierujon. Sed ĉar la projekto pligrandiĝas kaj vi invitas aliajn homojn kunlabori, vi bezonas manieron malhelpi konfliktojn dum efike dividante modifojn. Vi ankaŭ bezonas manieron restarigi antaŭajn versiojn, ĉar krei sekurkopiojn kaj kopii/alglui en ili malnoviĝas. Vi (kaj viaj samteamanoj) bezonas ion pli bonan.

Ĉi tie fontkoda kontrolo fariĝas preskaŭ neceso. Ĉi tiu ilo konservas vian kodon en deponejoj, kontrolas versiojn kaj kunordigas la laboron de la partoprenantoj de la projekto.

Kvankam ekzistas multaj fontkontrolaj iloj tie, Git estas la normo, kaj ĝuste. Mi tre rekomendas uzi Git, kvankam ekzistas aliaj malfermfontaj opcioj se vi preferas.

Git: GPLv2 kaj LGPL v2.1
Subversio: Apache 2.0
Sistemo de Samtempaj Versioj (CVS): GNU
Vesta: LGPL
Mercurial: GNU GPL v2+

Jen kiel aspektas DevOps-dukto kun aldono de fontkodaj kontroloj.

Gvidilo por Komencantoj: Konstruado de DevOps Dukto

CI/KD-ilo povas aŭtomatigi la procezojn de revizio, fontkoda akiro kaj kunlaboro inter membroj. Ne malbona? Sed kiel vi igas ĝin funkcianta aplikaĵo por ke miliardoj da homoj povu uzi kaj aprezi ĝin?

Paŝo 3: Kreu Konstruan Aŭtomatan Ilon

Bonege! Vi povas revizii kodon kaj fari ŝanĝojn al fontkontrolo, kaj inviti viajn amikojn kunlabori pri evoluo. Sed vi ankoraŭ ne kreis aplikaĵon. Por fari TTT-aplikaĵon, ĝi devas esti kompilita kaj pakita en deplojebla batformato aŭ ruliĝi kiel rulebla dosiero. (Notu, ke interpretita programlingvo kiel JavaScript aŭ PHP ne bezonas esti kompilita).

Uzu konstruan aŭtomatigan ilon. Ne gravas, kiun konstruan aŭtomatigan ilon vi decidas uzi, ili ĉiuj havas la saman celon: konstrui la fontkodon en iun deziratan formaton kaj aŭtomatigi la taskon purigi, kompili, testi kaj deploji al specifa medio. Konstruaj iloj varias laŭ via programlingvo, sed jen kelkaj oftaj malfermfontaj opcioj.

nomo
Permesilo
Programlingvo

Maven
Apache 2.0
java

Ant
Apache 2.0
java

gradle
Apache 2.0
java

bazel
Apache 2.0
java

fari
GNU
N / A

Grunti
MIT
JavaScript

Gluti
MIT
JavaScript

Konstruisto
Apache
Rubeno

Rake
MIT
Rubeno

AAP
GNU
python

SCons
MIT
python

BitBake
GPLv2
python

kuko
MIT
C#

ASDF
Elmigranto (MIT)
LISP

Preciza
BSD
Haskell

Bonege! Vi povas meti la agordajn dosierojn pri konstrua aŭtomatiga ilo en vian fontkontrolan sistemon kaj lasi vian CI/KD-ilon kunmeti ĉion.

Gvidilo por Komencantoj: Konstruado de DevOps Dukto

Ĉio estas en ordo, ĉu ne? Sed kie disfaldi vian aplikaĵon?

Paŝo 4: Reta Aplika Servilo

Nuntempe, vi havas pakitan dosieron, kiu povas esti aŭ plenumebla aŭ instalebla. Por ke iu ajn aplikaĵo estu vere utila, ĝi devas provizi ian servon aŭ interfacon, sed vi bezonas ujon por gastigi vian aplikaĵon.

TTT-aplikservilo estas ĝuste tia ujo. La servilo disponigas medion en kiu la logiko de la pakaĵo estanta deplojita povas esti difinita. La servilo ankaŭ disponigas interfacon kaj ofertas retservojn elmontrante ingojn al la ekstera mondo. Vi bezonas HTTP-servilon, same kiel iun medion (kiel virtuala maŝino) por instali ĝin. Nuntempe, ni supozu, ke vi lernos pli pri tio (kvankam mi kovros ujojn sube).

Ekzistas pluraj malfermfontaj ret-aplikaj serviloj.

nomo
Permesilo
Programlingvo

Tomcat
Apache 2.0
java

Jetty
Apache 2.0
java

Sovaĝa Muŝo
GNU Malgranda Publiko
java

Vitrofiŝo
CDDL & GNU Malpli Publika
java

Django
3-Klazo BSD
python

Revenita
Apache 2.0
python

Gunicorno
MIT
python

python
MIT
python

Ruloj
MIT
Rubeno

node.js
MIT
Javascript

Via DevOps-dukto estas preskaŭ preta por uzi. Bona laboro!

Gvidilo por Komencantoj: Konstruado de DevOps Dukto

Dum vi povas halti tie kaj pritrakti la integriĝon mem, kodkvalito estas grava afero por ke aplikaĵa programisto zorgu pri tio.

Paŝo 5: Koda Testa Kovrado

Efektivigo de testoj povas esti alia maloportuna postulo, sed programistoj devas frue kapti iujn cimojn en la aplikaĵo kaj plibonigi la kvaliton de la kodo por certigi ke finaj uzantoj estas kontentaj. Feliĉe, ekzistas multaj malfermfontaj iloj por testi vian kodon kaj fari rekomendojn por plibonigi ĝian kvaliton. Kio estas eĉ pli bona estas, ke la plej multaj CI/KD-iloj povas konekti al ĉi tiuj iloj kaj aŭtomatigi la procezon.

Kodotestado konsistas el du partoj: koda testado kadroj kiuj helpas vin skribi kaj fari testojn, kaj sugestaj iloj kiuj helpas vin plibonigi la kvaliton de via kodo.

Kodaj testaj sistemoj

nomo
Permesilo
Programlingvo

JUnit
Eklipso Publika Permesilo
java

EasyMock
Apache
java

mockito
MIT
java

PowerMock
Apache 2.0
java

Pytest
MIT
python

Hipotezo
Mozilla
python

tox
MIT
python

Rekomendaj sistemoj por koda plibonigo

nomo
Permesilo
Programlingvo

Kostumo
GNU
java

Kodkovrilo
Eklipso Publiko (EPL)
java

Kovrado.py
Apache 2.0
python

emma
Komuna Publika Permesilo
java

JaCoCo
Eklipso Publika Permesilo
java

Hipotezo
Mozilla
python

tox
MIT
python

Jasmine
MIT
JavaScript

Karmo
MIT
JavaScript

Mocha
MIT
JavaScript

Ŝerco
MIT
JavaScript

Rimarku, ke la plej multaj el la iloj kaj kadroj menciitaj supre estas skribitaj por Java, Python kaj JavaScript, ĉar C++ kaj C# estas proprietaj programlingvoj (kvankam GCC estas malfermkoda).

Nun kiam vi efektivigis testajn priraportajn ilojn, via DevOps-dukto devus aspekti simila al la diagramo montrita ĉe la komenco de ĉi tiu lernilo.

Pliaj paŝoj

Ujoj

Kiel mi diris, vi povas gastigi vian servilon sur virtuala maŝino aŭ servilo, sed ujoj estas populara solvo.

Kio estas ujoj? La mallonga klarigo estas, ke virtuala maŝino bezonas grandegan kvanton da operaciuma memoro, superante la grandecon de la aplikaĵo, dum ujo nur bezonas kelkajn bibliotekojn kaj agordojn por ruli la aplikaĵon. Evidente, ankoraŭ ekzistas gravaj uzoj por virtuala maŝino, sed ujo estas malpeza solvo por gastigado de aplikaĵo, inkluzive de aplikaĵoservilo.

Kvankam ekzistas aliaj uj-opcioj, la plej popularaj estas Docker kaj Kubernetes.

Docker: Apache 2.0
Kubernetes: Apache 2.0

Mezaj aŭtomatigaj iloj

Nia DevOps-dukto ĉefe koncentriĝas pri kunlabora kreado kaj disvastigo de aplikaĵoj, sed estas multaj aliaj aferoj, kiuj povas esti faritaj per DevOps-iloj. Unu el ili estas la uzo de iloj de Infrastrukturo kiel Kodo (IaC), kiuj ankaŭ estas konataj kiel iloj de aŭtomatigo de mezaj programoj. Ĉi tiuj iloj helpas aŭtomatigi instaladon, administradon kaj aliajn taskojn por mezvaro. Do, ekzemple, aŭtomatiga ilo povas ĉerpi aplikojn kiel TTT-aplikservilo, datumbazo kaj monitora ilo kun la ĝustaj agordoj kaj disfaldi ilin al la aplikaĵoservilo.

Jen kelkaj malfermfontaj mezvaraj aŭtomatigaj iloj:

Ansible: GNU Publiko
SaltStack: Apache 2.0
Kuiristo: Apache 2.0
Marioneto: Apache aŭ GPL

Gvidilo por Komencantoj: Konstruado de DevOps Dukto

Eltrovu la detalojn pri kiel akiri serĉatatan profesion de nulo aŭ Level Up laŭ kapabloj kaj salajro kompletigante SkillFactory pagitaj interretaj kursoj:

pli da kursoj

Utila

fonto: www.habr.com

Aldoni komenton