Bootstrapping Linux VMs with DSC in Azure

Part 2: Doing it in Azure

This is part two of a three part series on using DSC and Azure Automation to configure Linux.

You can find part one: “Getting started” here.

Part three: “Automating it all together” is located here.

In part one of this series, we used a Linux test host to create a Desired State Configuration (DSC) file, and then we configured the test host using it. But the title says Azure… so let’s get into it cloud-style.

Getting things ready

The first thing you need is an Azure Automation account. Go into the Azure Portal, and search “All Services” for automation.

Or however else you want to find it…

We’ll click on “Automation Accounts”, and then click the “Add” button.

I’m going to call my account “DSCTestAutomate”, and I’ll create a new Resource Group to hold it (and the other test items). Click “Create”.

That should kick off a deployment that creates the Azure Automation account, as well as some “Run As” accounts. If you’re a guest user in your Azure AD, then creating the “Run As” accounts will fail…but you don’t need them for what we’re doing.

About 13 seconds later (in my case) your new Account and Resource Group will be ready to use.

Adding the “nx” module to your Automation Account

In Azure Automation DSC, you upload your Powershell DSC files and Azure compiles them to the MOF format for you to store on the built in pull server.

Most of the important Powershell modules are pre-staged on the Azure compilation service, but the one we need most — the magical “nx” — is not. If you try and compile any of our test Powershell configurations without fixing this you’ll get an error.

Oops…

To fix this, you have two choices. Either you can download the “nx” module locally, zip it up, and upload it to your Automation account, or you can look for it in the Module Gallery.

And then select and import it.

If you check your Automation Account Modules, you’ll see now contains the “nx” module.

It takes a few minutes to get through Importing and be Available.

Now that you’ve gotten it ready, let’s start with Azure Automation DSC.

Getting the first configuration

So let’s take our /tmp file example from the last post and paste it into a .ps1 file.

root@ubuntuservtest:~# vi dsctestlinux.ps1
root@ubuntuservtest:~# more dsctestlinux.ps1
Configuration dsctestlinux{
Import-DscResource -ModuleName PSDesiredStateConfiguration,nx
Node  "TestDSCLinuxfile"{
    nxFile ExampleFile 
    {
        DestinationPath = "/tmp/example"
        Contents = "hello world `n"
        Ensure = "Present"
        Type = "File"
    }
}
}

And then we can upload it. For this first one, let’s take it simple. Go back into the Azure Portal, find our new Automation Account, and click on “DSC Configurations”.

We’ll click the “Add a configuration” button. Then we can browse to where our file is located and select it. This starts the upload. Let Azure fill in the name for you (it parses it from the Configuration statement in the Powershell file when it uploads).

Then click “OK”. Your configuration is now in Azure…but it’s not ready yet. Now we have to compile it.

Your Configuration is now in Azure.

Let’s click on the name of our dsctestlinux configuration. This will open the configuration detail window.

So from here we can “View configuration source” that will show us the raw Powershell we just uploaded. And we can export our configuration file back out of Azure. But what we need is to compile the configuration into the MOF files. So click the “Compile” button.

This submits a compile job to the Azure Automation service. You’ll see that your job is now queued.

You can also click on the Queued job to get details and errors. If you’re impatient you can also see when it’s moved from Starting to Started.

After a few minutes, the job should complete.

(That first suspended job was what I did to generate the nx error for you.)

You should see a new Node configuration available, named in the form of Configuration.Node based off of your Powershell code. This means your Node configuration is compiled, uploaded to the pull server, and ready to be assigned to nodes.

Getting a node connected

So our next step is to create a Linux virtual machine in Azure and get it connected with Azure Automation DSC. I’m not going to go into how to create the virtual machine here, but for our purposes I’ll create a test node running Ubuntu 16.04 LTS of instance size “Standard B1s”. I’ll open SSH to it from the internet in the Network Security Group so I can see the results of our testing. I’ll call the node “DSCLinuxTestNode1”.

Waiting…

The sharp-eyed among you might notice my VM is in a different Location than my Automation Account (East US vs. East US-2). This is fine! Automation Accounts can only be built in 12 certain regions within Azure, but you can use the account across all regions.

Once the node is finished building, I’ll SSH in to check the /tmp folder contents:

dmills@DSCLinuxTestNode1:~$ ls /tmp
systemd-private-53367f32d0134db399ed4714a73ff2cd-systemd-timesyncd.service-oyfbfI
dmills@DSCLinuxTestNode1:~$

Now let’s go back to the Azure Automation Account in the portal and look at another part of the options — “DSC Nodes”.

I’ll click “Add Azure VM” and search for my new node in the search box. When it comes up I’ll click it and then click “Connect” in the new dialogue.

Got a little cray-cray with the erase tool!

That will bring up the “Registration” dialogue. Let’s talk about this one for a minute.

As you can see, I’ve chosen the “Node configuration name” to be our test /tmp file configuration we uploaded and compiled (dsctestlinux.TestDSCLinuxfile). As for the rest of those boxes, a few have some interesting choices.

“Refresh Frequency” is how often the node’s LSM (Local State Manager if you forgot) will poll the Azure Automation service looking for new configuration data under the same name as we assigned it.

“Configuration Mode Frequency” is how often the node’s LSM will attempt to implement the configuration it’s pulled. Both of these are measured in minutes.

“Configuration Mode” gives you three choices:

1. “ApplyAndMonitor” means apply the configuration and then report back to the Automation service if what was configured changes (this is the default).
2. “Apply” means just apply the configuration and that’s it.
3. And “ApplyAndAutoCorrect” is an interesting choice that means apply the configuration, and if it changes, re-apply it and alert the Automation service. This is often how other configuration management tools (Chef comes to mind) operate.

Ok for so now we’re going to leave everything as the default but our “Node configuration name”, and click “OK”.

Azure Automation DSC will now be connecting to the node, and installing the “DSCForLinux Extension” that allows it to work with the service (we’ll talk a lot more about this next installment). After a few minutes, you should see the below:

If I click on the node name, I’ll open a detail box that has the status and initial report from the node.

Looks pretty good from here…

The node should have configured itself on registration, and I see a “Consistency” report of compliant, so let me go back over to that SSH session to the test node.

dmills@DSCLinuxTestNode1:~$ ls /tmp
example
systemd-private-53367f32d0134db399ed4714a73ff2cd-systemd-timesyncd.service-oyfbfI
dmills@DSCLinuxTestNode1:~$ more /tmp/example
hello world
dmills@DSCLinuxTestNode1:~$

And there we are! We’ve now successfully used Azure Automation DSC to upload our Powershell configurations, compile them in the Azure service, extract and create the node configurations, register a new node, and then apply the configuration to that node.

In the Next Episode

For next time we’ll be true DevOps mack daddies (or daddy macks if you prefer) and get rid of all this Portal GUI nonsense. There will be templates, and Powershell, and a lot of crazy automation happening all over the place. Come back, and bring a poncho or umbrella.