Monthly Archives: May 2017

Introducing StatusCakeDSC

I recently published a new open source PowerShell project for creating StatusCake checks and contact groups, called – logically enough – StatusCakeDSC.

If you use StatusCake, and you do Infrastructure as Code, then you may be thankful for a nice declarative way to define and manage your checks and groups. For PowerShell users like myself, that declarative syntax is generally DSC.

I happen to use StatusCake for my personal projects, which I’ve been modernising a little of late, and I figured I should just build and publish a nice little DSC resource to do what I need done. The syntax of it is pretty simple, it’s like pretty much every other DSC resource you’ve ever seen. Look

configuration StatusCakeExample
{
    Import-DscResource -ModuleName StatusCakeDSC
    node(hostname)
    {
        StatusCakeTest MyTest
        {
            Name = "D.Evops.co"
            Ensure = "Present"
            URL = "http://d.evops.co/"
            Paused = $true
            CheckRate = 50
        }

        StatusCakeContactGroup MyGroup
        {
            Ensure = "Present"
            GroupName = "My simple Contact Group"
            Email = @("test@test.com", "test2@test.com")
            PingUrl = "http://d.evops.co/ping"
        }
    }
}

StatusCakeExample -outputpath $env:tmp\StatusCake

Start-DscConfiguration -Path $env:tmp\StatusCake -Verbose -Wait -Force

That example creates a test and a contact group. There are more examples over at the repo. There’s also a simple install script, and a little further down the line there’ll be an Octopus Deploy step template and maybe some other goodies.

It’s not production-perfect, but it certainly does the basics. I’ll probably declare it ready in a week or two, at which point I’ll publish it as a package and maybe even wrap it in Chocolatey or PowerShellGet to make it even easier to install. Do feel free to let me know if it’s useful, and drop in PRs if you spot bugs or gaps.

Turn your PowerShell scripts into a Web API – three options

So, you’ve got a load of PowerShell code that does useful stuff, and because you’re doing Modern Windows Ops now, you want to port that code into some kind of web-based API, so you can scale it out and make your epic PowerShell code accessible from more devices and environments.

You don’t want to rewrite it all in C# as an ASP.NET Web Api – for an ops engineer that seems like terrible overkill. Besides, who’s got time for that nonsense? Modern Ops teams are busy as hell, even though they’ve got automation everywhere. You could get devs to do it, but then you have to manage requirements and specs and Jira tickets oh god not Jira tickets. Please anything other than Jira tickets NOOOOOOOOO!

Ahem *cough* excuse me. Where was I?

Oh yes.

If only there was a way you could take your existing PowerShell code and turn it into an HTTP API quickly and easily.

Well, it turns out there are lots of options now. Check below the fold for three I’ve used recently.

Continue reading →

Blog Update 17 May 2017. Job stuff, Wannacry and MVA

So, what’s been going on? I’ve been a bit lax in blogging here of late, which I hope to fix in the near future. So what’s the news?

Well, new item number one if that I’m about to move on from Domain Group, where I’ve been Windows DevOps Wonk for the last three years, and head to Octopus Deploy, where I’ll be doing some really exciting Cloud Architecture work and generally trying to reach as many people as possible with the good news of Modern Windows Ops.

So that’s the first thing out of the way. What else has been going on?

Oh yeah, there’s that whole WannaCry thing which went by. At Domain we were entirely unaffected. Why?

Well, most of us are running Windows 10 on our laptops, which was immune to the specific vulnerability. That was a major factor. But I don’t manage the client OS fleet. I manage the servers.

Good solid firewall practice was a major factor. SMB would never be open to the internet, and we have periodic security scanning that checks our Cloud environments against an exhaustive set of rules. We absolutely don’t allow SMB shares on our fleet – that was common practice at one time, but rapidly deemed anticloud because it does nothing except enable bad deployment practice.

However, an interesting wrinkle on the subsequent community debate: At Domain, we turn off Windows Update on our Robot Army Windows Server fleet.

“WHAAAAAT?” you say. “WHYYYY?”

There’s a specific reason for these instances. We found quite early on that occasionally Windows Update would fire off on instances, and push CPU usage to 100%, triggering scale-up events. In some cases, we’d end up with alerts and minor outages as a result of this behaviour. It also skewed the metrics we collect on resource usage by causing spikes at weird times, and was known to delay deployments

So we made a considered, reasoned decision to disable Windows Update on the autoscaling fleet. That’s a few hundred boxes right there.

As threat mitigation, we don’t allow RDP access to those boxes, we run Windows Server Core Edition with a minimal set of features enabled, and we closely monitor and correct changes to things like Security Group rules, service state and installed Windows features. All boxes are disposable at a moment’s notice, and we renew our AMI images on a regular basis – sometimes several times a week. Those images are fully patched and tested – with a suite of Pester tests – at creation time. We also maintain a small number of more “traditional” servers, which do have updates enabled, but none of these run customer-facing workloads

Make no mistake, Troy Hunt is absolutely right that no client OS should have updates disabled. But a modern server workload may have a case for it, as long as other measures are taken to protect the OS from threats. Your mileage may vary. Treat all advice with caution. I am not a doctor.

Last, here’s a new bit from Microsoft Virtual Academy (published 15 May 2017) which I think did a decent job of explaining modern DevOps practices to the curious or confused. The video and I certainly differ on some specific points of dogma, but the big picture is good – automate, tighten your feedback loops, throw away the old stuff, treat servers as software objects, move fast, apply laziness early on, build often, deploy often etc. Worth a look even if you’re a grizzled veteran, I’d say.