Skip to main content

Announcing Nocalhost v0.5.6

Anur

Anur

Backend engineer at Nocalhost Team

Nocalhost v0.5.6 has been released, we've fixed some bugs, improved the performance and add some new features.

What's new?#

We recently shipped four major improvements:

Supports Node.js remote Run/Debug and HotReload in JetBrains#

Nocalhost now supports remote run/debug/HotReload of Node.js in JetBrains.

Learn more about how to configure Remote Debug of Node.js

Supports HotReload in JetBrains#

Nocalhost now supports HotReload when doing remote run/debug in JetBrains. When enabled this feature, Nocalhost will monitor real-time file changes and automatically re-execute the preset Run/debug commands without manually operation during the development or remote debugging.

Learn more about how to configure HotReload

Major update for Nocalhost Server#

New UI#

We've build a new Server Dashboard UI.

Try our new Nocalhost Sever

MeshSpace#

MeshSpace is based on Istio, allows you to share workloads by specifying header with independent routing.

Learn more about MeshSpace

Supports to share Kubernetes namespace#

You can easily share your Kubernetes namespace with anyone within your team by using Nocalhost Server.

Supports to store Nocalhost configuration in Kubernetes cluster#

You can now easily share your Nocalhost Configuration with anyone who is using the same Kubernetes cluster.

Other Updates#

Read the full changelogs of Nocalhost v0.5.6

Developing APISIX Ingress Controller with Nocalhost in Kubernetes

Garry Chen

Garry Chen

Product Manager at Nocalhost Team

Introduction#

This article walks you through using Nocalhost to seamlessly connect your local development machine to a remote Kubernetes cluster, allowing you to use your favourite IDE to develop and debug Apache APISIX ingress controller. Giving you the ability to comfortably develop and debug your remote apps with your existing skills.

This article covers:

  1. Deploy the APISIX Ingress controller to the remote Kubernetes cluster within IDE
  2. Developing and debugging APISIX ingress controller in Kubernetes without image rebuilding

Prerequisites#

  • Prepare an available Kubernetes cluster in your workstation. You can use any Kubernetes clusters that you have namespace admin privilege.
  • Helm v3.0+ installed
  • APISIX installed
  • GoLand IDE 2020.03+ (I am using GoLand 2021.2 in this article)
  • Install Nocalhost JetBrains plugin
  • Install Go 1.13 or later

Deploy APISIX Ingress Controller#

I'm going to deploy APISIX Ingress Controller by Nocalhost within GoLand:

  1. Open the Nocalhost plugin within GoLand
  2. Use the cluster inspector to select the namespace that you want to deploy.
  3. Right-click the selected namespace, choose Deploy Application, and select Helm Repo as installation method.
  4. In the following dialog box, input
    • apisix-ingress-controller as Name
    • https://charts.apiseven.com as Chart URL
Deploy APISIX ingress controller

Let's test the apisix-ingress-controller after deployment by enable the port-forwarding within IDE:

  1. Find the apisix-ingress-controller workload in the cluster inspector, right-click and select the Port Forward
  2. Add the port-forwarding 8080:8080
  3. Visiting the http://127.0.0.1:8080/healthz in local and check the result
Test the deployment

Developing#

Step 1. Start DevMode#

  1. Right-click the deployment apisix-ingress-controller in cluster inspector, select Start DevMode
  2. Choose your source code directory if you have already cloned in local, or let Nocalhost clone the source code for you by entering the apache/apisix-ingress-controller repository URL
  3. Wait for the operations, Nocalhost will open the remote terminal within IDE after entering DevMode

Now start the apisix-ingress-controller process by entering the following command in the remote terminal:

go run main.go ingress --config-path conf/config-default.yaml

After the apisix-ingress-controller has started, access the service by visiting http://127.0.0.1:8080/healthz on local and check the result.

Entering DevMode

Step 2. Change code and check result#

Now I will make some code changes and check the result.

  1. Stop the apisix-ingress-controller process
  2. Search healthz and find the router.go file. Change the healthzResponse status code from ok to Hello Nocalhost
  3. Start the process again and check the change result in local
⭐️   No need to rebuild image or restart container, see result under seconds   ⭐️

Step 3. End DevMode#

Now close the development window and end DevMode.

  1. Right-click the apisix-ingress-controller in the cluster inspector
  2. Select End DevMode

Nocalhost will make apisix-ingress-controller end DevMode, and reset the apisix-ingress-controller Pod to its original version. Enable the port-forwarding and check the result after ending DevMode.

Ending DevMode
Code Change

All code changes in DevMode will only take effect in the development container.

After exiting the DevMode, Nocalhost will reset the remote container to its original state (before the code is modified). In this way, after exiting the DevMode, the modification of the code will not cause any changes or impact on the original environment.

Debugging#

Debugging an application is not easy, and debugging an application in the Kubernetes cluster is even more difficult. Nocalhost is here to help by providing the same debugging experience you're used in the IDE when debugging in the remote Kubernetes cluster.

Step 1. Start remote debugging#

We can start remote debugging by:

  1. Right-click apisix-ingress-controller and choose Remote Debug
  2. Nocalhost will put apisix-ingress-controller into DevMode and run debug command defined in dev config automatically
Start remote debugging

Step 2. Step through breakpoints#

Now set a breakpoint on the healthz function. Hover over just to the left of the line number and click on the red dot. Once it’s set, visit http://127.0.0.1:8080/healthz in your local browser, GoLand should pop to the foreground. Click the play button to close the request and the progress should continue loading.

In addition, as I enable the dev.hotReload, so every time you make the code change, Nocalhost will automatically re-run the debug command. This is very useful when you make the code change and debug frequently.

Setting up breakpoints and run the service

Remote Run#

Not just remote debugging, Nocalhost also provides an easy way to run your Go service in the Kubernetes cluster, plus hot reload!

You can using the remote run feature by:

  1. Right-click apisix-ingress-controller in cluster inspector, choose Remote Run
  2. Nocalhost will put apisix-ingress-controller into DevMode and start run command defined in dev config automatically

Now every time you make code changes, Nocalhost will automatically trigger the run command. You can now enjoy the hot reload for Go without complex configuration.

Remote run

Conclusion#

Today, we’ve learned how to use Nocalhost to develop and debug the APISIX ingress controller in Kubernetes. Now, instead of waiting for slow local development processes, we can iterate quickly with an instant feedback loop and a productive cloud-native development environment.

References#

Nocalhost 官方文档翻译活动

背景#

Nocalhost 的新官网框架已经上线。因为目前 Nocalhost 官方文档只有英文版,这提高了学习和使用 Nocalhost 的门槛,不利于项目的传播和发展。同时翻译工作也能显著提升语言能力,帮助我们拓宽阅读技术资料的广度,故组织本次活动。

活动流程#

本次活動可以通过使用 Crowdin 平台或下载源码对文档进行翻译

通过 Crowndin 进行翻译#

翻译项目的的地址在:https://crowdin.com/project/nocalhost

账号

当进入项目后,需要注册一个 Crowdin 的账号,您也可以通过 GitHub 账号一键登录

  1. 进入上述地址进入项目
  2. 选择需要翻译的文档,进入在线编辑器
  3. 进行在线翻译
  4. 翻译完成后退出编译器

翻译要求#

  • 如果使用自动翻译,请先检查清楚自动翻译的结果,包括格式和阅读习惯
  • 数字和英文两边是中文要加空格。
  • Nocalhost 和 Nocalhost Server 统一写法。
  • 翻译完请先阅读一遍,不要出现遗漏段落,保证文章通顺、符合中文阅读习惯。不追求严格一致,可以意译。review 的时候也会检验。
  • 你和您不要混用,统一使用用 “你”
  • 不会翻译的词汇可以不翻译,可以在 PR 中说明,review 的时候会查看。
  • 注意中英文标点符号。

注意事项#

在翻译的时候,请注意原文格式和 Crowdin 生成的标签。比如下图中的 <0></0><1></1>。这些标签是 Crowdin 自动生成的,用于替换原文中的图标,特殊格式等。

Crowdin 标签

Nocalhost 官网使用了 Docusaurus,因此某些特殊符号和格式请注意。

例如:

:::note title
内容。。。。。
:::

这个是 Docuasurus 的告示(Admonition)方法。在翻译时,note 需要翻译,后面的 title 需要翻译。另外,请注意格式。

更美成立于2013年,旗下更美App是专业医美平台, 提供整形、微整形、齿科、眼科、抗衰老等消费医疗服务。更美App平台的业务主要分为三大部分:医美用户社区、健康服务电商及特卖、企业级医疗机构应用平台。 更美致力于帮助求美者更高效地找到合适的医生,降低消费风险;也帮助医生塑造个人品牌。

更美的开发环境发展历程#

更美架构介绍#

更美目前的整体技术架构形式为微服务+多语言,基于云厂商进行容器化部署。微服务基于功能分为业务逻辑层、核心服务层、底层服务层。

最初的本地开发环境#

开发模式#

在更美基础团队最初的开发模式中,所有的开发和调试工作都是在本地进行的。在上面提到的服务分层,业务逻辑和核心服务是最常变动开发的服务。底层服务层相对稳定,例如passport服务,一般不会变动,提供基础的接口支持。开发人员在个人开发环境运行服务、调试代码。联调服务时,在办公网络下暴露自己电脑的网络接口。底层服务只作为服务端,不会作为客户端请求其他服务,可以部署在云端测试环境,通过打通办公网络与云端测试环境网络的方式,暴露给开发人员。

存在问题#

在这种开发模式下,存在如下几个问题:

  1. 开发人员本地微服务环境难以搭建。在微服务的架构下,一套环境有几十个微服务,每个服务都需要相对独立的运行环境。
  2. 开发人员需要在本地同时运行多个服务,对开发机的要求极高。一般的个人笔记本电脑难以支撑及时升级配置,也难以完成支撑一整套测试环境的运行,极大的提升成本,降低开发效率。
  3. 测试环境供不应求,资源冗余,成本上升。开发环境与测试环境分离,需求开发完成提交代码到测试环境时,尝尝遇到上一个需求还在测试中,占用环境阻塞提测。
  4. 创建多套完全独立的测试环境,在一定程度上可以缓解阻塞的情况,但是带来了更多的资源冗余问题。每一套环境,都需要跑整套的微服务、底层数据和配置管理。资源消耗、运维压力都很大。
  5. 在业务需求多、周期紧张的情况下,仍旧无法很好的支持多分支、多feature并行开发、并行测试的需求

基于GitOps的云原生开发环境#

什么是GitOps#

GitOps 是一套使用 Git 来管理基础架构和应用配置的实践,GitOps 在运行过程中以 Git 为声明性基础架构和应用的单一事实来源,Git 仓库包含系统的全部状态(集群部署的mainfest file)。

新环境架构及现状#

面对之前存在的种种痛点和问题,我们的架构运维团队一直在探索和优化整体的架构新模式。首先,服务部署形式全部容器化,由主机部署模式,转变为基于k8s的容器化部署。引入了多种开源工具,基于云原生生态,搭建了一整套的自动化开发测试体系。实现了整个开发测试流程运维无介入的GitOps体系。极大的解放了人力,提高的迭代效率。

在新的测试环境体系中,为了解决多分支、多feature并行测试的需求,我们引入了serviceMesh工具Istio,做流量管理。通过Istio流量分发,串联多套测试环境。测试环境维护一套基于当前线上最新分支构建的base环境。所有微服务在未进入开发周期中,只保持base环境的最小化运行。进入开发周期的微服务,可以在根据命名规范切出对应分支后,部署对应分支环境,测试流量通过Istio IngressGateway进入后,根据不同的规则进行路由。实现了一套基础环境+多套feature环境的大测试集群。

未命名文件

整体环境的自动化流转基于git代码提交来实现,在代码提交后,自动实现镜像构建、容器发布、流量切换、群通知,极大提升开发迭代效率。主要实现如下能力:

  • 一套base测试环境,减少资源冗余

基础环境同步当前线上最新代码,自动触发部署。确保base环境永远与生产环境相同

  • 多套feature环境

根据分支命名规则,同feature下的不同微服务形成一套小环境,流量与其他feature隔离;

各feature对应的小环境相互独立;

feature中的服务请求到了不在开发中的微服务,把流量路由到base环境。实现底层服务的对多环境共享。

开发、测试环境一体化。在独立feature环境下完成开发联调和提测。

  • GitOps自动化运维体系

    基于git代码的变更实现自动化流程的运转

    基于git仓库来声明整体的基础架构

基于coding的CICD体系#

在持续集成阶段,我们采用git+jenkins+docker镜像仓库来实现。符合开发命名规范的代码分支变更后,触发jenkins的构建流程,完成后push镜像到仓库。

在持续交付阶段,采用的是Netflix 开源持续交付平台 Spinnaker。在CI流程完成后触发CD流程,spinnaker自动完成新分支版本的创建、部署、流量分发及结果通知触发。

image-20210903184802962

image-20210903185123216

后续我们逐步把CD流程在逐步迁移到腾讯云的coding平台。coding的CICD发布体系,也是基于jenkins+spinnaker来实现,并进行了一系列优化。与我们的技术栈非常契合,迁移成本非常小,能有效降低我们的运维成本。

目前我们的生产环境已经完成全部迁移,可以基于coding发布单实现服务的快速发布。整体发布过程由开发人员提交发布,测试人员确认后,即进入自动化发布流程。相比之前的上线开发与测试线下沟通确认可上线后,再找运维来处理发布,更加合理也更加灵活。

当前主要痛点#

  1. 开发测试阶段如何快速联调应用。在当前的架构形式下,整体的流程都是正常运转的。但是开发人员的code环境和开发联调、测试环境是分离的,每一次修改都需要数分钟的时间等待CICD流程的完成,才能实际验证修改效果。比较影响开发人员的开发体验,降低工作效率。
  2. 初始开发环境构建难度大。本地仍旧需要开发人员针对不同的微服务,设置不同语言、甚至不同语言版本的开发环境。微服务越多,本地开发环境越难以搭建。新入职的初级开发工程师,甚至需要花费数天乃至一周来搭建自己的开发环境。

Nocalhost的到来#

为了解决目前最主要的痛点,我们一直在调研本地容器化开发、云端开发等各种开发模式与开发工具,来提升开发体验。我们调研过多种方案与工具,最终发现Nocalhost的出现,非常契合我们目前的架构体系,也能最大程度解决我们现在遇到的痛点。

Nocalhost是什么#

根据官网介绍,Nocalhost 一词源于 No Local,它是一款基于 IDE 的云原生开发工具,提供实时的云原生应用开发体验。

在Nocalhost中开发基于云端的应用时,任何代码更改都可以立即在远程端生效,无需重新构建新镜像。这可以缩短整个开发反馈循环周期并大幅提高研发效率。有团队把nocalhost称之为容器时代的rsync工具。

Nocalhost带来了什么#

开发中的优势:

  • 环境一致性:开发环境与生产环境统一由运维团队维护和部署,整体环境一致性非常高;
  • 反馈及时性:在nocalhost开发模式下,开发人员在IDE中的代码编辑可实现保存即生效,与本地开发没有太大差别;
  • 环境易搭建:即使是新人入职,本地没有开发环境。那他在常用的IDE中安装插件后,运维提供授权即可连接云端K8S测试集群,即时进入coding状态;
  • 资源易拓展:开发不再受限于开发机的计算资源,可随时借助云端集群扩展资源。

Nocalhost in 更美#

下图是一张通过Nocalhost VScode插件进入云端的开发模式,左侧可以遍历显示所有容器的当前开发状态,代码编辑窗口的保存可实时同步到容器触发重载;最下面的终端其实是已经远程到容器内的输出了,可以看到容器内running进程的实时反馈。

image-20210903200621789

可以看到,在进入nocalhost开发模式后,完全可以实现类似于本地开发模式的即改即生效的效果,开发过程非常舒适。对于编译型语言,既可以在本地编译,也可以直接在云端编译。

根据参与体验的开发人员反馈,使用nocalhost开发,能大约提升30%的开发效率,效果非常可观。我们也在与nocalhost团队保持沟通、持续反馈使用体验和过程中遇到的一些问题,希望这款工具能越来越好。我们也会尝试在团队内继续推进工具的落地,助力我们进一步提升团队工作效率。十分期待nocalhost的进一步发展

微服务远程Debug,Nocalhost + Rainbond微服务开发第二弹

Qi Zhang

Qi Zhang

Cloud Native Enthusiasts

之前的文章中我们介绍了如何通过 Nocalhost 快速开发 Rainbond 上的微服务,介绍了基本的开发流程。

本文将续接上文继续介绍,使用 Nocalhost 开发配置文件 实现以下内容:

  • 一键 Run 和 远程Debug
  • 持久化配置
  • 开发容器资源限制
  • 端口转发

什么是开发配置?

开发配置是围绕 开发模式 来进行的,例如使用什么镜像来进入 开发模式,是否需要开启持久化来保存开发容器的内容,将哪些文件同步到开发容器中,如何一键调试、一键运行容器内的服务等。 配置了正确且合适的开发配置后,可以在使用 Nocalhost 开发模式 时更加得心应手。

部署 Rainbond + SpringCloud#

接下来继续以上文中的 SpringCloud Pig 为例,调试 Java Maven 服务的 Pig-auth 模块。

项目 Gitee 地址:https://gitee.com/zhangbigqi/pig

部署 Rainbond#

这里就不详细介绍 Rainbond 的安装,请参阅 基于Linux安装Rainbond

部署 SpringCloud#

我们在 Rainbond 内对接了开源应用商店后,在开源应用商店内搜索 Spring Cloud Pig 安装 3.5.0 版本。

来自应用商店安装应用组件的英文名称是自动生成的字符串,需要我们设置一下组件的英文名称(Deployment Name),通过 Nocalhost 连接到集群时可以很直观的分清楚 Deployment 对应的组件。

Nocalhost 对接 Rainbond#

  1. 安装 Nocalhost JetBrains Plugin 插件,请参阅文档 安装Nocalhost JetBrains Plugin 插件

  2. 获取 K8s Kubeconfig,请参阅文档 获取 Kubeconfig 文件

  3. pig 命名空间下,找到工作负载 pig-auth 右击并选择 Dev Config (开发配置)

  4. 将以下配置文件复制到 Dev Config 中。

# Deployment Name
name: pig-auth
serviceType: deployment
containers:
# Deployment 主容器名称
- name: auth
dev:
# 开发镜像,该镜像包含了 Java Maven 环境
image: registry.cn-hangzhou.aliyuncs.com/zqqq/maven:3.8.6-openjdk-8
# 默认终端为 bash
shell: bash
# Rainbond 提供的 StorageClass Name
storageClass: rainbondvolumerwx
# 配置开发容器资源
resources:
limits:
memory: 4096Mi
cpu: "2"
requests:
memory: 2048Mi
cpu: "1"
persistentVolumeDirs:
# Maven 依赖包缓存路径,配合 storageClass 一起食用
- path: /root/.m2/repository
capacity: 10Gi
command:
# 一键启动命令,安装依赖包和启动 pig-auth 子模块
run:
- mvn
- install
- '&&'
- mvn
- spring-boot:run
- -pl
# 指定子模块启动
- pig-auth
# 一键 Debug 命令,安装依赖包和 Debug pig-auth 子模块
debug:
- mvn
- install
- '&&'
- mvn
- spring-boot:run
- -pl
# 指定子模块启动
- pig-auth
# Java Debug 命令
- -Dspring-boot.run.jvmArguments=-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005
debug:
# 远程端口,对应Debug命令中的 address=5005
remoteDebugPort: 5005
# 选择 Java 语言
language: java
# 热加载
hotReload: true
# 文件同步
sync:
type: send
mode: gitIgnore
deleteProtection: true
# 端口转发,转发容器内的3000端口到本地3999
portForward:
- 3999:3000

一键 Run#

  1. 右击工作负载 pig-auth
  2. 选择 Remote Run。
  3. Nocalhost 会自动进入 DevMode 并执行 Remote Run。

一键 Debug#

  1. 右击工作负载 pig-auth
  2. 选择 Remote Debug。
  3. Nocalhost 会自动进入 DevMode 并执行 Remote Debug。
  4. 在代码中打上断点,发起请求,进入 IDE Debug 模式。

持久化配置#

在开发时,我们希望持久化的文件大多数都是 依赖包 日志,本篇文章中也是缓存了 Java 的依赖包。

rainbondvolumerwx 是 Rainbond 默认提供的存储类,填写以下配置后会在当前命名空间下自动创建 PVC,如下:

storageClass: rainbondvolumerwx
persistentVolumeDirs:
- path: /root/.m2/repository
capacity: 10Gi

容器资源限制#

限制开发容器的资源,限额能让服务器的资源利用最大化,可以通过以下开发配置修改:

resources:
limits:
memory: 4096Mi
cpu: "2"
requests:
memory: 2048Mi
cpu: "1"

端口转发#

转发容器端口到本地,可以通过以下开发配置修改:

portForward:
- 3999:3000 # 转发容器 3000 端口到本地 3999 端口

最后#

当然 Nocalhost 可以同时调试多个微服务,同样的方式只需修改配置文件中的 Deployment Name 和 Containers Name 以及微服务的子模块。

Nocalhost 还有一些开发配置文中没讲到的,比如:开发环境变量、文件同步的两种模式 pattern gitignore 等等,并且 Nocalhost 支持多种语言,Java 只是其中一种,小伙伴们可以自行探索。

Nocalhost + Rainbond 让开发、部署更加高效、便捷。

使用 Nocalhost 开发 Rainbond 上的微服务应用

Qi Zhang

Qi Zhang

Cloud Native Enthusiasts

本文将介绍如何使用 Nocalhost 快速开发 Rainbond 上的微服务应用的开发流程以及实践操作步骤。

Nocalhost 可以直接在 Kubernetes 中开发应用,Rainbond 可以快速部署微服务项目,无需编写Yaml,Nocalhost 结合 Rainbond 加速我们的微服务开发效率。

一. 简介#

Nocalhost 是一款开源的基于 IDE 的云原生应用开发工具:

  • 直接在 Kubernetes 集群中构建、测试和调试应用程序
  • 提供易于使用的 IDE 插件(支持 VS Code 和 JetBrains),即使在 Kubernetes 集群中进行开发和调试,使用 Nocalhost 之后也能够获得和本地开发一样的开发体验
  • 使用即时文件同步进行开发: 即时将您的代码更改同步到远端容器,而无需重建镜像或重新启动容器。

Rainbond 是一款云原生应用管理平台:

  • 使用简单,不需要懂容器、Kubernetes和底层复杂技术,支持管理多个Kubernetes集群,和管理企业应用全生命周期。主要功能包括应用开发环境、应用市场、微服务架构、应用交付、应用运维、应用级多云管理等。

二. 本地 + Rainbond 开发微服务#

在以往的开发模式中,我们在本地 + Rainbond 开发微服务时,要开发的模块我们运行在本地,其他模块运行在 Rainbond 上,我们通过 Rainbond 的网关与本地进行通信、联调。

这种场景下,我们有以下问题急需解决:

  • 多人协作开发联调困难
  • 本地环境差异化
  • 无法通过注册中心(Nacos)调用其他微服务
  • 远程Debug较难
  • 受限于本地资源

三. 使用 Nocalhost + Rainbond 开发微服务#

现在我们通过 Nocalhost + Rainbond 开发微服务时,所有服务都运行在 Rainbond 上,在开发过程中可以使用 VSCode 插件 Nocalhost 连接进入到 Rainbond 组件中,并将本地代码实时同步到 Rainbond 组件中。多人开发联调时,可通过 Rainbond 内置的 Service Mesh 进行服务之间调用。

使用 Nocalhost 开发,可以解决本地开发时遇到的问题:

  • 多人联调开发更便捷
  • 服务都运行在 Rainbond 上,不再受限于本地
  • 与生产环境更接近
  • 远程Debug
  • 通过注册中心(Nacos)调用其他微服务组件

四. 实践操作步骤#

Nocalhost 目前支持两种开发模式:

  • Replace DevMode
  • Duplicate DevMode

本篇将主要介绍 Replace DevMode,当进入 Replace DevMode 时,Nocalhost 会对 组件 执行以下操作:

  1. 将副本数缩减为 1
  2. 替换容器的镜像为开发镜像
  3. 增加一个 sidecar 容器。
  4. 转发一个本地端口到文件同步服务器。
  5. 启动本地文件同步客户端。
  6. 打开远程终端。

4.1 安装 Nocalhost 插件#

Nocalhost IDE 插件支持 VSCode JetBrains ,这里我们主要介绍 VSCode 插件安装参考官网文档。

  1. 打开 VSCode,点击左侧的 Extension 按钮 img 图标
  2. 在搜索框中输入 Nocalhost 选择 Nocalhost 插件,并点击 Install 按钮

4.2 安装 Rainbond#

我们选择 基于主机安装 Rainbond

4.3 Nocalhost 对接 Rainbond 集群#

  1. 获取 kubeconfig 文件,进入 Rainbond 集群视图 -> 点击节点配置 -> kubeconfig

  1. 我们将 kubeconfig 文件复制到本地并保存为 yaml 文件。

  2. 打开 VSCode,点击按钮 ,打开 Nocalhost 插件,选择 Connect to Cluster,选择我们 kubeconfig 文件的路径,点击 Add Cluster,添加集群。

  3. 添加完成后,如下图:

4.4 在 Rainbond 上部署 Spring Cloud 应用#

  1. 这里选择从开源应用商店安装 Spring Cloud Pig 微服务组件,在应用商店中搜索 Pig 进行安装。

  2. 部署完成后,效果如下:

4.5 进入 Nocalhost 开发模式#

上面我们已经在本地 VSCode 中对接好了集群,并且也已经在 Rainbond 中安装了 Spring Cloud Pig 微服务,那么接下来我们在本地 VSCode 中选择其中一个组件进行开发,这里为了效果更明显,选择开发 pig-ui 组件。

Spring Cloud Pig 后端

Spring Cloud Pig 前端

4.5.1 克隆 Pig-ui 代码到本地#

git clone https://gitee.com/zhangbigqi/pig-ui

4.5.2 启动本地开发#

打开 VSCode,点击按钮 ,找到我们的 Pig-ui 组件,由于该应用是从开源应用商店中安装,Deployment名称是自动生成的字符串,我们需要在组件中查询下。

我们点击旁边的🔨进入开发模式,

  1. 提示选择容器,我们选择 gred5f1c 这个容器。

    另外一个容器是 Rainbond 默认注入的 sidecar 容器,用于组件之间的内部通信。

  2. 提示指定源代码目录,选择我们刚刚克隆下来的代码目录。
  3. 等待片刻后,会默认打开远端容器的终端界面并且将本地项目的文件同步至容器内,如下:

4.5.3 启动项目#

  1. 安装项目依赖,执行
npm install
  1. 运行项目
npm run dev

启动后效果如下,容器内端口为 80

  1. 开启端口转发,点击按钮 ,找到我们的 Deployment,右键选择 Port Forward,Add Port Forward,输入 38000:80 将容器的80端口转发到本地的38000端口。
  1. 通过 http://localhost:38000 可以访问到页面,并且也可以正常登录。

4.5.4 修改代码查看效果#

上面已经演示了如果通过本地访问到远端容器内的服务,接下来我们修改代码看下效果。

修改 src/page/wel.vue,新增一段代码,保存。可以发现,当我们保存的时候,终端中就自动重启了,与本地开发效果一致。

文件的修改会实时同步到容器中。

刷新页面http://localhost:38000,可以看到修改的内容已生效。

写在最后#

通过以上的实践步骤,我们已经可以通过 Nocalhost 开发 Rainbond 上的微服务应用,进入云原生快速开发,提升我们的开发效率。

本文仅介绍了基本的开发,还可以为项目配置 Nocalhost开发配置 等等,小伙伴们可以自行探索。

How to debug microservices in Kubernetes with proxy, sidecar or service mesh?

Jimmy Song

Jimmy Song

Developer advocate at Tetrate

This blog is originally posted on Jimmy's Blog

How to debug microservices in Kubernetes with proxy, sidecar or service mesh?#

This article explains three patterns/tools for debugging microservices in Kubernetes and the changes brought by the introduction of Istio for debugging microservices.

Kubernetes is arguably the best environment for running microservices so far, but the experience of debugging microservices in a Kubernetes environment may not be as user-friendly. This article will show you how to debug microservices in Kubernetes, introduce common tools, and explain how the introduction of Istio impacts debugging microservices.

Debugging microservices is vastly different from traditional monolithic applications#

The debugging of microservices has been a long-standing problem for software developers. This challenge does not exist in traditional monolithic applications because developers can leverage the debugger in IDEs to add breakpoints, modify environment variables, single-step execution, etc. for their applications, all of which provide great help in software debugging. With the popularity of Kubernetes, the debugging of microservices becomes a thorny issue, where the following issues are more complicated than the debugging of traditional monolithic applications.

Multiple dependencies#

A microservice often depends on multiple other microservices, some shared volumes across multiple microservices, and authorizations based on service accounts. When debugging a microservice, how do you deploy other dependent services to quickly build a latest set of staging environments?

Access from a local machine#

When microservices are running on a developer’s local computer, there is usually no direct access to the services in a Kubernetes cluster. How can you debug microservices deployed in a Kubernetes cluster as if they were local services?

Slow development loop#

Usually, it takes a long process to update the code and build it into an image before pushing it to the cluster. How do you speed up the development cycle? Let’s look at the tools that address those challenges.

Tools#

The main solutions for debugging microservices in Kubernetes are:

  • Proxy: by building a VPN, deploying a proxy in the Kubernetes cluster, and adding local debug endpoints to make the services in Kubernetes directly accessible to local applications, your architecture will look like [ local service ] <-> [ proxy ] <-> [ app in Kubernetes ].
  • Sidecar: Inject a sidecar into the pod of the microservice to be debugged to intercept all traffic to and from the service, so that the service can be tracked and monitored, and the service can also be debugged in this sidecar.
  • Service Mesh: To get an overall picture of the application, inject sidecars into all microservices so that you can get a dashboard that monitors global status.

Here are three typical open source projects that implement the above solutions, each of which can help you debug microservices from a different perspective. You can apply them at different stages of software development and they can be said to be complementary to each other.

Proxy – debugging microservices with Telepresence#

Telepresence is essentially a local proxy that proxies data volumes, environment variables, and networks in a Kubernetes cluster locally. The following diagram shows the main usage scenarios for Telepresence.

Proxy mode: Telepresence

Users need to manually execute the telepresence command locally, which will automatically deploy the agent to Kubernetes. Once the agent has been deployed,

  • Local services will have complete access to other services in the Kubernetes cluster, environment variables, Secret, ConfigMap, etc.
  • Services in the cluster also have direct access to the locally exposed endpoints.

However, this approach requires users to run multiple commands while debugging locally, and in some network environments it may not be possible to establish a VPN connection to the Kubernetes cluster.

Sidecar – debugging microservices with Nocalhost#

Nocalhost is a Kubernetes-based cloud development environment. To use it, you just need to install a plugin in your IDE – VS Code to extend Kubernetes and shorten the development feedback cycle. The development environment can be isolated by creating different namespaces for different users and using ServiceAccount when binding to different user corners. Nocalhost also provides a web console and API for administrators to manage different development environments.

Sidecar mode: Nocalhost

As long as you have a Kubernetes cluster and have admin rights to the cluster, you can refer to the Nocalhost documentation to quickly start trying it out. To use the Nocalhost plugin in VS Code, you need to configure the Kubernetes cluster in the plugin first.

  1. Select the Kubeconfig file you just exported or copy and paste the contents of the file directly into the configuration.
  2. Then select the service you need to test and select the corresponding Dev Container. VS Code will automatically open a new code window.

Here is an example of the bookinfo sample provided by Istio. You can open the cloned code in your local IDE and click the hammer next to the code file to enter development mode. Selecting the corresponding DevContainer and Nocalhost will automatically inject a development container sidecar into the pod and automatically enter the container in the terminal, as shown in the following figure.

Nocalhost VS Code

In development mode, the code is modified locally without rebuilding the image, and the remote development environment takes effect in real time, which can greatly accelerate the development speed. At the same time, Nocalhost also provides a server for managing the development environment and user rights, as shown in the following figure.

Nocalhost Server

Service Mesh – debugging microservices with Istio#

The above method of using proxy and sidecar can only debug one service at a time. You’ll need a mesh to get the global status of the application, such as the metrics of the service obtained, and debug the performance of the service by understanding the dependency and invocation process of the service through distributed tracing. These observability features need to be implemented by injecting sidecar uniformly for all services. And, when your services are in the process of migrating from VMs to Kubernetes, using Istio can bring VMs and Kubernetes into a single network plane (as shown below), making it easy for developers to debug and do incremental migrations.

Service Mesh mode: Istio

Of course, these benefits do not come without a “cost.” With the introduction of Istio, your Kubernetes services will need to adhere to the Istio naming convention and you’ll need to know how to debug microservices using the Istioctl command line and logging.

  • Use the istioctl analyze command to debug the deployment of microservices in your cluster, and you can use YAML files to examine the deployment of resources in a namespace or across your cluster.
  • Use istioctl proxy-config secret to ensure that the secret of a pod in a service mesh is loaded correctly and is valid.

Summary#

In the process of microservicing applications and migrating from virtual machines to Kubernetes, developers need to make a lot of changes in their mindset and habits. By building a VPN between local and Kubernetes via proxy, developers can easily debug services in Kubernetes as if they were local services. By injecting a sidecar into the pod, you can achieve real-time debugging and speed up the development process. Finally, the Istio service mesh truly enables global observability, and you can also use tools like Tetrate Service Bridge to manage heterogeneous platforms, helping you gradually move from monolithic applications to microservices.

Redefine Cloud Native Dev Environment

Wang Wei

Wang Wei

Nocalhost Core Team

Preface#

With the rapid development of business, the organizational structure of the technical department has been continuously expanded and adjusted horizontally and vertically. At the same time, the enterprise's production materials: application systems, have also become larger and larger. In order to adapt the application system to the adjustment of the enterprise organizational structure and sort out the boundaries of the organizational structure for application rights and responsibilities, most organizations will choose to use the "microservice" architecture to split the application system horizontally, so that the maintenance boundary of the application system is adapted The power and responsibility boundary of the organizational structure.

Generally speaking, the larger the organizational structure, the more detailed the application system will be, and the number of "microservices" will also increase. In the practice of splitting "microservices", it is easy to mark the authority and responsibility boundaries of the organizational structure into the splitting granularity of "microservices", which may lead to too fine granularity of "microservices". The problem of further sharp increase in number. In the end, the calling relationship between "microservices" is like cross-departmental collaboration, and it has become more and more complex. The problem is particularly prominent when you want to add new requirements.

While "microservices" bring convenience, it also brings additional challenges for developers: how to quickly start a complete development environment? The development requirements depend on how other colleagues can coordinate and debug? How to quickly debug these microservices?

For managers, it also brings a series of challenges: how to manage the development environment of developers? How to let new colleagues quickly develop?

Imagine what difficulties would you encounter when developing a cloud-native application consisting of 200 "microservices"?

Localhost era#

In the era of monolithic applications, it is extremely friendly to developers. Developers use the local machine to run the application, modify the code to take effect in real time, and visit Localhost through a browser to view the code effect in real time.

Monolithic applications are different from "microservices" applications. Monolithic applications are organized as "ALL-IN-ONE". All calling relationships are limited to their own classes and functions, and the hardware requirements of applications are generally not too high.

The development of "microservice" applications is quite different. Due to the mutual dependence, when a certain function or microservice needs to be developed, all dependent services have to be activated. With the increase in the number of microservices, more and more local resources are needed to develop applications, which ultimately leads to the local inability to meet the configuration requirements of development.

Cloud Native liberates deployment and operation, What about development?#

The popularity of cloud native and Kubernetes further shields the complexity of "microservice" applications, which is mainly reflected in the deployment and operation and maintenance stages.

In order to solve the problem of environmental consistency in the development, testing, and production stages of microservice applications, modern microservice application development will package each component into a Docker image and deploy it in the form of workload. Using continuous integration and continuous deployment in the DevOps pipeline, combined with Kubernetes probes, HPA, and application self-healing capabilities, completely liberated the deployment and operation and maintenance of microservice applications.

But we overlooked a key node: the development phase.

After microservice applications are packaged with Kubernetes workloads, the problem of rapid application startup in the development process is solved. Developers only need to install a single-node Kubernetes cluster locally, such as Minikube, Kind, etc., to quickly start microservice applications.

But for developers, the original monolithic application development experience no longer exists. Since the application is difficult to run outside of the Docker container, each code modification needs to go through the following steps:

  • Execute docker build to build the image
  • Execute docker tag to tag the image
  • Execute docker push to push the image to the warehouse
  • Modify the image version of the Kubernetes workload
  • Wait for the mirror pull to end
  • Wait for the Pod to rebuild
  • View the modified code effect

This directly slows down the cyclic feedback process of development, and each modification requires several minutes or even ten minutes of waiting time.

Redefine Cloud Native Dev Environment#

Nocalhost is a Cloud Native development environment, hoping to make developing cloud-native applications as primitive and simple as developing a single application.

Nocalhost reorganized the roles and resources involved in the development process:

  • Team manager
  • Developer
  • Application
  • Cluster
  • Development Space

Through the reintegration of these roles and resources, Nocalhost redefines the cloud-native development environment and brings a new cloud-native development experience.

In order to quickly understand the cloud-native development environment redefined by Nocalhost, let us first stand in different roles and see what Nocalhost can bring to them.

Developer:

  • Get rid of the need to rebuild a new image for each modification and long-term loop feedback, and the modified code will take effect immediately.
  • One-click deployment of the development environment, get rid of the limitations of local environment construction and insufficient resources.
  • Link between local IDE editor and development environment, support remote debugging.
  • Graphical IDE plug-in, no need to be familiar with kubectl commands to complete development in cloud native environment.

Manager:

  • Unified management of microservice application packages, reducing application maintenance costs.
  • Unified management of the development environment and cluster, improve the utilization of cluster resources, and have isolation characteristics.
  • Quickly allocate development environment for new employees, and application development can be carried out immediately after the allocation of the environment.
  • Flexible development environment resources can be destroyed when used up, reducing development costs.

Quick Start#

Try to use Nocalhost for the easier and faster cloud-native application development

Taking Nocalhost's built-in Demo: Bookinfo as an example, the development of Productpage microservices has become the following simple steps:

  1. Connect to remote Kubernetes cluster by click
  2. Select the workload that need to develop, enter development mode
  3. Nocalhost IDE plugin will automatically sync the source code to remote DevContainer
  4. Change the code and see the change under seconds without rebuild image or restart remote POD.

Landing case#

Currently, Tencent Cloud CODING DevOps (nearly 200 microservices) is using Nocalhost for development. Practice has verified that Nocalhost can greatly improve development efficiency and shorten feedback loops.

Open source and community co-construction#

Nocalhost is currently fully open source and has entered CNCF Landscape: https://landscape.cncf.io/

Our Github Repo.

We are using Apache-2.0 open source agreement, can use unlimited free.

For more information about Nocalhost, please visit our documentations.