This is the first article of my Octopus Deploy Deep Dive Series. I’m looking to dive into specifics within Octopus Deploy. There’s lots to cover and today were going to dive into Machine Roles or just plain old Roles. Octopus has roles for team permissions so to avoid confusion for this article, the context of roles is in reference to Server Roles or Machine Roles.
When you add a tentacle to an Octopus Deploy server, you have to specify at least one role for that tentacle. I’ve covered tentacles previously in the Octopus Deploy series. When typing in the role field, you’ll see that you can type anything that you want in addition to seeing anything else that was previously typed in. There’s no scoping limitation when it comes to machine role names. All machine roles are shared among all project groups and projects on an Octopus Server.
At first, roles may seem a little strange. I’ve seen some project teams confuse them for server environments. Since roles are really a free-for-all with no guidance, it’s easy to ignore or not consider what roles can do for you and your deployments. With a little planning and some creativity, you can leverage roles to do some mighty powerful deployments that would be otherwise cumbersome.
Within each step of your deployment process, you must specify at least one machine role to target. When adding a step to your deployment process you’ll see the field as shown below.
You can also scope your variables based on roles as well.
Why does it matter to define a role for a server? If you’re deploying your code to that server, you should know what you’re deploying to it. So what is it that makes roles so beneficial?
First, roles allow you to target servers in your deployment steps and variable assignments by server function. As Octopus has only one deployment process per project, all servers can be included within the entirety of the process. Having roles allows you address steps for specific server types.
Second, as an extension to my first point, roles are an easy mechanism for targeting one specific server or a large number of servers. This may not seem like a big deal, but unless you have a few of servers this is a huge boon. Imagine for a moment that you need to setup or copy each individual step across 10 servers. Then imagine you have to make a change to the process – to each server. For those who wonder why Octopus Deploy has only has one deployment process for each project, this is the blessing in disguise: by forcing projects to one process, there’s an implied notion that deployments should be (relatively) consistent across environments. Your deployment to your development or staging environment should be remarkably similar to production obviously permitting minor variations in the details. Roles allow you to target either narrow scope or subset of servers in your environments, or a wide scope across all of your servers.
Lastly, since you can apply multiple roles to each server, you can craft your own creative deployment scheme or implement a deployment pattern as defined by Octopus Deploy. These patterns are easily achievable with the advent of the role that can be used for the following defined patterns:
- Canary Deployments (role-based)
- Blue-Green Deployments (environment-based)
- Multi-tenant Deployments (mix of environments/projects/roles)
We’ve implemented our own deployment pattern that suits are needs. One pattern allows us to target subgroups of servers and take them offline through a load balancer. So while the application is still online, albeit at a smaller capacity, we can deploy new code without service interruption. Without roles, we’d have no other mechanism for doing so and manually would be extremely long and arduous deployment.
Let’s take a simple, hypothetical example of a web deployment to four web servers.
By placing the “Web” role on each tentacle, you can now address all of the servers for a single nuget package deployment step. That’s simple enough. But let’s say for your deployments, you want to deploy to two servers at a time. One way to do this is by using a rolling deployment, but that’s outside of this discussion of roles. Another way you can do this by adding another role to pair the servers together.
By assigning another role, say Group A or B, you can specify the Groups rather than all of the servers with the Web role. Now this might not be nearly useful as rolling deployments really take care of this problem, but say you have a load balancer in front of your servers and you want to take down a group from the load balancer using a script to remove them from routing any requests. This would be an ideal configuration for that particular scenario.
Additionally, we can expand on this if your servers have other unique roles such as running a console application, hosting a REST API or a Windows Service. Now you can easily deploy your Windows service to all machines with the role “Service”. Now, you don’t have to sweat the details of the servers and the scope automatically adjusts based on the role or roles. Keep in mind, when scoping variables with roles, you don’t have to specify any roles or as many as you’d like so the more granular your roles assigned to your servers, the more options you’ll have for your deployment process later.
This simple example demonstrates that the number of servers you have to target are no longer a challenge. The new task now lies in the combination of roles to meet your specific deployment needs. As there’s no real restrictions regarding roles, you’re free to do as you please but it’s best to plan your roles accordingly. You can always make changes later as well but depending on the number of servers you’re working with, you may want to be a little prudent.
So you can see how roles allow you to target a wide array of servers or to hone in on one particular machines depending on how you’ve assigned said server roles. By assigning roles to your servers by function (database, reporting, analysis, web services, etc.) or by a pattern of your own design, you’ll see that roles are a simple, flexible and effective method for controlling your deployment to machines within your environments.
So that’s it for roles. Next up for the Deep Dive Series, Users, Roles and Teams.