基于gin框架实现的脚手架工具ginhelper用法介绍

ginhelper是用于gin框架快速开发的辅助工具，支持monorepo方式，使用方法如下：

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名申请、网页空间、营销软件、网站建设、象山网站维护、网站推广。

等待安装完成后，查看使用帮助提示：

创建好的工程目录为：

这里api定义使用纯go代码实现，通过注解来定义路由、请求方法、是否需要认证，具体注解说明如下：

api定义文件纯Go语法，使用成本低！例如在internal/demo1/api/目录下定义api文件user.go，内容如下：

根据上面定义的api文件自动生成代码，上面的api定义在demo1的app里面，所以更新方法为：

这个时候api定义里的/user相关的路由请求代码自动生成好了，只需要在internal/demo1/service/user.go里实现自己的业务逻辑即可

这里仅仅实现了基于gin框架的自动生成繁琐代码的方法，对于简单的服务来说能一定程度上提效，但对于成熟的脚手架工具来说远远还不够，代码开源地址为：

Kubernetes Operator 快速入门教程（Operator 101）

在 Kubernetes 的监控方案中我们经常会使用到一个Promethues Operator的项目，该项目可以让我们更加方便的去使用 Prometheus，而不需要直接去使用最原始的一些资源对象，比如 Pod、Deployment，随着 Prometheus Operator 项目的成功，CoreOS 公司开源了一个比较厉害的工具：Operator Framework，该工具可以让开发人员更加容易的开发 Operator 应用。

在本篇文章中我们会为大家介绍一个简单示例来演示如何使用 Operator Framework 框架来开发一个 Operator 应用。

Kubernetes Operator

Operator 是由 CoreOS 开发的，用来扩展 Kubernetes API，特定的应用程序控制器，它用来创建、配置和管理复杂的有状态应用，如数据库、缓存和监控系统。Operator 基于 Kubernetes 的资源和控制器概念之上构建，但同时又包含了应用程序特定的领域知识。创建Operator 的关键是CRD（自定义资源）的设计。

Kubernetes 1.7 版本以来就引入了自定义控制器的概念，该功能可以让开发人员扩展添加新功能，更新现有的功能，并且可以自动执行一些管理任务，这些自定义的控制器就像 Kubernetes 原生的组件一样，Operator 直接使用 Kubernetes API进行开发，也就是说他们可以根据这些控制器内部编写的自定义规则来监控集群、更改 Pods/Services、对正在运行的应用进行扩缩容。

Operator Framework

Operator Framework 同样也是 CoreOS 开源的一个用于快速开发 Operator 的工具包，该框架包含两个主要的部分：

Workflow

Operator SDK 提供以下工作流来开发一个新的 Operator：

Demo

我们平时在部署一个简单的 Webserver 到 Kubernetes 集群中的时候，都需要先编写一个 Deployment 的控制器，然后创建一个 Service 对象，通过 Pod 的 label 标签进行关联，最后通过 Ingress 或者 type=NodePort 类型的 Service 来暴露服务，每次都需要这样操作，是不是略显麻烦，我们就可以创建一个自定义的资源对象，通过我们的 CRD 来描述我们要部署的应用信息，比如镜像、服务端口、环境变量等等，然后创建我们的自定义类型的资源对象的时候，通过控制器去创建对应的 Deployment 和 Service，是不是就方便很多了，相当于我们用一个资源清单去描述了 Deployment 和 Service 要做的两件事情。

这里我们将创建一个名为 AppService 的 CRD 资源对象，然后定义如下的资源清单进行应用部署：

通过这里的自定义的 AppService 资源对象去创建副本数为2的 Pod，然后通过 nodePort=30002 的端口去暴露服务，接下来我们就来一步一步的实现我们这里的这个简单的 Operator 应用。

开发环境

环境需求

要开发 Operator 自然 Kubernetes 集群是少不了的，还需要 Golang 的环境，这里的安装就不多说了，然后还需要一个 Go 语言的依赖管理工具包：dep，由于 Operator SDK 是使用的 dep 该工具包，所以需要我们提前安装好，可以查看资料：，另外一个需要说明的是，由于 dep 去安装的时候需要去谷歌的网站拉取很多代码，所以正常情况下的话是会失败的，需要做什么工作大家应该清楚吧？要科学。

安装 operator-sdk

operator sdk 安装方法非常多，我们可以直接在 github 上面下载需要使用的版本，然后放置到 PATH 环境下面即可，当然也可以将源码 clone 到本地手动编译安装即可，如果你是 Mac，当然还可以使用常用的 brew 工具进行安装：

我们这里使用的 sdk 版本是v0.7.0，其他安装方法可以参考文档：

演示

创建新项目

环境准备好了，接下来就可以使用 operator-sdk 直接创建一个新的项目了，命令格式为： operator-sdk new

按照上面我们预先定义的 CRD 资源清单，我们这里可以这样创建：

到这里一个全新的 Operator 项目就新建完成了。

项目结构

使用operator-sdk new命令创建新的 Operator 项目后，项目目录就包含了很多生成的文件夹和文件。

我们主要需要编写的是 pkg 目录下面的 api 定义以及对应的 controller 实现。

添加 API

接下来为我们的自定义资源添加一个新的 API，按照上面我们预定义的资源清单文件，在 Operator 相关根目录下面执行如下命令：

添加完成后，我们可以看到类似于下面的这样项目结构：

添加控制器

上面我们添加自定义的 API，接下来可以添加对应的自定义 API 的具体实现 Controller，同样在项目根目录下面执行如下命令：

这样整个 Operator 项目的脚手架就已经搭建完成了，接下来就是具体的实现了。

自定义 API

打开源文件pkg/apis/app/v1/appservice_types.go，需要我们根据我们的需求去自定义结构体 AppServiceSpec，我们最上面预定义的资源清单中就有 size、image、ports 这些属性，所有我们需要用到的属性都需要在这个结构体中进行定义：

代码中会涉及到一些包名的导入，由于包名较多，所以我们会使用一些别名进行区分，主要的包含下面几个：

这里的 resources、envs、ports 的定义都是直接引用的"k8s.io/api/core/v1"中定义的结构体，而且需要注意的是我们这里使用的是ServicePort，而不是像传统的 Pod 中定义的 ContanerPort，这是因为我们的资源清单中不仅要描述容器的 Port，还要描述 Service 的 Port。

然后一个比较重要的结构体AppServiceStatus用来描述资源的状态，当然我们可以根据需要去自定义状态的描述，我这里就偷懒直接使用 Deployment 的状态了：

定义完成后，在项目根目录下面执行如下命令：

改命令是用来根据我们自定义的 API 描述来自动生成一些代码，目录pkg/apis/app/v1/下面以zz_generated开头的文件就是自动生成的代码，里面的内容并不需要我们去手动编写。

实现业务逻辑

NewDeploy 方法实现如下：

newService 对应的方法实现如下：

这样我们就实现了 AppService 这种资源对象的业务逻辑。

调试

如果我们本地有一个可以访问的 Kubernetes 集群，我们也可以直接进行调试，在本地用户~/.kube/config文件中配置集群访问信息，下面的信息表明可以访问 Kubernetes 集群：

首先，在集群中安装 CRD 对象：

上面的命令会在本地运行 Operator 应用，通过~/.kube/config去关联集群信息，现在我们去添加一个 AppService 类型的资源然后观察本地 Operator 的变化情况，资源清单文件就是我们上面预定义的（deploy/crds/app_v1_appservice_cr.yaml）

直接创建这个资源对象：

我们可以看到我们的应用创建成功了，这个时候查看 Operator 的调试窗口会有如下的信息出现：

然后我们可以去查看集群中是否有符合我们预期的资源出现：

看到了吧，我们定义了两个副本（size=2），这里就出现了两个 Pod，还有一个 NodePort=30002 的 Service 对象，我们可以通过该端口去访问下应用：

如果应用在安装过程中出现了任何问题，我们都可以通过本地的 Operator 调试窗口找到有用的信息，然后调试修改即可。

清理：

部署

自定义的资源对象现在测试通过了，但是如果我们将本地的operator-sdk up local命令终止掉，我们可以猜想到就没办法处理 AppService 资源对象的一些操作了，所以我们需要将我们的业务逻辑实现部署到集群中去。

执行下面的命令构建 Operator 应用打包成 Docker 镜像：

镜像构建成功后，推送到 docker hub：

镜像推送成功后，使用上面的镜像地址更新 Operator 的资源清单：

现在 Operator 的资源清单文件准备好了，然后创建对应的 RBAC 的对象：

到这里我们的 CRD 和 Operator 实现都已经安装成功了。

现在我们再来部署我们的 AppService 资源清单文件，现在的业务逻辑就会在上面的opdemo-64db96d575-9vtq6的 Pod 中去处理了。

然后同样的可以通过 30002 这个 NodePort 端口去访问应用，到这里应用就部署成功了。

清理

有资源清单文件，直接删除即可：

开发

Operator SDK 为我们创建了一个快速启动的代码和相关配置，如果我们要开始处理相关的逻辑，我们可以在项目中搜索TODO(user)这个注释来实现我们自己的逻辑，比如在我的 VSCode 环境中，看上去是这样的：

本篇文章示例代码地址：

参考资料

Go语言命令行利器cobra使用教程

cobra是一个提供简单接口来创建强大的现代CLI界面的库类似git git tools，cobra也是一个应用程序，它会生成你的应用程序的脚手架来快速开发基于cobra的应用程序

cobra提供：

cobra建立在命令、参数、标志的结构之上

commands代表动作，args是事物，flags是动作的修饰符

最好的应用程序在使用时读起来就像句子，因此，用户直观地知道如何与它们交互

模式如下：APPNAME VERB NOUN --ADJECTIVE. or APPNAME COMMAND ARG --FLAG（APPNAME 动词 名词 形容词 或者 APPNAME 命令 参数 标志）

一些真实世界的好例子可以更好地说明这一点

kubectl 命令更能体现APPNAME 动词 名词 形容词

如下的例子，server 是command，port是flag

这个命令中，我们告诉git 克隆url

命令是应用程序的中心点，应用程序支持的每一个交互都包含在一个命令中，命令可以有子命令，也可以运行操作

在上面的例子中，server是命令

更多关于cobra.Command

flag是一种修改命令行为的方式，cobra支持完全兼容POSIX标志，也支持go flag package，cobra可以定义到子命令上的标志，也可以仅对该命令可用的标志

在上面的命令中，port是标志

标志的功能由 pflag library 提供，pflag library是flag标准库的一个分支，在添加POSIX兼容性的同时维护相同的接口。

使用cobra很简单，首先，使用go get按照最新版本的库，这个命令会安装cobra可执行程序以及库和依赖项

下一步，引入cobra到应用程序中

虽然欢迎您提供自己的组织，但通常基于Cobra的应用程序将遵循以下组织结构：

在Cobra应用程序中，main.go文件通常非常简单。它有一个目的：初始化Cobra。

使用cobra生成器

cobra提供了程序用来创建你的应用程序然后添加你想添加的命令，这是将cobra引入应用程序最简单的方式

这儿 你可以发现关于cobra的更多信息

要手动实现cobra，需要创建一个main.go 和rootCmd文件，可以根据需要提供其他命令

Cobra不需要任何特殊的构造器。只需创建命令。

理想情况下，您可以将其放在app/cmd/root.go中：

在init（）函数中定义标志和处理配置

例子如下，cmd/root.go:

创建main.go

使用root命令，您需要让主函数执行它。为清楚起见，Execute应该在根目录下运行，尽管它可以在任何命令上调用。

在Cobra应用程序中，main.go文件通常非常简单。它有一个目的：初始化Cobra。

可以定义其他命令，通常每个命令在cmd/目录中都有自己的文件。

如果要创建版本命令，可以创建cmd/version.go并用以下内容填充它：

如果希望将错误返回给命令的调用者，可以使用RunE。

然后可以在execute函数调用中捕获错误。

标志提供修饰符来控制操作命令的操作方式。

由于标志是在不同的位置定义和使用的，因此我们需要在外部定义一个具有正确作用域的变量来分配要使用的标志。

有两种不同的方法来分配标志。

标志可以是“持久”的，这意味着该标志将可用于分配给它的命令以及该命令下的每个命令。对于全局标志，在根上指定一个标志作为持久标志。

也可以在本地分配一个标志，该标志只应用于该特定命令。

默认情况下，Cobra只解析目标命令上的本地标志，而忽略父命令上的任何本地标志。通过启用Command.TraverseChildren，Cobra将在执行目标命令之前解析每个命令上的本地标志。

使用viper绑定标志

在本例中，持久标志author与viper绑定。注意：当用户未提供--author标志时，变量author将不会设置为config中的值。

更多关于 viper的文档

Flags默认是可选的，如果希望命令在未设置标志时报告错误，请根据需要进行标记：

持久性Flags

可以使用命令的Args字段指定位置参数的验证。

内置了以下验证器：

在下面的示例中，我们定义了三个命令。两个是顶级命令，一个（cmdTimes）是顶级命令之一的子命令。在这种情况下，根是不可执行的，这意味着需要一个子命令。这是通过不为“rootCmd”提供“Run”来实现的。

我们只为一个命令定义了一个标志。

有关标志的更多文档，请访问

对于一个更完整的例子更大的应用程序，请检查 Hugo 。

当您有子命令时，Cobra会自动将help命令添加到应用程序中。当用户运行“应用程序帮助”时，将调用此函数。此外，help还支持所有其他命令作为输入。例如，您有一个名为“create”的命令，没有任何附加配置；调用“app help create”时，Cobra将起作用。每个命令都会自动添加“-help”标志。

以下输出由Cobra自动生成。除了命令和标志定义之外，不需要任何东西。

帮助就像其他命令一样。它周围没有特殊的逻辑或行为。事实上，你可以提供你想提供的。

您可以为默认命令提供自己的帮助命令或模板，以用于以下功能：

当用户提供无效的标志或无效的命令时，Cobra通过向用户显示“用法”来响应。

你可以从上面的帮助中认识到这一点。这是因为默认帮助将用法作为其输出的一部分嵌入。

您可以提供自己的使用函数或模板供Cobra使用。与帮助一样，函数和模板也可以通过公共方法重写：

如果在root命令上设置了version字段，Cobra会添加一个顶级的'--version'标志。运行带有“-version”标志的应用程序将使用版本模板将版本打印到标准输出。可以使用cmd.SetVersionTemplate（s string）函数自定义模板。

可以在命令的主运行函数之前或之后运行函数。PersistentPreRun和PreRun函数将在运行之前执行。PersistentPostRun和PostRun将在运行后执行。如果子函数不声明自己的函数，则它们将继承Persistent*Run函数。这些函数按以下顺序运行：

输出：

当发生“未知命令”错误时，Cobra将打印自动建议。这使得Cobra在发生拼写错误时的行为类似于git命令。例如：

基于注册的每个子命令和Levenshtein距离的实现，建议是自动的。匹配最小距离2（忽略大小写）的每个已注册命令都将显示为建议。

如果需要在命令中禁用建议或调整字符串距离，请使用：

or

您还可以使用SuggestFor属性显式设置将为其建议给定命令的名称。这允许对在字符串距离方面不接近的字符串提供建议，但在您的一组命令中是有意义的，并且对于某些您不需要别名的字符串。例子：

Cobra可以基于子命令、标志等生成文档。请在 docs generation文档 中阅读更多关于它的信息。

Cobra可以为以下shell生成shell完成文件：bash、zsh、fish、PowerShell。如果您在命令中添加更多信息，这些补全功能将非常强大和灵活。在 Shell Completions 中阅读更多关于它的信息。

Cobra is released under the Apache 2.0 license. See LICENSE.txt

文章题目：go语言脚手架 golang 脚手架
本文网址：http://azwzsj.com/article/hgpjdh.html