Two VPS, Octopus Server, Jenkins - Deployment Process Design

I come to you with a question about designing a continuous integration process.
We currently have an application that uses a single database, has a single API composed of multiple projects (.Net Core), while the frontend part is implemented in Angular.
We have a production server (VPS, Windows Server 2019) and the deployment process has been done manually so far.
We wanted to create the above mentioned process to improve the current solutions. For this purpose, we bought a new server (VPS, Windows Server 2019) and created a deployment process there based on Jenkins, Octopus Server, Octopus Tentacle and IIS server.
Everything works fine, but we don’t know how we should approach promoting the current solution to production.
We would not like to duplicate the entire infrastructure (Jenkins, Octopus Server), but only move the proven and tested version of the application to the production server.
For this purpose we wanted to use:

so that on the production server, some tool (Octopus Tentacle?) would listen for the command to deploy a new version of the application instead of the currently running instance.
The problem is that the test VPS server (#1) is in a completely different network and subnet than the production server (#2). Is such communication safe?
We would be very grateful for any help on the topic, we are not tied to the current solution - we want to do it right and if possible using the current infrastructure.

I will be very grateful for any help and advice.

Hi @Garmet

Thanks for getting in touch!

It sounds like you are on the right track. Octopus supports different ways to deploy to Servers, and the most straight-forward for your Windows Server is the Octopus tentacle.

This is a light-weight agent that runs as a windows service on each server you wish to deploy your applications to.

When modelling your application in Octopus, you’d typically create one or more Octopus projects.
You’d then add deployment steps to your deployment process. This could include things like the “deploy to IIS step” for your website.

If you have a Test server and a Production server, you’d typically model this as 2 deployment targets. This means 2 tentacles would be installed, 1 on the Test server, and 1 on the Production server.

In terms of the segregated network for Test and Production, this is really only an infrastructure concern, as opposed to an Octopus concern. By this, I mean it’s transparent to Octopus Server how it connects to the Tentacle on the Test or the Production Server.

Tentacles can operate in 2 communication modes:

  1. Listening mode where they listen on a TCP port (10933 is the default, but you can change this) - they will wait for work to be pushed to them by the Octopus server. This communication mode is generally recommended as the tentacle has to do less work over the network.
  2. Polling mode is where the tentacle actively polls the Octopus Server for work, over an outbound TCP port (10943 is the default, but you can change this). This mode can be useful if you have any policies preventing you from opening inbound port access on your servers. Typically outbound firewall rules are more relaxed, and this is how a polling tentacle operates.

Once you have your targets set up in Octopus, you would then create a release in octopus. A release is a snapshot of the deployment process and the associated assets (packages, scripts, variables) as they existed when the release was created.

You then deploy your release to an Environment, in your case Test would be first. In order to ensure you deploy to Test first, and not Production, you can control the order in which releases are deployed to environments through what’s known as a Lifecycle.

Once you have deployed to your test server (in the Test environment), you can promote that release to Production.

If you haven’t seen it already, we have a getting-started guide in our docs which cover the core concepts of Octopus and more.

In addition, we also have a Getting Started webinar on youtube which also covers some of the core concepts -

I hope that helps!


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.