National Environmental Satellite Data Information Service (NESDIS) har minskat sina kostnader för konfigurationshantering för Red Hat Enterprise Linux (RHEL) med 35 % genom att migrera från Puppet Enterprise till Ansible Tower. I den här videon "hur vi gjorde det" förklarar systemingenjören Michael Rau fallet med denna migrering, och delar med sig av användbara tips och lärdomar från att flytta från en SCM till en annan.
Från den här videon kommer du att lära dig:
- hur man för ledningen kan motivera möjligheten att byta från Puppet Enterprise till Ansible Tower;
- vilka strategier som ska användas för att göra övergången så smidig som möjligt;
- tips för omkodning av PE-manifest till Ansible Playbook;
- Rekommendationer för optimal installation av Ansible Tower.
Hej alla, jag heter Michael Rau, jag är senior systemingenjör på ActioNet, som arbetar för National Oceanic and Atmospheric Administration (NOAA) NESDIS-tjänst. Idag ska vi prata om strängtrimning - min egen erfarenhet av att migrera från Puppet Enterprise till Ansible Tower. Temat för den här presentationen är att "ta en titt på mina ärr" efter att jag gjorde den här övergången tidigare under året. Jag vill dela med mig av vad jag lärde mig genom den här processen. Så när du tar dig an något sånt här, med hjälp av min erfarenhet, kan du göra övergången utan extra arbete.
Du ser bilder liknande detta i början av varje presentation på Ansible Fest. Den här bilden beskriver historien om mitt företags automatisering. Jag är inte ny på det här eftersom jag har använt Puppet/Puppet Enterprise sedan 2007. Jag började arbeta med Ansible 2016, och precis som många andra användare av denna produkt lockades jag av möjligheten till "tricks" med hjälp av kommandoraden och enkla skript (playbooks). I slutet av 2017 kontaktade jag min ledning om de starka skälen till att flytta till Ansible Tower. Om en minut ska jag berätta om anledningarna som fick mig att ta detta steg. Efter att ha fått ledningens medgivande tog det flera månader till att slutföra planen, och jag gjorde övergången i januari-februari i år. Så vi övergav Puppet helt till förmån för Ansible, och det är en fantastisk sak.
Det som tilltalar mig mest med Ansible är förmågan att skriva och använda roller och spelböcker. Roller är utmärkta för att skapa distinkta men relaterade uppgifter och lägga all data relaterade till dessa uppgifter på ett ställe. En spelbok är en YAML-syntax, skriptfil som beskriver åtgärder för en eller flera värdar. Jag berättar för användare om dessa funktioner, i första hand mjukvaruutvecklare. Ansible Tower ger dig möjligheten att säga, "nej, du har inte skalåtkomst, men jag ger dig möjligheten att köra alla Tower-processer och starta om tjänsten när du behöver den." Jag kommer att berätta om arbetsmiljön och den utrustning vi använder.
Detta är ett federalt LAN, 7 fysiska platser anslutna via moln MPLS, 140 RHEL-servrar, varav 99% är virtuella (vSphere), SuperMicro-hårdvara, NexentaStore nätverkslagring, en uppsättning Cisco, Arista och Cumulus-switchar och Fortinet UTM unified hot management verktyg på varje webbplats.
Det federala nätverket innebär att jag måste använda alla informationssäkerhetsåtgärder enligt lag. Du bör komma ihåg att Puppet Enterprise inte stöder det mesta av hårdvaran vi använder. Vi är tvungna att använda budgethårdvara eftersom statliga myndigheter har problem med att finansiera denna utgiftspost. Det är därför vi köper SuperMicro-hårdvara och monterar vår utrustning från enskilda delar, vars underhåll garanteras av statliga kontrakt. Vi använder Linux och detta är en av de viktiga anledningarna till att byta till Ansible.
Vår historia med Puppet är följande.
Under 2007 hade vi ett litet nätverk med 20-25 noder, där vi distribuerade Puppet. I grund och botten var dessa noder bara RedHat "lådor". Under 2010 började vi använda webbgränssnittet Puppet Dashboard för 45 noder. När nätverket fortsatte att expandera, flyttade vi till PE 2014 3.3, och gjorde en fullständig övergång med en manifest omskrivning för 75 noder. Detta måste göras eftersom Puppet gillar att ändra spelets regler, och i det här fallet ändrade de språket helt. Ett år senare, när stödet för version 3 av Puppet Enterprise upphörde, tvingades vi migrera till PE 2015.2. Vi var tvungna att skriva om manifestet igen för de nya servrarna och köpa en licens med en reserv på 100 noder, även om vi vid den tiden bara hade 85 noder.
Bara 2 år har gått, och vi var återigen tvungna att göra mycket arbete för att migrera till den nya versionen PE 2016.4. Vi köpte en licens för 300 noder, med bara 130. Vi var återigen tvungna att göra stora ändringar i manifestet eftersom den nya versionen av språket hade en annan syntax än språket i 2015 års version. Som ett resultat bytte vår SCM från SVN-versionskontroll till Bitbucket (Git). Detta var vårt "förhållande" med Puppet.
Så jag var tvungen att förklara för ledningen varför vi behövde flytta till en annan SCM med hjälp av följande argument. Den första är det höga priset på tjänsten. Jag pratade med killarna på RedHat och de sa att kostnaden för att driva ett nätverk med 300 noder med Ansible Tower är halva kostnaden för Puppet Enterprise. Om du också köper Ansible Engine blir kostnaden ungefär densamma, men du får många fler funktioner än PE. Eftersom vi är ett statligt ägt företag som finansieras från den federala budgeten är detta ett ganska kraftfullt argument.
Det andra argumentet är mångsidighet. Puppet stöder bara hårdvara som har en Puppet-agent. Det betyder att en agent måste installeras på alla switchar, och det måste vara den senaste versionen. Och om några av dina switchar stöder en version, och vissa stöder en annan, måste du installera en ny version av PE-agenten på dem så att de alla kan fungera i samma SCM-system.
Ansible Tower-systemet fungerar annorlunda eftersom det inte har några agenter, men det har moduler som stöder Cisco-switchar och alla andra switchar. Denna SCM stöder Qubes OS, Linux och 4.NET UTM. Ansible Tower stöder även NexentaStore nätverkslagringskontroller baserade på Illumos kärna, ett Unix-baserat operativsystem med öppen källkod. Detta är väldigt lite stöd, men Ansible Tower gör det ändå.
Det tredje argumentet, som är mycket viktigt både för mig och för vår administration, är användarvänligheten. Jag tillbringade 10 år med att bemästra Puppet-moduler och manifestkod, men jag lärde mig Ansible inom en vecka eftersom denna SCM är mycket lättare att arbeta med. Om du kör körbara filer, naturligtvis, om du inte gör det i onödan, så arbetar intelligenta och lyhörda hanterare med dem. YAML-baserade spelböcker är lätta att lära sig och snabba att använda. De som aldrig har hört talas om YAML förut kan helt enkelt läsa manusen och enkelt förstå hur det fungerar.
För att vara ärlig, gör Puppet ditt jobb som utvecklare mycket svårare eftersom det bygger på att använda Puppet Master. Det är den enda maskinen som får kommunicera med Puppet-agenter. Om du har gjort några ändringar i manifestet och vill testa din kod måste du skriva om koden för Puppet Master, det vill säga konfigurera Puppet Master /etc/hosts-filen för att ansluta alla klienter och starta Puppet Server-tjänsten. Först efter detta kommer du att kunna testa driften av nätverksutrustning på en värd. Detta är en ganska smärtsam procedur.
Allt är mycket enklare i Ansible. Allt du behöver göra är att utveckla kod för en maskin som kan kommunicera via SSH med värden som testas. Detta är mycket lättare att arbeta med.
Nästa stora fördel med Ansible Tower är möjligheten att utnyttja ditt befintliga supportsystem och underhålla din befintliga hårdvarukonfiguration. Denna SCM använder all tillgänglig information om din infrastruktur och hårdvara, virtuella maskiner, servrar etc. utan några ytterligare steg. Den kan prata med dina RH Satellite-servrar, om du har en, och ger dig integrationer som du aldrig kommer att få med Puppet.
En annan viktig sak är detaljkontroll. Du vet att Puppet är ett modulärt system, det är en klient-serverapplikation, så du måste definiera de befintliga aspekterna av alla dina maskiner i ett långt manifest. I det här fallet måste tillståndet för varje enskilt element i systemet testas varje halvtimme - detta är standardperioden. Så här fungerar Puppet.
Tower räddar dig från det. Du kan köra en mängd olika processer på en mängd olika utrustning utan begränsningar; du kan utföra grundläggande arbete, köra andra viktiga processer, sätta upp ett säkerhetssystem och arbeta med databaser. Du kan göra allt som är svårt i Puppet Enterprise. Så om du konfigurerade det på en värd, kommer det att ta tid för ändringarna att träda i kraft på de återstående värdarna. I Ansible träder alla ändringar i kraft samtidigt.
Låt oss slutligen titta på säkerhetsmodulen. Ansible Tower implementerar det helt enkelt fantastiskt, med stor precision och omsorg. Du kan ge användare åtkomst till specifika tjänster eller till specifika värdar. Jag gör detta med mina anställda som är vana vid att arbeta på Windows, vilket begränsar deras tillgång till Linux-skalet. Jag ser till att de har tillgång till Tower så att de bara kan göra jobbet och köra endast de tjänster som är relevanta för dem.
Låt oss titta på de saker du behöver göra i förväg för att göra din övergång till Ansible Tower enklare. Först och främst måste du förbereda din utrustning. Om vissa delar av din infrastruktur inte redan finns i databasen måste du lägga till dem där. Det finns system som inte ändrar sina egenskaper och därför inte finns i Puppet-databasen, men om du inte lägger till dem där innan du flyttar till Tower kommer du att förlora en rad fördelar. Detta kan vara en "smutsig", preliminär databas, men den bör innehålla information om all utrustning du har. Därför bör du skriva ett dynamiskt hårdvaruskript som automatiskt skjuter in alla infrastrukturändringar i databasen, sedan vet Ansible vilka värdar som ska finnas på det nya systemet. Du behöver inte berätta för denna SCM vilka värdar du har lagt till och vilka värdar som inte längre finns, eftersom den kommer att veta allt detta automatiskt. Ju mer data det finns i databasen, desto mer användbar och flexibel blir Ansible. Det fungerar som om det helt enkelt läser hårdvarustatusstreckkoden från en databas.
Lägg lite tid på att bli bekant med kommandoraden i Ansible. Kör några anpassade kommandon för att testa hårdvaruskriptet, skriv och kör några enkla men användbara playbook-skript, använd Jinja2-mallar där det är lämpligt. Försök att skriva en roll och ett skript för en komplex process i flera steg med hjälp av en vanlig hårdvarukonfiguration. Lek med dessa saker, testa hur det fungerar. På så sätt lär du dig hur du använder verktygen för att skapa bibliotek som används i Tower. Jag har redan sagt att det tog mig cirka 3 månader att förbereda mig för övergången. Jag tror att baserat på min erfarenhet kommer du att kunna göra detta snabbare. Tänk inte på att denna tid är bortkastad, för senare kommer du att uppleva alla fördelar med det utförda arbetet.
Därefter måste du bestämma vad du förväntar dig av Ansible Tower, vad exakt detta system ska göra för dig.
Behöver du distribuera systemet på bar hårdvara, på bara virtuella maskiner? Eller vill du behålla de ursprungliga driftsförhållandena och inställningarna för befintlig utrustning? Detta är en mycket viktig aspekt för offentliga företag, så du måste vara säker på att du kommer att kunna migrera och distribuera Ansible på din befintliga konfiguration. Identifiera rutinmässiga administrativa processer som du vill automatisera. Ta reda på om du behöver distribuera specifika applikationer och tjänster på det nya systemet. Gör en lista över vad du vill göra och prioritera det.
Börja sedan skriva skriptkod och roller som möjliggör de uppgifter du planerar att slutföra. Kombinera dem till Projects, en logisk samling relevanta spelböcker. Varje projekt kommer att tillhöra ett separat Git-förråd eller ett annat förråd beroende på vilken kodhanterare du använder. Du kan hantera playbook-skript och playbook-kataloger genom att manuellt placera dem i Project Base Path på Tower-servern, eller genom att placera playbook i valfritt källkodshanteringssystem (SCM) som stöds av Tower, inklusive Git, Subversion, Mercurial och Red Hat Insikter. Inom ett projekt kan du placera hur många skript du vill. Till exempel skapade jag ett grundläggande projekt där jag placerade ett skript för RedHat-kärnelementen, ett skript för Linux-kärnan och skript för resten av baslinjerna. I ett projekt fanns det alltså en mängd olika roller och scenarier som hanterades från ett Git-förråd.
Att köra alla dessa saker genom kommandoraden är ett bra sätt att testa deras funktionalitet. Detta förbereder dig för Tower-installationen.
Låt oss prata lite om omkodning av Puppet-manifestet, eftersom jag tillbringade mycket tid på detta tills jag kom på vad som faktiskt behövde göras.
Som jag sa tidigare lagrar Puppet alla inställningar och hårdvarualternativ i ett långt manifest, och detta manifest lagrar allt som denna SCM ska göra. När du gör övergången behöver du inte klämma ihop alla dina uppgifter i en lista utan tänk istället på strukturen i det nya systemet: roller, skript, taggar, grupper och vad som ska finnas där. Vissa av de autonoma nätverkselementen bör grupperas i grupper för vilka skript kan skapas. Mer komplexa infrastrukturelement som involverar ett stort antal resurser, inklusive fristående klasser, kan kombineras till roller. Innan du migrerar måste du bestämma dig för detta. Om du skapar stora roller eller scenarier som inte får plats på en skärm bör du använda taggar för att kunna fånga specifika delar av infrastrukturen.
18:00
Några annonser 🙂
Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss genom att lägga en beställning eller rekommendera till vänner, , en unik analog av ingångsservrar, som uppfanns av oss för dig: (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).
Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om
Källa: will.com