Tag Archives: OctopusDeploy

BamiWvqCIAAfBgw

Upgrading to Octopus 2.0

On 20th December 2013, Paul Stovell and the Octopus Team released Octopus Deploy 2.0. We’ve had a chance to play with the product for sometime, and it’s a great next version.

Here’s 5 great reasons to upgrade;

  1. Configurable Dashboards
  2. Sensitive variables
  3. Polling Tentacles (Pull or Push)
  4. IIS website and application pool configuration
  5. Rolling deployments

So let’s take a look at how the upgrade process works.

Step 1 – Backup your existing database

Things to check before you upgrade;

  1. Your administrator username and password (especially, if you are not using Active Directory)
  2. Before attempting to migrate, make sure that you don’t have any projects, environments, or machines with duplicated names (this is no longer allowed in Octopus 2.0, and the migration wizard will report an error if it finds duplicates).
  3. IIS Configuration. Are you using ARR or rewrite rules of any kind.
  4. SMTP Server Settings (these are not kept in upgrade)

The first step is to ensure that you have a  recent database backup that you can restore in case anything goes wrong.

1 - Database Backup

Confirm the location of your backup file. You’ll need this file at a later stage in the upgrade process (and if anything goes wrong)

2-Database Backup Location

Step 2 – Install Octopus 2.0

Download the latest installer MSI from the Octopus Website at http://octopusdeploy.com/downloads

Next follow the installer instructions and the Octopus Manager process. This process is really straight forward, and if you’ve installed Octopus before you’ll be familiar with most of the process. There’s a great video here on how to install Octopus http://docs.octopusdeploy.com/display/OD/Installing+Octopus

Step 3 – Import Previous Octopus Database

Once you’ve installed Octopus 2.0, you’ll most likely want to import your old v1.6 database with all your existing configuration. To do this, select the “import from Octopus 1.6″ option and choose the database back-up from the process you followed in step 1 and follow the instructions.

3 - Import Octopus Database

Step 4 – Post Upgrade Steps (server)

When you have completed the installation it’s essential to task a copy of the master key for backups. Instructions on how to backup the key can be found here http://docs.octopusdeploy.com/display/OD/Security+and+encryption

Once you have the server installed there’s a couple of items you’ll need to configure again.

  1. SMTP Server Settings are not kept, so these will need to be re-entered.

Step 5 – Upgrading Tentacles

If you are upgrading from version 1.6 - Octopus 2.0 server can no longer communicate with Tentacle 1.6. So in addition to upgrading Octopus, you’ll also need to upgrade any Tentacles manually. There are two ways to achieve this;

1. Download and Install the new Octopus Deploy Tentacle MSI on each target server

2. Use  a PowerShell script to download the latest Tentacle MSI, install it, import the X.509 certificate used for Tentacle 1.6, and configure it in listening mode. The powershell script is as follows;

function Upgrade-Tentacle
{ 
  Write-Output "Beginning Tentacle installation"
  Write-Output "Downloading Octopus Tentacle MSI..."
  $downloader = new-object System.Net.WebClient
  $downloader.DownloadFile("http://download.octopusdeploy.com/octopus/Octopus.Tentacle.2.0.5.933.msi", "Tentacle.msi")
  
  Write-Output "Installing MSI"
  $msiExitCode = (Start-Process -FilePath "msiexec.exe" -ArgumentList "/i Tentacle.msi /quiet" -Wait -Passthru).ExitCode
  Write-Output "Tentacle MSI installer returned exit code $msiExitCode"
  if ($msiExitCode -ne 0) {
    throw "Installation aborted"
  }
  
  Write-Output "Configuring and registering Tentacle"
   
  cd "${env:ProgramFiles(x86)}\Octopus Tentacle 2.0\Agent"
  Write-Output "Stopping the 1.0 Tentacle"
  
  & .\tentacle.exe create-instance --instance "Tentacle" --config "${env:SystemDrive}\Octopus\Tentacle\Tentacle.config" --console
  & .\tentacle.exe configure --instance "Tentacle" --home "${env:SystemDrive}\Octopus" --console
  & .\tentacle.exe configure --instance "Tentacle" --app "${env:SystemDrive}\Octopus\Applications" --console
  & .\tentacle.exe configure --instance "Tentacle" --port "10933" --console
  & .\tentacle.exe import-certificate --instance "Tentacle" --from-registry  --console
  Write-Output "Stopping the 1.0 Tentacle"
  Stop-Service "Tentacle"
  Write-Output "Starting the 2.0 Tentacle"
  & .\tentacle.exe service --instance "Tentacle" --install --start --console
  
  Write-Output "Tentacle commands complete"
}
  
Upgrade-Tentacle

Step 6 – Upgrade TeamCity Integration

The JetBrains TeamCity Plugin has also been released and requires an upgrade. To do this

  1. Download the plugin from the Octopus Website http://octopusdeploy.com/downloads.
  2. Shutdown the TeamCity server.
  3. Copy the zip archive (Octopus.TeamCity.zip) with the plugin into the <TeamCity Data Directory>/plugins directory.
  4. Start the TeamCity server: the plugin files will be unpacked and processed automatically. The plugin will be available in the Plugins List in the Administration area.

Please Note: The API Key’s for the users will have changed and will need to be re-entered into the Octopus Deploy Runner Configuration within the Build Step

Summary

We think that overall the Octopus Team have done a great job making the upgrade process easy. There’s still a few little issues to iron out, but overall the process is robust and simple. It’s a shame that automatic upgrade of the tentacles couldn’t have been supported as this may cause pain for customers with a large server install base, but Powershell automation makes for a great workaround.

As we learn more about Octopus 2.0, we’ll continue to let you know what we find. Good Luck with Upgrading — it’s definitely worth it!

DevOpsGuys use Octopus Deploy to deliver automated deployment solutions – ensuring frequent, low-risk software releases into multiple environments. Our engineers have deployed thousands of software releases using Octopus Deploy and we can help you do the same. Contact us today – we’d be more than happy to help.

Automated release management for .NET with OctopusDeploy

Introducing OctopusDeploy

We are big fans of OctopusDeploy and have been using it since its beta release in early 2012. If you’re not familiar with OctopusDeploy, here’s the background;

1. It’s an automated release management tool for Microsoft .NET, comprising of a centralized server and agents, known as Tentacles, which are installed on each target server.

2. It uses the NuGet package format,  an open source package manager for the Microsoft .NET Framework.

3. Tentacle agents listen on TCP port 10933 by default and HTTP requests are encrypted using a pair of X509 certificates.

The following diagram shows the release management components;

Deployment Components
Deployment Components

Release Management On-premise or Off-premise

One of the highlights of using OctopusDeploy is its’ ability to deploy software to servers located in any environment. The highlight reel goes a little something like this;

Whether your servers live in the cloud, in a data centre, or under your desk , Octopus can securely upload, install and configure your applications.

Just install a tiny service agent called Tentacle on your servers, and then use our easy installation wizard to set up a secure connection between the Octopus and Tentacle based on public/private key encryption technology. Your server is ready for deployments!

We’ve installed OctopusDeploy many times and have used some of the following installation scenarios to deploy to on-premise and off-premise data centres.

Scenario 1: On-Premise Installation with On-Premise Deploy

One of the more common ways of installing Octopus is one where the NuGet Server and Octopus Server are located on your own network,  along-side Continuous Integration servers or source control systems.

In this installation, OctopusDeploy will pull NuGet packages from a NuGet Server (such as MyGetJetBrains TeamCity, a NuGet Feed Server or just a local file path) and push the deployment out to target servers located on a local network.

Since all servers are located on the same network, this configuration is straight-forward and requires not much more than Windows Firewall configuration to be completed,  where TCP traffic over port 10933 (presuming the default ports) is allowed between the OctopusDeploy server and the target servers.

On-Premise Installation with On-Premise Deploy
On-Premise Installation with On-Premise Deploy

Scenario 2 :On-Premise Configuration with Off-Premise Deploy

This installation presumes that your target servers are not within your own network. E.g. hosted in an off-premise data centre E.g. a cloud environment. Configuration is the same as Scenario 1, and Windows Firewall will still need to be configured.

However, in this scenario it is likely that additional layers of security will be in place E.g. a hardware firewall. Network teams will need to ensure that TCP traffic on the OctopusDeploy port (10933 by default) is allowed into each server.

This deployment scenario has some complications however. Each target server needs to be publicly addressable. For load balanced server farms this is going to add a level of complexity, as firewalls and content switches/load balancers will need to be configured to allow each target server to be individually and publicly available to an external caller.

More common, is the fact that servers located in the off-premise data centre might not be publicly addressable with good reason. E.g. Web Servers in a DMZ can receive traffic originating from public networks, whereas application and database servers (and firewalls) are configured only to receive traffic generated within the off-premise data centre.

If you do decide to expose servers publicly to allow Octopus to deploy from an on-premise to an off-premise location, you can take some solace from the fact that the Paul Stovell from OctopusDeploy has ensured deployment is secured with HTTP requests that are encrypted using a pair of X509 certificates.

On-Premise Configuration with Off-Premise Deploy
On-Premise Configuration with Off-Premise Deploy

Scenario 3 :Off-Premise Installation with Off-Premise Deploy

Finally, you might want to consider a scenario where the Octopus Server is hosted within the off-premise data centre that software will be deployed into.

The NuGet server can remain on-premise in this scenario. Since Octopus will generate outbound HTTP (TCP:80) traffic to a known destination ( in our experience ), security guys (not all) are cool (don’t complain complain less) with this approach.

Advantages over Scenario 2

1. Octopus and target servers are now located within the same network, or are on trusted networks.

2. Servers do not have to be made publicly addressable. Non public servers can be deployed to.

3. Load balanced challenges in Scenario 2 are overcome. Octopus can now individually address all servers.

4. Deployment time can be reduced, as NuGet packages are transferred once from NuGet source and are deployed across local or trusted networks.

Disadvantages

1. Additional server infrastructure is required in data centre to host OctopusDeploy Server.

Off-Premise Installation with Off-Premise Deploy
Off-Premise Installation with Off-Premise Deploy

We hope that’s given you a flavor of the installation scenarios available to Octopus Deploy! More information on OctopusDeploy can be found at http://octopusdeploy.com

DevOpsGuys use Octopus Deploy to deliver automated deployment solutions – ensuring frequent, low-risk software releases into multiple environments. Our engineers have deployed thousands of software releases using Octopus Deploy and we can help you do the same. Contact us today – we’d be more than happy to help.