Configuring Octopus Deploy and Tentacles

Installing Octopus Deploy is a fairly trivial task. Updating Octopus Deploy is a slightly different story, but I’ll address that in another article.

TL;DR I’m diving into registering tentacles and servers as that’s the most challenging part in an Octopus Deploy installation if you’re unfamiliar with the terrain. I’ll address some possible issues that may crop up and how to avoid them. I’m not going into great detail how to install the server and tentacles as it’s pretty simple and there are documents direct from Octopus Deploy’s documentation site on how to do so.

There are essentially four aspects of installation and configuration: installing the Octopus server, the Octopus agent (or tentacle), registering both components with each other and storing your packages. I’ll address the packages in another article and skip dealing with installing both components as it’s very straightforward. In fact, the folks at Octopus Deploy already have a nice video on how to install the server here: http://docs.octopusdeploy.com/display/OD/Installing+Octopus

The tentacle instructions are readily available on the same site as well: http://docs.octopusdeploy.com/display/OD/Installing+Tentacles Rather than reiterate the obvious, I’ll just focus in on the registering of tentacles and server.

Installation note: While installing the tentacle, they’ll recommend using a listening mode (push) rather than polling mode (pull) system of communication. I’ve never tried polling, nor do I see any need to at this point. If you have no preference, go with listening.

Now to the good stuff; registering tentacles with Octopus. When beginning your first Octopus Deploy installation, there are three things to keep in mind:

• Make sure you have a clear network path to the server from the tentacle
• Make sure the firewall ports to be used on your server and tentacle are open
• Keep the thumbprints handy when registering the tentacles and server to each other

The network path and firewall ports will simply make registering easier. Keep in mind firewall ports on the Octopus server do not have to match the tentacles and vice versa, they just need to have an open path to one another. After the tentacle installation, there’s a setup wizard. In that setup you’ll notice that a port was required as part of the installation.

Make sure the port number is opened on your Windows Server firewall only on the tentacle itself and that the server itself can access the Octopus server. If not, you may receive an error message when you try to register the tentacle.

Once you’ve copied the thumbprint (from the Octopus server) to the listening tentacle, you should see another install button. Hit that button and your screen should appear similar to this:

Side story:
The recent project I had at a large client had numerous network configurations world-wide; multiple zones and intricate port restrictions between said zones. One of the biggest features in Octopus isn’t given enough credit: the ability to have tentacles on different ports than the server itself. At first, I didn’t understand how this worked. I had gone so far as to ask on the support forums just how ports worked in Octopus.

For large companies with numerous network restrictions, this is a huge feature. For smaller organizations with less to manage, I imagine it’s not such a big deal. So what’s this mean for you?

Take this scenario for example:

Keep in mind this example drastically understates all the complexities between networks. It’s meant to show that the Octopus server does not need one specific single port for tentacles to register to! 

You should know in advance how your servers are currently communicating with one another within your organization beforehand so you can determine if there is even a path that the Octopus server can communicate with the tentacles. If not, then your network team may have to reconfigure some security measures or create a new network configuration where all the tentacles have a way to communicate with the Octopus server. The Octopus documentation site mentions how communication between Octopus and the tentacles actually works (link).

Regardless of whether Tentacle is in listening mode or polling mode, all communication between the Tentacle and Octopus is performed over HTTPS. Octopus and Tentacle both have a public/private key pair, that they use to establish the HTTPS connection (one is the TLS server and presents a server certificate, the other is a TLS client and presents a client certificate).

 

Back to the registration. Once the tentacle is installed, you can attempt to discover the machine from your Octopus server interface.

You can then assign the new tentacle to an environment and a role. Roles are essentially dynamic labels you can assign to servers. Whatever role you desire, you simply type it in and it will be an available role for all tentacles. It’s more of a meta filter for when you want to deploy to specific types of tentacles.

Once you hit “Save”, you should see the environment screen with the newest tentacle added to your environment.

Keep in mind that this alone does not mean the tentacle has successfully registered. The next step is to check the health of the environment. 

You’ll be taken to the Task summary for the Check Tentacle health in your environment.

Click on the Task log tab to view the details of the health check.

Green is good. Your tentacle is now good to go.

You may have noticed that during your installation of the Octopus server, there’s no mention of SQL Server or IIS. That’s because Octopus uses RavenDB as the embedded database of choice and NancyFX as the embedded web server. At first glance this may seem to be a shortcoming as some organizations may want to harvest any information in the SQL Server database or customize the web server in IIS, but I’ve learned to view both design choices as bonuses. I will discuss the database and web server technologies in further detail in the next articles in this series.

So we’ve focused in on the registration of tentacles and some of the pitfalls to avoid. In the next article, I’ll cover the one of the two components of Octopus; first the database (RavenDB) followed by the web server (NancyFX) and why they’re an important and positive feature to have rather than the traditional SQL Server and IIS that Windows applications are accustomed to using.