Automate Everything. That’s my new mantra, and it should be yours…
Like many of you, I’m an infrastructure guy and grew up with the crutches of setup.exe and the massive installers that MSFT built in the late 90’s and 2000’s. But, that was then, and today all of us need to become DevOps engineers! It used to be when we built servers they would have a lifespan of many years, but now there is a new type of VM that might only live for a day or even less.
The concept of deleting a server would have scared the daylights out of me in 2002!? Yikes!
In this new world of Azure, we should be building VMs that are purpose-built and automated in their deployment end to end. We want the teams that are consuming these servers to be ready to work as soon as they login.
Windows, Linux, and Azure provide us with many tools to make that happen such as ARM templates, PowerShell or Yum and Apt on Linux. These tools can work together with the custom script extension for Windows or Linux to build out our VMs. Read More
When I first heard that you could run nested VMs with Azure, I ran over to my laptop to deploy one of those shiny new Version 3 VMs!
Once my Host was provisioned, I got right to work. Quickly adding the Hyper-V role and after a quick reboot, I started downloading ISOs! And before you know it I was disappointed. Yeah, I had a VM running, but after searching the internet for hours, I gave up. I never could get the thing talking to the Internet.
Well, fast forward a few months and a client of mine asked if we could build a self-provisioning Nested Hyper-V Host in Azure that would pull down pre-configured VMs and start them with only one click? I was excited. There is nothing cooler than getting to figure something out while you are getting paid. Well, it wasn’t easy to figure out, but what I have for you here is the fruit of that labor! Read More
This is top of mind for everyone these days and Azure has many security features. Today we are going to explore the world of Network Security Groups (NSGs) and their use on Virtual Machines and traffic into and out of Virtual Networks.
A network security group (NSG) is a networking filter (firewall) containing a list of security rules allowing or denying network traffic to resources connected to Azure VNets. These rules can manage both inbound and outbound traffic. NSGs can be associated to subnets and/or individual Network Interfaces attached to ARM VMs and Classic VMs. Each NSG has the following properties regardless of where it is associated:
- Name for the NSG
- Azure region where the NSG is located
- resource group
- Rules either Inbound or Outboard defining what traffic is allowed or denied
When a NSG is associated to a subnet, the rules apply to all resources connected to the subnet. Traffic can be further restricted by also associating a NSG to a VM or NIC. NSGs that are associated to subnets are said to be filtering “North/South” traffic (in other words, packets flowing in and out of a subnet). NSGs that are associated to Network Interfaces are said to be filtering “East/West” traffic (in other words, how the VMs within the subnet connect to each other). Read More
One of the largest gaps that Azure has had when compared to the competition has been the lack of high-availability options. The most glaring has been the lack of Availability Zones, which have been available in all the main providers such as AWS, Google and even Oracle.
Basically, Availability Zones allow cloud admins to deploy cloud resources to separate datacenters within a region. This ensures that applications will remain online even if one of the provider’s datacenters go down.
Microsoft has announced a public preview of their Availability Zones to help protect you from datacenter-level failures. These Availability Zones are located inside an Azure region, and each one has its own independent power source, network, and cooling. These zones are separate datacenters which are located “10’s of miles”, from each other. Microsoft has super-fast network connections between the zones, and have stated that they maintain very strict rules on the network latency between these datacenters. Read More