Sorry if this question is answered in the docs, but they’re currently unavailable.
Basically we have three different data centers that we need to deploy our software to, with about 20 target machines in each. Whilst we can simply expose each machine on the WAN for deployments this feels a bit of a risk and a maintenance overhead. Maybe it’s possible to deploy to a single tentacle in the remote data centers and have that tentacle forward the deployments on to the internal machines. Also we’d like to use a mix of linux and windows machines.
Thanks for getting in touch! The docs are back up, sorry for the troubles!
Listening Tentacle communication is secure. It’s the most reliable and best method for deployments and has the least amount of wait for a deployment to happen. I can point you at corresponding communication and security documentation if you require it. There really should not be much maintenance at all, and once opened it gives you the most flexibility for more than deployments, in many cases it takes away all need to RDP and connect to the machines.
If there is just no convincing networking and security to open up the one port, then there is the Polling tentacle method.
We have no plans to implement a relay style deployment pipeline, it has been discussed at length but was determined something we did not want to support.
Thanks for the response - unfortunately we have servers that we’d like to deploy to that do not, nor ever would, live on the network edge so opening them up to the outside world is something we couldn’t do.
I’ve found this http://community.octopusdeploy.com/t/relay-tentacles/305 which implies that you are looking at this style of deployment, are you saying that you have now changed your minds and won’t be supporting it?
When we looked at all the options we would support with HA relay was on the table, but we determined in the end it wasn’t something we would be able to support as a solution - so yes that is what I was talking about with ‘discussed at length’.
There is another option that customers use when they are in completely locked down environments. We suggest an Octopus instance inside the DMZ and use of the import/export features to keep it in sync with the external/main Octopus server when needing to deploy. It’s has some maintenance overhead, but it all could be scripted.