35 | 效率神器：如何设计和实现一个命令行客户端工具？

孔令飞



该思维导图由 AI 生成，仅供参考

你好，我是孔令飞。今天我们来聊聊，如何实现一个命令行客户端工具。
如果你用过 Kubernetes、Istio、etcd，那你一定用过这些开源项目所提供的命令行工具：kubectl、istioctl、etcdctl。一个 xxx 项目，伴随着一个 xxxctl 命令行工具，这似乎已经成为一种趋势，在一些大型系统中更是常见。提供 xxxctl 命令行工具有这两个好处：
实现自动化：可以通过在脚本中调用 xxxctl 工具，实现自动化。
提高效率：通过将应用的功能封装成命令和参数，方便运维、开发人员在 Linux 服务器上调用。
其中，kubectl 命令设计的功能最为复杂，也是非常优秀的命令行工具，IAM 项目的 iamctl 客户端工具就是仿照 kubectl 来实现的。这一讲，我就通过剖析 iamctl 命令行工具的实现，来介绍下如何实现一个优秀的客户端工具。
常见客户端介绍在介绍 iamctl 命令行工具的实现之前，我们先来看下常见的客户端。
客户端又叫用户端，与后端服务相对应，安装在客户机上，用户可以使用这些客户端访问后端服务。不同的客户端面向的人群不同，所能提供的访问能力也有差异。常见的客户端有下面这几种：
前端，包括浏览器、手机应用；
SDK；
命令行工具；
其他终端。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文深入介绍了如何设计和实现一个命令行客户端工具，以及大型系统客户端的特点。首先，文章介绍了常见的客户端类型，包括前端、SDK、命令行工具和其他终端，并分别介绍了它们的特点和使用场景。接着，详细介绍了大型系统客户端的特点，包括支持命令和子命令、全局option、特殊命令等，并举例说明了iamctl的功能和代码结构。最后，重点介绍了iamctl的核心实现，包括功能分类、代码结构、命令行选项等方面的内容。文章还介绍了命令构建、命令自动补全和更友好的输出等方面的内容。通过本文，读者可以了解到如何设计和实现一个优秀的命令行客户端工具，以及大型系统客户端的特点和实现细节。本文还介绍了客户端配置文件的创建、SDK调用和REST API调用的实现方式。通过对iamctl命令行工具的剖析，读者可以了解到如何实现一个优秀的客户端工具，以及如何通过SDK调用和REST API调用来访问服务端API接口。最后，文章提出了课后练习，鼓励读者在iamctl中添加新的子命令，并分享其他好的命令行工具构建方式。总的来说，本文通过深入剖析iamctl命令行工具的实现，向读者介绍了如何设计和实现一个优秀的客户端工具，以及如何通过SDK调用和REST API调用来访问服务端API接口。同时，通过课后练习，鼓励读者在实践中加深对命令行工具构建方式的理解。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Go 语言项目开发实战》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(8)

最新
精选

宙斯
有cmd为什么还单独分割出来一个tools呢？tools感觉放到cmd里面也是可以的
作者回复: tools说明是工具，cmd/下的程序都属于iam服务。
2021-11-11

1
我来也
有新的发现： ko 自动生成的代码中，嵌套了中括号，就会导致补全失败。 ko completion zsh 生成的代码是这样： '--platform[Which platform to use when pulling a multi-platform base. Format: all | <os>[/<arch>[/<variant>]][,platform]*]:' \ 这个在使用 Tab 补全时就会报错： _arguments:comparguments:325: invalid option definition: --platform[Which platform to use when pulling a multi-platform base. Format: all | <os>[/<arch>[/<variant>]][,platform]*]: 如果手动将上面生成的代码改成： '--platform[Which platform to use when pulling a multi-platform base. Format: all | <os></<arch></<variant>>><,platform>*]:' \ 再使用 ko apply --<Tab> 时，就不会遇到上面的错误了。现在就只剩下最后一个问题了： ko 补全时，出现的错误不知道哪来的，比较尴尬。 ➜ zsh ✗ autoload exec ➜ zsh ✗ ko ap<Tab> (eval):6: exec: function definition file not found Error: required flag(s) "image" not set ➜ zsh ✗ ko apply --help
作者回复: 牛批！
2021-08-14
2
1
我来也
老师的项目真全，连 ctl 都有了。😁 本地一个 make 命令，就构建出来了对应架构的可执行文件。有个地方比较好奇，咨询一下老师：老师的 zsh 补全脚本是如何生成的，为什么是在代码中定义的常量？ https://github.com/marmotedu/iam/blob/922885b4a502c589785eb08a61522ca03bc8ba55/internal/iamctl/cmd/completion/completion.go#L139-L163 而 ko 的 zsh 补全是完全有代码自动生成的： https://github.com/google/ko/blob/0af2e5e8a9107523c287d7c67af874d3837cc39f/pkg/commands/completion.go#L35 重点来了： ko 的 bash 补全是可以正常工作的，但 zsh 补全在我这有点不正常。（按了Tag虽然能出提示，但有其他错误。不知道哪来的，也不好调试。）老师的 zsh 补全是好使的！
作者回复: zsh脚本是cobra框架自动生成的。如果生成的zsh自动补全脚本有问题，可能说明没有正确使用cobra或者cobra有问题，提议google下
2021-08-14
2
1
随风而过
这套命令行基本通用，还学到大型开源项目的命令行工具的构建，我一般开发都是些shell脚本，没想到cobra、pflag、viper 包来构建的更好使，效率还更高
2021-09-08

3
yandongxiao
总结： iamctl 工具的实现参考了 kubectl 命令的实现对功能和选项进行分组代码结构的组织方式：internal/iamctl/cmd/<命令>/<命令>_<子命令>.go 子命令的构建方式：可手动扩展也可使用iamctl new 自动生成。保证构建命令方式的一致性。 iamctl 支持通过 RESTClient 和 SDK 两种方式调用后端服务，f cmdutil.Factory 作为命令实现的第一个参数，按需实例化客户端。
2021-12-04

1
lunar
一个盛老师，一个这个老师，是真写代码啊！！！可能是对cli开发不熟悉，看代码里用了viper, 直接先看viper 迷瞪了两天,还是先看cobra吧
2021-09-12
2

Sch0ng
命令行客户端工具是大型项目交互和管理的一部分。又学到了一个最佳实践，赞👍
2021-08-17


pedro
cool!
2021-08-14



收起评论