Structuring Scalr
Overview
The Scalr organizational model is broken up into the three components listed below. The model allows for object inheritance and assignment as well as visibility of Terraform or OpenTofu workspaces and runs from an admin perspective.
- Administration Scope - Primarily an administrative control plane where environments, IAM, policies, modules, variables, integrations, and more are maintained. Administrators have the ability to create objects at the admin scope and then assign them to underlying environments to provide an inheritance model. The admin scope also serves as a global dashboard with views of all workspaces, run operations, and reports across environments.
- Environment Scope - Environments enable self-service for platform teams looking to decentralize their operations and enable development teams. Environments are isolated groupings of workspaces, teams, policies, variables, and more. Users and teams can only access environments they have been given explicit permissions to.
- Workspaces - Workspaces are the child of an environment. This is where Terraform and OpenTofu runs are executed, the state is stored, and all objects related to the deployments are linked. Each workspace is linked to a single state file.
A best practice when designing your implementation is to manage the structure with the Scalr Terraform provider. By doing this, you can easily onboard teams into Scalr by updating a variable file and it reduces the long-term overhead.
Let's get into some more specifics about each scope.
Admin Scope
Used primarily by admins as the control plane for the entire platform. There are three main themes in the administration scope:
- Management: Manage environments, IAM, modules, OPA policies, VCS connections, variables, and provider configurations for the entire account.
- Reporting: Report on modules, providers, Terraform version, resources, and more to give you a good understanding of how Terraform or OpenTofu is being used.
- Operations: Have cross-account views into workspaces and runs with the ability to execute bulk actions on them without having to search through environments and workspaces.
Management
The following objects can be created and managed at the admin scope:
| Object | Description |
|---|---|
| IAM | Required. Control teams, users, services accounts, and SAML/LDAP integrations. Access policies can be assigned to the account, environment, and/or workspace scope. |
| Provider Configurations | Optional. Provider configurations are created and managed at the admin scope but assigned to environments. A single configuration can be assigned to one or more environments. |
| Environments | Required. Environments are the child of the admin scope. Environments are where workspaces are created and Terraform runs are executed. |
| Policy Engine | Optional. OPA policy groups can be created and managed at the admin scope but assigned to environments. A policy group can be assigned to one or more environments. |
| Variables | Optional. If a shell variable is created at the admin scope, the variable will be inherited by all environments and workspaces. |
| VCS Providers | Optional. If a VCS provider is created at the admin scope, the provider will be available to all environments and workspaces. |
| Modules | Optional. If a module is created at the admin scope, the module will be available to all environments and workspaces. |
| Agent Pools | Optional. If an agent is created at the admin scope, the agent will be available to all environments and workspaces. |
All of the objects above can be assigned and automatically inherited by environments.
Click Through Demo
Environment Scope
Environments are mainly where the development teams will operate as the workspaces within the environments are where the Terraform deployments actually happen.
Teams have the ability to consume modules created at the admin scope or create and manage their own modules in the environment-level registry if they have the proper permissions assigned to them. All objects assigned to an environment from the admin scope cannot be removed based on the inheritance model.
Admins have the ability to assign the following objects to an environment:
| Object | Description |
|---|---|
| Provider Configurations | Optional. A single provider configuration can be used across one or more environments. When a provider configuration is the default for an environment Scalr will automatically insert the provider block when needed in a run. |
| VCS Providers | Optional. A VCS provider is needed for the module registry and VCS connected workspaces. If a VCS provider is created here, it is only available in this environment. The VCS provider will be made available for workspaces within the environment, but not required if the workspace is CLI driven. |
| Variables | Optional. If a shell variable is assigned to an environment, the variable will be inherited by all workspaces within the environment. |
| OPA Policies | Optional. OPA policy groups must be created at the admin scope. The policy group is then assigned to an environment. |
| Webhooks | Optional. If a webhook and endpoint are created and assigned to an environment, the webhook will be available to all workspaces. |
| Access Policies | Required. For users or teams to access an environment, they must be assigned an access policy within the environment. |
Any of the objects assigned to the environment scope will be automatically inherited by all workspaces within the environment. For example, if you set a shell variable at the environment scope, all workspaces in that environment will inherit it and end users are not able to change or remove it.
Workspace Scope
Workspaces are where the Terraform deployments happen. Users have the ability to select whether runs are triggered in workspaces from the terraform CLI, a VCS repository, or using the Scalr no code module deployments.
All state files are stored within the workspaces and users have many different automation, drift, variable, and credential settings for each workspaces.
Again, it is highly recommended to leverage the Scalr Terraform provider to manage workspaces.
Sample Structure
As you scale your Terraform or OpenTofu usage, it's important to enable self-service for users who will be deploying the code. The Scalr inheritance model is built to enable your end users while ensuring they inherit the correct variables, credentials, modules, and more. Objects that are created at the account scope by an admin will be assigned and inherited by the environments. Objects that are assigned to environments, like variables or provider credentials, will then be inherited by the workspaces within environments. The inheritance model allows you to create the concept of environment admins by allowing them to create and manage their workspaces knowing that they are operating within the guidelines that the top-level admins have set. Many of our customers are familiar with the inheritance model and structure that is set in AWS, which Scalr is not far off from, see a sample structure below.
Sample Structure - AWS Comparison
When customers initially onboard into Scalr we typically get asked the question about best practices for structuring Scalr. If you're accustomed to the AWS account structure, and it works for you in AWS, then we recommend following that same structure in Scalr. The structure being the concept of an AWS management account with multiple child accounts. That same concept applies in Scalr, where the Scalr account is equivalent to the AWS management account and Scalr environments are equivalent to the AWS child accounts.
In the diagram above, we see that the management account is managing the child accounts, and assigning policies as well as integrations. Each child account has a set of teams that have access to it, potentially admin access depending on the permissions, where they are deploying cloud resources. This same concept can be applied to Scalr:
In Scalr, the account scope is where the administration team manages all of the environments, creates policies, variables, sets modules, controls IAM, and has visibility over reports and operations. The environments are where the development teams can deploy their code and depending on permissions, have complete admin control of that environment or multiple environments.
Modeling the structure after AWS not only helps the admins deploy the same concept in AWS and Scalr, but also helps the development teams with visualization when they are switching contexts between AWS and Scalr.
Updated about 1 month ago