Vim on 小盒子的技术分享

Postman 越来越臃肿了，我换了个开源的，还能让 AI 帮我写测试

Mon, 13 Apr 2026 03:56:46 +0000

Postman 我用了好几年了。

从最早的 Chrome 插件时代开始用的，那时候它还是个轻量小工具，打开就能测接口，干干净净。但最近这两年，怎么说呢，它开始「端着」了。

打开就让我登录。不登录不让用。

好不容易登录了，又弹窗让我升级 Team 版。

集合还给我存到云端去了。我就测个本地接口，你把我的请求数据往你服务器上传干嘛？

我一直忍着，直到有一天，团队里两个人同时改了同一个集合，Postman 云同步直接给合并冲突了，还没法像 Git 那样 diff 看变更。那天我就想，不行了，得换。

然后我遇到了 Bruno。

怎么形容呢，就像你一直在用一个越来越臃肿的 IDE，突然有人递给你一个 Vim，告诉你「够用了，而且是你的」。

Bruno 干了一件特别简单但特别对的事情，它把你的 API 请求存成 .bru 文件，放在你本地文件夹里。

就是普通的文本文件，打开长这样。

1meta { name: 用户登录 type: http seq: 1}post { url: {{baseUrl}}/auth/login body: json auth: none}headers { Content-Type: application/json}body:json { { "username": "{{username}}", "password": "{{password}}", "expiresInMins": 30 }}script:post-response { if (res.status === 200) { bru.setVar("authToken", res.body.accessToken); bru.setVar("userId", res.body.id); }}tests { test("登录应该返回 200", function() { expect(res.status).to.equal(200); }); test("响应中应该包含 accessToken", function() { expect(res.body.accessToken).to.be.a("string"); expect(res.body.accessToken.length).to.be.greaterThan(0); }); test("响应中应该包含用户基本信息", function() { expect(res.body.id).to.be.a("number"); expect(res.body.username).to.equal("emilys"); expect(res.body.email).to.be.a("string"); }); test("响应时间应该小于 3 秒", function() { expect(res.responseTime).to.be.lessThan(3000); });}

你看，GET 请求、Header、Body、断言，全都是纯文本。你用任何编辑器都能打开它，改完保存就行。

这玩意最不同的地方在哪？

它可以用 Git 管理。

以前团队共享 Postman 集合，那叫一个痛苦。谁改了什么不知道，版本对不对不确定，冲突了还没法 resolve。

现在用 Bruno，接口定义就是文件，扔进 Git 仓库，该 PR 就 PR，该 Code Review 就 Code Review。有人改了某个接口的 Header，diff 里看得一清二楚。

用程序员已经会的工具，解决程序员的问题。不用学新的协作方式，不用付费，不用担心数据被传到哪个云上。

Bruno 官网上有一句话我印象特别深，大意是**「我们不会同步你的任何数据到云端，甚至连登录的概念都没有。我们看不到你在 Bruno 里输入了什么，也不会用你的数据训练任何 AI 模型」。**

在这个年代，一个工具敢这么说，我觉得还是挺硬气的。

回到工具本身。说到这里，可能有朋友会想，开源 API 客户端一抓一大把，Insomnia、Hoppscotch、Thunder Client，凭什么是 Bruno？

我自己用下来，让我有「这玩意不一样」的瞬间，是发现它有 CLI。

但我说的不是「能在终端里跑测试」这种废话。Newman 也能跑，Postman 自己也有命令行。我说的是另一件事。

Bruno 的 CLI，让 Claude Code 和 Cursor 这种 AI 编程工具，第一次能真正帮你写和跑接口测试。

这话有点大，我用两件刚发生的真事讲一下。

回到 Bruno 的 CLI 本身。装它就一行，

1npm i -g @usebruno/cli

装完之后命令叫 bru，跑整个集合的测试是这样，

1bru run --env production

输出长这样。

干净、彩色、有 ✓ 和 ✗、有总耗时、有失败原因。最重要的是，这是一段普通的终端命令，输出是普通的文本。

为什么这件事重要？因为这两个特征，正好是 AI 编程 agent 工作的边界。

Claude Code、Cursor、Codex 这些工具，它们能干什么？它们能读你的代码文件，能写新的文件，能在终端里跑命令，能读命令的输出。它们不能干什么？它们不能点击 Postman 的按钮，不能在你 GUI 里输入 token，不能登录任何账号。(或者说不方便，成本高，效率低)

Postman 的核心数据存在云端、操作靠 GUI、协作靠登录，这三件事每一件都把 AI agent 挡在外面。

而 Bruno 的核心数据是 .bru 文本文件、操作靠 CLI、协作靠 Git。每一件都正好是 AI 最擅长的那种事。

抽象的说完了，说点具体的。

我前两天就让 Claude Code 帮我加了一个测试，过程是这样的。

我跟它说，「我刚加了一个搜索商品的接口，帮我在 bruno 集合里加个测试用例」。

它干了三件事，全程没问我任何问题。

第一步，读了我现有的一个 .bru 文件，就是为了搞清楚我用的格式。比如我习惯加哪些 test，断言风格是什么样的。

第二步，照着这个格式写了一个新的 06-搜索商品.bru 文件，放在我集合的根目录里。请求方法、URL、query 参数、4 条断言，全都给我加上了。

第三步，它直接执行 bru run 06-搜索商品.bru --env production，亲眼看着 4 个测试全绿，然后才回我一句「写完了，4/4 通过」。

整个过程我没碰 Bruno 的 GUI，没敲一个字符的代码，没解释什么是 .bru 格式。AI 自己读自己写自己跑自己验证。

你可能会问，这个事换成 Postman 不行吗？

我得先把话说清楚，Postman 不是没有 CLI。Newman 一直都在，Postman Collection 也是 JSON 文件，AI 理论上能读能写。这条路是通的。

但你真去试一下就会发现，那条路上全是石头。

Postman 的 Collection JSON 格式不是给人手写的。我做了个最朴素的对比，同一个 GET 请求加一条「状态码等于 200」的断言，写成 .bru 是 15 行，导出成 Postman Collection JSON 是 44 行。区别在哪？.bru 里 URL 就是一个字符串 https://api.example.com/users，Postman JSON 里 URL 被拆成 protocol、host 数组、path 数组三个字段。.bru 里测试代码就是普通 JS，Postman JSON 里测试代码以字符串数组的形式塞在 event 里，每一行 JS 都得加引号、转义、再 JSON 序列化一次。还有一堆 _postman_id、_exporter_id、schema 这种内部元数据，跟你的业务接口毫无关系，但你不写就报错。

让 AI 写 .bru，它跟写 markdown 一样轻松。让 AI 写 Postman JSON，它更像在翻译一份配置文件，token 烧得多，出错概率高，写完你自己 review 都费劲，git diff 出来三行业务变更夹在二十行格式噪音里。

所以不是 AI 不能写 Postman 的测试，是 Postman 的格式从一开始就没打算让人手写，更没打算让 AI 直接读写。它假设你有一个 GUI 在中间帮你管理这些内部细节。AI 进来之后，那个假设就有点尴尬了。

我说的还不是最炸的场景。

真正让我觉得 Bruno + AI 是 1 + 1 大于 10 的，是调试场景。

我又试了一次，让 Claude Code 帮我加一个购物车接口的测试。它写完跑了一遍，挂了。

错误信息是这样的。

 1✕ 购物车应该有 totalPrice 字段 expected undefined to be a number✕ 购物车应该有 products 数组 expected undefined to be an array
 2
 3```bash
 4
 5它猜错了字段名。这种事很正常，毕竟它没真的去看接口返回。但接下来才有意思。
 6
 7它没有问我、没有让我提供文档、也没有放弃。它自己执行了一条 curl 命令，把购物车接口的真实响应拉了下来。
 8
 9```bash
10curl -s https://dummyjson.com/carts/1

看到响应里字段是 total 和 products，不是 totalPrice 和 items。它马上把测试里的字段名改了，再跑一遍，全绿。

整个调试过程，我做了什么？我什么也没做。我只是看着它一步一步跑完。

这就是 Bruno + CLI + AI 的真正价值。你的 API 测试不再是一个孤立的、需要你手动维护的负担，而是变成了 AI 可以读、可以写、可以跑、可以调试的一种代码。

它和你的源码、你的 Git 历史、你的 CI/CD、你的 AI agent，全都是一体的。

写到这里我猜有人要拍桌子了。

「等等，国内程序员谁还用 Postman 啊？Apifox 它不香吗？」

发，我们专门聊聊 Apifox。

我必须先承认它真的很强。一体化平台，API 文档、调试、Mock、自动化测试、团队协作全在一个工具里搞定，相当于 Postman + Swagger + JMeter 三合一。界面是中文，文档是中文，国内团队几乎零学习成本。如果你的团队 20 人以上，需要权限管理、需要实时协作、需要统一的 API 文档管理，Apifox 是比 Bruno 更合适的选择。这点我不否认。

而且 Apifox 不傻，它也在跟上 AI 浪潮。它有 apifox-cli，能在终端里跑测试场景。它甚至专门做了 Apifox MCP Server，可以让 Cursor 和 Claude Desktop 读取 Apifox 项目里的 API 文档，帮你写代码。

那问题来了，Bruno 和 Apifox 在 AI 这件事上到底有啥不一样？

我读了一圈 Apifox 的官方文档，发现一个挺有意思的差别。

Apifox 接 AI 的方式，是让 AI 来连接 Apifox。Bruno 接 AI 的方式，是 Bruno 根本就是 AI 已经会读的格式。

具体说，Apifox 的 AI 工作流是这样的，你的测试数据躺在 Apifox 云端项目里，你装一个 Apifox MCP Server，配置 Cursor 去连这个 MCP，AI 通过 MCP 协议向 Apifox 服务发请求，把 API 文档拿下来，再帮你生成代码。

Bruno 的 AI 工作流是这样的，你的测试就是项目目录里的 .bru 文件，AI 直接 cat、edit、bru run。完了。

你看出区别了吗？Apifox 把 AI 当成一个外部工具来对接，所以需要 MCP 这一层中转。而 Bruno 根本不需要 MCP，因为它跟 AI 用的是同一种原生语言：文本文件加终端命令。

还有一个更现实的差别。Apifox 的 MCP Server 现在的能力，是让 AI 读取 API 文档来生成代码，它并不能让 AI 直接去编辑你的测试用例。AI 在 Apifox 这边的角色基本上是只读的。

而我前面演示的那两个场景，Claude Code 帮我写新测试、自动调试、修字段名，那是完整的读写跑改循环。AI 不光在读，还在写，还在跑，还在调试。这是因为 .bru 是普通文件，Edit 工具就能改，Bash 工具就能跑。它中间没有任何一层，所以也没有任何一层会卡住。

这不是说 Apifox 不好，是两条不同的路。Apifox 选的是「我是平台，AI 来连我」，Bruno 选的是「我什么都不是，我就是文件」。前者适合企业级场景，后者适合代码即测试的开发者工作流。

我自己是后者。我喜欢我所有的东西都能塞进 Git 仓库，喜欢 AI 直接读我硬盘上的文件，不喜欢任何账号、登录、云端中转。所以我选 Bruno。

如果你的工作场景更接近企业级 SaaS 那一套，那 Apifox 完全没问题，甚至更合适。但如果你跟我一样，希望让 AI 一句话把接口测试搞定，那 Bruno 这条路确实更顺。

聊完 Apifox 我们继续。顺便提一下 CI 集成，因为这块也很丝滑。Bruno CLI 支持输出 JUnit XML，GitHub Actions、GitLab CI、Jenkins 直接吃这个格式。我的工作流文件大概长这样。

1- name: 安装 Bruno CLI run: npm install -g @usebruno/cli- name: 跑接口测试 run: bru run --env production --reporter-junit junit.xml

两步。你的 PR 一提交，所有接口测试自动跑一遍，挂了直接拒绝合并。

生成的测试执行也挺好看的

整套东西免费、开源、本地、Git 友好、AI 友好，不用登录、不用付钱、不用担心数据上云。

安装很简单。桌面版，

1brew install bruno
2
3```bash
4
5CLI，
6
7```bash
8npm i -g @usebruno/cli

用了一周之后我把 Postman 卸了。

不是它不好，是我不再需要一个登录才能用、集合存在别人云上、免费版各种限制、AI 完全帮不上忙的接口测试工具了。

我只需要一个文件夹、几个 .bru 文件、一条终端命令，和一个能读懂这一切的 AI。

有时候工具的进步不是功能越加越多，而是把不该有的东西去掉。Bruno 去掉了登录、去掉了云端、去掉了 GUI 锁定，剩下的全是程序员真正需要的东西。

而当你把这些不需要的东西去掉之后，你会发现一个意外的副作用，AI 进来了。

好了就说这么多。

如果你也受够了 Postman，试试 Bruno。说不定你也会像我一样，用完就回不去了。

ps:我写的 demo 在这里，你可以拉下来试一下，可以 run 的：https://github.com/xiaobox/bruno-demo

Vim 从何而来

Sat, 04 Nov 2023 06:38:45 +0000

Vim 编辑器的创造者、维护者和终身领导者 Bram Moolenaar 于 2023 年 8 月 3 日因病去世，享年 62 岁

为了纪念这位杰出的荷兰程序员，我们今天来聊一聊 Vim 的历史。

Vim 无处不在。它被很多人使用。同时 Vim 可能是世界上 “最难用的软件之一” ，但是又多次被程序员们评价为最受欢迎的代码编辑器。

Vim 预装在 Mac OS 上，并且在 Linux 领域拥有大量支持者。即使对于那些讨厌它的人来说，它也很熟悉，因为足够流行的命令行工具会默认将用户带入 Vim。

有一些主要网站，包括 Facebook，当你按 j 键时会向下滚动，当你按 k 键时会向上滚动 — 这就是通过 Vim 的广泛传播而形成的文化。

然而 Vim 也是一个谜。

例如，与众所周知的由 Facebook 开发和维护的 React 不同，Vim 没有明显的赞助商。

尽管它无处不在且很重要，但似乎没有任何类型的委员会或组织对 Vim 做出决策。

你可能会花几分钟浏览 Vim 网站（https://www.vim.org），但无法更好地了解谁创建了 Vim 或为什么创建。

如果你启动 Vim 时没有给它提供文件参数，那么你将看到 Vim 的启动消息，其中显示 Vim 是由“Bram Moolenaar 等人”开发的。但这并不能告诉你太多。布拉姆·穆勒纳尔 (Bram Moolenaar) 是谁？他的合作者又是谁？

也许更重要的是，为什么退出 Vim 需要输入 :wq ？

当然，这是一个“写入”操作，然后是一个“退出”操作，但这并不是一个特别直观的约定。谁决定复制文本应该被称为“yanking”？为什么 :%s/foo/bar/gc 是“查找和替换”的缩写？Vim 的特性似乎太随意了，不可能是虚构的，但它们是从哪里来的呢？

正如通常的情况一样，答案始于古老——贝尔实验室。从某种意义上说，Vim 只是一个软件的最新版本——称之为“wq 文本编辑器”——自 Unix 时代开始以来一直在不断开发和改进。

Ken Thompson 编写了一个行编辑器

1966 年，贝尔实验室聘请了 Ken Thompson。汤普森刚刚在加州大学伯克利分校获得了电气工程和计算机科学硕士学位。在那里，他使用了一个名为 QED 的文本编辑器，该编辑器是在 1965 年至 1966 年间为伯克利分时系统编写的。

汤普森到达贝尔实验室后做的第一件事就是为麻省理工学院兼容时间重写 QED - 共享系统。后来他为 Multics 项目编写了 QED 的另一个版本。在此过程中，他扩展了该程序，以便用户可以搜索文件中的行并使用正则表达式进行替换。

Multics 项目与伯克利分时系统一样，旨在创建一个商业上可行的分时操作系统，该项目是麻省理工学院、通用电气和贝尔实验室之间的合作项目。AT&T 最终认为该项目毫无进展并退出。

汤普森和贝尔实验室研究员丹尼斯·里奇现在无法访问分时系统，他们开始创建自己的版本，最终被称为 Unix。1969 年 8 月，当他的妻子和年幼的儿子去加利福尼亚度假时，Thompson 组装了新系统的基本组件，“为操作系统、shell、编辑器各分配了一周的时间”。

编辑器将被称为 ed 。它基于 QED，但并不是精确的重新实现。Thompson 决定放弃某些 QED 功能。正则表达式支持被削减，以便只能理解相对简单的正则表达式。QED 允许用户通过打开多个缓冲区来一次编辑多个文件，但 ed 一次只能使用一个缓冲区。尽管 QED 可以执行包含命令的缓冲区，但 ed 不会执行此类操作。可能需要进行这些简化。Dennis Ritchie 表示，没有 QED 的高级正则表达式“并没有多大损失”

ed 现在是 POSIX 规范的一部分，因此如果你有兼容 POSIX 的系统，则可以将其安装在你的计算机上。它值得一试，因为许多 ed 命令如今已成为 Vim 的一部分。例如，为了将缓冲区写入磁盘，你必须使用 w 命令。为了退出编辑器，你必须使用 q 命令。这两个命令可以同时在同一行指定 - wq 。

与 Vim 一样， ed 是一个模式编辑器；要从命令模式进入输入模式，你可以使用插入命令（ i ）、附加命令（ a ）或更改命令（ c ），取决于你如何转换文本。ed 还引入了用于查找和替换（或“替换”）文本的 s/foo/bar/g 语法。

鉴于所有这些相似之处，你可能认为普通 Vim 用户使用 ed 不会遇到任何问题。但 ed 在另一个重要方面与 Vim 完全不同。ed 是一个真正的行编辑器。它是在电传打字机时代编写并广泛使用的。当 Ken Thompson 和 Dennis Ritchie 攻克 Unix 时，他们看起来像这样：

ed 不允许你在打开缓冲区的其他行之间编辑行，或移动光标，因为 ed 每次都必须重新打印整个文件对其进行了更改。1969 年的时候， ed 还没有“清除”屏幕内容的机制，因为屏幕只是一张纸，已经输出的所有内容都是用墨水输出的。必要时，你可以要求 ed 使用列表命令 ( l ) 为您打印出一系列行。因此，使用 ed 有点像试图用功率不足的手电筒在黑暗的房子里寻找出路。你一次只能看到这么多，所以你必须尽力记住所有东西在哪里。

这是 ed 会话的示例。我添加了注释（在 # 字符之后）来解释每行的用途

 1[tt 09:49 ~]$ ed
 2i # Enter input mode
 3Hello world!
 4
 5Isn't it a nice day?
 6. # Finish input
 71,2l # List lines 1 to 2
 8Hello world!$
 9$
102d # Delete line 2
11,l # List entire buffer
12Hello world!$
13Isn't it a nice day?$
14s/nice/terrible/g # Substitute globally
15,l
16Hello world!$
17Isn't it a terrible day?$
18w foo.txt # Write to foo.txt
1938 # (bytes written)
20q # Quit
21[sinclairtarget 10:50 ~]$ cat foo.txt
22Hello world!
23Isn't it a terrible day?

Bill Joy 编写了一个文本编辑器

ed 对于 Thompson 和 Ritchie 来说工作得足够好。但其他人发现它很难使用，并且它被认为是 Unix 对新手特别不友好的一个例子。

1975 年，一位名叫 George Coulouris 的人在伦敦玛丽女王学院安装的 Unix 系统上开发了 ed 的改进版本。

与 ed 不同，Coulouris 的程序允许用户在屏幕上编辑一行，逐个按键地浏览该行。Coulouris 称他的程序为 em ，或“凡人的编辑器”

1976 年，Coulouris 带着 em 来到加州大学伯克利分校，并以客座教授的身份在加州大学伯克利分校度过了一个夏天。此时距离肯·汤普森离开伯克利去贝尔实验室工作整整十年了。在伯克利，Coulouris 遇到了 Bill Joy，他是一名从事 Berkeley Software Distribution (BSD) 工作的研究生。Coulouris 向 Joy 展示了 em ，Joy 从 Coulouris 的源代码开始构建了 ed 的改进版本，称为 ex ，用于“扩展 ed 的 1.1 版本与 1978 年 BSD Unix 的第一个版本捆绑在一起。ex 很大程度上与 ed 兼容，但它增加了两种模式：“open”模式，它启用了单行编辑，就像 em 一样，以及“视觉”模式，它接管整个屏幕并启用整个文件的实时编辑，就像我们今天习惯的那样。

1979 年的第二个 BSD 版本，引入了一个名为 vi 的可执行文件，它的作用只不过是在可视模式下打开 ex 。

ex / vi （此后称为 vi ）建立了我们现在与 Vim 关联的大部分约定，这些约定尚未成为 ed 的一部分。Joy 使用的视频终端是 Lear Siegler ADM-3A，其键盘没有光标键。相反，箭头被绘制在 h 、 j 、 k 和 l 键上，这就是 Joy 使用这些键作为光标的原因 vi 中的移动。ADM-3A 键盘上的退出键也是今天我们可以找到 Tab 键的地方。

命令前缀的:字符也来自 vi ，在常规模式下（即通过运行 ex 输入的模式）使用 : 作为提示。这解决了长期以来对 ed 的抱怨。在可视模式下，保存和退出现在需要输入经典的 :wq 。“Yanking”和“putting”、标记以及用于设置选项的 set 命令都是原始 vi 的一部分。我们今天在 Vim 中进行基本文本编辑过程中使用的功能主要是 vi 功能。

vi 是除 ed 之外唯一与 BSD Unix 捆绑在一起的文本编辑器。当时，Emacs 可能要花费数百美元（这是在 GNU Emacs 之前），因此 vi 变得非常流行。但 vi 是 ed 的直接后代，这意味着如果没有 AT&T 源许可证，则无法修改源代码。这促使一些人创建 vi 的开源版本。STEVIE（VI 爱好者的 ST 编辑器）出现于 1987 年，Elvis 出现于 1990 年， nvi 出现于 1994 年。其中一些克隆添加了额外的功能，如语法突出显示和分割窗口。尤其是 Elvis，它的许多功能都被纳入了 Vim，因为许多 Elvis 用户都在推动将其纳入其中。

Bram Moolenaar 撰写 Vim

“Vim” 现在缩写为“Vi Improve”，最初代表“Vi Imitation”。与许多其他 vi 克隆一样，Vim 最初是尝试在不可用的平台上复制 vi 。Bram Moolenaar 是一位荷兰软件工程师，在荷兰 Venlo 的一家复印机公司工作，他想要为他全新的 Amiga 2000 使用类似 vi 的东西。在 1988 年，Moolenaar 以现有的 STEVIE vi 克隆为起点，开始研究 Vim。

Moolenaar 可以访问 STEVIE，因为 STEVIE 之前曾出现在名为 Fred Fish 磁盘的东西上。Fred Fish 是一位美国程序员，他每个月都会寄出一张软盘，其中包含精选的适用于 Amiga 平台的最佳开源软件。任何人都可以索取磁盘，只需支付邮费即可。Fred Fish 磁盘上发布了 STEVIE 的多个版本。Moolenaar 使用的版本已在 Fred Fish 磁盘 256 上发布。

Moolenaar 喜欢 STEVIE，但很快注意到缺少许多 vi 命令。因此，对于 Vim 的第一个版本，Moolenaar 将 vi 兼容性作为他的首要任务。其他人编写了一系列 vi 宏，Moolenaar 能够让这些宏在 Vim 中运行。1991 年，Vim 首次在 Fred Fish 磁盘 591 上发布，名称为“Vi Imitation”。Moolenaar 添加了一些功能（包括多级撤消和针对编译器错误的“快速修复”模式），这意味着 Vim 已经超越了 vi 。但 Vim 一直是“Vi Imitation（模仿）”，直到 1993 年通过 FTP 发布 Vim 2.0。

Moolenaar 在各种互联网合作者的偶尔帮助下，稳定地为 Vim 添加了功能。Vim 2.0 引入了对 wrap 选项和水平滚动长行文本的支持。Vim 3.0 添加了对分割窗口和缓冲区的支持，该功能受到 vi 克隆 nvi 的启发。Vim 现在还将每个缓冲区保存到交换文件中，以便编辑后的文本可以在崩溃时幸存下来。Vimscript 首次出现在 Vim 5.0 中，并支持语法突出显示。与此同时，Vim 的受欢迎程度与日俱增。它被移植到 MS-DOS、Windows、Mac，甚至 Unix，与原始的 vi 竞争。

2006 年，Vim 被评选为最受 Linux Journal 读者欢迎的编辑器。如今，根据 Stack Overflow 的 2018 年开发者调查，Vim 是最流行的文本模式（即终端仿真器）编辑器，25.8% 的软件开发人员（以及 40% 的系统管理员/DevOps 人员）使用它。有一段时间，在 20 世纪 80 年代末和整个 90 年代，程序员发动了“编辑器战争”，使 Emacs 用户与 vi （最终是 Vim）用户对立。虽然 Emacs 当然仍然有一些追随者，但有些人认为编辑器之战已经结束，Vim 获胜了。2018 年 Stack Overflow 开发者调查表明这是事实；只有 4.1% 的受访者使用 Emacs。

Vim 是如何变得如此成功的？显然人们喜欢 Vim 提供的功能。但我认为，Vim 背后的悠久历史表明，它拥有的优势不仅仅是其功能集。Vim 的代码库可以追溯到 1988 年，当时 Moolenaar 开始研究它。“wq 文本编辑器”有几种不同的具体表达方式，但部分归功于 Bill Joy 和 Bram Moolenaar 对向后兼容性的不同寻常的关注，随着时间的推移，好的想法逐渐积累起来。从这个意义上说，“wq 文本编辑器”是运行时间最长、最成功的开源项目之一，得到了计算世界中一些最伟大思想家的贡献。我不认为“初创公司抛弃所有先例并创造颠覆性新软件”的开发方法一定是坏事，但 Vim 提醒我们，协作和增量方法也可以产生奇迹。

vim 配置 nginx 语法高亮

Mon, 06 Sep 2021 07:33:47 +0000

当你使用 vim 编辑器编辑 nginx 的配置文件时，vim 编辑器是无法自动识别出 nginx 的相关语法的。
所以，使用 vim 编辑器编辑 nginx 配置文件时，无法实现”语法高亮”功能，也就是说，默认情况下，使用 vim 编辑 nginx 配置文件时，没有彩色的语法着色。
对于使用者来说，这样体验不好，nginx 官方很贴心，在源码包中为我们提供了 vim 针对 nginx 的语法高亮配置文件，我们只要把这些文件拷贝到 vim 的对应目录中即可直接使用，方法很简单

如下：

1
2# wget http://nginx.org/download/nginx-1.14.2.tar.gz
3# tar -xf nginx-1.14.2.tar.gz
4
5进入到源码包解压目录
6# cd nginx-1.14.2/
7将相应的语法文件拷贝到对应的目录中，即可完成
8# cp -r contrib/vim/* /usr/share/vim/vimfiles/

参考：https://www.zsythink.net/archives/3091

centos7 使用kubeadm 安装 k8s集群

Sun, 21 Mar 2021 10:56:34 +0000

环境

centos 7.6
k8s 1.13.4
3台机器 1台master 2台worker

准备工作

关闭swap

执行swapoff临时关闭swap。重启后会失效，若要永久关闭，可以编辑/etc/fstab文件，将其中swap分区一行注释掉

至于为什么关闭这里有个说明：https://github.com/kubernetes/kubernetes/issues/53533，亦有说影响性能的 https://www.zhihu.com/question/374752553

关闭防火墙和selinux

根据文档来的:https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

1# 将 SELinux 设置为 permissive 模式（相当于将其禁用）
2setenforce 0
3sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

开放端口

允许 iptables 检查桥接流量

1cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
2br_netfilter
3EOF
4
5cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
6net.bridge.bridge-nf-call-ip6tables = 1
7net.bridge.bridge-nf-call-iptables = 1
8EOF
9sudo sysctl --system

安装docker（全部节点）

安装

 1#安装需要的工具
 2yum install -y yum-utils device-mapper-persistent-data lvm2
 3#设置源
 4yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
 5#查看有哪些docker版本
 6yum list docker-ce --showduplicates | sort -r
 7#安装特定的版本
 8yum makecache fast && yum install -y docker-ce-18.09.8-3.el7 docker-ce-cli-18.09.8-3.el7 containerd.io-1.2.0-3.el7
 9#启动docker
10systemctl daemon-reload && systemctl restart docker
11#设置为开机启动
12systemctl enable docker.service

修改Docker默认存储位置

 1systemctl stop docker 或者 service docker stop
 2 
 3#然后移动整个/var/lib/docker目录到目的路径：
 4mv /var/lib/docker /home/data/docker
 5ln -s /home/data/docker /var/lib/docker
 6#reload配置文件
 7systemctl daemon-reload
 8#重启docker
 9systemctl restart docker.service
10#设置docker 开机启动
11systemctl enable docker
12 
13//当然你也可以通过修改配置文件的方式
14vim /etc/docker/daemon.json
15 
16{"registry-mirrors": ["http://7e61f7f9.m.daocloud.io"],"graph": "/new-path/docker"}

阿里云镜像加速

 1#访问：https://cr.console.aliyun.com/cn-beijing/instances/mirrors
 2#找到加速方法，如：
 3 
 4sudo mkdir -p /etc/docker
 5sudo tee /etc/docker/daemon.json <<-'EOF'
 6{
 7 "registry-mirrors": ["https://se35r65b.mirror.aliyuncs.com"]
 8}
 9EOF
10sudo systemctl daemon-reload
11sudo systemctl restart docker

安装kubeadm, kubelet和kubectl(master和worker都装)

添加 yum 仓库创建/etc/yum.repos.d/kubernetes.repo，文件如下内容

1[kubernetes]
2name=Kubernetes
3baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
4enabled=1
5gpgcheck=1
6repo_gpgcheck=1
7gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

安装 kubelet kubectl 和 kubeadm

1yum install -y kubelet-1.13.4 kubeadm-1.13.4 kubectl-1.13.4 kubernetes-cni-0.6.0 
2systemctl enable --now kubelet

从阿里云手动摘取镜像

执行kubeadm config images pull查看到 gcr.io 的连接，如果拉取成功可以进入下一步。如果失败，说明无法访问 grc.io。这时需要手动拉取镜像，可以执行下面的脚本，从阿里云拉取相应镜像

 1#!/bin/bash
 2images=(
 3 kube-apiserver:v1.13.4
 4 kube-controller-manager:v1.13.4
 5 kube-scheduler:v1.13.4
 6 kube-proxy:v1.13.4
 7 pause:3.1
 8 etcd:3.2.24
 9 coredns:1.2.6
10)
11for imageName in ${images[@]} ; do
12 docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName
13 docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName k8s.gcr.io/$imageName
14done

初始化（master）

记得加入 pod-network-cidr 因为后面的网络组件用的是flannel

1kubeadm init --pod-network-cidr=10.244.0.0/16 --image-repository registry.aliyuncs.com/google_containers

安装成功提示

 1Your Kubernetes master has initialized successfully!
 2To start using your cluster, you need to run the following as a regular user:
 3 mkdir -p $HOME/.kube
 4 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 5 sudo chown $(id -u):$(id -g) $HOME/.kube/config
 6You should now deploy a pod network to the cluster.
 7Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
 8 https://kubernetes.io/docs/concepts/cluster-administration/addons/
 9You can now join any number of machines by running the following on each node
10as root:
11 kubeadm join 10.22.9.162:6443 --token e225cp.14g848dy4vpoas75 --discovery-token-ca-cert-hash sha256:aaf9910fb2b94e8c2bc2aea0b2a08538796d8322331561ef1094bebe8a7a790f

第一次使用 Kubernetes 集群所需要的配置命令

1mkdir -p $HOME/.kube
2sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
3sudo chown $(id -u):$(id -g) $HOME/.kube/config

这些配置命令的原因是：Kubernetes 集群默认需要加密方式访问。所以，这几条命令，就是将刚刚部署生成的 Kubernetes 集群的安全配置文件，保存到当前用户的.kube 目录下，kubectl 默认会使用这个目录下的授权信息访问 Kubernetes 集群。如果不这么做的话，我们每次都需要通过 export KUBECONFIG 环境变量告诉 kubectl 这个安全配置文件的位置。

master节点生成其他节点加入的方式

1kubeadm token create --print-join-command

部署 flannel 网络组件

1kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml

查看状态

1# 用 kubectl get 命令来查看当前唯一一个节点的状态了
2kubectl get nodes
3# 用 kubectl describe 来查看这个节点（Node）对象的详细信息、状态和事件（Event）
4kubectl describe node master
5# 通过 kubectl get 重新检查 Pod 的状态：
6kubectl get pods -n kube-system
7# 部署过程中任何环节有问题都可以查看日志 
8journalctl -l -u kubelet

master 节点配置

删除master节点默认污点 taint：污点的意思。如果一个节点被打上了污点，那么pod是不允许运行在这个节点上面的默认情况下集群不会在master上调度pod，如果偏想在master上调度Pod，可以执行如下操作：

1#查看污点
2kubectl describe node master|grep -i taints
3#删除污点
4kubectl taint nodes master node-role.kubernetes.io/master-

加入集群（worker）

利用之前master 初始化的信息加入集群

1kubeadm join 10.22.9.162:6443 --token 43t2na.80oiehldy76rw6lz --discovery-token-ca-cert-hash sha256:67fd28cb6fd03242eda63c7a395096aba1a6784f7234a9b6269ff0941e9070e3

加入成功后在master查看集群状态

1kubectl get nodes

安装Dashboard UI（master）

获得配置文件

1wget https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml

手动获取镜像

1docker pull anjia0532/google-containers.kubernetes-dashboard-amd64:v1.10.0
2docker tag anjia0532/google-containers.kubernetes-dashboard-amd64:v1.10.0 k8s.gcr.io/kubernetes-dashboard-amd64:v1.10.0
3docker rmi anjia0532/google-containers.kubernetes-dashboard-amd64:v1.10.0

修改配置文件（ports部分）

 1# ------------------- Dashboard Service ------------------- #
 2kind: Service
 3apiVersion: v1
 4metadata:
 5 labels:
 6 k8s-app: kubernetes-dashboard
 7 name: kubernetes-dashboard
 8 namespace: kube-system
 9spec:
10 type: NodePort
11 ports:
12 - port: 443
13 targetPort: 8443
14 nodePort: 30001
15 selector:
16 k8s-app: kubernetes-dashboard

运行并查看状态

1kubectl apply -f kubernetes-dashboard.yaml
2#通过以下命令查看 pod 状态
3kubectl get pods -n kubernetes-dashboard
4kubectl get pods,svc -n kubernetes-dashboard

1##创建管理员
2kubectl create serviceaccount dashboard-admin -n kube-system
3kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin
4##获取token 
5kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | grep dashboard-admin | awk '{print $1}')

完全清除或卸载K8s

This a gist for quick uninstall kubernetes If the cluster is node, First delete it from master

1kubectl drain <node name> — delete-local-data — force — ignore-daemonsets
2kubectl delete node <node name>

Then remove kubeadm completely

 1kubeadm reset 
 2# on debian base 
 3sudo apt-get purge kubeadm kubectl kubelet kubernetes-cni kube* 
 4#on centos base
 5sudo yum remove kubeadm kubectl kubelet kubernetes-cni kube*
 6# on debian base
 7sudo apt-get autoremove
 8#on centos base
 9sudo yum autoremove
10 
11sudo rm -rf ~/.kube

参考：

关注公众号获取更多精彩内容