Recently, Tencent Cloud CODING DevOps opened source the cloud native development environment – Nocalhost.

Nocalhost comes from No Localhost, which means that developers are No longer dependent on the local computer for coding, debugging, and testing. It is a cloud native development environment, designed to solve the problem of cloud native development.

For example, microservice development in the Kubernetes environment typically faces the following problems:

  • Every time you change the code, you need to build the image -> push the image -> pull the image -> restart the application (Pod), developing a very long feedback loop (more than 10 minutes);
  • In order to develop a microservice, the entire environment and all microservices must be launched locally, which creates the problem of over-reliance on local resources;
  • Developers focus on their own services, and as iterations go on, it becomes increasingly difficult to launch or update a full development environment locally;
  • It is difficult to control the dependencies and startup sequence among microservices.
  • New employees generally need 2-3 weeks to familiarize themselves with the setup of the development environment and learn the background knowledge

So how does Nocalhost solve these problems? What impact will Nocalhost’s open source bring to the K8s ecosystem? With these questions in mind, we talked with Wang Wei from Tencent Cloud CODING DevOps, one of Nocalhost’s designers, a new CNCF ambassador and a member of the cloud native community, about Nocalhost’s products, technology and ecology in detail.

guests

The following is the transcript of the interview:

Q: Let me start by telling you about the origin of Nocalhost

Wang Wei: The origin of Nocalhost is to solve the problem that CODING itself is difficult to develop. CODING has embraced microservices, cloud native and Kubernetes in the early stage. However, in our daily development process, we found that Kubernetes solved the problems of deployment and operation and maintenance, but also brought the problems of development difficulty.

The most typical sore spot is the long process of having to rebuild the image -> push the image -> change the version of the workload image -> wait for the Pod to rebuild every few lines of code to be written to see how the code works or to debug. The core of this process remains the same, although some manual running problems can be solved with automated CI/CD.

In addition, the resources required for the local full operation of CODING were very high, and early developers had to be equipped with an 8-core 64G computer to develop CODING. Later, they also tried to provide a remote high-configuration development machine for everyone, but the development efficiency was still not improved.

We started exploring solutions for this scenario and eventually open-source the practice as the Nocalhost project.

Q: In the cloud native environment, are there any other pain points in practice other than having to rebuild the image every time you code?

< Wang Wei > : Very many pain points! For back-end students, it takes a lot of time and energy to get familiar with and configure the development environment from the beginning. In addition, when the development environment is set up with great difficulty, a large number of microservice components cannot be started when they need to be updated. Of course, this is probably more of an application management issue, and there are good application model practices in the community today.

The problem is that it is very difficult to maintain this application model uniformly, and if it is used in very low frequency scenarios, the problem will be exposed later and later, and ultimately will be no different from unmanned maintenance. All developers have separate environments, and problems are solved by themselves rather than by updating the application model, which further results in older versions of the application.

Therefore, we consider that the development environment must be centrally managed. The deployment source of the development environment can only be an independently maintained application model, and the service groups cooperate in the maintenance and produce a deploy-modify cycle effect to achieve consistent application management.

Q: So does Nocalhost manage the application and development environment?

< Wang Wei > : Yes. Application management is the use of external standards such as Manifest file composite application, Helm application, Kustomize application, etc. It is the standard installation method for pulling up the development environment. The development environment of different developers is defined as DevSpace in Nocalhost. Currently, Namespace is used for isolation and management, and different development Spaces will support collaborative development in the future. The management of applications and development space can be done from the Nocalhost console.

Q: What are the components of Nocalhost?

< Wang Wei > : Nocalhost is mainly composed of these components:

  • Management side (managers facing the development environment)

    • Nocalhost console: provides developer management, application management, development space management and other functions
      • Nocalhost Dep component: provides application dependency management and controls the startup sequence of microservice dependencies

  • User side (Developer)

    • NHCTL -cli: Nocalhost command line tool, which provides complete functions
      • IDE plug-ins: VS Code plug-ins and JetBrains plug-ins are available

Nocalhost working diagram:

Q: What is the most intuitive experience for developers to use Nocalhost?

< Wang Wei > : For developers, the most intuitive experience is that the development process is very simple. From deployment to development, there are only four simple steps on the IDE plug-in:

  1. Pull up the development environment with one click

  2. Click “Hammer” to enter “Development Mode” for the component to be developed

  3. Write code in the local IDE, save

  4. Without rebuilding the image, the new code takes effect directly in the remote container

When using Nocalhost for service development, the complex background knowledge required for development is shielded, and only the language development foundation is required, the business code development can be carried out immediately.

At present, the fastest practice of CODING is that the new students who have just joined the job have submitted the business code in the afternoon after receiving the demand at noon. What was exciting was that he was faced with the need to create a system of over 100 microservices, all without knowing anything about the CODING microservice architecture, the development environment, or even the repository address of the business code (Nocalhost had been pre-configured). This would have been unthinkable under previous development models.

Q: For example, if I have a business system, how can I use Nocalhost?

< Wei > : For the existing business system, first confirm whether it is the Kubernetes standard application installation mode, such as Manifest, Helm and Kustomize.

Second, Nocalhost does not intrude on any business logic and only needs to provide development parameter configurations in a declarative way, such as Bookinfo, which Istio provides.

Here is the Git repository for the Bookinfo installation file: github.com/nocalhost/b…

The directory structure of the repository is shown below.

Where the manifest/templates directory contains an installation file of the Bookinfo manifest type:

When we have an application, we can create.nocalHost /config.yaml for the repository to provide development parameters for nocalHost. For example, here are some of the development parameters for the Bookinfo application and the ProductPage service:

ConfigProperties: version: v2 Application: name: bookInfo # RawManifest # Apply the Manifest directory resourcePath: [" Manifest /templates"] ignoredPath: [] onPreInstall: [] services: DependLabelSelector: jobs: dependLabelSelector: jobs: dependLabelSelector: jobs: dependLabelSelector: jobs: dependLabelSelector: Jobs: dependLabelSelector: Jobs: dependLabelSelector: Jobs: - "dep-job" containers: -name: productpage # Install: portForward: -39080:9080 dev: # https://e.coding.net/codingcorp/nocalhost/bookinfo-productpage.git # define development mirror image: Bash shell codingcorp-docker.pkg.coding.net/nocalhost/dev-images/python:3.7.7-slim-productpage # define into the development of container: Sync: type: send filePattern: -./ ignoreFilePattern: - ".git" # development mode automatic portForward: -39080:9080Copy the code

In this configuration file, we provide some development parameters for the ProductPage service for Nocalhost. Finally, create the application through the Nocalhost console and provide the repository address.

With the above configuration, applications can be seamlessly migrated to Nocalhost for development.

Q: What’s next for Nocalhost?

< Wang Wei > : Nocalhost has almost fully covered CODING daily development at present, but there is still a lot of room for optimization.

Like its Slogan, Nocalhost’s original intention was to bring cloud native development back to primitive and simple. We hope to provide exploration and demonstration for cloud native development environment and become an indispensable part of cloud native ecology.

At present, Nocalhost has entered CNCF Landscape, and further cooperation with CNCF will be promoted in the future.

Q: Can you talk about the development trend of cloud native in China and your personal opinion?

Wang Wei: According to Gartner research report, the penetration rate of cloud native and containerization will reach more than 75% by 2022, which means that the trend of cloud native has become a foregone conclusion. As a powerful infrastructure base, the K8s provides extremely strong production stability for enterprise applications.

However, as we used K8s more and more, we found that the K8s’ “workload-oriented” design needed to be improved in some scenarios. Around the focus of these issues, the community continues to make plug-in extensions for K8s. There are nearly 400 open source products in CNCF Landscape that provide additional capabilities for K8s. These technical directions are roughly divided into database, messaging, application definition and mirror building, and the number of products is still increasing.

As far as K8s ecological development is concerned, I think there are two major directions that need to be solved by the community: the first is the application definition model, which represents OAM standard and Kubevela. This direction is closely related to DevOps and GitOps. The second is app development, which has been neglected. Both directions are key to improving the efficiency of large-scale organization development.

In app development in particular, there are still no standards or good practices, and I’m sure there will be standards in the community.

Finally, welcome to join the Cloud Native community and participate in the Nocalhost discussion. In addition, Nocalhost is recruiting, and we also welcome students who are interested in cloud native field to join us.