This course covers the knowledge domain for designing a management, monitoring, and business continuity strategy in Azure in preparation for the 70-534 certification exam. The course will cover managing resources with systems center, on-premises monitoring, cloud-based virtual machines and applications, patching strategies, business continuity and disaster recovery, as well as a discussion of automation tools.
Welcome back. In this lesson we're gonna talk about Azure automation and PowerShell work flows.
I want to start with PowerShell. If you need to script things out in the Windows world, PowerShell is likely the tool for the job. You can use one of the many modules that exist and you can create your own modules which include binary modules, so we have a lot of power there.
Now, if you want to start using PowerShell with Azure, you need to install the Azure commandlet, and we can do that with PsGet or with the Web Platform Installer, and in this example I'm going to use the Platform Installer. Okay, and once it's all installed, we can list off the modules and we can see what we have available. So you can see here we have a lot of different options and we can also run the login method to kick off the login screen, so we can start using Azure. Now, once we have all of that installed, we can start creating PowerShell workflows. I'm not gonna get into showing how to write PowerShell scripts in this course, however, I do want to cover workflows.
Now workflows are different from plain old scripts because workflows allow us to execute a series of tasks and these tasks can be executed in parallel or in sequence, and we can even create checkpoints to allow us to ensure that if our workflow is interrupted, we can resume it where it left off. All of this makes workflows a great option for long-running complex tasks. If you have a task with steps that you think might fail, then the use of checkpoints before and after is going to ensure that either way, succeed or fail, we can start up in the correct place if we need to. So I want you to start thinking about workflows as one of your go-to tools for automating long-running or error-prone tasks.
Okay, this segues nicely into Azure Automation. Azure Automation is a cloud-native tool for automating tasks. If you need to do something such as deploying an app, or custom monitoring, or maybe even creating an entire text stack in Azure, Azure automation is what you're looking for. Automation uses the concept of runbooks, which are just a name for one or more tasks that we want to run. Runbooks allow us to a select type, now currently we have four supported types. We can use Graphical or PowerShell, the difference being PowerShell is just a PowerShell script and Graphical provides a user interface for creating these scripts. And then we have Graphical and PowerShell workflow. The difference here is what we talked about earlier, these are gonna use workflow to enable features such as checkpoints.
Let's take a look at using a PowerShell runbook. Here we have a runbook that I have thrown together based on sample code online. It's going to authenticate us, and then get the VM information for a resource group aptly named Resource Group, and if we try it out in the test panel, we can see how it works. Okay, it queues up the script, and then it's gonna kick off the login process, and now it's gonna run the code to fetch the VM's data. Now, if we scroll through we can see we have quite a bit of data. And that's about all there is to it.
I like to use the PowerShell and PowerShell workflows, because we can check those into source control, and then we can have those versioned. However the Gooey gives us a nice drag-and-drop experience so you're gonna want to select the one that's right for you and your team.
While we're talking about automation, I also want to cover configuration management because it's a part of Azure animation, and it's an important part of modern operations. Configuration management is about being able to ensure that the server is configured the way it's supposed to be in an automated way. The reason it's important is if you have 10 servers, and you manually configure each to have IIS installed, and then you configure your website, then you need to install some patches so you go through and manually install them, maybe you get distracted and you forget to patch one of those servers. Now those environments no longer match. Or maybe you manually install some binaries for the developers for the application that you're running and just one of those is using the wrong version. And I've seen this cause all kinds of problems.
So if just 10 servers are going to be difficult to manage manually, imagine a hundred, thousand, ten thousand, so manual efforts just don't scale well in this arena. This is something that the tech world has long since identified as a problem in need of solving, and that's why we have so many different configuration management tools.
Now if you want to use open source tools, you have options such as Puppet, Chef, and Ansible, among many others. You're gonna find that a lot of user-created scripts exist to handle configuration of servers especially Linux-based servers with these tools. These are all great tools, and if you're managing more Linux-based servers than Windows, I recommend that you look into all of these further to find the one that's right for you. The documentation and community around these tools when using it for mostly Linux systems is fantastic. You're going to find a lot of sample code, modules, and you'll be able to use many of these without modification for common tasks. It's gonna save a lot of time.
Now Ansible is my personal favorite out of these three due to the amount of existing modules, the easy to use YAML syntax, and the ability to create modules in any programming language that supports standard IO. Now however, if you're supporting more Windows than Linux servers, it's gonna be hard to ignore DSC, which stands for Desired State Configuration. DSC works with Windows and Linux, though the Linux support is kind of light at this point, and it's just an extension of the standard PowerShell. So with something like DSC, you specify the state that the server should be in, what I mean by that is, if you expect IIS to be present, than the state of that server is to have IIS installed. And this is gonna allow us to basically specify what things we need installed and what things we don't, and even ensure that our own application code is installed, and the correct version.
Here's an example of using Azure automation with DSC to ensure that IIS is installed. If you look at this PowerShell script, you can see that there's really not much to it. We have a configuration for installing IIS. We have a node that targets local hosts, and then we make sure that IIS is present on that node.
So to show you that I'm not pulling a fast one, we're gonna try to hit the IP address for that VM in our browser. And we can see that it's just not loading. And that's because we don't have anything listening on port 80. And as for the proof, I'm gonna show you that the web server role isn't enabled on this. So there you see it.
Our goal is to install IIS with DSC. For that, we're gonna go back to Azure Automation. I've already set up a DSC node. And it takes about 10 minutes for the VM to register, so I didn't want to subject you to sitting there waiting while I completed that, however, now we need to link it to a configuration. So I've added a DSC script. It's the one that I just showed previously. And I've compiled it with the compile option for that configuration. So now I'm going to link this node to the install IIS configuration. Now once I do that, you can see that it's pending. So that's going to take awhile, I'm gonna jump ahead, and we'll recheck in once this is complete.
Okay, welcome back. Okay, it's now complete and the status is compliant. That means that IIS should be installed. Alright, let's check it out. And to check it out, we're gonna reload the browser. And see if we get the IIS welcome page. And there it is. Okay, so with a few lines of PowerShell, we can ensure that IIS is installed on any of the nodes that we want to configure. Now this is a simplistic example but a good idea of what it's capable of.
Once you've started using configuration management to handle your server's configuration, that's it. You need to keep using it for any changes. If you make a manual change, it's possible that it's going to be undone by your DSC. Once you're using DSC, it needs to become the single source for changes.
Let's uninstall IIS and see what happens. Okay so we're going to remove it here from the list. And then we're gonna restart the VM. Now, I'm gonna wait a bit, we're gonna come back, and we're gonna show you what happens.
Okay now that we're back, you can see that we have a list of checks that show statuses of not compliant. That's because we manually changed this. Now we can certainly rerun this so that it reinstalls IIS, however that's why I said once you start using DSC, it should really become the single source of truth for changes. Alright, we've covered a lot in this lesson because automation really is quite the topic. In our next lesson, we're gonna summarize the key takaways from this course, so if you're ready to wrap up this course, let's get started.
About the Author
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.