FAQ
Bedrock is a set of automation, tooling and infrastructure for deploying production-level Kubernetes clusters with a GitOps flow. The goal is to make development teams productive through automating DevOps best practices through Continuous Integration and Continuous Delivery. As a developer, a commit into application code will pass through the GitOps pipeline and end up in production Kubernetes cluster with a single approval click or code commit.
Bedrock uses Flux to synchronize all manifests in a repository with a Kubernetes cluster and monitors container registries for new images while updating the manifests accordingly. We also include alerting using Prometheus which would help monitor the deployments in case of any issues.
Bedrock at the moment is setup to work end-to-end with Azure DevOps, but plans are in place to support Travis, CircleCI, Jenkins, Spinnaker, Tekton and Brigade. We're also welcoming pull requests for anything that is currently not supported.
High level definition is a description of the Kubernetes deployment which includes dependencies on microservices and any external infrastructure (stacks) they consume. We use a tool called Fabrikate to install dependencies specified in this high level definition and create the Kubernetes manifest yaml definitions that are necessary to setup the cluster.
Fabrikate simplifies the front end of the GitOps workflow: it takes a high level description of your deployment, a target environment config (such as prod or staging), and renders the Kubernetes resource manifests for that deployment utilizing templating tools like Helm.
Here is a good guide on how to get started writing a high level definition.
Different environments are needed for an application to have fool proof deployment and user experience, for example a different environment for production and development. Bedrock supports deploying multiple platforms using the terraform config in azure-multiple-clusters.
You can specify multiple configurations in a high level definition and fabrikate can build combinations of these environments. For example:
If you would like to generate prod-east from this configuration, simply type fab generate prod-east and staging-central using fab generate staging-central for example.
When this configuration is generated for all specified environments and lands in the manifest repository, we get manifest folders generated for each of the configs as shown below.
Flux can be configured in each cluster to listen to a specific path in this repository and it will only apply changes that happen in that folder.
Even though we recommend using multiple clusters for multiple environments (for simplicity and security purposes), there's ways we can configure all of them to run on a single cluster, for example by isolating them with a namespace prefix. In this case, a single instance of flux would update all the environments at once.
When an approver sets off a release for an environment that is not configured for automatic releases, a release pipeline is started which begins by first updating the image tag of the newly built ACR image into the HLD repository.
These steps can be repeated for n amount of environment promotions depending on the number of Kubernetes environments a dev team maintains for an application.
Environment promotion is the process dev teams use to move across different environments, for example when smoke tests and QA tests are performed on a build, it's ready to be deployed to staging. When the working functionality is verified in staging, it's ready to be deployed to production.
Some teams perform a swap between staging and production so that they can swap back in case of any errors or failures that were not caught during testing.
Bedrock updates the image tag that is referred in the high level definition, for let's say the dev environment. When the HLD receives an update, it fires the manifest yaml generation pipeline for the dev environment and produces manifest files which are pushed into the manifest repository folder dev/. Flux picks up this change and applies it to the Kubernetes cluster automatically.
When the user/operator is ready to promote this dev environment to QA, depending on the rules for this environment, they may kick off a release for QA which will perform the repeat steps as above for the QA environment, and the cycle continues.