Ef upplýsingatækniinnviðir þínir stækka of hratt muntu fyrr eða síðar standa frammi fyrir vali: auka mannauðinn línulega til að styðja hann eða hefja sjálfvirkni. Fram að einhverjum tímapunkti lifðum við í fyrstu hugmyndafræðinni og þá hófst langa leiðin að Infrastructure-as-Code.
Auðvitað er NSPK ekki sprotafyrirtæki en slíkt andrúmsloft ríkti í fyrirtækinu á fyrstu árum þess og það voru mjög áhugaverð ár. Ég heiti , Ég hef stutt Linux innviði með háum kröfum um framboð í yfir 10 ár. Hann gekk til liðs við NSPK teymið í janúar 2016 og sá því miður ekki upphafið að tilveru félagsins, en kom á stigi mikilla breytinga.
Almennt má segja að teymið okkar útvegar 2 vörur fyrir fyrirtækið. Í fyrsta lagi eru innviðir. Póstur ætti að virka, DNS ætti að virka og lénsstýringar ættu að hleypa þér inn á netþjóna sem ættu ekki að hrynja. Upplýsingatækni landslag fyrirtækisins er risastórt! Þetta eru viðskipta- og verkefnakerfi, kröfur um framboð fyrir sum eru 99,999. Önnur varan eru netþjónarnir sjálfir, líkamlegir og sýndir. Fylgjast þarf með þeim sem fyrir eru og reglulega þarf að koma nýjum til viðskiptavina úr mörgum deildum. Í þessari grein vil ég einbeita mér að því hvernig við þróuðum innviðina sem er ábyrgur fyrir líftíma netþjónsins.
Byrjun á ferð
Í upphafi ferðalags okkar leit tæknistafla okkar svona út:
OS CentOS 7
FreeIPA lénsstýringar
Sjálfvirkni - Ansible(+Tower), Cobbler
Allt þetta var staðsett á 3 lénum, dreift yfir nokkur gagnaver. Í einni gagnaverinu eru skrifstofukerfi og prófunarstaðir, í hinum er PROD.
Að búa til netþjóna á einum tímapunkti leit svona út:
Í VM sniðmátinu er CentOS í lágmarki og nauðsynlegt lágmark er eins og rétt /etc/resolv.conf, restin kemur í gegnum Ansible.
CMDB - Excel.
Ef þjónninn er líkamlegur, þá var stýrikerfið sett upp á hana í stað þess að afrita sýndarvélina með Cobbler - MAC vistföngum miðlarans er bætt við Cobbler stillinguna, þjónninn fær IP tölu í gegnum DHCP og síðan stýrikerfið er bætt við.
Í fyrstu reyndum við meira að segja að gera einhvers konar stillingarstjórnun í Cobbler. En með tímanum fór þetta að valda vandamálum með færanleika stillinga bæði til annarra gagnavera og Ansible kóðans til að undirbúa VMs.
Á þeim tíma litu mörg okkar á Ansible sem þægilega framlengingu á Bash og spöruðum ekki við hönnun með skel og sed. Á heildina litið Bashsible. Þetta leiddi á endanum til þess að ef leikbókin af einhverjum ástæðum virkaði ekki á þjóninum var auðveldara að eyða þjóninum, laga leikbókina og keyra hana aftur. Það var í rauninni engin útgáfa af forskriftum, engin færanleiki á stillingum.
Til dæmis vildum við breyta einhverjum stillingum á öllum netþjónum:
- Við breytum stillingum á núverandi netþjónum í rökrétta hlutanum/gagnaverinu. Stundum ekki á einum degi - aðgengiskröfur og lög um stórar tölur leyfa ekki að öllum breytingum sé beitt í einu. Og sumar breytingar eru hugsanlega eyðileggjandi og krefjast þess að endurræsa eitthvað - allt frá þjónustu til stýrikerfisins sjálfs.
- Er að laga það í Ansible
- Við reddum því í Cobbler
- Endurtaktu N sinnum fyrir hvern rökréttan hluta/gagnaver
Til þess að allar breytingar gengi snurðulaust fyrir sig þurfti að taka tillit til margra þátta og breytingar eiga sér stað stöðugt.
- Refactoring ansible kóða, stillingar skrár
- Breyting á innri bestu starfsvenjum
- Breytingar byggðar á niðurstöðum greiningar atvika/slysa
- Breyttir öryggisstaðlar, bæði innri og ytri. Til dæmis er PCI DSS uppfært með nýjum kröfum á hverju ári
Рост инфраструктуры и начало пути
Fjöldi netþjóna/rökréttra léna/gagnavera jókst og þar með fjöldi villna í stillingum. Á einhverjum tímapunkti komum við að þremur áttum þar sem þarf að þróa stillingarstjórnun:
- Sjálfvirkni. Forðast skal mannleg mistök í endurteknum aðgerðum eins og hægt er.
- Endurtekningarhæfni. Það er miklu auðveldara að stjórna innviðum þegar það er fyrirsjáanlegt. Uppsetning netþjóna og verkfæra fyrir undirbúning þeirra ætti að vera eins alls staðar. Þetta er líka mikilvægt fyrir vöruteymi - eftir prófun þarf að tryggja að forritið endi í framleiðsluumhverfi sem er stillt á svipaðan hátt og prófunarumhverfið.
- Einfaldleiki og gagnsæi við að gera breytingar á stillingarstjórnun.
Það er eftir að bæta við nokkrum verkfærum.
Við völdum GitLab CE sem kóðageymslu okkar, ekki síst fyrir innbyggðu CI/CD einingarnar.
Vault of secrets - Hashicorp Vault, þ.m.t. fyrir frábæra API.
Prófunarstillingar og hugsanleg hlutverk – Molecule+Testinfra. Próf ganga mun hraðar ef þú tengist mítógeni. Á sama tíma byrjuðum við að skrifa okkar eigin CMDB og hljómsveitarstjóra fyrir sjálfvirka dreifingu (á myndinni fyrir ofan Cobbler), en þetta er allt önnur saga, sem kollegi minn og aðalframleiðandi þessara kerfa munu segja í framtíðinni.
Val okkar:
Sameind + Testinfra
Ansible + Tower + AWX
Мир Серверов + DITNET(Собственная разработка)
Skósmiður
Gitlab + GitLab hlaupari
Hashicorp Vault
Við the vegur, um ansible hlutverk. Í fyrstu var það aðeins eitt, en eftir nokkrar endurstillingar voru þær 17. Ég mæli eindregið með því að skipta einliðanum í vanmáttug hlutverk, sem síðan er hægt að ræsa sérstaklega, auk þess er hægt að bæta við merkjum. Við skiptum hlutverkunum eftir virkni - netkerfi, skógarhögg, pakka, vélbúnað, sameindir o.s.frv. Almennt fylgdum við stefnunni hér að neðan. Ég fullyrði ekki að þetta sé eini sannleikurinn, en það virkaði fyrir okkur.
- Að afrita netþjóna frá „gylltu myndinni“ er illt!Helsti ókosturinn er sá að þú veist ekki nákvæmlega í hvaða ástandi myndirnar eru núna og að allar breytingar munu koma á allar myndir í öllum sýndarvæðingarbæjum.
- Notaðu sjálfgefnar stillingarskrár í lágmarki og komdu að samkomulagi við aðrar deildir um að þú sért ábyrgur fyrir helstu kerfisskrám, til dæmis:
- Skildu /etc/sysctl.conf eftir autt, stillingarnar ættu aðeins að vera í /etc/sysctl.d/. Sjálfgefið þitt í einni skrá, sérsniðið fyrir forritið í annarri.
- Notaðu yfirskriftarskrár til að breyta systemd einingum.
- Sniðmát allar stillingar og hafðu þær að öllu leyti; ef mögulegt er, engin sed eða hliðstæður þess í leikbókum
- Að endurskoða kóða stillingarstjórnunarkerfisins:
- Skiptu verkefnum niður í rökréttar einingar og endurskrifaðu einstæðuna í hlutverk
- Notaðu linters! Ansible-lint, yaml-lint, osfrv
- Breyttu nálgun þinni! Ekkert bashible. Nauðsynlegt er að lýsa stöðu kerfisins
- Fyrir öll Ansible hlutverk þarftu að skrifa próf í sameind og búa til skýrslur einu sinni á dag.
- Í okkar tilviki, eftir að hafa undirbúið prófin (þar af eru meira en 100), fundust um 70000 villur. Það tók nokkra mánuði að laga það.
Framkvæmd okkar
Svo voru hlutverkin tilbúin, sniðmát og skoðuð með linters. Og jafnvel gits eru hækkaðir alls staðar. En spurningin um áreiðanlega afhendingu kóða til mismunandi hluta var áfram opin. Við ákváðum að samstilla við handrit. Lítur svona út:
Eftir að breytingin kemur er CI ræst, prófunarþjónn er búinn til, hlutverkum er rúllað út og prófað af sameindinni. Ef allt er í lagi fer kóðinn í prod útibúið. En við notum ekki nýjan kóða á núverandi netþjóna í vélinni. Þetta er eins konar tappa sem er nauðsynlegur fyrir mikið framboð á kerfum okkar. Og þegar innviðirnir verða risastórir kemur lögmálið um stórar tölur við sögu - jafnvel þótt þú sért viss um að breytingin sé skaðlaus getur það haft skelfilegar afleiðingar.
Það eru líka margir möguleikar til að búa til netþjóna. Við enduðum á því að velja sérsniðin Python forskriftir. Og fyrir CI ansible:
- 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}}"Þetta er það sem við erum komin að, kerfið heldur áfram að lifa og þróast.
- 17 Ansible hlutverk til að setja upp þjóninn. Hvert hlutverk er hannað til að leysa sérstakt rökrétt verkefni (skráning, endurskoðun, notendaheimild, eftirlit osfrv.).
- Hlutverkaprófun. Sameind + TestInfra.
- Eigin þróun: CMDB + hljómsveitarstjóri.
- Tími til að búa til netþjón er ~30 mínútur, sjálfvirkur og nánast óháður verkefnaröðinni.
- Sama ástand/nöfnun innviða í öllum hlutum - leikbókum, geymslum, sýndarvæðingarþáttum.
- Dagleg athugun á stöðu netþjóns með gerð skýrslna um misræmi við staðalinn.
Ég vona að saga mín nýtist þeim sem eru á byrjunarreit. Hvaða sjálfvirknistafla notar þú?
Heimild: www.habr.com