National Environmental Satellite Data Information Service (NESDIS) har redusert sine konfigurasjonsadministrasjonskostnader for Red Hat Enterprise Linux (RHEL) med 35 % ved å migrere fra Puppet Enterprise til Ansible Tower. I denne «hvordan vi gjorde det»-videoen forklarer systemingeniør Michael Rau saken for denne migreringen, og deler nyttige tips og erfaringer fra å flytte fra en SCM til en annen.
Fra denne videoen lærer du:
- hvordan rettferdiggjøre for ledelsen muligheten for å bytte fra Puppet Enterprise til Ansible Tower;
- hvilke strategier du skal bruke for å gjøre overgangen så smidig som mulig;
- tips for omkoding av PE-manifester til Ansible Playbook;
- Anbefalinger for optimal installasjon av Ansible Tower.
Hei alle sammen, mitt navn er Michael Rau, jeg er senior systemingeniør hos ActioNet, som jobber for National Oceanic and Atmospheric Administration (NOAA) NESDIS-tjenesten. I dag skal vi snakke om strengtrimming - min egen erfaring med å migrere fra Puppet Enterprise til Ansible Tower. Temaet for denne presentasjonen er å "ta en titt på arrene mine" etter at jeg gjorde denne overgangen tidligere på året. Jeg vil dele det jeg har lært gjennom denne prosessen. Så når du tar på deg noe slikt, ved å bruke min erfaring, kan du gjøre overgangen uten ekstra arbeid.
Du ser lysbilder som ligner på dette i begynnelsen av hver presentasjon på Ansible Fest. Dette lysbildet skisserer historien til selskapets automatisering. Jeg er ikke ny på dette fordi jeg har brukt Puppet/Puppet Enterprise siden 2007. Jeg begynte å jobbe med Ansible i 2016, og som mange andre brukere av dette produktet ble jeg tiltrukket av muligheten for "triks" ved å bruke kommandolinjen og enkle skript (playbooks). På slutten av 2017 henvendte jeg meg til ledelsen min om de sterke grunnene til å flytte til Ansible Tower. Om et øyeblikk vil jeg fortelle deg om årsakene som fikk meg til å ta dette skrittet. Etter å ha mottatt ledelsens samtykke tok det flere måneder å fullføre planen, og jeg gjorde overgangen i januar-februar i år. Så vi forlot Puppet fullstendig til fordel for Ansible, og det er en flott ting.
Det som tiltaler meg mest med Ansible er evnen til å skrive og bruke roller og spillebøker. Roller er flotte for å lage distinkte, men relaterte oppgaver og plassere all data relatert til disse oppgavene på ett sted. En playbook er en YAML-syntaks, skriptfil som beskriver handlinger for en eller flere verter. Jeg snakker om disse funksjonene til brukere, først og fremst programvareutviklere. Ansible Tower gir deg muligheten til å si "nei, du har ikke shell-tilgang, men jeg gir deg muligheten til å kjøre alle Tower-prosesser og starte tjenesten på nytt når du trenger det." Jeg vil fortelle om arbeidsmiljøet og utstyret vi bruker.
Dette er et føderalt LAN, 7 fysiske nettsteder koblet via sky MPLS, 140 RHEL-servere, hvorav 99 % er virtuelle (vSphere), SuperMicro-maskinvare, NexentaStore nettverkslagring, et sett med Cisco, Arista og Cumulus-svitsjer og Fortinet UTM enhetlig trusselhåndtering verktøy på hvert nettsted.
Det føderale nettverket betyr at jeg må bruke alle informasjonssikkerhetstiltakene som følger av loven. Du bør huske på at Puppet Enterprise ikke støtter det meste av maskinvaren vi bruker. Vi er tvunget til å bruke budsjettmaskinvare fordi offentlige etater har problemer med å finansiere denne utgiftsposten. Det er derfor vi kjøper SuperMicro-maskinvare og setter sammen utstyret vårt fra individuelle deler, hvis vedlikehold er garantert av offentlige kontrakter. Vi bruker Linux og dette er en av de viktige grunnene til å bytte til Ansible.
Vår historie med Puppet er som følger.
I 2007 hadde vi et lite nettverk med 20-25 noder, der vi distribuerte Puppet. I utgangspunktet var disse nodene bare RedHat "bokser". I 2010 begynte vi å bruke Puppet Dashboard-nettgrensesnittet for 45 noder. Ettersom nettverket fortsatte å utvide, flyttet vi til PE 2014 i 3.3, og gjorde en fullstendig overgang med en manifest omskriving for 75 noder. Dette måtte gjøres fordi Puppet liker å endre spillereglene, og i dette tilfellet endret de språket fullstendig. Et år senere, da støtten for versjon 3 av Puppet Enterprise ble avsluttet, ble vi tvunget til å migrere til PE 2015.2. Vi måtte skrive om manifestet på nytt for de nye serverne og kjøpe en lisens med en reserve på 100 noder, selv om vi på den tiden bare hadde 85 noder.
Bare 2 år har gått, og vi måtte igjen gjøre mye arbeid for å migrere til den nye versjonen PE 2016.4. Vi kjøpte en lisens for 300 noder, med bare 130. Vi måtte igjen gjøre store endringer i manifestet fordi den nye versjonen av språket hadde en annen syntaks enn språket i 2015-versjonen. Som et resultat byttet vår SCM fra SVN-versjonskontroll til Bitbucket (Git). Dette var vårt "forhold" til Puppet.
Så jeg måtte forklare ledelsen hvorfor vi måtte flytte til en annen SCM ved å bruke følgende argumenter. Den første er den høye prisen på tjenesten. Jeg snakket med gutta på RedHat og de sa at kostnadene for å drive et 300 nodenettverk med Ansible Tower er halvparten av kostnadene for Puppet Enterprise. Hvis du også kjøper Ansible Engine, vil kostnaden være omtrent den samme, men du vil få mange flere funksjoner enn PE. Siden vi er et statseid selskap finansiert over det føderale budsjettet, er dette et ganske kraftig argument.
Det andre argumentet er allsidighet. Puppet støtter bare maskinvare som har en Puppet-agent. Det betyr at en agent må være installert på alle brytere, og det må være siste versjon. Og hvis noen av bryterne dine støtter én versjon, og noen støtter en annen, må du installere en ny versjon av PE-agenten på dem slik at de alle kan fungere i samme SCM-system.
Ansible Tower-systemet fungerer annerledes fordi det ikke har noen agenter, men det har moduler som støtter Cisco-svitsjer og alle andre svitsjer. Denne SCM støtter Qubes OS, Linux og 4.NET UTM. Ansible Tower støtter også NexentaStore nettverkslagringskontrollere basert på Illumos-kjernen, et åpen kildekode Unix-basert operativsystem. Dette er veldig lite støtte, men Ansible Tower gjør det likevel.
Det tredje argumentet, som er veldig viktig både for meg og for vår administrasjon, er brukervennlighet. Jeg brukte 10 år på å mestre Puppet-moduler og manifestkode, men jeg lærte Ansible i løpet av en uke fordi denne SCM er mye lettere å jobbe med. Hvis du kjører kjørbare filer, selvfølgelig, med mindre du gjør det unødvendig, fungerer intelligente og responsive behandlere med dem. YAML-baserte lekebøker er enkle å lære og raske å bruke. De som aldri har hørt om YAML før kan ganske enkelt lese skriptene og enkelt forstå hvordan det fungerer.
For å være ærlig, gjør Puppet jobben din som utvikler mye vanskeligere fordi den er basert på bruk av Puppet Master. Det er den eneste maskinen som har lov til å kommunisere med Puppet-agenter. Hvis du har gjort noen endringer i manifestet og ønsker å teste koden din, må du skrive om koden for Puppet Master, det vil si konfigurere Puppet Master /etc/hosts-filen til å koble til alle klienter og starte Puppet Server-tjenesten. Først etter dette vil du kunne teste driften av nettverksutstyr på én vert. Dette er en ganske smertefull prosedyre.
Alt er mye enklere i Ansible. Alt du trenger å gjøre er å utvikle kode for en maskin som kan kommunisere via SSH med verten som testes. Dette er mye lettere å jobbe med.
Den neste store fordelen med Ansible Tower er muligheten til å utnytte ditt eksisterende støttesystem og opprettholde din eksisterende maskinvarekonfigurasjon. Denne SCM bruker all tilgjengelig informasjon om din infrastruktur og maskinvare, virtuelle maskiner, servere osv. uten noen ekstra trinn. Den kan snakke med RH Satellite-serverne dine, hvis du har en, og gir deg integrasjoner du aldri får med Puppet.
En annen viktig ting er detaljkontroll. Du vet at Puppet er et modulært system, det er en klient-server-applikasjon, så du må definere de eksisterende aspektene av alle maskinene dine i ett langt manifest. I dette tilfellet må tilstanden til hvert enkelt element i systemet testes hver halvtime - dette er standardperioden. Dette er hvordan Puppet fungerer.
Tower redder deg fra det. Du kan kjøre en rekke prosesser på en rekke utstyr uten begrensninger; du kan gjøre grunnleggende arbeid, kjøre andre viktige prosesser, sette opp et sikkerhetssystem og jobbe med databaser. Du kan gjøre alt som er vanskelig i Puppet Enterprise. Så hvis du konfigurerte det på én vert, vil det ta tid før endringene trer i kraft på de gjenværende vertene. I Ansible trer alle endringer i kraft samtidig.
Til slutt, la oss se på sikkerhetsmodulen. Ansible Tower implementerer det ganske enkelt utrolig, med stor presisjon og forsiktighet. Du kan gi brukere tilgang til bestemte tjenester eller til bestemte verter. Jeg gjør dette med mine ansatte som er vant til å jobbe med Windows, og begrenser deres tilgang til Linux-skallet. Jeg sørger for at de har tilgang til Tower slik at de kun kan gjøre jobben og kun drive de tjenestene som er relevante for dem.
La oss se på tingene du må gjøre på forhånd for å gjøre overgangen til Ansible Tower enklere. Først av alt må du forberede utstyret ditt. Hvis noen elementer av infrastrukturen din ikke allerede er i databasen, må du legge dem til der. Det finnes systemer som ikke endrer egenskapene og derfor ikke er i Puppet-databasen, men hvis du ikke legger dem til der før du flytter til Tower, vil du miste en rekke fordeler. Dette kan være en "skitten", foreløpig database, men den bør inneholde informasjon om alt utstyret du har. Derfor bør du skrive et dynamisk maskinvareskript som automatisk vil presse alle infrastrukturendringer inn i databasen, så vil Ansible vite hvilke verter som skal være tilstede på det nye systemet. Du trenger ikke å fortelle denne SCM hvilke verter du har lagt til og hvilke verter som ikke lenger eksisterer, fordi den vil vite alt dette automatisk. Jo mer data det er i databasen, jo mer nyttig og fleksibel vil Ansible være. Det fungerer som om det bare leser strekkoden for maskinvarestatus fra en database.
Bruk litt tid på å bli kjent med kommandolinjen i Ansible. Kjør noen egendefinerte kommandoer for å teste maskinvareskriptet, skriv og kjør noen enkle, men nyttige playbook-skript, bruk Jinja2-maler der det passer. Prøv å skrive en rolle og et skript for en kompleks prosess med flere trinn ved å bruke en vanlig maskinvarekonfigurasjon som ofte forekommer. Lek med disse tingene, test hvordan det fungerer. På denne måten lærer du hvordan du bruker bibliotekopprettingsverktøyene som brukes i Tower. Jeg har allerede sagt at det tok meg ca 3 måneder å forberede meg på overgangen. Jeg tror at basert på min erfaring, vil du kunne gjøre dette raskere. Ikke betrakt denne tiden som bortkastet, for senere vil du oppleve alle fordelene med arbeidet som er utført.
Deretter må du bestemme deg for hva du forventer av Ansible Tower, akkurat hva dette systemet skal gjøre for deg.
Trenger du å distribuere systemet på bar maskinvare, på bare virtuelle maskiner? Eller ønsker du å opprettholde de opprinnelige driftsforholdene og innstillingene til eksisterende utstyr? Dette er et veldig viktig aspekt for offentlige selskaper, så du må være sikker på at du vil kunne migrere og distribuere Ansible på din eksisterende konfigurasjon. Identifiser rutinemessige administrative prosesser som du ønsker å automatisere. Finn ut om du trenger å distribuere spesifikke applikasjoner og tjenester på det nye systemet. Lag en liste over hva du vil gjøre og prioriter det.
Begynn deretter å skrive skriptkode og roller som vil aktivere oppgavene du planlegger å fullføre. Kombiner dem til Projects, en logisk samling av relevante lekebøker. Hvert prosjekt vil tilhøre et separat Git-depot eller et annet depot avhengig av hvilken kodebehandler du bruker. Du kan administrere playbook-skript og playbook-kataloger ved å manuelt plassere dem i Project Base Path på Tower-serveren, eller ved å plassere playbook i et hvilket som helst kildekodeadministrasjonssystem (SCM) som støttes av Tower, inkludert Git, Subversion, Mercurial og Red Hat Innsikt. Innenfor ett prosjekt kan du plassere så mange skript du vil. For eksempel opprettet jeg et grunnleggende prosjekt der jeg plasserte et skript for RedHat-kjerneelementene, et skript for Linux-kjernen og skript for resten av grunnlinjene. I ett prosjekt var det således en rekke roller og scenarier som ble administrert fra ett Git-depot.
Å kjøre alle disse tingene gjennom kommandolinjen er en god måte å teste funksjonaliteten deres på. Dette vil forberede deg på tårninstallasjonen.
La oss snakke litt om transkoding av Puppet-manifestet, fordi jeg brukte mye tid på dette til jeg fant ut hva som faktisk måtte gjøres.
Som jeg sa før, lagrer Puppet alle innstillingene og maskinvarealternativene i ett langt manifest, og dette manifestet lagrer alt som denne SCM skal gjøre. Når du foretar overgangen, trenger du ikke å stappe alle oppgavene dine i én liste, men tenk i stedet på strukturen til det nye systemet: roller, skript, tagger, grupper og hva som skal gå der. Noen av de autonome nettverkselementene bør grupperes i grupper som skript kan opprettes for. Mer komplekse infrastrukturelementer som involverer et stort antall ressurser, inkludert selvstendige klasser, kan kombineres til roller. Før du migrerer, må du bestemme deg for dette. Hvis du lager store roller eller scenarier som ikke passer på én skjerm, bør du bruke tagger for å kunne fange opp spesifikke deler av infrastrukturen.
18:00
Noen annonser 🙂
Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, , en unik analog av entry-level servere, som ble oppfunnet av oss for deg: (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).
Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om
Kilde: www.habr.com