I wanted to make sure of sharing this because it really saved my bacon this week. There’s a longer post in the pipeline, possibly over at Domain’s forthcoming Tech Blog, but here’s the meat.

For the last couple of sprints I’ve been working on an end-to-end CloudFormation/DSC solution to stand-up new load-balanced, auto-scaling, self-healing, IIS8.x clusters ready to host various websites and microservices.

End-to-end of course means everything. No-touch from running the initial New-CFStack call to, 20 minutes later or so, hitting the LB in a browser and seeing our app-code in production.

Among the many pre-requisites for this is a configured Octopus Deploy Tentacle, and that’s what I’ll chat about here for a moment.

For my initial assault on the auto-configuring this beastie, I decided to follow this guidance. Installing the tentacle is not much of a hassle at all. Using DSC’s Package resource, I could pull down the tentacle installer either directly from the Octopus website, or from an S3 bucket, and install the MSI. The code for that is easy enough.

Download

Invoke-WebRequest `
    -uri http://octopusdeploy.com/downloads/latest/OctopusTentacle64 `
    -outfile c:\oh\pkg\OctopusTentacle_x64.msi

 Install

Package OctopusTentacle
{
    Ensure = "Present"  
    Path  = "$Env:SystemDrive\oh\pkg\OctopusTentacle_x64.msi"
    Name = "OctopusTentacle"
    Arguments = "/q"
    ProductId = "[varies dependent on package version]"
    DependsOn = "[Script]S3SharedFiles"
}

 Configure

cd "C:\Program Files\Octopus Deploy\Tentacle"
 
Tentacle.exe create-instance --instance "Tentacle" --config "C:\Octopus\Tentacle\Tentacle.config" --console
Tentacle.exe new-certificate --instance "Tentacle" --console
Tentacle.exe configure --instance "Tentacle" --home "C:\Octopus" --console
Tentacle.exe configure --instance "Tentacle" --app "C:\Octopus\Applications" --console
Tentacle.exe configure --instance "Tentacle" --port "10933" --console
Tentacle.exe configure --instance "Tentacle" --trust "$thumprint" --console
Tentacle.exe register-with --instance "Tentacle" --server "$optupusUrl" --apiKey="$api-key" --role "$role" --environment "$env" --comms-style TentaclePassive --console
Tentacle.exe service --instance "Tentacle" --install --start --console

However, while this works perfectly when run in a test scenario, it refuses to run from CloudFormation.

Why?

Well, to cut a long investigation short, I discovered that the certificate generation utilises Windows DPAPI, and Windows DPAPI refuses to run if a user profile is not loaded.

So ensued a largely fruitless quest to make a profile load from CloudFormation’s Launch Config. I tried Powershell’s Invoke-Command. I used generated batch files. I tried to create a scheduled task and execute that. I tried Sysinternals PsExec. I tried importing a pre-generated certificate. Nothing helped.

On the brink of going insane, I pinged a message to the developers of Octopus Deploy. The first option offered was the import-certificate option. Which I’d already tried, but the second option was a quite new (three weeks old) Octopus DSC module.

DSC always loads a profile. This was precisely what we needed. So I pulled it down, and added it to a zipfile which we load from S3 with various other DSC modules in it. This gets installed to c:\Program Files\MicrosoftPowershell\Modules so will be available straight away. I then added some code to the config DSC script.

cTentacleAgent OctopusTentacle 
{ 

    Ensure = "Present"; 
    State = "Started"; 

    Name = "Tentacle";

    # Registration - all parameters required
    ApiKey = "<apikey here>";
    OctopusServerUrl = "<url here>";
    Environments = @("staging");
    Roles = @("auth-service"); 

    # Optional settings
    ListenPort = 10933;
    DefaultApplicationDirectory = "C:\Octopus\Applications"
    DependsOn = "[File]OctopusFolder"
}

Running this didn’t quite get us there. There were a couple of further, tiny obstacles to overcome. OctopusDSC tries to pull down the latest tentacle version, but this failed for me a few times, so I downloaded a version myself, as above, to c:\Octopus. This was OK. But I also experienced a few module load issues. So I had to throw in a reboot to make sure the OctopusDSC and xWebAdministration modules were available to our DSC config script.

Et voila, the clusters stood themselves up, fully configured.

All that remained after that was to fire off octo.exe with the right parameters to trigger a deployment of the latest code and we have an autoscaling, self-healing CloudFormation/DSC LaunchConfiguration that takes under 20 minutes to spin up a brand new Windows Server 2012 node, complete with troubleshooting tools, monitoring tools, app code, management tools, an idempotent configuration management script and auto-deployment in-place. We now live in DevOps Shangri-La with a herd of Unicorns.

There’ll be a longer post on this at the Domain Tech Blog, but I just had to get out the news that OctopusDSC exists and works with near-perfect panache.

I cannot commend the Octopus Deploy guys enough for their work on this excellent product, and the fact that OctopusDSC now exists is just the icing on a very delicious Continuous Depoyment cake for us. Cheers!