Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 1

National Environmental Satellite Data Information Service (NESDIS) on vähentänyt Red Hat Enterprise Linuxin (RHEL) kokoonpanonhallintakustannuksiaan 35 % siirtymällä Puppet Enterprisesta Ansible Toweriin. Tässä "miten teimme sen" -videossa järjestelmäinsinööri Michael Rau selittää tämän siirron tapauksen ja jakaa hyödyllisiä vinkkejä ja oppitunteja siirtymisestä SCM:stä toiseen.

Tästä videosta opit:

  • kuinka perustella johdolle toteutettavuus vaihtaa Puppet Enterprisesta Ansible Toweriin;
  • mitä strategioita käyttää, jotta siirtyminen olisi mahdollisimman sujuvaa;
  • vinkkejä PE-luetteloiden muuntamiseen Ansible Playbookiksi;
  • Suosituksia Ansible Towerin optimaaliseen asennukseen.

Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 1

Hei kaikki, nimeni on Michael Rau, olen vanhempi järjestelmäinsinööri ActioNetissä, joka työskentelee National Oceanic and Atmospheric Administrationin (NOAA) NESDIS-palvelussa. Tänään puhumme merkkijonojen trimmauksesta - omasta kokemuksestani siirtymisestä Puppet Enterprisesta Ansible Toweriin. Tämän esityksen teemana on "katsoa arpiani", jotka jäivät sen jälkeen, kun tein tämän muutoksen aiemmin tänä vuonna. Haluan jakaa sen, mitä olen oppinut tämän prosessin aikana. Joten kun otat jotain tällaista, kokemukseni perusteella, voit tehdä siirtymisen ilman ylimääräistä työtä.

Näet tämän kaltaiset diat jokaisen Ansible Fest -esityksen alussa. Tämä dia esittelee yritykseni automaation historiaa. En ole uusi tässä, koska olen käyttänyt Puppet/Puppet Enterprisea vuodesta 2007 lähtien. Aloitin työskentelyn Ansiblen kanssa vuonna 2016, ja kuten monia muita tämän tuotteen käyttäjiä, minua houkutteli mahdollisuus "temppuihin" käyttämällä komentoriviä ja yksinkertaisia ​​skriptejä (pelikirjoja). Vuoden 2017 lopulla otin johtoon yhteyttä Ansible Toweriin muuttamisen vahvoista syistä. Hetken kuluttua kerron sinulle syistä, jotka saivat minut ottamaan tämän askeleen. Johdon suostumuksen saatuaan suunnitelman toteuttaminen kesti vielä useita kuukausia ja tein siirtymän tämän vuoden tammi-helmikuussa. Joten hylkäsimme Puppetin kokonaan Ansiblen hyväksi, ja se on hieno asia.

Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 1

Minua kiinnostaa eniten Ansiblessa kyky kirjoittaa ja käyttää rooleja ja leikkikirjoja. Roolit ovat erinomaisia ​​erillisten, mutta toisiinsa liittyvien tehtävien luomiseen ja kaikkien näihin tehtäviin liittyvien tietojen kokoamiseen yhteen paikkaan. Pelikirja on YAML-syntaksi, komentosarjatiedosto, joka kuvaa yhden tai useamman isännän toimintoja. Kerron näistä ominaisuuksista käyttäjille, ensisijaisesti ohjelmistokehittäjille. Ansible Tower antaa sinulle mahdollisuuden sanoa: "Ei, sinulla ei ole shell-käyttöoikeutta, mutta annan sinulle mahdollisuuden suorittaa kaikkia Towerin prosesseja ja käynnistää palvelu uudelleen, kun tarvitset sitä." Kerron sinulle työympäristöstä ja käyttämistämme laitteista.

Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 1

Tämä on liittovaltion LAN, 7 fyysistä sivustoa, jotka on yhdistetty pilvi MPLS:n kautta, 140 RHEL-palvelinta, joista 99 % on virtuaalisia (vSphere), SuperMicro-laitteisto, NexentaStore-verkkotallennus, joukko Cisco-, Arista- ja Cumulus-kytkimiä sekä yhtenäinen Fortinet UTM -uhanhallinta. työkaluja jokaisessa sivustossa.

Liittovaltion verkko tarkoittaa, että minun on käytettävä kaikkia lain edellyttämiä tietoturvatoimenpiteitä. Muista, että Puppet Enterprise ei tue suurinta osaa käyttämistämme laitteistoista. Meidän on pakko käyttää budjettilaitteistoa, koska valtion virastoilla on ongelmia tämän kuluerän rahoittamisessa. Siksi ostamme SuperMicro-laitteistoja ja kokoamme laitteistomme yksittäisistä osista, joiden ylläpito on taattu valtion sopimuksilla. Käytämme Linuxia, ja tämä on yksi tärkeimmistä syistä vaihtaa Ansibleen.

Historiamme Puppetin kanssa on seuraava.

Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 1

Vuonna 2007 meillä oli pieni 20-25 solmun verkosto, jossa otimme käyttöön Puppetin. Pohjimmiltaan nämä solmut olivat vain RedHat "laatikoita". Vuonna 2010 aloitimme Puppet Dashboard -verkkoliittymän käytön 45 solmulle. Kun verkko laajeni edelleen, siirryimme PE 2014:een vuonna 3.3, jolloin tehtiin täydellinen siirtyminen luettelon uudelleenkirjoituksella 75 solmulle. Tämä oli tehtävä, koska Puppet tykkää muuttaa pelin sääntöjä, ja tässä tapauksessa he muuttivat kielen kokonaan. Vuotta myöhemmin, kun Puppet Enterprisen version 3 tuki päättyi, meidän oli pakko siirtyä PE 2015.2:een. Meidän piti kirjoittaa uudelleen manifesti uusille palvelimille ja ostaa lisenssi 100 solmun varauksella, vaikka meillä oli tuolloin vain 85 solmua.

Vain 2 vuotta on kulunut, ja meidän piti jälleen tehdä paljon työtä siirtyäksemme uuteen versioon PE 2016.4. Ostimme lisenssin 300 solmulle, joista vain 130. Jouduimme jälleen tekemään suuria muutoksia manifestiin, koska kielen uudella versiolla oli erilainen syntaksi kuin vuoden 2015 version kielellä. Tämän seurauksena SCM:mme siirtyi SVN-versionhallinnasta Bitbucketiin (Git). Tämä oli "suhteemme" Puppetin kanssa.

Joten minun piti selittää johdolle, miksi meidän piti siirtyä toiseen SCM:ään seuraavilla perusteilla. Ensimmäinen on palvelun korkea hinta. Puhuin RedHatin kavereiden kanssa, ja he sanoivat, että 300 solmun verkon käyttö Ansible Towerin kanssa on puolet Puppet Enterprisen kustannuksista. Jos ostat myös Ansible Enginen, hinta on suunnilleen sama, mutta saat paljon enemmän ominaisuuksia kuin PE. Koska olemme valtionyhtiö, joka rahoitetaan liittovaltion budjetista, tämä on melko vahva argumentti.

Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 1

Toinen argumentti on monipuolisuus. Puppet tukee vain laitteita, joissa on Puppet-agentti. Tämä tarkoittaa, että agentti on asennettava kaikkiin kytkimiin, ja sen on oltava uusin versio. Ja jos osa kytkimistäsi tukee yhtä versiota ja toiset toista, sinun on asennettava niihin uusi versio PE-agentista, jotta ne kaikki voivat toimia samassa SCM-järjestelmässä.

Ansible Tower -järjestelmä toimii eri tavalla, koska siinä ei ole agentteja, mutta siinä on moduuleja, jotka tukevat Ciscon kytkimiä ja kaikkia muita kytkimiä. Tämä SCM tukee Qubes OS:ää, Linuxia ja 4.NET UTM:ää. Ansible Tower tukee myös NexentaStore-verkkotallennusohjaimia, jotka perustuvat Illumos-ytimeen, avoimen lähdekoodin Unix-pohjaiseen käyttöjärjestelmään. Tämä on hyvin vähän tukea, mutta Ansible Tower tekee sen joka tapauksessa.

Kolmas argumentti, joka on erittäin tärkeä sekä minulle että hallinnollemme, on helppokäyttöisyys. Vietin 10 vuotta Puppet-moduulien ja manifestikoodin hallitsemiseen, mutta opin Ansiblen viikossa, koska tämän SCM:n kanssa on paljon helpompi työskennellä. Jos suoritat suoritettavia tiedostoja, tietysti, ellet tee sitä tarpeettomasti, älykkäät ja reagoivat käsittelijät toimivat niiden kanssa. YAML-pohjaiset pelikirjat ovat helppoja oppia ja nopeita käyttää. Ne, jotka eivät ole koskaan kuulleet YAML:sta, voivat yksinkertaisesti lukea skriptit ja ymmärtää helposti, kuinka se toimii.

Rehellisesti sanottuna Puppet tekee työstäsi kehittäjänä paljon vaikeampaa, koska se perustuu Puppet Masterin käyttöön. Se on ainoa kone, joka saa kommunikoida Nukke-agenttien kanssa. Jos olet tehnyt muutoksia luetteloon ja haluat testata koodiasi, sinun on kirjoitettava Puppet Masterin koodi uudelleen, toisin sanoen määritettävä Puppet Master /etc/hosts -tiedosto yhdistämään kaikki asiakkaat ja käynnistämään Puppet Server -palvelu. Vasta tämän jälkeen voit testata verkkolaitteiden toimintaa yhdellä isännällä. Tämä on melko tuskallinen toimenpide.
Ansiblessa kaikki on paljon yksinkertaisempaa. Sinun tarvitsee vain kehittää koodi koneelle, joka voi kommunikoida SSH:n kautta testattavan isännän kanssa. Tämän kanssa on paljon helpompi työskennellä.

Seuraava suuri Ansible Towerin etu on kyky hyödyntää olemassa olevaa tukijärjestelmääsi ja ylläpitää olemassa olevaa laitteistokokoonpanoasi. Tämä SCM käyttää kaikkia saatavilla olevia tietoja infrastruktuuristasi ja laitteistostasi, virtuaalikoneistasi, palvelimistasi jne. ilman lisätoimenpiteitä. Se voi puhua RH-satelliittipalvelimillesi, jos sinulla on sellainen, ja se tarjoaa integraatioita, joita et koskaan saa Puppetin kanssa.

Toinen tärkeä asia on yksityiskohtainen valvonta. Tiedät, että Puppet on modulaarinen järjestelmä, se on asiakas-palvelinsovellus, joten sinun on määriteltävä kaikkien koneidesi olemassa olevat aspektit yhdessä pitkässä luettelossa. Tässä tapauksessa järjestelmän jokaisen yksittäisen elementin tila on testattava puolen tunnin välein - tämä on oletusjakso. Näin Puppet toimii.

Torni pelastaa sinut siltä. Voit ajaa erilaisia ​​prosesseja erilaisilla laitteilla ilman rajoituksia; voit tehdä perustyötä, suorittaa muita tärkeitä prosesseja, määrittää suojausjärjestelmän ja työskennellä tietokantojen kanssa. Voit tehdä kaiken, mikä on vaikeaa Puppet Enterprisessa. Joten jos määritit sen yhdelle isännälle, kestää jonkin aikaa, ennen kuin muutokset tulevat voimaan muissa isännissä. Ansiblessa kaikki muutokset tulevat voimaan samaan aikaan.

Katsotaan lopuksi suojausmoduulia. Ansible Tower toteuttaa sen yksinkertaisesti hämmästyttävällä tavalla, erittäin tarkasti ja huolellisesti. Voit myöntää käyttäjille pääsyn tiettyihin palveluihin tai tiettyihin isänteihin. Teen tämän työntekijöideni kanssa, jotka ovat tottuneet työskentelemään Windowsin kanssa, rajoittaen heidän pääsyään Linux-kuoreen. Varmistan, että heillä on pääsy Toweriin, jotta he voivat tehdä vain työn ja suorittaa vain heille tärkeitä palveluita.

Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 1

Katsotaanpa asioita, jotka sinun on tehtävä etukäteen helpottaaksesi siirtymistäsi Ansible Toweriin. Ensinnäkin sinun on valmisteltava varusteesi. Jos jotkin infrastruktuurisi elementit eivät vielä ole tietokannassa, sinun on lisättävä ne sinne. On järjestelmiä, jotka eivät muuta ominaisuuksiaan eivätkä siksi ole Puppet-tietokannassa, mutta jos et lisää niitä sinne ennen Toweriin muuttoa, menetät monia etuja. Tämä voi olla "likainen", alustava tietokanta, mutta sen pitäisi sisältää tiedot kaikista laitteistasi. Siksi sinun tulee kirjoittaa dynaaminen laitteistoskripti, joka työntää automaattisesti kaikki infrastruktuurin muutokset tietokantaan, jolloin Ansible tietää, mitkä isännät pitäisi olla läsnä uudessa järjestelmässä. Sinun ei tarvitse kertoa tälle SCM:lle, mitkä isännät lisäsit ja mitkä eivät enää ole, koska se tietää kaiken tämän automaattisesti. Mitä enemmän tietoa tietokannassa on, sitä hyödyllisempi ja joustavampi Ansible on. Se toimii ikään kuin se vain lukisi laitteiston tilan viivakoodin tietokannasta.

Vietä aikaa Ansiblen komentoriville tutustumiseen. Suorita mukautettuja komentoja testataksesi laitteistoskriptiä, kirjoita ja suorita yksinkertaisia ​​mutta hyödyllisiä pelikirjan skriptejä, käytä Jinja2-malleja tarvittaessa. Yritä kirjoittaa rooli ja komentosarja monimutkaiselle, monivaiheiselle prosessille käyttämällä yleistä, usein tavattua laitteistokokoonpanoa. Leiki näillä asioilla ja testaa, miten se toimii. Näin opit käyttämään Towerissa käytettyjä kirjaston luontityökaluja. Olen jo sanonut, että minulla kesti noin 3 kuukautta valmistautua siirtymään. Uskon, että kokemukseni perusteella pystyt tekemään tämän nopeammin. Älä pidä tätä aikaa hukkaan heitettyä, sillä myöhemmin koet kaikki tehdyn työn edut.

Seuraavaksi sinun on päätettävä, mitä odotat Ansible Towerilta, mitä tämän järjestelmän pitäisi tehdä sinulle.

Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 1

Tarvitseeko järjestelmä ottaa käyttöön paljaalla laitteistolla, paljailla virtuaalikoneilla? Vai haluatko säilyttää olemassa olevien laitteiden alkuperäiset käyttöolosuhteet ja asetukset? Tämä on erittäin tärkeä näkökohta julkisille yrityksille, joten sinun on oltava varma, että voit siirtää ja ottaa Ansiblen käyttöön olemassa olevissa kokoonpanoissasi. Tunnista rutiinihallinnolliset prosessit, jotka haluat automatisoida. Ota selvää, tarvitseeko sinun ottaa käyttöön tiettyjä sovelluksia ja palveluita uudessa järjestelmässä. Tee luettelo siitä, mitä haluat tehdä, ja priorisoi se.

Aloita sitten skriptikoodin ja roolien kirjoittaminen, jotka mahdollistavat suorittamasi tehtävät. Yhdistä ne Projectsiksi, loogiseksi kokoelmaksi relevantteja pelikirjoja. Jokainen projekti kuuluu erilliseen Git-tietovarastoon tai eri arkistoon riippuen siitä, mitä koodinhallintaa käytät. Voit hallita pelikirjan skriptejä ja pelikirjahakemistoja asettamalla ne manuaalisesti Tower-palvelimen Project Base Path -polkuun tai sijoittamalla pelikirjan mihin tahansa Towerin tukemaan lähdekoodinhallintajärjestelmään (SCM), mukaan lukien Git, Subversion, Mercurial ja Red Hat. Näkemyksiä. Yhteen projektiin voit sijoittaa niin monta skriptiä kuin haluat. Loin esimerkiksi yhden perusprojektin, johon laitoin skriptin RedHat-ydinelementeille, komentosarjan Linux-ytimelle ja komentosarjat muille peruslinjoille. Siten yhdessä projektissa oli useita rooleja ja skenaarioita, joita hallittiin yhdestä Git-varastosta.

Kaikkien näiden asioiden suorittaminen komentorivin kautta on hyvä tapa testata niiden toimivuutta. Tämä valmistaa sinut Towerin asennusta varten.

Puhutaanpa hieman Puppet-luettelon transkoodaamisesta, koska vietin tähän paljon aikaa, kunnes tajusin, mitä todella piti tehdä.

Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 1

Kuten sanoin aiemmin, Puppet tallentaa kaikki asetukset ja laitteistovaihtoehdot yhteen pitkään luetteloon, ja tämä luettelo tallentaa kaiken, mitä tämän SCM:n pitäisi tehdä. Siirtyessäsi sinun ei tarvitse koota kaikkia tehtäviäsi yhteen luetteloon, vaan mieti uuden järjestelmän rakennetta: roolit, komentosarjat, tagit, ryhmät ja mitä sinne pitäisi sisällyttää. Jotkut autonomisista verkkoelementeistä tulisi ryhmitellä ryhmiin, joille voidaan luoda komentosarjat. Monimutkaisempia infrastruktuurielementtejä, joihin liittyy suuri määrä resursseja, mukaan lukien itsenäiset luokat, voidaan yhdistää rooleiksi. Ennen siirtymistä sinun on päätettävä tästä. Jos luot suuria rooleja tai skenaarioita, jotka eivät mahdu yhdelle näytölle, sinun tulee käyttää tunnisteita, jotta pystyt kaappaamaan infrastruktuurin tiettyjä osia.

18:00

Lankojen leikkaaminen: siirtyminen Puppet Enterprisesta Ansible Toweriin. Osa 2

Muutamia mainoksia 🙂

Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, pilvi VPS kehittäjille alkaen 4.99 dollaria, ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: Koko totuus VPS (KVM) E5-2697 v3 (6 ydintä) 10 Gt DDR4 480 Gt SSD 1 Gbps alkaen 19 dollarista tai kuinka jakaa palvelin? (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).

Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä 2 x Intel TetraDeca-Core Xeon 2 x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV alkaen 199 dollaria Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea Kuinka rakentaa infrastruktuuriyritys. luokkaa Dell R730xd E5-2650 v4 -palvelimilla 9000 euron arvosta penniä vastaan?

Lähde: will.com

Lisää kommentti