CloudAcademy
  1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. 70-534 - Design a Management, Monitoring, and Business Continuity Strategy

Azure Automation and PowerShell

play-arrow
Start course
Overview
DifficultyIntermediate
Duration35m
Students404

Description

This course covers the Design a management, monitoring, and business continuity strategy part of the 70-534 exam, which is worth 20–25% of the exam. The intent of the course is to help fill in an knowledge gaps that you might have, and help to prepare you for the exam. 

Transcript

Welcome back. In this lesson, we're gonna talk about Azure automation and PowerShell workflows.

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 wanna start using PowerShell with Azure, you need to install the Azure cmdlet and we can do that with PsGet or with the Web Platform Installer.

In this example, I'm gonna 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 that 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 wanna cover workflows. Now, workflows are different than 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 gonna 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 you 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 a concept of runbooks which are just a name for one or more tasks that we want to run. Runbooks allow us to select a 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 gonna authenticate us and then at the VM information for a resource group, aptly named resourcegroup, and if we try it out in the Test panel, we can see how it works.

Okay, it cues 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 in the source control and then we can have those versions. However, the GUI gives us a nice drag-and-drop experience. So, you're gonna wanna select the one that's right for you and your team.

While we're talking about automation, I also wanna cover configuration management because it's a part of Azure Automation 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 is going to be difficult to manage manually, imagine a hundred, a thousand, 10,000 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 wanna 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 gonna 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 I/O. 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, then 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 in 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 localhost 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 and 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 further proof, I'm gonna show you that the web server role isn't enabled on this. So, there you see it, okay.

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 don't wanna 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 this is gonna take awhile. I'm gonna jump ahead and we'll re-check in once this is complete.

Okay, welcome back. It's now complete and the status is Compliant. That means the IIS should be installed. 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 wanna 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 servers' 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 gonna 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 gonna remove it here from the list and then we're gonna restart the VM. Now, I'm gonna wait a bit. I'm 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 and now we can certainly rerun this so that it re-installs 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 is really quite the topic. In our next lesson, we're gonna summarize the key takeaways from this course. So, if you're ready to wrap up this course, then let's get started.

About the Author

Students31476
Courses29
Learning paths16

Ben Lambert is the Director of Engineering 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 the first platform to run and measure enterprise transformation initiatives at Cloud Academy, he’s hiking, camping, or creating video games.