Automation for Production Kubernetes Clusters with a GitOps Workflow
Перейти к файлу
Nate 1850ba88f9
Nate.scheduled.builds (#1058)
* trigger Azure-simple integration test

* testing new simple IT

* testing var syntax

* adding tasks

* adjusting dependencies

* new changes

* checking in export task

* validating

* stage dependency test

* removing stages

* adding job dependency

* syntax switch on env vars

* adding job toggling to al IT

* Whitelist_Bedrock.

* merging stages to repair issue with pipeline vars

* syntax repair

* syntax

* Publishing artifacts for future repair

* removing debug prints

* removing comments

* Adding scheduled pipelines

* adjusting paths for template pipelines

* testing with comments

* Addint 0 trigger

* upgrading go version
2020-02-28 16:24:00 -05:00
.github/ISSUE_TEMPLATE Add acceptance criteria to issue template (#685) 2019-10-25 14:41:06 -07:00
cluster Fix type to Terraform 0.12 format (#957) 2020-02-06 13:09:56 -05:00
docs [DOC] Fix typo, state helm version and sample git repo name (#879) 2020-01-13 16:31:55 -08:00
gitops Fix helm init (#962) 2020-02-06 20:58:57 -08:00
pipelines Nate.scheduled.builds (#1058) 2020-02-28 16:24:00 -05:00
test Nate.scheduled.builds (#1058) 2020-02-28 16:24:00 -05:00
tools Support for using existing / requiring existing resource group(s). (#549) 2019-08-21 13:25:50 -07:00
.gitignore Repeatable load generation framework that runs on Bedrock (AKS) to load test the target service or application (#541) 2019-08-13 11:03:33 -07:00
LICENSE initial commit 2018-11-16 09:02:43 -08:00
README.md Correct typo in README (#750) 2019-11-11 12:23:22 -08:00
azure-pipelines.yml Nate.scheduled.builds (#1058) 2020-02-28 16:24:00 -05:00

README.md

Bedrock

Build Status Go Report Card

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.