In this post, I'd like to discuss some of the changes we're making to Tentacle, and deployment targets in general as part of Octopus 3.0.
Summary:
- Multiple types of "machines" (Listening and Polling Tentacles, SSH, Azure Websites, Azure Cloud Services, WebDeploy, offline drops)
- Tentacle as a shell
- Open sourcing Tentacle
- FTP deployments no longer supported
Multiple types of machines (deployment targets)
Octopus and Tentacle were designed together, and it was assumed that the only kind of "target" that Octopus would deploy to would always run Tentacle. In 2013, we added support for Azure Cloud Services and FTP sites, both to handle situations where installing Tentacle wasn't possible. These didn't appear on the environments page, weren't involved in health checks, and deploying to multiple of them in parallel (e.g., uploading to multiple FTP repositories) wasn't possible.
Some of our most common feature requests were to add support for new kinds of deployment targets: specifically, support for deploying to Linux servers, better support for deploying to Azure websites, and the ability to deploy to "offline" machines by creating a package that could be manually executed.
To do this, we'll be expanding the concept of "machines" in Octopus to a more general concept of "deployment targets". From the environments page, instead of adding a machine (which always meant a Tentacle), you can add different deployment targets:
Previously, for FTP and Azure cloud service steps to work, you had to have a special Tentacle running on the Octopus server. For 3.0, this will no longer be required; Octopus will be able to push Azure Websites/Cloud Services natively.
As you can see in the image above, we're adding a few new deployment targets. The SSH target allows you to deploy to any server that runs SSH, using either username/password authentication or certificates. These could be Amazon AWS Linux instances, your own on-premises Linux servers, machines running OSX, or even a Raspberry Pi. Instead of running PowerShell scripts, we'll execute bash scripts. You can read more about Linux/SSH plans in our RFC.
The WebDeploy target will allow you to deploy to any server that has WebDeploy enabled. Some third party hosting vendors, as well as Microsoft Azure, support WebDeploy. A specific Azure Website deployment target uses the WebDeploy client under the hood, but will be easier to set up (once you connect Octopus to your Azure subscriptions, you'll be able to pick the websites from a list).
Offline drops are a special deployment target which will bundle all the files needed to execute the deployment, and put them on a file share ready to be coped to a USB drive and deployed manually.
Just like Tentacles, these machine types can be tagged with roles, and you'll be able to deploy to them in parallel. For example, if you have two Azure websites in different regions, you could give them the same role, and then set that role as the target of a NuGet package step - the package will then be pushed to both sites in parallel.
Depending on the targets, deployment logic will be executed slightly differently. For Tentacles and SSH deployments, we'll execute config transforms and run scripts on the remote target machine. For Azure websites, cloud services and WebDeploy, they'll be executed on the Octopus server and then uploaded. For offline drops, they won't be executed at all, instead the code needed to execute them will be included in the bundled package.
Going forward, we have plans for more target types, specifically a PowerShell Remoting target. These are just the ones that will ship as part of Octopus 3.0.
Tentacle as a shell
Another big change we're making is to how Tentacle is currently designed. At the moment, Tentacle is an agent that communicates with Octopus. It knows how to do many things:
As an example, the C# code that makes up Tentacle knows how to do configuration transforms, modify IIS, and a load of other things. If we ever need to change how these features work, we we had to release a new version of Tentacle.
As we added SSH support, we realised that the same architecture couldn't work - all SSH can do is to run commands and move files. All the logic and conventions for configuration transforms, etc. would need to be pushed over from the Octopus Server.
Decoupling the communication logic (the SSH side of things) from the deployment logic is a much nicer architecture. So we've decided to do the same for Tentacles in 3.0: Tentacle will just know how to run commands or transfer files, over a secure connection. All the logic and tools for deployments will be sent up from the Octopus server, meaning Tentacle upgrades will be far less common.
From 3.0 onwards, think of Tentacle as a Windows-oriented version of SSH, except with support for both polling and listening modes. All it knows how to do is to execute PowerShell scripts, or transfer files. Everything else - the config transform stuff, the IIS stuff - will be PowerShell scripts that Octopus will ensure exist on the Octopus server prior to deployments executing.
Open sourcing the core package deployment components of Tentacle
Now that we're decoupling Tentacle the communication channel from Tentacle the deployment engine, we gain a new possibility: all the scripts and deployment logic that Tentacle executes during a deployment (as well as the scripts and tools used in SSH deployments) can now be open sourced. Our plan is to manage this as a GitHub project. If you don't like the scripts that we call during a deployment, you'll be able to fork this, build your own Tentacle package, put it on the Octopus server and use your own scripts/tools during the deployment instead. It will also mean we can take community contributions, which will be especially helpful for supporting the various Linux distributions.
Dropping support for FTP
Looking at our usage statistics, FTP is the least commonly used deployment target (~253 FTP steps in the world, compared to 36,000 NuGet package steps), and I suspect most of these are for Azure websites.
Since we're adding native WebDeploy and Azure Website support, it's hard to justify continuing to maintain FTP as a standalone step or machine type. For this reason, we'll be deprecating it. We'll make a step template that uses a command-line FTP tool which could be used as a replacement instead.
Conclusion
We still plan to release a preview of Octopus 3.0 around late March/early April, even if all these deployment targets aren't fully complete by then. In the mean time, we'd really appreciate your comments on our plans above, especially on open sourcing the core deployment scripts/tooling. Let us know in the comments below!