How we create the Tentacle Army

Published on: 23 Feb 2015 by: Shane

One of the challenges of being an independent software vendor is using your software on infrastructure that resembles what your clients are using. Octopus Deploy gets installed on a variety of operating systems and deploys over every network configuration imaginable to targets ranging from a single tentacle to a thousand tentacle monster. Our typical development configuration consists of a server and one or two tentacles residing on the same machine. In that configuration everything works fine, it isn't until Octopus gets deployed into the wild that it starts to unravel.

The Tentacle Army

The Tentacle Army is our attempt to replicate the most demanding configuration that Octopus will run in. Before a release of Octopus is published we fire up the Tentacle Army and attempt to break the release. At the moment the Tentacle Army consists of 800 tentacles located in Singapore and Brazil, regions chosen for their high region-to-region latency. In this configuration we have 40 tentacle virtual machines with 20 tentacle instances per machine.

Provisioning the Tentacle Army

We use Amazon AWS to provide the infrastructure for the Tentacle Army. A configuration file specifies what we want in our test environment:

  "OctopusServerConfiguration" : {
      "Environments" : [ "Development", "Test", "Production" ],
        "InstanceType" : {
            "Value" : "m3.medium"
      "NumberOfInstances" : 1,
      "Platform" : "OctopusServer",
      "PrimaryStorage" : 40,
      "Projects" : [ {
            "Name" : "Multi release project",
            "DeploymentSteps" : [ {
                  "Name" : "Deploy package",
                  "PackageId" : "100mb",
                  "PackageUrl" : ""
                } ],            
            "Releases" : [ {
                  "Environment" : "Development",
                  "RepeatAfterMinutes" : 10,
                  "RunAfterMinutes" : 5
                } ]
      "RegionEndpoint" : "ap-southeast-1",
      "ServerInstallerDownloadPath" : "",
      "ToolsInstallerDownloadPath" : ""
  "TentacleConfiguration" : [ {
        "InstanceType" : {
            "Value" : "m3.medium"
        "Mode" : "Listening",
        "NumberOfInstances" : 5,
        "NumberOfTentaclesPerInstance" : 5,
        "Platform" : "Server2012_R2",
        "PrimaryStorage" : 40,
        "RegionEndpoint" : "ap-southeast-1",
        "TentacleInstallerDownloadPath" : ""
      } ],
  "VPCConfiguration" : [ { 
        "RegionEndpoint" : "ap-southeast-1"
      } ]

Through the configuration file we can specify:

  • the platform (we test Server 2008 32, 2008 64, 2012, 2012 R2)
  • the version of the Octopus server and tentacles
  • the number of tentacles and their location
  • environments, projects and automatic deployments
  • domain controller configuration

The configuration is fed into an application that calls the AWS API to provision the required machines. Once the machines have been provisioned they are set up via PowerShell. In addition to the Octopus server and tentacles, we also provision a NAT and, if required, a region-to-region VPN. The Tentacle Army ends up looking something like this:

Tentacle Army diagram

To infinity and beyond

The Tentacle Army has helped us to better relate to customers who put Octopus under pressure. We have been able to identify areas where Octopus struggles and felt the experience of managing a large number of tentacles through our UI. With a bit more work we will be collecting metrics so that we can benchmark our releases and validate the improvements that we continue to make on Octopus. We will also provide Tentacle Army as a service, allowing any team member to fire up a test environment and integrate the Tentacle Army into our automated process.