Rahvuslik keskkonnaandmete satelliitide teabe süsteem (NESDIS) vähendas Red Hat Enterprise Linuxi (RHEL) konfiguratsioonihalduse kulusid 35%, liikudes Puppet Enterprise'ilt Ansible Towerile. Selles videos kategoorias „kuidas me seda tegime“ selgitab süsteemiinsener Michael Rau, miks see migratsioon tehti, jagab kasulikke nõuandeid ja kogemusi, mis saadud üleminekul ühest SCM-ist teise.
Selles videos õpite:
- kuidas põhjendada juhtkonnale ülemineku vajadust Puppet Enterprise'ilt Ansible Towerile;
- milliseid strateegiaid kasutada sujuvaks üleminekuks;
- nõuandeid PE manifestide translatsiooniks Ansible Playbookiks;
- soovitusi Ansible Toweri optimaalseks seadistamiseks.
Tere kõigile, mina olen Michael Rau, ActioNet'i vanem süsteemiinsener, kes töötab Riikliku Ookean ja Atmosfääri Administratsiooni (NOAA) NESDIS'i teenistuseks. Täna räägime ridade kärpimisest – minu isiklik kogemus üleminekust Puppet Enterprise'ilt Ansible Towerile. Selle esitluse eesmärgiks on „vaadata mu arme”, mis on jäänud pärast minu üleminekut aasta alguses. Soovin jagada, mida olen selle protsessi käigus õppinud. Nii et kui võtate sarnase ette, saate kasutada minu kogemusi, et üleminek sujuks paremini.
Te näete slaide, mis on sarnased sellele, iga esitluse alguses Ansible Festil. Sellel slaidil on välja toodud minu ettevõtte automatiseerimise lugu. Ma ei ole selles alles algaja, olen kasutanud Puppet/Puppet Enterprise'i alates 2007. aastast. Alustasin Ansible'i kasutamist 2016. aastal ja mind, nagu ka paljusid teisi selle toote kasutajaid, tõmbas „trikkide” tegemise võimalus käsurea ja lihtsate skriptide (playbookide) kaudu. 2017. aasta lõpus pöördusin oma juhtkonna poole tõsiste põhjustega, miks üle minna Ansible Towerile. Mõne hetke pärast räägin, mis mind selle sammu astuma sundis. Pärast juhtkonna heakskiitu kulus veel paar kuud, et plaan ellu viia, ja ma tegin ülemineku jaanuaris-veebruaris sel aastal. Nii et loobusime täielikult Puppetist Ansible'i kasuks, ja see on suurepärane saavutus.
Ansible's ability to write and use roles and playbooks is what I find most appealing. Roles are perfect for creating various but interrelated tasks and placing all relevant data for these tasks in one location. A playbook is a YAML syntax file that describes actions for one or several hosts. I primarily share these capabilities with software developers. Ansible Tower allows me to say, 'No, you do not have shell access, but I provide you the ability to run all Tower processes and restart the service whenever you need.' I will explain our working environment and the equipment we use.
This is a federal LAN with 7 physical sites connected via a cloud MPLS, 140 RHEL servers, 99% of which are virtual (vSphere), SuperMicro hardware, NexentaStore network storage, a set of Cisco, Arista, and Cumulus switches, and Fortinet UTM unified threat management tools at each site.
The federal network means that I must use all information protection measures required by legislation. You should bear in mind that Puppet Enterprise does not support most of the equipment we use. We are forced to use budget hardware as government bodies face funding issues for this expense. Therefore, we purchase SuperMicro class hardware and assemble our equipment from individual parts, the maintenance of which is guaranteed by government contracts. We use Linux, and this is one of the important reasons for switching to Ansible.
Our history with Puppet is as follows.
2007. aastal oli meil väike võrk, kus oli 20-25 sõlme, kuhu paigaldasime Puppet'i. Enamasti olid need sõlmed lihtsalt RedHat'i "kastid". 2010. aastal hakkasime kasutama Puppet Dashboard'i veebiliidest 45 sõlme jaoks. Kuna võrk jätkas laienemist, 2014. aastal Üksikasjalik üleminek PE 3.3-le, täieliku üleminekuga 75 sõlme mansi arenguga. See tuli teha, kuna Puppet meeldib mängureegleid muuta ning sel juhul muutsid nad täielikult keelt. Aasta hiljem, kui 3. versiooni Puppet Enterprise'i tugi lõpetati, pidime migreerima PE 2015.2-le. Jõudis taas ümberehitus uusimate serverite jaoks ja ostsime litsentsi 100 sõlme jaoks, kuigi sel hetkel oli meil vaid 85 sõlme.
Kaks aastat hiljem pidime taas läbi viima suurt tööd üleminekuks uuele versioonile PE 2016.4. Ostsime litsentsi 300 sõlme jaoks, kuid meil oli vaid 130. Me pidime jälle tõsiselt muutma mansi, kuna uuel keele versioonil oli süntaks, mis erineb 2015. aasta versiooni keelest. Lõpuks kolis meie SCM versioonihaldussüsteemilt SVN Bitbucket'i (Git) peale. Sellised olid meie "suhted" Puppet'iga.
Nii et pidin juhtkonnale selgitama, miks peame minema üle teisele SCM-le, kasutades järgmisi argumente. Esimene - teenuse kõrge hind. Kõneldes RedHat'i poisiga ütlesid nad, et 300 sõlme haldamise hind Ansible Toweriga on ainult Pool Puppet Enterprise'i õigusi. Kui ostate veel Ansible Engine'i, on hind ligikaudu sama, kuid saate palju rohkem funktsioone kui PE. Kuna oleme riigiettevõte, mille rahastamine toimub föderaalse eelarve kaudu, on see üsna kaalukas argument.
Teine argument - universaalsus. Puppet toetab ainult neid seadmeid, kus on Puppet'i agent. See tähendab, et kõikide lülitite jaoks peab olema agent paigaldatud, ja see peab olema viimase versiooniga. Kui osa teie lülititest toetab ühte versiooni, kuid osa teist, peate nendel uut PE agenti versiooni paigaldama, et kõik need saaksid ühes SCM süsteemis töötada.
Ansible Toweri süsteem töötab erinevalt, kuna tal ei ole agente, vaid on moodulid, mis toetavad Cisco lülitid ja kõiki teisi lüliteid. See SCM toetab Qubes OS-i, Linuxit ja 4.NET UTM-i. Ansible Tower toetab ka NexentaStore'i, mis põhineb Illumose tuumadel – Unix-põhine avatud lähtekoodiga operatsioonisüsteem. Kuigi see tugi on väga väike, pakub Ansible Tower seda siiski.
Kolmas argument, mis on mulle ja meie haldusele väga oluline, on lihtsus. Olen 10 aastat õppinud Puppet'i mooduleid ja manifestide koodi, kuid Ansible'i õppisin nädalaga, kuna see SCM on palju lihtsam kasutada. Kui käitate täidetavaid faile, siis kui te ei tee seda põhjendamatult, töötavad nende kallal mõistlikud ja vastutulelikud töötlejad. YAML-põhised playbook'id on kergesti õpitavad ja kiiresti kasutatavad. Need, kes ei ole kunagi varem YAML-i kuulnud, saavad lihtsalt skripte lugeda ja kergesti mõista, kuidas see töötab.
Ausalt öeldes, Puppet muudab teie töö arendajana palju keerulisemaks, kuna see põhineb Puppet Master'i kasutamisel. See on ainus masin, millel on õigus suhelda Puppet agentidega. Kui olete teinud mingeid muudatusi manifestis ja soovite oma koodi testida, peate koodi Puppet Master'ile ümber kirjutama, seadma Puppet Master'i faili /etc/hosts, et ühendust saada kõikide klientidega, ja käivitama Puppet Server'i teenuse. Alles pärast seda saate testida võrgu seadmeid ühel hostil. See on üsna valutav protseduur.
Ansible'is on kõik palju lihtsam. Kõik, mida peate tegema, on arendada kood masinale, millel on võimalik testitava hostiga läbi SSH protokolli suhelda. Sellega on palju lihtsam töötada.
Järgmine suur pluss Ansible Tower'is on võimalus rakendada juba olemasolevat tugisüsteemi ja säilitada olemasolev riistvara konfiguratsioon. See SCM kasutab kõik olemasolevat teavet teie infrastruktuuri ja seadmete, virtuaalmasinate, serverite jne kohta ilma igasuguste täiendavate toiminguteta. See saab suhelda teie RH Satellite serveritega, kui need on olemas, ja pakub teile sellist integratsiooni, mida te kunagi ei saaks, töötades Puppetiga.
Veel tähtsam on detailsed kontrollid. Te teate, et Puppet on modulaarne süsteem, klient-serveri rakendus, seega peate määratlema kõigi teie masinate töös eksisteerivad aspektid ühes pikas manifestis. Samuti tuleb testida iga süsteemi elemendi seisundit iga poole tunni tagant – see on vaikimisi ajavahemik. Just nii töötab Puppet.
Tower vabastab teid sellest. Saate piiramatult teostada erinevaid protsesse erinevates seadmetes, teha põhitegevust, käivitada muid olulisi protsesse, seadistada turvasüsteemi, töötada andmebaasidega. Kõik see, millega Puppet Enterprise'is on seotud teatud raskused. Nii et kui teete seadistuse ühel hostil, peab aega minema, enne kui muudatused jõustuvad teistel hostidel. Ansible'is jõustuvad kõik muudatused samaaegselt.
Lõpuks vaatame turvamoodulit. Ansible Toweris on see ellu viidud lihtsalt hämmastavalt, suure täpsuse ja hoolikusega. Saate anda kasutajatele õiguse pääseda teatud teenustele või teatud hostidele. Maakohas piirduvad mu töötajad, kes on harjunud Windowsiga, Linuxi shell'i juurdepääsuga. Ma hellitan neile juurdepääsu Towerisse, et nad saaksid teha ainult neid töid ja käivitada ainult neid teenuseid, mis kuuluvad nende pädevusse.
Vaatame, mida on vaja ette valmistada, et üleminek Ansible Towerile sujuvam oleks. Esiteks peate valmistama ette oma seadmed. Kui mõningad teie infrastruktuuri elemendid ei ole veel andmebaasis, tuleb need sinna lisada. On süsteeme, mille omadused ei muutu ja seega ei ole need Puppet'i andmebaasis, kuid kui te ei lisa neid sinna enne Towerile üleminekut, kaotate mitmed eelised. See võib olla "määrdunud" eeldatav andmebaas, kuid see peab sisaldama teavet kogu teie olemasoleva varustuse kohta. Seetõttu peaksite kirjutama dünaamilise seadme skripti, mis automaatselt kannab infrastruktuuri muudatused andmebaasi, et Ansible saaks teada, millised hostid peavad uues süsteemis olema. Te ei pea sellele SCM-ile teatama, milliseid hoste olete lisanud ja milliseid enam ei eksisteeri, kuna seda saab automaatselt teada. Mida rohkem andmeid andmebaasis on, seda kasulikum ja paindlikum on Ansible. Ta töötab nagu seade, mis lihtsalt loeb andmebaasist seadmete oleku triipkoodi.
Pühendage veidi aega Ansible'i käsurea tööga tutvumisele. Käivitage mõni spetsiaalne käsk, et kontrollida seadme skripti tööd, kirjutage ja käivitage mõned lihtsad, kuid kasulikud playbook'i stsenaariumid, kasutage Jinja2 malli seal, kus see on asjakohane. Proovige kirjutada roll ja stsenaarium keerukaks mitmeastmeliseks protsessiks, kasutades tavalist, sageli esinevat seadmete konfiguratsiooni. Katsetage nendega, testige, kuidas see töötab. Nii õpite tööriistu, mida kasutatakse Toweri raamatukogude loomisel. Olen juba öelnud, et minu ettevalmistus üleminekuks kestis umbes 3 kuud. Arvan, et minu kogemusele toetudes suudate seda kiiremini teha. Ärge pidage seda aega raiskamiseks, sest hiljem tunnete kõiki tehtud töö eeliseid.
Seejärel tuleb otsustada, mida te Ansible Towerilt ootate, mida see süsteem peaks teie jaoks tegema.
Kas vajate süsteemi juurutamist tühjale riistvarale või tühjadesse virtuaalmasinatesse? Või soovite hoida olemasolevaid töötingimusi ja seadistusi? See on väga oluline aspekt riigiasutuste töö jaoks, seega peate olema kindel, et suudate migratsiooni teostada ja Ansible'i olemasolevale konfiguratsioonile rakendada. Määrake rutiinsed administratiivsed protsessid, mida soovite automatiseerida. Selgitage välja, kas peate juurutama uut süsteemi spetsiifilisi rakendusi ja teenuseid. Koostage nimekiri selle kohta, mida soovite teha, ja seada prioriteedid.
Seejärel minge edasi koodiskripti ja rollide kirjutamisega, mis tagavad teie plaanitud ülesannete täitmise. Koguge need Projects'isse, loogilisse kogumisse vastavaid playbook'e. Iga Project kuulub eraldi Git-repositooriumisse või mõnda muusse repositoriumisse sõltuvalt sellest, millist koodihaldurit kasutate. Saate hallata playbook'e ja playbook'i katalooge, paigutades need käsitsi Serveri Tower'i Project Base Path'i või panedes playbook'i mõnda Tower'i toetatud lähtekoodihaldussüsteemi (SCM), sealhulgas Git, Subversion, Mercurial ja Red Hat Insights. Ühes Project'is võite paigutada nii palju skripte, kui soovite. Näiteks lõin ühe põhialuste Project'i, kuhu paigutasin skripti RedHat'i põhielementide jaoks, skripti Linuxi baasi jaoks ja skripte teiste põhinäitaja jaoks. Nii esines ühes projektis mitmesuguseid rolle ja skripte, mida haldati ühest Git-repositooriumist.
Käivitage kõik need asjad käsurealt, see on hea viis nende toimimise kontrollimiseks. Nii valmistute Toweri installimiseks.
Räägime veidi Puppet'i manifisti transkodeerimisest, sest kulutasin sellele palju aega, enne kui taipasin, mida tõeliselt teha tuleb.
Nagu ma juba ütlesin, hoiab Puppet kõik seadistused ja seadme parameetrid ühes pikemas manifestis, kus on kajastatud kõik, mida see SCM tegema peab. Üleminekul ei pea te kõiki oma ülesandeid ühte nimekirja suruma; mõelge pigem uue süsteemi struktuurile: rollidele, stsenaariumitele, siltidele, rühmadele ja sellele, mida sinna peaks kuuluma. Mõned iseseisvad võrguelemendid tuleks rühmitada gruppidesse, mille jaoks saab luua stsenaariume. Täiendavad infrastruktuuri elemendid, mis kasutavad suurt hulka ressursse, sealhulgas iseseisvad klassid, saab koondada rollidesse. Enne migreerimist peate seda välja selgitama. Kui loote mahukaid rolle või stsenaariume, mis ei mahdu ühele ekraanile, peaksite kasutama silte, et saaksite hõlpsasti haarata erinevaid infrastruktuuri osi.
18:00
Veidi reklaami 🙂
Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. , ainulaadne entry-level serverite analoog, mille oleme teie jaoks välja mõelnud: (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).
Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest
Allikas: habr.com
