Red Hat implementeren: 5 valkuilen om te vermijden

Als je het tegenwoordig over open source of Linux hebt, valt al snel de naam Red Hat. Denk aan het populaire containerplatform OpenShift, automatiseringstool Ansible of systeembeheersoftware Satellite. De voordelen van een gestandaardiseerd cloudplatform, dat vanzelf meeschaalt en zich grotendeels geautomatiseerd laat beheren, zijn natuurlijk enorm. Daarmee zijn organisaties heel flexibel naar gebruikers, terwijl hun ontwikkelaars en andere techneuten geen tijd verliezen aan routinewerk. Maar zoals bij iedere technologie, zijn er ook bij Red Hat-implementaties aandachtspunten. In deze blog zetten we er vijf op een rij. 

Je hebt een uitdaging die je met een oplossing van Red Hat of van een Red Hat-partner wilt aangaan en er komt een legertje consultants je organisatie binnen om een Proof of Concept (PoC) te maken. Maar als ze weer vertrekken, heb je zelf nog niet de nodige Red Hat-kennis in huis om te gaan bouwen. Je medewerkers weten niet hoe ze de bedachte oplossing moeten neerzetten en de handleiding van Red Hat brengt helaas geen soelaas. Daarin staat wel welke knop waarvoor dient, maar niet hoe je er gebruik van maakt. En een trucje in een cursus is leuk, maar daarmee begrijp je nog niet precies waarom je iets doet. 

Zorg dus dat je mensen een goede opleiding op Red Hat-gebied krijgen en laat in ieder geval de senior medewerkers die de oplossing straks bouwen meelopen met de consultants tijdens het maken van de PoC. Afhankelijk van het soort Red Hat-product zijn dat bijvoorbeeld IT-architecten, ontwikkelaars, systeembeheerders of infrastructuurbeheerders. Door ze te betrekken bij de totstandkoming van de PoC zien ze hoe dingen worden gedaan en kunnen ze vragen stellen aan de consultants. Zo voorkom je dat ze bij het bouwen onnodig tegen problemen aanlopen.

De gouden tip met Red Hat is alles te automatiseren wat er te automatiseren valt, want zo maak je dingen herhaalbaar. Neem de installatie van software of een rampscenario waarbij een systeem uitvalt: als je je playbooks klaar hebt liggen, ben je voorbereid. Zo is Red Hat Ansible een prachtige tool, waarmee je heel veel standaard beheertaken kunt automatiseren. Blijf je echter ‘oude stijl’ werken met shell scripts die je een-op-een overneemt in Ansible, dan maak je geen gebruik van de grote kracht van deze Red Hat-oplossing. Die kracht zit hem namelijk in de playbooks die je schrijft en die je eindeloos kunt herhalen. Daarvoor moet je gebruikmaken van ‘idempotente’ Ansible-modules. Dat betekent dat het resultaat altijd hetzelfde is, hoe vaak je een playbook ook draait, en dat er alleen wijzigingen worden uitgevoerd als dat nodig is. 

Laten we een simpele metafoor nemen, het schilderen van een huis. In een script oude stijl geef je alle stappen aan die daarvoor moeten worden genomen: pak een bus verf in die kleur, schud de bus verf, open de bus, pak de kwast, et cetera. In Ansible beschrijf je een ‘state’: ik wil dat die muur in die kleur wordt geverfd. De software zorgt vervolgens met de modules, een soort bouwblokken, dat de juiste stappen worden gezet. Gaat er in de oude situatie iets mis, bijvoorbeeld het verfblik (in deze analogie dus een bestand) staat niet op de juiste plek, dan loopt de uitvoering spaak. Met Ansible staat het blik altijd op de juiste plaats. Je hebt in je playbook beschreven waar het moet staan en de modules bevatten alle commando’s die nodig zijn om te zorgen dat dit ook echt zo is.

Ansible Engine zorgt voor de automatische uitvoering van playbooks, zoals we dat net hebben beschreven. Maar zeker in grotere en complexere IT-omgevingen loop je de kans het zicht te verliezen op wat er allemaal onder de motorkap gebeurt. Daardoor heb je minder controle. Dat maakt het verstandig om naast Ansible Engine ook Ansible Tower te gebruiken. Dit is een extra laag op Ansible Engine die verschillende dingen voor je regelt. Zo worden de logs van alle playbook-runs standaard opgeslagen, zodat je ze kunt bekijken. Wanneer is een bepaalde wijziging bijvoorbeeld uitgevoerd? Is die wel gebeurd? En waar is het eventueel misgegaan? Ook kun je de uitvoering van playbooks plannen in Ansible Tower. Denk bijvoorbeeld aan het automatisch draaien van een playbook dat ‘s nachts een ongewenste systeemwijziging terugdraait. Of aan het automatisch maken van een back-up of het opschonen van bestanden. 

Tot slot maakt Ansible Tower het mogelijk om medewerkers een playbook te laten draaien zonder dat ze daar inzage in hebben. Denk aan een helpdeskmedewerker die met een playbook een wachtwoord kan resetten. Normaal gesproken moet deze taak op beheerniveau gebeuren omdat er speciale rechten mee zijn gemoeid. Nu neemt dit geen kostbare tijd van drukbezette mensen in beslag. 

Zonder Ansible Tower loop je al snel het risico dat mensen zelf oplossingen voor al dit soort zaken gaan verzinnen, waardoor er een bouwsel ontstaat dat niet te onderhouden is.

Red Hat verkoopt geen producten, maar ‘subscriptions’ voor het gebruik van zijn software. Dat is inclusief ondersteuning en updates. Die subscriptions kunnen best ingewikkeld zijn. Wat heb je nu precies nodig – nu, maar ook straks? Wat als je bijvoorbeeld over een half jaar meer gebruik wilt maken van OpenShift? 

Het beste is om je plannen te bespreken met Red Hat of met een Red Hat-partner en om advies te vragen. Zo hebben we als Premier Red Hat Partner bij Conclusion Xforce een tool waarmee we precies kunnen berekenen welke subscriptions in de situatie van jouw organisatie het beste zijn. Op die manier weet je zeker dat je niet te veel betaalt.

We eindigen waar we begonnen zijn, namelijk bij de Proof of Concept. Je maakt een PoC om aan te tonen of bepaalde functionaliteit doet wat ze moet doen. Maar in de praktijk groeit de PoC al snel uit tot een productieplatform. Stel, je gaat met een Red Hat-product voor identity management aan de slag. Je bouwt een kleine omgeving met één machine om te zien of het aanroepen en het identificeren van gebruikers en alle andere dingen daaromheen goed werken. Maar als je dan vanuit de PoC gaat doorgroeien, trekt die ene machine het op een gegeven moment niet meer en ligt je identity management plat. En dan kan niemand meer werken...

Denk dus van te voren goed na aan welke eisen je productieplatform moet voldoen. Bijvoorbeeld als het gaat om beschikbaarheid, componenten die mogen uitvallen zonder dat je systeem onderuit gaat of wat er aan recovery-voorzieningen nodig is. Ontwerp het hele landschap, bepaal wat waar komt te staan en kijk welke Red Hat-producten je bij het realiseren van deze omgeving kunnen helpen. Dat kost tijd, maar is zeker de moeite waard!