kapitan 正在参加 2021 年度 OSC 中国开源项目评选,请投票支持!
kapitan 在 2021 年度 OSC 中国开源项目评选 中已获得 {{ projectVoteCount }} 票,请投票支持!
2021 年度 OSC 中国开源项目评选 正在火热进行中,快来投票支持你喜欢的开源项目!
2021 年度 OSC 中国开源项目评选 >>> 中场回顾
kapitan 获得 2021 年度 OSC 中国开源项目评选「最佳人气项目」 !
授权协议 Readme
开发语言 Python
操作系统 跨平台
软件类型 开源软件
所属分类 云计算云原生
开源组织
地区 不详
投 递 者 首席测试
适用人群 未知
收录时间 2021-11-10

软件简介

Kapitan: Generic templated configuration management for Kubernetes, Terraform and other things

Unit Tests Docker Releases Docker Image Size

Kapitan is the tool to help you manage the complexity of your configuration using an inventory and a choice of templates like generators, jsonnet, kadet, jinja2 and helm.

Use Kapitan to build an inventory which you can then use to drive templates for your Kubernetes manifests, your documentation, your Terraform configuration or even simplify your scripts.

Community

How is it different from helm and kustomize? Please look at our FAQ!

Key Concepts

Inventory

The inventory is the heart of Kapitan. Using simple reusable yaml files (classes), you can represent as a single source of truth everything that matters in your setup, for instance:

  • kubernetes components definitions
  • terraform resources
  • business concepts
  • documentation and tooling
  • ...anything else you want!

Once you have it defined, you can reuse this data to feed into any of the many templating backends available to Kapitan.

Generators

The simplest way to get started with Kapitan. Generators are universal templates that are a simplified way to generate configuration files (for instance, Kubernetes manifests) without using any templating at all.

Check out our reference repository to get started: Kapitan Reference

Read our blog post Keep your ship together with Kapitan

Jsonnet or Kadet templates backends

For more complex scenarios, you have a choice of directly using our 2 main templating engines.

You can use either Jsonnet (tapping into an ever growing number of libraries and examples) or our Python based Kadet to create json/yaml based configurations (e.g. Kubernetes, Terraform);

Jinja2

Good old Jinja to create text based templates for scripts and documentation; Don't underestimate the power of this very simple approach to create templated scripts and documentation!

Kapitan Declarative Secrets

Use Kapitan to securely generate and manage secrets with GPG, AWS KMS, gCloud KMS and Vault.

Use Tesoro, our Kubernetes Admission Controller, to complete your integration with Kubernetes for secure secret decryption on-the-fly.

Quickstart

Docker (recommended)

docker run -t --rm -v $(pwd):/src:delegated kapicorp/kapitan -h

On Linux you can add -u $(id -u) to docker run to preserve file permissions.

For CI/CD usage, check out CI.md

Pip

Kapitan needs Python 3.7.

Install Python 3.7:

  • Linux: sudo apt-get update && sudo apt-get install -y python3.7-dev python3-pip python3-yaml
  • Mac: brew install python3 libyaml

Install Kapitan:

User ($HOME/.local/lib/python3.6/bin on Linux or $HOME/Library/Python/3.7/bin on macOS):

pip3 install --user --upgrade kapitan

System-wide (not recommended):

sudo pip3 install --upgrade kapitan

Example

The example below compiles 2 targets inside the examples/kubernetes folder. Each target represents a different namespace in a minikube cluster.

These targets generate the following resources:

  • Kubernetes Namespace for the targets
  • Kubernetes StatefulSet for ElasticSearch Master node
  • Kubernetes StatefulSet for ElasticSearch Client node
  • Kubernetes StatefulSet for ElasticSearch Data node
  • Kubernetes Service to expose ElasticSearch discovery port
  • Kubernetes Service to expose ElasticSearch service port
  • Kubernetes StatefulSet for MySQL
  • Kubernetes Service to expose MySQL service port
  • Kubernetes Secret for MySQL credentials
  • Scripts to configure kubectl context to control the targets and helpers to apply/delete objects.
  • Documentation

demo

$ cd examples/kubernetes

$ kapitan compile
Compiled minikube-mysql
Compiled minikube-es

Documentation

Getting Started

Kapitan features

Miscellaneous

Examples

Credits

FAQ

Why do we prefer Kapitan to Helm?

Before developing Kapitan, we turned to Helm in an attempt to improve our old Jinja based templating system.

We quickly discovered that Helm did not fit well with our workflow, for the following reasons (which were true at the time of the evaluation):

  • Helm uses Go templates to define Kubernetes (yaml) manifests. We were already unsatisfied by using Jinja and we did not see a huge improvement from our previous system, the main reason being: YAML files are not suitable to be managed by text templating frameworks.
  • Helm does not have a solution for sharing values across charts, if not through subcharts. We wanted to be able to have one single place to define all values for all our templates. Sharing data between charts felt awkward and complicated.
  • Helm is component/chart based. We wanted to have something that would treat all our deployments as a whole.
  • We did not fancy the dependency on the tiller.

In short, we feel Helm is trying to be apt-get for Kubernetes charts, while we are trying to take you further than that.

Why do I need Kapitan?

With Kapitan, we worked to de-compose several problems that most of the other solutions are treating as one.

  1. Kubernetes manifests: We like the jsonnet approach of using json as the working language. Jsonnet allows us to use inheritance and composition, and hide complexity at higher levels.

  2. Configuration files: Most solutions will assume this problem is solved somewhere else. We feel Jinja (or your template engine of choice) have the upper hand here.

  3. Hierarchical inventory: This is the feature that sets us apart from other solutions. We use the inventory (based on reclass) to define variables and properties that can be reused across different projects/deployments. This allows us to limit repetition, but also to define a nicer interface with developers (or CI tools) which will only need to understand YAML to operate changes.

  4. Secrets: We manage most of our secrets with kapitan using the GPG, Google Cloud KMS and AWS KMS integrations. Keys can be setup per class, per target or shared so you can easily and flexibly manage access per environment. They can also be dynamically generated on compilation, if you don't feel like generating random passwords or RSA private keys, and they can be referenced in the inventory like any other variables. We have plans to support other providers such as Vault, in addition to GPG, Google Cloud KMS and AWS KMS.

  5. Canned scripts: We treat scripts as text templates, so that we can craft pre-canned scripts for the specific target we are working on. This can be used for instance to define scripts that setup clusters, contexts or allow running kubectl with all the correct settings. Most other solutions require you to define contexts and call kubectl with the correct settings. We take care of that for you. Less ambiguity, fewer mistakes.

  6. Documentation: We also use templates to create documentation for the targets we deploy. Documentation lived alongside everything else and it is treated as a first class citizen. We feel most other solutions are pushing the limits of their capacity in order to provide for the above problems. Helm treats everything as a text template, while jsonnet tries to do everything as json. We believe that these approaches can be blended in a powerful new way, glued together by the inventory.

Related projects

展开阅读全文

代码

评论

点击引领话题📣 发布并加入讨论🔥
暂无内容
发表了博客
{{o.pubDate | formatDate}}

{{formatAllHtml(o.title)}}

{{parseInt(o.replyCount) | bigNumberTransform}}
{{parseInt(o.viewCount) | bigNumberTransform}}
没有更多内容
暂无内容
发表了问答
{{o.pubDate | formatDate}}

{{formatAllHtml(o.title)}}

{{parseInt(o.replyCount) | bigNumberTransform}}
{{parseInt(o.viewCount) | bigNumberTransform}}
没有更多内容
暂无内容
gitpython 存在ReDoS漏洞
ReDoS
GitPython 是一个用于与 Git 存储库交互的 Python 库。当用户控制传递给模式匹配函数的输入时,此软件包的受影响版本容易受到正则表达式拒绝服务 (ReDoS) 的攻击。
MPS-2022-14928
2022-08-08 18:40
没有更多内容
加载失败,请刷新页面
点击加载更多
加载中
下一页
0 评论
0 收藏
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部