Kui teie IT-infrastruktuur kasvab liiga kiiresti, seisate varem või hiljem valiku ees: suurendada selle toetamiseks lineaarselt inimressurssi või alustada automatiseerimist. Kuni mingi hetkeni elasime esimeses paradigmas ja siis algas pikk tee Infrastructure-as-Code poole.
Loomulikult ei ole NSPK startup, kuid selline õhkkond valitses ettevõttes esimestel eksisteerimisaastatel ja need olid väga huvitavad aastad. Minu nimi on , olen toetanud kõrgete käideldavusnõuetega Linuxi infrastruktuuri üle 10 aasta. Ta liitus NSPK meeskonnaga 2016. aasta jaanuaris ja kahjuks ei näinud ta ettevõtte eksisteerimise algust, kuid jõudis suurte muutuste etappi.
Üldiselt võib öelda, et meie meeskond tarnib ettevõttele 2 toodet. Esimene on infrastruktuur. Mail peaks töötama, DNS peaks töötama ja domeenikontrollerid peaksid laskma teid serveritesse, mis ei peaks kokkujooksma. Ettevõtte IT-maastik on tohutu! Need on äri- ja missioonikriitilised süsteemid, mõnede saadavusnõuded on 99,999 XNUMX. Teine toode on serverid ise, nii füüsilised kui ka virtuaalsed. Olemasolevaid tuleb jälgida ja uusi tuleb regulaarselt paljudest osakondadest klientideni tarnida. Selles artiklis tahan keskenduda sellele, kuidas arendasime serveri elutsükli eest vastutava infrastruktuuri.
Algus reisi
Meie teekonna alguses nägi meie tehnoloogiapakk välja selline:
OS CentOS 7
FreeIPA domeenikontrollerid
Automaatika - Ansible(+torn), kingsepp
Kõik see asus kolmes domeenis, mis olid levinud mitmes andmekeskuses. Ühes andmekeskuses on kontorisüsteemid ja testimispaigad, ülejäänutes PROD.
Serverite loomine nägi ühel hetkel välja selline:
VM mallis on CentOS minimaalne ja nõutav miinimum on nagu õige /etc/resolv.conf, ülejäänu tuleb Ansible kaudu.
CMDB – Excel.
Kui server on füüsiline, siis virtuaalse masina kopeerimise asemel installiti sellesse operatsioonisüsteem Cobbleri abil - sihtserveri MAC-aadressid lisatakse Cobbleri konfiguratsiooni, server saab DHCP kaudu IP-aadressi ja seejärel OS. lisatakse.
Algul proovisime isegi Cobbleris mingit konfiguratsioonihaldust teha. Kuid aja jooksul hakkas see tekitama probleeme konfiguratsioonide teisaldamisega nii teistesse andmekeskustesse kui ka VM-ide ettevalmistamise Ansible koodiga.
Sel ajal tajusid paljud meist Ansible'i kui Bashi mugavat laiendust ega koonerdanud shelli ja sed-i kasutavate kujundustega. Üldiselt Bashsible. See viis lõpuks selleni, et kui mänguraamat mingil põhjusel serveris ei töötanud, oli lihtsam server kustutada, mänguraamat parandada ja uuesti käivitada. Sisuliselt puudus skriptide versioonimine ega konfiguratsioonide teisaldatavus.
Näiteks tahtsime muuta mõnda konfiguratsiooni kõigis serverites:
- Muudame konfiguratsiooni olemasolevates serverites loogilises segmendis/andmekeskuses. Mõnikord mitte ühe päevaga – juurdepääsetavuse nõuded ja suurte arvude seadus ei võimalda kõiki muudatusi korraga rakendada. Ja mõned muudatused on potentsiaalselt hävitavad ja nõuavad millegi taaskäivitamist - teenustest OS-i endani.
- Selle parandamine Ansibles
- Parandame selle Cobbleris
- Korrake N korda iga loogilise segmendi/andmekeskuse jaoks
Et kõik muudatused sujuks, oli vaja arvestada paljude teguritega ning muutusi toimub pidevalt.
- Võimalik koodi, konfiguratsioonifailide taastamine
- Sisemiste parimate tavade muutmine
- Muudatused juhtumite/õnnetuste analüüsi tulemuste põhjal
- Turvastandardite muutmine, nii sisemised kui ka välised. Näiteks PCI DSS-i uuendatakse igal aastal uute nõuetega
Infrastruktuuri kasv ja teekonna algus
Kasvas serverite/loogiliste domeenide/andmekeskuste arv ja koos nendega ka konfiguratsioonide vigade arv. Mingil hetkel jõudsime kolme suunas, milles konfiguratsioonihaldust tuleb arendada:
- Automatiseerimine. Võimaluse korral tuleks vältida inimlikke eksimusi korduvate operatsioonide puhul.
- Korratavus. Infrastruktuuri on palju lihtsam hallata, kui see on prognoositav. Serverite konfiguratsioon ja nende ettevalmistamise tööriistad peaksid olema kõikjal ühesugused. See on oluline ka tootemeeskondade jaoks – pärast testimist peab olema garanteeritud, et rakendus jõuab testkeskkonnaga sarnaselt konfigureeritud tootmiskeskkonda.
- Konfiguratsioonihalduses muudatuste tegemise lihtsus ja läbipaistvus.
Jääb lisada paar tööriista.
Valisime oma koodihoidlaks GitLab CE, eriti selle sisseehitatud CI/CD moodulite jaoks.
Saladuste varahoidla - Hashicorp Vault, sh. suurepärase API jaoks.
Konfiguratsioonide ja võimalike rollide testimine – Molecule+Testinfra. Testid lähevad palju kiiremini, kui ühendate võimaliku mitogeeniga. Samal ajal hakkasime kirjutama oma CMDB-d ja orkestraatorit automaatseks juurutamiseks (üleval Cobbleri pildil), kuid see on hoopis teine lugu, mida minu kolleeg ja nende süsteemide peamine arendaja tulevikus räägivad.
Meie valik:
Molekul + Testinfra
Ansible + torn + AWX
Serverite maailm + DITNET (oma arendus)
Cobbler
Gitlab + GitLabi jooksja
Hashicorpi varahoidla
Muide, asjalike rollide kohta. Algul oli neid ainult üks, kuid peale mitmeid ümbertöötlusi 17. Soovitan tungivalt jagada monoliit idempotentseteks rollideks, mida saab seejärel eraldi käivitada, lisaks saab lisada silte. Jagasime rollid funktsionaalsuse järgi – võrk, logimine, paketid, riistvara, molekul jne. Üldiselt järgisime alltoodud strateegiat. Ma ei väida, et see on ainus tõde, kuid see töötas meie jaoks.
- Serverite kopeerimine “kuldpildist” on kurjast!Peamine puudus on see, et te ei tea täpselt, millises olekus pildid praegu on, ja et kõik muudatused puudutavad kõiki pilte kõigis virtualiseerimisfarmides.
- Kasutage minimaalselt vaikekonfiguratsioonifaile ja nõustuge teiste osakondadega, et vastutate peamiste süsteemifailide eest, näiteks:
- Jätke /etc/sysctl.conf tühjaks, sätted peaksid olema ainult failis /etc/sysctl.d/. Teie vaikimisi ühes failis, kohandatud rakenduse jaoks teises.
- Kasutage süsteemiüksuste redigeerimiseks alistamisfaile.
- Koostage kõik konfiguratsioonid ja lisage need täielikult; võimalusel ärge mänguraamatutes sed-i ega selle analooge
- Konfiguratsioonihaldussüsteemi koodi ümberkujundamine:
- Jaotage ülesanded loogilisteks üksusteks ja kirjutage monoliit ümber rollideks
- Kasutage lintereid! Ansible-lint, yaml-lint jne
- Muutke oma lähenemist! Ei mingit jaburat. On vaja kirjeldada süsteemi olekut
- Kõigi Ansible rollide jaoks peate kirjutama testid molekulis ja looma aruandeid kord päevas.
- Meie puhul leiti pärast testide (mida on üle 100) ettevalmistamist umbes 70000 XNUMX viga. Selle parandamiseks kulus mitu kuud.
Meie rakendamine
Niisiis, võimalikud rollid olid valmis, mallitud ja linterite poolt kontrollitud. Ja isegi gitte kasvatatakse igal pool. Kuid küsimus usaldusväärse koodi edastamise kohta erinevatesse segmentidesse jäi lahtiseks. Otsustasime skriptidega sünkroonida. Näeb välja selline:
Pärast muudatuse saabumist käivitatakse CI, luuakse testserver, rullutakse välja rollid ja testitakse molekuli poolt. Kui kõik on korras, läheb kood tooteharusse. Kuid me ei rakenda uut koodi masinas olemasolevatele serveritele. See on omamoodi kork, mis on vajalik meie süsteemide kõrge kättesaadavuse tagamiseks. Ja kui infrastruktuur muutub tohutuks, hakkab mängu suurte arvude seadus – isegi kui olete kindel, et muudatus on kahjutu, võib see kaasa tuua kohutavaid tagajärgi.
Serverite loomiseks on ka palju võimalusi. Lõppkokkuvõttes valisime kohandatud Pythoni skriptid. Ja CI võimalike jaoks:
- 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}}"Selleni oleme jõudnud, süsteem elab ja areneb edasi.
- 17 Võimalikud rollid serveri seadistamisel. Iga roll on mõeldud eraldi loogilise ülesande lahendamiseks (logimine, auditeerimine, kasutaja autoriseerimine, jälgimine jne).
- Rolli testimine. Molekul + TestInfra.
- Omaarendus: CMDB + Orchestrator.
- Serveri loomise aeg on ~30 minutit, automatiseeritud ja praktiliselt sõltumatu tegumijärjekorrast.
- Sama infrastruktuuri olek/nimetamine kõikides segmentides – mänguraamatud, hoidlad, virtualiseerimiselemendid.
- Igapäevane serveri oleku kontroll koos aruannete genereerimisega standardile mittevastavuse kohta.
Loodan, et minu lugu on kasulik neile, kes on oma teekonna alguses. Millist automatiseerimispakki te kasutate?
Allikas: www.habr.com