乐趣区

关于nocalhost:专访-CNCF-大使王炜让云原生开发回归原始而又简单

jiezi

近期，腾讯云 CODING DevOps 开源了云原生开发环境 – Nocalhost。

依据官网文档介绍，Nocalhost 来源于 No Localhost，其含意是开发者不再依赖本地计算机的编码、调试和测试过程。他是一个云原生开发环境，旨在解决云原生下开发难的问题。

例如，在 Kubernetes 环境下进行微服务开发，通常会面临以下问题：

  • 每次批改代码，都须要通过构建映像 -> 推送映像 -> 拉取映像 -> 重新启动应用程序（Pod）的过程，开发的反馈循环十分长（10 分钟以上）；
  • 为了开发某个微服务，必须要在本地启动整个环境和所有微服务，这带来了适度依赖本地资源的问题；
  • 开发人员只专一于他们本人的服务，随着迭代的进行，本地启动或更新残缺的开发环境越来越难；
  • 微服务之间的依赖关系和启动程序难以管制；

  • 新入职的员工个别须要 2-3 周的工夫来相熟开发环境的搭建及学习背景常识

    那么，Nocalhost 到底是怎么解决以上问题的？Nocalhost 的开源，又会给 K8s 生态带来哪些影响呢？带着这些问题，咱们与 Nocalhost 的设计者之一、新晋 CNCF 大使、云原生社区成员，来自腾讯云 CODING DevOps 的王炜，具体聊聊对于 Nocalhost 的产品、技术和生态。

    采访嘉宾

    以下为采访原文：

    Q: 首先跟大家介绍一下 Nocalhost 的起源吧

    王炜：Nocalhost 的起源其实是解决 CODING 本身开发难的问题。CODING 在晚期曾经拥抱微服务、云原生和 Kubernetes，但在咱们日常开发过程中，发现 Kubernetes 尽管解决了部署和运维的问题，但同时也带来了开发难的问题。

    最典型的痛处是每写几行代码，要察看代码成果或者调试，就不得不从新构建镜像 -> 推送镜像 -> 批改工作负载镜像版本 -> 期待 Pod 重建的漫长过程。这个过程尽管能够用自动化的 CI/CD 来解决一部分人工手动运行问题，但其外围不变。

    此外，本地全量运行 CODING 所需的资源要求十分高，晚期开发人员不得不装备一台 8 核 64G 的电脑来开发，后续也尝试过为每个人都装备了一台近程的高配开发机，但开发效率依然无奈晋升。

    针对这种场景，咱们开始摸索相应的解决方案，并最终将该实际开源成为了 Nocalhost 我的项目。

    Q：在云原生环境下，开发难除了体现在每次编码须要从新构建镜像以外，在实践中还遇到了其余痛点吗？

    王炜：痛点十分多！当前端同学为例，从入职开始，相熟和配置开发环境须要花大量的工夫和精力。另外，好不容易搭建好了开发环境，须要更新微服务组件时往往呈现大量组件无奈启动。当然这可能更多的是利用治理问题了，目前社区也有十分好的利用模型实际。

    但问题是，对立保护这套利用模型是十分吃力的，如果应用它的场景十分低频，那么问题裸露会越来越迟，最终与无人保护没有多大差异。而所有开发者的环境又是独立的，遇到问题总是本人解决而不是往下层去更新利用模型，这会进一步导致利用版本越来越老旧。

    所以，咱们思考开发环境是必须要集中化治理，开发环境的部署起源只能是独立保护的利用模型，业务组协同保护并产生部署 - 批改循环效应，能力实现一致性的利用治理。

    Q：所以 Nocalhost 会治理利用和开发环境吗？

    王炜：是的。利用治理是应用内部规范，例如 Manifest 文件组合成的利用、Helm 利用和 Kustomize 利用等，它是用于拉起开发环境的规范装置办法，不同的开发者的开发环境在 Nocalhost 里的定义是开发空间（DevSpace），目前是采纳 Namespace 的形式进行隔离和治理的，不同开发空间后续将反对合作开发。利用和开发空间的治理都能够在 Nocalhost 控制台来实现。

    Q：Nocalhost 有哪些组件组成？

    王炜：Nocalhost 次要由这几个组件组成：

    • 治理侧（面对开发环境的管理人员）

      • Nocalhost 控制台：提供开发人员治理、利用治理、开发空间治理等性能

        • Nocalhost Dep 组件：提供利用依赖治理，管制微服务依赖启动程序

    • 用户侧（开发者）

      • nhctl-cli：Nocalhost 命令行工具，提供残缺的性能

        • IDE 插件：提供 VS Code 插件和 JetBrains 插件

    Nocalhost 工作示意图：

    Q：Nocalhost 对开发者来说最直观的应用感触是什么？

    王炜：对开发者来说，最直观的应用感触是开发过程变得非常简单，从部署开发环境到开发只须要在 IDE 插件上进行简略的 四步 操作：

    1. 一键拉起开发环境

    2. 点击“锤子”进入待开发组件的“开发模式”

    3. 在本地 IDE 编写代码，保留

    4. 无需从新构建镜像，新代码在远端容器间接失效

      在应用 Nocalhost 进行服务开发时，屏蔽了开发所需的简单背景常识，只须要具备语言开发根底，就可能立刻进行业务代码的开发工作。

      目前在 CODING 最快的实际是：刚入职的新同学，中午接到需要后，下午就曾经提交了业务代码。令人兴奋的是，他面对的需要是一套由 100 多个微服务组成的零碎，这一切都是建设在他不理解任何 CODING 微服务架构、开发环境、甚至是业务代码的仓库地址（Nocalhost 已提前配置好）的背景下独立实现，这在以前的开发模式下是无奈设想的。

      Q：比方我已有一套业务零碎，怎么应用 Nocalhost？

      王炜：对于已有的业务零碎，首先确认是否为 Kubernetes 规范的利用装置形式，例如 Manifest、Helm 和 Kustomize。

      其次，Nocalhost 不侵入任何的业务逻辑，只须要应用申明式的配置形式提供开发参数配置即可，以开发 Istio 提供的 Bookinfo 为例。

      以下是寄存 Bookinfo 安装文件的 Git 仓库：https://github.com/nocalhost/bookinfo。

      该仓库的目录构造如下图所示。

      其中，manifest/templates 目录蕴含 Bookinfo Manifest 类型的安装文件：

      当有了利用之后，咱们便可能为该仓库创立 .nocalhost/config.yaml 来为 Nocalhost 提供开发参数。例如，这是 Bookinfo 利用以及 productpage 服务的局部开发参数：

      configProperties:
      version: v2
      ​
      application:
      name: bookinfo
      # 利用类型
      manifestType: rawManifest
      # 利用 Manifest 的目录
      resourcePath: [“manifest/templates”]
      ignoredPath: []
      onPreInstall: []
      services:
      # 要开发的服务名称

      • name: productpage

      # 要开发的服务类型
      serviceType: deployment
      # 申明依赖服务，将会期待依赖启动后本身才会启动
      dependLabelSelector:
      jobs:

      • “dep-job”

      containers:

      • name: productpage

      # 利用装置后主动端口转发
      install:
      portForward:

      • 39080:9080

      dev:
      # 定义源码仓库地址
      gitUrl: https://e.coding.net/codingco…
      # 定义开发镜像
      image: codingcorp-docker.pkg.coding.net/nocalhost/dev-images/python:3.7.7-slim-productpage
      # 定义进入开发容器的 bash
      shell: bash
      workDir: /home/nocalhost-dev
      # 定义文件同步
      sync:
      type: send
      filePattern:

      • ./

      ignoreFilePattern:

      • “.git”

      # 开发模式主动端口转发
      portForward:

      • 39080:9080

      在该配置文件中，咱们为 Nocalhost 提供了 productpage 服务的一些开发参数。最初，再通过 Nocalhost 控制台创立该利用并提供仓库地址即可。

      通过以上配置，便可能实现利用无缝迁徙到 Nocalhost 进行开发。

      Q：Nocalhost 下一步的打算是什么？

      王炜：Nocalhost 目前在 CODING 日常开发简直已全员笼罩，但依然有很多优化空间。

      正如 Nocalhost 的 Slogan 一样，Nocalhost 的初心是让云原生开发回归原始而又简略。心愿能为云原生开发环境提供摸索和示范，并成为云原生生态不可短少的一部分。

      目前 Nocalhost 已进入 CNCF Landscape，后续将推动与 CNCF 更加深刻的单干。

      Q：是否谈谈国内的云原生发展趋势和集体认识？

      王炜：依据 Gartner 钻研报告指出：到 2022 年，云原生和容器化的普及率将达到 75% 以上，这意味着云原生的大趋势已成为定局。K8s 作为弱小的基础设施底座，为企业应用提供了极强的生产稳定性。

      但随着咱们对 K8s 的应用水平越来越深，会发现 K8s 面向“工作负载”的设计在一些场景下是须要晋升的。围绕着这些问题的焦点，社区一直地在为 K8s 进行插件式的扩大。CNCF Landscape 中已有靠近 400 个开源产品为 K8s 提供了额定能力，这些技术方向大抵被分为了数据库、音讯、利用定义和镜像构建等，产品数量依然一直回升。

      K8s 生态倒退至今，集体认为目前有两大方向是急需社区来解决的：第一是利用定义模型，代表有 OAM 规范和 Kubevela，该方向与 DevOps、GitOps 具备紧密联系。第二是始终被疏忽的利用开发。这两个方向都是晋升大规模组织开发效率的要害。

      尤其是利用开发方向，目前依然没有标准规范和优良的实际，我置信社区也肯定会有规范诞生。

      最初，欢送大家退出云原生社区参加 Nocalhost 话题探讨。另外 Nocalhost 正在招聘，也欢送对云原生畛域感兴趣的同学退出咱们。

退出移动版