Zure IT azpiegitura azkarregi hazten bada, lehenago edo beranduago aukera baten aurrean egongo zara: linealki handitu giza baliabideak laguntzeko edo automatizazioa abiaraztea. Noizbait arte, lehen paradigman bizi izan ginen, eta orduan hasi zen Azpiegitura-koderako bide luzea.
Jakina, NSPK ez da startup bat, baina horrelako giroa izan zen enpresan bere existentziaren lehen urteetan, eta oso urte interesgarriak izan ziren. Nire izena da , 10 urte baino gehiago daramatzat erabilgarritasun handiko eskakizunekin Linux azpiegitura onartzen. 2016ko urtarrilean sartu zen NSPK taldean eta, zoritxarrez, ez zuen konpainiaren existentziaren hasiera-hasierarik ikusi, baina aldaketa handien fasean iritsi zen.
Oro har, esan dezakegu gure taldeak 2 produktu hornitzen dituela enpresarentzat. Lehenengoa azpiegitura da. Postak funtzionatu beharko luke, DNS-k funtzionatu beharko luke eta domeinu-kontrolatzaileek huts egin behar ez duten zerbitzarietan sartu behar zaituzte. Konpainiaren IT panorama handia da! Hauek negozio eta misio kritikoko sistemak dira, batzuen erabilgarritasun-eskakizunak 99,999 dira. Bigarren produktua zerbitzariak beraiek dira, fisikoak eta birtualak. Daudenak kontrolatu behar dira, eta berriak aldian-aldian entregatu behar zaizkie sail askotako bezeroei. Artikulu honetan zerbitzariaren bizi-zikloaz arduratzen den azpiegitura nola garatu genuen zentratu nahi dut.
Bidaia baten hasiera
Gure bidaiaren hasieran, gure teknologia pila hau itxura zen:
OS CentOS 7
Doako IPA domeinu-kontrolatzaileak
Automatizazioa - Ansible(+Tower), Cobbler
Hori guztia 3 domeinutan kokatuta zegoen, hainbat datu-zentrotan banatuta. Datu-zentro batean bulego sistemak eta proba guneak daude, gainerakoetan PROD dago.
Momentu batean zerbitzariak sortzeak honelakoa izan zen:
VM txantiloian, CentOS gutxienekoa da eta behar den minimoa /etc/resolv.conf zuzena bezalakoa da, gainerakoa Ansibleren bidez dator.
CMDB - Excel.
Zerbitzaria fisikoa bada, makina birtuala kopiatu beharrean, sistema eragilea instalatu zen Cobbler erabiliz - xede zerbitzariaren MAC helbideak Cobbler konfigurazioan gehitzen dira, zerbitzariak IP helbide bat jasotzen du DHCP bidez eta, ondoren, OS. gehitzen da.
Hasieran, Cobbler-en konfigurazio kudeaketaren bat egiten saiatu ginen. Baina denborarekin, honek konfigurazioen eramangarritasunarekin arazoak ekartzen hasi ziren, bai beste datu-zentroetara, bai VM-ak prestatzeko Ansible kodeari.
Garai hartan, gutako askok Ansible Bash-en luzapen eroso gisa hautematen genuen eta ez genituen shell eta sed erabiliz diseinuak gutxietsi. Bashsible orokorra. Honek, azken batean, arrazoiren batengatik playbook-ak zerbitzarian funtzionatzen ez bazuen, zerbitzaria ezabatzea, playbook-a konpondu eta berriro exekutatu errazagoa zela ekarri zuen. Funtsean, ez zegoen scripten bertsiorik, ez konfigurazioen eramangarritasunik.
Adibidez, zerbitzari guztietan konfigurazio batzuk aldatu nahi genituen:
- Segmentu logiko/datu zentroan dauden zerbitzarietan konfigurazioa aldatzen dugu. Batzuetan ez egun batean - irisgarritasun eskakizunek eta kopuru handien legeak ez dute onartzen aldaketa guztiak aldi berean aplikatzea. Eta aldaketa batzuk potentzialki suntsitzaileak dira eta zerbait berrabiarazi behar dute - zerbitzuetatik OSra bera.
- Ansible-n konpontzen
- Cobbler-en konpontzen dugu
- Errepikatu N aldiz segmentu/datu zentro logiko bakoitzeko
Aldaketa guztiak ondo joan daitezen, faktore asko kontuan hartu behar ziren, eta aldaketak etengabe gertatzen dira.
- Ansible kodea birfactoring, konfigurazio fitxategiak
- Barneko jardunbide egokiak aldatzea
- Gorabeheren/istripuen analisiaren emaitzetan oinarritutako aldaketak
- Segurtasun estandarrak aldatzea, bai barnekoak bai kanpokoak. Adibidez, PCI DSS urtero baldintza berriekin eguneratzen da
Azpiegituren hazkundea eta ibilbidearen hasiera
Zerbitzarien/domeinu logikoen/datu-zentroen kopurua hazi zen, eta horiekin batera konfigurazioetako erroreen kopurua. Noizbait, konfigurazio kudeaketa garatu behar den hiru norabidetara iritsi ginen:
- Automatizazioa. Eragiketa errepikakorretan giza akatsa saihestu behar da ahal den neurrian.
- Errepikagarritasuna. Askoz errazagoa da azpiegiturak kudeatzea aurreikusten denean. Zerbitzarien eta haiek prestatzeko tresnen konfigurazioa berdina izan behar da leku guztietan. Hau ere garrantzitsua da produktu-taldeentzat - proba egin ondoren, aplikazioa proba-ingurunearen antzera konfiguratutako ekoizpen-ingurunean amaitzea bermatu behar da.
- Konfigurazioaren kudeaketan aldaketak egiteko sinpletasuna eta gardentasuna.
Tresna pare bat gehitzea geratzen da.
GitLab CE aukeratu dugu gure kode biltegi gisa, batez ere integratutako CI/CD moduluengatik.
Sekretuen ganga - Hashicorp Vault, barne. API handirako.
Proba konfigurazioak eta rol ansibleak β Molekula+Testinfra. Probak askoz azkarrago doaz mitogeno ansiblera konektatzen bazara. Aldi berean, gure CMDB eta orkestratzailea idazten hasi ginen inplementazio automatikorako (Cobbler goiko irudian), baina hau guztiz bestelako istorio bat da, nire lankideak eta sistema hauen garatzaile nagusiak etorkizunean kontatuko dutena.
Gure aukera:
Molekula + Testinfra
Ansible + Dorrea + AWX
Zerbitzarien Mundua + DITNET (Bere garapena)
Harri-jasotzailea
Gitlab + GitLab korrikalaria
Hashicorp ganga
Bide batez, rol ansibleei buruz. Hasieran bakarra zegoen, baina hainbat birfaktorizazioaren ondoren 17 izan ziren. Monolitoa idempotente roletan apurtzea gomendatzen dut, gero bereizita abiarazteko; gainera, etiketak gehi ditzakezu. Funtzionalitateen arabera banatu ditugu rolak: sarea, erregistroa, paketeak, hardwarea, molekula eta abar. Oro har, beheko estrategia jarraitu dugu. Ez dut azpimarratzen hori denik egia bakarra, baina balio izan zigun.
- "Urrezko iruditik" zerbitzariak kopiatzea gaiztoa da!Desabantaila nagusia da ez dakizula zehatz-mehatz zein egoeratan dauden irudiak orain, eta aldaketa guztiak birtualizazio baserri guztietako irudi guztietan etorriko direla.
- Erabili lehenetsitako konfigurazio-fitxategiak ahalik eta gehien eta adostu beste sail batzuekin zu zaren sistemaren fitxategi nagusien arduraduna, adibidez:
- Utzi /etc/sysctl.conf hutsik, ezarpenak /etc/sysctl.d/-en soilik egon beharko lukete. Zure lehenetsia fitxategi batean, aplikaziorako pertsonalizatua beste batean.
- Erabili gainidazteko fitxategiak systemd unitateak editatzeko.
- Txantiloi konfigurazio guztiak eta sartu oso-osorik; ahal bada, ez sed edo bere analogorik playbooketan
- Konfigurazioa kudeatzeko sistemaren kodea birfactorizatzea:
- Banatu zereginak entitate logikoetan eta berridatzi monolitoa roletan
- Erabili linters! Ansible-lint, yaml-lint, etab
- Aldatu zure ikuspegia! Bashable ez. Beharrezkoa da sistemaren egoera deskribatzea
- Ansible rol guztietarako probak molekula batean idatzi eta txostenak sortu behar dituzu egunean behin.
- Gure kasuan, probak prestatu ondoren (horietatik 100 baino gehiago dira), 70000 akats inguru aurkitu ziren. Hainbat hilabete behar izan zituen konpontzeko.
Gure ezarpena
Beraz, rol ansibleak prest zeuden, txantiloiak eta lintersek egiaztatuak. Eta gits ere nonahi planteatzen dira. Baina segmentu desberdinetara kode fidagarriaren entregaren auzia irekita geratu zen. Scriptekin sinkronizatzea erabaki genuen. Honela dirudi:
Aldaketa iritsi ondoren, CI abiarazten da, proba zerbitzari bat sortzen da, rolak zabaltzen dira eta molekulak probatzen ditu. Dena ondo badago, kodea prod adarra doa. Baina ez diegu kode berririk aplikatzen makinan dauden zerbitzariei. Gure sistemen erabilgarritasun handia izateko beharrezkoa den tapoi moduko bat da. Eta azpiegitura handia bihurtzen denean, kopuru handien legea sartzen da jokoan; aldaketak kaltegabeak direla ziur egon arren, ondorio latzak ekar ditzake.
Zerbitzariak sortzeko ere aukera asko daude. Python script pertsonalizatuak aukeratzen amaitu genuen. Eta CI ansiblerako:
- 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}}"Honetara heldu gara, sistemak bizitzen eta garatzen jarraitzen du.
- 17 Zerbitzaria konfiguratzeko Ansible rolak. Rol bakoitza zeregin logiko bat ebazteko diseinatuta dago (erregistroa, auditoria, erabiltzailearen baimena, jarraipena, etab.).
- Rolen probak. Molekula + TestInfra.
- Garapen propioa: CMDB + Orkestratzailea.
- Zerbitzaria sortzeko denbora ~30 minutukoa da, automatizatua eta ia zeregin-ilaratik independentea.
- Azpiegituraren egoera/izen bera segmentu guztietan: liburuak, biltegiak, birtualizazio elementuak.
- Zerbitzariaren egoera egunero egiaztatzea estandararekiko desadostasunei buruzko txostenak sortuz.
Espero dut nire istorioa baliagarria izatea bidaiaren hasieran daudenentzat. Zein automatizazio pila erabiltzen duzu?
Iturria: www.habr.com