Bedrock

Bedrock is automation and tooling for operationalizing production Kubernetes clusters with a GitOps workflow. GitOps enables you to build a workflow around your deployments and infrastructure similiar to that of a typical development workflow: pull request based operational changes, point in time auditability into what was deployed on the Kubernetes cluster, and providing nonrepudation about who made those changes.

This GitOps workflow revolves around Fabrikate definitions that enable you to specify your deployments at a higher level of abstraction that separates structure from configuration. This makes them easier to maintain versus directly specifying them in Kubernetes resource manifest YAML or cobbling together shell scripts to build Kubernetes resource manifests from templating solutions. Fabrikate definitions also allow you to leverage common pieces across many deployments and to share structure amongst different clusters differentiated only by config.

Bedrock also provides guidance and automation for building GitOps pipelines with a variety of popular CI/CD orchestrators.

Finally, Bedrock provides a set of Terraform environment templates for deploying your Kubernetes clusters, including automation for setting up the GitOps Operator Flux in your cluster.

Getting Started

A Bedrock deployment follows three steps at a high level:

1. Create and deploy a GitOps enabled Kubernetes cluster.
2. Define a Fabrikate high level deployment definition.
3. Setup a GitOps pipeline to automate deployments of this definition to this cluster based on typical application and cluster lifecycle events.

The steps required to operationalize a production Kubernetes cluster can be pretty extensive, so we have also put together a simple walkthrough for deploying a first cluster that makes a great first step.

Community

Please join us on Slack for discussion and/or questions.

Contributing

We do not claim to have all the answers and would greatly appreciate your ideas and pull requests.

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

For project level questions, please contact Tim Park.