INLEIDING De opkomst van Cloud computing zal weinigen ontgaan zijn, en er is ondertussen nauwelijks discussie meer over dat dit een blijvende plaats in het IT landschap ingenomen heeft. De daarbij genoemde belangrijkste voordeel zijn de flexibilisering van IT resources, die geconsumeerd worden met een pay-as-you-go afrekenmodel. En als het even kan ook nog de nodige kostenbesparingen. De genoemde flexibiliteit van Cloud computing brengt ongekende mogelijkheden, maar er zijn een fors aantal uitdagingen om die flexibiliteit ook daadwerkelijk te exploiteren. Dit artikel belicht een aantal bouwstenen om de mogelijkheden van een op Infrastructure as a Service (IaaS) gebaseerde oplossing uit te nutten.
Infrastructure as a Service IaaS biedt infrastructuurcomponenten als servers, storage, load balancers en netwerken on demand. Het feit dat je bij zo’n IaaS op ieder gewenst moment resources zoals servers en storage kunt starten en weer stoppen biedt een aanzienlijk voordeel ten opzichte van de traditionele ‘harde’ infrastructuur. IaaS is een vorm van cloud computing met een relatief laag abstractieniveau. Dit heeft als nadeel dat er nog steeds veel beheerd moet worden aangezien in feite alleen het fysieke aspect van infrastructuren uitbesteed is aan de cloud leverancier. Dit lage abstractienivea maakt het echter ook mogelijk om zonder veel aanpassingen te migreren naar een cloud omgeving. Deze laagdrempeligheid heeft er voor gezorgd dat IaaS op dit moment veruit de meest populaire vorm van cloud computing is. Met de opkomst van Cloud computing, met haar op papier onbegrensde mogelijkheden maar ook met haar eigen uitdagingen is er een explosie van nieuwe methodes, tools en services op gang gekomen die inspelen op deze ontwikkelingen, maar vaak ook zeer waardevol zijn in traditionele IT omgevingen. In dit artikel lichten we een tweetal veelbelovende aspecten eruit. De eerste is vooral bekend onder de term Infrastructure as Code, waarbij infrastructuren (netwerken, firewalls, servers, load balancers, dns configuraties etc.) als programmatuur ontwikkelt wordt en vervolgens ook op die manier gecreëerd en beheerd worden. Het tweede, hier aan gerelateerd, is het automatiseren van systeem configuratie management, waarbij systemen volledig automatisch geconfigureerd worden en dat ook blijven gedurende de levensduur van het systeem. Dit is natuurlijk niet nieuw, maar als gevolg van de dynamiek van een op cloud computing gebaseerde oplossing nog veel belangrijker geworden. In dit artikel belichten we de achtergrond van deze ontwikkelingen, en laten met behulp van een concreet voorbeeld zien hoe dat er in de praktijk werkt.
Infrastructure as Code en de DevOps beweging
De meest ‘voelbare’ verandering van een IaaS cloud is dat niets tastbaar meer is. Er zijn racks, servers en switches meer die je kunt vasthouden en je hoort niet meer het gezoem en geratel van harde schijven die op topsnelheid roteren. Het fysieke aspect is volledig overgenomen door de IaaS provider, met als consequentie dat de hardware eigenlijk ook software is geworden. Dit heeft veel invloed op hoe wij IT consumeren. Een van de belangrijkste verschuivingen is de rol van de traditionele IT operations. Dit is niet alleen doordat bepaalde werkzaamheden uitbesteed worden, maar ook doordat infrastructuur services steeds meer verweven worden met applicatie logica worden. Een aansprekend voorbeeld is hierbij het automatisch kunnen opschalen (en weer terug) van server resources bij pieken in het gebruik van de applicatie. Dit vereist een integratie tussen applicatie en infrastructuur die tot voorheen niet mogelijk was. Een logisch gevolg van deze is dat applicatie ontwikkelaars, veel meer dan voorheen verantwoordelijk worden voor de provisioning van server resources. Aangezien deze ontwikkelaars niet de achtergrond en ervaring hebben die nodig is voor het beheren van grootschalige infrastructuren kan dit al snel tot een onwerkbare situatie leiden. De trend die hier op inspeelt is de zogenaamde DevOps aanpak, die een veel strakkere integratie tussen Corporate IT, Application Development en Quality Assurance nastreeft.
Een van de fundamentele pijlers in de DevOps aanpak is de Infrastructure as Code. Met de opkomst van cloud computing is het mogelijk geworden om infrastructuren te creëren (en ook weer af te breken) met behulp van code. Het creëren van netwerken, subnets, firewalls servers, load balancers en harde schijven door middel van scripts is
een bijzonder krachtig middel en door een aantal natuurkundige wetten simpelweg niet mogelijk in een traditionele architectuur. Voorbeelden van dergelijke oplossingen zijn Amazon Cloudformation, Spiceweasel en Vagrant, waarbij de focus in dit artikel op Cloudformation zal liggen. Met dergelijke tools kunnen servers, firewall, loadbalancers, dns configuraties, etc worden geactiveerd en geconfigureerd. Dit alles op basis van een configuratie script en zonder de fysieke handelngen die daar normaliter bijhoren. Dit betekent dat wanneer je het script klaar hebt je met één druk een server draaiende kan hebben in een volledig geconfigureerd netwerk. Cloudformation als voorbeeld van Infrastructure as Code Cloudformation is een onderdeel van Amazon Webservices (AWS). AWS is veruit marktleider in de IaaS markt, en volgens rapporten draait reeds een adembenemende 1% van het gehele internet op deze service. Met AWS Cloudformation kun je op basis van een template een ‘stack’ starten of wijzigen. Een ‘stack’ is een verzameling van infrastructuur elementen die gestart/geconfigureerd worden op basis van een web services api. Deze onderdelen kunnen bijv. zijn: ● Netwerk topologie, inclusief subnets, route tables, access control lists en NAT configuraties; ● Automatisch schalende server instances inclusief bijbehorende storage; ● Een volledig geconfigureerde firewall; ● DNS configuraties; ● Messaging queues en topics; Een stack wordt ontwikkeld in de vorm van een script (in json formaat) en met behulp van de web interface of command line geïnitieerd. Een interessant detail, en in dit artikel tevens de link naar het volgende topic is het feit dat je een server kunt laten opstarten waarbij zelf gedefinieerde data als opstart parameter meegegeven wordt. Op basis van deze feature zijn een aantal tools ontwikkeld die op basis van deze meegegeven informatie actie ondernemen. Het meest bekende voorbeeld van zo’n tool is de zogeheten cloud-init tool, ontsproten uit de Ubuntu community maar ook beschikbaar op andere platformen. Cloud-init stelt je o.a. in staat om de meegegeven user-data in de vorm van een shell script te formuleren die automatisch uitgevoerd wordt aan het einde van de boot sequence. Dit lijkt triviaal maar is in feite een krachtige enabler voor het automatisch kunnen configureren van spontaan opkomende server instances. In theorie kan een gehele server op deze manier geconfigureerd worden met behulp van custom scripts maar al vrij snel wordt dat een tijdsrovende aangelegenheid en wordt de toegevoegde waarde van een meer flexibele configuration management oplossing duidelijk. Dit is het tweede aspect waar we op inzoomen.
Configuration Management Het installeren en configureren van servers is een tijdrovende aangelegenheid. Dit was al duidelijk in de tijd dat servers nog zoemende dozen waren, maar door de flexibiliteit van gevirutaliseerde infrastructuren is het aantal noodzakelijke configuratiehandelingen geëxplodeerd. Voor het efficient kunnen lanceren van nieuwe server instances zijn in hoofdlijnen twee oplossingsrichtingen te bedenken: ● het creëren van gespecialiseerde server images die alle services en configuraties bevat, en waarbij de image zeer snel geinstantieerd kunnen worden. ● het gebruiken van een basis server image en het on-the-fly (tijdens het opstarten van de server instance) configureren van de benodigde services en configuraties. Beide oplossingen kunnen werken en hebben hun eigen voor- en nadelen. De configuration management aanpak die hier geschetst wordt gaat uit van de aanpak waarbij er één basis image is en alle configuraties tijdens het opstarten van de server instance toegepast worden. Het voordeel van deze aanpak is dat er gewonnen is op flexibiliteit en makkelijker ingespeeld kan worden op wijzigingen (bijv. updates op het operating systeem), maar vereist daarentegen wel weer een forse investering. Het moge duidelijk zijn dat tooling vereist is voor het kunnen beheren en uitvoeren van dergelijke configuraties. Naast de commerciele oplossingen zijn er in de loop van tijd een aantal Open Source producten verschenen met als doel het automatiseren van dit soort configuratie taken. De eerste serieuze speler was CFEngine, daarna gevolgd door Puppet en in een later stadium Chef. Chef is afgeleid van Puppet, waarbij Puppet weer afgeleid is van CFEngine. Centraal binnen deze toepassingen staat het concept van rollen die toegepast worden op een server instance. Deze rollen beschrijven in welke staat (software, services, configuraties) een server dient te verkeren door middel van client wordt met regelmaat gecontroleerd in hoeverre de actuele status overeenkomt met de werkelijkheid en indien gewenst worden aanpassingen doorgevoerd. Chef in meer detail Een aantal kernonderdelen en -concepten van de Chef oplossing worden hieronder beschreven: ● De centrale Chef Server, al dan niet in een ‘hosted’ variant; ● Chef Workstation; ● Chef Client; ● Nodes; ● Server Roles; ● Cookbooks en Recipes.
Cookbooks / Recipes Chef maakt gebruik van cookbooks, die weer bestaan uit een of meerdere recipes. Een Cookbook is een verzameling configuraties voor een bepaalde tool of server rol, bijv. voor het inrichten van de Apache webserver. Er is een grote collectie open source cookbooks vrij beschikbaar en waar nodig kunnen deze aangepast worden of nieuwe cookbooks gemaakt worden. De verschillende onderdelen Het volgende plaatje geeft aan hoe de Chef Server, Workstation, Client en Nodes zich tot elkaar verhouden.
Voor de server kun je kiezen tussen een eigen Chef server inrichten en beheren (wat overigens ook weer via Chef kan) of een Software as a Service variant: Hosted Chef. Via het workstation wordt beheerd welke rollen en welke configuratieparameters gebruikt zullen worden en wanneer een server instance (een node genaamd, kan ook een desktop zijn) geïnitieerd wordt. Een node draait de Chef Client die zorgt dat de gewenste configuratie toegepast wordt. Het ontwikkelen van een configuratie op basis van een dergelijk tool is iets dat zeker een investering vergt en met name ook alleen floreert als er sprake is van gedisciplineerd werken. Het is in een cloud omgeving echter nagenoeg onmisbaar maar kan ook van veel toegevoegde waarde zijn in andere omgevingen. Zo is een eenmaal ontwikkelde configuratie direct toepasbaar in andere omgevingen als een traditioneel server park of voor het automatisch creëren en configureren van een desktop virtual machine voor ontwikkel- en testwerkzaamheden.
Voorbeeld: Ontwikkel- en testomgeving On Demand
In dit voorbeeld laten we zien hoe een volledig geconfigureerde ontwikkel- en testomgeving opgestart kan worden met behulp van Cloudformation en (Hosted) Chef. Behalve de configuratie voor de server in kwestie, zijn er meer configuratie benodigd. Onder word sterk vereenvoudigd de verschillende componenten weergegeven van in dit geval een omgeving die (al dan niet automatisch) kan uitschalen.
AMAZON CLOUDFORMATION: De hierboven getoonde omgeving wordt gecreëerd en vervolgens beheerd met behulp van een zogeheten Cloudformation stack. Cloudformation stelt je in staat alle keuzes die je maakt op een declaratieve manier in een template vast te leggen. Zo’n template is een JSON script waarin je specificeert uit welke resources de omgeving bestaat. Zo’n template is met een simpele text editor te maken en alhoewel het al snel vrij groot wordt kan het snel opgebouwd worden door de beschikbaarheid van een grote hoeveelheid voorbeelden en snippets. Een vast onderdeel van een Cloudformation template zijn de input parameters, waarmee de template herbruikbaar gemaakt kan worden en al naar gelang de situatie specifieke keuzes gemaakt worden.
Deze parameters kunnen een default waarde toegekend worden en tijdens het creëren van de Cloudformation stack kunnen nieuwe waarden toegekend worden. Het meest omvangrijke onderdeel van de template is de declaratie van de gewenste resources. Deze kunnen in een willekeurige volgorde gespecificeerd worden waarna
Cloudformation de afhankelijkheden bepaald en deze in de gewenste volgorde zal creëren. Als voorbeeld wordt hieronder de definitie van een security group (een soort firewall) gegeven.
Iedere resource wordt op een dergelijke manier gedeclareerd waarbij input parameters maar ook gegevens van andere resource elementen gebruikt kunnen worden.
Onderstaand wordt een complexere snippet getoond van de DNS A-Record registratie waarbij zowel input data (DomainName) als bepaalde parameters van de net gecreëerde load balancer gebruikt worden.
Door middel van het Cloudformation template wordt de volledige infrastructuur gecreëerd, maar hoe wordt er nu voor gezorgd dat de server de uiteindelijke gewenste configuratie toegepast krijgt? Dit kan bereikt worden door in de template een script te definieren dat door iedere server bij het opstarten uitgevoerd wordt.
Dit script, in dit geval op een Windows server maar dit werkt nagenoeg identiek op bijv. Ubuntu Linux voert het cfn-init commando uit. Dit cfn-init commando interpreteert de meta-data sectie wat ook gespecificeerd is in de template. Deze meta-data sectie stelt je in staat om te specificeren welke bestanden aangemaakt moeten worden, (op Linux) welke software packages geïnstalleerd en services gestart moeten worden en welke aanvullende commando’s uitgevoerd moeten worden. In feite is het cfn-init een lichtgewicht server configuratie management systeem. Deze script en meta-data secties kunnen gebruikt worden voor het initialiseren van de server zodanig dat het contact kan maken met de Chef server. Dit betekent het installeren en configureren van de Chef Client software, die dan vervolgens contact zoekt met de Chef server om de benodigde wijzigingen door te voeren. De cloudformation stack kan uitgevoerd worden via de Web console van AWS, dan wel via de command line interface uitgevoerd worden. Tijdens het aanmaken van de stack kan de voortgang gevolgd worden door middel van het monitoren van de events.
En wanneer de stack succesvol is voltooid zal je dit te zien krijgen:
Indien Cloudformation niet lukt om de stack aan te maken wordt alles teruggedraaid en alle reeds aangemaakte resources weer opgeruimd. Het is overigens wel belangrijk om vervolgens eventuele wijzigingen in de configuratie altijd via Cloudformation door te voeren, en dus niet meer handmatig. Opscode Chef: Nadat een server via de Cloudformation stack opgestart en geconfigureerd is, zoekt de geinstalleerde Chef client contact met de Chef server. Hierbij hebben we gebruik gemaakt van de SaaS variant Hosted Chef. Deze is gratis in het gebruik tot vijf nodes en daardoor uitermate geschikt voor evaluaties. De configuratie die we hierbij toegepast hebben bestond nagenoeg uit standaard beschikbare Cookbooks:
Op het moment dat de Chef client zich geauthenticeerd heeft bij de Chef server wordt deze getoond in de Node list:
Node list:
Om de node te juiste packages te laten installeren moet deze een rol worden toegekend. Wij hebben een rol DEV aangemaakt en daaraan een aantal recipes aangekoppeld.
Role DEV (runlist):
Nadat de rol is toegekend kan de chef-client, al dan niet als service uitgevoerd worden waarbij gezorgd wordt de node up-to-date is en dat ook blijft bij eventuele wijzigingen in de configuratie.
Conclusies Cloud Computing brengt grote mogelijkheden maar komt met haar eigen beperkingen en uitdagingen. In dit artikel hebben we laten zien hoe de industrie daar op reageert en hebben we een tweetal tools uitgelicht die een indruk geven wat de mogelijkheden zijn. We staan nog slechts aan het begin van deze ontwikkelingen en het is onze vaste overtuiging dat de manier hoe wij met Informatie Technologie omgaan drastisch aan het wijzigen is.
Dat biedt nieuwe, ongekende mogelijkheden maar die weg zal niet zonder hobbels zijn. Meegaan met de trend met een sterke focus op eigen behoeften en mogelijkheden is het devies.
