The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Infrastructure as code (IaC) is the practice of managing and provisioning infrastructure through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. The IT infrastructure managed by this comprises both physical equipment such as bare-metal servers as well as virtual machines and associated configuration resources. The definitions are stored in a version control system, and changes are often applied automatically. IaC takes proven coding techniques and extends them to your infrastructure directly, effectively blurring the line between what is an application and what is the environment.
Our focus will be to provide tight integration with best of breed IaC tools, such that all infrastructure related workflows in GitLab are well supported. Our initial focus will likely be on Terraform.
Infrastructure and Application provisioning shouldn't be mixed! Application delivery is covered by our Continuous Delivery directions. Infrastructure as Code integrations leverage the features of generic Continuous Delivery, and extend those with the special aspects of infrastructure.
Our vision is to provide several levels of Infrastructure as Code support:
GitLab supports transitioning traditional I&O teams to automated Infrastructure as Code solutions from the first steps of providing a source code repository to enabling developers with self-service solutions.
According to Gartner, I&O automation is the second most common investment target in 2021. Adoption is often led by the move to cloud, but it's expected to rise from 5% to 40% by 2023 for on-prem infrastructure provisioning too. The biggest obstacles for adoption are the lack of developers educated in the area.
By providing easy to use primitives and with a focus on good developer experience, GitLab is well positioned to break down the obstacles of infrastructure as code adoption.
With GitLab's Infrastructure as Code support - in the order of importance - we are targeting:
As Infrastructure as Code usage scales across teams collaboration pain points around security, compliance and adopting best practices arise. Traditionally these pain points are solved by written documentation. Modern infrastructure as code applications have implemented Policy as Code tools to enable automated checking of infrastructure definitions against easy to write policy definitions. One prime example of this is Hashicorp's Sentinel.
The principles of Policy as Code are closely aligned with Infrastructure as Code. Within GitLab our existing primitives of integrated CI with CI job definition in-code model similar behavior to modern Policy as Code frameworks. At present our existing CI approach allows easy integration of special Policy as Code tools and GitLab. The primary difference with policy as code is the separation of duties, namely the appearance of a new persona, the compliance manager.
Today, GitLab's infrastructure as code support is at "Viable" maturity, and we are in the process of validating for "Complete" maturity. We offer deep integrations with Terraform in the form of
Collaboration around Infrastructure as Code is more involved than generic collaboration around code is, because every code change has a direct effect on the underlying infrastructure. To support IaC collaboration workflows, we have developed the Terraform Merge Request widget.
We plan to extend the widget with more insights and have it integrated with the Managed Terraform state.
We would like to provide GitLab users with an unmatched Terraform experience. This involves a Terraform backend that integrates with GitLab pipelines without any setup from the user, and allows advanced state management from within GitLab. GitLab provides a versioned, encrypted Terraform state backend and templates to get started with it. The state backend removes every friction around starting a new Terraform project, and streamlines the complexity of infrastructure to manage.
We have many ideas planned to provide even more funtionality and a better experience around the GitLab Managed Terraform state.
Please contribute to our plans in the related epic.
For larger infrastructures, re-usable modules are a call part of the IaC codebase. We provide a Terraform module registry as part of GitLab by extending the current module registries. We plan to add insights into modules usage for module owners. This should help around deprecations and risk management of modules.
Please, contribute to our plans around the registry in the Terraform registry Epic
We don't consider GitLab a replacement of IaC tools, but rather a complement. Based on several discussions, we consider Terraform the de facto standard of infrastructure provisioning, and we want to support Terraform based workflows.
Given the trends around containerization, ephemeral and immutable infrastructures, we expect the relevance of configuration management tools to decrease, and infrastructure provisioning to gain more market share.
As already mentioned, we've several customers using IaC solutions with GitLab. The following list shows our primary points of contacts for customer interviews around IaC.
CloudSkiff describes itself as a CI/CD for Terraform, on steroids.
We consider HashiCorp to be a partner, not a competitor, and we do not support many advanced features offered by Terraform Enterprise.