├── .github └── workflows │ └── ci.yml ├── .markdownlint.json ├── CODE-OF-CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE ├── README.md └── img └── gitops_conceptual_diagram.svg /.github/workflows/ci.yml: -------------------------------------------------------------------------------- 1 | name: CI 2 | 3 | on: 4 | push: 5 | pull_request: 6 | 7 | jobs: 8 | lint: 9 | runs-on: ubuntu-latest 10 | steps: 11 | - uses: actions/checkout@v3 12 | - name: Lint Markdown files 13 | uses: avto-dev/markdown-lint@v1.5.0 14 | with: 15 | args: '.' 16 | - name: install markdown-toc 17 | run: | 18 | npm install -g markdown-toc 19 | - name: verify TOC is up-to-date 20 | run: | 21 | markdown-toc --bullets="-" -i README.md 22 | git diff --exit-code 23 | -------------------------------------------------------------------------------- /.markdownlint.json: -------------------------------------------------------------------------------- 1 | { 2 | "default": true, 3 | 4 | "line_length": false, 5 | "no-bare-urls": false, 6 | 7 | "comment": "Ignore errors like MD026/no-trailing-punctuation Trailing punctuation in heading [Punctuation: '?'] in README.md's title", 8 | "no-trailing-punctuation": false, 9 | 10 | "comment": "Ignore some MD033/no-inline-html errors, as we sometimes need raw HTML for more advanced styling", 11 | "no-inline-html": { 12 | "allowed_elements": [ 13 | "p", 14 | "img" 15 | ] 16 | } 17 | } 18 | -------------------------------------------------------------------------------- /CODE-OF-CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, gender identity and expression, level of experience, 9 | nationality, personal appearance, race, religion, or sexual identity and 10 | orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at https://weave-community.slack.com. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at [http://contributor-covenant.org/version/1/4][version] 72 | 73 | [homepage]: http://contributor-covenant.org 74 | [version]: http://contributor-covenant.org/version/1/4/ 75 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contribution Guidelines 2 | 3 | We appreciate and recognize all contributors. Please ensure your pull request adheres to the following guidelines: 4 | 5 | - Search previous suggestions before making a new one, as yours may be a duplicate. 6 | - Make sure your contribution is useful before submitting. 7 | - Make an individual pull request for each suggestion. 8 | - Use the following format: `[Item Name](link) - Short Description` 9 | - Link additions should be added in alphabetical order of the relevant category. 10 | - New categories or improvements to the existing categorization are welcome. 11 | - Check your spelling and grammar. 12 | - Make sure your text editor is set to remove trailing whitespace. 13 | - The pull request and commit should have a useful title as well as why you are proposing the change(s). 14 | 15 | Thank you for your suggestions! 16 | 17 | ## Adding something to an Awesome list 18 | 19 | If you have something awesome to contribute to an awesome list, this is how you do it. 20 | 21 | You'll need a [GitHub account](https://github.com/join)! 22 | 23 | 1. Access the awesome list's GitHub page. For example: https://github.com/sindresorhus/awesome 24 | 2. Click on the `readme.md` file: ![Step 2 Click on Readme.md](https://cloud.githubusercontent.com/assets/170270/9402920/53a7e3ea-480c-11e5-9d81-aecf64be55eb.png) 25 | 3. Now click on the edit icon. ![Step 3 - Click on Edit](https://cloud.githubusercontent.com/assets/170270/9402927/6506af22-480c-11e5-8c18-7ea823530099.png) 26 | 4. You can start editing the text of the file in the in-browser editor. Make sure you follow guidelines above. You can use [GitHub Flavored Markdown](https://help.github.com/articles/github-flavored-markdown/). ![Step 4 - Edit the file](https://cloud.githubusercontent.com/assets/170270/9402932/7301c3a0-480c-11e5-81f5-7e343b71674f.png) 27 | 5. Say why you're proposing the changes, and then click on "Propose file change". ![Step 5 - Propose Changes](https://cloud.githubusercontent.com/assets/170270/9402937/7dd0652a-480c-11e5-9138-bd14244593d5.png) 28 | 6. Submit the [pull request](https://help.github.com/articles/using-pull-requests/)! 29 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | 2 | The MIT License (MIT) 3 | 4 | Copyright (c) 2014 Thiago Avelino 5 | 6 | Permission is hereby granted, free of charge, to any person obtaining a copy 7 | of this software and associated documentation files (the "Software"), to deal 8 | in the Software without restriction, including without limitation the rights 9 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 10 | copies of the Software, and to permit persons to whom the Software is 11 | furnished to do so, subject to the following conditions: 12 | 13 | The above copyright notice and this permission notice shall be included in all 14 | copies or substantial portions of the Software. 15 | 16 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 17 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 18 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 19 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 20 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 21 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 22 | SOFTWARE. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Awesome-GitOps 2 | 3 | [![Awesome](https://awesome.re/badge.svg)](https://awesome.re) 4 | 5 | A curated list for awesome GitOps resources inspired by [@sindresorhus' awesome](https://github.com/sindresorhus/awesome) 6 | 7 | We follow this [code of conduct](CODE-OF-CONDUCT.md). 8 | 9 | ## What is GitOps? 10 | 11 | GitOps is a way to do Kubernetes cluster management and application delivery. 12 | It works by using [Git](https://git-scm.com/) as a single source of truth for 13 | [declarative infrastructure and applications](https://en.wikipedia.org/wiki/Infrastructure_as_code), 14 | together with tools ensuring the _actual state_ of infrastructure and 15 | applications converges towards the _desired state_ declared in Git. With Git at 16 | the center of your delivery pipelines, developers can make pull requests to 17 | accelerate and simplify application deployments and operations tasks to your 18 | infrastructure or container-orchestration system (e.g. [Kubernetes](https://kubernetes.io/)). 19 | 20 |

Conceptual diagram of GitOps-based infrastructure

21 | 22 | ## Why is GitOps awesome? 23 | 24 | It [increases developer productivity](https://www.weave.works/technologies/gitops/#key-benefits), [enhances developer experience](https://www.weave.works/technologies/gitops/#key-benefits), [improves stability](https://www.weave.works/technologies/gitops/#key-benefits), all while having [higher reliability](https://www.weave.works/technologies/gitops/#key-benefits), [higher consistency](https://www.weave.works/technologies/gitops/#key-benefits) and [stronger security guarantees](https://www.weave.works/technologies/gitops/#key-benefits). 25 | 26 | Modern software development practices _assume_ support for reviewing changes, tracking history, comparing versions, and rolling back bad updates; GitOps applies the same tooling and engineering perspective to managing the systems that deliver direct business value to users and customers. 27 | 28 | 29 | 30 | - [Background](#background) 31 | - [Tools](#tools) 32 | - [Ancillary Tools](#ancillary-tools) 33 | - [Notifications](#notifications) 34 | - [Secrets](#secrets) 35 | - [Tutorials](#tutorials) 36 | - [Community](#community) 37 | 38 | 39 | 40 | ## Background 41 | 42 | - [Operations by pull request](https://www.weave.works/blog/gitops-operations-by-pull-request) - a blog entry about how GitOps came about at Weaveworks 43 | - [GitOps.tech](https://www.gitops.tech/) - a summary of how GitOps works 44 | - [GitOps Conversation Kit](https://gitops-community.github.io/kit/) - How to showcase GitOps awesomeness and convince all stakeholders to implement it 45 | - [GitOps Working Group](https://github.com/gitops-working-group/gitops-working-group) - GitHub repo of GitOps working group under the CNCF App Delivery SIG. 46 | 47 | ## Tools 48 | 49 | - [ArgoCD](https://github.com/argoproj/argo-cd) - Declarative continuous deployment for Kubernetes 50 | - [Atlantis](https://www.runatlantis.io/) - Terraform pull request automation 51 | - [Autoapply](https://github.com/autoapply/autoapply) - Automatically apply changes from a Git repository to a Kubernetes cluster 52 | - [Carvel](https://carvel.dev) — Tool suite for building, packaging, and managing software on Kubernetes in a GitOps way 53 | - [CloudBees Rollout](https://rollout.io/) - Feature Flag as-a-Service that leverages GitOps & Config-as-Code (commercial product from CloudBees) 54 | - [Flux](https://github.com/fluxcd/flux2) - Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit 55 | - [Helm Operator](https://github.com/fluxcd/helm-operator) - Automates Helm Chart releases in a GitOps manner 56 | - [Flagger](https://github.com/weaveworks/flagger) - Progressive delivery Kubernetes operator (Canary, A/B testing and Blue/Green deployments automation) 57 | - [Ignite](https://github.com/weaveworks/ignite) - A Virtual Machine manager with a container UX and built-in GitOps 58 | - [Faros](https://github.com/pusher/faros) - CRD based GitOps controller 59 | - [Jenkins X](https://jenkins-x.io/) - a CI/CD platform for Kubernetes that provides pipeline automation, built-in GitOps and preview environments 60 | - [Kubefirst](https://github.com/kubefirst/kubefirst) - Fully-automated OSS delivery & infrastructure management gitops platforms 61 | - [KubeStack](https://www.kubestack.com/) - GitOps framework using Terraform for Cloud Kubernetes distros (AKS, GKE, and EKS) with CI/CD examples for common tools 62 | - [Sceptre](https://github.com/Sceptre/sceptre) - Sceptre is a tool to drive AWS CloudFormation as part of a CI/CD pipeline by using Hooks 63 | - [Weave GitOps OSS](https://github.com/weaveworks/weave-gitops) - Weave GitOps is a simple open source developer platform for people who want cloud native applications, without needing Kubernetes expertise. 64 | - [Weave GitOps Enterprise](https://www.weave.works/product/gitops-enterprise/) - Weave GitOps Enterprise is a continuous operations product that makes it easy to deploy and manage Kubernetes clusters and applications at scale in any environment. (commercial product from Weaveworks) 65 | - [Werf](https://werf.io) - GitOps tool with advanced features to build images and deploy them to Kubernetes (integrates with any existing CI system) 66 | - [PipeCD](https://pipecd.dev/) - Continuous Delivery for Declarative Kubernetes, Serverless and Infrastructure Applications 67 | - [Grant.rs](https://github.com/duyet/grant.rs) - Manage Redshift/Postgres privileges in GitOps style 68 | - [Gimlet](https://github.com/gimlet-io/gimlet) - The Flux-based Internal Developer Platform 69 | 70 | ## Ancillary Tools 71 | 72 | ### Notifications 73 | 74 | - [Fluxcloud](https://github.com/topfreegames/fluxcloud) - Slack notifications for Flux without Weave Cloud 75 | 76 | ### Secrets 77 | 78 | - [argocd-vault-plugin](https://argocd-vault-plugin.readthedocs.io/en/stable/) - An ArgoCD plugin to retrieve secrets from Vault and inject them into Kubernetes resources 79 | - [git-secret](https://github.com/sobolevn/git-secret) - A bash-tool to store your private data inside a git repository 80 | - [Kamus](https://github.com/Soluto/kamus) - Zero-trust secret encryption/decryption solution for Kubernetes applications 81 | - [Sealed Secrets](https://github.com/bitnami-labs/sealed-secrets) - One-way encrypted Secrets 82 | - [SOPS](https://github.com/mozilla/sops) - Secrets OPerationS 83 | - [Vault Secrets Operator](https://github.com/ricoberger/vault-secrets-operator) - Sync secrets from Vault with Kubernetes 84 | 85 | ## Tutorials 86 | 87 | - [Managing Helm releases the GitOps way](https://github.com/fluxcd/flux2-kustomize-helm-example) - Flux and Helm Operator tutorial 88 | - [Automating Istio canary deployments with GitOps](https://github.com/stefanprodan/gitops-istio) - Progressive Delivery tutorial with Flagger, Flux, Helm Operator and Istio 89 | - [Managing a multi-tenant cluster with GitOps](https://github.com/fluxcd/flux2-multi-tenancy) - Flux and Kustomize tutorial 90 | - [GitOps-style continuous delivery with Cloud Build](https://cloud.google.com/kubernetes-engine/docs/tutorials/gitops-cloud-build) - Google Cloud Build tutorial 91 | 92 | ## Community 93 | 94 | - [Kubernetes slack](https://slack.kubernetes.io/) - #gitops channel for discussion of GitOps patterns and tooling 95 | - [CNCF slack](https://slack.cncf.io/) - #flux channel for discussion of GitOps patterns and tooling 96 | - [Weaveworks slack](https://slack.weave.works/) - multiple channels (including #flagger, #wksctl and others) to discuss Weaveworks GitOps products, give feedback, and talk about general approaches 97 | --------------------------------------------------------------------------------