Authentication method, device, equipment and medium for license service

Abstract

This disclosure relates to an authentication method, apparatus, device, and medium for a licensing service. The method includes: creating multiple containers corresponding to each licensing service; creating a corresponding virtual Ethernet device pair for each container; connecting a first device object to the network namespace of the container and a second device object to the host network of a physical server; receiving first license request data sent by a first client of the first licensing service and determining the IP address of the first client from the first license request data; querying a routing table configuration file based on the IP address of the first client to determine the first container corresponding to the IP address of the first client; and sending the first license request data from the host network to the first container via the second device object and the first device object corresponding to the first container, so that the first licensing service can perform licensing authorization processing on the first client. According to the technical solution of this disclosure, a highly available deployment of the licensing service is achieved.

Description

Technical Field

[0001] This disclosure relates to the field of licensing service technology, and in particular to an authentication method, apparatus, equipment and medium for licensing services. Background Technology

[0002] In the commercial software and services sector, licensing services are a core component for ensuring the legal use of software and controlling access permissions. Their stability and efficiency directly affect the operational reliability and resource utilization efficiency of enterprise-level applications.

[0003] Currently, the licensing service authorization model generally adopts a single-machine license management method based on network identity parameter identification. This method achieves precise control over the scope of software use by binding the license authorization with the server's network identity parameters (such as IP address, MAC address, port number used by the transport layer to distinguish services, etc.).

[0004] In the above licensing service authorization model, because the license service is bound to the server's network identity parameters, in actual deployment, it is limited by fixed configuration parameters such as the server's network card address, network address, and port service number. This results in each license service instance being deployed and running only on a single server node, forming a rigid "single-node, single-service" architecture. Under this architecture, if a software anomaly occurs on the service node, such as adding an identical service port, it will directly cause the license service to become unavailable. This single-node, single-service authorization management method has a single point of failure risk.

[0005] Furthermore, due to the single-node deployment architecture, it is impossible to leverage service-level parallel processing mechanisms to improve authorization efficiency. When a large number of clients in the working network concurrently initiate authorization requests, a single license service instance needs to process the requests in a serial or limited parallel manner, resulting in request queue accumulation, extended response time, and failure to fully improve resource utilization, thus failing to fully utilize the parallel characteristics of service-level processing. Summary of the Invention

[0006] To address the aforementioned technical problems, this disclosure provides an authentication method, apparatus, device, and medium for licensed services.

[0007] In a first aspect, embodiments of this disclosure provide an authentication method for a licensed service, applied to a single physical server, the method comprising: For multiple licensed services, create multiple corresponding containers for each licensed service; among them, each container corresponding to the same licensed service uses the same network identity parameters; For the plurality of containers, a corresponding virtual Ethernet device pair is created for each container; each virtual Ethernet device pair includes a first device object and a second device object; Connect the first device object to the network namespace of the container, and connect the second device object to the host network of the physical server; Receive first license request data sent by a first client of a first license service, and determine the IP address of the first client from the first license request data; the first license service is any one of the plurality of license services; The routing table configuration file is queried based on the IP address of the first client to determine the first container corresponding to the IP address of the first client; wherein, the routing table configuration file includes multiple routing tables, and the routing tables indicate the mapping relationship between the IP addresses of the clients of the licensed service and the containers; The first license request data is sent from the host network to the first container via the second device object and the first device object corresponding to the first container, so that the first license service can perform license authorization processing on the first client.

[0008] Secondly, embodiments of this disclosure provide an authentication device for a licensing service, applied to a single physical server, the device comprising: The first creation unit is used to create multiple containers for each licensed service; wherein, each container corresponding to the same licensed service uses the same network identity parameters. The second creation unit is used to create a corresponding virtual Ethernet device pair for each of the plurality of containers; each virtual Ethernet device pair includes a first device object and a second device object. A configuration unit is used to connect the first device object to the network namespace of the container and to connect the second device object to the host network of the physical server. The receiving unit is configured to receive first license request data sent by a first client of a first license service, and determine the IP address of the first client from the first license request data; the first license service is any one of the plurality of license services; The determining unit is configured to query the routing table configuration file based on the IP address of the first client to determine the first container corresponding to the IP address of the first client; wherein, the routing table configuration file includes multiple routing tables, and the routing tables indicate the mapping relationship between the IP addresses of the clients of the licensed service and the containers; The licensing unit is used to send the first license request data from the host network to the first container through the second device object and the first device object corresponding to the first container, so that the first licensing service can perform license authorization processing on the first client.

[0009] Thirdly, embodiments of this disclosure provide an electronic device, including: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the authentication method for the licensing service described in the first aspect.

[0010] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the authentication method for the licensing service described in the first aspect.

[0011] Compared with the prior art, the technical solution provided in this disclosure has the following advantages: By creating multiple containers for each license service and allowing multiple containers with the same network identity parameters to coexist, and creating a corresponding virtual Ethernet device pair for each container, the first device object and the second device object respectively access the network namespace of the container and the host network of the physical server, a multi-copy license service framework is realized on a single physical server. Then, when license request data is received, the routing table is queried through the client's IP address to select the communication object according to the external client's IP address, so as to accurately route the license request data to the container of the corresponding license service. This can extend the authorization access based on the single-process mode to the parallel authorization mode of multiple service nodes, improve the stability and resource utilization of the system, and realize the high availability deployment of the license service. Attached Figure Description

[0012] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0013] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A schematic flowchart illustrating an authentication method for a licensing service provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram illustrating an application scenario of a licensing service provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of the structure of an authentication device for a licensing service provided in an embodiment of this disclosure. Detailed Implementation

[0015] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0016] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0017] Figure 1 This is a flowchart illustrating an authentication method for a licensing service provided in an embodiment of this disclosure. The method provided in this embodiment can be executed by an authentication device for the licensing service. This device can be implemented using software and / or hardware and can be integrated into any electronic device with computing capabilities.

[0018] like Figure 1 As shown, the authentication method for the licensing service provided in this disclosure embodiment may include: Step 101: For multiple licensed services, create multiple corresponding containers for each licensed service.

[0019] In this embodiment, multiple different licensed services can be deployed on a single physical server, and for each licensed service, at least two containers are created for that licensed service.

[0020] Taking the first license service as an example, the first license service can be any one of multiple license services. Multiple containers are created for each license service, including: creating multiple containers for the first license service based on the container image, setting the containers to no default network mode, creating an independent network namespace for each container, and configuring the multiple containers of the first license service to have the same IP address (Internet Protocol address) and MAC address (Media Access Control address).

[0021] As an example, the first license service includes multiple containers, Container 1 and Container 2. Container 1 and Container 2 are configured with no default network mode. Independent network namespaces are created for Container 1 and Container 2, and they are configured with the same IP address and MAC address. Containers can be created based on the nginx:alpine image. The independent network namespaces allow both to use the same IP address and MAC address without conflict. The no default network mode (--net none) avoids interference from automatic container network configuration.

[0022] Step 102: For multiple containers, create a corresponding virtual Ethernet device pair for each container.

[0023] Each virtual Ethernet device pair includes a first device object and a second device object.

[0024] Step 103: Connect the first device object to the container's network namespace and connect the second device object to the physical server's host network.

[0025] In this embodiment, the virtual Ethernet device is, for example, a veth device. By connecting one end of the virtual Ethernet device pair, namely the first device object, to the network namespace of the container as a network card within the container, and connecting the other end of the virtual Ethernet device pair, namely the second device object, to the host network to be associated with the core bridge, a Layer 2 interconnection between the container and the host network is achieved.

[0026] As an example, taking container one and container two as examples, container one and container two of the first license service use the same IP address and MAC address. For the second device objects of container one and container two, different virtual interface IP addresses are set respectively, that is, the second device objects use different IP addresses.

[0027] Step 104: Receive first license request data sent by the first client of the first license service, and determine the IP address of the first client from the first license request data.

[0028] Step 105: Query the routing table configuration file based on the IP address of the first client to determine the first container corresponding to the IP address of the first client.

[0029] Step 106: The first license request data is sent from the host network to the first container through the second device object and the first device object corresponding to the first container, so that the first license service can perform license authorization processing on the first client.

[0030] In this embodiment, after configuring each container of each licensed service, a routing table configuration file is configured. The routing table configuration file includes multiple routing tables, which indicate the mapping relationship between the IP addresses of the licensed service's clients and the containers.

[0031] As an example, multiple routing tables correspond to multiple containers; for instance, container one corresponds to routing table one. Each routing table records one or more client IP addresses. When a permission request is received, the routing table is queried based on the client IP address from which the request originated. For example, if the corresponding IP address is found in routing table one, the permission request is routed to container one via the host network, the second device object, and the first device object. This enables precise traffic forwarding based on external client IP addresses, directing requests from different sources to the corresponding containers, thus fulfilling the business requirement of selecting the communication object by source IP. In this embodiment, the first license request data is sent from the host network to the first container so that the first license service can perform license authorization processing on the first client. This includes: parsing the first network identity parameter of the license certificate in the license request data through the first container, and matching the first network identity parameter with the second network identity parameter of the first container. When the match is consistent, the first license service starts and provides authorization verification function. The network identity parameters include IP address, MAC address, etc.

[0032] In related technologies, the authorization logic of licensing services relies on the inherent network identity parameters of the server as the core identifier. Because the licensing service is strongly bound to the server's network identity parameters, each licensing service instance can only be deployed and run on a single server node, forming a rigid "single-node, single-service" architecture. This results in poor deployment stability, availability, and low resource utilization. Furthermore, there is a significant technical incompatibility between the existing container service cluster configuration methods and the deployment requirements of licensing services. Because container service clusters use a dynamic network configuration mechanism to achieve flexible service scheduling and expansion, the network identity parameters of container instances are dynamically allocated by the cluster network plugin. In contrast, the authorization logic of existing licensing services relies on the static binding of server network identity parameters. The pre-configured network identity information in the license certificate must completely match the operating environment to pass verification. This static binding mechanism contradicts the service configuration requirements of service clusters based on networks with different IP and MAC address nodes.

[0033] According to the technical solution of this disclosure, by creating multiple containers for each licensed service and having multiple containers with the same network identity parameters coexist, and by creating a corresponding virtual Ethernet device pair for each container, and by connecting the first device object and the second device object to the network namespace of the container and the host network of the physical server respectively, a multi-copy licensed service framework is realized on a single physical server. Then, when licensed request data is received, the routing table is queried through the client's IP address to select the communication object based on the external client's IP address, so as to accurately route the licensed request data to the container of the corresponding licensed service. This can extend the authorization access based on the single-process mode to the parallel authorization mode of multiple service nodes, improve the stability and resource utilization of the system, and realize the high availability deployment of the licensed service.

[0034] Based on the above embodiments, Figure 2 This is a schematic diagram illustrating an application scenario of a licensing service provided in an embodiment of this disclosure. Figure 2 The diagram shows: License Service A and License Service B; License Service A has two image containers 1 and 2, and License Service B has two image containers 3 and 4, as a high availability solution; physical servers; Client 1 and Client 2 of License Service A; Client 3 and Client 4 of License Service B.

[0035] In this embodiment of the disclosure, the steps for configuring the network interface, enabling data forwarding function, and deploying containerized licensing service in the server system are described below: Step 1: Configure the IP address of the physical network interface of the physical server hosting the licensing service. This step specifically includes: executing a network configuration command with superuser privileges to set the IPv4 address of the network connection interface named "ens192" to static allocation mode, and specifying the IP address as 172.18.1.100 / 24. This IP address will be the data communication path for licensing service A. Next, add the IPv4 address 172.18.2.100 / 24 ​​to the same interface; this IP address will be the data communication path for licensing service B. Activate the modified network connection configuration from the previous step.

[0036] Step 2: Enable IP forwarding and proxy ARP (Address Resolution Protocol) functionality. This step specifically includes: enabling the physical server's system-wide IPv4 forwarding function; enabling proxy ARP functionality for interface ens192, allowing it to respond to ARP requests from other networks, in order to respond to client ARP protocol requests; and enabling proxy ARP support in the private VLAN environment on the physical server.

[0037] Step 3: Configure static ARP proxy entries. This step specifically includes adding an ARP proxy rule for Permission Service A (e.g., 172.18.1.1) on interface ens192. Similarly, add an ARP proxy rule for 172.18.2.1: `sudo ipneigh add proxy 172.18.2.1 dev ens192`.

[0038] Step 4: Create custom routing tables. This step specifically includes adding four custom routing tables to the routing table configuration file, labeled t100, t200, t300, and t400, corresponding to numbers 100 to 400.

[0039] Step 5: Configure policy routing rules. This step specifically includes: adding policy rules that cause packets from client 1 with IP address 172.18.1.61 to query routing tables t100 and t200; adding policy rules that cause packets from client 2 with IP address 172.18.1.62 to query routing tables t100 and t200; adding policy rules that cause packets from client 3 with IP address 172.18.2.61 to query routing tables t300 and t400; and adding policy rules that cause packets from client 4 with IP address 172.18.2.62 to query routing tables t300 and t400.

[0040] Step Six: Configure Firewall Forwarding Policies. This step specifically includes: adding a rule in the FORWARD chain of the routing table to allow packets flowing from the virtual Ethernet device (matched with veth+) to ens192. Adding a rule in the FORWARD chain of the routing table to allow reverse traffic to flow from ens192 to the virtual Ethernet device.

[0041] Step 7: Start the containerized service. This step specifically includes: starting four Nginx containers running in non-network mode, namely container 1, container 2, container 3, and container 4, and mounting the corresponding local directories into the containers. Obtain the process ID of each container for subsequent network configuration.

[0042] Step 8: Configure container virtual network interfaces and routes. This involves creating virtual Ethernet device pairs for each of the four containers, configuring the MAC address, IP address, routing table, and default gateway for the network interfaces within each container. Taking container 1 as an example: Create virtual Ethernet device pairs veth1 and lic0, and move lic0 to the network namespace of container 1; rename the interface to eth0 within the container and set its MAC address to 02:42:ac:11:00:02. Assign the IP address 172.18.1.1 / 32 to license service A for container 1 and enable the interface. Add point-to-point routes and a default gateway, setting the default gateway to the address of the virtual interface veth1, such as... Figure 2 The address shown is 169.254.1.1. Containers 2, 3, and 4 can refer to container 1 and use different addresses (such as 169.254.2.1, 169.254.3.1, and 169.254.4.1).

[0043] Step Nine: Activate the virtual interfaces on the host machine and configure routing. This step specifically includes: enabling virtual interfaces veth1 to veth4 on the host machine and assigning link-local addresses. Add static routes pointing to the corresponding virtual interfaces in each custom routing table. Through the above steps, the system implements advanced network functions such as multi-IP address binding, ARP proxy, policy routing, container network isolation and interconnection, which are suitable for service deployment needs in complex network environments.

[0044] The second device object uses a different IP address, and the mapping relationship is specifically the relationship between the IP address of the second device object and the IP address of the client. Thus, based on the fact that each container corresponding to the same license service uses the same network identity parameters to adapt to the authorization logic of the license service, the license request data can be accurately routed to the specified container, which also meets the needs of different business scenarios.

[0045] In one embodiment of this disclosure, multiple routing tables include routing table one and routing table two, where routing table one corresponds to container one and routing table two corresponds to container two. Determining the first container corresponding to the IP address of the first client by querying the routing table configuration file includes: querying multiple routing tables based on the IP address of the first client; if the IP address of the first client is found in routing table one, then container one is determined to be the first container; if the IP address of the first client is found in routing table two, then container two is determined to be the first container.

[0046] As an example, communication data destined for licensed service A with IP address 169.254.1.1 is routed through routing table t100. Similarly, routes are configured in tables t200 to t400 for veth2 to veth4 respectively. This enables precise routing of different clients to a specified container under the same licensed service.

[0047] In one embodiment of this disclosure, container one is the container currently providing services, and container two is a backup container. The authentication method for the licensed service further includes: monitoring multiple containers of the first licensed service to detect container availability; when an anomaly is detected in container one, deleting route table one of container one from multiple routing tables, and generating a mapping relationship with container two based on the client IP address in route table one to switch the service to container two; regenerating and configuring container one, and restoring route table one, and jumping back to the monitoring step; when an anomaly is detected in container two, regenerating and configuring container two.

[0048] As an example, step 1001: Enable all service container status monitoring functions, set the monitoring interval, and check container availability. Step 1002: After the detection clock cycle arrives, check if the service container status is normal. If normal, repeat this step; otherwise, proceed to step 1003. Step 1003: Determine if the container currently providing the service is abnormal. If licensed service A container 1 is abnormal, proceed to step 1004; otherwise, proceed to step 1005. Step 1004: Delete the communication data query t100 route table with the target address of licensed service A, add the communication data query t200 route table with the target address of licensed service A, and convert the service to container 2. Destroy container 1, regenerate licensed service A container 1, configure the network address and gateway route of licensed service A container 1, and proceed to step 1002. Step 1005: If the standby container 2 is abnormal, destroy licensed service A container 2, regenerate licensed service A container 2, reconfigure the same network address and gateway route, and proceed to step 1002. Therefore, when a problem occurs in the licensed service and a backup service is switched, the service can be automatically switched over without the client needing to change the configuration of the licensed service. This achieves a seamless service switch for users and reduces the cost of secondary deployment and adjustment during service switching.

[0049] In one embodiment of this disclosure, the authentication method for the licensed service further includes: obtaining the number of containers and setting the available resources for each container based on the number of containers, wherein the available resources are negatively correlated with the number of containers.

[0050] In one embodiment of this disclosure, the authentication method for the licensed service further includes: obtaining the business type involved in the licensed service; and determining the available resources of each container corresponding to the licensed service based on the business type.

[0051] In summary, the method of this disclosure, based on a customized network structure, solves the problem of "containers with the same network identifier cannot coexist" in license server deployment through dedicated network namespaces and multi-level subnet routing, providing a new network isolation paradigm for multi-instance service deployment. Furthermore, the policy-based routing non-NAT directed forwarding mechanism ensures transparent access from external hosts to container services, achieving a low-cost, high-availability technical solution for single-node license service scenarios. In addition, this method does not require high-end hardware switches such as VLANs, VXLAN, IEEE 802.1Q, or MVRP protocols; it only requires a simple interconnection system of ordinary switches with basic switching capabilities, significantly reducing the hardware cost of high-availability solutions and increasing the market competitiveness of license service products.

[0052] The following describes the implementation of the functional modules of this solution.

[0053] This solution constructs a technical system with multiple functional modules working together. The architecture is based on a single-machine server environment and deploys multiple licensed service nodes through Docker containerization technology. External physical hosts are interconnected with the server's physical network cards through simple switches. The architecture breaks through the constraints of traditional networks. While meeting the conditions of "same IP / MAC address, single physical network card communication, no NAT technology dependence, and compatibility with simple switches", it achieves functional decoupling through modular design, thus achieving high availability deployment and transparent access to licensed services.

[0054] The system includes multiple functional modules: physical network configuration module, forwarding policy optimization module, network isolation and interconnection module, container deployment management module, traffic direction control module, application service and data management module, and service monitoring and management module.

[0055] The physical network configuration module, serving as the foundational network access layer of the architecture, is responsible for adapting the server's physical network interface card (NIC) to external networks, providing the underlying physical channel for communication between containers and external hosts. The module implementation includes: Physical NIC configuration: configuring parameters for the server's unique data communication NIC (ens192), including IP address (as the container's default gateway), subnet mask, etc., ensuring Layer 3 connectivity with the external network (172.18.1.0 / 24 network segment). External device compatibility: adapting to simple switches without advanced features such as VLANs and routing, ensuring Layer 2 frames can be forwarded normally by disabling advanced NIC features (such as 802.1Q tags). Configuration persistence: using standardized network configuration tools (including identifiable connection names) to ensure NIC parameters remain valid after server restarts. Thus, by simplifying physical network configuration, the adaptation threshold to simple external network environments is lowered, providing a stable physical communication foundation for upper-layer modules.

[0056] The forwarding policy optimization module addresses traffic forwarding restrictions imposed by Docker's default security policies, ensuring normal forwarding of cross-network traffic between containers and external hosts. The module's responsibilities include: Security policy adaptation: Customizing forwarding rules to allow container-related traffic (via specified bridges or virtual devices) to pass through Docker's default iptables FORWARD chain policy (which is set to DROP). Forwarding scope control: Only opening forwarding paths necessary for communication between containers and external hosts, avoiding security risks caused by indiscriminately opening network forwarding. Rule persistence: Ensuring that custom forwarding rules remain effective after system restarts, guaranteeing service continuity. Thus, while maintaining Docker's basic security, precise rule configuration breaks through traffic forwarding restrictions, ensuring connectivity between containers and external networks.

[0057] The network isolation and interconnection module is used to isolate network resources between two containers while establishing an interconnection channel between the container and the server host network, enabling "coexistence of containers with the same IP / MAC address". Specifically, network namespace management: Independent network namespaces are created for each container, allowing them to use the same IP address, MAC address, and port 80 without conflict. Virtual device interconnection: A dedicated veth device pair is created for each container, with one end connected to the container namespace (acting as the container's internal network interface card) and the other end connected to the host network (associated with the core bridge), achieving Layer 2 interconnection between the container and the host network. Container network configuration: Network interface card activation, IP / MAC address configuration, and default route settings are completed within the container namespace, ensuring the container has independent network communication capabilities. Thus, based on the Linux kernel's network isolation mechanism, the resource conflict problem of the same network identifier is fundamentally solved, while efficient cross-namespace traffic interaction is achieved through virtual devices.

[0058] The container deployment management module is responsible for the standardized deployment of licensed service containers, ensuring that containers meet the requirements of "identical configuration, independent operation, and controllable resources." The module's implementation includes: Container creation: Creating containers based on the nginx:alpine image, using a no-default network mode to avoid interference from Docker's automatic network configuration with custom network solutions. Resource control: Limiting the CPU, memory, and other resources of containers to prevent a single container from excessively consuming server resources and affecting overall stability. Basic configuration: Ensuring the normal startup of the web service (port 80) within the container, laying the foundation for subsequent network access and traffic interaction. Thus, through a standardized deployment process and resource control mechanism, it ensures that two containers run independently under a unified configuration baseline, providing support for the consistency of upper-layer services.

[0059] The traffic redirection control module achieves precise traffic forwarding based on external host IPs, directing requests from different sources to the corresponding containers, fulfilling the business requirement of "selecting the communication object by source IP". The module includes: Policy routing planning: defining routing rules based on source IPs, configuring dedicated routing tables for external hosts, and specifying traffic forwarding paths. Forwarding path binding: binding traffic from different source IPs to the corresponding veth devices in the containers. Route effectiveness guarantee: ensuring that policy routing takes effect immediately through operations such as refreshing the route cache, guaranteeing the real-time performance and accuracy of traffic forwarding. Therefore, it abandons traditional NAT technology and uses policy routing to achieve address translation-free redirection, ensuring a transparent access experience for external hosts while avoiding the performance overhead and configuration complexity caused by address translation.

[0060] The Application Services and Data Management module is responsible for the application deployment and data persistence of the licensed services, ensuring that service content is maintainable, data is retainable, and high availability is guaranteed. The module includes: Data Volume Mapping: Binding the host directory to the root directory of the web service within the container, enabling persistent storage and direct maintenance of static service resources (such as license pages and configuration files) on the host side. Service Content Synchronization: To ensure consistency of service content between two containers, a scheduled synchronization mechanism can be used to align the content of the host-side directories. High Availability Guarantee: Integrating container health checks and automatic restart mechanisms, combined with log monitoring, to achieve rapid detection and recovery of service anomalies. Application Configuration Optimization: Optimizing the performance and stability parameters of the web service (Nginx) through custom configuration file mapping. Thus, application services and data management are separated, ensuring both lightweight container operation and flexible management and high availability support for service content through host-side data control.

[0061] The service monitoring and management module is responsible for monitoring the image services of licensed services and managing their routing tables, ensuring high availability and reliability of licensed services. The module includes: Service monitoring: configuring time intervals to periodically check the health of the containers hosting the services, as well as the availability of service IPs and ports. Service creation: creating backup licensed service containers based on the status of the licensed services. Container management: discovering and shutting down abnormal service containers. Routing table management: adding new routes and deleting old routes to enable licensed service switching. Thus, by monitoring the service status, service containers are managed and routing tables are quickly switched.

[0062] Figure 3 This is a schematic diagram of the structure of an authentication device for a licensing service provided in an embodiment of this disclosure, as shown below. Figure 3 As shown, the authentication device for this licensed service includes: The first creation unit 31 is used to create multiple containers for each licensed service; wherein each container corresponding to the same licensed service uses the same network identity parameters. The second creation unit 32 is used to create a corresponding virtual Ethernet device pair for each of the plurality of containers; each virtual Ethernet device pair includes a first device object and a second device object. Configuration unit 33 is used to connect the first device object to the network namespace of the container and connect the second device object to the host network of the physical server; The receiving unit 34 is configured to receive first license request data sent by a first client of the first license service, and determine the IP address of the first client from the first license request data; the first license service is any one of the plurality of license services; The determining unit 35 is configured to query the routing table configuration file based on the IP address of the first client to determine the first container corresponding to the IP address of the first client; wherein, the routing table configuration file includes multiple routing tables, and the routing tables indicate the mapping relationship between the IP addresses of the clients of the licensed service and the containers; The licensing unit 36 ​​is used to send the first license request data from the host network to the first container through the second device object and the first device object corresponding to the first container, so that the first license service can perform license authorization processing on the first client.

[0063] The authentication device for licensing services provided in this disclosure can execute the authentication method for any licensing service provided in this disclosure, and has the corresponding functional modules and beneficial effects for executing the method. Content not described in detail in the device embodiments of this disclosure can be referred to the description in any method embodiment of this disclosure.

[0064] This disclosure also provides an electronic device including one or more processors and a memory. The processor may be a central processing unit (CPU) or other processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions. The memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor may execute the program instructions to implement the methods of the embodiments of this disclosure above and / or other desired functions. Various contents such as input signals, signal components, and noise components may also be stored in the computer-readable storage medium.

[0065] In one example, the electronic device may also include input and output devices, which are interconnected via a bus system and / or other forms of connection. Furthermore, the input device may include, for example, a keyboard, a mouse, etc. The output device can output various information to the outside, including determined distance information, direction information, etc. The output device may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc. In addition, depending on the specific application, the electronic device may include any other suitable components such as a bus, input / output interfaces, etc.

[0066] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform any of the methods provided in the embodiments of this disclosure.

[0067] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0068] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform any of the methods provided in the embodiments of this disclosure.

[0069] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0070] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0071] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An authentication method of a license service, characterized by, Applied to a single physical server, the method includes: For multiple licensed services, create multiple corresponding containers for each licensed service; among them, each container corresponding to the same licensed service uses the same network identity parameters; For the plurality of containers, a corresponding virtual Ethernet device pair is created for each container; each virtual Ethernet device pair includes a first device object and a second device object; Connect the first device object to the network namespace of the container, and connect the second device object to the host network of the physical server; Receive first license request data sent by a first client of a first license service, and determine the IP address of the first client from the first license request data; the first license service is any one of the plurality of license services; The routing table configuration file is queried based on the IP address of the first client to determine the first container corresponding to the IP address of the first client; wherein, the routing table configuration file includes multiple routing tables, and the routing tables indicate the mapping relationship between the IP addresses of the clients of the licensed service and the containers; The first license request data is sent from the host network to the first container via the second device object and the first device object corresponding to the first container, so that the first license service can perform license authorization processing on the first client.

2. The method of claim 1, wherein, The creation of multiple containers for each licensed service includes: Multiple containers are created for the first licensed service based on the container image; the multiple containers for the first licensed service include container one and container two. Set both container one and container two to a no-default network mode; Create independent network namespaces for container one and container two respectively, and configure container one and container two with the same IP address and MAC address.

3. The method of claim 2, wherein, The plurality of routing tables include routing table one and routing table two, where routing table one corresponds to container one and routing table two corresponds to container two. The step of querying the routing table configuration file based on the IP address of the first client to determine the first container corresponding to the IP address of the first client includes: The multiple routing tables are queried based on the IP address of the first client; If the IP address of the first client is found in the routing table, then container one is determined to be the first container; If the IP address of the first client is found in the second routing table, then the second container is determined to be the first container.

4. The method of claim 2, wherein, The method further includes: Monitor multiple containers of the first licensed service to detect container availability; wherein, container one is the container currently providing the service, and container two is a backup container; When an anomaly is detected in container one, the routing table one of container one is deleted from the multiple routing tables, and a mapping relationship with container two is generated based on the client IP address in the routing table one, so as to switch the service to container two. Regenerate and configure container one, and restore routing table one, then jump back to the monitoring steps; If an anomaly is detected in container two, container two is regenerated and configured.

5. The method of claim 1, wherein, The second device object uses a different IP address, and the mapping relationship is specifically the relationship between the IP address of the second device object and the IP address of the client.

6. The method of claim 1, wherein, The method further includes: Obtain the quantity of the containers; The available resources for each container are set according to the number of containers; wherein, the available resources are negatively correlated with the number of containers; And / or, Obtain the types of business involved in the licensed services; The available resources for each container corresponding to the licensed service are determined based on the business type.

7. An authentication device for a license service, characterized by comprising: The device, applied to a single physical server, includes: The first creation unit is used to create multiple containers for each licensed service; wherein, each container corresponding to the same licensed service uses the same network identity parameters. The second creation unit is used to create a corresponding virtual Ethernet device pair for each of the plurality of containers; each virtual Ethernet device pair includes a first device object and a second device object. A configuration unit is used to connect the first device object to the network namespace of the container and to connect the second device object to the host network of the physical server. The receiving unit is configured to receive first license request data sent by a first client of a first license service, and determine the IP address of the first client from the first license request data; the first license service is any one of the plurality of license services; The determining unit is configured to query the routing table configuration file based on the IP address of the first client to determine the first container corresponding to the IP address of the first client; wherein, the routing table configuration file includes multiple routing tables, and the routing tables indicate the mapping relationship between the IP addresses of the clients of the licensed service and the containers; The licensing unit is used to send the first license request data from the host network to the first container through the second device object and the first device object corresponding to the first container, so that the first licensing service can perform license authorization processing on the first client.

8. An electronic device, comprising: include: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the authentication method for the licensed service as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, implements the authentication method for the licensed service as described in any one of claims 1-6.

Images