Kui teie IT-infrastruktuur kasvab liiga kiiresti, peate tôtama valiku – kas suurendada inimressursse selle toetamiseks või alustada automatiseerimist. Teatud aja jooksul elasime esimeses paradigmas, kuid seejärel algas pikk tee Infrastructure-as-Code'i suunas.
Tõepoolest, NSPK ei ole idufirma, kuid selline õhkkond valitses ettevõttes selle esimese olemasolu aasta jooksul ning need olid väga huvitavad aastad. Minu nimi on , olen rohkem kui 10 aastat toetanud kõrgtehnoloogia nõudmistega Linuxi infrastruktuuri. Liitusin NSPK meeskonnaga jaanuaris 2016 ja kahjuks ei kogenud ettevõtte algusaegu, kuid tulin perioodil, mil toimusid suured muutused.
Üldiselt võib öelda, et meie meeskond pakub ettevõttele kahte toodet. Esimene on infrastruktuur. Postkast peab töötama, DNS peab toimima, ja domeeni kontrollijad peavad lastma teid serveritesse, mis ei tohi kokku kukkuda. Ettevõtte IT-maastik on tohutu! Need on business&mission critical süsteemid, mille kättesaadavuse nõuded on mõnel juhul 99,999. Teine toode on serverid, nii füüsilised kui virtuaalsed. Eksisteerivates tuleb hoolt kanda, ja uusi tuleb regulaarselt tarnida paljusid osakondi. Selles artiklis tahan rõhutada, kuidas me arendasime infrastruktuuri, mis toetab elutsüklit. serverid.
Teekonna algus
Alguses nägi meie tehnoloogiapeal välja järgmine:
OS CentOS 7
Domeeni kontrollijad FreeIPA
Automatiseerimine – Ansible(+Tower), Cobbler
Kõik need asusid kolmes domeenis, mis olid jaotatud mitmele andmekeskusele. Ühes andmekeskuses olid kontorisüsteemid ja testimisplatvormid, teistes PROD.
Serverite loomine nägi mingil hetkel välja nii:
VM CentOS minimal mall ja vajalik minimaalne, näiteks korrektne /etc/resolv.conf, kõik muu saab Ansible'i kaudu.
CMDB – Excel.
Kui server on füüsiline, siis OS installitakse selle asemel, et virtuaalmasinat kopeerida, Cobbleri abil – Cobbleri konfiguratsioonile lisatakse sihtserveri MAC-aadresse, server saab DHCP kaudu IP-aadressi ja seejärel installitakse OS.
Alguses proovisime isegi teha mingit konfiguratsioonihaldust Cobbleris. Kuid aja jooksul hakkas see tekitama probleeme konfiguratsioonide ülekandmisel nii teistesse andmekeskustesse kui ka Ansible'i koodi VM ettevalmistamiseks.
Paljude jaoks oli Ansible sel ajal mugav Bash'i laiendus, ja me ei hoidunud shell'i ja sed'i kasutamisest. Üks sõna – Bashsible. See tõi kaasa selle, et kui playbook mingil põhjusel serveril ei töötanud, oli lihtsam server kustutada, playbook't parandada ja uuesti üles laadida. Scriptide versioonide haldamist tegelikult ei olnud, samuti mitte konfiguratsioonide ülekandmist.
Näiteks, me tahtsime muuta mingit konfiguratsiooni kõigil serveritel:
- Muudame konfiguratsiooni olemasolevates serverites loogilises segmendis/andmekeskuses. Mõnikord ei toimu see päevaga – saadavuse nõuded ja suurte numbrite seadus ei võimalda kõiki muudatusi korraga rakendada. Ja mõned muudatused on potentsiaalselt hävitavad ning vajavad millegi taaskäivitamist – teenustest kuni operatsioonisüsteemini.
- Korrigeerime Ansible'is
- Korrigeerime Cobbleris
- Korratakse N korda iga loogilise segmendi/andmekeskuse jaoks
Selleks, et kõik muudatused sujuvalt kulgeks, tuli arvesse võtta mitmeid tegureid, ja muudatusi toimub pidevalt.
- Ansible'i koodi, konfiguratsioonifailide refaktoreerimine
- Sisemiste parimate praktikade muutmine
- Muudatused sündmuste/juhuslike olukordade analüüsi tulemusena
- Turvastandardi muudatused, nii sise- kui väliste. Näiteks PCI DSS täiendatakse iga aasta uute nõuetega.
Infrastruktuuri kasv ja teekonna algus
Serverite/logiliste domeenide/andmekeskuste arv suurenes, samas suurenes ka konfiguratsioonivigade arv. Millalgi jõudsime kolme suunani, kuhu oli vaja configuration management'i suunata:
- Automatiseerimine. Küllalt palju tuleb vältida inimfaktorit korduvates toimingutes.
- Korratavus. Infrastruktuuri haldamine on palju lihtsam, kui see on prognoositav. Serverite ja nende ettevalmistamise tööriistade konfiguratsioon peab olema igal pool ühesugune. See on samuti oluline toote meeskondade jaoks – rakendus peab pärast testimist garanteeritult jõudma tootmiskeskkonda, mis on sarnane testkeskkonnaga.
- Muudatuste lihtsus ja läbipaistvus configuration management'is.
Mõned tööriistad on veel lisada.
Koodihoiustajana valisime GitLab CE, mitte vähem tähtis oli ka sisseehitatud CI/CD moodulite olemasolu.
Salajaste hoidla – Hashicorp Vault, sealhulgas suurepärane API.
Konfiguratsioonide ja ansible rollide testimine – Molecule + Testinfra. Testid toimuvad palju kiiremini, kui ühendate ansible’i mitogeniga. Samal ajal hakkasime kirjutama oma CMDB-d ja orkestrit avtomaatseks nasteks (pildil Cobbleri kohal), kuid see on juba hoopis teine lugu, millest räägib tulevikus minu kolleeg ja nende süsteemide pea arendaja.
Meie valik:
Molecule + Testinfra
Ansible + Tower + AWX
Serverite maailm + DITNET (oma arendus)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault
Muide, ansible rollidest. Alguses oli üks, pärast mitmeid refaktoreerimisi sai neid 17. Soovitan kategooriliselt jagada monoliit idempotentseteks rollideks, mida saab hiljem eraldi käivitada, lisaks saab lisada silte. Me jagasime rollid funktsionaalsuse järgi – võrk, logimine, paketid, riistvara, molecule jne. Tegelikult järgnesime allpool olevatele strateegiatele. Ma ei nõua, et see oleks ainus tõde, kuid see töötas meie jaoks.
- Serverite kopeerimine "kuldsetest piltidest" on kuritegu!Peamiste puudustega – te ei tea täpselt, millises seisundis pildid praegu on, ja et kõik muudatused jõuavad kõikidesse piltidesse kõigil virtualiseerimissektoritel.
- Kasutage vaikimisi konfiguratsioonifaile minimaalselt ja leppige kokku teiste osakondadega, et põhikohustused süsteemifailide osas on teie., näiteks:
- Jätke /etc/sysctl.conf tühjaks, seadistused peavad olema ainult /etc/sysctl.d/. Teie vaikimisi ühes failis, kohandused rakenduse jaoks teises.
- Kasutage override-faile systemd üksuste redigeerimiseks.
- Template'ige kõik konfiguratsioonid ja tooge need täielikult sisse, vältige võimaluse korral 'sed' ja sarnaseid tööriistu mängukäikudes.
- Refaktoreerides konfigureerimise haldus süsteemi:
- Jagage ülesanded loogilisteks üksusteks ja kirjutage monoliit rollideks ümber.
- Kasutage linte! Ansible-lint, yaml-lint jne.
- Muuda lähenemist! Mingit bashsible. Tuleb kirjeldada süsteemi olekut.
- Kõigi Ansible rollide jaoks tuleb kirjutada testid molekulis ja genereerida aruanded üks kord päevas.
- Meie puhul, pärast testide ettevalmistamist (mille arv ületas 100) leidis umbes 70000 viga. Parandamine võttis mitu kuud.
Meie teostus
Nii et, ansible rollid olid valmis, template'eritud ja linters kontrollitud. Ja isegi git'id on kõik üles tõstetud. Kuid küsimus usaldusväärsest koodi edastamisest erinevatesse segmentidesse jäi avatuks. Otsustasime sünkroniseerida skriptidega. Näeb välja nii:
Pärast muudatuse saabumist käivitatakse CI, luuakse testserver, käivad läbi rollid ja testitakse molekuliga. Kui kõik on korras, saadetakse kood tootmisettevõtte haru. Kuid me ei rakenda uut koodi olemasolevatele serveritele automaatselt. See on omamoodi takistus, mis on vajalik meie süsteemide kõrge kättesaadavuse tagamiseks. Ja kui infrastruktuur muutub tohutuks, tuleb mängu ka suurte numbrite seadus – isegi kui olete kindel, et muudatus on ohutu, võib see viia kurbade tagajärgedeni.
Serverite loomise variante on samuti palju. Lõpuks valisime kohandatud skriptid Pythoni peal. CI jaoks ansible:
- name: create1.yml - Loo VM 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 on, kuhu me jõudsime, süsteem jätkab elu ja arenemist.
- 17 ansible-rolli serveri seadistamiseks. Iga roll on mõeldud lahendama eraldi loogilist ülesannet (logimine, auditeerimine, kasutajate autoriseerimine, monitooring jne).
- Rollide testimine. Molecule + TestInfra.
- Omandatud arendus: CMDB + Orkestrator.
- Serveri loomise aeg ~30 minutit, automatiseeritud ja praktiliselt ei sõltu ülesannete järjekorrast.
- Ühtne infrastruktuuri seisund/nimetus kõigis segmentides – mängukavad, hoidlad, virtualiseerimise elemendid.
- Igapäevane serverite oleku kontroll koos aruannete genereerimisega erinevustest standarditega.
Loodan, et minu jutt on kasulik neile, kes on veel teel. Millist automatiseerimise steki kasutate teie?
Allikas: habr.com
