De Nationale Informatie Dienst voor Satellietgegevens over het Milieu (NESDIS) heeft haar kosten voor het beheer van de configuratie van Red Hat Enterprise Linux (RHEL) met 35% verlaagd door over te stappen van Puppet Enterprise naar Ansible Tower. In deze video uit de categorie 'hoe we het deden' legt systeemingenieur Michael Rau de redenen voor deze migratie uit, deelt nuttige tips en ervaringen die hij heeft opgedaan tijdens de overstap van de ene SCM naar de andere.
In deze video leert u:
- hoe u het management overtuigt van de voordelen van de overstap van Puppet Enterprise naar Ansible Tower;
- welke strategieën te gebruiken voor een zo soepel mogelijke overgang;
- tips voor het transcoderen van PE-manifesten naar Ansible Playbook;
- aanbevelingen voor de optimale installatie van Ansible Tower.
Hallo allemaal, mijn naam is Michael Rau, ik ben senior systeemingenieur bij ActioNet, dat werkt voor het National Oceanic and Atmospheric Administration (NOAA) NESDIS. Vandaag zullen we het hebben over string trimming – mijn persoonlijke ervaring met de migratie van Puppet Enterprise naar Ansible Tower. Het onderwerp van deze presentatie is om 'mijn littekens te laten zien' die zijn achtergebleven na mijn overstap eerder dit jaar. Ik wil delen wat ik heb geleerd tijdens dit proces. Dus wanneer je zoiets aanpakt, gebruik mijn ervaring om de overstap eenvoudiger te maken.
Je ziet dia's zoals deze aan het begin van elke presentatie op Ansible Fest. Deze dia beschrijft het automatiseringsverhaal van mijn bedrijf. Ik ben geen nieuweling, want ik gebruik Puppet/Puppet Enterprise sinds 2007. Ik begon met Ansible in 2016, en net als veel andere gebruikers van dit product werd ik aangetrokken door de 'tricks' die mogelijk zijn met de commandoregel en de eenvoudige scripts (playbooks). Eind 2017 benaderde ik mijn management met sterke argumenten voor de overstap naar Ansible Tower. Over een minuut zal ik de redenen delen die mij hebben aangespoord deze stap te zetten. Na de goedkeuring van het management duurde het nog enkele maanden om de plannen te realiseren, en ik voltooide de overstap in januari-februari van dit jaar. Dus we hebben volledig afscheid genomen van Puppet ten gunste van Ansible, en dat is een geweldige zaak.
Wat mij het meest aanspreekt in Ansible is de mogelijkheid om rollen en playbooks te schrijven en te gebruiken. Rollen zijn uitstekend voor het creëren van verschillende, maar onderling verwante taken en het centraliseren van alle gegevens die aan deze taken zijn gerelateerd. Een playbook is een YAML-syntaxis, een scripts-bestand dat acties beschrijft voor een of meerdere hosts. Ik leg deze mogelijkheden uit aan gebruikers, vooral aan softwareontwikkelaars. Ansible Tower biedt de mogelijkheid om te zeggen: 'nee, jullie hebben geen toegang tot shell-toegang, maar ik geef jullie de mogelijkheid om alle Tower-processen te starten en de service opnieuw op te starten wanneer dat nodig is.' Ik zal je vertellen over de werkomgeving en de apparatuur die we gebruiken.
Dit is een federale LAN, 7 fysieke locaties verbonden via een cloud-based MPLS, 140 RHEL-servers, waarvan 99% virtueel is (vSphere), SuperMicro-hardware, NexentaStore-netwerkopslag, een set switches van Cisco, Arista en Cumulus, en Fortinet UTM-oplossingen voor unified threat management op elke locatie.
Een federale netwerkinfrastructuur betekent dat ik alle informatiebeveiligingsmiddelen moet gebruiken die door de wetgeving zijn voorgeschreven. Je moet je realiseren dat Puppet Enterprise niet veel van onze hardware ondersteunt. We zijn gedwongen om budgethardware te gebruiken, aangezien overheidsinstanties problemen hebben met de financiering van deze uitgaven. Daarom kopen we SuperMicro klasse hardware en assembleren we onze uitrusting uit afzonderlijke onderdelen, waarvan het onderhoud wordt gegarandeerd door overheidscontracten. We gebruiken Linux, en dit is een van de belangrijkste redenen voor de overstap naar Ansible.
Onze ervaring met Puppet is als volgt.
In 2007 hadden we een klein netwerk van 20-25 knooppunten, waar we Puppet op implementeerden. Deze knooppunten waren voornamelijk gewoon RedHat 'dozen'. In 2010 begonnen we de webinterface Puppet Dashboard te gebruiken voor 45 knooppunten. Terwijl het netwerk bleef groeien, stapten we in 2014 over naar PE 3.3, waarbij we een volledige overgang maakten door het manifest voor 75 knooppunten opnieuw te schrijven. Dit was nodig omdat Puppet graag de spelregels verandert, en in dit geval veranderden ze de taal volledig. Een jaar later, toen de ondersteuning voor versie 3 van Puppet Enterprise stopte, moesten we migreren naar PE 2015.2. We moesten het manifest opnieuw herschrijven voor de nieuwe servers en een licentie met een marge voor 100 knooppunten aanschaffen, hoewel we op dat moment slechts 85 knooppunten hadden.
Na slechts 2 jaar moesten we opnieuw een grote overstap maken naar de nieuwe versie PE 2016.4. We kochten een licentie voor 300 knooppunten, terwijl we er slechts 130 hadden. We moesten opnieuw aanzienlijke wijzigingen in het manifest aanbrengen, omdat de nieuwe versie van de taal een andere syntaxis had dan die van 2015. Uiteindelijk stapte onze SCM over van het versiebeheersysteem SVN naar Bitbucket (Git). Dat zijn onze ‘relaties’ met Puppet.
Dus ik moest het management uitleggen waarom we naar een andere SCM moesten overstappen met de volgende argumenten. Het eerste argument is de hoge prijs van de dienst. Ik sprak met de mensen van RedHat en zij zeiden dat de kosten voor het onderhouden van een netwerk van 300 knooppunten met Ansible Tower de helft zijn van de kosten van Puppet Enterprise. Als je ook Ansible Engine aanschaft, zullen de kosten ongeveer gelijk zijn, maar krijg je veel meer functies dan bij PE. Aangezien we een overheidsbedrijf zijn dat gefinancierd wordt uit het federale budget, is dit een behoorlijk zwaarwegend argument.
Het tweede argument is de veelzijdigheid. Puppet ondersteunt alleen die hardware waarop de Puppet-agent beschikbaar is. Dit betekent dat op alle switches de agent moet worden geïnstalleerd, en deze moet de laatste versie zijn. En als een deel van je switches de ene versie ondersteunt en een ander deel een andere versie, moet je de nieuwe versie van de PE-agent op hen 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 de NexentaStore-netwerkopslagcontrollers, gebaseerd op de Illumos-kern - een open-source Unix-gebaseerd besturingssysteem. Dit is een zeer beperkte ondersteuning, maar Ansible Tower biedt het nog steeds.
Het derde argument, dat zowel voor mij als voor onze administratie zeer belangrijk is, is de gebruiksvriendelijkheid. Ik heb 10 jaar lang gewerkt met modules en manifestcode voor Puppet, maar ik leerde Ansible in een week, omdat deze SCM veel gemakkelijker te gebruiken is. Als je uitvoerbare bestanden draait, en natuurlijk als je dat niet onnodig doet, dan werken ze met redelijke en responsieve handlers. Playbook-scripts, gebaseerd op YAML, zijn gemakkelijk 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 ingewikkelder, omdat het gebaseerd is op het gebruik van Puppet Master. Dit is de enige machine die het recht heeft om te communiceren met Puppet-agents. Als je wijzigingen aanbrengt in een manifest en je wilt je code testen, moet je de code herschrijven voor de Puppet Master, dat wil zeggen het Puppet Master-bestand /etc/hosts configureren om verbinding te maken met alle clients en de Puppet Server-service starten. Pas daarna kun je de werking van de netwerkinfrastructuur op één host testen. Dit is een behoorlijk pijnlijke procedure.
Bij Ansible is alles veel eenvoudiger. Alles wat je hoeft te doen, is code ontwikkelen voor een machine die via SSH verbinding kan maken met de te testen host. Dit is veel gemakkelijker te beheren.
Een andere grote plus van Ansible Tower is de mogelijkheid om al je bestaande ondersteuningssystemen te gebruiken en de huidige hardwareconfiguratie te behouden. Deze SCM maakt gebruik van alle beschikbare informatie over jouw infrastructuur en apparatuur, virtuele machines, servers, enz. zonder extra stappen. Het kan communiceren met je RH Satellite-servers, indien aanwezig, en biedt je een integratie die je nooit zult krijgen wanneer je met Puppet werkt.
Een andere belangrijke zaak is gedetailleerde controle. U weet dat Puppet een modulaire systeem is, een client-server toepassing, dus u moet de bestaande aspecten van het werk van al uw machines in één lange manifest definiëren. Daarbij moet de staat van elk afzonderlijk systeemonderdeel elke dertig minuten worden getest – dat is de standaardperiode. Zo werkt Puppet.
Tower bevrijdt u daarvan. U kunt onbeperkt verschillende processen uitvoeren op de meest uiteenlopende hardware, u kunt belangrijke werkzaamheden uitvoeren, andere belangrijke processen starten, het beveiligingssysteem configureren, met databases werken. U kunt alles doen wat in Puppet Enterprise met bepaalde moeilijkheden is verbonden. Als u bijvoorbeeld configuratie op één host hebt uitgevoerd, kost het tijd voordat de wijzigingen op de andere hosts van kracht worden. In Ansible worden alle wijzigingen tegelijkertijd van kracht.
Tot slot, laten we de beveiligingsmodule bekijken. In Ansible Tower is deze gewoon geweldig geïmplementeerd, met grote precisie en zorgvuldigheid. U kunt gebruikers toegang geven tot specifieke services of specifieke hosts. Ik ga zo te werk met mijn medewerkers, die gewend zijn om op Windows te werken, door hun toegang tot de Linux-shell te beperken. Ik zorg ervoor dat ze toegang hebben tot Tower, zodat ze alleen het werk kunnen uitvoeren en de services kunnen starten die binnen hun expertise vallen.
Laten we de dingen bekijken die u van tevoren moet doen om de overstap naar Ansible Tower te vergemakkelijken. Allereerst moet u uw hardware voorbereiden. Als bepaalde onderdelen van uw infrastructuur nog niet in de database staan, moeten ze daar worden toegevoegd. Er zijn systemen waarvan de specificaties niet veranderen en die daarom ontbreken in de Puppet-database, maar als u ze niet vóór de overstap naar Tower toevoegt, mist u verschillende voordelen. Dit kan een 'rommelige', voorlopige database zijn, maar deze moet wel informatie bevatten over al uw aanwezige apparatuur. Daarom moet u een dynamisch hardware-script schrijven dat automatisch alle wijzigingen in de infrastructuur in de database vastlegt, zodat Ansible weet welke hosts in het nieuwe systeem moeten staan. U hoeft deze SCM niet te vertellen welke hosts u hebt toegevoegd en welke niet meer bestaan, omdat dat alles automatisch zal worden gedetecteerd. Hoe meer gegevens er in de database staan, hoe nuttiger en flexibeler Ansible zal zijn. Het werkt alsof het simpelweg de status van de hardware uit de database leest.
Neem de tijd om vertrouwd te raken met het gebruik van de command line in Ansible. Voer een paar speciale opdrachten uit om de werking van het hardware-script te testen, schrijf en voer een paar eenvoudige maar nuttige playbook-scenario's uit en gebruik Jinja2-sjablonen waar het past. Probeer een rol en een script te schrijven voor een complex meervoudig proces, met behulp van een standaard configuratie van veelvoorkomende hardware. Experimenteer met deze zaken en test hoe het werkt. Op deze manier leert u werken met de tools voor het maken van bibliotheken die in Tower worden gebruikt. Ik heb al eerder gezegd dat mijn voorbereiding op de overstap ongeveer 3 maanden in beslag nam. Ik denk dat u, baat hebbend bij mijn ervaring, dit sneller kunt doen. Beschouw die tijd niet als verloren, want later zult u de voordelen van uw inspanningen merken.
Vervolgens moet u beslissen wat u van Ansible Tower verwacht, wat deze specifieke systeem voor u moet doen.
Heeft u een systeemimplementatie nodig op lege hardware of op lege virtuele machines? Of wilt u de oorspronkelijke werkomstandigheden en instellingen van de bestaande hardware behouden? Dit is een zeer belangrijk aspect voor de werking van overheidsbedrijven, dus u moet er zeker van zijn dat u de migratie kunt uitvoeren en Ansible op de bestaande configuratie kunt implementeren. Bepaal de routinematige administratieve processen die u wilt automatiseren. Onderzoek of u specifieke toepassingen en diensten op het nieuwe systeem wilt implementeren. Maak een lijst van wat u wilt doen en stel prioriteiten.
Begin vervolgens met het schrijven van de script- en rolcode die de taken die u hebt gepland zal uitvoeren. Groepeer ze in Projects, een logische verzameling van de bijbehorende playbook-scripts. Elk Project komt overeen met een afzonderlijke Git-repository of een andere repository, afhankelijk van welke codebeheerder u gebruikt. U kunt playbook-scripts en catalogi beheren door ze handmatig in Project Base Path op de Tower-server te plaatsen, of door playbooks in elk systeem voor broncodebeheer (SCM) te plaatsen dat door Tower wordt ondersteund, inclusief Git, Subversion, Mercurial en Red Hat Insights. Binnen één Project kunt u zoveel scripts plaatsen als u wilt. Bijvoorbeeld, ik heb één basis Project aangemaakt waarin ik een script voor de basiscomponenten van RedHat, een script voor de basis van Linux en scripts voor de andere basisparameters heb geplaatst. Zo waren er in één project verschillende rollen en scripts die vanuit één Git-repository werden beheerd.
Voer al deze dingen via de commandoregel uit, dit is een goede manier om hun werking te controleren. Op deze manier bereidt u zich voor op de installatie van Tower.
Laten we een beetje praten over de transcodering van het Puppet-manifest, want ik heb hier veel tijd aan besteed voordat ik me realiseerde wat ik echt moest doen.
Zoals ik al zei, slaat Puppet alle instellingen en hardwareparameters op in een lange manifest, en in dit manifest staat alles wat deze SCM moet doen. Bij de overgang hoeft u niet al uw taken in één lijst te dwingen; in plaats daarvan kunt u nadenken over de structuur van het nieuwe systeem: rollen, scenario's, tags, groepen en wat daarin moet komen. Sommige van de autonome netwerk-elementen moeten worden samengevoegd in groepen waarvoor scenario's kunnen worden gemaakt. Complexere infrastructuurelementen, die veel middelen vereisen, inclusief autonome klassen, kunnen worden samengevoegd in rollen. U moet dit bepalen voordat u migreert. Als u omvangrijke rollen of scenario's aanmaakt die niet op één scherm passen, moet u tags gebruiken om afzonderlijke delen van de infrastructuur vast te leggen.
18:00
Een beetje reclame 🙂
Bedankt dat je bij ons blijft. Houd je van onze artikelen? Wil je meer interessante inhoud zien? Ondersteun ons door een bestelling te plaatsen of ons aan vrienden aan te bevelen, , een unieke variant van entry-level servers, die we voor jou hebben bedacht: (opties beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).
Dell R730xd is 2 keer goedkoper in datacenter Equinix Tier IV in Amsterdam? Alleen bij ons in Nederland! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — vanaf $99! Lees over hoe
Bron: habr.com
