Os bydd eich seilwaith TG yn tyfu'n rhy gyflym, yn hwyr neu'n hwyrach byddwch yn wynebu dewis: cynyddu adnoddau dynol yn llinol i'w gefnogi neu ddechrau awtomeiddio. Hyd at ryw bwynt, roeddem yn byw yn y patrwm cyntaf, ac yna dechreuodd y llwybr hir i Seilwaith-fel-Cod.
Wrth gwrs, nid busnes cychwynnol yw NSPK, ond roedd awyrgylch o'r fath yn teyrnasu yn y cwmni ym mlynyddoedd cyntaf ei fodolaeth, ac roedd y rheini'n flynyddoedd diddorol iawn. Fy enw i yw , Rwyf wedi bod yn cefnogi seilwaith Linux gyda gofynion argaeledd uchel ers dros 10 mlynedd. Ymunodd â thîm NSPK ym mis Ionawr 2016 ac, yn anffodus, ni welodd ddechrau bodolaeth y cwmni, ond daeth ar gyfnod o newidiadau mawr.
Yn gyffredinol, gallwn ddweud bod ein tîm yn cyflenwi 2 gynnyrch ar gyfer y cwmni. Y cyntaf yw seilwaith. Dylai post weithio, dylai DNS weithio, a dylai rheolwyr parth eich gadael i mewn i weinyddion na ddylai ddamwain. Mae tirwedd TG y cwmni yn enfawr! Mae'r rhain yn systemau busnes a chenhadaeth hanfodol, a'r gofynion argaeledd ar gyfer rhai yw 99,999. Yr ail gynnyrch yw'r gweinyddwyr eu hunain, corfforol a rhithwir. Mae angen monitro'r rhai presennol, a rhaid danfon rhai newydd yn rheolaidd i gwsmeriaid o lawer o adrannau. Yn yr erthygl hon rwyf am ganolbwyntio ar sut y gwnaethom ddatblygu'r seilwaith sy'n gyfrifol am gylchred oes y gweinydd.
Dechrau o daith
Ar ddechrau ein taith, roedd ein pentwr technoleg yn edrych fel hyn:
OS CentOS 7
Rheolyddion Parth FreeIPA
Awtomeiddio - Atebol (+ Tŵr), Crydd
Roedd hyn i gyd wedi'i leoli mewn 3 pharth, wedi'i wasgaru ar draws sawl canolfan ddata. Mewn un ganolfan ddata mae systemau swyddfa a safleoedd prawf, yn y gweddill mae PROD.
Roedd creu gweinyddwyr ar un adeg yn edrych fel hyn:
Yn y templed VM, mae CentOS yn fach iawn ac mae'r lleiafswm gofynnol fel y cywir /etc/resolv.conf, daw'r gweddill trwy Ansible.
CMDB - Excel.
Os yw'r gweinydd yn gorfforol, yna yn lle copïo'r peiriant rhithwir, gosodwyd yr OS arno gan ddefnyddio Cobbler - mae cyfeiriadau MAC y gweinydd targed yn cael eu hychwanegu at ffurfwedd Cobbler, mae'r gweinydd yn derbyn cyfeiriad IP trwy DHCP, ac yna'r OS yn cael ei ychwanegu.
Ar y dechrau fe wnaethom hyd yn oed geisio gwneud rhyw fath o reolaeth cyfluniad yn Cobbler. Ond dros amser, dechreuodd hyn ddod â phroblemau gyda hygludedd ffurfweddiadau i ganolfannau data eraill ac i'r cod Ansible ar gyfer paratoi VMs.
Bryd hynny, roedd llawer ohonom yn gweld Ansible fel estyniad cyfleus o Bash ac ni wnaethom anwybyddu dyluniadau gan ddefnyddio cragen a sed. Bashsible cyffredinol. Arweiniodd hyn yn y pen draw at y ffaith pe na bai'r llyfr chwarae am ryw reswm yn gweithio ar y gweinydd, roedd yn haws dileu'r gweinydd, trwsio'r llyfr chwarae a'i redeg eto. Yn y bôn, nid oedd unrhyw fersiynau o sgriptiau, dim hygludedd ffurfweddiadau.
Er enghraifft, roeddem am newid rhywfaint o gyfluniad ar bob gweinydd:
- Rydym yn newid y ffurfweddiad ar weinyddion presennol yn y segment rhesymegol/canolfan ddata. Weithiau nid mewn un diwrnod - nid yw gofynion hygyrchedd a chyfraith niferoedd mawr yn caniatáu i bob newid gael ei gymhwyso ar unwaith. Ac mae rhai newidiadau o bosibl yn ddinistriol ac mae angen ailgychwyn rhywbeth - o wasanaethau i'r OS ei hun.
- Ei drwsio yn Ansible
- Rydym yn ei drwsio yn Cobbler
- Ailadrodd N amseroedd ar gyfer pob segment rhesymegol/canolfan ddata
Er mwyn i'r holl newidiadau fynd yn esmwyth, roedd angen ystyried llawer o ffactorau, ac mae newidiadau'n digwydd yn gyson.
- Refactoring cod ansible, ffeiliau ffurfweddu
- Newid arferion gorau mewnol
- Newidiadau yn seiliedig ar ganlyniadau dadansoddiad o ddigwyddiadau/damweiniau
- Newid safonau diogelwch, yn fewnol ac yn allanol. Er enghraifft, mae PCI DSS yn cael ei ddiweddaru gyda gofynion newydd bob blwyddyn
Twf seilwaith a dechrau'r daith
Tyfodd nifer y gweinyddwyr/parthau rhesymegol/canolfannau data, a chyda nhw nifer y gwallau mewn ffurfweddiadau. Ar ryw adeg, daethom i dri chyfeiriad lle mae angen datblygu rheolaeth cyfluniad:
- Awtomatiaeth. Dylid osgoi gwallau dynol mewn gweithrediadau ailadroddus cymaint â phosibl.
- Ailadroddadwyedd. Mae'n llawer haws rheoli seilwaith pan fo'n rhagweladwy. Dylai cyfluniad gweinyddwyr ac offer ar gyfer eu paratoi fod yr un fath ym mhobman. Mae hyn hefyd yn bwysig i dimau cynnyrch - ar ôl profi, rhaid gwarantu y bydd y cais yn dod i ben mewn amgylchedd cynhyrchu wedi'i ffurfweddu'n debyg i'r amgylchedd prawf.
- Symlrwydd a thryloywder gwneud newidiadau i reolaeth cyfluniad.
Mae'n aros i ychwanegu cwpl o offer.
Fe wnaethom ddewis GitLab CE fel ein storfa god, yn anad dim ar gyfer ei fodiwlau CI/CD adeiledig.
Vault o gyfrinachau - Hashicorp Vault, gan gynnwys. ar gyfer yr API gwych.
Profi ffurfweddiadau a rolau ymarferol – Molecule+Testinfra. Mae profion yn mynd yn llawer cyflymach os ydych chi'n cysylltu â mitogen anible. Ar yr un pryd, dechreuon ni ysgrifennu ein CMDB a'n cerddorfa ein hunain i'w defnyddio'n awtomatig (yn y llun uchod Cobbler), ond mae hon yn stori hollol wahanol, y bydd fy nghydweithiwr a phrif ddatblygwr y systemau hyn yn ei hadrodd yn y dyfodol.
Ein dewis:
Moleciwl + Testinfra
Atebol + Twr + AWX
World of Servers + DITNET (Datblygiad eich hun)
Crydd
Gitlab + rhedwr GitLab
Hashicorp Vault
Gyda llaw, am rolau anible. Ar y dechrau dim ond un oedd, ond ar ôl sawl ailffactorio cafwyd 17 ohonynt. Rwy'n argymell yn gryf torri'r monolith yn rolau analluog, y gellir eu lansio ar wahân wedyn; yn ogystal, gallwch ychwanegu tagiau. Rhannwyd y rolau yn ôl swyddogaeth - rhwydwaith, logio, pecynnau, caledwedd, moleciwl ac ati. Yn gyffredinol, dilynwyd y strategaeth isod. Dydw i ddim yn mynnu mai dyma'r unig wirionedd, ond fe weithiodd i ni.
- Mae copïo gweinyddwyr o'r “delwedd aur” yn ddrwg!Y brif anfantais yw nad ydych chi'n gwybod yn union beth yw cyflwr y delweddau nawr, ac y bydd pob newid yn dod i bob delwedd ym mhob fferm rhithwiroli.
- Defnyddiwch y ffeiliau ffurfweddu rhagosodedig i'r lleiafswm a chytunwch ag adrannau eraill mai chi sy'n gyfrifol am y prif ffeiliau system, er enghraifft:
- Gadewch /etc/sysctl.conf yn wag, dim ond yn /etc/sysctl.d/ y dylai'r gosodiadau fod. Eich rhagosodiad mewn un ffeil, wedi'i haddasu ar gyfer y rhaglen mewn ffeil arall.
- Defnyddiwch wrthwneud ffeiliau i olygu unedau system.
- Templed pob ffurfwedd a'u cynnwys yn gyfan gwbl; os yn bosibl, dim sed na'i analogau mewn llyfrau chwarae
- Ailffactorio cod y system rheoli cyfluniad:
- Rhannwch dasgau yn endidau rhesymegol ac ailysgrifennu'r monolith yn rolau
- Defnyddiwch linters! Ansible-lint, yaml-lint, etc
- Newidiwch eich dull! Dim bashsible. Mae angen disgrifio cyflwr y system
- Ar gyfer pob rôl Ansible mae angen i chi ysgrifennu profion mewn moleciwl a chynhyrchu adroddiadau unwaith y dydd.
- Yn ein hachos ni, ar ôl paratoi'r profion (y mae mwy na 100 ohonynt), canfuwyd tua 70000 o wallau. Cymerodd sawl mis i'w drwsio.
Ein gweithrediad
Felly, roedd y rolau cyfrifol yn barod, wedi'u templedi a'u gwirio â linters. Ac mae hyd yn oed gits yn cael eu codi ym mhobman. Ond arhosodd y cwestiwn o gyflwyno cod dibynadwy i wahanol segmentau yn agored. Fe benderfynon ni gydamseru gyda sgriptiau. Edrych fel hyn:
Ar ôl i'r newid gyrraedd, mae CI yn cael ei lansio, gweinydd prawf yn cael ei greu, rolau yn cael eu cyflwyno, a'u profi gan y moleciwl. Os yw popeth yn iawn, mae'r cod yn mynd i'r gangen prod. Ond nid ydym yn cymhwyso cod newydd i weinyddion presennol yn y peiriant. Mae hwn yn fath o stopiwr sy'n angenrheidiol ar gyfer argaeledd uchel ein systemau. A phan ddaw'r seilwaith yn enfawr, daw cyfraith niferoedd mawr i rym - hyd yn oed os ydych chi'n siŵr bod y newid yn ddiniwed, gall arwain at ganlyniadau enbyd.
Mae yna hefyd lawer o opsiynau ar gyfer creu gweinyddwyr. Yn y diwedd fe wnaethon ni ddewis sgriptiau Python personol. Ac ar gyfer CI anible:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Dyma beth rydym wedi dod ato, mae'r system yn parhau i fyw a datblygu.
- 17 Rolau addas ar gyfer sefydlu'r gweinydd. Mae pob un o'r rolau wedi'i gynllunio i ddatrys tasg resymegol ar wahân (logio, archwilio, awdurdodi defnyddwyr, monitro, ac ati).
- Profi rôl. Moleciwl + TestInfra.
- Datblygiad eich hun: CMDB + Cerddorfa.
- Amser creu gweinydd yw ~30 munud, yn awtomataidd ac bron yn annibynnol ar y ciw tasg.
- Yr un cyflwr/enw'r seilwaith ym mhob segment - llyfrau chwarae, storfeydd, elfennau rhithwiroli.
- Gwiriad dyddiol o statws gweinydd gyda chynhyrchu adroddiadau ar anghysondebau gyda'r safon.
Rwy'n gobeithio y bydd fy stori yn ddefnyddiol i'r rhai sydd ar ddechrau eu taith. Pa stac awtomeiddio ydych chi'n ei ddefnyddio?
Ffynhonnell: hab.com