Kui teie IT infrastruktuur kasvab liiga kiiresti, seisate varem või hiljem silmitsi valikuga – kas suurendada inimesi selle toetamiseks või alustada automatiseerimist. Kuni teatud hetkeni elasime me esimeses paradigmas, seejärel algas pikk teekond Infrastructure-as-Code'i juurde.
Muidugi ei ole NSPK startup, kuid selline õhkkond valitses ettevõttes selle esimestel tegevusaastatel, ja need olid väga huvitavad aastad. Minu nimi on , olen üle 10 aasta hooldanud Linuxi infrastruktuuri, millele on seatud kõrged kättesaadavuse nõuded. Liitusin NSPK meeskonnaga 2016. aasta jaanuaris ja kahjuks ei olnud ma ettevõtte loomise algusaegadel, kuid tulin suure muutuste etapi ajal.
Üldiselt võib öelda, et meie meeskond toob ettevõttele välja kaks toodet. Esiteks – infrastruktuur. Post ei tohi seista, DNS peab töötama ja domeeni kontrollijad peavad lasma teid serveritesse, mis ei tohi kokku kukkuda. Ettevõtte IT maastik on tohutu! Need on business&mission critical süsteemid, mõnedel on kättesaadavuse nõudeks 99,999. Teine toode – need on serverid, füüsilised ja virtuaalsed. Me peame olemasolevaid jälgima ja uusi regulaarset tarnima paljudele osakondadele. Selles artiklis tahan rõhutada, kuidas me arendasime infrastruktuuri, mis vastutab elutsükli eest. serverite.
Teekonna algus
Teekonna alguses nägi meie tehnoloogia virn välja järgmiselt:
OS CentOS 7
Domeeni kontrollijad FreeIPA
Automatiseerimine – Ansible(+Tower), Cobbler
Kõik see asus kolme domeeni, jaotatuna mitme andmekeskuse vahel. Ühes andmekeskuses – kontorisüsteemid ja testimispoliigonid, teistes PROD.
Serverite loomine nägi mingil hetkel välja nii:
VM CentOS minimal malli ja vajalik miinimum, nagu õige /etc/resolv.conf, tuleb ülejäänu Ansible'iga.
CMDB – Excel.
Kui server on füüsiline, siis installitakse selle peale OS mitte virtuaalse masina kopeerimise teel, vaid Cobbleri abil – Cobbleri konfi lisatakse sihtserveri MAC-aadressid, server saab DHCP kaudu IP-aadressi ja seejärel installitakse OS.
Alguses proovisime me isegi Cobbleris mingit konfiguratsioonihaldust. Kuid aja jooksul hakkas see tekitama probleeme konfiguratsioonide ülekandmisel nii teistesse andmekeskustesse kui ka Ansible'i koodile, mis valmistab VM-e ette.
Ansible'it nägid paljud meist toona kui mugavat Bash'i laiendust ja ei pidanud tagasihoidlikuks shell'i, sed'i kasutamise konstruktsioonide osas. Ühesõnaga, Bashsible. See tõi lõpuks kaasa selle, et kui playbook ei töötanud mingil põhjusel serveris, oli lihtsam server kustutada, playbook 'i parandada ja uuesti käivitada. Mingeid versioonihalduse skripte ei toimunud ning konfiguratsioonide ülekandmine ei olnud samuti võimalik.
Näiteks, kui soovisime muuta mingit konfiguratsiooni kõikides serverites:
- Muudame konfiguratsiooni olemasolevates serverites loogilises segmendis/andmekeskuses. Mõnikord ei pruugi see toimuda ühe päevaga – kättesaadavuse nõuded ja suurte numbrite seadus ei luba kõiki muudatusi korraga rakendada. Mõned muudatused võivad olla potentsiaalselt hävitavad ja nõuavad millegi_restartimist – alates teenustest kuni kogu OS-ni.
- Parandame Ansible'is
- Parandame Cobbleris
- Korrake N korda iga loogilise segmendi/andmekeskuse jaoks
Selleks, et kõik muudatused sujuksid, tuli arvesse võtta mitmeid tegureid, ja muudatused toimuvad pidevalt.
- Ansible'i koodi, konfiguratsioonifailide refaktooring
- Siseste best practice'ide muutmine
- Muudatused pärast intsidentide/õnnetuste analüüsi
- Turvastandardite muutmine, nii sisemised kui välised. Näiteks PCI DSS täiendatakse igal aastal uute nõuetega.
Infrastruktuuri kasv ja teekonna algus
Serverite/loogiliste domeenide/andmekeskuste arv kasvas, koos sellega konfiguratsioonide vigade hulk. Ühel hetkel jõudsime kolme suunani, kuhu on vaja arendada konfiguratsioonihaldust:
- Automatiseerimine. Kuidas iganes võimalik, tuleb vältida inimfaktorit korduvates toimingutes.
- Korduvus. Infrastruktuuri haldamine on palju lihtsam, kui see on ettearvatav. Serverite ja nende ettevalmistamise tööriistade konfiguratsioon peab olema igal pool identne. See on samuti oluline tootearenduse meeskondade jaoks – rakendus peab pärast testimist jõudma tootmis keskkonda, mis on seadistatud analooge testkeskkonnale.
- Mugavus ja läbipaistvus muudatuste tegemisel konfiguratsioonihalduses.
Jäänud on lisada paar tööriista.
Koodide hoidjana valisime GitLab CE, mitte viimaseks tagasihoidlikuks ühtekuuluvasse CI/CD mudelisse.
Salvestite hoidjana – Hashicorp Vault, sealhulgas suurepärase API tõttu.
Konfiguratsioonide ja ansible rollide testimine – Molecule + Testinfra. Testid toimuvad palju kiiremini, kui ühendate ansible'i mitogeniga. Samal ajal alustasime oma CMDB ja orkestri kirjutamist automaatse juurutamise jaoks (pildil Cobbleri kohal), kuid see on juba hoopis teine lugu, millest räägib tulevikus minu kolleeg ja nende süsteemide peamine arendaja.
Meie valik:
Molecule + Testinfra
Ansible + Tower + AWX
Serverite maailm + DITNET (Omandatud arendus)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault
Muide ansible'i rollidest. Alguses oli neid üks, pärast mitmeid refaktoreerimisi muutus neid 17. Soovitan tungivalt jagada monoliitseid rolle idempotentseteks rollideks, mida saab hiljem eraldi käivitada, lisades vajadusel silte. Me jagasime rolle funktsiooni järgi – võrgundus, logimine, paketid, riistvara, molecule jne. Ja üldiselt järgnesime allolevale strateegiale. Ma ei väida, et see on ainuõige tõde, kuid meil töötas see.
- Serverite kopeerimine "kuldse pildi" järgi on kuri!Peamised puudused – te ei tea kindlasti, mis seisus pildid hetkel on, ja kõik muudatused satuvad kõigi piltide kaudu kõikidesse virtualiseerimise farmidesse.
- Kasutage vaikimisi konfiguratsioonifaile minimaalselt ja leppige teiste osakondadega kokku, et peamiste süsteemifailide eest vastutate teie., näiteks:
- Jätke /etc/sysctl.conf tühjaks, seaded peaksid olema ainult /etc/sysctl.d/. Teie vaikimisi ühes failis, kohandatud rakenduse jaoks teises.
- Kasutage override faile systemd unitide redigeerimiseks.
- Mallige kõik konfiguratsioonid ja sisestage need täielikult, võimalusel vältige sed'i ja selle sarnaseid käsklusi mängudes.
- Refaktoreerides konfiguratsioonihalduse koodi:
- Jagage ülesandeid loogilisteks üksusteks ja kirjutage monoliit rollide formaadis.
- Kasutage lintereid! Ansible-lint, yaml-lint jne.
- Muutke lähenemist! Unustage bashsible. Tuleb kirjeldada süsteemi olekut.
- Iga Ansible rolli jaoks tuleb kirjutada testid molekulis ja genereerida raportid iga päev.
- Meie puhul, pärast testide ettevalmistamist (mille hulk ületab 100), leidsime umbes 70000 viga. Parandasime neid mitu kuud.
Meie rakendamine
Nii, ansible rollid olid valmis, mallitud ja kontrollitud linteritega. Ja isegi gitid on igal pool üles seatud. Kuid usaldusväärse koodi kohaletoimetamise küsimus erinevatesse segmentidesse jäi avatuks. Otsustasime sünkroniseerida skriptide abil. Näeb välja nii:
Pärast muutuse saabumist käivitatakse CI, luuakse testserver, rakendatakse rolle, testitakse molekuliga. Kui kõik on korras, läheb kood tootmisfiliaali. Kuid me ei rakenda uut koodi olemasolevatele serveritele automaatselt. See on teatud peatamine, mis on vajalik meie süsteemide kõrge kättesaadavuse tagamiseks. Ja kui infrastruktuur muutub tohutuks, mängib rolli ka suurte numbrite seadus – isegi kui olete kindel, et muudatus on kahjutu, võib see viia kurvade tagajärgedeni.
Serverite loomise variante on samuti palju. Me valisime lõpuks kohandatud skriptid Pythonis. Ja CI jaoks ansible:
- name: create1.yml - VM loomine mallist
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}}"Siin ongi see, kuhu me jõudsime, süsteem jätkab elu ja arengut.
- 17 ansible rolli serveri seadistamiseks. Iga roll on mõeldud lahendama erinevat loogilist ülesannet (logimine, auditeerimine, kasutajate autoriseerimine, jälgimine jne).
- Rollide testimine. Molecule + TestInfra.
- Omandatud arendus: CMDB + Orkestrator.
- Serveri loomise aeg ~30 minutit, automatiseeritud ja praktiliselt ei sõltu tööde järjekorrast.
- Infrastruktuuri ühtlane olek/nimetus kõikides segmentides – playbookid, hoidlad, virtualiseerimise elemendid.
- Igapäevane serverite oleku kontroll koos aruannete genereerimisega kõrvalekalletest normist.
Loodan, et minu lugu on kasulik neile, kes on alguses. Millist automatiseerimist steeki teie kasutate?
Allikas: habr.com
