An Overview of Scalr's CI/CD Capabilities for Terraform and OpenTofu

Infrastructure as Code (IaC) enables the management and provisioning of IT infrastructure through code. Terraform and its open-source fork, OpenTofu, are common tools for IaC. Increased IaC adoption necessitates solutions for automation, collaboration, and governance. Scalr is a platform designed for Terraform and OpenTofu operations.

This document outlines Scalr's CI/CD features, including its GitOps workflows, custom hooks, run triggers, and execution environment customization.

Core CI/CD Functionality

Scalr automates Terraform and OpenTofu operations. It integrates with Version Control Systems (VCS) like Git, supporting GitOps workflows. Scalr supports two primary models:

1. Merge-Before-Apply: Changes are proposed via a pull/merge request. Scalr can automatically run a plan and report the output. After review and merge into the main branch, Scalr proceeds with the apply operation. This model ensures that only approved code is applied to the infrastructure.
2. Apply-Before-Merge (or Plan-and-Apply on PR): This model allows teams to view the impact of changes and apply them from a feature branch or pull request before merging. This can be utilized for iteration in development environments or for validating changes prior to mainline integration.

Scalr's CI/CD automates standard Terraform/OpenTofu commands (init, plan, apply), reducing manual intervention and potential errors.

Custom Hooks for Workflow Extension

Standard IaC workflows may require steps beyond automated plans and applies. Scalr's Custom Hooks allow the integration of custom scripts and tools at various stages of a run lifecycle. These hooks enable customization of the CI/CD process.

Available hook points include:

• Pre-init: Execute scripts before Terraform/OpenTofu initializes the backend and providers. This can be used for setting up dynamic configurations or fetching credentials.
• Pre-plan: Run scripts before the plan operation. Used for static code analysis (e.g., tfsec, tflint), compliance checks, or generating dynamic input variables.
• Post-plan: Execute scripts after a plan has been generated. This can be used for custom plan analysis, cost estimation checks, or sending notifications about planned changes.
• Pre-apply: Run scripts before the apply operation. Used for final validation, integration with external approval systems, or security checks.
• Post-apply: Execute scripts after changes have been applied. Used for sending deployment notifications, updating CMDBs, running integration tests, or cleaning up temporary resources.

Scripts for custom hooks can be sourced from a VCS repository or downloaded from an external location. Scalr also supports a "hooks registry" for centralized management of hooks. This enables platform teams to define and maintain standard hooks for use by development teams, which can aid in consistency and adherence to best practices.

Run Triggers for Dependency Management

Infrastructure components often have dependencies requiring coordinated provisioning and updates. Scalr's Run Triggers manage these dependencies.

Run Triggers offer the following capabilities:

• Chaining Workspace Runs: A workspace run can be configured to automatically trigger a run in another workspace upon successful completion, creating deployment pipelines (e.g., a network infrastructure update triggering an application deployment).
• Creating Dependencies Between Workspaces: Run triggers define explicit dependencies. If Workspace B depends on an output from Workspace A, a successful apply in Workspace A can trigger Workspace B to re-plan and apply, incorporating the latest outputs.
• Federate Environments: This feature allows the creation of dependencies between workspaces in different Scalr environments. This is applicable for scenarios such as promoting infrastructure changes between staging and production environments, or when different teams manage interconnected components in separate environments.
• VCS Event-Based Triggers: Run triggers can be initiated based on VCS events, such as a push to a specific branch or the creation of a tag. This integrates IaC automation with Git workflows.

Scalr's cross-workspace run triggering is comparable to features in other platforms like Terraform Cloud (TFC) or Spacelift for managing infrastructure dependencies.

Customizable Execution Environments: Self-Hosted Agents

Execution environment requirements can vary. Scalr supports both managed execution and self-hosted agents (runners).

Self-hosted agents provide the following benefits:

• Network Access: Agents can be deployed within a private network, enabling access to non-publicly exposed resources like internal artifact repositories, secret management systems, or private cloud APIs.
• Custom Execution Environment: Users have full control over the agent's environment. This allows for the installation of specific versions of Terraform, OpenTofu, providers, or other CLI tools and dependencies required by custom hooks or IaC modules. The agent's operating system can be customized, allowing users to define their own execution image.
• Compliance and Security: For organizations with specific security or compliance requirements, self-hosted agents ensure that code and credentials remain within the controlled network perimeter during execution.

This customization allows Scalr to meet diverse organizational requirements.

Conclusion

Scalr is a platform for automating and governing Terraform and OpenTofu workflows. Its CI/CD capabilities, including GitOps support, custom hooks, run triggers, and customizable execution environments, assist teams in managing infrastructure. Scalr provides tools for various levels of IaC automation and deployment complexity.

Further information is available in the Scalr documentation. A demo can be requested to view these features.

‍