ARR and environment

Hey guys,

First of all, big shout out to the octopus crew and the community. I love your work.
I have searched for something similar here in the forums to base my answers off, but no luck.

I have just started working on a deployment plan for a new company i am doing some deployment automation for. They are a small outfit with combined DB and App servers all over the world.

Here in Aus however, they have 2 web servers, pointed to a single DB server. All requests come into web server 1 and some are routed off to a second, which has been set up to ease the load on the first.
I am trying to adapt the all-in-one-server plan for this split environment, but i’m not sure how to structure things in octopus. Basically, i need to either deploy a package straight to web server 1 and another to the shared DB server, or deploy the same package to web server 2, a package to the DB server AND run a script to add ARR rules to web server 1.
If it wasn’t for the last part (running the ARR script) it would be a simple matter of disabling whichever node i didn’t want to deploy to, instead i have all these different ideas running through my head, separate environments, aus001 and aus002 sharing the DB server, does this require separate tentacles on different ports on the DB server? Adding another tentacle on web server 1 with the new role of “ARR”, idk anyway. Confused.
If any of this is unclear, i will try and explain better.
If someone has run into something similar or has a simple solution, i would really appreciate some advice :slight_smile:

I should add, i jumped on board with octopus a long time ago, but have since moved locations / employers and have only just managed to encourage adaptation here. I might be a little unfamiliar with many of the 3.0 features.

Hi Ryan,

Thanks for reaching out!

To make sure I understand what you’re trying to do, let me attempt to describe it back to you. You are trying to have one deployment process that can be used for all around the world. It needs to deploy both the Web and DB components onto one server in every region except Australia. In Australia, it has a separate database server, 2 web servers and needs to deploy some ARR rules to only one of the web servers. Is this correct?

Assuming I’ve got this right, I’m also going to assume this a brand new project, and that you want to deploy to all “production” servers at the same time.

If this is what you are trying to do, I would suggest:

  • tag all web servers with a role “web-server”
  • tag all non Aus servers with “db-server”
  • tag the Aus database server with “db-server”
  • tag web server 1 in Aus with a role “requires-arr-rules”

Create a process similar to:

  • deploy web package to all servers with role “web-server”
  • deploy database package to all servers with role “db-server”
  • run ARR script on all servers with role “requires-arr-rules”

A new feature in our upcoming 3.4 release that could be useful is tenants (see http://docs.octopusdeploy.com/display/OD/Multi-tenant+deployments). You could use these to have a “tenant” per region and target the individual steps to the specific regions. We are aiming to release 3.4 very soon - keep your eyes peeled!

Hope this helps!

cheers,
Matt

Hey Matt,

Thanks for the reply,

“Assuming I’ve got this right, I’m also going to assume this a brand new project, and that you want to deploy to all “production” servers at the same time.”

Not yet, generally about 30 preexisting sites per server. All clients on different versions currently, its a mess. I am working to integrate Octopus into this, i have retrofit every server to use a naming scheme and fixed file structure. So now we have bamboo and octopack packing our builds, i want to be able to use this build process to push out builds to one or more clients in a single environment. Currently i can do this by changing one variable in the build process, which all of the server structure is based off. I’m getting off topic, the multi tenancy stuff i will work out a bit later… Big plans.

But in regard to the environment issues, deploying to web002 requires deploying a package on the DB server, a package on web002 AND running an ARR script on web001. Deploying to web001 would only require deploying a package to web001 and a package to the DB server.

So if i tag web001 as a ‘webserver’ and ‘ARR’ and i want to deploy to web002 (which is tagged as ‘webserver’ only), i can’t seem to find a way to stop packages getting deployed to web001 when they should only be getting deployed to web002, although in this instance the ARR scripts are getting run.

I have tried to create separate environments, one for deploying to aus002 and one for deploying to aus001, but a server’s role seems to be static in every environment. So i am faced with the same issue.

I have looked at getting multiple tentacles on web001, so it can be treated as 2 entities, either a web server OR the ARR role, but this seems a little troublesome and not fully supported.

I have been looking at running the ARR scripts from web002 in a custom step which checks machine name before using invoke-cmd to run a script on web001, i don’t like this option, it feels less secure and a little error prone.

Finally, my other option was to make a separate deployment plan for deploying to web002, i don’t like this option either. I need to get maximum results with a minimum number of deployment plans before the big boys extend the octo-budget and i feel like this will not play well with multi tenancy in the future.

I know this legacy infrastructure setup is not ideal, but its what we have in place in production at the moment. And streamlining this process is not the be all and end all of my work here at the moment. Is there perhaps some feature of channels i have not yet explored?

As always, your advice and support is appreciated :slight_smile:

I think i’m going to look for an infrastructure change to negate this, i’m working too hard on an issue that octopus isn’t supposed to deal with. If i remove the ARR role from web001 altogether, i’m going to improve the flow of deployments and the ability to manage things with multi tenancy immeasurably.

Hi Ryan,

Does that mean there is a different package that needs to be deployed to web002 compared to web001?

ie:
db gets Package1
web001 gets Package2 and the ARR script
web002 gets Package3

If that is the case, then you could tag web002 with a different role and add a step that deploys Package3 to that role.

Would that work?

Cheers,
Matt