Azure

Connectivity gotcha when using private endpoints with Azure Service Bus georeplication

Reviewing David Rendón and Steve Miles’ book Microsoft Copliot in Azure: AI-powered cloud automation and optimization

Reviewing Kamil Mrzygłód’s book Azure for Developers

Reviewing Stéphane Eyskens book The Azure Cloud Native Architecture Mapbook

Configuring Azure alert action groups with the PagerDuty v2 api

I recently needed to set KEDA scaling rules on an Azure Container app that used the number of messages in a Service Bus queue. There’s plenty of info out there on the internet about scaling rules, but not when it comes to Service Bus, so I’m writing up what I learned here.

When working on a project recently I needed to deploy a Container App Environment within a virtual network in Azure. Thanks to the joys of internet search, I started off reading the wrong bits of the official documention and got incredibly confused, and much of the community content about this uses out of date schemas and code. This article is so I don’t need to go through that again, and hopefully it will help others, too.

If you’re hosting your application infrastructure in Azure and consolidate the diagnostic and audit information from your services into Log Analytics or elsewhere, it’s pretty easy to do using Bicep. It’s not very well documented, however, which is the reason for this post.

Bicep is a great improvement over ARM Templates but doesn’t remove the need to validate our code at build time. I could continue to use the ARM-TTK and validate the generated template, but bicep has it’s own built in rules. Getting build errors in a way that can provide meaningful information in my CI/CD tooling is an interesting challenge.

Using Lability, DSC and ARM to define and deploy multi-VM environments # Configuration as code crops up a lot in conversation these days. We are searching for that DevOps Nirvana of a single definition of our environment that we can deploy anywhere.

Recently I have been helping a number of organisations automate the deployment of their applications to Azure and came across a couple of scenarios that were not documented: Deploying an App Services web site with slots and SQL connection string settings, and the creation of a SQL Elastic Pool. Of those, the SQL Elastic Pool I found to be written up already by Vincent-Philipe Lauzon and all credit to him - my template draws on his excellent article.

I’ve had a number of people ask me if I can share the templates I use in my Resource Template sessions at conferences. It’s taken me a while to find the time, but I have created a repo on GitHub and there is a new Visual Studio solution and deployment project with my code.

As you work more with Azure Resource Templates you will find that you need to pass information from one resource you have created into another. This is fine if you had the information to begin with within your variables and parameters, but what if it’s something you cannot know before deploy, such as the dynamic IP address of your new VM, or the FQDN of your new public IP address for your service?

Over the past few weeks I’ve been refactoring and improving the templates that I have been creating for Black Marble to deploy environments in Azure. This is the first post of a few talking about some of the more advanced stuff I’m now doing.

Within a few days of each other I spoke about Azure Resource Templates at both DDDNorth 2015 and Integration Mondays run by the Integration User Group. I’d like to thank all of you who attended both and have been very kind in your feedback afterwards.

Unlike most of my recent posts this one won’t have code in it. Instead I want to talk about concepts and how you should look long and hard at your templates to optimise deployment.

Over the past few posts on this blog I’ve been documenting the templates I have been working on for Black Marble. In a previous sequence I showed how you can use nested deployments to keep your templates simple and still push out complex environments. The problem with those examples is that they are very fixed in what they do. The templates create a number of virtual machines on a virtual network, with static IP addresses for each machine.

In part one of this series of posts I talked about the project driving my creation of these Azure Resource Templates, the structure of the template and what resource I was deploying. This post will go through the deployment and configuration of the first VM which will become my domain controller and certificate server. In order to achieve my goals I need to deploy the VM, the DSC extension and finally the custom script extension to perform actions that current DSC modules can’t. I’ll show you the template code, the DSC code and the final scripts and talk about the gotchas I encountered on the way.

Part One of this series covered the project itself and the overall template structure. Part Two went through how I deploy the Domain Controller in depth. This post will focus on the next server in the chain: The ADFS server that is required to enable authentication in the application which will eventually be installed on this environment.

Part One of this series covered the project itself and the overall template structure. Part Two went through how I deploy the Domain Controller in depth. Part Three talks about deploying my ADFS server and in this final part I will show you how to configure the WAP server that faces the outside world.