Container terminal session management method and system suitable for cloud native architecture

Abstract

The invention provides a container terminal session management method and system suitable for a cloud native architecture. The method comprises the steps that a server verifies login information of a user; creating a terminal session; according to a container name, searching a Pod in a running state, starting a background coroutine, waiting for a SockJS to be connected with a client, binding the client with a terminal device, starting a specified shell command, obtaining an interactive TTY session, and connecting user input and output to a terminal session; and managing the state of each terminal session. According to the method, remote terminal access of the container instance is realized through WebSocket and SockJS, low-delay communication and full-duplex communication are realized, and stable connection can still be kept under the condition of network instability or high delay; the data security is ensured; only authorized users can access the terminal; multiple container types and operating systems are supported, and a unified access interface is provided; the connection stability, safety, reliability and compatibility are improved, and the user experience is improved.

Description

Technical Field

[0001] The present invention relates to the field of remote terminal access technology, and in particular to a container terminal session management method and system suitable for a cloud native architecture. Background Art

[0002] With the popularity of cloud computing and containerization technology, more and more applications are running in container environments. To facilitate the management and debugging of these containers, remote terminal access has become an important function. Existing remote terminal solutions mainly include SSH-based connections, Web terminals, and WebSocket technologies.

[0003] SSH-based connection is to connect to the container host through the SSH protocol, and then run commands through the container to enter the container. Although this method is simple and reliable, it requires additional configuration and management, and does not support the web interface, which has a poor user experience.

[0004] In addition, existing solutions for remote terminal access to container instances have the following problems:

[0005] 1. Existing SSH-based connections and simple WebSocket implementations have poor connection stability, which is mainly manifested in high latency sensitivity, high resource consumption, and low flexibility. For example, they lack heartbeat and reconnection mechanisms, and are easily disconnected when the network is unstable or has high latency, resulting in a poor user experience.

[0006] 2. There are security risks in the process of identity authentication and data transmission, which can be easily exploited by malicious attackers and are not secure enough.

[0007] 3. Incomplete support for different types of containers and different operating systems and poor compatibility limit its scope of application.

[0008] 4. Existing SSH-based connections require additional configuration and management, and the user experience is poor. Summary of the invention

[0009] In view of this, the purpose of the present invention is to propose a container terminal session management method and system suitable for cloud native architecture, which realizes remote terminal access to container instances through WebSocket and SockJS technologies, realizes low-latency communication and full-duplex communication, ensures stable connection in unstable network or high-latency conditions, adopts HTTPS and TLS protocols for data transmission, and ensures data security; at the same time, through the identity authentication mechanism, it is ensured that only authorized users can access the terminal; supports multiple container types and operating systems, and provides a unified access interface; improves the stability, security, reliability and compatibility of terminal session connections, and enhances user experience.

[0010] The present invention provides a container terminal session management method applicable to a cloud native architecture, comprising the following steps:

[0011] S1. The server verifies the user's login information and creates a terminal session.

[0012] The present invention ensures that only authorized users can access the terminal through an identity authentication mechanism, thereby solving the security deficiencies of existing solutions.

[0013] S2. According to the container name, find the Pod in the running state, start the background coroutine, wait for SockJS to connect to the client, bind the client to the terminal device, start the specified shell command, obtain an interactive TTY (terminal device) session, and connect the user input and output to the terminal session;

[0014] S3. Manage the status of each terminal session.

[0015] Furthermore, the method of connecting the SockJS client in step S2 and binding the client to the terminal device includes the following steps:

[0016] S21. The client processes the SockJS connection and creates a terminal session by calling the createContainerShell API, passing in the container name and command.

[0017] For example, the front-end code for the client to process the SockJS connection is as follows:

[0018]

[0019] S22, the client obtains the session ID of the terminal session, and binds the terminal device session through the session ID. When the SockJS connection is successfully established, the client sends a binding message;

[0020] S23, the client monitors the onConnectionMessage event, receives the message from the server, and processes it accordingly according to the message type;

[0021] S24. When the SockJS connection is closed, the client performs cleanup operations.

[0022] Furthermore, the method for creating a terminal session in step S1 includes:

[0023] The server verifies the client's login information through the GIN middleware. After the login information verification and authentication is successful, the logged-in user information is set to the context, a unique terminal session ID is generated, the terminal session is initialized, and stored.

[0024] Furthermore, the state of the terminal session in the state of managing each terminal session in step S3 includes: session ID, binding channel, socket session and terminal size change queue.

[0025] Furthermore, the step S2 of connecting the user input and output to the terminal session includes:

[0026] HTTPS and TLS protocols are used for data transmission to ensure data security.

[0027] The present invention also provides a container terminal session management system applicable to a cloud native architecture, which is used to implement the container terminal session management method applicable to a cloud native architecture as described above, including:

[0028] The server creates a terminal session module: used by the server to verify the user's login information and create a terminal session;

[0029] SockJS connection module: used to find the running Pod according to the container name, start the background coroutine, wait for SockJS to connect to the client, bind the client to the terminal device, start the specified shell command, obtain an interactive TTY session, and connect the user input and output to the terminal session;

[0030] Terminal session status management module: used for managing the status of each terminal session.

[0031] Specifically, the container terminal session management system suitable for cloud native architecture of the present invention is a container instance remote terminal access system based on WebSocket and SockJS, including the following core components:

[0032] API routing based on GIN framework;

[0033] / shell / :name: Used to create a new terminal session. The name parameter indicates the name of the container instance.

[0034] : Used to handle WebSocket connections, using a two-way communication protocol to achieve real-time communication.

[0035] Specifically, the client creates a terminal session by calling the / shell / :name interface and then calls To achieve communication, terminal device session binding is performed through sessionID.

[0036] Furthermore, the SockJS connection module includes:

[0037] The client creates a terminal session submodule: used by the client to process SockJS connections. The client creates a terminal session by calling the createContainerShell API and passing in the container name and command.

[0038] Client binding terminal submodule: used by the client to obtain the session ID of the terminal session, and to bind the terminal device session through the session ID. When the SockJS connection is successfully established, the client sends a binding message;

[0039] Client receiving message submodule: used by the client to listen to the onConnectionMessage event, receive messages from the server, and process them accordingly according to the message type;

[0040] Close connection submodule: used for the client to perform cleanup operations when the SockJS connection is closed.

[0041] The present invention uses WebSocket and SockJS technology to ensure that a stable connection can be maintained even when the network is unstable or has high latency. SockJS technology has the following two specific advantages:

[0042] 1. Mechanisms to achieve low-latency communication:

[0043] In today's era of information explosion, users have higher and higher expectations for the response speed of network applications. Whether it is online games or instant messaging software, any delay may seriously affect the user experience. SockJS came into being in this context. SockJS has successfully achieved low-latency communication through a series of innovative technical means. First of all, SockJS uses a variety of transmission methods to simulate the functions of WebSocket, including AJAX long polling, HTML5 history API, etc. These methods have their own strengths and characteristics, but the common point is that they can provide an experience similar to WebSocket in browsers that do not support WebSocket. More importantly, SockJS has a built-in intelligent selection mechanism that can automatically select the optimal transmission method according to the current browser environment. According to statistics, as of the beginning of 2023, about 5% of users are still using browser versions that do not fully support WebSocket. This feature of SockJS undoubtedly provides great convenience for these users, ensuring that they do not have to worry about compatibility issues while enjoying low-latency communication. In addition, SockJS also supports a heartbeat detection mechanism, which maintains the active state of the connection by sending heartbeat packets regularly, further reducing communication delays.

[0044] 2. Mechanism for achieving full-duplex communication:

[0045] Full-duplex communication means that data can be transmitted in both directions at the same time. Full-duplex communication is of vital importance to the needs of real-time applications. SockJS, through its unique design, ensures full-duplex communication even in cross-domain situations. When the client establishes a connection with the server, SockJS will automatically select the transmission method that best suits the current environment, whether it is WebSocket or other alternatives, to ensure the two-way flow of data. Therefore, developers can easily achieve full-duplex communication without worrying about the differences between different browsers. In addition, SockJS also has good cross-domain communication capabilities, allowing clients and servers under different domain names to communicate smoothly. This feature not only simplifies the development process, but also improves the overall performance of the application. By automatically detecting and adapting to the best transmission method for the current environment, SockJS provides developers with a nearly perfect WebSocket alternative, making it easier and more efficient to build high-performance, real-time interactive network applications.

[0046] The present invention supports multiple container types and operating systems, provides a unified access interface, and has good compatibility.

[0047] The present invention provides remote terminal access through a Web interface, and the user experience is good.

[0048] Although you can also consider using gRPC to replace WebSocket and SockJS to achieve remote terminal access, but the learning curve of gRPC is steeper, and its support on the Web front end is not as extensive as WebSocket. Although you can also consider using WebRTC to implement remote terminal functions, such as audio and video support, the implementation of WebRTC is more complex and has higher requirements for the network environment.

[0049] In summary, the present invention does not adopt gRPC and WebRTC technologies, but realizes remote terminal access to container instances through WebSocket and SockJS technologies, which has the advantages of stable connection, safe and reliable, strong compatibility and good user experience.

[0050] The present invention also provides a computer-readable storage medium having a computer program stored thereon, and when the program is executed by a processor, the steps of the container terminal session management method applicable to a cloud native architecture as described above are implemented.

[0051] The present invention also provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, the steps of the container terminal session management method applicable to a cloud native architecture as described above are implemented.

[0052] Compared with the prior art, the present invention has the following beneficial effects:

[0053] The container terminal session management method and system suitable for cloud native architecture provided by the present invention realize remote terminal access to container instances through WebSocket and SockJS technologies, realize low-latency communication and full-duplex communication, ensure stable connection under network instability or high latency conditions, adopt HTTPS and TLS protocols for data transmission to ensure data security; at the same time, through the identity authentication mechanism, ensure that only authorized users can access the terminal; support multiple container types and operating systems, and provide a unified access interface; improve the stability, security, reliability and compatibility of terminal session connection, and enhance user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the following detailed description of the preferred embodiment.The drawings are only for the purpose of illustrating the preferred embodiments and are not to be construed as limiting the invention.

[0055] In the attached picture:

[0056] Figure 1-3 It is an actual page diagram of the container terminal session management system applicable to the cloud native architecture according to an embodiment of the present invention;

[0057] Figure 4 It is a flow chart of the container terminal session management method applicable to the cloud native architecture of the present invention;

[0058] Figure 5 A flow chart of a method for connecting a client to a SockJS client and binding a terminal device according to an embodiment of the present invention;

[0059] Figure 6 The figure is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0060] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. Instead, they are merely examples of devices and products consistent with some aspects of the present disclosure as detailed in the appended claims.

[0061] The terms used in this disclosure are for the purpose of describing specific embodiments only and are not intended to limit the disclosure. The singular forms of "a", "said" and "the" used in this disclosure and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0062] It should be understood that although the terms first, second, third, etc. may be used in the present disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of the present disclosure, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0063] The embodiments of the present invention are described in further detail below.

[0064] The embodiment of the present invention provides a container terminal session management method applicable to a cloud native architecture, such as Figure 4 As shown, the following steps are included:

[0065] S1. The server verifies the user's login information and creates a terminal session.

[0066] There are several ways to create a terminal session:

[0067] The server verifies the client's login information through the GIN middleware. After the login information verification and authentication is successful, the logged-in user information is set to the context, a unique terminal session ID is generated, the terminal session is initialized, and stored.

[0068] This embodiment ensures that only authorized users can access the terminal through an identity authentication mechanism.

[0069] S2. According to the container name, find the Pod in the running state, start the background coroutine, wait for SockJS to connect to the client, bind the client to the terminal device, start the specified shell command, obtain an interactive TTY (terminal device) session, and connect the user input and output to the terminal session;

[0070] SockJS connects to the client, and the method for the client to bind the terminal device includes the following steps (such as Figure 5 shown):

[0071] S21. The client processes the SockJS connection and creates a terminal session by calling the createContainerShell API, passing in the container name and command.

[0072] In this embodiment, the front-end code for the client to process the SockJS connection is as follows:

[0073]

[0074] S22, the client obtains the session ID of the terminal session, and binds the terminal device session through the session ID. When the SockJS connection is successfully established, the client sends a binding message;

[0075] S23, the client monitors the onConnectionMessage event, receives the message from the server, and processes it accordingly according to the message type;

[0076] S24. When the SockJS connection is closed, the client performs cleanup operations.

[0077] Connecting user input and output to a terminal session involves:

[0078] HTTPS and TLS protocols are used for data transmission to ensure data security.

[0079] S3. Manage the status of each terminal session.

[0080] The state of each terminal session in managing the state of the terminal session includes: session ID, binding channel, socket session and terminal size change queue.

[0081] The embodiment of the present invention also provides a container terminal session management system applicable to a cloud native architecture, which is used to implement the container terminal session management method applicable to a cloud native architecture as described above, including:

[0082] The server creates a terminal session module: used by the server to verify the user's login information and create a terminal session;

[0083] SockJS connection module: used to find the running Pod according to the container name, start the background coroutine, wait for SockJS to connect to the client, bind the client to the terminal device, start the specified shell command, obtain an interactive TTY session, and connect the user input and output to the terminal session;

[0084] Terminal session status management module: used for managing the status of each terminal session.

[0085] like Figure 1-3 As shown in the figure, the system page provides a console click button. The client creates a terminal session by calling the / shell / :name interface and then calls To achieve communication, terminal device session binding is performed through sessionID.

[0086] The SockJS connection module includes:

[0087] The client creates a terminal session submodule: used by the client to process SockJS connections. The client creates a terminal session by calling the createContainerShell API and passing in the container name and command.

[0088] Client binding terminal submodule: used by the client to obtain the session ID of the terminal session, and to bind the terminal device session through the session ID. When the SockJS connection is successfully established, the client sends a binding message;

[0089] Client receiving message submodule: used by the client to listen to the onConnectionMessage event, receive messages from the server, and process them accordingly according to the message type;

[0090] Close connection submodule: used for the client to perform cleanup operations when the SockJS connection is closed.

[0091] An embodiment of the present invention further provides a computer device, Figure 6 is a schematic diagram of the structure of a computer device provided by an embodiment of the present invention; see the accompanying drawings Figure 6 As shown, the computer device includes: an input system 23, an output system 24, a memory 22 and a processor 21; the memory 22 is used to store one or more programs; when the one or more programs are executed by the one or more processors 21, the one or more processors 21 implement the container terminal session management method applicable to the cloud native architecture as provided in the above embodiment; wherein the input system 23, the output system 24, the memory 22 and the processor 21 can be connected via a bus or other means, Figure 6 The example of connecting through bus is taken in the following.

[0092] The memory 22 is a readable and writable storage medium of a computing device, which can be used to store software programs and computer executable programs, such as the corresponding program instructions of the container terminal session management method applicable to the cloud native architecture described in the embodiment of the present invention; the memory 22 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system and at least one application required for a function; the data storage area can store data created according to the use of the device, etc.; in addition, the memory 22 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other non-volatile solid-state storage device; in some instances, the memory 22 can further include a memory remotely arranged relative to the processor 21, and these remote memories can be connected to the device via a network. Examples of the above-mentioned network include the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0093] The input system 23 may be used to receive input digital or character information, and to generate key signal input related to user settings and function control of the device; the output system 24 may include display devices such as display screens.

[0094] The processor 21 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 22, that is, implements the above-mentioned container terminal session management method suitable for cloud native architecture.

[0095] The computer device provided above can be used to execute the container terminal session management method applicable to the cloud native architecture provided in the above embodiment, and has corresponding functions and beneficial effects.

[0096] The embodiment of the present invention also provides a storage medium containing computer executable instructions, which are used to execute the container terminal session management method applicable to the cloud native architecture as provided in the above embodiment when executed by a computer processor. The storage medium is any of various types of memory devices or storage devices, and the storage medium includes: installation media, such as CD-ROM, floppy disk or tape system; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media (such as hard disk or optical storage); registers or other similar types of memory elements, etc.; the storage medium may also include other types of memory or combinations thereof; in addition, the storage medium may be located in a first computer system in which the program is executed, or may be located in a different second computer system, which is connected to the first computer system via a network (such as the Internet); the second computer system may provide program instructions to the first computer for execution. The storage medium includes two or more storage media that can reside in different locations (for example, in different computer systems connected via a network). The storage medium can store program instructions (for example, specifically implemented as a computer program) that can be executed by one or more processors.

[0097] Of course, the storage medium containing computer executable instructions provided by an embodiment of the present invention is not limited to the container terminal session management method applicable to the cloud native architecture as described in the above embodiment, and can also execute related operations in the container terminal session management method applicable to the cloud native architecture provided by any embodiment of the present invention.

[0098] So far, the technical solutions of the present invention have been described in conjunction with the preferred embodiments, but it is easy for those skilled in the art to understand that the protection scope of the present invention is obviously not limited to these specific embodiments. Without departing from the principle of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will fall within the protection scope of the present invention.

[0099] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A container terminal session management method applicable to a cloud native architecture, characterized in that: The following steps are involved: S1. The server verifies the user's login information and creates a terminal session. S2. According to the container name, find the Pod in the running state, start the background coroutine, wait for SockJS to connect to the client, bind the client to the terminal device, start the specified shell command, obtain an interactive TTY session, and connect the user input and output to the terminal session; S3. Manage the status of each terminal session.

2. The container terminal session management method applicable to the cloud native architecture according to claim 1 is characterized in that: The method of connecting the SockJS to the client in step S2 and binding the client to the terminal device includes the following steps: S21. The client processes the SockJS connection. The client creates a terminal session by calling the createContainerShell API and passes in the container name and command. S22, the client obtains the session ID of the terminal session, and binds the terminal device session through the session ID. When the SockJS connection is successfully established, the client sends a binding message; S23, the client monitors the onConnectionMessage event, receives the message from the server, and processes it accordingly according to the message type; S24. When the SockJS connection is closed, the client performs cleanup operations.

3. The container terminal session management method applicable to the cloud native architecture according to claim 2 is characterized in that: The method for creating a terminal session in step S1 includes: The server verifies the client's login information through the GIN middleware. After the login information verification and authentication is successful, the logged-in user information is set to the context, a unique terminal session ID is generated, the terminal session is initialized, and stored.

4. The container terminal session management method applicable to the cloud native architecture according to claim 1 is characterized in that: The state of each terminal session in the management of the state of the terminal session in step S3 includes: session ID, binding channel, socket session and terminal size change queue.

5. The container terminal session management method applicable to cloud native architecture according to claim 1, characterized in that: The step S2 of connecting the user input and output to the terminal session includes: HTTPS and TLS protocols are used for data transmission to ensure data security.

6. A container terminal session management system applicable to a cloud native architecture, used to implement a container terminal session management method applicable to a cloud native architecture as described in any one of claims 1 to 5, characterized in that: include: The server creates a terminal session module: used by the server to verify the user's login information and create a terminal session; SockJS connection module: used to find the running Pod according to the container name, start the background coroutine, wait for SockJS to connect to the client, bind the client to the terminal device, start the specified shell command, obtain an interactive TTY session, and connect the user input and output to the terminal session; Terminal session status management module: used for managing the status of each terminal session.

7. The container terminal session management system applicable to cloud native architecture according to claim 6, characterized in that: The SockJS connection module includes: The client creates a terminal session submodule: used by the client to process SockJS connections. The client creates a terminal session by calling the createContainerShell API and passing in the container name and command. Client binding terminal submodule: used by the client to obtain the session ID of the terminal session, and to bind the terminal device session through the session ID. When the SockJS connection is successfully established, the client sends a binding message; Client receiving message submodule: used by the client to listen to the onConnectionMessage event, receive messages from the server, and process them accordingly according to the message type; Close connection submodule: used for the client to perform cleanup operations when the SockJS connection is closed.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the container terminal session management method applicable to a cloud native architecture as described in any one of claims 1 to 5 are implemented.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the steps of the container terminal session management method applicable to the cloud native architecture as described in any one of claims 1 to 5 are implemented.

Images