Our client host their web site on hosting platform we can only reach by connecting to the client’s VPN.
We’re looking at Octopus Deploy to help us introduce better deployment practices, my understanding is that a tentacle would need to be installed on the servers within this VPN - but I’m not sure how we initiate the connection?
Can Octopus Deploy do this for us prior to pushing the NuGet package or would it have to be something we do manually (run the VPN client) before promoting any deployment?
It would need to be something you do manually. You could have a script that establishes the VPN, then uses Octo.exe to trigger the deployment, and then shuts down the VPN connection.
Another alternative might be to place your Octopus server within the VPN too.
We also use a VPN to connect to a production environment in Atlanta. What is involved in our process is that we plug our VPN token in to the server and use our credentials to open the connection between the Octopus server to the tentacles.
When I go to our environments tab, I then see that the health is now all green lights. From here, I can easily promote any particular release to the Atlanta environment. Paul’s idea above is going a little fancier by doing all of this automatically using Octo.exe. In both cases, you will get everything displayed in the Octopus web interfaces because the same calls are made to the Octopus server to promote a release.
When you say “we plug our VPN token in to the server” can you clarify?
Sounds like you manually create your VPN connection on the Octopus server, then come back into the web gui and then promote?
We’ve come with a potential work around - we’ve installed a tentacle on the Octopus serve itself. Then our first step is a Powershell to initiate the VPN connection on that server, then subsequent steps to deploy followed by a final step to close the connection. Early tests seem to show it works as each step is executed in order, which ensures that the VPN connection was successful before deploying.
One problem you might run into is that package uploads happen before the steps (run a powershell script, deploy a NuGet package, etc.) are executed. We do this so that if the packages fail to be uploaded we don’t get half way through a deployment.
You may find the following post useful for planning your Octopus configuration:
All packages are uploaded to the appropriate Tentacles
All steps are then executed, and packages are installed in order
The reason for this is that for a large application being uploaded over a WAN, step 2 can take a long time. So it would cause problems if we were to start executing steps (which might include taking applications offline, changing database schemas, etc.) only to fail when uploading the last package because of a network problem. By uploading everything first we can increase the chances of “failing fast” rather than “failing slow”.
We have the same issue, at the moment I’ve written a bat file that opens the VPN, waits for a keypress, then closes, so I do my Octopus bit in the middle.
Obviously not ideal - and means our servers fail health checks. Would be good to have the ability to run some powershell before and after connecting to the Tentacle
It looks like I might have to configure our implementation similar to “Scenario 3 :Off-Premise Installation with Off-Premise Deploy” but how can I best achieve this if I have three of these environments? ie. each preprod (ie. DEV, INT, TEST), staging and production need to be configured in this manner?
If we added the ability to create a “VPN” and associate it with machines in Octopus, could that be a workable solution? Octopus could establish the VPN, then check health etc., and then shut it down.
Unfortunately we have to use the proprietary Cisco VPN client that someone mentioned above. It comes with a command line utility for connecting/disconnecting that we could call from PowerShell. Was thinking it might be a bit much for Octopus to try and support all the different clients out there but I might be missing something
We do have 3 separate clients that use this same VPN software for server access so it might be more ubiquitous than I realise!
If the VPN option is added I would love to buy Octopus Deploy!
As you mention, let Octopus manage the connection to the specific servers.
in our case the deployment to multiple servers for a specific build is always via the same VPN per environment (test and production) use a diffent VPN.
hey Paul, is this something that’s likely to work in Octopus 2? We’re also in the scenario of a Cisco VPN client so would need a pre-upload and post-deploy client script to run in all likelihood?
Yes, Octopus 2.0 supports the ability to set up a PowerShell script that runs prior to package download/upload, as well as at the end (even if deployment failed).
We have an identical setup with the Cisco VPN client being started in a step before and after the other steps of the deployment.
One issue we’re having is that we can no longer use Tentacle retention policies, as they run after the last step, where the VPN has been disconnected. For now the workaround will be to keep everything, but we would really like to use retention policies.
Is there any possibility of adding special pre/post release steps/powershell scripts? Or alternatively scripts per environment for begin and end of deployments? The latter would possibly enable the health checks and scheduled retention policies for tentacles behind a VPN to work too.
I manage solutions for several corporate clients that are deployed to their own servers behind VPNs, and while I will be manually starting and stopping these VPNs via scripts, it would be a massive relief to have Octopus Deploy able to manage the more common VPN solutions for us. For us specifically, we use Cisco VPN Client, Dell SonicWall NetExtender etc.
