V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Coding.NET 轻量级社交
开源项目广场
使用帮助
意见反馈
CodingNET
V2EX  ›  Coding

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

  •  
  •   CodingNET · 2021-11-24 17:23:33 +08:00 · 1083 次点击
    这是一个创建于 855 天前的主题,其中的信息可能已经有所发展或是发生改变。

    本文为 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 峰会回放

    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5281 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 09:34 · PVG 17:34 · LAX 02:34 · JFK 05:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.