Understanding Octopus Environments and Roles
When first trying out a new application, it’s tempting to jump right in. Often, you can learn a lot about a new system through usage and discovery. However, Octopus Deploy introduces a new vocabulary that needs to be understood. In particular, two concepts that crop up constantly are environments and roles. This post will provide a magic decoder ring.
Saving the Environment
The Octopus documentation describes an Octopus environment as simply “a group of machines that you will deploy to at the same time.” In the opening post of this series, I mentioned an Octopus Deploy pilot I participated in, and its goal – to replace an existing home-grown deployment process.
Our previous deployments, of course, already had the concept of environments. In my organization, our existing environments were known as DEV, QAT, UAT, and PRD. Naturally, other teams might have fewer (e.g. Test, Staging, Production) or more environments. Octopus Deploy allows you to create and use as many environments as you need, with any names you want.
For example, imagine working in a unit of a large organization. Some departments might have greater privacy needs than others. Perhaps you would even go so far as to provide physically isolated servers for some groups, with the remaining departments operating on different systems.
For this reason, Octopus allows you to set up many environments. Consider a work group with high privacy needs. You could prefix the normal environment names with the work group’s acronym, say ABC for example (Figure 2.) Then you might include only the servers of interest to that group. Other groups working on shared servers could have the typical DEV, QAT, UAT, and PRD environments. However, even with isolated infrastructure, you may not need the same level of isolation in Octopus that exists physically. And that is because of Octopus roles.
While creating an Octopus deployment process, you will target and scope various aspects to specific roles. Technically, the full name of this concept is “machine role.” However, the Octopus user interface usually shortens this to “role.” A role is nothing more than simply a tag on a machine. This tag indicates the functionality that a given machine provides within an environment.
When deploying web applications, a common role is that of a web server. Database server is another common role. Continuing along the vein of isolating some machines from those of other groups, you can also namespace machine roles. Again referring to Figure 2, you can see the role tags in grey background with white reversed text.
Looking at the ABC DEV environment in Figure 2, the first machine has the role abcweb. Look closely, and you’ll notice that it is that environment’s one and only web server in that role. Namespacing the roles this way is another way to distinguish isolated servers from shared infrastructure.
For example, if you look near the bottom of Figure 2, you’ll see a machine with the role WebInternal. This might be a shared machine that other groups use. So well-named roles can also allow you to distinguish separated infrastructure. In that case, you might not need separate sets of Octopus environments.
Deploying to Multiple Targets
If your deployment process targets a particular role, then each environment you are targeting must have at least one machine in that role. However, a role will often apply to more than one machine.
In the ABC UAT environment in Figure 2, four machines have the abcweb role tag. These machines might sit behind a load balancer. When Octopus Deploy runs a deployment step targeting the abcweb role, it will update all four of these machines at once. This is a big part of the power that Octopus Deploy brings to the table.
Multiple Personality Disorder
Referring to Figure 2 one last time, notice that several machines have more than one role tag. In Octopus, an individual machine can play multiple roles in a deployment. For example, a deployment might need a web server, a database server, and a reporting server. In a non-prod environment, one server might be able to play all three of these roles. Octopus allow you to have almost limitless flexibility in creating, naming, and assigning roles.
However, the Octopus documentation for machine roles urges some restraint. It closes with a warning:
Roles are not Environments or OS versions. Try to use roles to tag servers by their utility and watch out if you find yourself putting more than 3 roles on the same server.
The intention of this blog post was to provide enough background information about Octopus environments and roles to a developer who is new to Octopus Deploy. As we’ve seen, Octopus Deploy offers a great deal of flexibility and power when defining roles and environments for your deployments. You can set up and name environments and roles any way that you like. You can provide any level of isolation that you need using either feature, or both in tandem.
This is the second post in the multi-part series – “Practical Octopus Deploy.” The focus of this series is from the perspective of a developer who wishes to use Octopus to deploy an application. The next post in this series discusses Octopus Deploy lifecycles. The first post, with table of contents, is Practical Octopus Deploy – Introduction.
Some readers might be setting up an Octopus server on their own. Others may simply want more details. If so, you can check out these additional resources.
- Octopus Deploy Documentation – Environments
- Octopus Deploy Documentation – Machine Roles
- The following video demonstrates the user interface for creating an environment:
Octopus Training Video – Creating Environments (00:01:08)
- Installing a Tentacle is part of provisioning a server to a specific environment. This video demonstrates how to place a machine in an environment and assign it one or more roles:
Octopus Training Video – Adding a Listening Tentacle (00:04:33)