Jei jūsų IT infrastruktūra augs per greitai, anksčiau ar vėliau turėsite pasirinkimą: linijiškai didinti žmogiškuosius išteklius jai palaikyti arba pradėti automatizavimą. Iki tam tikro momento gyvenome pagal pirmąją paradigmą, o tada prasidėjo ilgas kelias į „Infrastructure-as-Code“.
Žinoma, NSPK nėra startuolis, tačiau tokia atmosfera įmonėje vyravo pirmaisiais jos gyvavimo metais ir tai buvo labai įdomūs metai. Mano vardas yra , Aš palaikau Linux infrastruktūrą su aukštais prieinamumo reikalavimais daugiau nei 10 metų. Jis prie NSPK komandos prisijungė 2016 metų sausį ir, deja, nematė pačios įmonės gyvavimo pradžios, tačiau atėjo didelių pokyčių stadijoje.
Bendrai galima teigti, kad mūsų komanda įmonei tiekia 2 produktus. Pirmasis yra infrastruktūra. Paštas turėtų veikti, DNS turėtų veikti, o domeno valdikliai turėtų leisti jus į serverius, kurie neturėtų strigti. Įmonės IT kraštovaizdis didžiulis! Tai verslui ir misijai svarbios sistemos, kai kurių prieinamumo reikalavimai yra 99,999 XNUMX. Antrasis produktas yra patys serveriai, fiziniai ir virtualūs. Esamus reikia stebėti, o naujus reguliariai pristatyti klientams iš daugelio skyrių. Šiame straipsnyje noriu sutelkti dėmesį į tai, kaip sukūrėme infrastruktūrą, kuri yra atsakinga už serverio gyvavimo ciklą.
Kelionės pradžia
Kelionės pradžioje mūsų technologijų krūva atrodė taip:
OS CentOS 7
FreeIPA domenų valdikliai
Automatika - Ansible(+Tower), Cobbler
Visa tai buvo 3 domenuose, pasklidusiuose keliuose duomenų centruose. Viename duomenų centre yra biuro sistemos ir bandymų aikštelės, likusioje – PROD.
Vienu metu serverių kūrimas atrodė taip:
VM šablone CentOS yra minimalus, o reikalingas minimumas yra panašus į teisingą /etc/resolv.conf, visa kita ateina per Ansible.
CMDB – „Excel“.
Jei serveris yra fizinis, vietoj virtualios mašinos kopijavimo, OS joje buvo įdiegta naudojant „Cobbler“ - tikslinio serverio MAC adresai pridedami prie „Cobbler“ konfigūracijos, serveris gauna IP adresą per DHCP, o tada OS. pridedamas.
Iš pradžių net bandėme atlikti tam tikrą konfigūracijos valdymą „Cobbler“. Tačiau laikui bėgant tai pradėjo kelti problemų dėl konfigūracijų perkeliamumo tiek į kitus duomenų centrus, tiek su VM paruošimo Ansible kodu.
Tuo metu daugelis iš mūsų suvokė Ansible kaip patogų „Bash“ plėtinį ir negailėjome dizaino naudojant „shell“ ir „sed“. Apskritai Bashsible. Tai galiausiai lėmė tai, kad jei žaidimo knyga dėl kokių nors priežasčių neveikė serveryje, buvo lengviau ištrinti serverį, pataisyti knygą ir paleisti ją iš naujo. Iš esmės nebuvo jokio scenarijų versijų kūrimo, konfigūracijų perkeliamumo.
Pavyzdžiui, norėjome pakeisti kai kurias konfigūracijas visuose serveriuose:
- Mes keičiame konfigūraciją esamuose serveriuose loginiame segmente/duomenų centre. Kartais ne per vieną dieną – prieinamumo reikalavimai ir didelių skaičių dėsnis neleidžia visų pakeitimų taikyti iš karto. Kai kurie pakeitimai gali būti žalingi ir reikalauja ką nors paleisti iš naujo – nuo paslaugų iki pačios OS.
- Taisome Ansible
- Taisome Cobbler
- Pakartokite N kartų kiekvienam loginiam segmentui / duomenų centrui
Kad visi pokyčiai vyktų sklandžiai, reikėjo atsižvelgti į daugybę faktorių, o pokyčiai vyksta nuolat.
- Galimo kodo pertvarkymas, konfigūracijos failai
- Vidinės geriausios praktikos keitimas
- Pakeitimai remiantis incidentų/avarijų analizės rezultatais
- Keičiasi vidaus ir išorės saugumo standartai. Pavyzdžiui, PCI DSS kasmet atnaujinamas naujais reikalavimais
Infrastruktūros augimas ir kelionės pradžia
Augo serverių/loginių domenų/duomenų centrų skaičius, o kartu ir klaidų skaičius konfigūracijose. Tam tikru momentu priėjome tris kryptis, kuriomis reikia plėtoti konfigūracijos valdymą:
- Automatika. Reikėtų kiek įmanoma vengti žmogiškųjų klaidų atliekant pasikartojančias operacijas.
- Pakartojamumas. Daug lengviau valdyti infrastruktūrą, kai ji yra nuspėjama. Serverių ir jų paruošimo įrankių konfigūracija visur turėtų būti vienoda. Tai svarbu ir produktų komandoms – po testavimo programa turi būti garantuota, kad ji atsidurs gamybinėje aplinkoje, sukonfigūruotoje panašiai kaip testavimo aplinka.
- Konfigūracijos valdymo pakeitimų atlikimo paprastumas ir skaidrumas.
Belieka pridėti porą įrankių.
Mes pasirinkome „GitLab CE“ kaip savo kodų saugyklą, ypač dėl jos integruotų CI / CD modulių.
Paslapčių saugykla - Hashicorp Vault, įsk. už puikią API.
Testavimo konfigūracijos ir galimi vaidmenys – Molecule+Testinfra. Bandymai vyksta daug greičiau, jei prisijungiate prie galimo mitogeno. Tuo pačiu metu mes pradėjome rašyti savo CMDB ir orkestrantą, skirtą automatiniam diegimui (nuotraukoje virš Cobbler), tačiau tai yra visiškai kita istorija, kurią ateityje papasakos mano kolega ir pagrindinis šių sistemų kūrėjas.
Mūsų pasirinkimas:
Molekulė + Testinfra
Ansible + bokštas + AWX
Serverių pasaulis + DITNET (savo kūrimas)
Varnėnas
Gitlab + GitLab bėgikas
Hashicorp saugykla
Beje, apie įmanomus vaidmenis. Iš pradžių buvo tik vienas, bet po kelių pertvarkymų jų buvo 17, primygtinai rekomenduoju suskaidyti monolitą į idempotentus vaidmenis, kuriuos vėliau galima paleisti atskirai, galite pridėti žymų. Pasidalijome vaidmenis pagal funkcionalumą – tinklą, registravimą, paketus, aparatinę įrangą, molekulę ir kt. Apskritai laikėmės toliau pateiktos strategijos. Nesakau, kad tai yra vienintelė tiesa, bet mums tai padėjo.
- Kopijuoti serverius iš „auksinio vaizdo“ yra blogis!Pagrindinis trūkumas yra tas, kad jūs tiksliai nežinote, kokios būklės dabar yra vaizdai, ir kad visi pakeitimai bus taikomi visuose vaizduose visuose virtualizacijos ūkiuose.
- Naudokite numatytuosius konfigūracijos failus iki minimumo ir susitarkite su kitais padaliniais, kad esate atsakingi už pagrindinius sistemos failus, pavyzdžiui:
- Palikite /etc/sysctl.conf tuščią, nustatymai turėtų būti tik /etc/sysctl.d/. Numatytasis viename faile, pritaikytas programai kitame.
- Norėdami redaguoti sistemos vienetus, naudokite nepaisymo failus.
- Sukurkite visas konfigūracijas ir, jei įmanoma, įtraukite jas visiškai, į žaidimų knygas neįtraukite sed ar jo analogų
- Konfigūracijos valdymo sistemos kodo pertvarkymas:
- Suskaidykite užduotis į loginius objektus ir perrašykite monolitą į vaidmenis
- Naudokite linterius! Ansible-lint, yaml-lint ir kt
- Pakeiskite savo požiūrį! Jokio šmeižto. Būtina apibūdinti sistemos būklę
- Visiems Ansible vaidmenims reikia rašyti testus molekulėje ir generuoti ataskaitas kartą per dieną.
- Mūsų atveju, paruošus testus (kurių yra daugiau nei 100), rasta apie 70000 XNUMX klaidų. Jai sutvarkyti prireikė kelių mėnesių.
Mūsų įgyvendinimas
Taigi, galimi vaidmenys buvo paruošti, suformuluoti ir patikrinti linijomis. Ir net gitai visur auginami. Tačiau patikimo kodo pristatymo skirtingiems segmentams klausimas liko atviras. Nusprendėme sinchronizuoti su scenarijais. Atrodo taip:
Gavus pakeitimą, paleidžiama CI, sukuriamas bandomasis serveris, išleidžiami vaidmenys ir išbandoma molekulės. Jei viskas gerai, kodas patenka į gamybos šaką. Bet mes netaikome naujo kodo esamiems mašinos serveriams. Tai tam tikras kamštis, reikalingas aukštam mūsų sistemų prieinamumui. O kai infrastruktūra tampa milžiniška, pradeda veikti didelių skaičių dėsnis – net jei esate tikri, kad pokytis nekenksmingas, tai gali sukelti skaudžių pasekmių.
Taip pat yra daug serverių kūrimo galimybių. Galų gale pasirinkome pasirinktinius Python scenarijus. O CI galima:
- 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}}"Taip ir priėjome, sistema toliau gyvuoja ir vystosi.
- 17 galimų serverio nustatymo vaidmenų. Kiekvienas iš vaidmenų yra skirtas atskirai loginei užduočiai išspręsti (registravimas, auditas, vartotojo autorizacija, stebėjimas ir kt.).
- Vaidmenų testavimas. Molekulė + TestInfra.
- Nuosavas kūrimas: CMDB + Orchestrator.
- Serverio sukūrimo laikas ~30 min., automatizuotas ir praktiškai nepriklausomas nuo užduočių eilės.
- Ta pati infrastruktūros būsena/pavadinimai visuose segmentuose – žaidimų knygelėse, saugyklose, virtualizacijos elementuose.
- Kasdien tikrinama serverio būsena generuojant ataskaitas apie neatitikimus standartui.
Tikiuosi, kad mano istorija bus naudinga tiems, kurie yra savo kelionės pradžioje. Kokį automatikos steką naudojate?
Šaltinis: www.habr.com