Se lähestyi uutta vuotta. Lapset ympäri maata olivat jo lähettäneet joulupukille kirjeitä tai tehneet itselleen lahjoja, ja heidän päätoteuttajansa, yksi suurimmista kauppiaista, valmistautui myynnin apoteoosiin. Joulukuussa sen konesalin kuormitus kasvaa useita kertoja. Siksi yhtiö päätti modernisoida konesalikeskuksen ja ottaa käyttöön useita kymmeniä uusia palvelimia käyttöikänsä lopussa olevien laitteiden sijaan. Tämä päättää tarinan pyörivien lumihiutaleiden taustalla ja trilleri alkaa.

Laitteet saapuivat paikalle useita kuukausia ennen myynnin huippua. Operaatiopalvelu tietysti tietää, miten ja mitä palvelimille tulee konfiguroida, jotta ne saadaan tuotantoympäristöön. Mutta meidän piti automatisoida tämä ja eliminoida inhimillinen tekijä. Lisäksi palvelimet vaihdettiin ennen yritykselle kriittisten SAP-järjestelmien siirtoa.

Uusien palvelimien käyttöönotto oli tiukasti sidottu määräaikaan. Ja sen siirtäminen merkitsi sekä miljardin lahjan lähettämisen että järjestelmien siirtymisen vaarantamista. Jopa Father Frostista ja Joulupukista koostuva tiimi ei voinut muuttaa päivämäärää - SAP-järjestelmän voi siirtää varastonhallintaan vain kerran vuodessa. 31.-1. välisenä aikana kauppiaan valtavat varastot, yhteensä 20 jalkapallokentän kokoiset, pysäyttävät työnsä 15 tunniksi. Ja tämä on ainoa aika järjestelmän siirtämiselle. Meillä ei ollut tilaa virheille ottaessamme käyttöön palvelimia.

Haluan tehdä selväksi: tarinani kuvastaa työkaluja ja kokoonpanonhallintaprosessia, joita tiimimme käyttää.

Konfiguroinnin hallintakompleksi koostuu useista tasoista. Keskeinen osa on CMS-järjestelmä. Teollisessa käytössä yhden tason puuttuminen johtaisi väistämättä epämiellyttäviin ihmeisiin.

Käyttöjärjestelmän asennuksen hallinta

Ensimmäinen taso on järjestelmä käyttöjärjestelmien asennuksen hallintaan fyysisille ja virtuaalisille palvelimille. Se luo peruskäyttöjärjestelmän kokoonpanot eliminoiden inhimillisen tekijän.

Tämän järjestelmän avulla saimme vakiopalvelininstanssit, joiden käyttöjärjestelmä soveltuu jatkoautomaatioon. "Kaatamisen" aikana he saivat vähimmäisjoukon paikallisia käyttäjiä ja julkisia SSH-avaimia sekä yhdenmukaisen käyttöjärjestelmän kokoonpanon. Pystyimme taatusti hallitsemaan palvelimia CMS:n kautta ja olimme varmoja, ettei käyttöjärjestelmätasolla ollut yllätyksiä "alla".

Asennuksenhallintajärjestelmän "maksimi" tehtävä on määrittää palvelimet automaattisesti BIOS-/laiteohjelmistotasolta käyttöjärjestelmään. Tässä riippuu paljon laitteista ja asennustehtävistä. Heterogeenisiä laitteita varten voit harkita REDFISH API. Jos kaikki laitteistot ovat yhdeltä toimittajalta, on usein kätevämpää käyttää valmiita hallintatyökaluja (esim. HP ILO Amplifier, DELL OpenManage jne.).

Käyttöjärjestelmän asentamiseen fyysisille palvelimille käytimme tunnettua Cobbleria, joka määrittelee joukon käyttöpalvelun kanssa sovittuja asennusprofiileja. Kun infrastruktuuriin lisättiin uusi palvelin, insinööri sidoi palvelimen MAC-osoitteen vaadittuun profiiliin Cobblerissa. Kun palvelin käynnistettiin ensimmäistä kertaa verkon kautta, palvelin sai väliaikaisen osoitteen ja uuden käyttöjärjestelmän. Sitten se siirrettiin kohde-VLAN/IP-osoitteeseen ja työ jatkui siellä. Kyllä, VLANin muuttaminen vie aikaa ja vaatii koordinointia, mutta se tarjoaa lisäsuojaa palvelimen vahingossa tapahtuvaa asennusta vastaan ​​tuotantoympäristöön.

Teimme virtuaalisia palvelimia HashiСorp Packerilla valmistettujen mallien pohjalta. Syy oli sama: estää mahdolliset inhimilliset virheet käyttöjärjestelmää asennettaessa. Mutta toisin kuin fyysiset palvelimet, Packer eliminoi PXE:n, verkkokäynnistyksen ja VLAN-muutosten tarpeen. Tämä on tehnyt virtuaalipalvelimien luomisesta entistä helpompaa ja yksinkertaisempaa.

Riisi. 1. Käyttöjärjestelmien asennuksen hallinta.

Salaisuuksien hallinta

Kaikki kokoonpanonhallintajärjestelmät sisältävät tietoja, jotka tulisi piilottaa tavallisilta käyttäjiltä, ​​mutta joita tarvitaan järjestelmien valmisteluun. Nämä ovat paikallisten käyttäjien ja palvelutilien salasanoja, sertifikaattiavaimia, erilaisia ​​API-tunnuksia jne. Niitä kutsutaan yleensä "salaisuuksiksi".

Jos et määritä alusta alkaen, missä ja miten nämä salaisuudet säilytetään, seuraavat tallennustavat ovat todennäköisiä tietoturvavaatimusten vakavuudesta riippuen:

• suoraan kokoonpanon ohjauskoodissa tai arkiston tiedostoissa;
• erikoistuneissa kokoonpanonhallintatyökaluissa (esimerkiksi Ansible Vault);
• CI/CD-järjestelmissä (Jenkins/TeamCity/GitLab/etc.) tai kokoonpanonhallintajärjestelmissä (Ansible Tower/Ansible AWX);
• salaisuudet voidaan siirtää myös "manuaalisesti". Esimerkiksi ne asetetaan tiettyyn paikkaan, ja sitten kokoonpanonhallintajärjestelmät käyttävät niitä;
• eri yhdistelmiä yllä olevista.

Jokaisella menetelmällä on omat haittapuolensa. Tärkein niistä on salaisuuksiin pääsyä koskevien käytäntöjen puute: on mahdotonta tai vaikeaa määrittää, kuka voi käyttää tiettyjä salaisuuksia. Toinen haittapuoli on pääsyn tarkastuksen ja koko elinkaaren puute. Kuinka nopeasti korvata esimerkiksi julkinen avain, joka on kirjoitettu koodiin ja useisiin siihen liittyviin järjestelmiin?

Käytimme keskitettyä salaista tallennustilaa HashiCorp Vault. Tämä mahdollisti meille:

• pidä salaisuudet turvassa. Ne ovat salattuja, ja vaikka joku pääsisi Vault-tietokantaan (esimerkiksi palauttamalla sen varmuuskopiosta), hän ei pysty lukemaan sinne tallennettuja salaisuuksia.
• järjestää salaisuuksiin pääsyä koskevia käytäntöjä. Vain heille "allokoidut" salaisuudet ovat käyttäjien ja sovellusten saatavilla;
• tarkastaa pääsy salaisuuksiin. Kaikki salaisuuksia sisältävät toiminnot kirjataan Holvin valvontalokiin;
• järjestää täysimittainen "elinkaari" salaisuuksien kanssa työskennellä. Niitä voidaan luoda, peruuttaa, asettaa viimeinen voimassaolopäivä jne.
• helppo integroida muihin järjestelmiin, jotka tarvitsevat pääsyn salaisuuksiin;
• ja käytä myös päästä päähän -salausta, käyttöjärjestelmän ja tietokannan kertakäyttöisiä salasanoja, valtuutettujen keskusten varmenteita jne.

Siirrytään nyt keskitettyyn todennus- ja valtuutusjärjestelmään. Ilmankin sitä voitiin tehdä, mutta käyttäjien hallinta monissa asiaan liittyvissä järjestelmissä on liian ei-triviaalia. Olemme määrittäneet todennuksen ja valtuutuksen LDAP-palvelun kautta. Muuten Holvin täytyisi jatkuvasti myöntää käyttäjien todennustunnuksia ja seurata niitä. Ja käyttäjien poistaminen ja lisääminen muuttuisi kyselyksi "loinko/poistanko tämän käyttäjätilin kaikkialta?"

Lisäämme järjestelmäämme toisen tason: salaisuuksien hallinta ja keskitetty todennus/valtuutus:

Riisi. 2. Salaisuuksien hallinta.

Kokoonpanon hallinta

Pääsimme ytimeen - CMS-järjestelmään. Meidän tapauksessamme tämä on Ansiblen ja Red Hat Ansible AWX:n yhdistelmä.

Ansiblen sijasta voidaan käyttää Chef, Puppet, SaltStack. Valitsimme Ansiblen useiden kriteerien perusteella.

• Ensinnäkin se on monipuolisuus. Valmiiden moduulien sarja ohjausta varten se on vaikuttava. Ja jos sinulla ei ole tarpeeksi, voit etsiä GitHubista ja Galaxysta.
• Toiseksi, agentteja ei tarvitse asentaa ja tukea hallittuihin laitteisiin, todistaa, että ne eivät häiritse kuormaa, ja vahvistaa "kirjanmerkkien" puuttumista.
• Kolmanneksi Ansiblella on alhainen pääsyn este. Pätevä insinööri kirjoittaa toimivan ohjekirjan kirjaimellisesti ensimmäisenä tuotteena työskentelypäivänä.

Mutta pelkkä Ansible tuotantoympäristössä ei riittänyt meille. Muutoin pääsyn rajoittamiseen ja järjestelmänvalvojien toiminnan tarkastamiseen syntyisi monia ongelmia. Kuinka rajoittaa pääsyä? Loppujen lopuksi jokaisen osaston täytyi hallita (lue: käyttää Ansible playbookia) "omaa" palvelinsarjaansa. Kuinka sallia vain tiettyjen työntekijöiden käyttää tiettyjä Ansible-pelikirjoja? Tai kuinka seurata, kuka julkaisi pelikirjan ilman, että hankit paljon paikallista tietoa palvelimista ja laitteista, joissa on Ansible?

Leijonanosan tällaisista ongelmista ratkaisee Red Hat Ansible Towertai hänen avoimen lähdekoodin alkupään projekti Mahdollinen AWX. Siksi suosimme sitä asiakkaalle.

Ja vielä yksi kosketus CMS-järjestelmämme muotokuvaan. Mahdollinen pelikirja tulisi tallentaa koodivaraston hallintajärjestelmiin. Meillä on se GitLab CE.

Joten itse kokoonpanoja hallitsee Ansible/Ansible AWX/GitLab-yhdistelmä (katso kuva 3). Tietenkin AWX/GitLab on integroitu yhteen todennusjärjestelmään, ja Ansible playbook on integroitu HashiCorp Vaultiin. Kokoonpanot tulevat tuotantoympäristöön vain Ansible AWX:n kautta, jossa määritellään kaikki ”pelin säännöt”: kuka voi määrittää mitä, mistä saa CMS:n konfiguraatiohallintakoodin jne.

Riisi. 3. Kokoonpanon hallinta.

Testin hallinta

Kokoonpanomme esitetään koodimuodossa. Siksi meidän on pakko pelata samoilla säännöillä kuin ohjelmistokehittäjät. Meidän piti organisoida kehitys-, jatkuva testaus-, toimitus- ja konfigurointikoodin soveltamisprosessit tuotantopalvelimille.

Jos tätä ei tehdä välittömästi, kokoonpanoon kirjoitettuja rooleja joko ei tueta ja muokata tai niitä ei oteta käyttöön tuotannossa. Lääke tähän kipuun tunnetaan, ja se on osoittautunut tässä projektissa:

• jokainen rooli katetaan yksikkötesteillä;
• testit suoritetaan automaattisesti aina, kun konfiguraatioita hallitsevassa koodissa tapahtuu muutoksia;
• kokoonpanonhallintakoodin muutokset julkaistaan ​​tuotantoympäristössä vasta, kun kaikki testit ja koodin tarkistus on läpäissyt onnistuneesti.

Koodikehityksestä ja konfiguraatioiden hallinnasta on tullut rauhallisempaa ja ennakoitavampaa. Jatkuvan testauksen järjestämiseksi käytimme GitLab CI/CD -työkalupakkia ja otimme Ansible molekyyli.

Aina kun asetusten hallintakoodissa tapahtuu muutos, GitLab CI/CD kutsuu Moleculea:

• se tarkistaa koodin syntaksin,
• nostaa Docker-kontin,
• käyttää muokattua koodia luotuun säilöön,
• tarkistaa roolin idempotenssin varalta ja suorittaa testit tälle koodille (rakeisuus on tässä mahdollisella roolitasolla, katso kuva 4).

Toimitimme konfiguraatiot tuotantoympäristöön Ansible AWX:n avulla. Käyttösuunnittelijat käyttivät kokoonpanomuutoksia ennalta määritettyjen mallien avulla. AWX "pyyteli" itsenäisesti uusimman version koodista GitLabin päähaaralta aina, kun sitä käytettiin. Näin jätimme pois testaamattoman tai vanhentuneen koodin käytön tuotantoympäristössä. Luonnollisesti koodi pääsi päähaaraan vasta testauksen, tarkastelun ja hyväksynnän jälkeen.

Riisi. 4. Roolien automaattinen testaus GitLab CI/CD:ssä.

Myös tuotantojärjestelmien toimintaan liittyy ongelma. Tosielämässä on erittäin vaikeaa tehdä konfiguraatiomuutoksia pelkän CMS-koodin avulla. Hätätilanteita syntyy, kun insinöörin on muutettava konfiguraatiota "tässä ja nyt" odottamatta koodin muokkausta, testausta, hyväksyntää jne.

Tämän seurauksena manuaalisista muutoksista johtuen samantyyppisten laitteiden määrityksissä ilmenee eroja (esimerkiksi sysctl-asetukset on määritetty eri tavalla HA-klusterin solmuissa). Tai laitteen todellinen kokoonpano eroaa CMS-koodissa määritellystä.

Siksi jatkuvan testauksen lisäksi tarkastamme tuotantoympäristöissä konfiguraatioeroja. Valitsimme yksinkertaisimman vaihtoehdon: CMS:n konfigurointikoodin suorittaminen "dry run" -tilassa, eli ilman muutoksia, mutta ilmoittamalla kaikista suunnitellun ja todellisen kokoonpanon välisistä eroista. Totesimme tämän suorittamalla ajoittain kaikki Ansible-pelikirjat "—check"-vaihtoehdolla tuotantopalvelimilla. Kuten aina, Ansible AWX vastaa pelikirjan käynnistämisestä ja pitämisestä ajan tasalla (katso kuva 5):

Riisi. 5. Tarkistaa Ansible AWX:n konfiguraatioeroista.

Tarkastuksen jälkeen AWX lähettää poikkeamaraportin järjestelmänvalvojille. He tutkivat ongelmallista kokoonpanoa ja korjaavat sen sitten mukautettujen pelikirjojen avulla. Näin ylläpidämme konfiguraatiota tuotantoympäristössä ja CMS on aina ajan tasalla ja synkronoitu. Tämä eliminoi epämiellyttävät "ihmeet", kun CMS-koodia käytetään "tuotantopalvelimilla".

Meillä on nyt tärkeä testauskerros, joka koostuu Ansible AWX/GitLab/Molecule (Kuva 6).

Riisi. 6. Testin hallinta.

Vaikea? En kiistä. Mutta tällaisesta kokoonpanonhallinnan kompleksista on tullut kattava vastaus moniin palvelimen konfiguroinnin automatisointiin liittyviin kysymyksiin. Nyt jälleenmyyjän vakiopalvelimilla on aina tiukasti määritelty kokoonpano. CMS, toisin kuin insinööri, ei unohda lisätä tarvittavia asetuksia, luoda käyttäjiä ja suorittaa kymmeniä tai satoja vaadittuja asetuksia.

Palvelimien ja ympäristöjen asetuksissa ei nykyään ole "salaista tietoa". Kaikki tarvittavat ominaisuudet näkyvät ohjekirjassa. Ei enää luovuutta ja epämääräisiä ohjeita: “Asenna se kuten tavallinen Oracle, mutta sinun on määritettävä muutama sysctl-asetus ja lisättävä käyttäjiä vaaditulla UID-tunnuksella. Kysy operaatiossa olevilta miehiltä, ​​he tietävät'.

Kyky havaita konfiguraatioerot ja korjata ne ennakoivasti tarjoaa mielenrauhaa. Ilman kokoonpanonhallintajärjestelmää tämä näyttää yleensä erilaiselta. Ongelmat kertyvät, kunnes ne eräänä päivänä "ammuvat" tuotantoon. Sen jälkeen suoritetaan selvitys, kokoonpanot tarkistetaan ja korjataan. Ja sykli toistuu taas

Ja tietysti nopeutimme palvelimien käyttöönottoa useista päivistä tunteihin.

No, itse uudenvuodenaattona, kun lapset avasivat iloisesti lahjoja ja aikuiset esittivät toiveita kelloäänien soidessa, suunnittelijamme siirsivät SAP-järjestelmän uusille palvelimille. Jopa Joulupukki sanoo, että parhaat ihmeet ovat ne, jotka ovat hyvin valmistautuneita.

PS Tiimimme kohtaa usein sen tosiasian, että asiakkaat haluavat ratkaista konfiguraationhallinnan ongelmat mahdollisimman yksinkertaisesti. Ihannetapauksessa kuin taianomaisesti - yhdellä työkalulla. Mutta elämässä kaikki on monimutkaisempaa (kyllä, hopealuotteja ei enää toimitettu): sinun on luotava koko prosessi asiakkaan tiimille sopivilla työkaluilla.

Kirjoittaja: Sergey Artemov, osaston arkkitehti DevOps-ratkaisut "Jet Infosystems"

Lähde: will.com