Ansible

Veranderende IT omgeving

Vroeger was alles overzichtelijk ;) Ooit had je als organisatie maar weinig servers te beheren. Misschien een mainframe voor je transacties, een fileserver op kantoor, of een webserver waar 1 of 2 websites op draaiden. Als beheerder installeerde je netjes het Operating System (vanaf floppies of CD-ROM) en na installatie logde je netjes in om alles af te configureren. En als je een mail kreeg dat er een patch was uitgebracht, logde je weer eens in (wat was het wachtwoord ook alweer?), ging je de updates downloaden (op welke site stonden die ook alweer?) en voerde je die uit (hoe draai je ook alweer een update en moet ik dan rebooten?). Kortom: veel handmatig werk in wisselende omgevingen.

Snellere paarden?

Het aantal servers dat je als bedrijf nodig hebt groeide echter door de opkomst van internet en digitalisering. En met de introductie van Virtualisering werd het aantal servers om te beheren alleen maar meer. Handige beheerders kopieerden configuratiefiles heen- en weer, bouwden shell scripts of haalden er andere talen bij, zoals Perl of Python. Er kwamen zelfs tools op de markt waarmee je dit werk kon automatiseren (XLDeploy?). Oneerbiedig gezegd: we automatiseerden de oude, ons bekende, manier van werken.

Het enige probleem: niet alleen pakt elke organisatie alles op een andere, eigen manier aan, maar ook de beheerders zelf hebben hun eigen manier van scripts maken, servers installeren en configureren en of, hoe en wanneer updates uit te voeren, en zo ja, welke? Het over moeten nemen en aanpassen van vaak ongedocumenteerde, zelfgebouwde pogingen tot automatisering is tijdrovend, foutgevoelig en soms zelfs ronduit frustrerend. Daar moet nog een oplossing voor te vinden zijn? Henry Ford zij ooit: “Als ik de mensen gevraagd had wat ze wilden hebben, dan hadden ze ze gevraagd om snellere paarden.”

Paradigmashift

Infrastructure as Code: GitOps & Ansible

De oplossing ligt in Configuration Management en Automation Tools. Alle benodigde acties en configuraties, vastgelegd in een gestandaardiseerde en gedocumenteerde taal. Dit is ook de basis van Infrastructure as Code (IaC): het in code beschrijven van je infrastructuur en de relaties onderling. Je hebt misschien wel eens gehoord van Ansible, CFEngine, Rudder, Chef, Puppet of SaltStack. Verschillende tools, soms met een net andere aanpak, en allemaal een eigen taal. Bij HCS Company kiezen we voor Ansible. Maar waarom?

Lees ook ons blog over deze vergelijking: een korte vergelijking tussen Ansible, Chef, Puppet & Saltstack.

Wat is Ansible? Onder de motorkap...

Ansible is een Open Source Automation Tool, geschikt voor software installatie en configuratie, applicatie deployment, het configureren van servers, switches, loadbalancers, routers en nog veel meer. Je hoeft voor het gebruik van Ansible geen Agents te installeren, het werkt op basis van SSH (Secure Shell)-toegang en de programmeertaal Python. En hoewel Ansible van oudsher op UNIX/Linux achtigen is gebouwd, kun je het zelfs gebruik om Windows machines (via WinRM) te configureren. Ansible is simpel en het is snel te leren. Playbooks en roles schrijf je in de makkelijke Ansible-eigen taal die heel erg lijkt op Engels, gebaseerd op YAML (Yet Another Markup Language) en Jinja2 templates. Lees dit simpele voorbeeld maar en kijk of je begrijpt wat er hier gebeurt:

yum:
  name: httpd
state: installed
service:
  name: httpd
  state: started
  enabled: true 

Ansible Engine

De ontwikkelingen aan Ansible gaan snel, voor sommige toepassingen zelfs iets te snel. Red Hat biedt met Ansible Engine een stabiele, ondersteunde versie gebaseerd op de Open Source Community Ansible. In je Ansible Engine subscription zitten onder andere ook de Core Modules als kant-en-klare oplossing voor het aansturen van o.a. systemen, commando’s, bestanden, inventories, AWS, Windows, versiecontrole, packages (yum) en standaard netwerkacties en de mogelijkheid om op een bepaalde, stabiele versie van Ansible te blijven draaien, inclusief security- en bugfixes (i.p.v. altijd de meest recente versie geïnstalleerd te krijgen).

Aan deze brede set aan functies kunnen ook de Network Modules worden toegevoegd, zodat je ook allerlei netwerkapparatuur van o.a. Cisco, F5, Fortinet, Juniper en Palo Alto kunt configureren. Buiten deze vaste set aan modules kunnen hardware- en softwareleveranciers hun eigen Certified Modules meeleveren. En zoek je, buiten de ondersteuning van Red Hat om, toch nog naar andere functionaliteit, dan is er nog altijd het grote aanbod van de Community Modules en de Ansible Automation Hub. En zoals bij de Community versie van Ansible kun je ook nog terecht op Ansible Galaxy.

Wat is Ansible Tower?

Wil je echter de volledige kracht van Ansible benutten, dan is er Red Hat Ansible Tower, een overzichtelijke, grafische webinterface voor centrale aansturing van al je Ansible acties, gebaseerd op het Open Source project AWX. Ansible Tower haalt al je playbooks en roles uit Git, zodat altijd te zien is welke versie van je Ansible code wordt uitgevoerd.

Tower is te koppelen aan je Active Directory, IDM of LDAP directory, zodat je makkelijk gebruikers toegang kunt geven. Ook biedt het Role Base Access Control (RBAC), zodat alleen de juiste gebruikers bij de juiste projecten en acties kunnen. En met de uitgebreide logging weet je dus altijd wie, welke versie van een playbook, op welk moment, op welke servers heeft uitgevoerd. Daarmee kun je al deze geautomatiseerde stappen uit je wijzigingsproces verantwoorden, of je nou een bank, verzekeraar, overheidsinstantie, telco of een ander soort bedrijf bent. Niet langer zwerven er dus allerlei versies van een playbook rond op laptops van verschillende mensen, die vervolgens als root overal acties uitvoeren die bijna niet meer te herleiden zijn.

Aan de slag met Ansible Tower

Met de eerder genoemde features van Tower kun je je organisatie een brede set aan mogelijkheden bieden. Systeembeheerders kunnen met een druk op de knop een set servers patchen, Netwerkbeheerders kunnen snel een wijziging maken in de rulesets van hun firewalls, Applicatiebeheerders kunnen met druk op een andere knop een nieuwe versie van een applicatie deployen en Applicatieontwikkelaars kunnen op eenzelfde simpele wijze een nieuwe testserver inrichten om de allernieuwste versie van diezelfde applicatie nog even volledig door te lichten. Met behulp van webhooks kun je dit soort processen zelfs automatisch vanuit Git acties laten verlopen. En doordat in Ansible Tower alle credentials beveiligd opgeslagen kunnen worden, hoef je niet zelf belangrijke (root-)wachtwoorden of SSH-keys uit je Vault te halen om je acties uit te kunnen voeren.

Ansible Tower is schaalbaar en kan de job runs verdelen over verschillende task / worker nodes. Dit kunnen extra VM’s zijn, maar deze resources kunnen ook gehaald worden uit een OpenShift Container Platform. Voor je DMZ of extra beveiligde netwerken kun je een Tower Isolated Node inrichten, die de taken kan uitvoeren op machines die niet direct vanaf je Ansible Tower cluster bereikbaar zijn. Het enige wat er nodig is, is SSH toegang van het Tower Cluster naar de Isolated Node en toegang vanaf de Isolated Node binnen dat betreffende netwerk. Verder is Ansible Tower gebouwd rondom een centrale REST API, die je zelf ook aan kunt spreken. Op deze manier kun je alle jobs, job templates en gehele workflows programmatisch aansturen, vanuit je eigen scripts, of met behulp van de krachtige tower-cli tool. Eventuele extra variabelen, authenticatie informatie en andere opties kun je meegeven als JSON data.

Satellite en Insights

Automation doen we niet alleen met Ansible. De Red Hat Automation & Management Suite biedt ook nog andere producten om je IT platform te beheren, die allen aansluiten op Ansible. Denk aan serverprovisioning, patchmanagement, het voldoen aan afgesproken securitystandaarden en het detecteren, voorspellen of oplossen van problemen en bedreigingen.

Red Hat Satellite is de centrale tool voor het provisionen, configureren en updaten van je Red Hat Enterprise Linux platform. Niet langer halen je RHEL machines de allerlaatste updates direct van het internet, maar kies je zelf - met behulp van Content Views en Lifecycle Environments - welke servers wanneer welke versies van bepaalde packages krijgen. Zo kun je een update altijd eerst testen voordat deze naar je productieplatform gaat. Satellite is de centrale plek voor al deze software en opereert daarmee als je Standard Operating Environment. Je kunt op dezelfde manier ook software van andere leveranciers in een Custom Repository uploaden en deze gecontroleerd aan je servers aanbieden. Vanuit Satellite kun je Ansible gebruiken als Remote Execution Engine en Ansible Roles gebruiken om configuraties uit te rollen op je servers. Ansible Tower kan, aansluitend op provisioning van servers door Satellite, opvolgende acties uitvoeren en met behulp van een zogenaamde Callback de server afmelden bij Satellite.

Red Hat Insights verzamelt informatie over je Red Hat producten, zij het op bare metal, virtueel, containers, private of public cloud en voert hier grondige analyses op uit. Met behulp van de zogenaamde Predictive Analysis kan dit systeem problemen detecteren voordat ze daadwerkelijk op gaan spelen. Verouderde software, inefficiënte configuraties, de verkeerde hardware drivers, et cetera. En vaak weet Insights op basis van de beschikbare informatie een remediation playbook te genereren, die je zo via Ansible (en dus ook Ansible Tower) kunt laten uitvoeren. Let er wel op dat Insights Software as a Service (SaaS) is; de Big Data engine draait volledig bij Red Hat in de cloud.

Red Hat Insights zit al in je Red Hat Enterprise Linux subscription. En als je ook Satellite wilt gaan gebruiken, kun je simpelweg Smart Management aanschaffen voor alle RHEL systemen die je door Satellite wilt laten managen.

Hoe helpen wij je verder met je Ansible vragen?

Dankzij de lage leercurve heb je zelf redelijk snel een playbook in elkaar gezet om een package te laten installeren. Maar wat als je dat op meerdere typen servers wilt doen? En doe je dat dan met een alles-in-een playbook of verdeel je alles netjes over roles? Maak je alles dynamisch met variabelen en secrets? Hoe verdeel je je servers over hostgroups? En moet je dat dan handmatig in een inventory invullen, of haal je de lijst uit Satellite? Hoe zorg je ervoor dat Ansible een bepaalde Git-branch gebruikt op een specifieke set servers? En wat als ik van dat package de nieuwste versie eerst alleen op mijn testservers wil hebben?

Onze Automation Engineers brengen jouw huidige landschap in kaart en adviseren hoe dit te automatiseren. Natuurlijk passen we daarbij onze eigen Best Practices toe, zoals hoe een Ansible role en playbook te schrijven, naamgeving van variabelen, het geheel onder versiecontrole (Git) te plaatsen en hoe je alles het beste kunt testen.

Met Satellite kunnen we je helpen met het bouwen van Lifecycle Environments en Content Views, Provisioning Templates en Kickstartconfiguraties, het controleren op en afdwingen van OpenSCAP security profiles en het implementeren van een gestandaardiseerd patchproces, eventueel met Ansible.

En met Insights laten we je zien hoe je problemen kunt voorkomen of op kunt lossen – hoogstwaarschijnlijk met een kant en klaar Ansible Playbook! Ansible Engine en Ansible Tower zijn de ideale combinatie aan tools om je organisatie te faciliteren in de DevOps werkmethode.

Door Infrastructure as Code en GitOps kan Dev infrastructuur net zo programmatisch aansturen als de applicaties waar ze aan werken, vanuit het versiecontrolesysteem waar ze al hun code al in hadden staan. En als je Application Deployment via Ansible doet, hoeft Ops zich geen zorgen meer te maken over applicatielogica, wijzigingen in configuratiefiles of de vraag of alle code wel naar de juiste plaatsen is gekopieerd. Niet langer wachten tot Ops servers voor je heeft klaargezet, of een waterval aan gewijzigde applicaties over de muur gegooid krijgen van Dev, maar op elk niveau van je IT landschap structureel samenwerken. HCS Company helpt je met Ansible bij deze culturele omslag!

Innovatie daadwerkelijk werkend maken. We laten het je graag zien!