National Environmental Satellite Data Information Service (NESDIS) har reduceret sine omkostninger til konfigurationsadministration for Red Hat Enterprise Linux (RHEL) med 35 % ved at migrere fra Puppet Enterprise til Ansible Tower. I denne "hvordan vi gjorde det"-video forklarer systemingeniør Michael Rau sagen for denne migrering og deler nyttige tips og erfaringer fra at flytte fra en SCM til en anden.
Fra denne video lærer du:
- hvordan man over for ledelsen kan begrunde muligheden for at skifte fra Puppet Enterprise til Ansible Tower;
- hvilke strategier der skal bruges for at gøre overgangen så smidig som muligt;
- tips til omkodning af PE-manifester til Ansible Playbook;
- Anbefalinger for optimal installation af Ansible Tower.
Hej alle sammen, mit navn er Michael Rau, jeg er senior systemingeniør hos ActioNet, som arbejder for NESDIS-tjenesten National Oceanic and Atmospheric Administration (NOAA). I dag skal vi tale om strengtrimning - min egen erfaring med at migrere fra Puppet Enterprise til Ansible Tower. Temaet for denne præsentation er at "tage et kig på mine ar", efter jeg lavede denne overgang tidligere på året. Jeg vil gerne dele, hvad jeg har lært gennem denne proces. Så når du påtager dig noget som dette, ved at bruge min erfaring, kan du klare overgangen uden ekstra arbejde.
Du ser slides lignende dette i begyndelsen af hver præsentation på Ansible Fest. Dette dias skitserer historien om min virksomheds automatisering. Jeg er ikke ny i dette, fordi 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 "tricks" ved hjælp af kommandolinjen og simple scripts (playbooks). I slutningen af 2017 henvendte jeg mig til min ledelse om de stærke grunde til at flytte til Ansible Tower. Om et øjeblik vil jeg fortælle dig om årsagerne, der fik mig til at tage dette skridt. Efter at have modtaget ledelsens samtykke tog det flere måneder at færdiggøre planen, og jeg foretog overgangen i januar-februar i år. Så vi har helt opgivet Puppet til fordel for Ansible, og det er en fantastisk ting.
Det, der tiltaler mig mest ved Ansible, er evnen til at skrive og bruge roller og spillebøger. Roller er gode til at skabe forskellige, men relaterede opgaver og placere alle data relateret til disse opgaver ét sted. En playbook er en YAML-syntaks, scriptfil, der beskriver handlinger for en eller flere værter. Jeg fortæller brugerne om disse funktioner, primært softwareudviklere. Ansible Tower giver dig mulighed for at sige, "nej, du har ikke shell-adgang, men jeg giver dig mulighed for at køre alle Tower-processer og genstarte tjenesten, når du har brug for det." Jeg fortæller om arbejdsmiljøet og det udstyr vi bruger.
Dette er et føderalt LAN, 7 fysiske websteder 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 og Fortinet UTM unified trusselsstyring værktøjer på hvert websted.
Det føderale netværk betyder, at jeg skal bruge alle de informationssikkerhedsforanstaltninger, der er fastsat i loven. Du skal huske på, at Puppet Enterprise ikke understøtter det meste af den hardware, vi bruger. Vi er tvunget til at bruge budgethardware, fordi offentlige myndigheder har problemer med at finansiere denne udgiftspost. Det er derfor, vi køber SuperMicro hardware og samler vores udstyr af individuelle dele, hvis vedligeholdelse er garanteret af offentlige kontrakter. Vi bruger Linux, og dette er en af de vigtige grunde til at skifte til Ansible.
Vores historie med Puppet er som følger.
I 2007 havde vi et lille netværk på 20-25 noder, hvor vi indsatte Puppet. Dybest set var disse noder kun RedHat "kasser". I 2010 begyndte vi at bruge Puppet Dashboard-webgrænsefladen til 45 noder. Da netværket fortsatte med at udvide, flyttede vi til PE 2014 i 3.3 og lavede en komplet overgang med en manifest omskrivning for 75 noder. Dette måtte gøres, fordi Puppet kan lide at ændre spillereglerne, og i dette tilfælde ændrede de sproget fuldstændigt. Et år senere, da understøttelsen af version 3 af Puppet Enterprise sluttede, blev vi tvunget til at migrere til PE 2015.2. Vi var nødt til at omskrive manifestet igen til de nye servere og købe en licens med en reserve på 100 noder, selvom vi på det tidspunkt kun havde 85 noder.
Der er kun gået 2 år, og vi skulle igen gøre en masse arbejde for at migrere til den nye version PE 2016.4. Vi købte en licens til 300 noder, der kun havde 130. Vi måtte igen lave store ændringer i manifestet, fordi den nye version af sproget havde en anden syntaks end sproget i 2015-versionen. Som et resultat skiftede vores SCM fra SVN-versionskontrol til Bitbucket (Git). Dette var vores "forhold" til Puppet.
Så jeg var nødt til at forklare ledelsen, hvorfor vi skulle flytte til en anden SCM ved hjælp af følgende argumenter. Den første er den høje pris på tjenesten. Jeg talte med fyrene på RedHat, og de sagde, at omkostningerne ved at drive et 300 node-netværk med Ansible Tower er halvdelen af omkostningerne ved Puppet Enterprise. Hvis du også køber Ansible Engine, vil omkostningerne være omtrent det samme, men du vil få mange flere funktioner end PE. Da vi er en statsejet virksomhed finansieret over det føderale budget, er dette et ret stærkt argument.
Det andet argument er alsidighed. Puppet understøtter kun hardware, der har en Puppet-agent. Det betyder, at der skal installeres en agent på alle switches, og det skal være den nyeste version. Og hvis nogle af dine switche understøtter én version, og nogle understøtter en anden, skal du installere en ny version af PE-agenten på dem, så de alle kan arbejde i det samme SCM-system.
Ansible Tower-systemet fungerer anderledes, fordi det ikke har nogen agenter, men det har moduler, der understøtter Cisco-switches og alle andre switches. Denne SCM understøtter Qubes OS, Linux og 4.NET UTM. Ansible Tower understøtter også NexentaStore-netværkslagringscontrollere baseret på Illumos-kernen, et open source Unix-baseret operativsystem. Dette er meget lidt støtte, men Ansible Tower gør det alligevel.
Det tredje argument, som er meget vigtigt både for mig og for vores administration, er brugervenlighed. Jeg brugte 10 år på at mestre Puppet-moduler og manifestkode, men jeg lærte Ansible inden for en uge, fordi denne SCM er meget lettere at arbejde med. Hvis du kører eksekverbare filer, selvfølgelig, medmindre du gør det unødvendigt, så arbejder intelligente og responsive handlere med dem. YAML-baserede spillebøger er nemme at lære og hurtige at bruge. De, der aldrig har hørt om YAML før, kan blot læse scripts og nemt forstå, hvordan det fungerer.
For at være ærlig gør Puppet dit job som udvikler meget vanskeligere, fordi det er baseret på at bruge Puppet Master. Det er den eneste maskine, der har lov til at kommunikere med Puppet-agenter. Hvis du har foretaget ændringer i manifestet og ønsker at teste din kode, skal du omskrive koden til Puppet Master, det vil sige konfigurere Puppet Master /etc/hosts-filen til at forbinde alle klienter og starte Puppet Server-tjenesten. Først efter dette vil du være i stand til at teste driften af netværksudstyr på én vært. Dette er en ret smertefuld procedure.
Alt er meget enklere i Ansible. Alt du skal gøre er at udvikle kode til en maskine, der kan kommunikere via SSH med værten under test. Dette er meget nemmere at arbejde med.
Den næste store fordel ved Ansible Tower er evnen til at udnytte dit eksisterende supportsystem og vedligeholde din eksisterende hardwarekonfiguration. Denne SCM bruger al tilgængelig information om din infrastruktur og hardware, virtuelle maskiner, servere osv. uden yderligere trin. Den kan tale med dine RH Satellite-servere, hvis du har en, og giver dig integrationer, du aldrig får 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 alle dine maskiner i et langt manifest. I dette tilfælde skal tilstanden for hvert enkelt element i systemet testes hver halve time - dette er standardperioden. Sådan fungerer Puppet.
Tower redder dig fra det. Du kan køre en række processer på en række forskellige udstyr uden begrænsninger; du kan udføre grundlæggende arbejde, køre andre vigtige processer, opsætte et sikkerhedssystem og arbejde med databaser. Du kan gøre alt, hvad der er svært i Puppet Enterprise. Så hvis du konfigurerede det på én vært, vil det tage tid, før ændringerne træder i kraft på de resterende værter. I Ansible træder alle ændringer i kraft på samme tid.
Lad os endelig se på sikkerhedsmodulet. Ansible Tower implementerer det simpelthen fantastisk, med stor præcision og omhu. Du kan give brugere adgang til bestemte tjenester eller til bestemte værter. Det gør jeg med mine medarbejdere, der er vant til at arbejde på Windows, hvilket begrænser deres adgang til Linux-skallen. Jeg sikrer, at de har adgang til Tower, så de kun kan udføre arbejdet og kun køre de tjenester, der er relevante for dem.
Lad os se på de ting, du skal gøre på forhånd for at gøre din overgang til Ansible Tower nemmere. Først og fremmest skal du forberede dit udstyr. Hvis nogle elementer af din infrastruktur ikke allerede er i databasen, skal du tilføje dem der. Der er systemer, der ikke ændrer deres egenskaber og derfor ikke er i Puppet-databasen, men hvis du ikke tilføjer dem der, inden du flytter til Tower, mister du en række fordele. Dette kan være en "beskidt", foreløbig database, men den bør indeholde oplysninger om alt det udstyr, du har. Derfor bør du skrive et dynamisk hardware-script, der automatisk vil skubbe alle infrastrukturændringer ind i databasen, så vil Ansible vide, hvilke værter der skal være til stede på det nye system. Du behøver ikke fortælle denne SCM, hvilke værter du har tilføjet, og hvilke værter der ikke længere eksisterer, fordi den vil vide alt dette automatisk. Jo mere data der er i databasen, jo mere anvendelig og fleksibel vil Ansible være. Det fungerer, som om det blot læser hardwarestatusstregkoden fra en database.
Brug lidt tid på at blive fortrolig med kommandolinjen i Ansible. Kør nogle brugerdefinerede kommandoer for at teste hardwarescriptet, skriv og kør nogle enkle, men nyttige playbook-scripts, brug Jinja2-skabeloner, hvor det er relevant. Prøv at skrive en rolle og et script til en kompleks proces med flere trin ved hjælp af en almindelig, almindeligt forekommende hardwarekonfiguration. Leg med disse ting, test hvordan det virker. På denne måde lærer du, hvordan du bruger biblioteksoprettelsesværktøjerne, der bruges i Tower. Jeg har allerede sagt, at det tog mig omkring 3 måneder at forberede mig på overgangen. Jeg tror, at baseret på min erfaring, vil du være i stand til at gøre dette hurtigere. Overvej ikke denne tid som spildt, for senere vil du opleve alle fordelene ved det udførte arbejde.
Dernæst skal du beslutte, hvad du forventer af Ansible Tower, hvad præcist dette system skal gøre for dig.
Har du brug for at implementere systemet på bare hardware, på bare virtuelle maskiner? Eller ønsker du at bevare de originale driftsforhold og indstillinger for eksisterende udstyr? Dette er et meget vigtigt aspekt for offentlige virksomheder, så du skal være sikker på, at du vil være i stand til at migrere og implementere Ansible på din eksisterende konfiguration. Identificer rutinemæssige administrative processer, som du ønsker at automatisere. Find ud af, om du har brug for at implementere specifikke applikationer og tjenester på det nye system. Lav en liste over, hvad du vil gøre, og prioriter det.
Begynd derefter at skrive scriptkode og roller, der vil aktivere de opgaver, du planlægger at udføre. Kombiner dem i Projects, en logisk samling af relevante spillebøger. Hvert projekt vil tilhøre et separat Git-lager eller et andet depot afhængigt af hvilken kodemanager du bruger. Du kan administrere playbook-scripts og playbook-mapper ved manuelt at placere dem i Project Base Path på Tower-serveren eller ved at placere playbook i et hvilket som helst kildekodestyringssystem (SCM) understøttet af Tower, inklusive Git, Subversion, Mercurial og Red Hat Indsigt. Inden for et projekt kan du placere så mange scripts, som du vil. For eksempel oprettede jeg et grundlæggende projekt, hvor jeg placerede et script til RedHat-kerneelementerne, et script til Linux-kernen og scripts til resten af basislinjerne. I et projekt var der således en række roller og scenarier, der blev styret fra ét Git-lager.
At køre alle disse ting gennem kommandolinjen er en god måde at teste deres funktionalitet på. Dette vil forberede dig til Tower-installationen.
Lad os tale lidt om omkodning af Puppet-manifestet, for jeg brugte meget tid på dette, indtil jeg fandt ud af, hvad der egentlig skulle gøres.
Som jeg sagde før, gemmer Puppet alle indstillinger og hardwaremuligheder i et langt manifest, og dette manifest gemmer alt, hvad denne SCM skal gøre. Når du laver overgangen, behøver du ikke at samle alle dine opgaver på én liste, men tænk i stedet på strukturen af det nye system: roller, scripts, tags, grupper og hvad der skal gå der. Nogle af de autonome netværkselementer bør grupperes i grupper, som scripts kan oprettes til. Mere komplekse infrastrukturelementer, der involverer et stort antal ressourcer, herunder selvstændige klasser, kan kombineres til roller. Før du migrerer, skal du tage stilling til dette. Hvis du opretter store roller eller scenarier, der ikke passer på én skærm, bør du bruge tags for at kunne fange bestemte dele af infrastrukturen.
18:00
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com