Nocalhost —— 让云原生开发回归原始而又简单

Posted 2021-12-02 DevOps 实践指南

随着应用复杂性不断增高，研发测试环境的准备与维护变成了让人苦恼的问题。CODING Nocalhost 研发负责人王炜将带领大家，一一破解 Kubernetes 应用开发困局。

本文为 CODING Nocalhost 研发负责人王炜在腾讯云 CIF 工程效能峰会上所做的分享。文末可前往峰会官网，观看回放并下载 PPT。

大家好，欢迎参加 CIF 大会，今天我跟大家分享的内容是：破解 Kubernetes 应用开发困局。首先做个简单的自我介绍，我是来自腾讯云 CODING DevOps 的王炜，目前是 Nocalhost 项目研发负责人，同时也是 CNCF 大使。话不多说，让我们进入正题。

这次分享主要分为五个方面：

1. 首先是 K8s 环境下的开发困局；
2. 以及主流的云原生开发方式；
3. 接下来是实现容器应用和热加载的原理；
4. 开发和调试演示，这里会用一个 Demo 来进行演示；
5. 最后是开源共建和展望。

首先是第一部分：K8s 环境下的开发困局。提到云原生开发，我们就不得不先从 Docker 开始说起。当我们的微服务越来越多，运行环境越来越复杂的时候，Docker 镜像为我们提供了很好的解决方案。但是当镜像和容器越来越多，服务的编排就成为了一个难题。这时候也出现了很多方案，例如 K8s、Docker Swarm 等等。当然 K8s 已经几乎成为了事实标准，也成为了容器编排的首选方案，然而这个事实标准提供的能力却是面向运维的。例如，我们可以通过 Liveness 和 Readiness 定义服务的自动恢复机制，通过 Resource 定义资源用量等。这些定义其实对开发人员来说是增加了极大的额外负担，也造成了开发和调试两难的问题。

此外云原生的技术栈跨度非常大，这就对开发人员提出了更高的要求，这也要求团队对云原生架构设计也需要更加符合业务的需要。所以总体而言，对企业来说，招聘和用人的成本也更高了。

下图是一张 CNCF 云原生应用开发的全景图，我们会发现云原生开发工具这一环节目前仍然是缺失的。云原生开发这么难，那么主流的开发方式又是什么呢？或者说我们现在是怎么解决问题的？

经过总结，目前云原生开发方式主要有以下四种。

1. 全手工的流程。例如手工构建以及推送镜像，修改镜像版本，并且等待调度生效。我们把每次查看编码效果称为编码的反馈循环，这种开发方式编码的反馈循环大概需要十分钟一次，这是非常漫长的过程。

2. 全自动的流程，也就是把手动的环节变成了自动。这种方式显然会更快一些，但是它的反馈循环也只是缩短为了五分钟左右一次。

3. 第三种是对云原生比较了解的团队经常会使用的方案，也就是使用 Telepresence 这款工具来开发。Telepresence 主要是打通本地和集群的网络，使开发者能够在本地进行开发。这种开发方式把编码的反馈循环降低到了 10 秒 1 次，但是因为开发服务以源码的方式运行在本地，这种方式有一定的限制，我将在后文深入讲解。

4. 第四种是使用 Nocalhost，直接在容器里开发。这种方式可以摆脱 Telepresence 在某些场景下的使用限制。

接下来我们详细聊一聊以 Telepresence 为代表的网络打通方案的使用限制。首先它最大的限制是本地环境和工作负载的运行环境有很大的差异，这就导致业务源码很难在本地运行。比如说业务在 K8s Manifest 里声明了 configmap、secret、volume 的挂载等等，这些很难在本地重建。其次还有环境方面的差异，以及跨平台，比如说像 Linux 和 Windows 之间的这些平台差异，以及在部分场景下的网络限制。

说了这么多，相信大家也能够理解，在 K8s 环境下开发的最大问题是：每次编码查看效果都需要重新构建镜像，这就导致了长时间的无效的等待。有没有不需要重新构建镜像的方案呢？答案是肯定的。如果我们能在容器里实现进程或者是应用的热加载，每次编码之后可以实时生效，我们是不是就不需要重新构建镜像了呢？

接下来我们继续探讨这种方式的实现原理和方案。首先从 Dockerfile 说起。Dockerfile 里定义了容器的启动命令，一般来说，这是业务进程的启动方式。例如运行一个可执行文件，如果我们进入容器内执行 PS 命令，会发现这个进程对应在容器里面，也就是 PID＝1 的进程。我们以 Go 应用为例，如果让这个 PID＝1 的进程替换为以源码的方式运行，go run main.go 这种方式，我们是不是就可以实现应用热加载，并且修改代码后只需要重新运行这条命令，就可以看到代码效果呢？

我们思路没有错，但是如果要实现这个方案，还需要三个条件。第一是容器的源码从哪里来？除了脚本型语言以外，一般的业务容器都没有源码；第二是以 Go 应用为例，编译的环境从哪里来？我们知道一般情况下构建的业务容器，因为存储大小的考虑，会保持最小的可运行环境；第三，如果将 PID＝1 的进程替换掉之后，怎么阻止容器 Crash？

我们分别来看如何解决这些问题。首先第一点源码问题，我们可以从本地同步到容器里来解决；第二是编译环境，我们可以把运行中的业务镜像，替换成具有编译环境的开发镜像，就能够提供编译环境；第三，我们可以将 PID＝1 的进程替换为一个阻塞的进程，这三个问题就解决了。当我们实现这些方案后，容器其实已经具备了热加载的基础，Nocalhost 的原理正是基于上述的方案来实现的。接下来我会用一个 Demo 来演示应用的热加载和一键 Debug 的效果。

Nocalhost 提供了 VSCode 插件和 JetBrains 的全系列插件，只要安装就可以立即使用。接下来我将以 Golang 的为例，演示开发 Demo 项目 Booking for。

【请点击文末阅读原文，前往 CIF 峰会「开源生态与效能提升」专场 - 《破解 Kubernetes 应用开发困局》，于 08:00 处观看 Demo 演示】

容器应用的实时热加载以及一键调试的演示到这里就结束了，感兴趣的同学可以按照 Nocalhost（nocalhost.dev）官网的 Quick Start 指导动手来试一试。

通过演示相信大家已经理解 Nocalhost 带来的全新云原生的开发体验。最后一部分我将与大家分享开源共建和展望。Nocalhost 目前是一个完全开源的项目，代码托管在 GitHub 上，已经有 900+ star，同时也是 CNCF Landscape 项目，并且被收录在云原生全景图当中，也欢迎大家关注和贡献。

关于展望，在这次的分享中，我介绍了 Telepresence 和 Nocalhost 两种开发方式，它们在解决问题的思路上其实是各有不同的，你可以根据自己的业务情况选择一种方法来使用。此外 Nocalhost 提供了完整的开发环境和开发过程的管理能力，对于希望统一管理开发环境的团队，则可以安装 Nocalhost Server 来集中管理开发集群、应用、以及开发环境，当然 Server 也是开源并且免费的，我在这里提供几张 Server 的截图，感兴趣的同学可以遵循官方文档进行安装以及使用。

我的分享到这里就结束了。欢迎大家访问 Nocalhost（nocalhost.dev）官网，并根据官方文档进行安装和试用，谢谢大家。

点击此处链接，观看 CIF 峰会回放