Dyma'r cyntaf mewn cyfres o swyddi am y newidiadau, gwelliannau, ac ychwanegiadau yn y diweddariad Red Hat OpenShift platfform 4.0 sydd ar ddod a fydd yn eich helpu i baratoi ar gyfer y newid i'r fersiwn newydd.
O'r eiliad yr ymgasglodd cymuned newydd Kubernetes yn swyddfa Google yn Seattle am y tro cyntaf yng nghwymp 2014, roedd yn amlwg bod prosiect Kubernetes i fod i chwyldroi'r ffordd y mae meddalwedd yn cael ei datblygu a'i defnyddio heddiw. Ar yr un pryd, parhaodd darparwyr gwasanaethau cwmwl cyhoeddus i fuddsoddi'n weithredol yn natblygiad seilwaith a gwasanaethau, a oedd yn gwneud gweithio gyda TG a chreu meddalwedd yn llawer haws ac yn fwy hygyrch, ac yn eu gwneud yn hynod hygyrch, na allai ychydig fod wedi'i ddychmygu ar ddechrau'r cyfnod. y degawd.
Wrth gwrs, roedd nifer o drafodaethau ymhlith arbenigwyr ar Twitter yn cyd-fynd â chyhoeddiad pob gwasanaeth cwmwl newydd, a chynhaliwyd dadleuon ar amrywiaeth o bynciau - gan gynnwys diwedd y cyfnod ffynhonnell agored, dirywiad TG ar y safle, a'r anochel. monopoli meddalwedd newydd yn y cwmwl, a sut y bydd y patrwm X newydd yn disodli'r holl baradeimau eraill.
Afraid dweud, roedd yr holl anghydfodau hyn yn dwp iawn
Y gwir amdani yw nad oes dim yn mynd i ddiflannu, a heddiw gallwn weld twf esbonyddol mewn cynhyrchion terfynol a'r ffordd y cânt eu datblygu, oherwydd ymddangosiad cyson meddalwedd newydd yn ein bywydau. Ac er gwaethaf y ffaith y bydd popeth o gwmpas yn newid, ar yr un pryd, yn ei hanfod, bydd popeth yn aros yn ddigyfnewid. Bydd datblygwyr meddalwedd yn dal i ysgrifennu cod gyda gwallau, bydd peirianwyr gweithrediadau ac arbenigwyr dibynadwyedd yn dal i gerdded o gwmpas gyda galwyr a derbyn rhybuddion awtomatig yn Slack, bydd rheolwyr yn dal i weithredu o ran OpEx a CapEx, a phob tro y bydd methiant yn digwydd, yr uwch fydd y datblygwr. ochneidiwch yn drist gyda'r geiriau: “Dywedais i wrthych felly”...
yn wîr dylid ei drafod, yw pa offer y gallwn eu cael i greu cynhyrchion meddalwedd gwell, a sut y gallant wella diogelwch a gwneud datblygiad yn haws ac yn fwy dibynadwy. Wrth i gymhlethdod prosiectau gynyddu, felly hefyd risgiau newydd, a heddiw mae bywydau pobl mor ddibynnol ar feddalwedd fel bod yn rhaid i ddatblygwyr geisio gwneud swydd well.
Mae Kubernetes yn un offeryn o'r fath. Mae gwaith ar y gweill i gyfuno Red Hat OpenShift ag offer a gwasanaethau eraill yn un platfform a fyddai'n gwneud y feddalwedd yn fwy dibynadwy, yn haws ei rheoli, ac yn fwy diogel i ddefnyddwyr.
Wedi dweud hynny, mae tîm OpenShift yn gofyn un cwestiwn syml:
Sut allwch chi wneud gweithio gyda Kubernetes yn haws ac yn fwy cyfleus?
Mae'r ateb yn rhyfeddol o amlwg:
- awtomeiddio agweddau cymhleth ar leoli ar y cwmwl neu y tu allan i'r cwmwl;
- canolbwyntio ar ddibynadwyedd tra'n cuddio cymhlethdod;
- parhau i weithio'n barhaus i ryddhau diweddariadau syml a diogel;
- sicrhau y gellir ei reoli a'i archwilio;
- ymdrechu i sicrhau diogelwch uchel i ddechrau, ond nid ar draul defnyddioldeb.
Dylai datganiad nesaf OpenShift ystyried profiad y crewyr a phrofiad datblygwyr eraill sy'n gweithredu meddalwedd ar raddfa fawr yn y cwmnïau mwyaf yn y byd. Yn ogystal, rhaid iddo gymryd i ystyriaeth yr holl brofiad cronedig o ecosystemau agored sy'n sail i'r byd modern heddiw. Ar yr un pryd, mae angen rhoi'r gorau i hen feddylfryd y datblygwr amatur a symud i athroniaeth newydd o ddyfodol awtomataidd. Mae angen iddo bontio'r bwlch rhwng ffyrdd hen a newydd o ddefnyddio meddalwedd, a manteisio'n llawn ar yr holl seilwaith sydd ar gael - boed yn cael ei gynnal gan y darparwr cwmwl mwyaf neu'n rhedeg ar systemau bach ar yr ymyl.
Sut i gyflawni'r canlyniad hwn?
Yn Red Hat, mae'n arferol gwneud gwaith diflas a di-ddiolch am amser hir er mwyn cadw'r gymuned sefydledig ac atal cau prosiectau y mae'r cwmni'n ymwneud â nhw. Mae'r gymuned ffynhonnell agored yn cynnwys nifer enfawr o ddatblygwyr dawnus sy'n creu'r pethau mwyaf rhyfeddol - difyr, addysgol, agor cyfleoedd newydd a hardd, ond, wrth gwrs, nid oes neb yn disgwyl i bawb symud i'r un cyfeiriad na dilyn nodau cyffredin. . Mae harneisio’r egni hwn a’i ailgyfeirio i’r cyfeiriad cywir weithiau’n angenrheidiol i ddatblygu meysydd a fyddai o fudd i’n defnyddwyr, ond ar yr un pryd rhaid inni fonitro datblygiad ein cymunedau a dysgu oddi wrthynt.
Ar ddechrau 2018, cafodd Red Hat y prosiect CoreOS, a oedd â safbwyntiau tebyg ar y dyfodol - yn fwy diogel a dibynadwy, a grëwyd ar egwyddorion ffynhonnell agored. Mae'r cwmni wedi gweithio i ddatblygu'r syniadau hyn ymhellach a'u rhoi ar waith, gan roi ein hathroniaeth ar waith - gan geisio sicrhau bod yr holl feddalwedd yn rhedeg yn ddiogel. Mae'r holl waith hwn wedi'i adeiladu ar Kubernetes, Linux, cymylau cyhoeddus, cymylau preifat, a miloedd o brosiectau eraill sy'n sail i'n hecosystem ddigidol fodern.
Bydd y datganiad newydd o OpenShift 4 yn glir, yn awtomataidd ac yn fwy naturiol
Bydd y platfform OpenShift yn gweithio gyda'r systemau gweithredu Linux gorau a mwyaf dibynadwy, gyda chefnogaeth caledwedd metel noeth, rhithwiroli cyfleus, rhaglennu seilwaith awtomatig ac, wrth gwrs, cynwysyddion (sef delweddau Linux yn unig yn y bôn).
Mae angen i'r platfform fod yn ddiogel o'r cychwyn cyntaf, ond yn dal i alluogi datblygwyr i ailadrodd yn hawdd - hynny yw, bod yn ddigon hyblyg a diogel tra'n dal i ganiatáu i weinyddwyr ei archwilio a'i reoli'n hawdd.
Dylai ganiatáu i feddalwedd gael ei rhedeg “fel gwasanaeth” a pheidio ag arwain at dwf seilwaith na ellir ei reoli i weithredwyr.
Bydd yn caniatáu i ddatblygwyr ganolbwyntio ar greu cynhyrchion go iawn ar gyfer defnyddwyr a chwsmeriaid. Ni fydd yn rhaid i chi gerdded trwy jyngl gosodiadau caledwedd a meddalwedd, a bydd yr holl gymhlethdodau damweiniol yn perthyn i'r gorffennol.
OpenShift 4: platfform NoOps nad oes angen ei gynnal a'i gadw
В disgrifiodd y tasgau hynny a helpodd i lunio gweledigaeth y cwmni ar gyfer OpenShift 4. Nod y tîm yw symleiddio'r tasgau dyddiol o weithredu a chynnal meddalwedd cymaint â phosibl, i wneud y prosesau hyn yn hawdd ac yn hamddenol - ar gyfer arbenigwyr sy'n ymwneud â gweithredu ac i ddatblygwyr. Ond sut allwch chi ddod yn agosach at y nod hwn? Sut i greu llwyfan ar gyfer rhedeg meddalwedd sydd angen ychydig iawn o ymyrraeth? Beth mae NoOps hyd yn oed yn ei olygu yn y cyd-destun hwn?
Os ceisiwch haniaethu, yna i ddatblygwyr mae’r cysyniadau o “ddi-weinydd” neu “NoOps” yn golygu offer a gwasanaethau sy’n caniatáu ichi guddio’r gydran “weithredol” neu leihau’r baich hwn i’r datblygwr.
- Gweithio nid gyda systemau, ond gyda rhyngwynebau cymhwysiad (APIs).
- Peidiwch â thrafferthu gweithredu meddalwedd - gadewch i'r darparwr ei wneud ar eich rhan.
- Ni ddylech neidio i mewn i greu fframwaith mawr ar unwaith - dechreuwch trwy ysgrifennu darnau bach a fydd yn gweithredu fel "blociau adeiladu", ceisiwch wneud i'r cod hwn weithio gyda data a digwyddiadau, ac nid gyda disgiau a chronfeydd data.
Y nod, fel o'r blaen, yw cyflymu iteriadau wrth ddatblygu meddalwedd, rhoi'r cyfle i greu cynhyrchion gwell, ac fel nad oes rhaid i'r datblygwr boeni am y systemau y mae ei feddalwedd yn rhedeg arnynt. Mae datblygwr profiadol yn ymwybodol iawn y gall canolbwyntio ar ddefnyddwyr newid y llun yn gyflym, felly ni ddylech roi gormod o ymdrech i ysgrifennu meddalwedd oni bai eich bod yn hollol siŵr bod ei angen.
Ar gyfer gweithwyr proffesiynol cynnal a chadw a gweithrediadau, gall y gair “NoOps” swnio ychydig yn frawychus. Ond wrth gyfathrebu â pheirianwyr maes, mae’n dod yn amlwg bod y patrymau a’r technegau a ddefnyddiant gyda’r nod o sicrhau dibynadwyedd a dibynadwyedd (Peirianneg Dibynadwyedd Safle, SRE) yn debyg iawn i’r patrymau a ddisgrifir uchod:
- Peidiwch â rheoli systemau - awtomeiddio eu prosesau rheoli.
- Peidiwch â gweithredu meddalwedd - crëwch biblinell i'w defnyddio.
- Ceisiwch osgoi bwndelu'ch holl wasanaethau gyda'i gilydd a gadael i fethiant un achosi i'r system gyfan fethu - gwasgarwch nhw ar draws eich seilwaith cyfan gan ddefnyddio offer awtomeiddio, a'u cysylltu mewn ffyrdd y gellir eu monitro a'u monitro.
Mae SREs yn gwybod y gall rhywbeth fynd o'i le a bydd yn rhaid iddynt olrhain a thrwsio'r broblem - felly maent yn awtomeiddio gwaith arferol a gosod cyllidebau gwall ymlaen llaw fel eu bod yn barod i flaenoriaethu a gwneud penderfyniadau pan fydd problem yn codi. .
Mae Kubernetes yn OpenShift yn blatfform sydd wedi'i gynllunio i ddatrys dwy brif broblem: yn hytrach na'ch gorfodi i ddeall peiriannau rhithwir neu APIs cydbwysedd llwyth, mae'n gweithio gyda thyniadau uwch - prosesau a gwasanaethau lleoli. Yn hytrach na gosod asiantau meddalwedd, gallwch redeg cynwysyddion, ac yn lle ysgrifennu eich pentwr monitro eich hun, defnyddiwch yr offer sydd eisoes ar gael yn y platfform. Felly, nid yw saws cyfrinachol OpenShift 4 yn gyfrinach mewn gwirionedd - dim ond mater o gymryd egwyddorion SRE a chysyniadau di-weinydd ydyw a mynd â nhw i'w casgliad rhesymegol i helpu datblygwyr a pheirianwyr gweithrediadau:
- Awtomeiddio a safoni'r seilwaith a ddefnyddir gan gymwysiadau
- Cysylltu prosesau lleoli a datblygu â'i gilydd heb gyfyngu ar y datblygwyr eu hunain
- Sicrhau nad yw lansio, archwilio a sicrhau'r XNUMXfed gwasanaeth, nodwedd, cymhwysiad, neu bentwr cyfan yn fwy anodd na'r cyntaf.
Ond beth yw’r gwahaniaeth rhwng platfform OpenShift 4 a’i ragflaenwyr ac o’r dull “safonol” o ddatrys problemau o’r fath? Beth sy'n gyrru graddfa ar gyfer timau gweithredu a gweithredu? Oherwydd y ffaith mai'r brenin yn y sefyllfa hon yw'r clwstwr. Felly,
- Rydym yn gwneud yn siŵr bod pwrpas y clystyrau yn glir (Annwyl gwmwl, codais y clwstwr hwn oherwydd gallwn)
- Mae peiriannau a systemau gweithredu yn bodoli i wasanaethu’r clwstwr (Eich Mawrhydi)
- Rheoli cyflwr gwesteiwyr o'r clwstwr, lleihau eu hailadeiladu (drifft).
- Ar gyfer pob elfen bwysig o'r system, mae angen nani (mecanwaith) a fydd yn monitro ac yn dileu problemau
- Mae methiant *pob* agwedd neu elfen o system a mecanweithiau adfer cysylltiedig yn rhan arferol o fywyd
- Rhaid i'r seilwaith cyfan gael ei ffurfweddu trwy API.
- Defnyddiwch Kubernetes i redeg Kubernetes. (Ie, ie, nid typo yw hwnna)
- Dylai diweddariadau fod yn hawdd ac yn ddi-drafferth i'w gosod. Os bydd yn cymryd mwy nag un clic i osod diweddariad, yna yn amlwg rydym yn gwneud rhywbeth o'i le.
- Ni ddylai monitro a dadfygio unrhyw gydran fod yn broblem, ac felly dylai olrhain ac adrodd ar draws y seilwaith cyfan fod yn hawdd ac yn gyfleus hefyd.
Eisiau gweld galluoedd y platfform ar waith?
Mae fersiwn rhagolwg o OpenShift 4 ar gael i ddatblygwyr. Gyda gosodwr hawdd ei ddefnyddio, gallwch redeg clwstwr ar AWS ar ben Red Had CoreOS. I ddefnyddio'r rhagolwg, dim ond cyfrif AWS sydd ei angen arnoch i ddarparu'r seilwaith a set o gyfrifon i gael mynediad at y delweddau rhagolwg.
- I ddechrau, ewch i a chliciwch ar “Cychwyn Arni”.
- Mewngofnodwch i'ch cyfrif Red Hat (neu crëwch un newydd) a dilynwch y cyfarwyddiadau i sefydlu'ch clwstwr cyntaf.
Ar ôl gosod yn llwyddiannus, edrychwch ar ein tiwtorialau i gael dealltwriaeth ddyfnach o'r systemau a'r cysyniadau sy'n gwneud platfform OpenShift 4 yn ffordd mor hawdd a chyfleus i redeg Kubernetes.
Rhowch gynnig ar y datganiad OpenShift newydd a rhannwch eich barn. Rydym wedi ymrwymo i wneud gweithio gyda Kumbernetes mor hygyrch a diymdrech â phosibl—mae dyfodol NoOps yn dechrau heddiw.
Sylw nawr!
Yn y gynhadledd Ar Ebrill 20, bydd un o ddatblygwyr OpenShift, Vadim Rutkovsky, yn cynnal dosbarth meistr - bydd yn torri deg clwstwr ac yn eu gorfodi i'w trwsio. Telir y gynhadledd, ond gyda'r cod hyrwyddo #RedHat byddwch yn cael gostyngiad o 37%.
Dosbarth meistr am 17:15 - 18:15, ac mae'r stondin ar agor drwy'r dydd. Crysau T, hetiau, sticeri - yr arferol!
Neuadd #2
“Yma mae angen newid y system gyfan: rydym yn atgyweirio clystyrau k8s sydd wedi torri ynghyd â mecaneg ardystiedig.”
Ffynhonnell: hab.com