开发者指南

浏览 0      扫码          2019-10-27 17:16:52     码农文档     

公告:如果您也想加入翻译队伍,或者您有相关中文文档想要贡献给大家,请联系coderdocument@163.com ,谢谢!

本指南解释了如何建立你的Helm和Tiller的开发环境。

前提条件

  • 最新版本的Go
  • 最新版本的Glide
  • 一个Kubernetes集群、kubectl(可选)
  • gRPC工具链
  • Git

构建Helm和Tiller

我们使用Make来构建我们的程序。最简单的方法是:


   
       

注意:如果不在路径 $GOPATH/src/k8s.io/helm下运行,则此操作将失败。k8s.io目录不应该是一个符号链接,否则build将找不到相关的包。

这样可以同时构建Helm和Tiller。如果缺少某些工具,make bootstrap将尝试安装它们。

要运行所有测试(不包含 vendor/的测试),请运行make test。要在容器环境中运行所有测试,请运行make docker-test

要在本地运行Helm和Tiller,你可以分别运行 bin/helmbin/tiller

  • Helm和Tiller可以运行在macOS和大多数Linux发行版上,包括Alpine。
  • Tiller必须有一个可访问的Kubernetes集群。它通过检查kubectl使用的kubeconfig文件来获取集群集群。

手册页面

手册页面和Markdown文档已经在docs/中预先构建好了。你可以使用make docs重新生成文档。

要向你的man客户端暴露Helm手册页面,你可以将文件放在$MANPATH中:


   
       

gRPC和ProtoBuf

Helm和Tiller使用gRPC通信。要开始使用gRPC,你需要:

  • 安装用于编译protobuf文件的protoc发布版本在这里找到;
  • 运行Helm的make bootstrap命令生成 protoc-gen-go插件,并将其放入bin/

注意:你需要使用protobuf 3.2.0(protoc --version)。 protoc-gen-go的版本与Kubernetes使用的gRPC版本相关联。所以插件是在本地维护的。

虽然gRPC和ProtoBuf规范对缩进无强制要求,但我们要求缩进样式与Go格式规范相匹配。也就是说,ProtoBuf应该使用基于Tab的缩进,而且rpc声明应该遵循Go函数声明的风格。

Helm API(HAPI)

我们使用gRPC作为API层。生成的Go代码请参见 pkg/proto/hapi,ProtoBuf定义参见 _proto

要根据ProtoBuf定义文件重新生成Go文件,请运行make protoc

Docker镜像

要构建Docker镜像,请使用make docker-build

预先构建的镜像已经在官方的Kubernetes Helm GCR仓库中,可直接使用。

运行一个本地集群

对于开发,我们强烈推荐使用Kubernetes Minikube面向开发人员的发行版(使用Minikube安装Kubernetes,请参看这里)。安装之后,可以使用helm init将其安装到集群中。注意,用于开发的Tiller版本可能在谷歌云容器仓库中不可用。如果你在拉取镜像时出现错误,你可以覆盖Tiller的版本。示例:


   
       

或者使用最新版本:


   
       

对于开发Tiller,有时更有效的做法是在本地运行Tiller,而不是将其打包成一个镜像并在集群中运行。你可以通过告诉Helm客户端使用本地实例来做到这一点。


   
       

要配置Helm客户端,需要使用--host选项或导出HELM_HOST环境变量:


   
       

注意:当你直接运行Tiller时,你不需要执行helm init

Tiller应运行在版本 >= v1.3 的Kubernetes集群上。

贡献指南

我们欢迎你作出贡献。该项目建立了一些指导方针,以确保:1. 代码质量保持高;2. 项目保持一致;3. 贡献遵循开源法律要求。我们的目的不是为了增加贡献者的负担,而是为了构建优雅而高质量的开放源代码,以便我们的用户能够从中受益。

确保你已经阅读并理解了主要的贡献指南:

https://github.com/helm/helm/blob/master/CONTRIBUTING.md

代码结构

Helm项目的代码组织如下:

  • 程序位于cmd/中。cmd/中的代码不是为了重用库而设计的。
  • 共享库存储在pkg/中。
  • 原始ProtoBuf文件存储在_proto/hapi中,其中hapi代表Helm应用程序编程接口。
  • 根据 proto 定义生成的Go文件存储在pkg/proto中。
  • scripts/目录包含许多实用程序脚本。其中大多数是由CI/CD管道使用的。
  • rootfs/目录用于存储Docker-specific文件。
  • docs/目录用于存储文档和示例。

Go依赖项由Glide管理并存储在vendor/目录中。

Git约定

我们使用Git作为版本控制系统。master分支是当前开发候选分支的首选分支,发布版本时也在master分支上打标签。

我们通过GitHub Pull Requests (PR)接受对代码的修改。其工作流程如下:

  1. 进入你的$GOPATH/src/k8s.io 目录并使用git clone克隆 github.com/helm/helm仓库。
  2. Fork仓库至你的GitHub账号。
  3. 将你的仓库作为 $GOPATH/src/k8s.io/helm的远程仓库。
  4. 创建一个新的工作分支(git checkout -b feat/my-feature)并在此分支进行开发。
  5. 当你准备好让我们审核时,签署你的提交,将你的分支推送到GitHub,然后向我们一起打开一个新的Pull Request。

对于Git提交消息,请遵循语义提交消息


   
       

常用提交类型:

  • fix:修改bug或错误
  • feat:添加新特性
  • docs:更改文档
  • test:改进测试
  • ref:重构已有代码

常用范围(Scope):

  • helm:Helm CLI
  • tiller:Tiller服务端
  • proto:ProtoBuf定义
  • pkg/link:lint包。所有包都遵循类似的约定。
  • *:超过两种范围

阅读更多:

  • Deis指南是本节的灵感来源。
  • Karma Runner定义了语义提交消息的概念。

Go约定

我们非常严格地遵循Go编码风格标准。通常,运行go fmt将使你的代码更漂亮。

我们通常也会遵循go lintgometalinter推荐的约定。运行make test-style来测试样式的一致性。如果你不想将gometalinter的所有linter安装到全局Go环境中,那么可以运行make docker-test-style,它将运行相同的测试,但会被隔离在docker容器中。

阅读更多:

Protobuf约定

因为这个项目主要是Go代码,所以我们尽可能紧密地格式化Protobuf文件。Protobuf目前还没有真正的格式化规则或指南,但随着它们的出现,我们可能会选择遵循这些规则。

标准:

  • 缩进使用制表符,而不是空格。
  • 间距规则遵循Go约定(行尾带花括号,操作符周围有空格)。

约定:

  • 文件应该使用 option go_package = "...";指定包。
  • 注释应该转换成好的Go代码注释(因为protoc将注释复制到目标源代码文件中)。
  • RPC函数定义位于与其请求/响应消息相同的文件中。
  • 废弃的RPC、消息和字段在注释中进行标记(// UpdateFoo DEPRECATED updates a foo.)。
返回顶部