Infrastructure Automation met Octopus Deploy

Auteur
Tom Meulensteen
Datum

Waarom Infrastructure automation?

Wanneer – als onderdeel van je continuous delivery - het automatisch deployen van releases gemeengoed is geworden, wordt het de tijd om de volgende stap te nemen: infrastructure as code.

Hoe cool zou het zijn wanneer we infrastructuur onderdeel laten uitmaken van een release? Zodat er samen met een release niet alleen software maar ook infra wordt uitgerold. Gebruik je AWS? Dan kan dit bijvoorbeeld met de Cloudformation service. Een service waarmee je een template omzet naar virtuele infra componenten, een zogenaamde stack.

Infrastructure Automation met Octopus Deploy 1

Hoe passen we het toe?

Elke applicatie krijgt een template, hierin staat de complete infrastructuur voor de applicatie beschreven. Op deze manier kunnen we goed controleren en bijhouden wat elke applicatie aan infra nodig heeft om te draaien. Deze templates krijgen net als releases een versienummer en worden opgeslagen in GIT en net zoals bij de releases ‘veegt’ Teamcity dit alles bij elkaar en koppelt de template aan de juiste applicatie.

Hoe helpt Octopus Deploy ons hierbij?

We hebben een release en een infra template. Dit moeten we nog uploaden naar de cloud en vervolgens cloudformation aanroepen. We gaan OctopusDeploy gebruiken om deze stappen uit te voeren. OctopusDeploy is namelijk een release automation framework. Vervolgens voeg je met powershell stappen toe waarin we een stap maken die de cloud aanspreekt.

Onderstaand diagram geeft een overzicht.

Infrastructure Automation met Octopus Deploy 2.docx (2)

Immutatable Infrastructure

Normaliter was een release altijd een deploy op een bestaande omgeving. De servers die nodig waren, waren al bekend en ook binnen OctopusDeploy. Nu werkt het geheel andersom. De servers die uitgerold gaan worden zijn nog niet bekend en OctopusDeploy weet daardoor nog niet waar de releases werkelijk heen moeten.

Nu zijn er meerdere mogelijkheden om dit op te lossen. Hieronder de twee stappen die wij hanteren.

  1. Nadat je infrastructuur template is uitgevoerd, moet je de nieuwe servers aanmelden bij OctopusDeploy en een verzoek doen voor de laatste applicatie release.
  2. Je pakt een algemene locatie, zoals een fileshare waar alle servers bij kunnen of een S3 Storage locatie. Vervolgens laat je OctopusDeploy je applicatie als ‘offline package’ wegschrijven. In de cloudformation template geef je de locatie mee en laat je hem installeren zodra de server beschikbaar is.

Meer mogelijkheden

Dit opent de deur naar nog meer mogelijkheden. Per release worden dus nieuwe servers aangemaakt en oude servers verwijderd. Servers die defect zijn worden weggegooid en binnen een aantal minuten staat er een andere voor in de plaats. Het is mogelijk om in een korte tijd meerdere omgevingen en zelfs versies van de applicatie naast elkaar te hebben draaien. Maar wat dacht je van windows patching? Gewoon na ‘patch Tuesday’ een nieuwe release starten met een aangepaste template. Alleen nu nog een manier om dat te automatiseren… Maar dat is een mooi onderwerp voor een volgende blog.

Meer weten?

Mocht je hier meer over willen weten dan kun je uiteraard contact met me opnemen.

Tags

Automation Cloud