Bi vê zanînê re biçe ku derê, di projeyê de çi bike û çiqas qezenc bike, di hevpeyivînekê de çi bêje û bipirse - dibêje Alexander Titov, hevkarê rêveberê Express 42 û nivîskar. .
Slav! Her çend peyva DevOps ji sala 2009-an vir ve heye, hîn jî di civata rûsî de lihevhatinek tune. We belkî ferq kiriye ku hin DevOps taybetmendiyek dihesibînin, yên din wê felsefeyek dihesibînin, û yên din jî termê komek teknolojiyê dihesibînin. Min berê jî gelek caran pê re pêk anî di derbarê pêşveçûna vî alî de, ji ber vê yekê ez ê di vê gotarê de neçim nav hûrgulî. Bihêle ez tenê bibêjim ku li Express 42 em di wê de jêrîn vedigirin:
DevOps rêbazek taybetî ye, çandek afirandina hilberek dîjîtal, dema ku hemî pisporên tîmê beşdarî hilberînê dibin.
Di pêşkeftina pargîdanî ya klasîk de, her tişt bi rêz derbas dibe: bernamekirin, ceribandin û tenê wê hingê xebitandin, û leza vê pêvajoyê ji ramanê heya hilberînê 3 meh e. Ev ji bo hilberên dîjîtal pirsgirêkek gerdûnî ye, ji ber ku ne mimkun e ku meriv zû bersiv ji xerîdaran bistîne.
Di DevOps de, amûr û nêzîkatî têne sêwirandin da ku pê ewle bibin ku pêvajoyên pêşkeftin, ceribandin û xebitandinê bi hevdemî dimeşînin.
Ji vê nêzîkatiyê çi derdikeve?
- Hûn nekarin hin "endezyar" ku werin û hemî pirsgirêkan bi hilberînê re çareser bikin bigirin. Divê tevahiya tîmê teknîkê bicîh bîne.
- DevOps NE forma paşîn a sysadmin-ê ye ku jê were nûve kirin. "endazyarê DevOps" bi heman rengî wekî "pêşdebirê Agile" dixuye.
- Ger tîmek Kubernetes, Ansible, Prometheus, Mesosphere û Docker bikar bîne, ev nayê vê wateyê ku pratîkên DevOps li wir hatine bicîh kirin.
Jiyana piştî DevOps dê çu carî nebe
Nêzîkatiya DevOps, berî her tiştî, ramanek cûda ye, têgihîştina pêşveçûnê bi tevahî û cîhê yek di pêvajoyê de ye. Me qursa xweya serhêl li 2 blokan dabeş kir:
1. Xweserîkirin
Pêşîn, em bi hûrgulî cewhera nêzîkatiya DevOps lêkolîn dikin, û xwendekar di tîmê de rolên nû kifş dikin, dibînin ku kîjan bêtir bersivê dide, û ji xwe re diyar dikin ku kîjan rêgezê pêşve bibin.
2. Amûr û pratîk
Xwendekar ji hêla rêbaza DevOps ve teknolojiyên taybetî master dikin.
Amûrên DevOps hem di nêzîkatiya DevOps de hem jî di pêşkeftina klasîk de têne bikar anîn. Mînaka herî berbiçav dê karanîna amûra rêveberiya mîhengê Ansible be. Ew ji bo pêkanîna pratîka DevOps "Binesaziya wekî Kodê" hate afirandin û fikirîn, ku tê vê wateyê ku rewşên cihêreng ên pergalê têne vegotin, ji mîhengên pergala xebitandinê heya nermalava serîlêdanê. Danasîn di qatan de tê dabeş kirin û dihêle hûn mîhengek tevlihev, bi domdarî diguhezin rêvebirin. Lê endezyar bi gelemperî Ansible-ê wekî rêgezek bikar tînin ku li ser gelek makîneyan nivîsên bash dimeşînin. Ev ne xirab û ne baş e, lê hûn hewce ne ku fêm bikin ku hebûna Ansible hebûna DevOps di pargîdaniyê de garantî nake.
Em di pêvajoyê de ne Hûn ê di pêvajoya pêşvebirina serîlêdanek mîna Reddit-a navdar de bin, bi guhertoya wê ya monolîtîk dest pê bikin, gav bi gav berbi mîkroservisan ve biçin. Gav bi gav em ê amûrên nû serdest bikin: Git, Ansible, Gitlab û bi Kubernetes û Prometheus biqedînin.
Di warê pratîkan de, em ê taktîkên sê rêyên ku di Destana DevOps de hatine diyar kirin bişopînin - pratîkên radestkirina domdar, pratîkên bersivdayînê, û cewherê qursê pratîka fêrbûna domdar digel pergala we ye.
Ev zanîn çi dide her yek ji pisporan?
Ji bo rêveberên pergalê
Pratîk dê bihêle ku hûn ji rêveberiyê dûr bikevin ber bi afirandina boriyek radestkirina domdar û platformek binesaziyê ji bo radestkirina nermalavê. Mesele ev e ku ew hilberek diafirîne - platformek binesaziyê ji bo pêşdebiran ku ji wan re dibe alîkar ku zû guheztinên xwe ber bi hilberînê ve bikişînin.
Berê, rêveberên pergalê baskê paşîn bûn, piştî ku her tişt diçe hilberînê. Û di bingeh de ew bi agirkujiya domdar ve mijûl bûn - di ronahiya vê de pir dijwar e ku meriv li hewcedariyên karsaziyê hûr bibe, li ser hilber û feydeyên ji bo bikarhêner bifikirin.
Bi saya rêbaza DevOps, fikir diguhere. Rêvebirê pergalê fam dike ka meriv çawa veavakirinê li kodê vedigerîne, ji bo vê çi pratîk hene.
Ev girîng e ji ber ku pargîdan her ku diçe fêhm dikin ku ew ne tenê hewce ne ku her tiştî otomatîk bikin, ango. di tiştê ku rêvebirên pergala dibistana kevin di bingeh de dihatin bikar anîn, yên ku ji bilî vê yekê hindik ragihandin û tîmê li ser hemî guhertinên hatine çêkirin agahdar nekir. Naha tîm li wan kesan digerin ku dê bibin hilberînerê hilberîna binesaziya navxweyî û bibin alîkar ku pêvajoyên veqetandî li hev bikin.
Developers
Pêşvebir tenê di algorîtmayan de difikire. Ew jêhatiya xebata bi binesaziyê, jêhatiya hişmendiya mîmarî ya perestgehê bi dest dixe. Pêşvebirek wusa fam dike ka serîlêdan çawa dixebite, ew çawa di xeta radestkirina domdar re derbas dibe, meriv wê çawa dişopîne, meriv wê çawa tomar dike da ku ji xerîdar sûd werbigire. Wekî encamek, hemî ev zanîn dihêle hûn koda têkildar binivîsin.
Ji bo ceribandinan
Ceribandin ji zû ve derbasî moda otomatîkî bûye; em hemî dibêjin ku divê gelek ceribandin neyên kirin, lê bêne nivîsandin :) Testkirin dibe beşek ji tevahiya lûleya radestkirina hilberê we. Pêdivî ye ku ceribandinek ne tenê fêr bibe ka meriv çawa kodê dinivîse, lê di heman demê de jî fêm bike ka meriv wê çawa di pergalên radestkirina domdar de entegre dike, meriv çawa di hemî qonaxên radestkirinê de ji kodê bertek werdigire, û meriv çawa bi berdewamî ceribandinê baştir dike da ku xeletiyan bibîne. zû zû.
Ji ber vê yekê derdikeve holê her sê qonax bi hev re pêk tên. Mînakî, dibe ku bi vî rengî xuya bike:
Pêşdebir kodê dinivîse, tavilê ji bo wê ceribandinan dinivîse, û ji bo koda ku divê were xebitandin konteynirek dokerê vedibêje. Di heman demê de yekser çavdêriya ku dê xebata vê karûbarê di hilberînê de bişopîne diyar dike û van hemîyan dike.
Dema ku entegrasyona domdar dest pê dike, pêvajoyên hevdemî dimeşînin. Xizmet dest pê dike û tê mîheng kirin. Di heman demê de, konteynera docker dest pê dike û tê kontrol kirin ku ew dimeşe. Di heman demê de, hemî agahdarî diçe pergala têketinê. Û bi vî awayî di her qonaxek pêşveçûnê de - ew xuya dibe ku tîmê rastîn a rêveberên pergalê, pêşdebir û ceribandinan e.
Min DevOps xwend, paşê çi?
Wek hûn jî dizanin, li meydanê yekî ne şervan e. Ger pargîdaniya we vê rêbazê bikar neyîne, jêhatîbûna bidestxistî dê bêkar bimîne. Û piştî ku hûn bi nêzîkatiyên DevOps re nas kirin, bi îhtîmalek mezin hûn ê nexwazin ku di pêşkeftina pargîdanî de bibin cog. Dibe ku yek îstîsna hebe: hûn di tîmê de rêveberek pergalê ne û dikarin hemî pêvajoyên bi rengek nû ji nû ve ava bikin. Hêjayî gotinê ye ku li vir pir pargîdanî hene ku vê nêzîkatiyê bikar tînin, û ew ji qefilandinê bandor nabin û li pisporan digerin. Ji ber ku DevOps di derbarê afirandina hilberên serhêl de ye.
Û naha di derbarê tiştên baş de: serweriya pratîk û amûrên DevOps bi qasî +30% ji nirxa we ya li ser bazara kedê ye. Meaş ji 140 hezar rubleyan dest pê dike, lê bi xwezayî, ji hêla taybetî û fonksiyona weya sereke ve têne destnîşankirin.
Hûn dikarin li valahiyên ku bi "binesaziyê ve girêdayî ne" binihêrin, li wir otomasyona ceribandinê, pêşkeftina sepanên mîkroxizmetê bi karanîna teknolojiyên ewr, valahiyên endezyarên binesaziyê û her cûre referansên DevOps hene. Tenê ji bîr mekin ku her pargîdanî ji hêla vê pênaseyê ve tê wateya tiştek cûda - bi baldarî danasînê bixwînin.
Di dema destpêkirina qursa me de, têgihîştinek ji min re hat - gelek kes piştî qursê dikevin xefika endezyarek DevOps. Ew bi sernavê jorîn valahiyek peyda dikin, pêşniyarek baş werdigirin, û dûv re têne ser kar û fêhm dikin ku ew ê neçar in ku li Jenkins nivîsarek bash a sê-rûpelî biparêzin. Kubernetes, ChatOps, serbestberdanên canary û her tiştî li ku ne? Lê tiştek tune, ji ber ku pargîdanî wekî rêbazek pêdivî bi DevOps nake, lê nûbûnên kesane bikar tîne.
Ev sedemek e ku meriv bi tundî ji pargîdaniyê fêr bibe ka pêvajoya radestkirina nermalavê çawa dixebite, stûna teknolojiyê û hûn ê çi berpirsiyariyan bikin.
Ger kardêr bersivê bide pirsên we bi rengekî abstrakt, mîna ku ji pirtûkek be, bêyî hûrgulî, wê hingê bi îhtîmalek mezin hîn di pargîdaniyê de pêvajoyek DevOps tune ye, lê ev ne sedemek redkirina, lêkolîna pargîdanî û hilberên wê ye, gelo serhêl hene. karûbarên ku pargîdanî bi xwe pêşve dike, serîlêdanên mobîl, ramanên hilberê.
Ger erê, wê hingê zelal bikin gelo hûn ê neçar bimînin ku rasterast bi van pergalan re bixebitin an gelo dema ku di pratîkên DevOps de encamên baş nîşan didin îhtîmala tevgera horizontî ya tîmên van karûbaran heye. Ger erê, wê hingê hêja ye ku hûn biçin û çalak û kêrhatî bin, û ger hûn qursa me temam bikin, ya paşîn garantî ye.
Girîng e ku bala xwe bidinê ku bijîjkên Devops tenê bi ezmûna di pêşkeftin / rêveberî / ceribandinê de nirxa rastîn digirin. Tenê wê hingê dê zanîn ne razber be, lê pispor (bi her wateyê) dewlemend bike. Ji ber vê yekê, ramana "hînbûna DevOps ji sifrê" bi heman rengî ye ku hûn fêr bibin "bikaranîna lensên ji sifirê" heke we qet kamerayek di destên xwe de negirtiye an jî kişandinek derhênerî nekiribe. Ji bo ku ji we re bibe alîkar ku hûn biryar bidin ka qurs ji we re rast e, me ceribandinek têketinê çêkiriye ku dê asta zanîna weya têr kontrol bike.
Ez yek ji hîleyan difikirim - ku di dema perwerdehiyê de her xwendekarek bi xwe diyar dike ku ew dixwaze di kîjan alî de pêşve bibe. Em pir caran gava ku pêşdebirek dibe endezyarek binesaziyê, û rêveberek pê dihese ku ew bi nivîsandina kodê re eleqedar e - wê hingê ew ziman bêtir dixwîne û bi jêhatîyên DevOps-ê yên bidestxistî re lê zêde dike. Ji ber vê yekê, em bi taybetî pêşwaziya wan kesan dikin ku hest dikin ku kariyera wan di çarçoveyek de asê maye. Kurs di 28ê Gulanê de dest pê dike, lê hûn dikarin 2 hefte piştî destpêkirina dersan beşdarî bibin. Hûn dikarin bernameyê bibînin û testê bikin . We li OTUS bibînin!
Source: www.habr.com