A multi-instance high-availability notebook dynamic access method and device

Abstract

The application relates to the technical field of network agent and interactive computing application deployment, and provides a multi-instance high-availability Notebook dynamic access method and equipment, which comprises the following steps: detecting port occupation and dynamically allocating an available port for a newly started Notebook instance, forcibly setting an access base path of the instance as a path identifier corresponding to the allocated port, and structuring a mapping relationship between the instance and the port; locating a configuration file of the Notebook, setting a source address and a trust parameter in the configuration file, so that the Notebook instance can recognize a cross-domain request from an agent layer; generating an agent server configuration file according to agent service parameters input by a user; and initiating access by the user through a unified entrance provided by the agent layer, parsing a port identifier from an access path, and forwarding a request to a corresponding Notebook instance. The application can improve access management and port management efficiency, enhance system security and stability, solve the cross-domain interception problem, and reduce the configuration threshold.

Description

Technical Field

[0001] This invention relates to the field of network proxy and interactive computing application deployment technology, and in particular to a method and device for dynamic access to a multi-instance highly available Notebook. Background Technology

[0002] In multi-user collaboration scenarios, different users need isolated working environments to avoid mutual interference. In multi-project parallel development scenarios, different projects may depend on different software package versions or runtime environments, and development must be carried out in isolated instances. Therefore, in actual deployment, it is often necessary to run multiple Notebook instances on the server simultaneously, with each instance serving a specific user or project to achieve environment isolation and resource independence.

[0003] However, while multi-instance deployment solves the environment isolation problem, it introduces complexity in access management. How to enable users to conveniently and securely access their respective Notebook instances, how to dynamically add or delete instances without increasing operational burden, and how to ensure smooth communication between the front-end management platform and the back-end multiple instances have become key technical issues that must be addressed in multi-instance deployment scenarios.

[0004] In current engineering practices and existing technical solutions, the deployment and access of multiple Notebook instances mainly adopt the following two methods, but both have obvious defects and shortcomings:

[0005] The first method: Direct access via server IP address and instance port. This is the simplest and most direct method. Each Notebook instance is assigned a unique network port, and users access a specific instance directly using the combination of the server IP address and port number. For example, instance 1 is accessed via port 8091, and instance 2 via port 8092. Users need to remember the port number for each instance. This method has the following drawbacks:

[0006] 1. Complex access management. In scenarios with a large number of instances, users need to remember multiple combinations of IP addresses and ports, which can easily lead to confusion and incorrect input. Furthermore, it is impossible to access all instances through a unified entry point, resulting in a poor user experience.

[0007] Second, port allocation is inefficient. When deploying multiple instances, operations and maintenance personnel need to check the current port usage status one by one through system commands and manually specify unused ports for new instances to use. This operation is cumbersome and prone to errors. If the system is relied upon to randomly allocate ports, the ports after the instance starts are unpredictable, making it impossible to configure access rules in advance or allow users to remember the access path.

[0008] Third, port conflict troubleshooting is difficult. When a manually specified port happens to be occupied by another application, Notebook only returns a vague startup error message. Users need to manually check the service occupying the port and release it, further increasing maintenance and time costs.

[0009] Fourth, high security risks. This method directly exposes the real service port of the Notebook instance to the outside world, lacking the isolation layer of port mapping or reverse proxy. Attackers can use port scanning tools to discover all open ports and then launch targeted attacks against the Notebook service. Furthermore, it is impossible to set up a front-end security verification mechanism at the port level.

[0010] The second method: configuring fixed port mapping via a reverse proxy. To improve upon the shortcomings of direct access, some technical solutions use reverse proxy servers such as Nginx, writing separate path forwarding rules for each Notebook instance. For example, a location block is added to the Nginx configuration for each instance, forwarding a specific path prefix to the corresponding instance port. This method is an improvement over direct access, but it still has the following drawbacks:

[0011] First, the configuration and maintenance costs are high. Adding or deleting a Notebook instance requires manually modifying the Nginx configuration file, adding or deleting the corresponding location forwarding rules, and then reloading the Nginx service to make the changes take effect. In a dynamic environment with frequent changes in multiple instances, this manual configuration method results in a huge workload for operations and maintenance, and makes it impossible to achieve dynamic elastic scaling of instances.

[0012] Second, there is no unified access point security control. Although the real ports of the instances are hidden through reverse proxies, the multiple instances are still scattered under different path rules, making it impossible to configure security policies such as identity authentication, access rate limiting, and IP blacklists and whitelists at a unified entry point. This poses risks of inconsistent access control and security vulnerabilities.

[0013] Third, cross-origin interception is a prominent issue. In practical applications, Notebook instances often need to be embedded in front-end management platforms. For example, a collaboration platform deployed at a specific address needs to load the Notebook through a page framework. In this case, because the origin address of the front-end page is different from the service address of the Notebook instance, the browser's same-origin policy will intercept two types of critical requests: one is application programming interface requests, such as retrieving kernel lists or file lists; the other is WebSocket connection requests, used to implement real-time code execution and result feedback. Existing solutions simply add a response header allowing all origins at the Nginx layer to handle cross-origin issues. This neither handles the browser's preflight requests nor configures an origin address recognition mechanism at the Notebook service level, resulting in the cross-origin problem not being completely resolved.

[0014] Fourth, the configuration process has a high barrier to entry. Notebook's cross-domain compatibility relies on a specific configuration file, which is not generated by default and requires users to create it manually. Moreover, the path of the configuration file varies depending on the deployment scenario. For local deployments, it is located in a hidden folder under the user's home directory, while for Docker container deployments, it is located in a specific path within the container. Users are prone to cross-domain configuration failures due to incorrect paths or missing parameters, increasing the difficulty of use for non-professionals.

[0015] Chinese patent CN121541889A discloses a Jupyter Notebook container orchestration method based on Kubernetes (K8s). This solution relies entirely on K8s' native Service and port exposure mechanisms, with K8s automatically assigning internal cluster ports to each NotebookPod and mapping them through Services. While this method achieves basic port management, it lacks a proactive port detection and allocation mechanism. When ports are occupied or conflicting, K8s only returns an error message indicating Pod startup failure, failing to automatically detect port availability and reallocate available ports. Users still need to manually troubleshoot port conflicts and adjust deployment configurations, increasing operational complexity.

[0016] Therefore, how to provide a method for dynamic access to multi-instance highly available Notebooks that can achieve automatic allocation of instance ports, dynamic generation of proxy configurations, and collaborative processing of cross-domain requests has become an urgent technical problem to be solved. Summary of the Invention

[0017] In view of this, in order to overcome the shortcomings of the prior art, the present invention aims to provide a method and device for dynamic access to a multi-instance highly available Notebook.

[0018] According to a first aspect of the present invention, a method for dynamic access to a multi-instance highly available Notebook is provided, the method comprising:

[0019] Step S1: Detect port occupancy and dynamically allocate available ports for the newly launched Notebook instance, force the instance's access base path to be set to the path identifier corresponding to the allocated port, and structure the mapping relationship between the instance and the port.

[0020] Step S2: Locate the Notebook's configuration file, set the source address and trust parameters in the configuration file, so that the Notebook instance can recognize cross-domain requests from the proxy layer;

[0021] Step S3: Based on the proxy service parameters input by the user, generate a proxy server configuration file containing instructions for dynamically extracting port identifiers from the access path, configuration items to support WebSocket protocol upgrades, and forwarding rules for dynamically forwarding requests to the corresponding Notebook instance;

[0022] Step S4: The user initiates access through the unified entry point provided by the proxy layer. According to the instructions used to dynamically extract the port identifier from the access path, the port identifier is parsed from the access path and the request is forwarded to the corresponding Notebook instance.

[0023] Optionally, in the multi-instance highly available Notebook dynamic access method of the present invention, step S1, detecting port occupancy and dynamically allocating available ports for newly started Notebook instances, includes: presetting a continuous range of available port values; scanning the current occupancy status of each port within the range by executing an operating system port query command; extracting a list of occupied port values ​​from the command return results using text matching; determining whether each port value exists in the list of occupied port values ​​by incrementing the value from the beginning of the range; and using the first unoccupied port value as the allocated port for the current instance.

[0024] Optionally, in the multi-instance highly available Notebook dynamic access method of the present invention, in step S1, the access base path of the instance is forcibly set to the path identifier corresponding to the allocated port in the following manner: when generating the startup command of the Notebook instance, the dynamically allocated port value is specified through the port parameter, and at the same time, the access root path of the instance is set to the same string form as the port value through the base path parameter.

[0025] Optionally, in the multi-instance highly available Notebook dynamic access method of the present invention, in step S1, the mapping relationship between instances and ports is structured in the following manner: after the Notebook instance is successfully started and running normally, the unique identification information of the instance, the allocated dynamic port value and the bound path identifier are combined into structured mapping relationship data.

[0026] Optionally, in the multi-instance highly available Notebook dynamic access method of the present invention, step S2 involves locating the Notebook's configuration file in the following manner:

[0027] Determine the runtime environment type of the current Notebook instance. If it is deployed on a local physical machine or virtual machine, locate the hidden configuration folder under the current user's home directory; if it is deployed in a container, enter the specified container through the container management tool and locate the preset user configuration folder inside the container.

[0028] Check if the configuration file exists in the above location path. If it does not exist, call the configuration file generation command to create the file.

[0029] Optionally, in the multi-instance highly available Notebook dynamic access method of the present invention, in step S2, the source address and trust parameters are set in the configuration file as follows: The allowed access source parameter is written to the located configuration file, and the parameter value is set to the complete address of the front-end management platform specified by the user; the allowed WebSocket connection source parameter is written, and the parameter value is set to the address list of the unified access entry point of the proxy layer; the proxy header trust parameter is written and its value is set to true, enabling the Notebook instance to recognize the original request header information transmitted by the proxy server; the listening address parameter is written and its value is set to all network interfaces, allowing the host where the proxy server is located to access the instance.

[0030] Optionally, in the multi-instance highly available Notebook dynamic access method of the present invention, in step S3, the configuration item supporting WebSocket protocol upgrade and the forwarding rule for dynamically forwarding requests to the corresponding Notebook instance are implemented as follows: a port variable is defined in the global configuration block of the proxy server configuration file, and the first-level path fragment in the user access path is captured by the regular expression path matching rule. This fragment consists of consecutive numeric characters. The captured numeric string is assigned to the port variable. When the user access path contains a numeric prefix, the port variable takes the corresponding numeric string as its value. When the user access path does not contain a numeric prefix, the port variable takes the empty value.

[0031] Optionally, in the multi-instance highly available Notebook dynamic access method of the present invention, in step S3, the forwarding rule for dynamically forwarding the request to the corresponding Notebook instance is implemented as follows: a path matching rule is configured in the service block of the proxy server configuration file. The path matching rule uses regular expressions to capture all access paths containing numeric prefixes. The forwarding instruction uses the extracted port variable to dynamically construct the backend target address in the format of proxy protocol plus Notebook server address plus port variable. At the same time, the HTTP protocol version parameters, upgrade header settings and connection header settings required for WebSocket protocol upgrade are configured in the service block, and the original host header transmission parameters and cross-domain response header parameters are configured.

[0032] Optionally, in the multi-instance highly available Notebook dynamic access method of the present invention, when the user initiates access through the unified entry point provided by the proxy layer in step S4, it further includes:

[0033] The application programming interface request is validated by accessing the kernel list interface and checking whether the returned response status code is successful.

[0034] Verify the WebSocket connection by executing the code in the Notebook and observing whether the output is returned in real time.

[0035] According to a second aspect of the present invention, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect of the present invention.

[0036] The multi-instance highly available Notebook dynamic access method and device of the present invention have the following beneficial technical effects:

[0037] I. Improve access management and port management efficiency

[0038] There is no need to write static location forwarding rules for each instance, enabling dynamic and lossless scaling of instances, significantly improving instance startup efficiency and significantly reducing operation and maintenance costs.

[0039] II. Completely hides the real port, significantly enhancing system security.

[0040] There is no need to deploy security mechanisms separately for each distributed Notebook instance, which not only improves the efficiency of security configuration, but also avoids security vulnerabilities caused by instance distribution, forming a multi-layered security system.

[0041] III. A layered cross-domain collaboration mechanism to completely solve the cross-domain interception problem.

[0042] This solution fundamentally addresses the cross-domain request blocking issue caused by the browser's same-origin policy. When users embed a Notebook in the front-end management platform, API requests for retrieving kernel lists, file lists, and other data can be successfully returned. The results of real-time code execution can be promptly fed back via WebSocket connection, achieving a user experience completely consistent with local usage.

[0043] IV. Significantly lowers the configuration threshold, allowing even non-professionals to complete the deployment.

[0044] To address the complexity of cross-domain Notebook configuration, a standardized process for generating configuration files and locating paths is provided. Even non-professional operations and maintenance personnel can quickly set up a cross-domain Notebook environment, greatly reducing the technical threshold.

[0045] V. Port conflict risks are eliminated, significantly improving system stability.

[0046] This fundamentally eliminates the risk of instance startup failure due to port conflicts, significantly improving system stability in multi-instance deployment scenarios. Attached Figure Description

[0047] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0048] Figure 1 A schematic diagram of the architecture for the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 2 of the present invention;

[0049] Figure 2 This is a schematic diagram of the execution flow of the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 2 of the present invention;

[0050] Figure 3 This is a schematic diagram illustrating the application principle of the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 3 of the present invention;

[0051] Figure 4 This is a first schematic diagram of the access verification interface of the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 3 of the present invention;

[0052] Figure 5 This is a second schematic diagram of the access verification interface for the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 3 of the present invention;

[0053] Figure 6 This is a schematic diagram of the structure of the device provided by the present invention. Detailed Implementation

[0054] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0055] It should be noted that, in the absence of conflict, the following embodiments and features can be combined with each other; and, based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0056] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0057] Example 1

[0058] Exemplary embodiment 1 of the present invention provides a method for dynamic access to a multi-instance highly available Notebook. The method in this embodiment is implemented according to the following steps:

[0059] Step S1: Detect port occupancy and dynamically allocate available ports for the newly launched Notebook instance. Force the instance's access base path to be set to the path identifier corresponding to the allocated port, thus structuring the mapping relationship between the instance and the port.

[0060] In this embodiment, a continuous range of available port values ​​is preset. The current occupancy status of each port within this range is scanned by executing the operating system port query command. The list of occupied port values ​​is extracted from the command return results using text matching. Starting from the beginning of the range, each port value is incremented to determine whether it exists in the list of occupied port values. The first unoccupied port value is used as the allocated port for the current instance, thereby ensuring that each newly started instance uses a unique available port and completely avoiding instance startup failures due to port conflicts.

[0061] In this embodiment, the access base path of the instance is forcibly set to the path identifier corresponding to the allocated port in the following way: when generating the startup command of the Notebook instance, the dynamically allocated port value is specified through the port parameter, and the access root path of the instance is set to the same string form as the port value through the base path parameter, so that the access path prefix of each Notebook instance forms a fixed relationship with its service port, which makes it easy for the proxy layer to accurately identify and route to the corresponding backend instance through the path prefix.

[0062] In this embodiment, the mapping relationship between instances and ports is structured as follows: After a Notebook instance successfully starts and runs normally, its unique identifier, the allocated dynamic port value, and the bound path identifier are combined into structured mapping data. This data is actively pushed to the configuration generation module via inter-process communication or shared storage, enabling the configuration generation module to obtain real-time information on the port allocation of all running instances. This provides an accurate data foundation for automatically adapting to newly added instances, allowing for dynamic configuration updates without manual intervention.

[0063] Step S2: Locate the Notebook's configuration file and set the source address and trust parameters in the configuration file so that the Notebook instance can recognize cross-domain requests from the proxy layer.

[0064] In this embodiment, the Notebook's configuration file is located as follows: the runtime environment type of the current Notebook instance is determined. If it is deployed on a local physical machine or virtual machine, the hidden configuration folder under the current user's home directory is located. If it is deployed in a containerized environment, the specified container is accessed through the container management tool and the preset user configuration folder inside the container is located. The configuration file is checked to see if it exists in the above location path. If it does not exist, the configuration file generation command is called to create the file, ensuring that the subsequent writing of cross-domain parameters has a reliable file basis.

[0065] In this embodiment, the source address and trust parameters are set in the configuration file as follows: The allowed access source parameter is written to the located configuration file, with its value set to the complete address of the front-end management platform specified by the user; the allowed WebSocket connection source parameter is written, with its value set to the address list of the unified access entry point of the proxy layer; the proxy header trust parameter is written and its value is set to true, enabling the Notebook instance to recognize the original request header information transmitted by the proxy server; the listening address parameter is written and its value is set to all network interfaces, allowing the host where the proxy server is located to access the instance, thereby establishing a complete cross-domain recognition mechanism at the service level.

[0066] Step S3: Based on the proxy service parameters input by the user, generate a proxy server configuration file containing instructions for dynamically extracting port identifiers from the access path, configuration items to support WebSocket protocol upgrades, and forwarding rules for dynamically forwarding requests to the corresponding Notebook instance.

[0067] In this embodiment, the configuration items supporting WebSocket protocol upgrades and the forwarding rules for dynamically forwarding requests to the corresponding Notebook instance are implemented as follows: A port variable is defined in the global configuration block of the proxy server configuration file. The first-level path fragment in the user's access path is captured by the regular expression path matching rules. This fragment consists of consecutive numeric characters. The captured numeric string is assigned to the port variable. When the user's access path contains a numeric prefix, the port variable takes the corresponding numeric string as its value. When the user's access path does not contain a numeric prefix, the port variable takes the empty value, thereby achieving accurate dynamic extraction of the port identifier.

[0068] In this embodiment, the forwarding rules for dynamically forwarding requests to the corresponding Notebook instance are implemented as follows: Path matching rules are configured in the service block of the proxy server configuration file. These rules use regular expressions to capture all access paths containing numeric prefixes. The forwarding instructions use extracted port variables to dynamically construct a backend target address in the format of proxy protocol plus Notebook server address plus port variable. At the same time, the HTTP protocol version parameters, upgrade header settings, and connection header settings required for WebSocket protocol upgrades are configured in the service block. The original host header transmission parameters are configured to ensure that the Notebook instance correctly identifies the access source. Cross-domain response header parameters are configured to allow cross-domain requests from the specified frontend source.

[0069] Step S4: The user initiates access through the unified entry point provided by the proxy layer. According to the instructions used to dynamically extract the port identifier from the access path, the port identifier is parsed from the access path and the request is forwarded to the corresponding Notebook instance.

[0070] In this embodiment, the user accesses a unified entry address through a browser. The address format is proxy protocol plus proxy server address plus proxy listening port plus dynamic port identifier. The proxy server forwards the request to the corresponding backend instance based on the dynamic port identifier.

[0071] When a user initiates access through the unified entry point provided by the proxy layer, the following steps are also included: verifying the application programming interface request by accessing the kernel list interface and checking whether the returned response status code is successful; and verifying the WebSocket connection by executing code in the Notebook and observing whether the output result is returned in real time, thereby confirming the effectiveness and correctness of the collaborative work of dynamic port allocation, proxy server dynamic forwarding, and layered cross-domain configuration.

[0072] Example 2

[0073] Exemplary embodiment 2 of the present invention provides a method for dynamic access to a multi-instance highly available Notebook. The method of this embodiment is described in detail below in a specific scenario.

[0074] In this scenario, the method of this embodiment is implemented in an architecture that includes a Notebook instance management module, an Nginx configuration generation module, a Notebook cross-domain configuration module, and a dynamic proxy module. Figure 1 A schematic diagram of the architecture for the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 2 of the present invention is shown below. Figure 1 As shown, as an optional example, the modules in this scenario's architecture are as follows:

[0075] Notebook instance management module: Supports configuring instance ports (including dynamic allocation) and base paths (ServerApp.base_url), and includes a built-in "Dynamic Port Allocation and Detection Submodule" (automatically detects port availability, dynamically allocates ports, and synchronizes port mapping relationships);

[0076] The Nginx configuration generation module receives user input regarding the Nginx listening port, Notebook instance server IP, and allowed front-end sources, and automatically generates a configuration file containing dynamic port extraction (map directive), WebSocket protocol upgrade, and cross-domain response headers; it also receives the "port-instance" mapping relationship synchronized from the Notebook instance management module to ensure that the configuration is adapted to the new instance.

[0077] Notebook cross-origin configuration module: Built-in jupyter_notebook_config.py template. After the user enters the allowed front-end source and Nginx access source, parameters such as allow_origin (allow front-end source), allow_websocket_origin (allow WebSocket source), and trust_xheaders=True (trust proxy header) are automatically added. It supports automatic location of configuration file path (local / Docker scenarios).

[0078] Dynamic proxy module: Based on Nginx, it extracts the instance port (including dynamically allocated new ports) from the URL using the map directive, matches the path containing the port prefix using the location regular expression, dynamically forwards the request to the target instance, and adds cross-domain response headers and WebSocket protocol upgrade headers.

[0079] In this embodiment, the modules work together to implement the process of "dynamic port allocation → Notebook instance startup → Notebook cross-domain configuration → Nginx application configuration → access and verification".

[0080] Figure 2 This is a schematic diagram of the execution flow of the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 2 of the present invention, as follows: Figure 2 As shown, specifically in this scenario, the method of the present invention is implemented in the following manner:

[0081] Step 1: Start the Notebook instance with dynamic port allocation and detection

[0082] 1) Dynamic Port Allocation and Detection: Port management is achieved through the "Dynamic Port Allocation and Detection Submodule" of the Notebook instance management module. It supports setting port ranges (such as --port-range 8090-8100). The module executes commands to detect port occupancy and extracts the list of currently occupied ports using regular expressions. Starting from the first port (8090), it filters the first unoccupied port (such as 8091) and automatically uses it as the port of the current instance.

[0083] 2) Instance startup and base path binding: The module automatically generates a startup command that forcibly binds the dynamically allocated port to ServerApp.base_url (ensuring that the path prefix matches the port). Example: Fully automatic allocation of port 8091: jupyter notebook --port=8091 --ServerApp.base_url= / 8091 --ip=0.0.0.0;

[0084] 3) Port mapping synchronization: After the instance starts successfully, the module automatically synchronizes the "instance ID - dynamic port - basic path" mapping relationship to the Nginx configuration generation module, ensuring that Nginx can recognize the new instance without manually modifying the configuration;

[0085] 4) Generate configuration file: If jupyter_notebook_config.py does not exist, execute jupyternotebook --generate-config to generate it. The local path is ~ / .jupyter / , and the Docker path is / home / jovyan / .jupyter / .

[0086] Step 2: Notebook Cross-Domain Configuration

[0087] 1) Locating the configuration file: For local deployment, navigate to ~ / .jupyter / ; for Docker deployment, execute `docker exec -it [container ID] bash` and then navigate to / home / jovyan / .jupyter / .

[0088] 2) Edit configuration parameters: Open jupyter_notebook_config.py and add the following core configurations:

[0089] # Allowed front-end access sources (consistent with Nginx cross-origin configuration)

[0090] c.NotebookApp.allow_origin = "http: / / 10.32.123.108:8080"

[0091] # Allowed WebSocket sources (Nginx unified access point)

[0092] c.NotebookApp.allow_websocket_origin = ["10.32.123.108:8880", "notebook.example.com"]

[0093] # Trust the header information passed by Nginx (to avoid source identification errors)

[0094] c.NotebookApp.trust_xheaders = True

[0095] # Allow external access to the instance (from the server where Nginx resides)

[0096] c.NotebookApp.ip = "0.0.0.0"

[0097] Step 3: Nginx Configuration Generation and Application

[0098] Generate configuration file: Use the Nginx configuration module to generate the configuration file. Enter the Nginx listening port (e.g., 8880), Notebook server IP (e.g., 10.32.123.12), and allowed frontend sources (e.g., http: / / 10.32.123.108:8080). The core configuration will be automatically generated (supports dynamic port extraction, allowing adaptation to new instances without modification). For example:

[0099] http {

[0100] # Extract the Notebook instance port from the URL path (including dynamically assigned ports, such as / 8091 / →8091, / 8092 / →8092)

[0101] map $uri $notebook_port {

[0102] default "";

[0103] ~^ / (\d+) / $1;

[0104] }

[0105] # WebSocket protocol switching (adapting to real-time interaction)

[0106] map $http_upgrade $connection_upgrade {

[0107] default upgrade;

[0108] '' close;

[0109] }

[0110] server {

[0111] listen 8880; # Nginx unified listening port

[0112] # Matches paths containing instance port prefixes (including dynamic port paths, such as / 8091 / , / 8093 / tree / ).

[0113] location ~ ^ / (\d+) / {

[0114] # Dynamically forward to the target Notebook instance (automatically adapts to dynamic ports)

[0115] proxy_pass http: / / 10.32.123.12:$notebook_port;

[0116] # WebSocket Protocol Upgrade Configuration

[0117] proxy_http_version 1.1;

[0118] proxy_set_header Upgrade $http_upgrade;

[0119] proxy_set_header Connection $connection_upgrade;

[0120] # Keep the Host header to ensure the Notebook identifies the correct source.

[0121] proxy_set_header Host $host;

[0122] # Add cross-origin header to regular requests

[0123] add_header'Access-Control-Allow-Origin' 'http: / / 10.32.123.108:8080';

[0124] }

[0125] }

[0126] }

[0127] Step 4: Access and Verification

[0128] 1) User access to the dynamic port instance: Access the new instance with dynamically assigned port 8091 via http: / / 10.32.123.108:8880 / 8091 / (no need to modify Nginx configuration);

[0129] 2) Functional verification:

[0130] API request verification:

[0131] Sending a GET request to http: / / 10.32.123.108:8880 / 8091 / api / kernels and receiving a 200 response code indicates that the API cross-origin configuration for the dynamic port instance is effective.

[0132] WebSocket verification: Run code (such as print("Hello World")) in the dynamic port instance. If the code outputs the result normally, it means that the WebSocket cross-domain configuration of the dynamic port instance is effective.

[0133] Dynamic port collaboration verification: Start a new instance with dynamic port 8092, and directly access http: / / 10.32.123.108:8880 / 8092 / to verify that Nginx can automatically forward, proving the effectiveness of collaboration between dynamic port and Nginx forwarding.

[0134] Example 3

[0135] Exemplary embodiment 3 of the present invention provides a method for dynamic access to a Notebook with high availability across multiple instances. The method of this embodiment will be further described below in a specific scenario.

[0136] Figure 3 This is a schematic diagram illustrating the application principle of the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 3 of the present invention. Figure 3This demonstrates the connections and data interactions between the user, the dynamic proxy module, and multiple Notebook instances. After a user initiates a request to access a Notebook, the dynamic proxy module first extracts the URL and port number, then forwards the request to the corresponding Notebook instance. Subsequently, the Notebook instance returns the result to the dynamic proxy module, which then returns the result to the user.

[0137] Figure 4 This is a first schematic diagram of the access verification interface for the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 3 of the present invention, as shown below. Figure 4 As shown, the user accesses the Notebook instance (URL: http: / / 10.32.123.108:8890 / 8891 / lab) on dynamic port 8891 through an Nginx proxy. The left side of the interface is the file management area (containing the test file test11.ipynb), and the right side is the code execution area. The code cell print('hello 8891') successfully outputs the result, and the conda list command returns the environment package list normally, proving that the code execution and environment access functions of the dynamic port instance are normal.

[0138] Figure 5 This is a second schematic diagram of the access verification interface for the multi-instance highly available Notebook dynamic access method according to Exemplary Embodiment 3 of the present invention. Figure 5 This demonstrates a Notebook instance accessed by a user via an Nginx proxy on dynamic port 8892.

[0139] The multi-instance highly available Notebook dynamic access method of the present invention has the following beneficial technical effects:

[0140] I. Improve access management and port management efficiency

[0141] By using Nginx's map directive to dynamically extract ports, the proxy server can automatically resolve the target instance's port identifier from the user's access path, eliminating the need to write static location forwarding rules for each instance. When adding a Notebook instance, there's no need to modify the Nginx configuration file or restart the proxy service, achieving dynamic and lossless scaling of instances.

[0142] Meanwhile, the built-in dynamic port allocation and detection submodule uses automated scripts to intelligently detect port occupancy and dynamically allocate available ports. Before instance startup, it automatically scans for occupancy within a specified port range, sequentially selecting the first unoccupied port as the allocated port for the current instance, completely avoiding conflicts that may occur when manually specifying ports. After successful instance startup, the system automatically synchronizes the mapping relationship between the instance identifier, dynamic port, and basic path to the Nginx configuration generation module. The entire process is fully automated, requiring no manual intervention, significantly improving instance startup efficiency and reducing operational costs.

[0143] II. Completely hides the real port, significantly enhancing system security.

[0144] By using Nginx reverse proxy to build a unified access isolation layer, all requests from external users can only access the publicly exposed listening ports of the proxy layer, and cannot directly access the real service ports of the Notebook instance. Even if attackers detect the proxy layer ports using scanning tools, they cannot obtain the actual network address and port information of the backend instance, let alone bypass the proxy layer to launch a direct attack on the instance.

[0145] Since all access requests must pass through the proxy layer, the system can centrally configure various security policies at a unified entry point, including identity authentication, access rate limiting, IP blacklists and whitelists, request filtering, etc. There is no need to deploy security mechanisms separately for each distributed Notebook instance. This not only improves the efficiency of security configuration, but also avoids security vulnerabilities caused by instance distribution, forming a multi-layered security system.

[0146] III. A layered cross-domain collaboration mechanism to completely solve the cross-domain interception problem.

[0147] By adopting a layered and collaborative cross-domain configuration mechanism of "Nginx proxy layer plus Notebook service layer", the problem of cross-domain request interception caused by the browser's same-origin policy is fundamentally solved.

[0148] At the proxy level, the Nginx configuration includes complete cross-origin response header settings, correctly handling browser preflight requests and adding cross-origin access permission headers to all requests passed through the proxy. At the service level, the Notebook cross-origin configuration module automatically locates the configuration file and sets the allowed front-end origin addresses, allowed WebSocket connection origin addresses, and proxy header trust parameters, enabling the Notebook instance to recognize cross-origin requests from the proxy layer and correctly identify the original request source forwarded by the proxy.

[0149] The two types of critical requests that were originally blocked by the browser—Application Programming Interface (API) requests and WebSocket connection requests—were able to pass through normally. When users embed a Notebook in the front-end management platform, API requests for retrieving kernel lists, file lists, and other data returned successfully, and the results of real-time code execution were promptly fed back via the WebSocket connection, achieving a user experience completely consistent with local usage.

[0150] IV. Significantly lowers the configuration threshold, allowing even non-professionals to complete the deployment.

[0151] To address the complexity of cross-domain configuration for Notebooks, a standardized process for generating configuration files and locating their paths is provided. The cross-domain configuration module can automatically identify whether the current deployment environment is a local physical machine, a virtual machine, or a Docker container, and automatically locate the correct configuration file directory based on the environment type. If the configuration file does not exist, the system automatically generates it using commands, eliminating the need for users to remember complex generation commands and path information.

[0152] Meanwhile, it has a complete built-in parameter template. Users only need to enter the allowed front-end source address and proxy layer access address. The system automatically writes the allowed access source parameters, allowed WebSocket connection source parameters, proxy header trust parameters and listening address parameters into the configuration file, ensuring that all necessary cross-domain configuration items are complete and correct. This allows even non-professional operations and maintenance personnel to quickly complete the setup of the Notebook cross-domain environment, greatly reducing the technical threshold.

[0153] V. Port conflict risks are eliminated, significantly improving system stability.

[0154] By employing a fully automated port detection and allocation mechanism, the risk of instance startup failure due to port conflicts is fundamentally eliminated. The dynamic port allocation submodule scans the system's port occupancy status in real time before each new instance startup, ensuring that the allocated ports are indeed available at that moment. Even when multiple instances are started simultaneously, different available ports are detected and allocated sequentially, avoiding conflicts.

[0155] When it detects that there are not enough available ports within the port range, it can provide clear prompts in a timely manner and recommend an expandable port range for users to adjust, avoiding startup failures caused by port resource exhaustion, reducing the startup failure rate caused by port conflicts to zero, and significantly improving system stability in multi-instance deployment scenarios.

[0156] VI. Widely compatible with various scenarios, meeting diverse deployment needs

[0157] It boasts excellent scenario adaptability and compatibility, meeting the diverse deployment needs of enterprise-level applications. Regarding deployment environments, it supports various deployment methods including local physical machines, virtual machines, and Docker containers. The cross-domain configuration module automatically identifies environmental differences and locates the correct configuration file path without manual intervention. For frontend access, it supports simultaneous access from multiple frontend sources. Multiple allowed access source addresses can be set in the Nginx configuration, or the returned allowed source address can be dynamically adapted based on the source field in the request header, meeting the needs of different frontend platforms accessing simultaneously. In terms of communication protocols, it supports encrypted transmission scenarios. By configuring the protocol type and passing parameters, the encrypted protocol type of the frontend request is passed to the backend Notebook instance. Simultaneously, the corresponding security options are enabled in the Notebook configuration, ensuring that dynamic access methods still function correctly in encrypted communication environments such as HTTPS. Communication and collaboration are achieved through standard interfaces. It can be deployed as a complete system or, depending on actual needs, selected modules can be integrated into existing platforms, demonstrating excellent scalability and integrability.

[0158] like Figure 6 As shown, the present invention also provides a device including a processor 310, a communication interface 320, a memory 330 for storing processor-executable computer programs, and a communication bus 340. The processor 310, communication interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 implements the aforementioned multi-instance highly available Notebook dynamic access method by running the executable computer program.

[0159] The computer program in memory 330, when implemented as a software functional unit and sold or used as an independent product, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0160] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected based on actual needs to achieve the purpose of this embodiment. Those skilled in the art can understand and implement this without any creative effort.

[0161] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0162] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for dynamic access to a multi-instance highly available Notebook, characterized in that, The method includes: Step S1: Detect port occupancy and dynamically allocate available ports for the newly launched Notebook instance, force the instance's access base path to be set to the path identifier corresponding to the allocated port, and structure the mapping relationship between the instance and the port. Step S2: Locate the Notebook's configuration file, set the source address and trust parameters in the configuration file, so that the Notebook instance can recognize cross-domain requests from the proxy layer; Step S3: Based on the proxy service parameters input by the user, generate a proxy server configuration file containing instructions for dynamically extracting port identifiers from the access path, configuration items to support WebSocket protocol upgrades, and forwarding rules for dynamically forwarding requests to the corresponding Notebook instance; Step S4: The user initiates access through the unified entry point provided by the proxy layer. According to the instructions used to dynamically extract the port identifier from the access path, the port identifier is parsed from the access path and the request is forwarded to the corresponding Notebook instance.

2. The method for dynamic access to a multi-instance highly available Notebook according to claim 1, characterized in that, In step S1, the port occupancy status is detected and an available port is dynamically allocated to the newly started Notebook instance. This includes: pre-setting a continuous range of available port values; scanning the current occupancy status of each port within the range by executing the operating system port query command; extracting the list of occupied port values ​​from the command return results using text matching; determining whether each port value exists in the list of occupied port values ​​by incrementing the value from the beginning of the range; and using the first unoccupied port value as the allocated port for the current instance.

3. The multi-instance highly available Notebook dynamic access method according to claim 2, characterized in that, In step S1, the instance's access base path is forcibly set to the path identifier corresponding to the allocated port in the following way: when generating the Notebook instance's startup command, the dynamically allocated port value is specified through the port parameter, and the instance's access root path is set to the same string format as the port value through the base path parameter.

4. The method for dynamic access to a multi-instance highly available Notebook according to claim 1, characterized in that, In step S1, the mapping relationship between the instance and the port is structured as follows: After the Notebook instance starts up and runs normally, the unique identifier of the instance, the assigned dynamic port value, and the bound path identifier are combined into structured mapping relationship data.

5. The method for dynamic access to a multi-instance highly available Notebook according to claim 1, characterized in that, In step S2, locate the Notebook's configuration file as follows: Determine the runtime environment type of the current Notebook instance. If it is deployed on a local physical machine or virtual machine, locate the hidden configuration folder under the current user's home directory; if it is deployed in a container, enter the specified container through the container management tool and locate the preset user configuration folder inside the container. Check if the configuration file exists in the above location path. If it does not exist, call the configuration file generation command to create the file.

6. The method for dynamic access to a multi-instance highly available Notebook according to claim 5, characterized in that, In step S2, the source address and trust parameters are set in the configuration file as follows: the allowed access source parameter is written in the located configuration file, and the value of the parameter is set to the full address of the front-end management platform specified by the user; Write the WebSocket connection source parameter, which is set to the list of addresses for the unified access entry point of the proxy layer; write the proxy header trust parameter and set its value to true, enabling the Notebook instance to recognize the original request header information passed by the proxy server; write the listening address parameter and set its value to all network interfaces, allowing the host where the proxy server is located to access the instance.

7. The method for dynamic access to a multi-instance highly available Notebook according to claim 1, characterized in that, In step S3, the configuration items supporting WebSocket protocol upgrades and the forwarding rules for dynamically forwarding requests to the corresponding Notebook instance are implemented as follows: a port variable is defined in the global configuration block of the proxy server configuration file. The first-level path fragment in the user access path is captured by the regular expression path matching rules. This fragment consists of consecutive numeric characters. The captured numeric string is assigned to the port variable. When the user access path contains a numeric prefix, the port variable takes the corresponding numeric string as its value. When the user access path does not contain a numeric prefix, the port variable takes the empty value.

8. The method for dynamic access to a multi-instance highly available Notebook according to claim 7, characterized in that, In step S3, the forwarding rules used to dynamically forward requests to the corresponding Notebook instance are implemented as follows: Path matching rules are configured in the service block of the proxy server configuration file. These path matching rules use regular expressions to capture all access paths containing numeric prefixes. The extracted port variables are used in the forwarding instructions to dynamically construct the backend target address in the format of proxy protocol plus Notebook server address plus port variable. At the same time, the HTTP protocol version parameters, upgrade header settings, and connection header settings required for WebSocket protocol upgrade are configured in the service block, and the original host header transmission parameters and cross-domain response header parameters are configured.

9. The method for dynamic access to a multi-instance highly available Notebook according to claim 1, characterized in that, In step S4, when a user initiates access through the unified entry point provided by the proxy layer, the following steps are also included: The application programming interface request is validated by accessing the kernel list interface and checking whether the returned response status code is successful. Verify the WebSocket connection by executing the code in the Notebook and observing whether the output is returned in real time.

10. A computer device, characterized in that, The computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method according to any one of claims 1-9.

Images