Barque* enables standing up K8s and GitOps infrastructure in a fast repeatable way with flexibility on enable different types of workflows, manifest configurations, tools and cluster deployments.
Get started by creating an Azure DevOps organization, adding an ssh key and running the following.
Watch a barque of the workflows in action.
./setup.sh --org <AzDo-OrgName> -acr <existing-acr-name>
This will provision the following infrastructure for deploying an app:
Infra Deployed:
- Azure Project
- Azure Git Repos:
- application
- terraform-modules
- terraform-live
- manifest-live
- Azure Pipelines
- App PR Triggered
- App Release Triggered
- terraform-module-release
- terraform-infra-live-release
- Azure Git Repos:
- Azure AKS clusters
- Dev
- Staging
- QA
Example Workflow:
- Dev checks in code
- Security checks, linting, build push to ACR (automated)
- Update Dev manifests with image id from ACR - Deployed automatically to dev via flex pull (automated)
- Update Staging manifests with image id from ACR - Deployed automatically to staging via flux pull (automated)
- Open PR against production manifests with image id (automated)
- Operator merges PR when ready to move to production
- Prod cluster pulls updates to cluster
note this is a prototype and the script to deploy may change or a different mechanism might be used but concepts and ease of use will remain. Please open an issue to share thoughts and ways to improve.
./setup.sh --org <AzDo-OrgName> -acr <existing-acr-name>
--org
is an existing Azure DevOps Organization. Required.-acr
or--acr-name
is an existing Azure Container Registry. Required.-w
or--workflow-strategy
is a workflow strategy in the workflow-strategies directory. You can use an existing one or add your own strategy. Defaults torelease-flow
. Optional.-p
or--project-name
is the name of the Azure DevOps Project within the org. If the project does not exist, it will be created. Defaults togitops-test
. Optional.-r
or--repo-app-name
is the name of the application repository in Azure DevOps. If the repository does not exist, it will be created. Defaults toapp
. Optional.-a
or--app-repo
is the local filepath or the url of the application repository. Defaults to Azure Voting App repository. Optional.-tp
or--trigger-pipelines
determines whether this script runs the pipelines after creation. Defaults tofalse
. Optional.
Most demos and articles only demonstrate how the "Pull Request" flow of GitOps to deploy to production and leaves how you to figure out the rest of the story. The "rest of the story" ends up being a complex set of options that are dependent on each teams workflows, processes, and team structures.
Additionally, there are many moving parts (build pipelines, multiple repositories, infrastructure) required to set up a workflow and manifest repository in order to evaluate the complex set of options gitops. When a team is evaluating GitOps it is often useful to see an end to end solution quickly to get a sense of the flows required and make a decision on how to approach the final solution.
Not every customer or team is going to have the same set of requirements or needs. To that end Barque does not care what tooling you use under the hood it simply is the orchestrator for wiring all the components together.
To that end, Barque can be provided *Strategies" which enable different types of workflows, Manifest configurations, tools and cluster deployments.
Multiple pipeline workflows can be supported:
- PR strategies
- Ring based strategies
- Helm Operator (not implemented)
- Progressive delivery with flagger (not implemented)
Many more are possible...
The can be support for multiple tools and strategies as well as combinations of them.
- Kustomize
- Directory per env
- branch per env (not implemented)
- Repository per env (not implemented)
Not only should you be able to set up workflows but you need a strategy for deploying your clusters. To stratgies that are in progress are:
Docs on how this works will be completed later after idea is flushed out more.
- git clone
- mkdir ./workflow-strategies/$NEW_STRATEGY_NAME
- mkdir ./workflow-strategies/$NEW_STRATEGY_NAME/pipelines
- Add your templates to the folder. These templates will be copied into a
.azuredevops/templates
folder - mkdir ./workflow-strategies/$NEW_STRATEGY_NAME/manifest
- Add main pipelines to this folder. These will be copied to
.azuredevops
folder. They will not be override later. The user should modify these to add there custom solutions. Reference the tempaltes in.azuredevops/tempaltes
folder. -
- mkdir ./workflow-strategies/$NEW_STRATEGY_NAME/pipelines/scripts
- Add custom scripts to this folder to set up pipeline variables, etc.
See https://github.com/jsturtevant/barque/issues.
Azure Cli
- https://github.com/Azure/azure-cli-dev-tools
- https://github.com/Azure/azure-cli/blob/master/doc/extensions/authoring.md
First run of the pipeline give ACR error, is typically a caching error in Azure. Waiting a 5-10 mins resolves the issue. Atlernatively could use a Service Connection with a preset Service Principal.
##[error]Error Code: [1]
##[error]Error: Azure login failed
##[error]Script failed with error: Get Token request returned http error: 400 and server response: {"error":"unauthorized_client","error_description":"AADSTS700016: Application with identifier '***' was not found in the directory '***'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.\r\nTrace ID: db7ef84c-4e7c-4\r\nCorrelation ID: c2eb30-99fe-4a8b315\r\nTimestamp: 2020-05-13 23:33:54Z","error_codes":[700016],"timestamp":"2020-05-13 23:33:54Z","trace_id":"db7ef84c-4bd2-a46e-680fc5482700","correlation_id":"c26a-31c304e315","error_uri":"https://login.microsoftonline.com/error?code=700016"
Inspired by the work at https://github.com/Microsoft/bedrock/
- because every project needs a cool name