It's one thing to talk about enterprise deployment patterns in abstract terms, but teams can only realize the value of these patterns by implementing them. To that end , we developed the enterprise patterns reference implementation. It's a Docker Compose-based application stack deploying and configuring a sample Octopus instance containing practical examples of the following patterns:
- Managed space per business unit/application
- Managed instance per business unit/region
- Managed instance per environment
This post describes how to install and use the reference implementation.
Support levels
The process presented in this post is part of a pilot program to support platform engineering teams. It incorporates tools with varying levels of official support. The Octopus support team will make reasonable endeavors to help customers that wish to use this process. However, existing support Service Level Agreements (SLAs) do not apply to many of the tools described below.
This post describes tools and processes we're seeking feedback on. They're not covered by existing SLAs, and you shouldn't apply them to production systems, or rely on them for production deployments.
Tools to get started
To use the reference implementation, ensure you have the following tools installed:
- Windows users must install WSL2.
- Git, which clones the sample GitHub repository.
- Docker and Docker Compose, which boots the application stack.
- Terraform, which configures Octopus.
- minikube, which creates a local development Kubernetes cluster.
- OpenSSL, which parses the minikube certificates.
- curl, which downloads files.
- jq, which parses JSON files.
Environment variables to get started
You also need a Docker Hub account. Octopus requires Docker Hub credentials to query image tags hosted by the service. The Docker Hub credentials are exposed by two environment variables:
TF_VAR_docker_username, which holds the Docker Hub username.TF_VAR_docker_password, which holds the Docker Hub password.
Finally you need an Octopus license key. This is an XML document, which you must base 64 encode and expose in the OCTOPUS_SERVER_BASE64_LICENSE environment variable.
You can find more information on persisting Linux environment variables (which also applies to Windows WSL users) in the Ubuntu help docs and for macOS on this Stack Exchange page.
Octopus employees can find sample credentials in the Sample environment vars for EnterprisePatternsReferenceImplmenetation note in the internal password manager.
Clone the repo
Clone the sample repo with the command:
git clone https://github.com/OctopusSolutionsEngineering/EnterprisePatternsReferenceImplementation.git
Enter the newly-cloned repo directory with the command:
cd EnterprisePatternsReferenceImplementation
Then initiate the creation of the sample application stack with the command:
./initdemo.sh
The first initialization will take some time as all the Docker images are downloaded and Octopus is configured via Terraform. Once the initialization is complete, the following URLs are available:
- http://localhost:18080, which grants access to Octopus. The username is
adminand the password isPassword01!. - http://localhost:3000, which grants access to Gitea (a hosted Git platform). The username is
octopusand the password isPassword01!.
Exploring the Octopus instance
Open http://localhost:18080. Log in with the credentials above, and you'll enter an Octopus instance configured with sample projects and spaces.
We configured the Default space as a management space. This space creates additional spaces representing regional teams and deploys template projects to them.
The Development and Test/Production spaces represent the "Managed instance per environment" pattern. This is where you refine a deployment process in the Development space and then promote it to the Test/Production space.
You'll also notice we preconfigured the Default space with global resources, including environments, lifecycles, accounts, certificates, targets, variable sets, tenants, and feeds. These all support the sample applications available for propagation to managed spaces.
We'll reference these resources in subsequent posts as we describe the implementation of the enterprise patterns.
Conclusion
The reference implementation serves as the foundation of this blog series. It lets DevOps teams explore a practical demonstration of Octopus used to support complex deployments across many business units or regions.
If you're interested in orchestrating Octopus with an Infrastructure as Code (IaC) approach, you'll find a wealth of example Terraform configuration files in this reference implementation that you can easily apply to your own instances.
In the next post, we'll cover the high-level configuration of the Default space supporting the "Managed space per business unit/application" and "Managed instance per business unit/region" patterns.
We're currently refining our approach to these enterprise patterns, so if you have any suggestions or feedback about the approach described here, please leave a comment on this GitHub issue.
Happy deployments!
