PowerShell

When you absolutely need to run your terminal as admin, gsudo can make adding an admin tab to Windows Terminal much easier.

If your working in Azure regularly at scale then it’s very likely you spend a fair amount of time at the command line using the Azure PowerShell cmdlets or Azure CLI (or both). This week at the Build conference Microsoft announced: “Windows Terminal” a new command line experience for Windows, which looks very interesting. It’s still in development, but you can download the source from Github and build it yourself if you’re interested in trying it out.

Don’t forget to check out the other parts in this series: Part 1 – Version Control Part 2 – Testing Part 3- Build In part 1 of this series we took our first step in building an Infrastructure as code pipeline by moving our infrastructure files into source control. Now that we have this code in a central repository we can use this as a base for the next steps in this process.

Azure Resource Manager (ARM) templates are a great resource for deploying Azure infrastructure, including virtual machines, in a declarative manner. However, using an ARM template to deploy a VM will only get you as far as having a VM deployed and the operating system installed and running. The next step is to get any applications and supporting software installed on those machines. Of course you can RDP to machine and do this manually, but this breaks down quickly if you have lots of machines or need to regularly deploy VM’s.

Azure App Service Certificates provide a convenient way to purchase SSL certificates and assign them to Azure Apps right from within the portal, but one question I see a lot is whether it is possible to use this certificate elsewhere, outside of the app service, particularly if you have purchased a wild-card certificate. The certificate provided by App Service Certificates isn’t anything special, it’s a pretty standard SSL cert, the service just provides a nice easy way to provision it and assign it to your web service.

Following on from my post on joining Azure batch pools to a vNet, this leads on to a requirement to access resources on the vNet and this means credentials are needed. Rather than hard-coding these credentials in scripts, we want to obtain these from a secure storage location on demand and this is where Azure KeyVault comes in, providing a secure, encrypted storage location for our credentials. Obviously there is no point putting your admin credentials in KeyVault, then hard-coding credentials to access KeyVault in your script, so the solution is to use a certificate to give your batch VM’s access to KeyVault.

A recent update to Azure Batch added the ability to join a batch pool to a virtual network. By doing so it is possible for batch compute nodes to access resources inside a vNet (file servers, SQL servers etc.). vNet Requirements There are some limitations on the vNet configuration if you wish to do this: Only Cloud Services Configuration pools can be assigned a VNet. This is no longer the case The VNet must be: - In the same Azure region as the Azure Batch account.