Jos IT-infrastruktuurisi kasvaa liian nopeasti, joudut ennemmin tai myöhemmin valinnan eteen: lisää sen tukemiseksi lineaarisesti henkilöstöresursseja tai käynnistä automaatio. Johonkin pisteeseen asti elimme ensimmäisessä paradigmassa, ja sitten alkoi pitkä tie Infrastructure-as-Codeen.
NSPK ei tietenkään ole startup, mutta tällainen ilmapiiri hallitsi yrityksessä sen olemassaolon ensimmäisinä vuosina, ja ne olivat erittäin mielenkiintoisia vuosia. Nimeni on , Olen tukenut Linux-infrastruktuuria korkeilla käytettävyysvaatimuksilla yli 10 vuoden ajan. Hän liittyi NSPK-tiimiin tammikuussa 2016, eikä valitettavasti nähnyt yrityksen olemassaolon alkua, vaan tuli suurten muutosten vaiheeseen.
Yleisesti ottaen voimme sanoa, että tiimimme toimittaa 2 tuotetta yritykselle. Ensimmäinen on infrastruktuuri. Postin pitäisi toimia, DNS:n pitäisi toimia ja verkkotunnuksen ohjainten pitäisi päästää sinut palvelimiin, joiden ei pitäisi kaatua. Yrityksen IT-maailma on valtava! Nämä ovat liiketoiminta- ja tehtäväkriittisiä järjestelmiä, joiden saatavuusvaatimukset ovat 99,999 XNUMX. Toinen tuote on itse palvelimet, fyysiset ja virtuaaliset. Vanhoja on seurattava ja uusia tulee toimittaa säännöllisesti asiakkaille monelta osastolta. Tässä artikkelissa haluan keskittyä siihen, kuinka kehitimme infrastruktuurin, joka vastaa palvelimen elinkaaresta.
Alku matkan
Matkamme alussa teknologiapinomme näytti tältä:
Käyttöjärjestelmä CentOS 7
FreeIPA-verkkotunnuksen ohjaimet
Automaatio - Ansible(+Tower), Suutarit
Kaikki tämä sijaitsi 3 verkkotunnuksessa, jotka olivat hajallaan useissa palvelinkeskuksissa. Yhdessä palvelinkeskuksessa on toimistojärjestelmiä ja testipaikkoja, muissa PROD.
Palvelimien luominen yhdessä vaiheessa näytti tältä:
VM-mallissa CentOS on minimaalinen ja vaadittu minimi on kuin oikea /etc/resolv.conf, loput tulee Ansiblen kautta.
CMDB - Excel.
Jos palvelin on fyysinen, virtuaalikoneen kopioimisen sijaan käyttöjärjestelmä asennettiin siihen Cobblerilla - kohdepalvelimen MAC-osoitteet lisätään Cobbler-konfiguraatioon, palvelin vastaanottaa IP-osoitteen DHCP:n kautta ja sitten käyttöjärjestelmä. on lisätty.
Aluksi yritimme jopa tehdä jonkinlaista asetusten hallintaa Cobblerissa. Mutta ajan myötä tämä alkoi tuoda ongelmia konfiguraatioiden siirrettävyydessä sekä muihin tietokeskuksiin että Ansible-koodiin VM:ien valmistelemiseksi.
Tuolloin monet meistä pitivät Ansiblea kätevänä Bashin jatkeena eivätkä säästäneet shelliä ja sediä käyttävillä malleilla. Kaiken kaikkiaan Bashsible. Tämä johti lopulta siihen, että jos pelikirja jostain syystä ei toiminut palvelimella, oli helpompi poistaa palvelin, korjata pelikirja ja ajaa se uudelleen. Komentosarjojen versiointia ei käytännössä ollut eikä kokoonpanojen siirrettävyyttä ollut.
Halusimme esimerkiksi muuttaa joitakin asetuksia kaikilla palvelimilla:
- Muutamme loogisen segmentin/tietokeskuksen olemassa olevien palvelimien määritystä. Joskus ei yhdessä päivässä - saavutettavuusvaatimukset ja suurten lukujen laki eivät salli kaikkien muutosten soveltamista kerralla. Ja jotkut muutokset ovat mahdollisesti tuhoisia ja vaativat jonkin uudelleenkäynnistyksen - palveluista itse käyttöjärjestelmään.
- Korjataan se Ansiblessa
- Korjaamme sen Cobblerissa
- Toista N kertaa jokaiselle loogiselle segmentille/tietokeskukselle
Jotta kaikki muutokset sujuisivat sujuvasti, piti ottaa huomioon monet tekijät ja muutoksia tapahtuu jatkuvasti.
- Refaktorointi mahdollinen koodi, asetustiedostot
- Sisäisten parhaiden käytäntöjen muuttaminen
- Muutokset tapahtumien/onnettomuuksien analysoinnin tulosten perusteella
- Muuttuvat turvallisuusstandardit, sekä sisäiset että ulkoiset. Esimerkiksi PCI DSS päivitetään uusilla vaatimuksilla joka vuosi
Infrastruktuurin kasvu ja matkan alku
Palvelimien/loogisten verkkotunnusten/palvelinkeskusten määrä kasvoi ja niiden myötä konfiguraatioiden virheiden määrä. Jossain vaiheessa päädyimme kolmeen suuntaan, joihin kokoonpanonhallintaa on kehitettävä:
- Automaatio. Inhimillisiä virheitä toistuvissa operaatioissa tulee välttää niin paljon kuin mahdollista.
- Toistettavuus. Infrastruktuurin hallinta on paljon helpompaa, kun se on ennakoitavissa. Palvelimien ja niiden valmisteluun tarkoitettujen työkalujen kokoonpanon tulee olla sama kaikkialla. Tämä on tärkeää myös tuotetiimeille - testauksen jälkeen sovelluksen on taattava päätyvän testiympäristön kaltaiseen tuotantoympäristöön.
- Yksinkertaisuus ja läpinäkyvyys muutosten tekemiseen konfiguraatiohallintaan.
Vielä on lisättävä pari työkalua.
Valitsimme GitLab CE:n koodivarastoksemme, ei vähiten sen sisäänrakennetuille CI/CD-moduuleille.
Salaisuuksien holvi - Hashicorp Vault, sis. mahtavalle API:lle.
Testauskokoonpanot ja mahdolliset roolit – Molecule+Testinfra. Testit menevät paljon nopeammin, jos muodostat yhteyden mahdolliseen mitogeeniin. Samaan aikaan aloimme kirjoittaa omaa CMDB:tä ja orkestraattoria automaattista käyttöönottoa varten (kuvassa Cobblerin yllä), mutta tämä on täysin erilainen tarina, jonka kollegani ja näiden järjestelmien pääkehittäjä kertovat tulevaisuudessa.
Valintamme:
Molekyyli + Testinfra
Ansible + torni + AWX
World of Servers + DITNET (oma kehitys)
Suutari
Gitlab + GitLab-juoksija
Hashicorp holvi
Muuten, sopivista rooleista. Aluksi niitä oli vain yksi, mutta useiden refaktorointien jälkeen niitä oli 17. Suosittelen vahvasti monoliitin jakamista idempotentteihin rooleihin, jotka voidaan sitten käynnistää erikseen, lisäksi voit lisätä tunnisteita. Jaoimme roolit toiminnallisuuden mukaan - verkko, kirjaus, paketit, laitteisto, molekyyli jne. Yleisesti ottaen noudatimme alla olevaa strategiaa. En väitä, että tämä on ainoa totuus, mutta se toimi meille.
- Palvelinten kopioiminen "kultaisesta kuvasta" on pahaa!Suurin haittapuoli on, että et tiedä tarkalleen, missä tilassa kuvat ovat nyt, ja että kaikki muutokset koskevat kaikkia kuvia kaikilla virtualisointitiloilla.
- Käytä oletusmääritystiedostoja mahdollisimman vähän ja sovi muiden osastojen kanssa, että olet vastuussa tärkeimmistä järjestelmätiedostoista, esimerkiksi:
- Jätä /etc/sysctl.conf tyhjäksi, asetusten tulee olla vain tiedostossa /etc/sysctl.d/. Oletusarvosi yhdessä tiedostossa, mukautettu sovellukselle toisessa.
- Käytä ohitustiedostoja muokataksesi järjestelmäyksiköitä.
- Malli kaikki asetukset ja sisällytä ne kokonaan; jos mahdollista, älä sediä tai sen analogeja pelikirjoissa
- Konfiguroinnin hallintajärjestelmän koodin muokkaaminen uudelleen:
- Jaa tehtävät loogisiksi kokonaisuuksiksi ja kirjoita monoliitti uudelleen rooleiksi
- Käytä linteriä! Ansible-lint, yaml-lint jne
- Muuta lähestymistapaasi! Ei hävettävää. On tarpeen kuvata järjestelmän tila
- Kaikkia Ansible-rooleja varten sinun on kirjoitettava molekyylitestejä ja luotava raportteja kerran päivässä.
- Meidän tapauksessamme testien (joita on yli 100) valmistelun jälkeen löytyi noin 70000 XNUMX virhettä. Sen korjaaminen kesti useita kuukausia.
Meidän toteutus
Joten mahdolliset roolit olivat valmiita, mallinnettuja ja linterien tarkastamia. Ja jopa tissejä kasvatetaan kaikkialla. Mutta kysymys luotettavasta koodin toimituksesta eri segmenteille jäi avoimeksi. Päätimme synkronoida skriptien kanssa. Näyttää tältä:
Muutoksen saapumisen jälkeen CI käynnistetään, testipalvelin luodaan, roolit otetaan käyttöön ja molekyyli testaa. Jos kaikki on kunnossa, koodi menee tuotehaaraan. Emme kuitenkaan käytä uutta koodia koneen olemassa oleville palvelimille. Tämä on eräänlainen tulppa, jota tarvitaan järjestelmiemme korkealle käytettävyydelle. Ja kun infrastruktuurista tulee valtava, suurten lukujen laki astuu voimaan - vaikka olisit varma, että muutos on vaaraton, se voi johtaa vakaviin seurauksiin.
Palvelimien luomiseen on myös monia vaihtoehtoja. Päädyimme valitsemaan mukautettuja Python-skriptejä. Ja CI:lle:
- 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}}"Tähän olemme päässeet, järjestelmä elää ja kehittyy edelleen.
- 17 mahdollisia rooleja palvelimen perustamiseen. Jokainen rooli on suunniteltu ratkaisemaan erillinen looginen tehtävä (lokikirjaus, auditointi, käyttäjän valtuutus, valvonta jne.).
- Roolitestaus. Molekyyli + TestInfra.
- Oma kehitystyö: CMDB + Orchestrator.
- Palvelimen luontiaika on ~30 minuuttia, automaattinen ja käytännössä riippumaton tehtäväjonosta.
- Sama infrastruktuurin tila/nimeäminen kaikissa segmenteissä - pelikirjat, tietovarastot, virtualisointielementit.
- Päivittäinen palvelimen tilan tarkistus luomalla raportteja eroista standardin kanssa.
Toivon, että tarinastani on hyötyä niille, jotka ovat matkansa alussa. Mitä automaatiopinoa käytät?
Lähde: will.com