Azure Cloud Shell is the web based cmd line tool provided by Microsoft that allows you to launch either a Bash or PowerShell command line in your browser, that is already authenticated to Azure with your credentials and contains all the command line tools you need to interact with Azure, it even includes other tools like Teraform, Ansible, Git etc.
When Cloud Shell was launched it was only available in the Azure portal, however it is now possible to launch an instance of cloud shell from pretty much any web page by including a clickable link with some Javascript to launch a new window and load Cloud Shell.
The relationship between an Azure Subscription and Azure AD is not always obvious, but each subscription is tied to to an AAD tenant, this allows for authorization of users in that tenant to undertake operations on that subscription. Sometimes it is necessary to change the tenant a subscription sits under, usually this is either to change the scope of users that can be granted roles in that subscription, delegate permissions for that subscription, or for services like Azure AD Domain Services, which require the subscription to sit under the AAD tenant that contians the AAD DS instance.
A web app in Azure actually consists of two things, an App Service Plan and an App Service, what is not always clear is why they are two things and what the purpose of the plan part is. The App Service is fairly easy to understand, it’s the actual instance of your web application, it’s where you deploy your code, set up SSL certificates, connection strings etc. The App Service Plan is a little less clear, when you create your app you select a plan and this determines what you pay, but it’s not entirely obvious what it is for, why it’s a separate things, or what you can do with it.
Monitoring your resources is vital to being able to detect issues or opportunities for performance improvements. When it comes to Azure the monitoring story can be a bit confusing with multiple different services seeming to offer similar or related solutions. In particular there is often confusion between two services, Azure Monitor and Log Analytics (part of the OMS suite). We’re going to take a look at these two services and when you would use them.
If you’ve been to any cloud or devops conference or meetup in the last year, you’ve probably heard about Terraform, the Infrastructure as Code tool from Hashicorp, it’s been one of the big talking points of the devops community for some time now. Terraform is a proprietary language for creating infrastructure as code deployment solutions, and one of it’s biggest selling points is that it supports multiple different cloud vendors including Azure.
Managed disks brought a number of benefits to Azure VM’s over thee previous method of manually managing storage accounts used for VM disks. One of these features that is often overlooked or misunderstood is snapshots. In this article we’ll explore what benefits snapshots give you, and how to use them.
Before we delve into how to use snapshots, there are some key points to be aware of when using them:
When your learning a new technology, like Azure, documentation is key and find inaccurate, out of date or just plain wrong documentation is incredibly frustrating. Microsoft have taken an interesting approach to this issue by storing all Azure (and many other MS services) documentation sources on Github and allowing the community to submit pull requests. What this means is that if you spot an error in a document or you feel it needs updating you can make this change your self and get the document updated very quickly, rather than waiting for product teams to spot the issue and make corrections.
Don’t forget to check out the other parts in this series:
Part 1 – Version Control Part 2 – Testing Part 3- Build Initially this might seem like a bit of an odd topic, “Build” in a software development process usually refers to the process of compiling an application and preparing it for distribution (creating MSI files etc.). Whilst we are writing infrastructure as code, there’s no compilation involved, no creating of installers, so what are we doing here?
Historically Azure Network Security Groups (NSG’s) have only allowed you to enter a single value for things things like source or destination IP and source or destination port. This has meant that for complex setups you end up with a very large amount of NSG’s. This is especially if you are trying to filter a large amount of IP’s, for example the Azure Data Center IP ranges, which is a common requirement if you want to restrict outbound access but allow access to PaaS resources.
Back a few years ago it was not uncommon to see a requirement for VMs to be rebooted when maintenance to apply updates to the underlying host was required, every few months. Fortunately this is now mostly a thing of the past, with most updates now being applied using Azure’s in place upgrade process which just pauses for a few seconds while the VM whilst the host is updated. Up until recently I had not seen a maintenance window that require VM reboots for over a year.
