De National Environmental Satellite Data Information Service (NESDIS) heeft de kosten voor configuratiebeheer voor Red Hat Enterprise Linux (RHEL) met 35% verlaagd door te migreren van Puppet Enterprise naar Ansible Tower. In deze video 'hoe we het hebben gedaan' legt systeemingenieur Michael Rau de argumenten voor deze migratie uit, waarbij hij nuttige tips en lessen deelt die zijn geleerd bij de overstap van de ene SCM naar de andere.
Uit deze video leer je:
- hoe het management de haalbaarheid van de overstap van Puppet Enterprise naar Ansible Tower kan rechtvaardigen;
- welke strategieën moeten worden gebruikt om de overgang zo soepel mogelijk te laten verlopen;
- tips voor het transcoderen van PE-manifesten naar Ansible Playbook;
- Aanbevelingen voor een optimale installatie van Ansible Tower.
Hallo allemaal, mijn naam is Michael Rau, ik ben Senior Systems Engineer bij ActioNet, dat werkt voor de NESDIS-service van de National Oceanic and Atmospheric Administration (NOAA). Vandaag zullen we het hebben over het trimmen van snaren - mijn eigen ervaring met het migreren van Puppet Enterprise naar Ansible Tower. Het thema van deze presentatie is ‘kijk eens naar mijn littekens’ die ik heb achtergelaten nadat ik eerder dit jaar deze transitie had gemaakt. Ik wil delen wat ik tijdens dit proces heb geleerd. Dus als je zoiets op je neemt, kun je, gebruikmakend van mijn ervaring, de overstap maken zonder extra werk.
Je ziet soortgelijke dia's aan het begin van elke presentatie op Ansible Fest. Deze dia schetst de geschiedenis van de automatisering van mijn bedrijf. Ik ben hier niet nieuw in, want ik gebruik Puppet/Puppet Enterprise sinds 2007. Ik begon in 2016 met Ansible te werken en net als veel andere gebruikers van dit product werd ik aangetrokken door de mogelijkheid van “trucs” met behulp van de opdrachtregel en eenvoudige scripts (playbooks). Eind 2017 heb ik mijn management benaderd over de sterke redenen om naar Ansible Tower te verhuizen. Binnenkort zal ik u vertellen over de redenen die mij ertoe hebben aangezet deze stap te zetten. Nadat ik toestemming van het management had gekregen, duurde het nog een aantal maanden om het plan te voltooien, en ik heb de overstap gemaakt in januari-februari van dit jaar. Dus we hebben Puppet volledig verlaten ten gunste van Ansible, en dat is iets geweldigs.
Wat mij het meest aanspreekt aan Ansible is het vermogen om rollen en draaiboeken te schrijven en te gebruiken. Rollen zijn ideaal voor het maken van afzonderlijke, maar gerelateerde taken en het op één plek plaatsen van alle gegevens die verband houden met die taken. Een playbook is een YAML-syntaxis, een scriptbestand dat acties voor een of meer hosts beschrijft. Ik vertel gebruikers over deze functies, voornamelijk softwareontwikkelaars. Ansible Tower geeft je de mogelijkheid om te zeggen: "Nee, je hebt geen shell-toegang, maar ik geef je de mogelijkheid om alle Tower-processen uit te voeren en de service opnieuw te starten wanneer je die nodig hebt." Ik vertel je over de werkomgeving en de apparatuur die we gebruiken.
Dit is een federaal LAN, 7 fysieke locaties verbonden via cloud-MPLS, 140 RHEL-servers, waarvan 99% virtueel (vSphere), SuperMicro-hardware, NexentaStore-netwerkopslag, een set Cisco-, Arista- en Cumulus-switches en Fortinet UTM unified threat management hulpmiddelen op elke site.
Het federale netwerk betekent dat ik alle informatiebeveiligingsmaatregelen moet gebruiken waarin de wet voorziet. Houd er rekening mee dat Puppet Enterprise de meeste hardware die we gebruiken niet ondersteunt. We zijn genoodzaakt budgethardware in te zetten omdat overheidsinstanties problemen hebben met de financiering van deze kostenpost. Daarom kopen wij SuperMicro-hardware en stellen wij onze apparatuur samen uit losse onderdelen, waarvan het onderhoud door overheidscontracten wordt gegarandeerd. Wij gebruiken Linux en dit is een van de belangrijke redenen om over te stappen naar Ansible.
Onze geschiedenis met Puppet is als volgt.
In 2007 hadden we een klein netwerk van 20-25 knooppunten, waarin we Puppet hebben ingezet. Kortom, deze knooppunten waren slechts RedHat-"boxen". In 2010 zijn we begonnen met het gebruik van de Puppet Dashboard-webinterface voor 45 knooppunten. Terwijl het netwerk bleef uitbreiden, zijn we in 2014 overgestapt op PE 3.3, waarbij we een volledige transitie doormaakten met een manifestherschrijving voor 75 knooppunten. Dit moest gebeuren omdat Puppet graag de spelregels verandert, en in dit geval hebben ze de taal volledig veranderd. Een jaar later, toen de ondersteuning voor versie 3 van Puppet Enterprise eindigde, werden we gedwongen te migreren naar PE 2015.2. We moesten het manifest opnieuw schrijven voor de nieuwe servers en een licentie aanschaffen met een reserve van 100 knooppunten, hoewel we op dat moment slechts 85 knooppunten hadden.
Er zijn slechts 2 jaar verstreken en we hebben opnieuw veel werk moeten verzetten om naar de nieuwe versie PE 2016.4 te migreren. We kochten een licentie voor 300 knooppunten, met slechts 130. We moesten opnieuw grote wijzigingen aanbrengen in het manifest omdat de nieuwe versie van de taal een andere syntaxis had dan de taal van de versie uit 2015. Als gevolg hiervan is onze SCM overgestapt van SVN-versiebeheer naar Bitbucket (Git). Dit was onze “relatie” met Puppet.
Ik moest dus aan het management uitleggen waarom we naar een andere SCM moesten overstappen, met behulp van de volgende argumenten. De eerste is de hoge prijs van de dienst. Ik sprak met de jongens van RedHat en zij zeiden dat de kosten voor het runnen van een netwerk met 300 knooppunten met Ansible Tower de helft bedragen van de kosten van Puppet Enterprise. Als u ook Ansible Engine aanschaft, zijn de kosten ongeveer hetzelfde, maar krijgt u veel meer functies dan PE. Aangezien we een staatsbedrijf zijn dat gefinancierd wordt uit de federale begroting, is dit een behoorlijk krachtig argument.
Het tweede argument is veelzijdigheid. Puppet ondersteunt alleen hardware met een Puppet-agent. Dit betekent dat er op alle switches een agent geïnstalleerd moet zijn, en dat deze de laatste versie moet zijn. En als sommige van uw switches de ene versie ondersteunen, en andere een andere, moet u er een nieuwe versie van de PE-agent op installeren, zodat ze allemaal in hetzelfde SCM-systeem kunnen werken.
Het Ansible Tower-systeem werkt anders omdat het geen agents heeft, maar wel modules die Cisco-switches en alle andere switches ondersteunen. Deze SCM ondersteunt Qubes OS, Linux en 4.NET UTM. Ansible Tower ondersteunt ook NexentaStore-netwerkopslagcontrollers op basis van de Illumos-kernel, een open-source Unix-gebaseerd besturingssysteem. Dit is heel weinig ondersteuning, maar Ansible Tower doet het toch.
Het derde argument, dat zowel voor mij als voor onze administratie erg belangrijk is, is gebruiksgemak. Ik heb 10 jaar besteed aan het beheersen van Puppet-modules en manifestcode, maar ik leerde Ansible binnen een week omdat deze SCM veel gemakkelijker is om mee te werken. Als u uitvoerbare bestanden uitvoert, werken er uiteraard intelligente en responsieve handlers mee, tenzij u dit onnodig doet. Op YAML gebaseerde draaiboeken zijn eenvoudig te leren en snel te gebruiken. Degenen die nog nooit van YAML hebben gehoord, kunnen eenvoudig de scripts lezen en gemakkelijk begrijpen hoe het werkt.
Eerlijk gezegd maakt Puppet je werk als ontwikkelaar veel moeilijker omdat het gebaseerd is op het gebruik van Puppet Master. Het is de enige machine die mag communiceren met Puppet-agenten. Als u wijzigingen in het manifest heeft aangebracht en uw code wilt testen, moet u de code voor Puppet Master herschrijven, dat wil zeggen, het bestand Puppet Master /etc/hosts configureren om alle clients te verbinden en de Puppet Server-service te starten. Pas daarna kunt u de werking van netwerkapparatuur op één host testen. Dit is een nogal pijnlijke procedure.
Alles is veel eenvoudiger in Ansible. Het enige wat u hoeft te doen is code ontwikkelen voor een machine die via SSH kan communiceren met de te testen host. Dit is veel gemakkelijker om mee te werken.
Het volgende grote voordeel van Ansible Tower is de mogelijkheid om uw bestaande ondersteuningssysteem te benutten en uw bestaande hardwareconfiguratie te behouden. Deze SCM gebruikt alle beschikbare informatie over uw infrastructuur en hardware, virtuele machines, servers, etc. zonder enige extra stappen. Het kan met uw RH Satellite-servers praten, als u die heeft, en biedt u integraties die u met Puppet nooit zult krijgen.
Een ander belangrijk ding is gedetailleerde controle. U weet dat Puppet een modulair systeem is, het is een client-server-applicatie, dus u moet de bestaande aspecten van al uw machines in één lang manifest definiëren. In dit geval moet de status van elk afzonderlijk element van het systeem elk half uur worden getest - dit is de standaardperiode. Dit is hoe Marionet werkt.
Tower redt je daarvan. U kunt zonder beperkingen allerlei processen op allerlei apparatuur uitvoeren; u kunt basiswerk doen, andere belangrijke processen uitvoeren, een beveiligingssysteem opzetten en met databases werken. In Puppet Enterprise kun je alles doen wat moeilijk is. Als u het dus op één host heeft geconfigureerd, zal het enige tijd duren voordat de wijzigingen van kracht worden op de overige hosts. In Ansible worden alle wijzigingen tegelijkertijd van kracht.
Laten we tot slot eens kijken naar de beveiligingsmodule. Ansible Tower implementeert het eenvoudigweg verbazingwekkend, met grote precisie en zorg. U kunt gebruikers toegang verlenen tot specifieke services of tot specifieke hosts. Dit doe ik met mijn medewerkers die gewend zijn om op Windows te werken, waardoor hun toegang tot de Linux-shell wordt beperkt. Ik zorg ervoor dat zij toegang hebben tot Tower zodat zij alleen het werk kunnen doen en alleen de diensten kunnen draaien die voor hen relevant zijn.
Laten we eens kijken naar de dingen die u van tevoren moet doen om uw overstap naar Ansible Tower gemakkelijker te maken. Allereerst moet u uw apparatuur voorbereiden. Als sommige elementen van uw infrastructuur nog niet in de database staan, moet u ze daar toevoegen. Er zijn systemen die hun kenmerken niet veranderen en daarom niet in de Puppet-database staan, maar als je ze daar niet toevoegt voordat je naar Tower verhuist, verlies je een aantal voordelen. Dit kan een “vieze”, voorlopige database zijn, maar deze moet informatie bevatten over alle apparatuur die u heeft. Daarom moet u een dynamisch hardwarescript schrijven dat automatisch alle infrastructuurwijzigingen in de database pusht, zodat Ansible weet welke hosts op het nieuwe systeem aanwezig moeten zijn. U hoeft deze SCM niet te vertellen welke hosts u heeft toegevoegd en welke hosts niet meer bestaan, omdat hij dit allemaal automatisch weet. Hoe meer gegevens er in de database staan, hoe nuttiger en flexibeler Ansible zal zijn. Het werkt alsof het eenvoudigweg de hardwarestatusbarcode uit een database leest.
Besteed wat tijd aan het vertrouwd raken met de opdrachtregel in Ansible. Voer enkele aangepaste opdrachten uit om het hardwarescript te testen, schrijf en voer enkele eenvoudige maar nuttige playbook-scripts uit en gebruik waar nodig Jinja2-sjablonen. Probeer een rol en script te schrijven voor een complex, uit meerdere stappen bestaand proces met behulp van een veel voorkomende hardwareconfiguratie. Speel met deze dingen, test hoe het werkt. Op deze manier leert u hoe u de tools voor het maken van bibliotheken kunt gebruiken die in Tower worden gebruikt. Ik heb al gezegd dat het me ongeveer 3 maanden kostte om me voor te bereiden op de transitie. Ik denk dat je, op basis van mijn ervaring, dit sneller zult kunnen doen. Beschouw deze tijd niet als verloren tijd, want later zult u alle voordelen van het verrichte werk ervaren.
Vervolgens moet u beslissen wat u van Ansible Tower verwacht, wat dit systeem precies voor u moet doen.
Moet u het systeem implementeren op kale hardware, op kale virtuele machines? Of wilt u de oorspronkelijke bedrijfsomstandigheden en instellingen van bestaande apparatuur behouden? Dit is een zeer belangrijk aspect voor openbare bedrijven, dus u moet er zeker van zijn dat u Ansible kunt migreren en implementeren op uw bestaande configuratie. Identificeer routinematige administratieve processen die u wilt automatiseren. Ontdek of u specifieke applicaties en services op het nieuwe systeem moet implementeren. Maak een lijst van wat u wilt doen en stel prioriteiten.
Begin vervolgens met het schrijven van scriptcode en rollen die de taken mogelijk maken die u wilt voltooien. Combineer ze in Projecten, een logische verzameling relevante draaiboeken. Elk project behoort tot een afzonderlijke Git-repository of een andere repository, afhankelijk van welke codemanager u gebruikt. U kunt playbook-scripts en playbook-mappen beheren door ze handmatig in het Project Base Path op de Tower-server te plaatsen, of door het playbook in een door Tower ondersteund broncodebeheersysteem (SCM) te plaatsen, waaronder Git, Subversion, Mercurial en Red Hat Inzichten. Binnen één Project kunt u zoveel scripts plaatsen als u wilt. Ik heb bijvoorbeeld één basisproject gemaakt waarin ik een script voor de RedHat-kernelementen, een script voor de Linux-kern en scripts voor de rest van de basislijnen plaatste. In één project waren er dus verschillende rollen en scenario's die vanuit één Git-repository werden beheerd.
Al deze dingen via de opdrachtregel uitvoeren is een goede manier om hun functionaliteit te testen. Hiermee wordt u voorbereid op de toreninstallatie.
Laten we het even hebben over het transcoderen van het Puppet-manifest, omdat ik hier veel tijd aan heb besteed totdat ik erachter kwam wat er eigenlijk moest gebeuren.
Zoals ik al eerder zei, slaat Puppet alle instellingen en hardware-opties op in één lang manifest, en dit manifest bevat alles wat deze SCM zou moeten doen. Wanneer u de overstap maakt, hoeft u niet al uw taken in één lijst te proppen; denk in plaats daarvan na over de structuur van het nieuwe systeem: rollen, scripts, tags, groepen en wat daarin moet komen. Sommige van de autonome netwerkelementen moeten worden gegroepeerd in groepen waarvoor scripts kunnen worden gemaakt. Complexere infrastructuurelementen waarbij een groot aantal bronnen betrokken zijn, inclusief op zichzelf staande klassen, kunnen in rollen worden gecombineerd. Voordat u migreert, moet u hierover beslissen. Als u grote rollen of scenario's maakt die niet op één scherm passen, moet u tags gebruiken om specifieke delen van de infrastructuur vast te leggen.
18:00
Sommige advertenties 🙂
Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, , een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over
Bron: www.habr.com