Ĉi tio estas la unua el serio de afiŝoj pri la ŝanĝoj, plibonigoj kaj aldonoj en la venonta Red Hat OpenShift platformo 4.0 ĝisdatigo kiu helpos vin prepari por la transiro al la nova versio.
Ekde la momento, kiam la novnaskita Kubernetes-komunumo unue kunvenis ĉe la Seatla oficejo de Google en la aŭtuno de 2014, estis klare ke la Kubernetes-projekto estis destinita revolucii la manieron kiel programaro estas evoluigita kaj deplojita hodiaŭ. Samtempe, provizantoj de publikaj nubaj servoj daŭre aktive investis en la disvolviĝo de infrastrukturoj kaj servoj, kiuj multe pli facilas kaj pli alirigis labori kun IT kaj krei programaron, kaj igis ilin nekredeble alireblaj, kion malmultaj povus imagi komence de la jardeko.
Kompreneble, la anonco de ĉiu nova nuba servo estis akompanita de multaj diskutoj inter spertuloj en Twitter, kaj debatoj estis faritaj pri diversaj temoj - inkluzive de la fino de la malfermfonta epoko, la malkresko de surloka IT kaj la neeviteblo. de nova programara monopolo en la nubo, kaj kiel la nova paradigmo X anstataŭigos ĉiujn aliajn paradigmojn.
Ne necesas diri, ke ĉiuj ĉi disputoj estis tre stultaj
La realo estas, ke nenio foriros, kaj hodiaŭ ni povas vidi eksponencan kreskon de finaj produktoj kaj la maniero kiel ili estas disvolvitaj, pro la konstanta apero de novaj programoj en niaj vivoj. Kaj malgraŭ tio, ke ĉio ĉirkaŭe ŝanĝiĝos, samtempe, en esenco, ĉio restos senŝanĝa. Programistoj ankoraŭ skribos kodon kun eraroj, operaciaj inĝenieroj kaj fidindecspecialistoj ankoraŭ promenos kun pagiloj kaj ricevos aŭtomatajn atentigojn en Slack, administrantoj ankoraŭ funkcios en la konceptoj de OpEx kaj CapEx, kaj ĉiufoje kiam okazas fiasko, la altranga la programisto. ĝemos malĝoje kun la vortoj: "Mi diris tion al vi"...
Ho ĉu vere devus esti diskutita, estas kiaj iloj ni povas havi je nia dispono por krei pli bonajn softvarajn produktojn, kaj kiel ili povas plibonigi sekurecon kaj fari disvolviĝon pli facila kaj pli fidinda. Ĉar projektoj fariĝas pli kompleksaj, novaj riskoj aperas, kaj hodiaŭ la vivoj de homoj tiom dependas de programaro, ke programistoj simple devas provi pli bone fari sian laboron.
Kubernetes estas unu tia ilo. Laboras por kombini Red Hat OpenShift kun aliaj iloj kaj servoj en ununuran platformon, kiu igus la programaron pli fidinda, pli facile administrebla kaj pli sekura por uzantoj.
Dirite, la teamo OpenShift faras unu simplan demandon:
Kiel vi povas fari labori kun Kubernetes pli facila kaj pli oportuna?
La respondo estas surprize evidenta:
- aŭtomatigi kompleksajn aspektojn de deplojo sur la nubo aŭ ekster la nubo;
- fokuso sur fidindeco kaŝante kompleksecon;
- daŭre laboru por liberigi simplajn kaj sekurajn ĝisdatigojn;
- atingi kontroleblecon kaj kontroleblecon;
- strebu por komence certigi altan sekurecon, sed ne koste de uzebleco.
La sekva eldono de OpenShift devus konsideri kaj la sperton de la kreintoj kaj la sperton de aliaj programistoj, kiuj efektivigas programaron grandskale en la plej grandaj kompanioj en la mondo. Krome, ĝi devas konsideri la tutan akumulitan sperton de malfermaj ekosistemoj, kiuj subtenas la modernan mondon hodiaŭ. Samtempe, necesas forlasi la malnovan menson de la amatora programisto kaj moviĝi al nova filozofio de aŭtomata estonteco. Ĝi devas limigi la interspacon inter malnovaj kaj novaj manieroj disfaldi programaron, kaj plene profiti ĉiujn disponeblajn infrastrukturojn—ĉu ĝi estas gastigita de la plej granda nuba provizanto aŭ funkcianta per etaj sistemoj ĉe la rando.
Kiel atingi ĉi tiun rezulton?
Ĉe Red Hat, estas kutime fari enuigan kaj sendankan laboron dum longa tempo por konservi la establitan komunumon kaj malhelpi la fermon de projektoj en kiuj la firmao estas implikita. La malfermfonta komunumo enhavas grandegan nombron da talentaj programistoj, kiuj kreas la plej eksterordinarajn aferojn - amuzajn, edukajn, malfermajn novajn ŝancojn kaj simple belajn, sed, kompreneble, neniu atendas, ke ĉiuj moviĝu en la sama direkto aŭ serĉu komunajn celojn. . Utiligi ĉi tiun energion kaj redirekti ĝin en la ĝusta direkto estas foje necesa por disvolvi areojn, kiuj profitigus niajn uzantojn, sed samtempe ni devas kontroli la evoluon de niaj komunumoj kaj lerni de ili.
Komence de 2018, Red Hat akiris la projekton CoreOS, kiu havis similajn vidojn pri la estonteco - pli sekura kaj fidinda, kreita laŭ malfermfontaj principoj. La firmao laboris por plue evoluigi ĉi tiujn ideojn kaj efektivigi ilin, metante nian filozofion en praktikon - provante certigi, ke ĉiuj programoj funkcias sekure. Ĉio ĉi tiu laboro estas konstruita sur Kubernetes, Linukso, publikaj nuboj, privataj nuboj kaj miloj da aliaj projektoj, kiuj subtenas nian modernan ciferecan ekosistemon.
La nova eldono de OpenShift 4 estos klara, aŭtomatigita kaj pli natura
La platformo OpenShift funkcios kun la plej bonaj kaj plej fidindaj Linuksaj operaciumoj, kun nuda metala aparataro subteno, oportuna virtualigo, aŭtomata infrastruktura programado kaj, kompreneble, ujoj (kiuj esence estas nur Linuksaj bildoj).
La platformo devas esti sekura de la komenco, sed tamen permesi al programistoj facile ripetadi—tio estas, esti sufiĉe fleksebla kaj sekura dum daŭre permesante al administrantoj kontroli kaj administri ĝin facile.
Ĝi devus permesi al programaro funkcii "kiel servo" kaj ne konduki al neregebla infrastruktura kresko por funkciigistoj.
Ĝi permesos al programistoj koncentriĝi pri kreado de realaj produktoj por uzantoj kaj klientoj. Vi ne devos vadi tra la ĝangalo de aparataro kaj programaro agordoj, kaj ĉiuj hazardaj komplikaĵoj estos aĵo de la pasinteco.
OpenShift 4: NoOps-platformo, kiu ne postulas prizorgadon
В priskribis tiujn taskojn, kiuj helpis formi la vizion de la firmao por OpenShift 4. La celo de la teamo estas simpligi la ĉiutagajn taskojn de funkciigado kaj prizorgado de programaro kiel eble plej multe, por igi ĉi tiujn procezojn facilaj kaj malstreĉaj - kaj por specialistoj implikitaj en efektivigo kaj por programistoj. Sed kiel vi povas proksimiĝi al ĉi tiu celo? Kiel krei platformon por ruli programaron, kiu postulas minimuman intervenon? Kion eĉ signifas NoOps en ĉi tiu kunteksto?
Se vi provas abstrakti, tiam por programistoj la konceptoj de "senservilo" aŭ "NoOps" signifas ilojn kaj servojn, kiuj ebligas al vi kaŝi la "funkcian" komponanton aŭ minimumigi ĉi tiun ŝarĝon por la programisto.
- Laboru ne kun sistemoj, sed kun aplikaj interfacoj (APIoj).
- Ne ĝenu efektivigi programaron - lasu la provizanton fari ĝin por vi.
- Vi ne devus tuj ekkrei grandan kadron - komencu skribante malgrandajn pecojn, kiuj funkcios kiel "konstrubriketoj", provu igi ĉi tiun kodon funkcii kun datumoj kaj eventoj, kaj ne kun diskoj kaj datumbazoj.
La celo, kiel antaŭe, estas akceli ripetojn en programaro-disvolviĝo, doni la ŝancon krei pli bonajn produktojn, kaj por ke la programisto ne devu zorgi pri la sistemoj, sur kiuj funkcias sia programaro. Sperta programisto bone konscias, ke koncentriĝi al uzantoj povas rapide ŝanĝi la bildon, do vi ne devas tro multe klopodi por verki programaron krom se vi estas absolute certa, ke ĝi estas bezonata.
Por profesiuloj pri prizorgado kaj operacioj, la vorto "NoOps" povas soni iom timiga. Sed kiam oni komunikas kun kampaj inĝenieroj, evidentiĝas, ke la ŝablonoj kaj teknikoj, kiujn ili uzas celantajn certigi fidindecon kaj fidindecon (Site Reliability Engineering, SRE) havas multajn similecojn kun la ŝablonoj priskribitaj supre:
- Ne administru sistemojn - aŭtomatigu iliajn administrajn procezojn.
- Ne efektivigu programaron - kreu dukton por deploji ĝin.
- Evitu kunigi ĉiujn viajn servojn kaj lasi la malsukceson de unu kaŭzi la tutan sistemon malsukcesi — disvastigu ilin tra via tuta infrastrukturo uzante aŭtomatigajn ilojn, kaj konektu ilin en manieroj kiuj povas esti monitoritaj kaj monitoritaj.
SRE-oj scias, ke io povas misfunkcii kaj ili devos spuri kaj ripari la problemon—do ili aŭtomatigas rutinan laboron kaj fiksas erarbuĝetojn anticipe por ke ili estu pretaj prioritatigi kaj fari decidojn kiam problemo ekestas. .
Kubernetes en OpenShift estas platformo desegnita por solvi du ĉefajn problemojn: anstataŭ devigi vin kompreni virtualajn maŝinojn aŭ ŝarĝajn ekvilibrajn APIojn, ĝi funkcias kun pli alta ordo abstraktaĵoj - deplojprocezoj kaj servoj. Anstataŭ instali programarajn agentojn, vi povas ruli ujojn, kaj anstataŭ skribi vian propran monitoran stakon, uzi la ilojn jam disponeblajn en la platformo. Do, la sekreta saŭco de OpenShift 4 estas vere neniu sekreto - temas nur pri preni SRE-principojn kaj senservilajn konceptojn kaj preni ilin al ilia logika konkludo por helpi programistojn kaj operaciajn inĝenierojn:
- Aŭtomatigu kaj normigu la infrastrukturon, kiun uzas aplikaĵoj
- Ligu deplojajn kaj evoluajn procezojn kune sen limigi programistojn mem
- Certigi, ke lanĉi, revizii kaj sekurigi la XNUMX-an servon, funkcion, aplikaĵon aŭ tutan stakon ne estas pli malfacila ol la unua.
Sed kio estas la diferenco inter la platformo OpenShift 4 kaj ĝiaj antaŭuloj kaj de la "norma" aliro al solvi tiajn problemojn? Kio movas skalon por efektivigo kaj operaciaj teamoj? Pro la fakto, ke la reĝo en ĉi tiu situacio estas la areto. Do,
- Ni certigas, ke la celo de la aretoj estas klara (Kara nubo, mi prenis ĉi tiun areton ĉar mi povis)
- Maŝinoj kaj operaciumoj ekzistas por servi la areton (Via Moŝto)
- Administri la staton de gastigantoj de la areto, minimumigi ilian rekonstruadon (drivo).
- Por ĉiu grava elemento de la sistemo necesas infanistino (mekanismo), kiu kontrolos kaj forigos problemojn
- Fiasko de *ĉiu* aspekto aŭ elemento de sistemo kaj rilataj reakiro-mekanismoj estas normala parto de vivo
- La tuta infrastrukturo devas esti agordita per API.
- Uzu Kubernetes por ruli Kubernetes. (Jes, jes, tio ne estas tajperaro)
- Ĝisdatigoj devus esti facile kaj senĝene instaleblaj. Se necesas pli ol unu klako por instali ĝisdatigon, tiam evidente ni faras ion malbone.
- Monitorado kaj elpurigado de ajna komponanto ne devus esti problemo, kaj tial spurado kaj raportado tra la tuta infrastrukturo ankaŭ devus esti facila kaj oportuna.
Ĉu vi volas vidi la kapablojn de la platformo en ago?
Antaŭprezentversio de OpenShift 4 fariĝis disponebla por programistoj. Kun facile uzebla instalilo, vi povas ruli areton sur AWS aldone al Red Had CoreOS. Por uzi la antaŭrigardon, vi nur bezonas AWS-konton por provizi la infrastrukturon kaj aron da kontoj por aliri la antaŭrigardajn bildojn.
- Por komenci, iru al kaj alklaku "Komencu".
- Ensalutu al via Red Hat-konto (aŭ kreu novan) kaj sekvu la instrukciojn por agordi vian unuan areton.
Post sukcesa instalado, rigardu niajn lernilojn akiri pli profundan komprenon pri la sistemoj kaj konceptoj, kiuj faras la OpenShift 4-platformon tiel facila kaj oportuna maniero funkciigi Kubernetes.
Provu la novan eldonon de OpenShift kaj dividu vian opinion. Ni kompromitas labori kun Kumbernetes kiel eble plej alirebla kaj senpene—la estonteco de NoOps komenciĝas hodiaŭ.
Nun atento!
Ĉe la konferenco La 20-an de aprilo, unu el la programistoj de OpenShift, Vadim Rutkovsky, okazigos majstran klason - li rompos dek aretojn kaj devigos ilin ripari ilin. La konferenco estas pagita, sed per la reklamkodo #RedHat vi ricevas 37% rabaton
Majstra klaso je 17:15 - 18:15, kaj la stando estas malfermita la tutan tagon. T-ĉemizoj, ĉapeloj, glumarkoj - la kutima!
Salono #2
"Ĉi tie la tuta sistemo devas esti ŝanĝita: ni riparas rompitajn k8s-aretojn kune kun atestitaj mekanikistoj."
fonto: www.habr.com