My company is trying to set up the correct roles and environments for 5 servers in 4 different environments for 2 applications for 1 tenant. We’re running into issues with Octopus deploying to “Server A” when it should not. Here is our setup:
Development
QA/Testing
Training/UAT
Production
App 1
Server A
Server B
Server C
Server D
App 2
Server A
Server A
Server A
Server E
How would we set up the roles and environments in this situation? We have all the Servers with Octopus Tentacles installed and communicating with Octopus. We currently have issues with Server A installing App 1 in the 3 environments where it should not.
First of all, welcome to the Octopus community! And thanks for reaching out with your question.
We have some excellent documentation here that does a great job of explaining the best practices with roles and environments (if you haven’t seen this already).
Essentially the guidance here should be that you’ll want some extra target roles combined with environments to group project steps into a bit more specificity.
If you could send me a few screenshots of have you have your steps and roles configured, I might be able to spot what’s going wrong on your side.
This is what our app roles and environments look like. I “generalized” the names from what they actually are due to some proprietary information and to boil the problem down to its essence, but the names are 1-to-1 to how we have it setup:
Environment Names are at the top (X-axis) and role names are on the side (Y-axis)
Development
QA/Testing
Training/UAT
Production
App 1-role
Server A
Server B
Server C
Server D
App 2-role
Server A
Server A
Server A
Server E
The issue is that with Octopus’s tools, I can say that App 1-role and App 2-role should install to Server A in Development OR I can say that App 2-role should install to Server A in the first 3 environments, but I cannot do both without issues.
Thanks for the additional details. Assigning multiple roles to a deployment step results in an OR statement so this is why the earlier deployments perform as expected but adding extra environments creates an AND statement and might be why you’re deploying to all machines.
It might be easiest to align this new information if we could correlate it with a copy of your process JSON. I might be able to spot how we can get the specificity you’re looking for.
If that’s something you can send over, I’ve created a secure upload link for you here: Support Files Upload
We don’t have multiple roles in our deployment steps. Each step only has 1 role. In fact, we split it out so that each project only has 1 role for all the deployment steps. The issue is that we can’t tag the server on the Infrastructure page correctly. We currently have Server A tagged as “App 1-role” and “App 2-role” for the 3 environments it is in.
This is what we have currently for our infrastructure tagging:
Server A: Roles: App1-role, App 2-role; Environment: Development, Testing, Training
Server B: Roles: App 1-role; Environment: Testing
Server C: Roles: App 1-role; Environment: Training
Server D: Roles: App 1-role; Environment: Production
Server E: Roles: App 2-role; Environment: Production
What we would like to say is something like the following for Server A:
For Development, use this server for both the App 1-role and App 2-role
For Testing and Training, use this server only for the App 2-role
This seems to be a limit of Octopus that we cannot do this.
I’m just stepping in for Garrett while he’s offline as a member of our US support rotation. Thanks for providing the additional details about your requirements.
I believe understand what you’re trying to accomplish, but I don’t think Octopus has a great way at handling it exactly as you’re attempting. I think that you’re going to need to introduce further complexity into your setup to achieve this.
Our roles are essentially tags for selecting the desired target at deployment time. This tagging uses an AND relation when used in conjunction with Environments but not with other roles. In order to achieve what you’re after, you will need to consider creating more unique roles, or creating additional environments to provide the level of granularity that you need. We have a section in our documentation under best practices that discusses Environments, Deployment Targets, and Roles which goes into detail about how we recommend modelling these resources in Octopus.
Under the Roles section in that documentation, we briefly mention what it sounds like you’re trying to do.
Using the generic role web-server will pick all the servers in a specific environment. For example, you have 25 servers in production with the role web-server . When you deploy to production , Octopus will pick all 25 servers, but you only want to deploy to 4 of them. There is no automatic way to limit the servers picked without either creating a specific role hello-world-api or creating a new environment.
Though I’m still not certain on your overall requirements, I’m wondering if you’ve also considered whether Channels could help you accomplish what you’re after? This would require breaking up your releases into separate channels to gain more control over the lifecycle being used for a particular pathway through to production. It’s possibly not the correct fit for your issue but well worth taking a look at.
Hopefully this helps give you some ideas that at least move you in the right direction. If you’re still stuck, please let us know. We’re happy to continue helping however we can.