Den nationale informationsservice for satellitdata om miljøet (NESDIS) har reduceret sine omkostninger til konfigurationsadministration af Red Hat Enterprise Linux (RHEL) med 35 % ved at skifte fra Puppet Enterprise til Ansible Tower. I denne 'hvordan vi gjorde det'-video begrunder systemingeniør Michael Rau denne migration og deler nyttige råd samt erfaringer fra overgangen fra ett SCM til en anden.
I denne video vil du lære:
- hvordan man begrunder overgangen fra Puppet Enterprise til Ansible Tower over for ledelsen;
- hvilke strategier der skal anvendes for at sikre en så glidende overgang som muligt;
- råd til transkodning af PE-manifest i Ansible Playbook;
- anbefalinger til optimal installation af Ansible Tower.
Hej alle sammen, mit navn er Michael Rau, jeg er senior systemingeniør hos ActioNet, som arbejder for National Oceanic and Atmospheric Administration (NOAA)'s NESDIS-tjeneste. I dag vil vi tale om koding af strenge – min egen erfaring med at migrere fra Puppet Enterprise til Ansible Tower. Emnet for denne præsentation er at 'se på mine ar', der er tilbage efter denne overgang i starten af året. Jeg vil dele, hvad jeg har lært i løbet af denne proces. Så når du tager fat på noget lignende, kan du bruge min erfaring til at gøre overgangen lettere.
Du ser dias, der ligner dette, i begyndelsen af hver præsentation ved Ansible Fest. Dette dia indeholder historien om min virksomheds automatisering. Jeg er ikke ny i dette, da jeg har brugt Puppet/Puppet Enterprise siden 2007. Jeg begyndte at arbejde med Ansible i 2016, og ligesom mange andre brugere af dette produkt blev jeg tiltrukket af muligheden for at udføre 'tricks' via kommandolinjen og enkle script (playbooks). I slutningen af 2017 henvendte jeg mig til min ledelse med alvorlige argumenter for en overgang til Ansible Tower. Om et øjeblik vil jeg tale om de grunde, der fik mig til at tage dette skridt. Efter at have fået godkendelse fra ledelsen tog det yderligere nogle måneder at udføre planen, og jeg gennemførte overgangen i januar-februar i år. Så vi har fuldstændigt opgivet Puppet til fordel for Ansible, og det er en fantastisk ting.
Det, jeg sætter mest pris på ved Ansible, er muligheden for at skrive og bruge roller og playbooks. Roller er perfekte til at skabe forskellige, men sammenhængende opgaver og til at samle alle data relateret til disse opgaver ét sted. En playbook er et YAML-syntaks script, der beskriver handlinger for en eller flere værter. Jeg præsenterer disse funktioner for brugerne, primært softwareudviklere. Ansible Tower giver mulighed for at sige: "nej, du har ikke adgang til shell adgang, men jeg giver dig mulighed for at starte alle Tower-processer og genstarte tjenesten, når du har brug for det." Jeg vil fortælle dig om vores arbejdsplads og det udstyr, vi bruger.
Dette er et føderalt LAN, 7 fysiske steder, der er forbundet via cloud MPLS, 140 RHEL-servere, hvoraf 99% er virtuelle (vSphere), SuperMicro-hardware, NexentaStore netværkslagring, et sæt Cisco-, Arista- og Cumulus-switches samt Fortinet UTM forenede trusler på hver lokation.
Det føderale netværk betyder, at jeg skal bruge alle de informationsbeskyttelsesmidler, som lovgivningen foreskriver. Du skal huske, at Puppet Enterprise ikke understøtter størstedelen af det udstyr, vi bruger. Vi er nødt til at anvende budgetvenlig hardware, da statslige institutioner har problemer med at finansiere denne udgiftskategori. Derfor køber vi "hardware" af SuperMicro-klassen og samler vores udstyr fra forskellige komponenter, hvis vedligeholdelse er garanteret af offentlige kontrakter. Vi bruger Linux, og det er en af de vigtigste grunde til overgangen til Ansible.
Vores historie med Puppet er som følger.
I 2007 havde vi et lille netværk med 20-25 noder, hvor vi implementerede Puppet. Disse noder var primært bare RedHat "bokse". I 2010 begyndte vi at bruge Puppet Dashboard webgrænsefladen til 45 noder. Da netværket fortsatte med at udvide, skiftede vi i 2014 til PE 3.3, hvilket krævede en komplet overgang med omskrivning af manifestet for 75 noder. Dette var nødvendigt, fordi Puppet kan ændre spillereglerne, og i dette tilfælde ændrede de helt sproget. Et år senere, da supporten for Puppet Enterprise 3 ophørte, var vi tvunget til at migrere til PE 2015.2. Vi måtte igen omskrive manifestet til de nye servere og købe en licens til 100 noder, selvom vi på det tidspunkt kun havde 85 noder.
Der gik kun 2 år, og vi måtte igen gøre en stor indsats for at opgradere til den nye PE 2016.4 version. Vi købte en licens til 300 noder, mens vi kun havde 130. Vi måtte igen foretage betydelige ændringer i manifestet, fordi den nye versions sprog havde en syntaks, der var forskellig fra 2015-versionen. Resultatet var, at vores SCM gik fra SVN versionskontrolsystemet til Bitbucket (Git). Sådan var vores "forhold" til Puppet.
Så jeg måtte forklare ledelsen, hvorfor vi skulle skifte til et andet SCM ved at bruge følgende argumenter. Det første var den høje pris på servicen. Jeg talte med fyrene fra RedHat, og de sagde, at omkostningerne ved at vedligeholde et netværk med 300 noder med Ansible Tower udgjorde halvdelen af omkostningerne ved Puppet Enterprise. Hvis man købte Ansible Engine, ville omkostningerne være omtrent de samme, men man ville få mange flere funktioner end med PE. Da vi er en statsejet virksomhed finansieret med føderale midler, er det et ret tungt argument.
Det andet argument er alsidighed. Puppet understøtter kun det udstyr, der har Puppet-agenten installeret. Det betyder, at der skal installeres en agent på alle switches, og den skal være den nyeste version. Og hvis nogle af dine switches understøtter én version, mens andre støtter en anden, skal du installere den nye PE-agentversion på dem for at sikre, at de alle kan fungere i det samme SCM-system.
Ansible Tower fungerer anderledes, fordi den ikke har nogen agenter, men har moduler, der understøtter Cisco-switches og andre switches. Denne SCM understøtter Qubes OS, Linux og 4.NET UTM. Ansible Tower understøtter også NexentaStore netværkslagringscontrollere, der er baseret på Illumos-kernen - et open-source operativsystem baseret på Unix. Dette er en meget begrænset støtte, men Ansible Tower tilbyder stadig denne funktion.
Det tredje argument, som er meget vigtigt for både mig og vores administration, er brugervenligheden. Jeg har brugt 10 år på at mestre moduler og manifestkode i Puppet, men jeg lærte Ansible i løbet af en uge, fordi det er meget lettere at arbejde med denne SCM. Hvis du kører eksekverbare filer, i det mindste hvis du ikke gør det unødigt, fungerer de med fornuftige og responsivrige håndterere. Playbooks baseret på YAML er kendetegnet ved nem indlæring og hurtig anvendelse. De, der aldrig har hørt om YAML før, kan blot læse scripts og let forstå, hvordan det fungerer.
Ærligt talt gør Puppet dit arbejde som udvikler meget mere kompliceret, fordi det er baseret på brugen af Puppet Master. Dette er den eneste maskine, der har tilladelse til at kommunikere med Puppet-agenterne. Hvis du har foretaget ændringer i manifestet og ønsker at teste din kode, skal du omskrive koden til Puppet Master, dvs. konfigurere Puppet-masterfilen /etc/hosts til at forbinde alle klienter og starte Puppet Server-tjenesten. Først derefter kan du teste netværksudstyret på én vært. Dette er en temmelig smertefuld procedure.
I Ansible er alt meget enklere. Alt, hvad du skal gøre, er at udvikle koden for den maskine, der har mulighed for at kommunikere via SSH-protokollen med den testede vært. Det er meget lettere at arbejde med dette.
Den næste store fordel ved Ansible Tower er muligheden for at inddrage dit eksisterende support-system og bevare den nuværende hardwarekonfiguration. Denne SCM anvender uden ekstra handling alle de oplysninger, du har om din infrastruktur og udstyr, virtuelle maskiner, servere osv. Den kan kommunikere med dine RH Satellite-servere, hvis du har nogen, og giver dig en integration, som du aldrig vil opnå ved at arbejde med Puppet.
En anden vigtig ting er detaljeret kontrol. Du ved, at Puppet er et modulært system, det er en klient-server applikation, så du skal definere de eksisterende aspekter af arbejdet på alle dine maskiner i ét langt manifest. På den måde skal tilstanden af hvert enkelt element i systemet testes hver halve time – det er standardperioden. Sådan fungerer Puppet.
Tower befrier dig fra dette. Du kan frit udføre forskellige processer på forskellige typer hardware, du kan udføre det grundlæggende arbejde, køre andre vigtige processer, konfigurere sikkerhedssystemet, arbejde med databaser. Du kan gøre alt det, som i Puppet Enterprise er forbundet med specifikke udfordringer. Så hvis du har foretaget konfigurationen på én vært, vil det tage tid, før ændringerne træder i kraft på de øvrige værter. I Ansible træder alle ændringer i kraft samtidig.
Endelig lad os se på sikkerhedsmodulet. I Ansible Tower er det implementeret virkelig fantastisk, med stor præcision og omhu. Du kan give brugerne adgang til specifikke tjenester eller til specifikke værter. Jeg gør det samme med mine medarbejdere, der er vant til at arbejde på Windows, ved at begrænse deres adgang til Linux-skallen. Jeg sikrer dem sådan adgang til Tower, så de kun kan udføre det arbejde og starte de tjenester, der relaterer sig til deres kompetence.
Lad os se på ting, der skal gøres på forhånd for at lette overgangen til Ansible Tower. Først og fremmest skal du forberede dit udstyr. Hvis nogle elementer i din infrastruktur ikke er til stede i databasen, skal du tilføje dem. Der findes systemer, der ikke ændrer deres egenskaber og derfor ikke er i Puppet-databasen, men hvis du ikke tilføjer dem, før du overgår til Tower, vil du gå glip af en række fordele. Det kan være en "beskidt" forberedende database, men den skal indeholde oplysninger om alt dit udstyr. Derfor bør du skrive et dynamisk udstyrsskript, der automatisk opdaterer databasen med alle ændringer i infrastrukturen, så Ansible ved, hvilke værter der skal være i det nye system. Du behøver ikke at informere denne SCM om, hvilke værter du har tilføjet, og hvilke værter der ikke længere eksisterer, fordi alt dette vil blive opdaget automatisk. Jo flere oplysninger der er i databasen, desto mere nyttig og fleksibel vil Ansible være. Det fungerer som om det blot scanner databasens stregkode for udstyrets status.
Brug lidt tid på at blive fortrolig med at arbejde i kommandolinjen i Ansible. Kør nogle specielle kommandoer for at teste udstyrsskriptet, skriv og kør nogle enkle, men nyttige playbook-scripts, brug Jinja2-skabeloner, hvor det er passende. Prøv at skrive en rolle og et script til en kompleks, flertrinsproces med en standard og ofte anvendt konfiguration af udstyr. Leg med disse ting, test hvordan det fungerer. På den måde vil du lære at arbejde med værktøjer til at oprette biblioteker, der bruges i Tower. Jeg har allerede nævnt, at min forberedelse til overgangen tog omkring 3 måneder. Jeg tror, at baseret på min erfaring vil du kunne gøre det hurtigere. Tænk ikke på den tid som spildt, da du senere vil mærke alle fordelene ved det udførte arbejde.
Dernæst er det nødvendigt at beslutte, hvad du forventer af Ansible Tower, og hvad denne system specifikt skal gøre for dig.
Har du brug for at implementere systemet på tomt udstyr eller på tomme virtuelle maskiner? Eller vil du bevare de eksisterende driftsbetingelser og indstillinger af det nuværende udstyr? Dette er en meget vigtig aspekt for arbejdet i offentlige virksomheder, så du skal være sikker på, at du kan migrere og implementere Ansible på den eksisterende konfiguration. Bestem de administrative proceser, du ønsker at automatisere. Find ud af, om du skal implementere specifikke applikationer og tjenester på det nye system. Lav en liste over, hvad du ønsker at gøre, og prioriterer det.
Begynd derefter at skrive koden til scripts og roller, der vil sikre udførelsen af de opgaver, du har planlagt. Saml dem i Projects, en logisk samling af relevante playbook-scripts. Hver Project vil være knyttet til et separat Git-repositorium eller et andet repository, afhængig af den kodehåndteringssystem du bruger. Du kan administrere playbook-scripts og playbook-kataloger ved at placere dem manuelt i Project Base Path på Tower-serveren, eller ved at placere playbook i et hvilket som helst source code management system (SCM), understøttet af Tower, herunder Git, Subversion, Mercurial og Red Hat Insights. Inden for et Project kan du have så mange scripts, som du vil. For eksempel har jeg oprettet et grundlæggende Project, hvor jeg har placeret et script for de grundlæggende elementer i RedHat, et script for Linux-basen og scripts til de øvrige grundlæggende målinger. På denne måde var der mange forskellige roller og scripts i ét projekt, der blev administreret fra et enkelt Git-repositorium.
Kør alle disse ting gennem kommandolinjen; det er en god måde at teste deres funktionalitet. På den måde vil du være forberedt til installationen af Tower.
Lad os tale lidt om transkodning af Puppet-manifestet, fordi jeg brugte meget tid på dette, indtil jeg indså, hvad der faktisk skulle gøres.
Som jeg allerede har nævnt, opbevarer Puppet alle indstillinger og hardwareparametre i et enkelt langt manifest, og i dette manifest er alt det, som denne SCM skal gøre, gemt. Når du skifter, skal du ikke presse alle dine opgaver ind i en liste; tænk i stedet på strukturen i det nye system: roller, scripts, tags, grupper, og hvad der skal indgå. Nogle af netværkets autonome elementer bør samles i grupper, for hvilke der kan oprettes scripts. Mere komplekse infrastrukturkomponenter, som kræver mange ressourcer, herunder autonome klasser, kan samles i roller. Du skal finde ud af dette inden migrationen. Hvis du opretter store roller eller scripts, der ikke kan vises på én skærm, bør du bruge tags for at kunne fange separate dele af infrastrukturen.
18:00
Lidt reklame 🙂
Tak fordi du bliver hos os. Kan du lide vores artikler? Ønsker du at se flere interessante materialer? Støt os ved at bestille eller anbefale os til dine bekendte, , en unik analog til entry-level servere, som vi har designet til dig: (tilgængelige muligheder med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd til halv pris i datacenteret Equinix Tier IV i Amsterdam? Kun hos os i Holland! Dell R420 - 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra 99 $! Læs om hvordan
Kilde: habr.com
