<\/a><\/noindex>DevOps h\u00f5lmab palju erinevaid kontseptsioone (pidev kohaletoimetamine, pidev integreerimine, automatiseerimine jne), seet\u00f5ttu v\u00f5ib peamise eristamine osutuda keeruliseks, eriti kui teema on teile oluline. Siiski on see oskus v\u00e4ga kasulik, olgu te siis p\u00fc\u00fcdes oma ideid \u00fclemusele edastada v\u00f5i lihtsalt r\u00e4\u00e4kides oma t\u00f6\u00f6st pereliikmetele v\u00f5i tuttavatele. Seega, l\u00fckake DevOps'i terminoloogilised n\u00fcansid hetkeks k\u00f5rvale ja keskenduge \u00fcldisele pildile.<\/p>\n
Mis on DevOps: 6 m\u00e4\u00e4ratlust ja analoogiat<\/h3>\n \nPalusime spetsialistidel selgitada DevOps'i olemust nii lihtsalt ja l\u00fchidalt, et selle v\u00e4\u00e4rtus oleks m\u00f5istetav iga tasemega tehnilise ettevalmistusega lugejale. Nende vestluste tulemuseks valisime v\u00e4lja k\u00f5ige silmapaistvamad analoogiad ja tabavad v\u00e4ljendid, mis aitavad teil oma lugu DevOps'ist \u00fcles ehitada.<\/p>\n
1. DevOps on kultuuriline liikumine<\/h4>\n \n\u201eDevOps on kultuuriline liikumine, kus m\u00f5lemad osalised (tarkvaraarendajad ja IT-s\u00fcsteemide haldajad) tunnistavad, et tarkvara ei too reaalselt kasu, kuni seda ei hakata kasutama: olgu need kliendid, tellijad v\u00f5i t\u00f6\u00f6tajad \u2013 \u00fctleb Eveline Oehrlich, DevOps Instituudi vanemanal\u00fc\u00fctik. \u2013 Seet\u00f5ttu tagavad m\u00f5lemad pooled koos kiire ja kvaliteetse tarkvara kohaletoimetamise.\u201c<\/p>\n
2. DevOps on see, mis annab arendajatele volitused<\/h4>\n \n\u201eDevOps annab arendajatele volitused rakenduste omanikkonnaks, nende k\u00e4ivitamiseks ja juhtimiseks alates algusest kuni l\u00f5puni\u201c<\/b><\/p>\n
\u201eTavaliselt r\u00e4\u00e4gitakse DevOpsist kui viisist kiirendada rakenduste kohaletoimetamist tootmisse, ehitades ja kasutades automatiseeritud protsesse,\u201c \u00fctleb Jai Schniepp, Liberty Mutuali kindlustusettev\u00f5tte DevOps platvormide direktor. \u201eKuid minu jaoks on see palju fundamentaalsem asi. DevOps annab arendajatele volitused rakenduste v\u00f5i teatud tarkvarade osade omanikkonnaks, nende k\u00e4ivitamiseks ja kohaletoimetamise juhtimiseks alates algusest kuni l\u00f5puni. DevOps kaotab segaduse vastutuses ja suunab k\u00f5ik osalised protsessi loomise suunas, milleks on automatiseeritud ja arendaja juhitud infrastruktuur.\u201d<\/p>\n
3. DevOps on koost\u00f6\u00f6 rakenduste loomisel ja kohaletoimetamisel<\/h4>\n \n\u201eLihtsamalt \u00f6eldes on DevOps l\u00e4henemine tarkvara tootmisele ja kohaletoimetamisele, kus k\u00f5ik t\u00f6\u00f6tavad koos,\u201c m\u00e4rgib Gur Staff, BMC digitaalsete \u00e4riprotsesside automatiseerimise president ja juht.<\/p>\n
4. DevOps on konveier<\/h4>\n \n\u201eKonveierikogumine on v\u00f5imalik ainult siis, kui k\u00f5ik osad sobivad \u00fcksteisega.\u201c<\/b><\/p>\n
\u201eV\u00f5rreldes DevOpsit autotootmise konveieriga,\u201c j\u00e4tkab Gur Staff. \u201eIdee on eelnevalt projekteerida ja valmistada k\u00f5ik osad nii, et need oleksid hiljem v\u00f5imalik kokku panna ilma individuaalse kohandamiseta. Konveierikogumine on v\u00f5imalik ainult siis, kui k\u00f5ik osad sobivad \u00fcksteisega. Need, kes projekteerivad ja valmistavad mootorit, peavad m\u00f5tlema sellele, kuidas see kinnitada kerele v\u00f5i raami. Need, kes valmistavad pidureid, peavad m\u00f5tlema ratastele ja nii edasi. Samuti peaks olema ka tarkvaraga. <\/p>\n
Arendaja, kes loob \u00e4ri\u00fclevaate v\u00f5i kasutajaliidese, peab m\u00f5tlema andmebaasile, mis sisaldab teavet klientide kohta, andmete kaitseks m\u00f5eldud turvameetmetele, samuti sellele, kuidas see k\u00f5ik t\u00f6\u00f6tab, kui teenus hakkab teenindama suurt, v\u00f5ib-olla isegi miljonite kasutajate hulka.<\/p>\n
\u201eTeha nii, et inimesed teeksid koost\u00f6\u00f6d ja m\u00f5tleksid nende t\u00f6\u00f6osade peale, mida teised teevad, mitte ei keskenduks ainult omaenese \u00fclesannetele \u2013 see on suurim takistus, mis tuleb \u00fcletada. Kui see \u00f5nnestub, on teil suurep\u00e4rased v\u00f5imalused digitaalseks transformatsiooniks,\u201c lisab Gur Staff.<\/p>\n
5. DevOps on \u00f5ige kombinatsioon inimestest, protsessidest ja automatiseerimisest.<\/h4>\n \nJayne Groll, DevOpsi Instituudi tegevjuht, pakkus suurep\u00e4rase analoogia DevOpsi seletamiseks. Tema s\u00f5nul on \u201eDevOps nagu kulinaarne retsept, milles on kolm peamist koostisosade kategooriat: inimesed, protsessid ja automatiseerimine. Enamik neist koostisosadest v\u00f5ib tulla teistest valdkondadest ja allikatest: Lean, Agile, SRE, CI\/CD, ITIL, juhtimine, kultuur, t\u00f6\u00f6riistad. DevOpsi saladus, nagu igas heas retseptis, seisneb selles, kuidas \u00f5igesti valida proportsioonid ja segada neid koostisosade, et suurendada t\u00f6\u00f6 efektiivsust ja tulemuslikkust rakenduste loomisel ja v\u00e4ljalaskmisel.\u201d<\/p>\n
6. DevOps on siis, kui programmeerijad t\u00f6\u00f6tavad nagu vormel-1 meeskond.<\/h4>\n \n\u201eV\u00f5istlust planeeritakse mitte stardist fini\u0161isse, vaid vastupidi, fini\u0161ist stardisse.\u201c<\/b><\/p>\n
\u201eR\u00e4\u00e4kides sellest, mida oodata DevOpsi algatuselt, toon ma n\u00e4itena NASCAR v\u00f5i vormel-1 v\u00f5istkonna,\u201c \u00fctleb Chris Short, Red Hat'i pilveteenuste turundusjuht ja DevOps\u2019ish uudiskirja toimetaja. \u201eSelle v\u00f5istkonna juhil on \u00fcks eesm\u00e4rk: saavutada v\u00f5idus\u00f5idu l\u00f5pus maksimaalne v\u00f5imalik koht, arvestades v\u00f5istkonna ressursse ja katsumusi, mis talle on osaks saanud. Sellega seoses on v\u00f5istlust planeeritud mitte stardist fini\u0161isse, vaid vastupidi, fini\u0161ist stardisse. Alguses seatakse ambitsioonikas eesm\u00e4rk ja seej\u00e4rel m\u00e4\u00e4ratakse vastavad teed selle saavutamiseks. Seej\u00e4rel jagatakse need alam\u00fclesanneteks ja delegatakse tiimiliikmetele.\u201c<\/p>\n
\u201eKogu n\u00e4dala enne v\u00f5istlust lihvib meeskond pit-stop'pe. Tegeletakse j\u00f5u- ja kardiotreenidega, et olla vormis pingelisel v\u00f5istlusp\u00e4eval. Harjutatakse koost\u00f6\u00f6d, et lahendada mis tahes probleeme, mis v\u00f5ivad v\u00f5istluse ajal tekkida. Samamoodi peavad arendajate meeskonnad harjutama oskusi uute versioonide sagedaseks v\u00e4ljalaskmiseks. Kui need oskused on olemas ja turvas\u00fcsteem on paika pandud, toimub uute versioonide lansseerimine tootmisse samuti sagedamini. Selle maailmavaate raames t\u00e4hendab kiirus t\u00f5usu ka turvalisust,\u201c \u00fctleb Short.<\/p>\n
\u201eAsi ei ole teha '\u00f5igeid asju',\u201c lisab Short, \u201evaid pigem k\u00f5rvaldada v\u00f5imalikult palju takistusi, mis seisavad tee peal soovitud tulemuse saavutamisele. Koost\u00f6\u00f6d tehke ja kohaneda tuleb tagasisidega, mida saad reaalajas. Olge valmis anomaaliateks ja t\u00f6\u00f6tage kvaliteedi t\u00f5stmise nimel, et v\u00e4hendada nende m\u00f5ju sihile liikumisele. Just seda ootame me DevOpi maailmas.\u201c<\/p>\n
Kuidas skaleerida DevOps: 10 ekspertide n\u00f5uannet<\/h3>\n \nLihtne DevOps ja massiline DevOps on t\u00e4iesti erinevad asjad. R\u00e4\u00e4gime, kuidas \u00fcletada takistused selle kahe vahel.<\/b><\/p>\n
Paljude organisatsioonide jaoks algab tee DevOps'ini lihtsalt ja meeldivalt. Luua saab v\u00e4ikseid kirglikke meeskondi, vanad protsessid asendatakse uutega ja esimesed edusammud ei lase kaua oodata.<\/p>\n
Kahjuks on see vaid vale s\u00e4ra, progressi illusioon, nagu \u00fctleb Ben Grinnell, North Highlandi konsultatsioonifirma digitaalsete tehnoloogiate juht. Varajased v\u00f5idud on kindlasti julgustavad, kuid need ei aita saavutada l\u00f5ppeesm\u00e4rki, milleks on DevOps'i massiline kasutuselev\u00f5tt organisatsioonis.<\/p>\n
On lihtne n\u00e4ha, et selle tulemuseks tekib kultuur, kus jagunetakse 'me' ja 'nemad'.<\/b><\/p>\n
\u00abSageli k\u00e4ivitavad organisatsioonid selliseid pioneerprojekte, arvates, et need rajavad teed laialdasele DevOps'ile, m\u00f5tlemata sellele, kas teised soovivad ja suudavad sellel teel k\u00e4ia, - selgitab Ben Greennell. - Need projektide meeskonnad koosnevad tavaliselt enesekindlatest \"v\u00e4ravatest\", kes on varem sarnaseid asju teinud, kuid on teie organisatsioonis alles algajad. Neid julgustatakse rikkuma ja h\u00e4vitama reegleid, mis kehtivad k\u00f5igile teistele. On lihtne n\u00e4ha, et selle tulemusena tekib \"meie\" ja \"nemad\" kultuur, mis takistab teadmiste ja oskuste jagamist.\"<\/p>\n
\u00abJa see kultuuriline probleem on vaid \u00fcks p\u00f5hjustest, miks DevOps'i on keeruline skaleerida. DevOps'i meeskonnad seisavad silmitsi tehniliste keerukustega, mis on iseloomulikud kiiresti arenevatele ettev\u00f5tetele, kes on panustanud IT-tehnoloogiale,\u00ab \u00fctleb Steve Newman, ettev\u00f5tte Scalyr kaasasutaja ja juhatuse esimees.<\/p>\n
\u00abKaasaegses maailmas muutuvad teenused kohe, kui tekib vajadus. Uute funktsioonide pidev rakendamine ja juurutamine on muidugi suurep\u00e4rane, kuid selle protsessi koordineerimine ja tekkivate probleemide lahendamine on t\u00f5eline peavalu,\u00ab lisab Steve Newman. - V\u00e4ga kiiresti kasvavates organisatsioonides v\u00f5itlevad insenerid ristfunktsionaalsetes meeskondades v\u00f5imaluse nimel j\u00e4lgida muudatusi ja nende tekitatud kaskaade s\u00f5ltuvustasandil. Veelgi enam, inseneridele ei meeldi, kui nad sellest v\u00f5imalusest ilma j\u00e4\u00e4vad ja seet\u00f5ttu on neil raskem aru saada tekkivate probleemide olemusest.\"<\/p>\n
Kuidas \u00fcletada eespool kirjeldatud raskused ja liikuda DevOps'i massilise kasutuselev\u00f5tu poole suure organisatsiooni raames? Eksperdid kutsuvad \u00fcles olema kannatlikud, isegi kui teie l\u00f5ppeesm\u00e4rk on kiirendada tarkvaraarenduse ja \u00e4riprotsesside ts\u00fcklit.<\/b><\/p>\n1. Pidage meeles, et kultuuri muutmiseks on vaja aega<\/h4>\n
\nJayne Groll, DevOpsi instituudi tegevjuht:<\/b> Minu arvates peaks DevOps'i laienemine olema sama j\u00e4rkj\u00e4rguline ja iteratiivne kui agile-arendamine (ning m\u00f5jutama kultuuri sama palju). Agile'is ja DevOps'is keskendutakse v\u00e4ikestele meeskondadele. Kuid kui nende meeskondade arv kasvab ja nad integreeruvad, on \u00fcha rohkem inimesi, kes rakendavad uusi t\u00f6\u00f6meetodeid, ja sellest tulenevalt toimub ulatuslik kultuuriline transformatsioon.<\/p>\n2. P\u00f6\u00f6rake piisavalt aega planeerimisele ja platvormi valimisele<\/h4>\n
\nEran Kinsbruner, Perfecto juhtiv tehniline evangelist:<\/b> \u201eEt skaleerimine t\u00f6\u00f6taks, peavad DevOps'i meeskonnad alguses \u00f5ppima kombineerima traditsioonilisi protsesse, t\u00f6\u00f6riistu ja oskusi ning seej\u00e4rel j\u00e4rk-j\u00e4rgult kasvatama igat DevOps'i etappi ja stabiliseerima seda. K\u00f5ik algab hoolikast kasutajate lugude (user story) ja v\u00e4\u00e4rtuse loomise voogude (value stream) planeerimisest, millele j\u00e4rgneb tarkvara kirjutamine ja versioonihaldus trunk-based development'i v\u00f5i teiste l\u00e4henemisviiside abil, mis on k\u00f5ige sobivamad koodi harude ja sulandumise jaoks.\u201d<\/p>\n
\u201eJ\u00e4rgneb integratsiooni ja testimise etapp, kus on juba vajalik skaleeritav automaatikaplatvorm. Siin on DevOps'i meeskondade jaoks oluline valida \u00f5ige platvorm, mis vastab nende oskuste tasemele ja projekti l\u00f5ppeesm\u00e4rkidele. <\/p>\n
J\u00e4rgmine etapp on juurutamine tootmiskeskkonnas, mis peaks olema t\u00e4ielikult automatiseeritud, kasutades orkestreerimise ja konteinerite t\u00f6\u00f6riistu. Oluline on omada virtualiseeritud keskkondi k\u00f5igis DevOps'i etappides (tootmiskeskkonna simulaator, kvaliteedikontrolli keskkond ja tegelik tootmiskeskkond) ning alati kasutada testimisteks vaid k\u00f5ige v\u00e4rskemaid andmeid, et saada asjakohaseid j\u00e4reldusi. Anal\u00fc\u00fctika peab olema nutikas ja suutma t\u00f6\u00f6delda suuri andmeid kiire ja t\u00f5husaga tagasiside saamiseks.\u201d<\/p>\n
3. Vabastage vastutus s\u00fc\u00fc eest<\/h4>\n \nGordon Haff, RedHati evangelist:<\/b> \u201eS\u00fcsteemi ja atmosf\u00e4\u00e4ri loomine, mis lubab ja julgustab katsetamist, v\u00f5imaldab saavutada nn edukaid eba\u00f5nnestumisi agile tarkvaraarenduses. See ei t\u00e4henda, et keegi ei vastuta eba\u00f5nnestumiste eest. Tegelikult on vastutuse m\u00e4\u00e4ramine isegi lihtsam, kuna \u201evastutav\u201d ei t\u00e4henda enam \u201e\u00f5nnetuse p\u00f5hjustaja\u201d olemist. Seega vastutuse olemus muutub kvaliteetselt. Samuti saavad \u00e4\u00e4rmiselt t\u00e4htsaks neli tegurit: eba\u00f5nnestumise ulatus, l\u00e4henemisviisid, tootmisprotsessid ja stiimulid\u201c. (Nende tegurite kohta saab l\u00e4hemalt lugeda Gordon Huffs artiklist \u201eDevOps lessons: 4 aspects of healthy experiments\u201c.)<\/p>\n4. Puhastage tee edasi<\/h4>\n
\nBen Grinnell, North Highlandi konsultatsioonifirma digitaalsete tehnoloogiate direktor:<\/b> \u201eSkaaleerimise saavutamiseks soovitan koos esmakordsete projektidega k\u00e4ivitada \u201etee puhastamise\u201d programmi. Selle programmi eesm\u00e4rk on eemaldada pr\u00fcgi, mis j\u00e4\u00e4b DevOpsi esmakordsetelt, nagu aegunud reeglid ja muud sarnased asjad, et tee edasi j\u00e4\u00e4ks vaba.\u201c<\/p>\n
\u201eAndke inimestele organisatsioonilist tuge ja andke hoogu suhtlusega, mis ulatub kaugele esmakordsete r\u00fchmadest, t\u00e4histades uute t\u00f6\u00f6tamisviiside edusamme laialdaselt. Koolitage inimesi, kes on j\u00e4rgmise DevOpsi projektide laine sees ja tunnevad \u00e4revust, kuna nad kasutavad DevOpsit esmakordselt. Ja pidage meeles, et need inimesed on v\u00e4ga erinevad esmakordsetest.\u201c<\/p>\n
5. Tehke t\u00f6\u00f6riistad demokraatlikumaks<\/h4>\n \nSteve Newman, Scalyr'i asutaja ja juhatuse esimees:<\/b> \u201eT\u00f6\u00f6riistu ei tohi inimestelt varjata ja need peaksid olema suhteliselt lihtsad igale\u00fchele, kes on valmis aega investeerima. Kui logide p\u00e4rimise v\u00f5imalus on antud vaid kolmele inimesele, kellel on \u201esertifikaat\u201d m\u00f5ne t\u00f6\u00f6riista kasutamiseks, on teil alati maksimaalselt kolm inimest, kes suudavad lahendada vastava probleemi, isegi kui teil on v\u00e4ga suur arvutikeskkond. Teisis\u00f5nu, see tekitab kitsas koha, mis v\u00f5ib tuua t\u00f5siseid (\u00e4ri)tagaj\u00e4rgi.\u201c<\/p>\n6. Looge ideaaltingimused meeskonna t\u00f6\u00f6ks<\/h4>\n
\nTom Clark, ITV Common Platformi juht:<\/b> \u201eSaate teha, mida iganes soovite, kuid mitte k\u00f5ike korraga. Seet\u00f5ttu seadke endale suured eesm\u00e4rgid, alustage v\u00e4ikesest ja liikuge kiirete iteratsioonidega edasi. Aja jooksul teenite maine meeskonnana, kellel k\u00f5ik \u00f5nnestub, mist\u00f5ttu tahavad teisedki kasutada teie meetodeid. Ja \u00e4rge p\u00fc\u00fcdke luua k\u00f5rgelt efektiivset meeskonda. Keskenduge sellele, et pakkuda inimestele ideaalsed t\u00f6\u00f6tingimused, ja efektiivsus tuleb iseenesest.\u201c<\/p>\n7. \u00c4rge unustage Conway seadust ja kanbani tahvleid<\/h4>\n
\nLogan Daigle, CollabNetVersionOne'i tarkvaratoote ja DevOpsi strateegia direktor:<\/b> \u201eOluline on teadvustada Conway seaduse tagaj\u00e4rgi. Minu vabas t\u00f5lkes \u00fctleb see seadus, et tooted, mida me loome, ja protsessid, mida me selle k\u00e4igus rakendame, sealhulgas DevOps, on organiseeritud samamoodi nagu meie organisatsioon.\u201d<\/p>\n
\u201eKui organisatsioonis on k\u00f5rge killustatus ning tarkvaraarenduse planeerimisel, loomisel ja v\u00e4ljaandmisel vahetatakse juhtimine korduvalt k\u00e4est k\u00e4esse, siis on skaleerimise efekt null v\u00f5i l\u00fchiajaline. Kui aga organisatsioon loob ristfunktsionaalsed meeskonnad toodete \u00fcmber, mis on finantseeritud turule orienteeritult, siis t\u00f5useb eduv\u00f5imalus j\u00e4rsult.\u201d<\/p>\n
\u201eVeel \u00fcks oluline aspekt skaleerimises on kuvada kanbani tahvlitel k\u00f5ik t\u00f6\u00f6d, mis on pooleli (WIP, work in progress). Kui organisatsioonis on koht, kus inimesed saavad neid asju n\u00e4ha, stimuleerib see tugevalt koost\u00f6\u00f6d, mis omakorda avaldab positiivset m\u00f5ju skaleerimisele.\u201d<\/p>\n
8. Otsige vanu arme<\/h4>\n \nManuel Pais, DevOpsi konsultant ja raamat \u201eTeam Topologies\u201d kaasautor:<\/b> \u201eDevOps praktikate viimine v\u00e4ljapoole DevOps'i endi ja nende rakendamine teistesse funktsioonidesse ei ole ilmselt optimaalne l\u00e4henemine. See toob kindlasti m\u00f5ningast kasu (nt t\u00e4nu k\u00e4sitsi haldamise automatiseerimisele), kuid palju rohkemat saab saavutada, kui alustada arusaamisest toimetamise ja tagasiside protsessidest.\u201d<\/p>\n
Kui organisatsiooni IT-s\u00fcsteemis on vanad armid \u2013 haldusprotseduurid ja mehhanismid, mis on ellu viidud m\u00f6\u00f6dunud intsidendi tagaj\u00e4rjel, kuid on oma kehtivuse kaotanud (toodete, tehnoloogiate v\u00f5i protsesside muutumise t\u00f5ttu), siis tuleb need kindlasti eemaldada v\u00f5i siluda, mitte automatiseerida ebaefektiivseid v\u00f5i tarbetuid protsesse.<\/p>\n
9. \u00c4rge looge DevOps'i erinevaid variante.<\/h4>\n \nAntony Edwards, Eggplant'i tootmisdirektor:<\/b> \u201eDevOps on \u00e4\u00e4rmiselt ebamugav termin, mist\u00f5ttu iga meeskond t\u00f5lgendab seda omamoodi. Pole midagi hullemat kui see, et organisatsioonis on korraga 20 erinevat DevOps'i varianti, mis ei suudagi h\u00e4sti koos eksisteerida. Ei tohi lubada, et igal kolmel arendajameeskonnal on oma ainulaadne liides arenduse ja tootehalduse vahel. Samuti ei tohi lasta toodetel omada unikaalseid ootusi tagasiside t\u00f6\u00f6tlemisel tootmisimulatsiooni keskkonda \u00fcleviimisel. Vastasel juhul ei suuda te kunagi DevOps'i skaleerida.\u201d<\/p>\n10. Tutvustage DevOps'i v\u00e4\u00e4rtust \u00e4ri jaoks.<\/h4>\n
\nSteve Newman, Scalyr'i asutaja ja juhatuse esimees:<\/b> \u201eT\u00f6\u00f6tage DevOps'i v\u00e4\u00e4rtuse tunnustamise nimel. \u00d5ppige ja \u00e4rge kartke r\u00e4\u00e4kida, kui kasulik see, mida teete, on. DevOps s\u00e4\u00e4stab uskumatult aega ja raha (k\u00f5igest m\u00f5elge: v\u00e4hem seisaegasid, l\u00fchem keskmine taastumisaeg), ja DevOps'i meeskonnad peavad pidevalt r\u00f5hutama (ja esitlema) nende algatuste t\u00e4htsust ettev\u00f5tte edule. Nii saate laiendada DevOps'i pooldajaid ja suurendada selle m\u00f5ju organisatsioonis.\u201d<\/p>\nBONUS<\/h3>\n
\nPealehe Red Hat Foorum Venemaa<\/a><\/noindex> 13. septembril tuleb meie enda DevOps - jah, Red Hat'il, kui tarkvaratootjal, on omad DevOps'i meeskonnad ja praktika.<\/b><\/p>\nMeie insener Mark Birger, kes tegeleb sisemiste automatiseerimisteenuste arendamisega teistele r\u00fchmadele kogu organisatsioonis, r\u00e4\u00e4gib puhtal vene keeles oma loo - kuidas Red Hat'i DevOps'i meeskond migreeris rakendused virtuaalsetest keskkondadest Hat Virtualization, mida haldab Ansible, t\u00e4isv\u00e4\u00e4rtuslikku konteineriformaati OpenShift'i platvormil.<\/p>\n
Kuid see pole veel k\u00f5ik:<\/b><\/p>\n
P\u00e4rast seda, kui organisatsioonid on oma t\u00f6\u00f6koormused konteineritesse viinud, v\u00f5ivad traditsioonilised rakenduste j\u00e4lgimise meetodid mitte t\u00f6\u00f6tada. Teises aruandes selgitame, miks me otsustasime registreerimise viisi muuta, ja n\u00e4itame teed, mis viis meid kaasaegsete logimise ja j\u00e4lgimise meetoditeni.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0440\u0443\u0434\u043d\u043e \u0443\u043b\u043e\u0432\u0438\u0442\u044c \u0433\u043b\u0430\u0432\u043d\u043e\u0435, \u0433\u043e\u0432\u043e\u0440\u044f \u043e DevOps? \u041c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u044f\u0440\u043a\u0438\u0435 \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0438, \u0443\u0434\u0430\u0440\u043d\u044b\u0435 \u0444\u043e\u0440\u043c\u0443\u043b\u0438\u0440\u043e\u0432\u043a\u0438 \u0438 \u0441\u043e\u0432\u0435\u0442\u044b \u043e\u0442 \u044d\u043a\u0441\u043f\u0435\u0440\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0434\u043e\u0439\u0442\u0438 \u0434\u043e \u0441\u0443\u0442\u0438 \u0434\u0430\u0436\u0435 \u043d\u0435\u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u0430\u043c. \u0412 \u043a\u043e\u043d\u0446\u0435 \u0431\u043e\u043d\u0443\u0441 \u2013 \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u044b\u0439 DevOps \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u043e\u0432 Red Hat. \u0422\u0435\u0440\u043c\u0438\u043d DevOps \u0432\u043e\u0437\u043d\u0438\u043a 10 \u043b\u0435\u0442 \u043d\u0430\u0437\u0430\u0434 \u0438 \u043f\u0440\u043e\u0448\u0435\u043b \u043f\u0443\u0442\u044c \u043e\u0442 \u0445\u044d\u0448\u0442\u0435\u0433\u0430 \u0432 \u0422\u0432\u0438\u0442\u0442\u0435\u0440\u0435 \u0434\u043e \u043c\u043e\u0449\u043d\u043e\u0433\u043e \u043a\u0443\u043b\u044c\u0442\u0443\u0440\u043d\u043e\u0433\u043e \u0434\u0432\u0438\u0436\u0435\u043d\u0438\u044f \u0432 \u043c\u0438\u0440\u0435 \u0418\u0422, \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28183,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-37551","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"R\u00e4\u00e4gime](\"\/wp-content\/uploads\/2019\/08\/c3df26c470065767bc37e7d1c732d0b5.jpeg\")