Roedd yn agosáu at y Flwyddyn Newydd. Roedd plant ledled y wlad eisoes wedi anfon llythyrau at Siôn Corn neu wedi gwneud anrhegion iddyn nhw eu hunain, ac roedd eu prif ysgutor, un o'r prif adwerthwyr, yn paratoi ar gyfer apotheosis gwerthiannau. Ym mis Rhagfyr, mae'r llwyth ar ei ganolfan ddata yn cynyddu sawl gwaith. Felly, penderfynodd y cwmni foderneiddio'r ganolfan ddata a rhoi sawl dwsin o weinyddion newydd ar waith yn lle offer a oedd yn cyrraedd diwedd ei oes gwasanaeth. Mae hyn yn gorffen y stori yn erbyn cefndir o blu eira chwyrlïol, ac mae'r ffilm gyffro yn dechrau.
Cyrhaeddodd yr offer y safle sawl mis cyn yr uchafbwynt gwerthu. Mae'r gwasanaeth gweithrediadau, wrth gwrs, yn gwybod sut a beth i'w ffurfweddu ar y gweinyddwyr er mwyn dod â nhw i'r amgylchedd cynhyrchu. Ond roedd angen i ni awtomeiddio hyn a dileu'r ffactor dynol. Yn ogystal, disodlwyd y gweinyddion cyn mudo set o systemau SAP a oedd yn hanfodol i'r cwmni.
Roedd y broses o gomisiynu gweinyddion newydd yn gaeth i derfyn amser. Ac roedd ei symud yn golygu peryglu cludo biliwn o roddion a mudo systemau. Ni allai hyd yn oed tîm sy'n cynnwys Tad Frost a Siôn Corn newid y dyddiad - dim ond unwaith y flwyddyn y gallwch chi drosglwyddo'r system SAP ar gyfer rheoli warws. Rhwng Rhagfyr 31 a Ionawr 1, mae warysau enfawr y manwerthwr, sef cyfanswm o 20 maes pêl-droed, yn atal eu gwaith am 15 awr. A dyma'r unig gyfnod o amser ar gyfer symud y system. Nid oedd gennym unrhyw le i gamgymeriad wrth gyflwyno gweinyddion.
Gadewch imi fod yn glir: mae fy stori yn adlewyrchu'r offer a'r broses rheoli cyfluniad y mae ein tîm yn eu defnyddio.
Mae'r cyfadeilad rheoli cyfluniad yn cynnwys sawl lefel. Y gydran allweddol yw'r system CMS. Mewn gweithrediad diwydiannol, byddai absenoldeb un o'r lefelau yn anochel yn arwain at wyrthiau annymunol.
Rheoli gosod OS
Y lefel gyntaf yw system ar gyfer rheoli gosod systemau gweithredu ar weinyddion ffisegol a rhithwir. Mae'n creu ffurfweddau OS sylfaenol, gan ddileu'r ffactor dynol.
Gan ddefnyddio'r system hon, cawsom enghreifftiau gweinydd safonol gydag OS a oedd yn addas ar gyfer awtomeiddio pellach. Yn ystod yr “arllwysiad” cawsant set leiaf o ddefnyddwyr lleol ac allweddi SSH cyhoeddus, yn ogystal â chyfluniad OS cyson. Gallem fod yn sicr o reoli'r gweinyddion trwy'r CMS ac roeddem yn sicr nad oedd unrhyw bethau annisgwyl “i lawr yn is” ar lefel yr OS.
Y dasg "uchaf" ar gyfer y system rheoli gosodiadau yw ffurfweddu gweinyddwyr yn awtomatig o'r lefel BIOS / Firmware i'r OS. Mae llawer yma yn dibynnu ar yr offer a thasgau gosod. Ar gyfer offer heterogenaidd, gallwch chi ystyried . Os yw'r holl galedwedd gan un gwerthwr, yna mae'n aml yn fwy cyfleus defnyddio offer rheoli parod (er enghraifft, Amplifier HP ILO, DELL OpenManage, ac ati).
I osod yr OS ar weinyddion ffisegol, fe wnaethom ddefnyddio'r Cobbler adnabyddus, sy'n diffinio set o broffiliau gosod y cytunwyd arnynt gyda'r gwasanaeth gweithredu. Wrth ychwanegu gweinydd newydd i'r seilwaith, clymodd y peiriannydd gyfeiriad MAC y gweinydd i'r proffil gofynnol yn Cobbler. Wrth gychwyn dros y rhwydwaith am y tro cyntaf, derbyniodd y gweinydd gyfeiriad dros dro ac OS newydd. Yna fe'i trosglwyddwyd i'r cyfeiriad VLAN/IP targed a pharhau i weithio yno. Ydy, mae newid VLAN yn cymryd amser ac mae angen cydgysylltu, ond mae'n darparu amddiffyniad ychwanegol rhag gosod y gweinydd yn ddamweiniol mewn amgylchedd cynhyrchu.
Fe wnaethon ni greu gweinyddwyr rhithwir yn seiliedig ar dempledi a baratowyd gan ddefnyddio Hashiїorp Packer. Roedd y rheswm yr un peth: i atal gwallau dynol posibl wrth osod yr OS. Ond, yn wahanol i weinyddion ffisegol, mae Packer yn dileu'r angen am PXE, cychwyn rhwydwaith, a newidiadau VLAN. Mae hyn wedi ei gwneud hi'n haws ac yn symlach creu gweinyddwyr rhithwir.
Reis. 1. Rheoli gosod systemau gweithredu.
Rheoli cyfrinachau
Mae unrhyw system rheoli cyfluniad yn cynnwys data y dylid ei guddio rhag defnyddwyr cyffredin, ond sydd ei angen i baratoi systemau. Mae'r rhain yn gyfrineiriau defnyddwyr lleol a chyfrifon gwasanaeth, allweddi tystysgrif, Tocynnau API amrywiol, ac ati Fe'u gelwir fel arfer yn “gyfrinachau”.
Os na fyddwch chi'n penderfynu o'r cychwyn cyntaf ble a sut i storio'r cyfrinachau hyn, yna, yn dibynnu ar ddifrifoldeb y gofynion diogelwch gwybodaeth, mae'r dulliau storio canlynol yn debygol:
- yn uniongyrchol yn y cod rheoli cyfluniad neu mewn ffeiliau yn yr ystorfa;
- mewn offer rheoli cyfluniad arbenigol (er enghraifft, Ansible Vault);
- mewn systemau CI/CD (Jenkins/TeamCity/GitLab/etc.) neu mewn systemau rheoli cyfluniad (Ansible Tower/Ansible AWX);
- gall cyfrinachau hefyd gael eu trosglwyddo “â llaw”. Er enghraifft, maent wedi'u gosod mewn lleoliad penodol, ac yna fe'u defnyddir gan systemau rheoli cyfluniad;
- cyfuniadau amrywiol o'r uchod.
Mae gan bob dull ei anfanteision ei hun. Y prif un yw'r diffyg polisïau ar gyfer mynediad at gyfrinachau: mae'n amhosibl neu'n anodd penderfynu pwy all ddefnyddio rhai cyfrinachau. Anfantais arall yw diffyg archwilio mynediad a chylch bywyd llawn. Sut i newid yn gyflym, er enghraifft, allwedd gyhoeddus sydd wedi'i hysgrifennu yn y cod ac mewn nifer o systemau cysylltiedig?
Fe wnaethon ni ddefnyddio'r storfa gudd ganolog HashiCorp Vault. Roedd hyn yn caniatáu i ni:
- cadw cyfrinachau yn ddiogel. Maent wedi'u hamgryptio, a hyd yn oed os bydd rhywun yn cael mynediad i gronfa ddata Vault (er enghraifft, trwy ei adfer o gopi wrth gefn), ni fyddant yn gallu darllen y cyfrinachau sydd wedi'u storio yno;
- trefnu polisïau ar gyfer mynediad at gyfrinachau. Dim ond y cyfrinachau a “ddyrannwyd” iddynt sydd ar gael i ddefnyddwyr a chymwysiadau;
- archwilio mynediad at gyfrinachau. Mae unrhyw gamau gweithredu sydd â chyfrinachau yn cael eu cofnodi yn log archwilio Vault;
- trefnu “cylch bywyd” llawn o weithio gyda chyfrinachau. Gellir eu creu, eu dirymu, gosod dyddiad dod i ben, ac ati.
- hawdd eu hintegreiddio â systemau eraill sydd angen mynediad at gyfrinachau;
- a hefyd yn defnyddio amgryptio diwedd-i-ddiwedd, cyfrineiriau un-amser ar gyfer yr OS a chronfa ddata, tystysgrifau canolfannau awdurdodedig, ac ati.
Nawr, gadewch i ni symud ymlaen i'r system ddilysu ac awdurdodi ganolog. Roedd yn bosibl gwneud hebddo, ond mae gweinyddu defnyddwyr mewn llawer o systemau cysylltiedig yn rhy ddibwys. Rydym wedi ffurfweddu dilysu ac awdurdodi drwy'r gwasanaeth LDAP. Fel arall, byddai'n rhaid i Vault gyhoeddi a chadw golwg ar docynnau dilysu ar gyfer defnyddwyr yn barhaus. A byddai dileu ac ychwanegu defnyddwyr yn troi’n chwil “wnes i greu/dileu’r cyfrif defnyddiwr hwn ym mhobman?”
Rydym yn ychwanegu lefel arall at ein system: rheoli cyfrinachau a dilysu/awdurdodi canolog:
Reis. 2. Rheoli cyfrinachau.
Rheoli cyfluniad
Cyrhaeddom y craidd - y system CMS. Yn ein hachos ni, mae hwn yn gyfuniad o Ansible a Red Hat Ansible AWX.
Yn lle Ansible, gellir defnyddio Cogydd, Pyped, SaltStack. Fe wnaethom ddewis Ansible ar sail nifer o feini prawf.
- Yn gyntaf, amlochredd ydyw. Set o fodiwlau parod i'w rheoli . Ac os nad oes gennych chi ddigon ohono, gallwch chi chwilio ar GitHub a Galaxy.
- Yn ail, nid oes angen gosod a chefnogi asiantau ar offer a reolir, profi nad ydynt yn ymyrryd â'r llwyth, a chadarnhau absenoldeb "nodau tudalen".
- Yn drydydd, mae gan Ansible rwystr isel i fynediad. Bydd peiriannydd cymwys yn ysgrifennu llyfr chwarae gweithredol yn llythrennol ar y diwrnod cyntaf o weithio gyda'r cynnyrch.
Ond nid oedd Ansible yn unig mewn amgylchedd cynhyrchu yn ddigon i ni. Fel arall, byddai llawer o broblemau'n codi o ran cyfyngu ar fynediad ac archwilio gweithredoedd gweinyddwyr. Sut i gyfyngu mynediad? Wedi'r cyfan, roedd angen i bob adran reoli (darllenwch: rhedeg y llyfr chwarae Ansible) ei set ei hun o weinyddion. Sut i ganiatáu i rai gweithwyr yn unig redeg llyfrau chwarae Ansible penodol? Neu sut i olrhain pwy lansiodd y llyfr chwarae heb sefydlu llawer o wybodaeth leol ar weinyddion ac offer sy'n rhedeg Ansible?
Mae'r rhan fwyaf o faterion o'r fath yn cael ei datrys gan Red Hat , neu ei brosiect ffynhonnell agored i fyny'r afon . Dyna pam roedd yn well gennym ni i'r cwsmer.
Ac un cyffyrddiad arall i'r portread o'n system CMS. Dylid storio llyfr chwarae ansible mewn systemau rheoli cadwrfeydd cod. Mae gennym ni .
Felly, mae'r cyfluniadau eu hunain yn cael eu rheoli gan gyfuniad o Ansible/Ansible AWX/GitLab (gweler Ffig. 3). Wrth gwrs, mae AWX/GitLab wedi'i integreiddio ag un system ddilysu, ac mae llyfr chwarae Ansible wedi'i integreiddio â HashiCorp Vault. Dim ond trwy Ansible AWX y mae cyfluniadau'n mynd i mewn i'r amgylchedd cynhyrchu, lle mae holl “reolau'r gêm” wedi'u nodi: pwy all ffurfweddu beth, ble i gael y cod rheoli cyfluniad ar gyfer y CMS, ac ati.
Reis. 3. rheoli cyfluniad.
Rheoli prawf
Cyflwynir ein ffurfweddiad ar ffurf cod. Felly, rydym yn cael ein gorfodi i chwarae gan yr un rheolau â datblygwyr meddalwedd. Roedd angen i ni drefnu'r prosesau datblygu, profi parhaus, cyflwyno a chymhwyso cod ffurfweddu i weinyddion cynhyrchu.
Os na wneir hyn ar unwaith, yna byddai'r rolau a ysgrifennwyd ar gyfer y cyfluniad naill ai'n peidio â chael eu cefnogi a'u haddasu, neu byddent yn peidio â chael eu lansio wrth gynhyrchu. Mae'r iachâd ar gyfer y boen hon yn hysbys, ac mae wedi profi ei hun yn y prosiect hwn:
- ymdrinnir â phob rôl gan brofion uned;
- cynhelir profion yn awtomatig pryd bynnag y bydd unrhyw newid yn y cod sy'n rheoli'r ffurfweddiadau;
- dim ond ar ôl pasio'r holl brofion ac adolygiad cod yn llwyddiannus y caiff newidiadau yn y cod rheoli cyfluniad eu rhyddhau i'r amgylchedd cynhyrchu.
Mae datblygu cod a rheoli cyfluniad wedi dod yn dawelach ac yn fwy rhagweladwy. I drefnu profion parhaus, defnyddiwyd pecyn cymorth GitLab CI/CD, a chymerwyd .
Pryd bynnag y bydd newid yn y cod rheoli cyfluniad, mae GitLab CI/CD yn galw Moleciwl:
- mae'n gwirio cystrawen y cod,
- yn codi cynhwysydd y Docker,
- cymhwyso'r cod wedi'i addasu i'r cynhwysydd a grëwyd,
- yn gwirio'r rôl am analluedd ac yn cynnal profion ar gyfer y cod hwn (mae'r ronynnedd yma ar lefel y rôl asible, gweler Ffig. 4).
Fe wnaethom gyflwyno ffurfweddiadau i'r amgylchedd cynhyrchu gan ddefnyddio Ansible AWX. Cymhwysodd peirianwyr gweithrediadau newidiadau cyfluniad trwy dempledi wedi'u diffinio ymlaen llaw. Gofynnodd AWX yn annibynnol am y fersiwn ddiweddaraf o'r cod gan brif gangen GitLab bob tro y'i defnyddiwyd. Fel hyn rydym yn eithrio'r defnydd o god heb ei brofi neu hen ffasiwn yn yr amgylchedd cynhyrchu. Yn naturiol, dim ond ar ôl profi, adolygu a chymeradwyo y daeth y cod i mewn i'r brif gangen.
Reis. 4. Profi rolau yn GitLab CI/CD yn awtomatig.
Mae problem hefyd yn gysylltiedig â gweithredu systemau cynhyrchu. Mewn bywyd go iawn, mae'n anodd iawn gwneud newidiadau cyfluniad trwy god CMS yn unig. Mae sefyllfaoedd brys yn codi pan fydd yn rhaid i beiriannydd newid y cyfluniad “yma ac yn awr”, heb aros am olygu cod, profi, cymeradwyo, ac ati.
O ganlyniad, oherwydd newidiadau llaw, mae anghysondebau yn ymddangos yn y ffurfweddiad ar yr un math o offer (er enghraifft, mae gosodiadau sysctl wedi'u ffurfweddu'n wahanol ar nodau clwstwr HA). Neu mae'r cyfluniad gwirioneddol ar yr offer yn wahanol i'r un a nodir yn y cod CMS.
Felly, yn ogystal â phrofion parhaus, rydym yn gwirio amgylcheddau cynhyrchu ar gyfer anghysondebau cyfluniad. Dewisasom yr opsiwn symlaf: rhedeg y cod cyfluniad CMS yn y modd “rhediad sych”, hynny yw, heb gymhwyso newidiadau, ond gyda hysbysiad o'r holl anghysondebau rhwng y cyfluniad arfaethedig a gwirioneddol. Fe wnaethom weithredu hyn trwy redeg pob llyfr chwarae Ansible o bryd i'w gilydd gyda'r opsiwn “—check” ar weinyddion cynhyrchu. Fel bob amser, Ansible AWX sy'n gyfrifol am lansio a diweddaru'r llyfr chwarae (gweler Ffig. 5):
Reis. 5. Gwiriadau am anghysondebau cyfluniad yn Ansible AWX.
Ar ôl gwiriadau, mae AWX yn anfon adroddiad anghysondeb at weinyddwyr. Maent yn astudio'r cyfluniad problemus ac yna'n ei drwsio trwy lyfrau chwarae wedi'u haddasu. Dyma sut rydym yn cynnal y cyfluniad yn yr amgylchedd cynhyrchu ac mae'r CMS bob amser yn gyfredol ac wedi'i gydamseru. Mae hyn yn dileu “gwyrthiau” annymunol pan ddefnyddir cod CMS ar weinyddion “cynhyrchu”.
Bellach mae gennym haen brofi bwysig sy'n cynnwys Ansible AWX/GitLab/Molecule (Ffigur 6).
Reis. 6. Rheoli prawf.
Anodd? Nid wyf yn dadlau. Ond mae'r fath gymhleth o reoli cyfluniad wedi dod yn ateb cynhwysfawr i lawer o gwestiynau sy'n ymwneud ag awtomeiddio cyfluniad gweinydd. Nawr mae gan weinyddion safonol manwerthwr gyfluniad wedi'i ddiffinio'n llym bob amser. Ni fydd CMS, yn wahanol i beiriannydd, yn anghofio ychwanegu'r gosodiadau angenrheidiol, creu defnyddwyr a pherfformio dwsinau neu gannoedd o osodiadau gofynnol.
Nid oes “gwybodaeth gyfrinachol” yng ngosodiadau gweinyddwyr ac amgylcheddau heddiw. Adlewyrchir yr holl nodweddion angenrheidiol yn y llyfr chwarae. Dim mwy o greadigrwydd a chyfarwyddiadau annelwig: “Ei osod fel Oracle rheolaidd, ond mae angen i chi nodi cwpl o leoliadau sysctl ac ychwanegu defnyddwyr gyda'r UID gofynnol. Gofynnwch i'r bechgyn ar waith, maen nhw'n gwybod'.
Mae'r gallu i ganfod anghysondebau cyfluniad a'u cywiro'n rhagweithiol yn rhoi tawelwch meddwl. Heb system rheoli cyfluniad, mae hyn fel arfer yn edrych yn wahanol. Mae problemau'n cronni hyd nes y byddant yn “saethu” i gynhyrchu un diwrnod. Yna cynhelir dadfriffio, caiff ffurfweddiadau eu gwirio a'u cywiro. Ac mae'r cylch yn ailadrodd eto
Ac wrth gwrs, fe wnaethom gyflymu lansiad gweinyddwyr ar waith o sawl diwrnod i oriau.
Wel, ar Nos Galan ei hun, pan oedd plant yn llawen yn dadlapio anrhegion ac oedolion yn gwneud dymuniadau wrth i'r clychau daro, mudodd ein peirianwyr y system SAP i weinyddion newydd. Bydd hyd yn oed Siôn Corn yn dweud mai'r gwyrthiau gorau yw'r rhai sydd wedi'u paratoi'n dda.
ON Mae ein tîm yn aml yn dod ar draws y ffaith bod cwsmeriaid eisiau datrys problemau rheoli cyfluniad mor syml â phosib. Yn ddelfrydol, fel pe bai trwy hud - gydag un offeryn. Ond mewn bywyd mae popeth yn fwy cymhleth (ie, ni chyflwynwyd bwledi arian eto): mae'n rhaid i chi greu proses gyfan gan ddefnyddio offer sy'n gyfleus i dîm y cwsmer.
Awdur: Sergey Artemov, pensaer adran "Systemau Gwybodaeth Jet"
Ffynhonnell: hab.com