{"id":15715969,"url":"https://github.com/kbrew-dev/kbrew","last_synced_at":"2025-10-07T14:39:23.205Z","repository":{"id":40270751,"uuid":"331918304","full_name":"kbrew-dev/kbrew","owner":"kbrew-dev","description":"kbrew is homebrew for Kubernetes","archived":false,"fork":false,"pushed_at":"2023-02-25T08:32:05.000Z","size":1097,"stargazers_count":192,"open_issues_count":44,"forks_count":19,"subscribers_count":8,"default_branch":"main","last_synced_at":"2025-05-07T17:51:42.696Z","etag":null,"topics":["brew","gitops","golang","helm","kbrew","kubernetes","kubernetes-deployment"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/kbrew-dev.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2021-01-22T10:54:31.000Z","updated_at":"2025-01-14T08:51:18.000Z","dependencies_parsed_at":"2024-06-18T21:30:26.908Z","dependency_job_id":"8f04dbe7-08c0-4d64-9406-5efa89402b43","html_url":"https://github.com/kbrew-dev/kbrew","commit_stats":{"total_commits":79,"total_committers":8,"mean_commits":9.875,"dds":"0.31645569620253167","last_synced_commit":"e418f0eadc88452eff3a75f56a5dc33e5b5932a9"},"previous_names":[],"tags_count":9,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kbrew-dev%2Fkbrew","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kbrew-dev%2Fkbrew/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kbrew-dev%2Fkbrew/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kbrew-dev%2Fkbrew/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kbrew-dev","download_url":"https://codeload.github.com/kbrew-dev/kbrew/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":252931391,"owners_count":21827104,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["brew","gitops","golang","helm","kbrew","kubernetes","kubernetes-deployment"],"created_at":"2024-10-03T21:43:35.074Z","updated_at":"2025-10-07T14:39:18.145Z","avatar_url":"https://github.com/kbrew-dev.png","language":"Go","funding_links":[],"categories":["Go"],"sub_categories":[],"readme":"# kbrew\n\n[![CI](https://github.com/kbrew-dev/kbrew/actions/workflows/go.yml/badge.svg)](https://github.com/kbrew-dev/kbrew/actions/workflows/go.yml) [![Go Report Card](https://goreportcard.com/badge/github.com/kbrew-dev/kbrew)](https://goreportcard.com/report/github.com/kbrew-dev/kbrew)\n[![Release Version](https://img.shields.io/github/v/release/kbrew-dev/kbrew?label=kbrew)](https://github.com/kbrew-dev/kbrew/releases/latest)\n[![License](https://img.shields.io/github/license/kbrew-dev/kbrew?color=light%20green\u0026logo=github)](https://github.com/kbrew-dev/kbrew/blob/main/LICENSE)\n\n\n\n![kbrew-logo](./images/kbrew-logo.png)\n\n\nkbrew is a CLI tool for Kubernetes which makes installing any complex stack easy in `one step` (And yes we are definitely inspired by Homebrew from MacOS)\n\nLet's take the example of installing Kafka on a Kubernetes cluster. If you are a developer trying this on a non-prod environment, you want a quick and simple way to set it up. But a typical process looks like this:\n\n - You need a cert-manager, Zookeeper \u0026 kube-prometheus-stack for monitoring installed.\n - Zookeeper is an operator so you need to create a CR of the Zookeeper cluster after installation of the operator is done.\n - Then you have to install Kafka operator.\n - Finally, you have to create a CR of Kafka and wait for everything to stabilize.\n - And lastly, create a ServiceMonitor resource to enable Prometheus scraping.\n\nWith kbrew, all of this happens with a \"one step\":\n\n```\nkbrew install kafka-operator\n```\n\nSimilarly when you install a Rook Ceph cluster - it makes it a `one step easy`:\n\n![](./images/rook-demo.gif)\n\n\u003e Any engineering is not without tradeoffs and we are not claiming that this is a silver bullet. Please refer to the Goals and FAQ sections for details.\n\nTable of Contents\n=================\n\n* [Goals](#goals)\n   * [One step Easy for users](#one-step-easy-for-users)\n   * [Fully Configured \u0026amp; functional](#fully-configured--functional)\n   * [Recipe - abstracts complexity!](#recipe---abstracts-complexity)\n* [Installation](#installation)\n   * [Install the pre-compiled binary](#install-the-pre-compiled-binary)\n   * [Compiling from source](#compiling-from-source)\n      * [Step 1: Clone the repo](#step-1-clone-the-repo)\n      * [Step 2: Build binary using make](#step-2-build-binary-using-make)\n* [CLI Usage](#cli-usage)\n   * [Commonly used commands](#commonly-used-commands)\n      * [kbrew search](#kbrew-search)\n      * [kbrew info](#kbrew-info)\n      * [kbrew install](#kbrew-install)\n      * [kbrew update](#kbrew-update)\n      * [kbrew remove](#kbrew-remove)\n* [Recipes](#recipes)\n   * [Recipe structure](#recipe-structure)\n      * [Application](#application)\n         * [Arguments](#arguments)\n      * [Pre \u0026amp; Post Install](#pre--post-install)\n      * [Pre and Post Cleanup](#pre-and-post-cleanup)\n* [FAQ](#faq)\n   * [How is kbrew different than Helm or Kubernetes Operator?](https://github.com/kbrew-dev/kbrew#how-is-kbrew-different-than-helm-or-kubernetes-operator)\n   * [Should I use kbrew for installing applications in a production environment?](#should-i-use-kbrew-for-installing-applications-in-a-production-environment)\n   * [How can I contribute recipes for a project/tool?](#how-can-i-contribute-recipes-for-a-projecttool)\n   * [How is analytics used?](#how-is-analytics-used)\n   * [What data is collected for analytics?](#what-data-is-collected-for-analytics)\n   * [Who is developing kbrew?](#who-is-developing-kbrew)\n\nCreated by [gh-md-toc](https://github.com/ekalinin/github-markdown-toc)\n\n## Goals\n\n### `One step` Easy for users\n\nWe are basically optimizing for `one step` install easy for developers. You end up installing applications in dev/tinkering environments multiple times and it should not be this hard. Also, you should not have to write `glue code` or shell scripts to make it work!\n\n### Fully Configured \u0026 functional\n\n`One step` would not be true to its promise if you had to `configure` things such as StorageClass or verify the version of Kubernetes etc. It should work and be fully functional to use right after installation.\n\n### Recipe - abstracts complexity!\n\nWhile we are making it easy for users to install any application in one step, we are pushing the complexity to the recipe. This means the recipe authors have to understand and write recipes that just work!\n\n## Installation\n\n\u003cdetails\u003e\n   \u003csummary\u003e(Click to expand)\u003c/summary\u003e \n \n### Install the pre-compiled binary\n\n```bash\nexport BINDIR=/usr/local/bin\ncurl -sfL https://raw.githubusercontent.com/kbrew-dev/kbrew/main/install.sh | sh\n```\n\n### Compiling from source\n\n#### Step 1: Clone the repo\n\n```bash\ngit clone https://github.com/kbrew-dev/kbrew.git\n```\n\n#### Step 2: Build binary using make\n\n```bash\nmake\n```\n\u003c/details\u003e\n \n## CLI Usage\n\n\u003cdetails\u003e\n   \u003csummary\u003e(Click to expand)\u003c/summary\u003e \n\n```\n$ kbrew --help\nA CLI tool for Kubernetes which makes installing any complex stack easy in one step.\n\nUsage:\n  kbrew [command]\n\nAvailable Commands:\n  analytics   Manage analytics setting\n  completion  Output shell completion code for the specified shell\n  help        Help about any command\n  info        Describe application\n  install     Install application\n  remove      Remove application\n  search      Search application\n  update      Update kbrew and recipe registries\n  version     Print version information\n\nFlags:\n  -c, --config string       config file (default is $HOME/.kbrew.yaml)\n      --config-dir string   config dir (default is $HOME/.kbrew)\n      --debug               enable debug logs\n  -h, --help                help for kbrew\n  -n, --namespace string    namespace\n\nUse \"kbrew [command] --help\" for more information about a command.\n```\n\n### Commonly used commands\n\n#### kbrew search\n\nSearches for a recipe for the given application. Lists all the available recipes if no application name is passed.\n\n#### kbrew info\n\nPrints applications details including registry and dependency information. \n\n#### kbrew install\n\nInstalls a recipe in your cluster with all pre \u0026 posts steps and applications.\n\n#### kbrew update\n\nChecks for kbrew updates and upgrades automatically if a newer version is available. Fetches updates for all the kbrew recipe registries\n\n#### kbrew remove \n\nUninstalls the application and its dependencies.\n\n\u003c/details\u003e\n \n## Recipes\n\nA kbrew recipe is a YAML file that declares the installation process of a Kubernetes app. It allows to *brew* Helm charts or vanilla Kubernetes manifests with scripts, also managing dependencies with other recipes.\n\nRecipes can be grouped in a structured directory called `Registry`. kbrew uses the [kbrew-registry](https://github.com/kbrew-dev/kbrew-registry/) by default.\n\n### Recipe structure\n\nThe process of how kbrew manages the installation of an app according to the recipe specification is depicted below. As can be seen, kbrew takes care of the order of pre/post actions.\n\n![kbrew-install](./images/kbrew-install.png)\n\n\nSimilarly, while removing an app, kbrew takes care of the order of removal of the dependent apps and the cleanup steps specified via `pre/post_cleanup` in the recipe.\n\n![kbrew-install](./images/kbrew-remove.png)\n\nA bare-bones structure of a recipe is a composition of pre-install steps, install and post-install steps. Each step could have another application being installed or a further set of steps.\n\n```\napiVersion: v1\nkind: kbrew\napp:\n  repository:\n    url: https://raw.githubusercontent.com/repo/manifest.yaml\n    type: raw\n  args:\n    Deployment.nginx.spec.replicas: 4\n  namespace: default\n  version: v0.17.0\n  pre_install:\n  - apps:\n      - OtherApp\n  - steps:\n      - echo \"installing app\"\n  post_install:\n  - steps:\n      - echo \"done installing\"\n  pre_cleanup:\n  - steps\n      - echo \"deleting prerequisite\"\n  post_cleanup:\n  - steps:\n      - echo \"app deleted\"\n```\n\n#### Application\n\n- `app` is the declaration of how a Kubernetes application - a Helm chart or a YAML manifest - will get installed.\n  * `repository`: defines the source of the app\n    - `url`: location of a Helm chart or a Kubernetes YAML manifest\n    - `type`: can be `helm` or `raw`\n\nFor example for the Kafka recipe, we will use the Helm chart from Banzaicloud and point to the Helm repo where the chart is available.\n\n```\napp:\n  repository:\n    name: banzaicloud-stable\n    url: https://kubernetes-charts.banzaicloud.com\n    type: helm\n```\n\n##### Arguments\n\nkbrew allows you to modify the app via arguments that can modify the Helm chart values or manifest field values.  kbrew supports passing arguments to recipes as [Go templates](https://pkg.go.dev/text/template).\n\nAll the functions from the [Sprig library](http://masterminds.github.io/sprig/) and the [lookup](https://helm.sh/docs/chart_template_guide/functions_and_pipelines/#using-the-lookup-function) \u0026 [include](https://helm.sh/docs/howto/charts_tips_and_tricks/#using-the-include-function) functions from Helm are supported.\n\n**Helm app**: Arguments to a helm app can be the key-value pairs offered by the chart in its values.yaml file.\n\n**Raw app**: These arguments patch the manifest of a raw app and can be specified in the format: `\u003cKind\u003e.\u003cName\u003e.\u003cFieldPath\u003e: \u003cvalue\u003e`. For example, to change `spec.replicas` of a `Deployment` named `nginx`, specify `Deployment.nginx.spec.replicas`\n\nFor example for [Nginx Ingress recipe](https://github.com/kbrew-dev/kbrew-registry/blob/19d9cd3ae269265c1e3147918a3a2287fc006bda/recipes/ingress-nginx.yaml) we configure an annotation if the application is being installed in AWS EKS or Digital Ocean.\n\n```\napp:\n  args:\n    # annotation for EKS\n    controller.service.annotations.\"service\\.beta\\.kubernetes\\.io/aws-load-balancer-type\": '{{ $providerID := (index (lookup \"v1\" \"Node\" \"\" \"\").items 0).spec.providerID }}{{ if hasPrefix \"aws\" $providerID }}nlb{{end}}'\n    # annotations for Digital Ocean\n    controller.service.annotations.\"service\\.beta\\.kubernetes\\.io/do-loadbalancer-enable-proxy-protocol\": '{{ $providerID := (index (lookup \"v1\" \"Node\" \"\" \"\").items 0).spec.providerID }}{{ if hasPrefix \"digitalocean\" $providerID }}true{{end}}'\n```\n\n* `namespace`: Kubernetes namespace where the app should be installed. If not specified, `default` is used for installation.\n\n#### Pre \u0026 Post Install\n\nPre and post-install sections allow the recipe author to do steps needed before or after the installation of the core application.  This could be for example:\n\n- Checking for compatibility of cluster or the environment-specific things such as `StorageClass`.\n- Install another dependency application by using the recipe of that application.\n- After installation wait for setup to be ready and fully functional.\n- Create CRs of a specific application so that it is fully functional and ready to use.\n\nLet's look at some examples. In the RookCeph recipe, we install the operator as a dependency application:\n\n```\npre_install:\n  - apps:\n    - rook-ceph-operator\n```    \n\nIn the Minio recipe, we check the version of Kubernetes so that only compatible versions of Kubernetes are used for rest of the install\n\n```\npre_install:\n  - steps:\n    - |\n      # Prerequisites\n      # https://github.com/minio/operator#prerequisites\n      minK8sVersion=\"v1.19.0\"\n      expected=$(echo $minK8sVersion |  sed 's/v//g' | sed 's/\\.//g')\n      k8sVersion=$(kubectl version --short=true --output json | jq -r \".serverVersion.gitVersion\" | sed 's/-.*//g' | sed 's/v//g' | sed 's/\\.//g')\n      if [ $expected -gt $k8sVersion ]\n      then\n        echo \"The cluster does not meet requirements.\"\n        echo \"Kubernetes version v1.19.0 or later required.\"\n        exit 1\n      fi\n```\n\nOr for example, in case of Minio, the `StorageClass` should have the value of `volumeBindingMode` as `WaitForFirstConsumer` - and is one of the prerequisites for the installation:\n\n```\npre_install:\n  - steps:\n    - |\n      # Prerequisites - The StorageClass must have volumeBindingMode: WaitForFirstConsumer\n      # https://github.com/minio/operator#prerequisites\n      scList=$(kubectl get storageclass -o jsonpath='{.items[?(@.volumeBindingMode==\"WaitForFirstConsumer\")].metadata.name}')\n      if [ -z \"$scList\" ]\n      then\n        echo \"The cluster does not meet requirements.\"\n        echo \"Atleast 1 StorageClass should have WaitForFirstConsumer volumeBindingMode.\"\n        exit 1\n      fi\n```      \n\n#### Pre and Post Cleanup\n\nThe `pre_cleanup` and `post_cleanup` are very similar to the `pre_install` and `post_install` steps but are used in the uninstall lifecycle.\n\n## FAQ\n\n##### How is kbrew different than Helm or Kubernetes Operator?\n\nkbrew uses Helm charts and operators both under the hood. kbrew acts as a `glue code` that makes combination of installing a Helm chart, creating a manifest CR etc. into a single command that also tries to make some decisions such as StorageClass configuration etc. It is great for developers who wants to just get something running fast and fully working!\n\n##### Should I use kbrew for installing applications in a production environment?\n\nAt this point, kbrew is not meant to install applications in production. It makes installing applications easy for developers and anyone tinkering and installing frequently\n\n##### How can I contribute recipes for a project/tool?\n\nThe recipes are maintained in [kbrew registry](https://github.com/kbrew-dev/kbrew-registry), and if a recipe does not exist then please raise an issue and you can contribute to the registry.\n\n##### How is analytics used?\n\nThe analytics is anonymized and used in aggregate to determine the failure/success rate of recipes and to improve user experience.\n\n##### What data is collected for analytics?\n\nPlease check [analytics](docs/analytics.md) for details.\n\n##### Who is developing kbrew?\n\nThe team at [InfraCloud](https://www.infracloud.io/) is supporting kbrew's development with love! But we love contributions from the community.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkbrew-dev%2Fkbrew","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkbrew-dev%2Fkbrew","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkbrew-dev%2Fkbrew/lists"}