Octopus was designed to be a single, central point of truth for application deployments. In an ideal world, you would only need one Octopus server, and then many Tentacles. Octopus uses a secure communication channel when communicating with remote endpoints, and can work in both listening and polling mode, giving you multiple options to work around firewall issues.
Of course, the real world and the ideal world don't always overlap, and you might need to have separate Octopus servers. Common examples are:
- Solution providers with an internal Octopus server for pre-production deployments while developing a solution, and then Octopus servers managed by the client for production deployments, on different networks
- When company policies require production and pre-production environments to be on completely isolated networks, like PCI compliant environments. Learn about PCI Compliance and Octopus Deploy.
On this page, we discuss two different scenarios, and the features and options that exist for dealing with them.
Tentacle Can't be Installed (Offline Deployments)
Chris's Consulting are developing an application for a government client. They're using Octopus internally to manage pre-production deployments (dev, UAT, and so-on). However, the client have advised that they won't allow the consultancy to install the Tentacle agent on their production servers, nor the Octopus server. They'd prefer the consultancy to provide them with a something they can run from a USB stick.
In Octopus 3.0, you can configure an Offline Package Drop deployment target. This allows you to "deploy" to a location on the filesystem and take that deployment offline to be used elsewhere. The dropped package contains everything you need to deploy to a location offsite.
Tentacle Can be Installed (Isolated Octopus Servers)
A credit card processing gateway have decided to use Octopus to manage deployments. For PCI-compliance reasons, the production environment is required to be on a different network to the pre-production environments, and very little is shared. Since they own the servers, they can install the Octopus servers and Tentacles on each environment, but they just can't share an Octopus server between environments.
In this scenario, the customer would install different instances of Octopus in both environments. To keep settings in sync and to automate between environments, they can use a combination of strategies:
- They could use the new data migration tool to export the internal Octopus Deploy configuration to a folder. The resulting folder tree could be imported into the production Octopus instance. This will result in a duplicate configuration in the production environment.
- The migration tool could be reused periodically to keep both servers in sync. Because the resulting export is simply a collection of JSON files in folders, a source control system like Git could be used for this purpose. Any imports subsequent to the initial import would result in a merge of any changes.
- They can manually keep some additional settings in sync, such as common Nuget feeds.
- Packages can be moved between environments using NuGet.exe to push packages to both Octopus servers. For example, the CI server could publish packages to both the pre-production and production Octopus server after a build, or they could manually use Nuget to push them when ready to promote.
- Finally, to automate anything else that isn't possible above, the REST API or Octopus.Client can be used.
Friendly multi-instance licensing model
Your Octopus Deploy license includes the ability to install and configure up to three (3) separate instances of Octopus Server to support scenarios like this one.
Tentacle can be installed but communication must go via a proxy
An agency manages lots of small applications on behalf of their customers, and wants to use Octopus to manage deployments. Quite often the production environment is managed by the customer and even after being convinced to allow the Tentacle agent to be installed on their servers, they want communication to be controlled by a proxy server.
In this scenario you would install Tentacle onto the customer's servers, but configure all communication to go via the customer's proxy server. Learn about proxy support in Octopus Deploy.