“Online development of the whole process” has been gaining popularity in recent years, such as the practice of AWS in C9, the well-known TheiaJS in the open source sector, the up-and-comer Code-Server and the industry leader VS Online. I personally and my team have also made in-depth exploration and practice of “online development process”, from ignorant and confused at the beginning to clear goals now.

Since WebIDE speak.

The group’s construction of WebIDE can be said to have started late, when the industry has a complete solution of TheIA-IDE, Coding.net own CloudStudio business model, we are still in the internal construction stage. But on the plus side, our IDE-based technology sector and related tool platforms have sprung up in recent days:

Studio,
*

After 18 years of investigation, our team decided to carry out upper-level encapsulation based on Ds **Studio to meet business needs, but later it was no longer suitable to give up for various reasons.

In 19 years, with the support of open-source code-Server) and cloud native Kubernetes, we created a YunIDE by ourselves. Since it takes a lot of energy to schedule and maintain the IDE bottom layer, it is also difficult for a business team to realize. Migration was also selected after the first iteration was completed.

And finally we are based on

*

Dawn tools

Self-built processes and challenges

Basically WebIDE consists of three parts:

  • Client: The Client is also the most important side, porting native functions such as code editing to the browser.
  • Server: The Server is also the control end, including the management of data interaction and resource scheduling.
  • Container Pool: At runtime, the Container environment in which user code actually runs. The most typical architecture among the three is shown below:

Code-server solves the Client side problems to a large extent. It is redeveloped based on VSCode. In terms of experience and some basic editor issues, we no longer spend time refactoring and focus on the server side and the Container Pool.

Server Design

YunIDE has been designed for the cloud from the very beginning, so when discussing the architecture, more power lies in the use of cloud infrastructure & open source tools in the industry, so it is different from most WebIDE practices in The user rights system, container resource scheduling, code file persistence and other issues. A large view of the early architecture:

By the end of the first iteration of YunIDE, the whole server-side development was quite challenging for me, especially the part of “resource scheduling & Orchestration”, which required a deep understanding of containers and Kubernetes, as well as certain understanding and experience of cloud resources, network environment and middleware of the group’s existing infrastructure. WebIDE resource scheduling itself is a process of pursuing limits (who doesn’t want their IDE to start cold faster), and even a little bit of knowledge blindness can cause an avalanche of negative effects.

Editor & IPC

On the editor side, we maximized the implementation of Coder/VSCode. That’s why YunIDE is more comfortable and grounded than TheiaIDE in its initial motion, and it can obtain almost unlimited imagination space by inheriting the extension system of VSCode. The functionality of our extension is also implemented through vscode extensions. Unlike third-party extensions, built-in plug-ins cannot be removed.

In addition to the work done by code-server in IPC layer, YunIDE does proxy and Hack on socket IPC in HTTP application layer, and makes corresponding authentication and application layer adaptation.

Key question

Resource utilization: Reasonable arrangement and maximum utilization of resources is always the goal we pursue. In weak editing scenarios (coding only without debugging preview), how to share resources without maintaining isolation:

Ensure high availability: Shorten the runtime life cycle while ensuring that user code files are not lost. Ideally, the runtime container would be configured dynamically by the number of socket connections, but the technical cost of implementation is currently too high and the destruction cycle can only be calculated in hours per day. Using NFS to mount user workspaces, user data is independent of runtime conditions, enabling data recovery.

Startup speed optimization: Completely cold startup: it is difficult to optimize for unknown mirrors, but it can be done within 1 minute in vertical scenarios. Preset Container pool + Container Buffer: Good experience, but a certain amount of waste.

Plug-in ecology: VSCode official plug-in system is perfect enough, but there is still room for improvement, and in the background of the group’s front and back end technology blooming, the interface is not strong enough to customize defects are highlighted (the solution based on TheiaIDE is more flexible), VSC official plug-in market is open to use, However, it cannot be used directly due to protocol and other issues.

Since then, there have been too many opportunities and challenges on the road to build WebIDE, and there has been a considerable degree of technology precipitation. Gradually, we consider to quickly implement business scenarios to the group infrastructure, and then there is the following basis

*

The whole process of online campaign

Based on the group’s existing infrastructure such as

IDE/K

The environment custom

As with almost all WebIDE environment preparations, the development runtime does this out of the box by building corresponding images. As our team built up a lot of front-end infrastructure, such as Dawn scaffolding, cloud queries, XCloud, etc., it became more demanding when it came to customizing the environment.

Through the QTOKEN authorization system of the front cloud query on the Web side, we can get the user identity in the terminal environment of WebIDE, and even call many interfaces requiring permission verification through the user identity. This greatly expands our operability. For example, it is easy to implement build release control, daily error collection, accurate question answering and so on through user identity:

At the same time, some common permissions of team public accounts are integrated in the image. Many weak permissions are managed and maintained by unified public accounts, such as GitGroup authorization, NPM package release, iterative associated work items and so on.

Plug-in development

Based on the

*

We did a number of optimizations when we clicked preview:

  • Since the plug-in runs on the browser side, it sends instructions to the container side through socket to query the currently available port when clicking “Preview”.
  • To rule out
    *

    * Ports used by IDE and plug-in itself, excluding external inaccessible (0.0.0.0), excluding ports opened by non-Node processes, the rest is basically our target port, the actual use of the experience is also relatively good.

  • Use the built-in rules (warehouse, staff info, project info) to determine the domain name to use for the actual preview, thanks
    *

    * With support from the IDE team, we can currently preview development under three domains.

docking

*

Local solution:

  • Start the dev server
  • Bind hosts local.foo.aliyun.com to obtain the login status synchronization interface of the official website
  • Open a browser

WebIDE plan 1:

  • Dev Server is started when the container runs
  • Bind hosts local.foo.aliyun.com to the container IP address

WebIDE scheme 2:

  • Dev Server is started when the container runs
  • Provide the unified domain name preview.ide.alibaba-inc.com and distinguish different Spaces by pathName

WebIDE solution 3:

  • Dev Server is started when the container runs
  • Provide variable pan-domain to isolate different Spaces [uniqueId]-[port]. Id *io.aliyun.com

Solution 1 can effectively solve the problem, but it is very troublesome. Users need to manually bind Hosts and bind them again after the IP address of the container changes. From the perspective of products, this solution is not mature, but it can be regarded as a degradation solution.

Solution 2 cannot solve the problem of front-end development, and cannot deal with the diversity of resource introduction in HTML. For example, the behavior of SRC =”/index.js” and SRC =”index.js” is inconsistent, which easily leads to the failure of resource loading and page preview.

Solution 3 perfectly solves the above problems, but the expansibility is limited. Every time a new service domain is added, it is necessary to apply for another pan-domain name.

Finally, the project preview looks like the following picture:

Project initialization

Since this is an I2P campaign, there will be a lot of init, which is a simple one-line command locally, but not in the cloud.

  • At the beginning of the slash-and-burn era, we maintained the K8S cluster of the test environment ourselves and used Jobs to complete the init operation.
  • Later due to too much trouble, migrated to ECI.
  • Finally, ECI did not go through the “mirror warm-up”, resulting in a long initialization time (1-3 min), and then migrated from ECI to other orchestration systems.

Finally, the successful practices of I2P were applied to other BU and other teams to help other business scenarios quickly achieve “whole process online”.

Scene landing

In the process of moving from ignorance to certainty, we learned this: find your vertical scene and shine. We avoid thinking of WebIDE as a big, complete system, but as a small, beautiful tool. Here are the areas where we’ve put down roots:

  • XCloud VC component development: low code materials in the background
  • Hongmeng ACE/ international station component development: marketing building materials
  • Dawn engineering: For outsourcing students and other rapid development scenarios
  • Fast project development in cloud Query FaaS: Serverless scenario

Different compatibility is made for each different field at the level of mirror, plug-in and so on. The overall entrance converges to XCloud, and finally completes the scene implementation of WebIDE. Meanwhile, many positive praise has been received:

We are fighting the epidemic. We are acting

Affected by the epidemic, many students cannot resume work normally. WebIDE is particularly important to solve the development environment problems of outsourced students. We also attach great importance to it, actively improve functions, maintain stability and answer questions at any time. From “installing the environment almost all day long” to “opening the browser and developing WebIDE online”, it is truly “out of the box”.

The following figure shows the process from XCloud into a development project:

The last

Any objections to the content of the article are welcome to be corrected.

A large number of front end team in Taiwan HC waiting for you, welcome to contact: [email protected]




Read more: https://yqh.aliyun.com/detail/6958?utm_content=g_1000107306

On the cloud to see yunqi: more cloud information, on the cloud case, best practices, product introduction, visit: https://yqh.aliyun.com/