This is the product vision for Configure.
The Configure stage solves user problems related to the configuration and operation of applications and infrastructure, including features like Auto DevOps, Kubernetes integration, runbooks, serverless workloads, and ChatOps. We aim to make complex tasks (such as standing up new environments) fast and easy. We provide operators all the necessary tools to execute their day-to-day actions upon their infrastructure.
In keeping with our single application promise, we want GitLab to be a robust, best-of-breed tool for operators as much as it is for developers. Our vision is that operators will use GitLab as their main day-to-day tool for provisioning, configuring, testing, and decomissioning infrastructure.
We understand GitLab will play side-by-side with existing tools which teams have already invested considerable time and money. As a result, we will extend GitLab's Configure features to have rich interactions through both the GUI and API. To provide the best experience possible we must identify best-of-breed tools in this segment that share our open source DNA and provide seamless integration.
GitLab is the most popular way to deploy to Kubernetes. Many organizations (of all scales) have adopted Kubernetes prior to their use of our GitLab. We will support this model by identifying the most common set of use cases where Kubernetes clusters exist. We'll then enable those existing clusters to be plugged in to GitLab so users can gain the value of using our integrated development approach. This includes both enterprise users of Kubernetes (typically OpenShift) and startup Kubernetes use (typically public cloud providers).
Our Kubernetes integration currently operates under the assumption of cluster-admin privilege. While this is acceptable
for most use cases, there is a large minority that, appropriately, operates strictly on least-privilege security
principle. In these environments only single-namespace access is allowed and cluster-wide access is denyed. To encourage
adoption of these principles, we will provide the same rich integration we provide today for this further restricted use
case.
We aim to support the nascent serverless environment on Kubernetes as well as public cloud providers' serverless offerings. The quickly changing landscape on Kubernetes is a big challenge to keep up with. On the public cloud side, our biggest challenge is to provide a solution that relieves potential vendor lock-in.
Our opportunities in the Configure stage are derived from the Ops Section opportunities. Namely:
We're pursuing a few key principles within the Configure stage.
We recognize getting started with modern devops practices from zero is hard. With Auto DevOps, GitLab already provides a great framework to automatically detect, build, test, secure, deploy, and monitor your application. We'll extend Auto DevOps to provide further customization of your application, such as automatically securing it with an SSL certificate or easily define a custom domain. Additionally, we will extend its deployment capabilities to provide built-in best practices, such as blue/green deployments, postgress replication, and postgres backup/restore.
If your application is not a good candidate for Auto DevOps, GitLab will provide great templates with smart defaults which will provide a great experience for other approaches (such as serverless and micro-services) making tasks such as scaling functions and inter-connecting micro-services, quick & easy.
Teams who begin their journey with GitLab may already have existing Kubernetes resources in place. So these can be used effectively, we will detect and track the state of applications which are already installed in-cluster. Following sensible conventions, once a cluster is added to any level of your workflow, GitLab will show which apps are installed and offer all relevant features, regardless of how those apps have been installed.
Provisioning infrastructure is a critical responsibility of the operations team. GitLab will make it easy to provision resources either directly with your cloud of choice or by leveraging your existing infrastructure-as-code resources. To that end, GitLab will offer cluster creation workflows with every major cloud provider as well as robust integration with leading IaC providers such as Terraform.
For those teams just getting started with IaC, GitLab will lower the intial investment to use Terraform, with Git as the source of truth for IaC.
Providing a resilient production environment is an important part of day-to-day Ops. However, planning for real-world outages, edge conditions, and erratic applications behavior, is not always possible. GitLab will provide seamless integration with cloud-native chaos engineering tools, allowing ops teams to easily and realistically run experiments on their infrastructure. Insights gained from these experiments will allow Ops teams to harden their deployments and plan for real-world failures.
We want operators to use GitLab as their main day-to-day system. In addition to managing infrastructure, GitLab will provide features for downtime action planning (via Runbooks) as well as ways to quickly execute actions on both applications and infrastructure (via ChatOps).
Our Key Performance Indicator for the Configure stage is the Configure SMAU (stage monthly active users).
Configure SMAU is determined by tracking how users configure, interact, and view the features contained within the stage. The following features are considered:
| Configure | Interact | View |
|---|---|---|
| Create Kubenetes cluster on GKE | Dismiss Auto DevOps banner | View cluster health metrics |
| Add existing Kubernetes cluster | Run Auto DevOps pipeline | View serverless page |
| Enable Auto DevOps | JupyterHub login | View function metrics (/../../../serverless/functions/*/my-function) |
| Install Kubernetes application - Helm - Ingress - Cert Manager - Prometheus - GitLab Runner - JupyterHub - Knative |
Upgrade Kubernetes application | - |
| Enable Slack application on gitlab.com | Uninstall Kubernetes application | - |
| Enable Slack slash commands | - | - |
| Use Auto DevOps templates (composable Auto DevOps) | - | - |
See the corresponding Periscope dashboard (internal).
Our vision for “Auto DevOps” is to leverage our single application to assist users in every phase of the development and delivery process, implementing automatic tasks that can be customized and refined to get the best fit for their needs.
With the dramatic increase in the number of projects being managed by software teams (especially with the rise of micro-services), it's no longer enough to just craft your code. In addition, you must consider all of the other aspects that will make your project successful, such as tests, quality, security, logging, monitoring, etc. It's no longer acceptable to add these things only when they are needed, or when the project becomes popular, or when there's a problem to address; on the contrary, all of these things should be available at inception.
That's why we created Auto DevOps. We also made it composable so you can pick and choose which stages to use our default templates in.
Watch the video explaining our vision on Auto DevOps
Learn more • Documentation • Vision
Configuring and managing your Kubernetes clusters can be a complex, time-consuming task. We aim to provide a simple way for users to configure their clusters within GitLab; tasks such as scaling, adding, and deleting clusters become simple, single-click events.
Learn more • Documentation • Vision
Taking full advantage of the power of the cloud computing model and container orchestration, cloud native is an innovative way to build and run applications. A big part of our cloud native strategy is around serverless. Serverless computing provides an easy way to build highly scalable applications and services, eliminating the pains of provisioning & maintaining.
Learn more • Documentation • Vision
Incident Management will
allow operators to have real-time view into the happenings of their systems.
Building upon this concept, we envision rendering of runbook inside of GitLab as
interactive documents for operators which in turn could trigger automation
defined in gitlab-ci.yml.
The next generation of our ChatOps implementation will allow users to have a dedicated interface to configure, invoke, and audit ChatOps actions, doing it in a secure way through RBAC.
Infrastructure as code (IaC) is the practice of managing and provisioning infrastructure through machine-readable definition files, rather than manual 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. 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 be on Terraform.
Chaos engineering in a powerful practice that allows operators to architect powerful distributed systems that can withstand turbulent conditions. We want operators to be able to run downtime scenarios randomly to test the resilience of their architecture. Starting with the minimum units (pods) all the way the largest units (regions).
Compute costs are a significant expenditure for many companies, whether they are in the cloud or on-premise. Managing these costs is an important function for many companies. We aim to provide easy-to-understand analysis of your infrastructure that could identify overprovisioned infrastructure (leading to waste), recommended changes, estimated costs, and automatic resizing.
At GitLab, one of our values is that everyone can contribute. If you're looking to get involved with features in the Configure area, there are a couple searches you can use to find issues to work on:
Contribute for Prize program is available on our Code Contributor Programs page.You can read more about our general contribution guidelines here.
In general, we follow the same prioritization guidelines as the product team at large. Issues will tend to flow from having no milestone, to being added to the backlog, to being added to this page and/or a specific milestone for delivery.
You can see our entire public backlog for Configure at this link; filtering by labels or milestones will allow you to explore. If you find something you're interested in, you're encouraged to jump into the conversation and participate. At GitLab, everyone can contribute!
Issues with the "direction" label have been flagged as being particularly interesting, and are listed in the sections below.
.gitlab/auto-deploy-values.yaml in Auto DevOpsThere are a number of other issues that we've identified as being interesting that we are potentially thinking about, but do not currently have planned by setting a milestone for delivery. Some are good ideas we want to do, but don't yet know when; some we may never get around to, some may be replaced by another idea, and some are just waiting for that right spark of inspiration to turn them into something special.
Remember that at GitLab, everyone can contribute! This is one of our fundamental values and something we truly believe in, so if you have feedback on any of these items you're more than welcome to jump into the discussion. Our vision and product are truly something we build together!
