Klipper trådar: övergång från Puppet Enterprise till Ansible Tower. Del 1

Den nationella informationsservicen för satellitdata om miljön (NESDIS) har minskat sina kostnader för hantering av Red Hat Enterprise Linux (RHEL) med 35 % genom att byta från Puppet Enterprise till Ansible Tower. I den här videon från kategorin 'hur vi gjorde det' förklarar systemingenjören Michael Rau varför denna migrering genomfördes, delar med sig av användbara tips och erfarenheter från övergången mellan olika SCM-system.

I den här videon får du veta:

• hur man motiverar ledningen till att byta från Puppet Enterprise till Ansible Tower;
• vilka strategier man ska använda för en så smidig övergång som möjligt;
• tips för att transkoda PE-manifest till Ansible Playbook;
• rekommendationer för optimal installation av Ansible Tower.

Hej allihopa, jag heter Michael Rau och jag är senior systemingenjör på ActioNet, som arbetar för National Oceanic and Atmospheric Administration (NOAA) och NESDIS. Idag ska vi prata om att klippa strängar – min egen erfarenhet av att migrera från Puppet Enterprise till Ansible Tower. Ämnet för denna presentation handlar om att 'titta på mina ärr', kvarstående efter att jag genomfört denna övergång i början av året. Jag vill berätta om vad jag lärt mig under detta process. Så när du tar på dig något liknande, kan du använda min erfarenhet för att göra övergången utan onödigt besvär.

Du ser diabilder som denna i början av varje presentation på Ansible Fest. På denna bild framgår historien om min företagsautomatisering. Jag är ingen nybörjare på detta område, eftersom jag har använt Puppet/Puppet Enterprise sedan 2007. Jag började arbeta med Ansible 2016, och det som lockade mig, liksom många andra användare av produkten, var möjligheten till 'tricks' med hjälp av kommandoraden och enkla skript (playbooks). I slutet av 2017 talade jag med min ledning om de allvarliga skälen till att övergå till Ansible Tower. Om en stund kommer jag att berätta om de skäl som fick mig att ta detta steg. Efter att ha fått ledningens godkännande tog det flera månader innan den planerade övergången genomfördes i januari-februari i år. Så, vi har helt övergivit Puppet till förmån för Ansible, vilket är en stor prestation.

Det som fascinerar mig mest med Ansible är möjligheten att skriva och använda roller (roles) och spelböcker (playbooks). Roller passar utmärkt för att skapa olika men relaterade uppgifter (tasks) och att samla all information relaterad till dessa uppgifter på ett ställe. En playbook är en YAML-syntax, en skriptfil som beskriver åtgärder för en eller flera värdar. Jag berättar för användarna, främst utvecklare, om dessa funktioner. Ansible Tower ger möjlighet att säga: "nej, ni har inte tillgång till shell access, men jag ger er möjlighet att starta alla Tower-processer och starta om tjänsten när ni behöver det". Jag kommer att berätta om arbetsmiljön och den utrustning vi använder.

Detta är ett federalt LAN, 7 fysiska platser kopplade via molnbaserat MPLS, 140 RHEL-servrar, varav 99 % är virtuella (vSphere), SuperMicro-hårdvara, NexentaStore nätverkslagring, en uppsättning switchar från Cisco, Arista och Cumulus samt lösningar för enhetlig hotstyrning från Fortinet UTM på varje plats.

Det federala nätverket innebär att jag måste använda alla informationsskyddsmedel som föreskrivs av lagstiftningen. Ni bör ha i åtanke att Puppet Enterprise inte stödjer den flesta hårdvara vi använder. Vi är tvungna att använda budgetvänlig hårdvara eftersom statliga institutioner har problem med finansiering av denna kostnad. Därför köper vi SuperMicro-hårdvara och sätter ihop vår utrustning av individuella komponenter vars underhåll garanteras av statliga kontrakt. Vi använder Linux, och det är en av de viktiga anledningarna till övergången till Ansible.

Vår historia med Puppet är som följande.

År 2007 hade vi ett litet nätverk med 20-25 noder där vi implementerade Puppet. Huvudsakligen bestod dessa noder bara av RedHat "lådor". År 2010 började vi använda webbgränssnittet Puppet Dashboard för 45 noder. Eftersom nätverket fortsatte att växa, övergick vi 2014 till PE 3.3 och gjorde en fullständig övergång med omskrivning av manifestet för 75 noder. Detta behövde göras eftersom Puppet älskar att ändra spelreglerna, och i detta fall ändrade de helt språket. Ett år senare, när stödet för tredje versionen av Puppet Enterprise upphörde, var vi tvungna att migrera till PE 2015.2. Återigen var vi tvungna att skriva om manifestet för de nya servrarna och köpa licens för 100 noder, även om vi vid den tidpunkten bara hade 85 noder.

Det tog bara två år, och vi behövde återigen göra ett stort arbete för att övergå till den nya versionen PE 2016.4. Vi köpte en licens för 300 noder, medan vi bara hade 130. Vi var återigen tvungna att göra betydande ändringar i manifestet eftersom den nya versionen av språket hade en syntax som skiljde sig från 2015 års version. I slutändan övergick vår SCM från versionshanteringssystemet SVN till Bitbucket (Git). Så var våra "relationer" med Puppet.

Så jag var tvungen att förklara för ledningen varför vi behövde övergå till ett annat SCM, med följande argument. Först och främst – den höga kostnaden för tjänsten. Jag pratade med killarna från RedHat, och de sa att kostnaden för att underhålla ett nätverk med 300 noder med Ansible Tower är hälften så hög som Puppet Enterprise. Om man också köper Ansible Engine kommer kostnaden att bli ungefär den samma, men man får betydligt fler funktioner än med PE. Eftersom vi är ett statligt företag som finansieras av federala medel är detta ett ganska tungt argument.

Det andra argumentet är mångsidigheten. Puppet stöder endast den hårdvara som har en Puppet-agent installerad. Det innebär att en agent måste installeras på alla switchar, och den måste vara den senaste versionen. Om vissa av dina switchar stöder en version, medan andra stöder en annan version, behöver du installera den nya versionen av PE-agenten på dem så att de alla kan fungera inom samma SCM-system.

Ansible Tower fungerar på ett annat sätt eftersom den inte har några agenter, men istället har den 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 också NexentaStore-nätverkslagringskontroller baserade på Illumos-kärnan – ett open-source Unix-baserat operativsystem. Det här är en mycket liten stöd, men Ansible Tower erbjuder det ändå.

Det tredje argumentet, som är mycket viktigt både för mig och vår administration, är den lätthet med vilken man kan lära sig det. Jag har under 10 år lärt mig moduler och kodmanifest för Puppet, men jag lärde mig Ansible på en vecka, eftersom det är mycket enklare att arbeta med denna SCM. Om du kör körbara filer, så länge du inte gör det utan anledning, så har de smarta och responsiva hanterare. Playbooks, som baseras på YAML, kännetecknas av att de är lätta att lära sig och snabba att använda. De som aldrig tidigare har hört talas om YAML kan helt enkelt läsa skripten och lätt förstå hur det fungerar.

Ärligt talat, gör Puppet ditt arbete som utvecklare mycket mer komplicerat eftersom det är baserat på användning av Puppet Master. Det är den enda maskinen som har rätt att kommunicera med Puppet-agenter. Om du gör 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-masterfilen /etc/hosts för att koppla alla klienter och starta Puppet Server-tjänsten. Endast efter detta kan du testa nätverksutrustningen på en värd. Det är en ganska smärtsam process.
I Ansible är allt mycket enklare. Allt du behöver göra är att utveckla koden för den maskin som kan kommunicera via SSH-protokollet med den testade värden. Det är mycket lättare att arbeta med det.

Nästa stora fördel med Ansible Tower är möjligheten att använda ditt befintliga supportsystem och bevara den nuvarande hårdvarukonfigurationen. Denna SCM använder utan några extra åtgärder all information du har om din infrastruktur och utrustning, virtuella maskiner, servrar, etc. Den kan kommunicera med dina RH Satellite-servrar, om sådana finns, och ger dig en integration som du aldrig kommer att få när du arbetar med Puppet.

En annan viktig sak är att ha detaljerad kontroll. Du vet att Puppet är ett modulärt system, det är en klient-serverapplikation, så du måste definiera de existerande aspekterna av alla dina maskiners arbete i en lång manifestfil. Vid detta tillfälle måste varje enskild del av systemet testas var trettionde minut – det är standardperioden. Så här fungerar Puppet.

Tower befriar dig från detta. Du kan utan begränsningar utföra de mest varierande processerna på den mest olika hårdvaran, du kan göra det grundläggande arbetet, starta andra viktiga processer, konfigurera säkerhetssystemet, arbeta med databaser. Du kan göra allt som är kopplat till vissa svårigheter inom Puppet Enterprise. Så, om du har gjort en konfiguration på en värd, tar det tid för förändringarna att träda i kraft på de andra värdarna. I Ansible träder alla förändringar i kraft samtidigt.

Slutligen, låt oss se på säkerhetsmodulen. I Ansible Tower är den implementerad på ett fantastiskt sätt, med stor noggrannhet och försiktighet. Du kan ge användare access till specifika tjänster eller till specifika värdar. Jag gör så med mina anställda, som är vana vid att arbeta på Windows, genom att begränsa deras tillgång till Linux-skalet. Jag ger dem sådan tillgång till Tower att de endast kan utföra det arbete och starta de tjänster som ligger inom deras kompetens.

Låt oss gå igenom de saker som behöver göras i förväg för att underlätta övergången till Ansible Tower. Först och främst måste du förbereda din hårdvara. Om vissa delar av din infrastruktur saknas i databasen, behöver de läggas till där. Det finns system som inte ändrar sina egenskaper och därför saknas i Puppet-databasen, men om du inte lägger till dem före övergången till Tower, kommer du att gå miste om en rad fördelar. Det kan vara en "smutsig" preliminär databas, men den måste innehålla information om all hårdvara du har. Därför bör du skriva ett dynamiskt hårdvaruskript som automatiskt kommer att göra alla ändringar i infrastrukturen i databasen, så att Ansible vet vilka värdar som ska finnas i det nya systemet. Du behöver inte informera denna SCM om vilka värdar du har lagt till och vilka som inte längre existerar, eftersom allt detta kommer den att lära sig automatiskt. Ju mer data som finns i databasen, desto mer användbar och flexibel blir Ansible. Den fungerar som om den helt enkelt läser av databasen för att få en statuskod för hårdvaran.

Ta dig tid att lära dig att arbeta med kommandoraden i Ansible. Kör specialkommandon 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 passar. Försök att skriva en roll och ett skript för en komplex flertrapsprocess med en standardkonfiguration av hårdvara som ofta förekommer. Låt dig leka med dessa saker, testa hur det fungerar. På så sätt lär du dig att arbeta med verktyg för att skapa bibliotek som används i Tower. Jag har redan nämnt att det tog mig cirka 3 månader att förbereda övergången. Jag tror att baserat på min erfarenhet kommer du att kunna göra det snabbare. Tänk inte på den här tiden som förlorad, för senare kommer du att känna alla fördelar med det arbete som gjorts.

Därefter måste du bestämma vad du förväntar dig av Ansible Tower, vad just detta system ska göra för dig.

Behöver du implementera systemet på tom hårdvara eller på tomma virtuella maskiner? Eller vill du behålla de ursprungliga driftsförhållandena och inställningarna för den befintliga hårdvaran? Detta är en mycket viktig aspekt för statliga företag, så du måste vara säker på att du kan genomföra migrationen och implementera Ansible på den nuvarande konfigurationen. Bestäm de rutinmässiga administrativa processer som du vill automatisera. Ta reda på om du behöver implementera specifika applikationer och tjänster på det nya systemet. Gör en lista över vad du vill göra och prioritera.

Gå sedan vidare med att skriva koden för skripten och rollerna som kommer att utföra de uppgifter du har planerat. Organisera dem i Projects, en logisk samling av motsvarande playbook-skript. Varje Project kommer att hänvisa till ett separat Git-repositorie eller annat repository beroende på vilken kodhanterare du använder. Du kan hantera playbook-skript och kataloger genom att placera dem manuellt i Project Base Path på Tower-servern, eller placera playbook i något versionshanteringssystem (SCM) som stöds av Tower, inklusive Git, Subversion, Mercurial och Red Hat Insights. Inom ett och samma Project kan du placera hur många skript du vill. Till exempel skapade jag ett grundläggande Project där jag placerade skript för RedHat:s huvudkomponenter, skript för Linux-grunden och skript för andra grundläggande indikatorer. På så sätt innehöll ett och samma projekt olika roller och skript som hanterades från ett enda Git-repositorie.

Kör allt detta via kommandoraden, det är ett bra sätt att kontrollera att de fungerar. På så sätt förbereder du dig för att installera Tower.

Låt oss prata lite om transkodning av Puppet-manifestet, för jag har spenderat mycket tid på detta innan jag insåg vad som verkligen behövdes.

Som jag redan nämnt lagrar Puppet alla inställningar och hårdvaruparametrar i en lång manifestfil, och i denna manifestfil finns allt som denna SCM ska göra. Vid övergången behöver du inte trycka in alla dina uppgifter i en lista; istället bör du tänka på strukturen i det nya systemet: roller, scenarier, taggar, grupper och vad som bör ingå där. Vissa av nätverkskomponenterna bör samlas i grupper, för vilka du kan skapa scenarier. Mer komplexa infrastrukturkomponenter som använder många resurser, inklusive autonoma klasser, kan samlas i roller. Innan migreringen måste du bestämma 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

Skär bort trådarna: övergång från Puppet Enterprise till Ansible Tower. Del 2

Lite reklam 🙂

Tack för att ni stannar kvar hos oss. Gillar ni våra artiklar? Vill ni se fler intressanta material? Stöd oss genom att göra en beställning eller rekommendera oss till era vänner, moln-VPS för utvecklare från $4,99, en unik motsvarighet till entry-level servrar som vi har skapat för er: Allt om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur man korrekt delar en server? (alternativ med RAID1 och RAID10 finns tillgängliga, upp till 24 kärnor och upp till 40GB DDR4).

Dell R730xd är två gånger billigare i datacentret Equinix Tier IV i Amsterdam? Bara hos oss 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100TB från $199 i Nederländerna! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — från $99! Läs om Hur man bygger en företagsinfrastruktur med Dell R730xd E5-2650 v4-servrar som kostar 9000 euro för en bråkdel?

Källa: habr.com