Automatische back-ups van een Azure SQL database maken doen we normaal gesproken met Azure Automation. Vanwege het probleem dat zich aandiende omdat het back-up proces via een ander IP adres loopt dan het IP adres van het automation proces, hebben we dit keer gekozen om het eens met behulp van Azure DevOps te proberen.
In Azure kun je een point-in-time restore doen van een database. Dit kan voor een bepaalde periode terug in de tijd. De lengte van de periode is afhankelijk van de gekozen pricing tier.
De wens was om verder terug te kunnen in de tijd en niet afhankelijk te zijn van de gekozen pricing tier. De oplossing die daarvoor is bedacht, is om elke dag een back-up van de database te maken en periodiek de back-ups op te schonen.
Azure automation en het gebruik van ‘runbooks’ is daarvoor de aangewezen manier. Je kunt PowerShell scripts schrijven en deze invoegen in een runbook. Je kunt vervolgens parameters meegeven aan het runbook en deze scripts op een tijdschema laten uitvoeren. Waarbij de mogelijkheden bij het maken van een tijdschema (schedule) uitgebreid zijn.
De automation resource en de runbook containers kunnen met een ARM template worden uitgerold. De PowerShell scripts kunnen door middel van een link in het ARM template worden aangegeven. Echter hebben we er (in dit stadium van het project) voor gekozen om de inrichting van het runbook handmatig te doen.
Wat dan verder nog nodig is, is een PowerShell script en een ‘Run as account’ om binnen de Azure context het PowerShell script te mogen uitvoeren.
Kort samengevat is de procedure in het PowerShell script als volgt
(download kopieerbare code: Azure Automation vs DevOps Release)
Omdat SQL Server is afgeschermd door een firewall, moet het IP adres worden toegevoegd aan de rules.
Echter, wanneer het runbook wordt gestart, produceert het script een foutmelding:
Het IP adres dat wordt genoemd in de foutmelding is niet gelijk aan het IP adres dat in het script is opgevraagd. En dus ongelijk aan het IP adres dat is ingesteld als firewall rule. Daarmee krijgen we geen toegang tot SQL-server en mogen we geen back-up maken.
Waar het IP adres uit de foutmelding vandaan komt is ons onbekend. Het IP adres is wel afkomstig van Microsoft. Wanneer dit IP adres wordt toegevoegd aan de firewall, werkt het script naar behoren. Ook hebben we gemerkt dat dit IP adres niet wijzigt.
Ter test hebben we besloten om de scripts vanuit Azure DevOps te draaien.
Het resultaat was: exact dezelfde foutmelding, maar daarin hetzelfde IP adres als in de foutmelding vanuit het Azure Automation runbook.
Voor dit probleem zijn geen oplossingen gevonden, alleen work-arounds en non-oplossingen (Hybrid Worker). En het probleem geldt ook voor andere resources zoals keyvault.
De work-around waar wij voor hebben gekozen is om het IP adres uit de foutmelding als variabele op te nemen in de Azure DevOps release. De variabele wordt als parameter door gegeven aan de ‘Azure resource group deployment’ task. Op deze manier wordt het IP adres m.b.v. het ARM template toegevoegd aan de SQL firewall rules.
ARM template snippet voor toevoegen van het IP adres aan de SQL firewall rules:
Wanneer deze firewall rule is ingesteld kan het PowerShell back-up script goed functioneren. Het is niet een ideale situatie om dit IP adres als waarde in te voeren en permanent in de firewall rules te laten staan.
Een andere denkbare work-around -waarbij geen parameters nodig zijn, is een retry scenario. Probeer de database back-up te maken, filter vervolgens met PowerShell en een regular expression het IP adres uit de foutmelding. Voeg dit IP adres tijdelijk toe aan de firewall rules en probeer daarna nogmaals de database back-up te creëren.
Of de scripts in Azure Automation of in Azure DevOps werden gedraaid: het maakte geen verschil. Toch hebben we dit keer gekozen om het in DevOps te laten staan om een aantal redenen.
- Ook in Azure DevOps kan de release ingepland worden om elke nacht uit te voeren.
- De PowerShell scripts staan in source control, de DevOps release pakt automatisch de laatste versie van het script op.
- Alle uitrol gerelateerde parameters en informatie staat bij elkaar op één plek.
- Wanneer het IP adres wijzigt, faalt de nachtelijke back-up release. Hiervoor kunnen we een (gratis) mailnotificatie instellen naar het development team dat zich bezighoudt met dit project.
Download hier het hele artikel om de stukjes code te kopieren:Â Azure Automation vs DevOps Release
