Deployment methods and electronic devices for the program

Abstract

This application relates to the field of data processing technology, and in particular to a method and electronic device for deploying a program. The method includes: receiving a response request from the development environment for the development program, triggering a local verification function to verify the local environment and obtain a verification result; in response to a successful verification result, constructing image data corresponding to the development program, generating a deployment request based on the image data, sending the deployment request to the production environment for verification, and generating a pull instruction for the image data after successful verification; receiving the pull instruction from the production environment, sending the image data to the production environment for deployment and execution. This method ensures the security of the image data obtained by the production environment, eliminates the need for manual copying and importing, and is simple, fast, and saves labor costs, improving program deployment efficiency.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and more particularly to a method for deploying a program and an electronic device. Background Technology

[0002] Currently, security requirements are quite strict during program development, so the development environment and production environment are isolated.

[0003] Therefore, if developers determine the program code based on the development environment, they need to manually copy the program code and then manually transfer it to the production environment for deployment via storage, which is cumbersome and has high labor costs. Summary of the Invention

[0004] In view of this, the purpose of this application is to propose a program deployment method and electronic device to solve the technical problem that the current method of manually copying program code from the development environment and transferring it to the production environment for deployment is cumbersome and has high labor costs.

[0005] To achieve the above objectives, this application provides a method for deploying a program, applied to a local terminal, wherein the local terminal is connected to both a development environment and a production environment, and the development environment is isolated from the production environment.

[0006] The method includes: Upon receiving the response request from the development environment for the development program, the local verification function is triggered to verify the local environment and obtain the verification result. In response to the verification result being successful, image data corresponding to the development program is constructed, a deployment request is generated based on the image data, and the deployment request is sent to the production environment for verification by the production environment. After the deployment request is verified, a pull instruction for the image data is generated. Upon receiving a pull command from the production environment, the image data is sent to the production environment for deployment and operation.

[0007] Based on the same inventive concept, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor implements the method described above when executing the computer program.

[0008] As can be seen from the above, the deployment method and electronic device provided in this application, because the development environment and production environment are isolated and cannot communicate directly, a local terminal is set up to connect to both the development environment and the production environment. When the local terminal receives a response request from the development environment for the development program, determining that the development environment needs to deploy the program in the production environment, the local terminal, to ensure security, first verifies the local environment. Only after successful verification will it build the corresponding image data for the development program in the development environment and generate a corresponding deployment request based on this image data. This deployment request is then sent to the production environment, allowing it to verify the request. After successful verification confirms the image data is trustworthy, a pull command is generated and sent to the local terminal, which then sends the image data to the production environment. This enables the production environment to accurately deploy and run the trustworthy image data. This ensures the security of the image data obtained by the production environment and eliminates the need for manual copying and importing. The entire process is simple, fast, saves labor costs, and improves program deployment efficiency. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram illustrating an application scenario of the program deployment method according to an embodiment of this application; Figure 2 A flowchart illustrating a method for deploying a procedure according to an embodiment of this application; Figure 3 This is a structural block diagram of a program deployment apparatus according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0012] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this application should have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms "first," "second," and similar terms used in the embodiments of this application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed after the word and their equivalents, without excluding other elements or objects. Terms such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are only used to indicate relative positional relationships; when the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0013] Definitions: CI / CD (Continuous Integration / Continuous Deployment): A method for frequently delivering code changes to the production environment through automated processes.

[0014] Network isolation refers to the inability of two network areas to communicate directly via the TCP / IP protocol, and is typically used for security protection.

[0015] Local Bridge Node: Refers to a computer that has access to both development and production environments (usually a developer's local computer or a dedicated bastion host) and is used to relay data.

[0016] Sandbox Isolation: Using container or virtual machine technology, build tasks are restricted to run in an isolated, limited environment to prevent them from affecting the security of the host machine.

[0017] Dynamic Credentials: These are temporary access tokens that are valid only during task execution and expire immediately after the task ends, replacing long-term static passwords.

[0018] Admission Control: An interceptor deployed in a production cluster to verify the legitimacy of an image (such as signature verification) before the container starts.

[0019] Webhook: A web hook is an event-driven communication mechanism based on HTTP callbacks.

[0020] Jenkins: A sandbox container, is an open-source continuous integration tool developed based on Java.

[0021] ACL: Access Control List. In the field of computer networks and network security, an access control list is a method used to define which users or devices can access network resources.

[0022] Harbor is an open-source image repository that protects images through policies and role-based access control, ensuring that images are scanned and free of vulnerabilities, and signing images as trusted images.

[0023] URL: Uniform Resource Locator.

[0024] In related technologies, industries with high security requirements generally have strict network security requirements during software development. They will divide the network into development and production environments, and physically or logically isolate the two through firewalls to prevent direct communication between them.

[0025] Therefore, after developers submit program code in the development environment, they build an image of the program code in the development environment through a sandbox container (Jenkins). The image is then manually exported as a compressed file and stored in a portable storage device (such as a USB flash drive or hard drive). The image is then manually carried to the production environment and deployed there.

[0026] Drawbacks: This manual process of transferring the program code image from the development environment to the production environment is cumbersome, inefficient, and lacks verification and auditing of the image and removable storage, resulting in lower security.

[0027] In addition, some related technologies, for convenience, expose the development environment and production environment to the network. This allows the image of the program code in the development environment to be transmitted to the production environment via the network, so that the production environment can deploy the image.

[0028] Drawback: The open network exposes production environment ports to the risk of scanning and attack for extended periods, making the production environment vulnerable to intrusion.

[0029] Based on the above description, the principles and spirit of this application will be explained in detail below with reference to several representative embodiments.

[0030] refer to Figure 1This is a schematic diagram illustrating an application scenario of the program deployment method provided in this application embodiment. The application scenario includes a local terminal 101, a development environment 102, and a production environment 103. The development environment 102 and the production environment 103 are network isolated and cannot communicate directly. The local terminal 101 is connected to both the development environment 102 and the production environment 103 via wired or wireless communication networks. The local terminal 101 includes, but is not limited to, desktop computers, mobile phones, mobile computers, tablet computers, media players, personal digital assistants (PDAs), or other electronic devices capable of performing the aforementioned functions.

[0031] After the developers complete the development program in the development environment 102, they will use the development environment 102 to generate a response request for the development program and send the response request to the local terminal 101.

[0032] After receiving the response request from the development environment 102, the local terminal 101 determines that the development environment 102 wants to deploy the development program in the production environment 103. It will first verify the local environment. After the verification passes and the environment of the local terminal 101 is confirmed to be safe, it will build the corresponding image data for the development program, generate the corresponding deployment request based on the image data, and send the deployment request to the production environment 103.

[0033] After receiving the deployment request, the production environment 103 can verify the deployment request. After the verification is successful and the image data is confirmed to be trustworthy, a pull command is generated and sent to the local terminal 101.

[0034] After receiving the pull command, the local terminal 101 will send the image data to the production environment 103.

[0035] Production environment 103 is capable of accurately deploying and running trusted mirror data.

[0036] The following is combined Figure 1 The application scenarios described above illustrate the deployment method of the program according to exemplary embodiments of this application. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way in this regard. Rather, the embodiments of this application can be applied to any applicable scenario.

[0037] Based on the above, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0038] The program deployment method proposed in the embodiments of this application is applied to a local terminal, which is connected to both a development environment and a production environment, and the development environment is isolated from the production environment.

[0039] The local terminal is configured with dual network cards or is route-accessible, enabling it to access both the development and production environments.

[0040] like Figure 2 As shown, the method includes: Step 201: Upon receiving the response request from the development environment for the development program, the local verification function is triggered to verify the local environment and obtain the verification result.

[0041] In practice, the development environment deploys a repository (e.g., a Git repository) for storing program code. Developers can store their programs in the repository, and the development environment will then generate a response request for that program and send it to the local terminal.

[0042] Then, after receiving the response request from the development environment, the local terminal determines that the development environment needs to deploy the development program in the production environment. However, at this time, it is uncertain whether the local environment of the local terminal is secure. Therefore, the local terminal will verify the local environment (for example, by using security software to perform antivirus verification and / or system patch verification) and obtain the verification result.

[0043] The verification result includes: verification passed or verification failed. If the verification passes, subsequent steps can continue. If the verification fails (for example, the local terminal is under attack), a response status code will be generated and sent back to the development environment, and subsequent steps will be stopped.

[0044] Step 202: In response to the verification result being successful, construct image data corresponding to the development program, generate a deployment request based on the image data, send the deployment request to the production environment for verification by the production environment, and generate a pull instruction for the image data after the deployment request is verified.

[0045] In practice, after verification, the local terminal performs image processing on the development program in the development environment to obtain the image data corresponding to the development program. Then, it extracts relevant information from the image data (e.g., name, function, version number, and / or space usage), and generates a deployment request based on this information, sending it to the production environment. Upon receiving the deployment request, the production environment verifies it to ensure its security. If the verification passes, it generates a pull command for the image data; if the verification fails, execution terminates.

[0046] Step 203: Upon receiving the pull instruction from the production environment, the image data is sent to the production environment for deployment and operation.

[0047] In practice, once the local terminal receives the pull command, it can determine that the image data is secure and trustworthy, and then send the image data to the production environment. In this way, the local terminal, as a trusted local bridging node, can securely and controllably achieve automated cross-network CI / CD deployment between the development and production environments.

[0048] In the production environment, there are image repositories (e.g., Harbor repositories) and business clusters (e.g., Kubernetes clusters). The image repository is used to store various image data pulled from the repository, and the business cluster is used to deploy and run business applications based on the image data.

[0049] The above solution involves setting up a local terminal connected to both the development and production environments. When the local terminal receives a response request from the development environment for a development program, it determines that the development environment needs to deploy the program in the production environment. To ensure security, the local terminal first verifies the local environment. Only after successful verification will it build the corresponding image data for the development program in the development environment and generate a deployment request based on this image data. This deployment request is then sent to the production environment for verification. Once the production environment confirms the image data is trustworthy, it generates a pull command and sends it to the local terminal. The local terminal then sends the image data to the production environment, enabling the production environment to accurately deploy and run the trustworthy image data. This approach ensures the security of the image data received by the production environment and eliminates the need for manual copying and importing. The entire process is simple, fast, saves labor costs, and improves program deployment efficiency.

[0050] In some embodiments, step 201 includes: Step 2011: Configure the link address between the development environment and the development environment, and listen for response requests for the development program sent by the development environment based on the link address.

[0051] In practice, the local terminal can be pre-configured with the corresponding link address (e.g., URL address), so that the development environment can be monitored in real time based on the link address.

[0052] If the development program is stored in the repository in the development environment, the repository will be updated, which will generate a response request and send the response request to the local terminal.

[0053] Step 2012: Based on the response request, perform local verification and signature verification of the response request to obtain the verification result.

[0054] In practice, once the local terminal detects a response request, it determines that the development environment has been updated and needs to be deployed to the production environment. To ensure the reliability of the local environment, the local terminal performs local verification; furthermore, to ensure the reliability of the development program, it also performs signature verification on the response request. If both local and signature verifications pass, the verification result is "verification passed"; if either fails, the verification result is "verification failed," and the subsequent process stops.

[0055] With the above approach, after listening to the response request from the development environment, the local terminal will perform local verification to determine the reliability of the local environment, and will also perform signature verification on the response request to determine the reliability of the response request. The verification results obtained in this way are more accurate, and subsequent execution can only continue after the verification result is passed, thus improving security.

[0056] In some embodiments, step 2011 includes: Step 20111: Deploy the agent program, bind the agent program to the network interface, and configure the link address between the agent program and the development environment based on the network interface.

[0057] In practice, an agent program (e.g., LocalAgent, a local bridging control agent) is deployed on the local terminal. This agent program can be a background daemon developed based on Python, Go, or Java.

[0058] After starting an agent program (e.g., Local Agent) on the local terminal, the agent program can bind to a local network interface (e.g., a specific port TCP 8080), and can then listen on that network interface.

[0059] The local terminal will preset a key (e.g., a Webhook Secret) in the configuration file corresponding to the agent program for subsequent legitimate verification.

[0060] Local terminals can configure link addresses (e.g., URL addresses) based on the local network (e.g., public IP or intranet reachable IP) and network interface.

[0061] Step 20112: Using the proxy program, listen for the response requests sent by the development environment to the network interface for the development program through the link address.

[0062] In practice, the local terminal can select trigger events (e.g., Push Events) through the agent program. This allows the local terminal to start the agent program's listening function and monitor the network interface in real time. If the development environment sends the generated response request for the development program to the network interface via the connection address, the agent program can accurately detect it. In this case, the agent program will perform subsequent local verification and response request signature verification based on the response request.

[0063] The above solution allows for the deployment of a proxy program and the binding of a corresponding network interface to the proxy program, thereby obtaining the corresponding connection address. This enables the development environment to send response requests based on the connection address, ensuring the proxy program can promptly listen for the corresponding response requests through the connection address and guaranteeing the timeliness and accuracy of response request monitoring.

[0064] In some embodiments, after configuring the link address with the development environment in step 2011, and before listening for a response request for the development program from the development environment based on the link address, the following is performed in the development environment: Step A1: Submit the developed application to the repository and generate an application push event.

[0065] In practice, a repository is deployed in the development environment to store various programs being developed. When developers execute code push commands (e.g., the `git push` command), the developed programs are committed to a specified branch in the repository (e.g., the main or release branch in the repository).

[0066] Then, the repository (e.g., the repository server) detects the corresponding branch update and generates a push event. The push event includes at least one of the following metadata: committer information, commit ID, branch name, and timestamp.

[0067] Step A2: Serialize the program push event to generate a data packet in a predetermined format.

[0068] In practice, the repository (e.g., the repository's server) serializes the program push events to obtain data packets (e.g., payloads) in a predefined format (e.g., JSON format).

[0069] Step A3: Generate a corresponding response request based on the data packet and send the response request to the link address.

[0070] In practice, the response request (e.g., an HTTP POST request) includes a request header and a request body. The request header includes an HTTP protocol request header (e.g., Content-Type: application / json) and a signature (e.g., a hash header, X-Gitlab-Token, or X-Hub-Signature), and the request body includes a data packet (e.g., a JSON-formatted data packet payload).

[0071] After receiving the response request, the development environment will send the response request out according to the previously deployed link address, so that the local terminal can listen for the response request in a timely manner based on the link address.

[0072] With the above solution, when developers submit their development programs to the development environment's repository, the development environment can promptly generate data packets in a predetermined format related to the development programs, and generate corresponding response requests based on these data packets, sending them to the link address. This allows the local terminal to promptly listen for the response requests based on the link address, preparing the local terminal to bridge and transmit the development program's image data to the production environment.

[0073] In some embodiments, step 2012 includes: Step 20121: Perform a security verification on the local environment. After confirming that the security verification is successful, extract the signature information from the response request.

[0074] In practice, security protection software deployed on the local terminal is used to perform security verification on the local environment (e.g., antivirus verification and / or system patch verification). If the security verification passes, the corresponding signature information is extracted from the response request (e.g., the signature hash value is extracted using a local agent) and then the signature information is verified. If the security verification fails, the execution of subsequent steps will be stopped.

[0075] Step 20122: Obtain preset key data, and use the key data to decrypt the response request to determine the decryption information.

[0076] In practice, the agent program deployed on the local terminal (e.g., Local Agent) uses preset key data (e.g., Webhook key) to decrypt the request body (e.g., JSON format data packet payload) in the response request (e.g., HMAC hash calculation) to obtain the decrypted information.

[0077] Step 20123: Match and verify the signature information with the decryption information to obtain the verification result.

[0078] In practice, the agent program on the local terminal will compare and match the obtained decryption information with the signature information. If the two match, the verification result is determined to be successful; if the two do not match, the verification result is determined to be unsuccessful.

[0079] If the verification passes, the subsequent process will continue; if the verification fails, it is determined that the response request may have been subjected to a replay attack or forgery, and the response request is an illegal request. In this case, a corresponding status code (e.g., 403 Forbidden) will be generated and returned to the production environment, and the subsequent process will be terminated.

[0080] The above scheme ensures that after receiving a response request, the local terminal first performs a security check on the local environment. Only after the security check passes can the response request be signed. This ensures that the signature verification process can be carried out in a secure environment, guaranteeing the accuracy of the signature verification and thus making the verification result obtained based on the signature verification more accurate.

[0081] In some embodiments, step 202 includes: Step 2021: In response to the verification result being successful, determine the data packet corresponding to the development program, parse the data packet, and generate a task identifier.

[0082] In practice, after the local terminal's agent program (e.g., Local Agent) confirms that the verification has passed, it uses the agent program to parse the data packet (e.g., JSON format data packet payload) corresponding to the development program extracted from the response request (e.g., HTTP POST request). After parsing out various parameters, it can generate a corresponding task identifier (e.g., Build ID) based on these parameters. This task identifier is used for subsequent association with logs and sandbox containers.

[0083] Step 2022: Determine the target sandbox container corresponding to the task identifier, and control the target sandbox container to execute the startup process.

[0084] In practice, the agent program on the local terminal (e.g., Local Agent) retrieves the corresponding target sandbox container from multiple sandbox containers based on the task identifier, and then controls the target sandbox container to start.

[0085] Step 2023: In response to the successful startup of the target sandbox container, a temporary access token is requested using the target sandbox container.

[0086] In practice, if a target sandbox container exists and it is confirmed that the target sandbox container has started successfully, it will use the target sandbox container to request a temporary access token from the credential management center set up on the local terminal. This temporary access token has an expiration date and exists only in the local terminal's memory, which is periodically updated according to the corresponding expiration date. Because the temporary access token is dynamically changing, its security is higher.

[0087] Step 2024: Using the target sandbox container, pull the development program corresponding to the response request and build image data corresponding to the development program.

[0088] In practice, the target sandbox container will pull the corresponding development program through the communication link between the local terminal and the development environment, and build the image data corresponding to the development program. This image data is a copy of the development program.

[0089] Step 2025: Obtain the basic information of the image data, generate a deployment request based on the basic information and the temporary access token, and send the deployment request to the production environment.

[0090] In practice, the local terminal will open the network channel corresponding to the production environment, allowing access to the production environment, and send the deployment request generated based on the basic information of the image data and the temporary access token to the production environment through the network channel. The production environment will then verify the deployment request so that the image data can be sent to the production environment later.

[0091] With the above approach, the local terminal will not send image data directly. Instead, it will first generate a corresponding deployment request based on the image data and send the deployment request to the production environment. The production environment will then be able to verify the deployment request. Only after the production environment has successfully verified the request will the local terminal be allowed to send the image data, thus improving the security of deploying image data in the production environment.

[0092] In some embodiments, step 2021 includes: Step 20211: Determine the data packet of the predetermined format corresponding to the development program.

[0093] In practice, the agent program on the local terminal (e.g., Local Agent) retrieves a predefined data packet (e.g., a JSON-formatted payload) extracted from the response request.

[0094] Step 20212: Parse the key information in the data packet and generate a task identifier based on the key information.

[0095] In practice, the local terminal's agent program (e.g., Local Agent) parses the data packets to obtain key information. This key information includes at least one of the following: Git Repository URL, Branch Name, Commit Hash (used for signing and tagging subsequent image data), and Trigger User (used for audit logs).

[0096] Then, a task identifier (e.g., Build ID) is generated based on at least one parameter from the obtained key information.

[0097] The above scheme generates a task identifier based on the key information of the parsed data packet, ensuring a higher degree of matching between the obtained task identifier and the corresponding development program, making the task identifier more accurate, and thus making the subsequent identification of sandbox containers based on the task identifier more accurate.

[0098] In some embodiments, step 2022 includes: Step 20221: Invoke the managed container engine and send the task identifier to the managed container engine.

[0099] In practice, a local terminal agent (e.g., Local Agent) is used to establish a connection with the managed container engine (e.g., Docker engine) through a local port (e.g., Unix Socket ( / var / run / docker.sock) or TCP port (localhost:2375)).

[0100] Then you can use the agent to invoke the managed container engine (for example, invoke the Docker engine's API POST / containers / create) and send the task identifier to the managed container engine.

[0101] Step 20222: Using the managed container engine, determine the target sandbox container corresponding to the task identifier from the container library, and control the target sandbox container to execute the startup process.

[0102] In practice, the managed container engine retrieves the container library (e.g., configures isolated namespaces (Network / PID / User Namespace)) and determines the process corresponding to the container identifier (e.g., container ID) of the target sandbox container based on the task identifier. The process corresponding to the target sandbox container is then used to control the startup of the target sandbox container.

[0103] Then, after the target sandbox container starts, it will start a pre-defined script for automatic image processing (e.g., the ENTRYPOINT script). This script will automatically initialize the environment (Jenkins environment) of the target sandbox container based on the passed environment variables, define the pipelines that need to be image processed later (e.g., the Jenkinsfile pipeline), and complete the preparation work for the target sandbox container so that it can build an image of the development program and obtain the corresponding image data.

[0104] Next, after confirming that the target sandbox container has started and initialized, the agent program on the local terminal (e.g., Local Agent) constructs the status code corresponding to the response body (e.g., HTTP response body) (e.g., HTTP 200 OK status code) and sends the status code to the repository in the development environment (e.g., code repository server). In addition, the agent program will also generate audit logs locally (e.g., record "Webhook triggered, container ID xxx started, task ID xxx").

[0105] If the target sandbox container fails to start (e.g., due to insufficient resources), the agent will capture the data indicating the failure and generate a corresponding container startup failure code (e.g., 500 Internal Server Error). This failure code will be sent to the development environment's repository, causing the repository to halt subsequent processes. Simultaneously, the agent will generate an alert notification and send it to the local terminal's display so developers can see and address the alert promptly.

[0106] The above approach enables the managed container engine to accurately identify the target sandbox container from the container library based on the task identifier, and to start the target sandbox container so that the image processing of the development program can be performed after the target sandbox container is successfully started.

[0107] In some embodiments, step 2025 includes: Step 20251: Obtain the offline private key, and use the offline private key to digitally sign the image data to obtain the signed image data.

[0108] In practice, after the target sandbox container completes the image processing of the development program and obtains the image data, the local terminal will obtain a pre-set offline private key and use the offline private key to sign the image data (e.g., image Digest) to obtain the signed image data.

[0109] Step 20252: Open the communication network with the production environment, obtain the basic information of the image data, and generate an initial deployment request based on the basic information.

[0110] In practice, the local terminal will open the communication network corresponding to the production environment, allowing access to the production environment. Specifically, it will configure a whitelist by using the listening port of the image repository (e.g., Harbor repository) corresponding to the production environment, as determined by the load balancing component (e.g., SLB, Server Load Balancing component), to allow access from the local terminal's corresponding network segment.

[0111] Then, the target sandbox container on the local terminal obtains basic information about the image data (e.g., the image data name, size, version number, and / or features) and generates the corresponding initial deployment request (e.g., an HTTP request).

[0112] Step 20253: Add the temporary access token to the initial deployment request to obtain a deployment request, and send the deployment request to the production environment.

[0113] In practice, within the target sandbox container, execute the command (e.g., `docker loginharbor.prod.com -u`). <username>The `-p<temporary token>` option can add a temporary access token to the initial deployment request (e.g., to the header, footer, or middle of the initial deployment request, preferably the header), thus generating a deployment request (e.g., with the HTTP request header carrying Authorization: Bearer<temporary token>), which is then sent to the production environment.

[0114] In this way, after receiving a deployment request, the production environment will verify the temporary access token in the deployment request. Specifically, it will verify whether the temporary access token is valid, expired, and / or whether it has push permissions (e.g., push permission). If any verification fails, the production environment will reject the subsequent process; if all verifications pass, the production environment will generate a pull instruction.

[0115] The corresponding step 203 includes: Upon receiving a pull command from the production environment, the signed image data is sent to the production environment for signature verification. Once the verification is successful, the signed image data is deployed and run.

[0116] In practice, after the local terminal receives the pull command from the production environment, it can determine that the production environment has verified the deployment request and can communicate normally. Then, the local terminal will send the signed image data to the production environment.

[0117] An admission controller (e.g., ValidatingAdmissionWebhook in a Kubernetes cluster) acts as a "gateway" for the production environment (e.g., the K8s API Server). When a local terminal (e.g., the target sandbox container Jenkins in the local terminal) requests the production environment to create a deployment application (e.g., a Pod), the production environment (e.g., the K8s API Server) pauses the request and forwards it to the admission controller. The admission controller runs code to check if the signed image data to be deployed has a valid digital signature. If the signature verification fails, the deployment application (e.g., the Pod) will not be created, preventing subsequent execution of the image data; if the signature verification passes, the deployment application (e.g., the Pod) will be created, and the image data will be deployed and run.

[0118] In addition, after the image data is deployed in the production environment, the development environment will send a termination command to the local terminal, and then the local terminal will destroy the data in the target sandbox container and clear the temporary access token to prevent it from being stolen.

[0119] The above scheme generates an initial deployment request based on the basic information of the image data, and then adds a temporary access token to obtain the deployment request, making the deployment request more secure. After being sent to the production environment, the production environment will accurately verify the temporary access token in the deployment request. Only after the verification is successful will a pull command be generated, so that the local terminal will send the signed image data to the production environment. In order to further improve security, the production environment will also perform signature verification. Only after the signature verification is successful will the image data be accurately deployed and run. In this way, through the verification of the deployment request and the verification of the signed image data, the security and accuracy of the image data obtained by the production environment are guaranteed.

[0120] The deployment method of the program in this application embodiment is described below with reference to a specific example. The specific process is as follows: I. Local verification.

[0121] 1.1 Configure the local terminal.

[0122] Deploy an agent (e.g., LocalAgent, a local bridging control agent) on a local terminal, where the agent can be a background daemon developed based on Python, Go, or Java.

[0123] After starting an agent program (e.g., Local Agent) on the local terminal, the agent program can bind to a local network interface (e.g., a specific port TCP 8080), and can then listen on that network interface.

[0124] The local terminal will preset a key (e.g., a Webhook Secret) in the configuration file corresponding to the agent program for subsequent legitimate verification.

[0125] Local terminals can configure link addresses (e.g., URL addresses) based on the local network (e.g., public IP or intranet reachable IP) and network interface.

[0126] The local terminal can select to trigger events (e.g., Push Events) through the agent program, which will enable the local terminal to start the agent program's listening function and monitor the network interface in real time.

[0127] 1.2, triggers the development program submission event.

[0128] The development environment has a repository deployed to store various programs being developed. When a developer executes a code push command (e.g., the git push command), the program is committed to a specified branch in the repository (e.g., the main or release branch in the repository).

[0129] When a repository (such as a repository server) detects a corresponding branch update, it generates a push event. This push event includes at least one of the following metadata: committer information, commit ID, branch name, and timestamp.

[0130] The repository (such as the repository's server) serializes the program push events to obtain data packets (e.g., payloads) in a predefined format (e.g., JSON format).

[0131] A corresponding response request is generated based on the data packet. This response request (e.g., an HTTP POST request) includes a request header and a request body. The request header includes an HTTP protocol request header (e.g., Content-Type: application / json) and a signature (e.g., a hash header, X-Gitlab-Token, or X-Hub-Signature). The request body includes a data packet (e.g., a JSON-formatted data packet payload).

[0132] After receiving the response request, the development environment will send the response request out according to the previously deployed link address.

[0133] 1.3 Verification process.

[0134] The system uses security protection software deployed on the local terminal to perform security verification on the local environment (e.g., antivirus verification and / or system patch verification). If the security verification passes, it extracts the corresponding signature information from the response request (e.g., using a local agent to extract the signature hash value) and then verifies the signature information. If the security verification fails, it stops the execution of subsequent steps.

[0135] An agent deployed on the local terminal (e.g., Local Agent) uses preset key data (e.g., Webhook key) to decrypt the request body (e.g., JSON format data packet payload) in the response request (e.g., HMAC hash calculation) to obtain the decrypted information.

[0136] The agent program on the local terminal will compare and match the obtained decryption information with the signature information. If they match, the verification result is determined to be successful; if they do not match, the verification result is determined to be unsuccessful.

[0137] If the verification passes, the subsequent process will continue; if the verification fails, it is determined that the response request may have been subjected to a replay attack or forgery, and the response request is an illegal request. In this case, a corresponding status code (e.g., 403 Forbidden) will be generated and returned to the production environment, and the subsequent process will be terminated.

[0138] II. Perform the image processing procedure.

[0139] 2.1 Analyze the development program.

[0140] Once the local terminal's agent (e.g., Local Agent) confirms that the verification has passed, it will extract the data packet (e.g., JSON format data packet payload) corresponding to the development program from the response request (e.g., HTTP POST request).

[0141] The local terminal's agent (e.g., Local Agent) parses the data packets to obtain key information. This key information includes at least one of the following: Git Repository URL, Branch Name, Commit Hash (used for signing and tagging subsequent image data), and Trigger User (used for audit logs).

[0142] Then, a task identifier (e.g., Build ID) is generated based on at least one parameter from the obtained key information.

[0143] 2.2, invoke the managed container engine for processing.

[0144] Use a local terminal agent (e.g., Local Agent) to establish a connection with the managed container engine (e.g., Docker engine) via a local port (e.g., Unix Socket ( / var / run / docker.sock) or TCP port (localhost:2375)).

[0145] Then, the agent can be used to invoke the managed container engine (e.g., invoke the Docker engine's API POST / containers / create) and send the task identifier to the managed container engine, which can then create a container identifier (e.g., a container ID) based on the task identifier.

[0146] 2.3 Start the sandbox container.

[0147] The managed container engine invokes the container library (e.g., configures the isolation namespace (Network / PID / UserNamespace)) and determines the process corresponding to the container identifier (e.g., container ID) of the target sandbox container based on the task identifier. It then uses the process corresponding to the target sandbox container to control the startup of the target sandbox container.

[0148] After the target sandbox container starts, it will start a pre-defined script for automatic image processing (e.g., the ENTRYPOINT script). This script will automatically initialize the environment (Jenkins environment) of the target sandbox container based on the passed environment variables, define the pipelines that need to be image processed later (e.g., the Jenkinsfile pipeline), and complete the preparation work for the target sandbox container so that it can build an image of the development program and obtain the corresponding image data.

[0149] 2.4 Determine the startup result of the target sandbox container.

[0150] Once the target sandbox container has started and initialized, a local terminal agent (e.g., LocalAgent) is used to construct the status code corresponding to the response body (e.g., HTTP response body) (e.g., HTTP 200 OK status code), and the status code is sent to the development environment's repository (e.g., code repository server). Additionally, the agent generates audit logs locally (e.g., recording "Webhook triggered, container ID xxx started, task ID xxx").

[0151] If the target sandbox container fails to start (e.g., due to insufficient resources), the agent will capture the data indicating the failure and generate a corresponding container startup failure code (e.g., 500 Internal Server Error). This failure code will be sent to the development environment's repository, causing the repository to halt subsequent processes. Simultaneously, the agent will generate an alert notification and send it to the local terminal's display so developers can see and address the alert promptly.

[0152] 2.5, Deployment requests are obtained based on image data.

[0153] After the target sandbox container completes the image processing of the development program and obtains the image data, the local terminal will obtain a pre-set offline private key and use the offline private key to sign the image data (e.g., image Digest) to obtain the signed image data.

[0154] The local terminal will open the communication network corresponding to the production environment, allowing access to the production environment. Specifically, it will configure a whitelist by using the listening port of the image repository (e.g., Harbor repository) corresponding to the production environment, as determined by the load balancing component (e.g., SLB, Server Load Balancing component), to allow access from the local terminal's corresponding network segment.

[0155] The target sandbox container on the local terminal obtains basic information about the image data (e.g., image data name, size, version number, and / or functionality) and generates a corresponding initial deployment request (e.g., an HTTP request).

[0156] Inside the target sandbox container, execute the command (e.g., `docker login harbor.prod.com -u`). <username>The `-p<temporary token>` option can add a temporary access token to the initial deployment request (e.g., to the header, footer, or middle of the initial deployment request, preferably the header), thus generating a deployment request (e.g., with the HTTP request header carrying Authorization: Bearer<temporary token>), which is then sent to the production environment.

[0157] In this way, after receiving a deployment request, the production environment will verify the temporary access token in the deployment request. Specifically, it will verify whether the temporary access token is valid, expired, and / or whether it has push permissions (e.g., push permission). If any verification fails, the production environment will reject the subsequent process; if all verifications pass, the production environment will generate a pull instruction.

[0158] III. Mirror data deployment.

[0159] After receiving the pull command from the production environment, the local terminal can determine that the production environment has verified the deployment request and can communicate normally. The local terminal will then send the signed image data to the production environment.

[0160] An admission controller (e.g., ValidatingAdmissionWebhook in a Kubernetes cluster) acts as a "gateway" for the production environment (e.g., the K8s API Server). When a local terminal (e.g., the target sandbox container Jenkins in the local terminal) requests the production environment to create a deployment application (e.g., a Pod), the production environment (e.g., the K8s API Server) pauses the request and forwards it to the admission controller. The admission controller runs code to check if the signed image data to be deployed has a valid digital signature. If the signature verification fails, the deployment application (e.g., the Pod) will not be created, preventing subsequent execution of the image data; if the signature verification passes, the deployment application (e.g., the Pod) will be created, and the image data will be deployed and run.

[0161] In addition, after the image data is deployed in the production environment, the development environment will send a termination command to the local terminal, and then the local terminal will destroy the data in the target sandbox container and clear the temporary access token to prevent it from being stolen.

[0162] It should be noted that the method in this embodiment can be executed by a single device, such as a computer or server. The method can also be applied in a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method in this embodiment, and the multiple devices will interact with each other to complete the method described.

[0163] It should be noted that the above description describes some embodiments of this application. Other embodiments are within the scope of the claims of this application. In some cases, the actions or steps described in the claims of this application can be performed in a different order than that shown in the above embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0164] Based on the same inventive concept, corresponding to any of the above embodiments, this application also provides a program deployment apparatus. This apparatus is located on a local terminal, which is connected to both a development environment and a production environment, with the development environment isolated from the production environment.

[0165] refer to Figure 3 The device includes: The verification module 301 is configured to receive a response request from the development environment for the development program, trigger the local verification function, verify the local environment, and obtain the verification result. The deployment request control module 302 is configured to, in response to the verification result being verified as passed, construct image data corresponding to the development program, generate a deployment request based on the image data, send the deployment request to the production environment for verification by the production environment, and generate a pull instruction for the image data after the deployment request is verified as passed. The image data sending module 303 is configured to receive a pull instruction from the production environment and send the image data to the production environment for deployment and operation.

[0166] In some embodiments, the verification module 301 is specifically configured as follows: Configure the link address between the development environment and the development environment, and listen for response requests from the development environment for the development program based on the link address; Based on the response request, local verification and signature verification of the response request are performed to obtain the verification result.

[0167] In some embodiments, the verification module 301 is specifically configured as follows: Deploy the agent program, bind the agent program to the network interface, and configure the link address between the agent program and the development environment based on the network interface; Using the proxy program, the response requests sent by the development environment to the network interface for the development program are monitored through the link address.

[0168] In some embodiments, the development environment is specifically configured as follows: Before a response request for the development program is received from the development environment based on the link address, the development program is submitted to the repository, generating a program push event; The program push event is serialized to generate a data packet in a predetermined format; A corresponding response request is generated based on the data packet, and the response request is sent to the link address.

[0169] In some embodiments, the verification module 301 is further configured to: Perform a security check on the local environment, and after confirming that the security check passes, extract the signature information from the response request; Obtain preset key data, and use the key data to decrypt the response request to determine the decryption information; The signature information is matched and verified with the decryption information to obtain the verification result.

[0170] In some embodiments, the deployment request control module 302 is specifically configured as follows: In response to the verification result being successful, the data packet corresponding to the development program is determined, the data packet is parsed, and a task identifier is generated; Determine the target sandbox container corresponding to the task identifier, and control the target sandbox container to execute the startup process; In response to the successful startup of the target sandbox container, a temporary access token is requested using the target sandbox container; Using the target sandbox container, pull the development program corresponding to the response request, and build image data corresponding to the development program; Obtain the basic information of the image data, generate a deployment request based on the basic information and the temporary access token, and send the deployment request to the production environment.

[0171] In some embodiments, the deployment request control module 302 is further configured to: Determine the data packet of the predetermined format corresponding to the development program; The key information in the data packet is parsed, and a task identifier is generated based on the key information.

[0172] In some embodiments, the deployment request control module 302 is further configured to: Invoke the managed container engine and send the task identifier to the managed container engine; Using the managed container engine, the target sandbox container corresponding to the task identifier is determined from the container library, and the target sandbox container is controlled to execute the startup process.

[0173] In some embodiments, the deployment request control module 302 is further configured to: Obtain the offline private key, and use the offline private key to digitally sign the image data to obtain the signed image data; Open the communication network with the production environment, obtain the basic information of the image data, and generate an initial deployment request based on the basic information; The temporary access token is added to the initial deployment request to obtain a deployment request, which is then sent to the production environment. The mirror data sending module 303 is specifically configured as follows: Upon receiving a pull command from the production environment, the signed image data is sent to the production environment for signature verification. Once the verification is successful, the signed image data is deployed and run.

[0174] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, in implementing this application, the functions of each module can be implemented in one or more software and / or hardware.

[0175] The apparatus of the above embodiments is used to implement the corresponding method in any of the foregoing embodiments and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0176] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the methods described in any of the above embodiments.

[0177] Figure 4 This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0178] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0179] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0180] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0181] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0182] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0183] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0184] The electronic devices described above are used to implement the corresponding methods in any of the foregoing embodiments and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0185] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a non-transitory computer-readable storage medium that stores computer instructions for causing the computer to perform the methods described in any of the above embodiments.

[0186] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), other types of random-access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0187] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to perform the method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0188] Based on the same concept, corresponding to any of the above embodiments, this application also provides a computer program product, including computer program instructions, which, when run on a computer, cause the computer to perform the method described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0189] Based on the same inventive concept, this application also provides a vehicle including the device or electronic device described in the above embodiments. The beneficial effects of embodiments having corresponding devices or electronic devices will not be elaborated further here.

[0190] It is understood that before using the technical solutions of the various embodiments in this application, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.

[0191] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations described in this application.

[0192] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0193] It is understood that the above notification and user authorization process is merely illustrative and does not limit the implementation of this application. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this application.

[0194] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this application (including the claims) is limited to these examples; within the framework of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this application as described above, which are not provided in the details for the sake of brevity.

[0195] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this application, the well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the provided drawings. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this application, and this also takes into account the fact that the details of the implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this application will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this application, it will be apparent to those skilled in the art that the embodiments of this application can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0196] Although this application has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0197] The embodiments of this application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the claims of this application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the embodiments of this application should be included within the protection scope of this application.< / username> < / username>

Claims

1. A method for deploying a program, characterized in that, It is applied to a local terminal, which is connected to both a development environment and a production environment, and the development environment is isolated from the production environment. The method includes: Upon receiving the response request from the development environment for the development program, the local verification function is triggered to verify the local environment and obtain the verification result. In response to the verification result being successful, image data corresponding to the development program is constructed, a deployment request is generated based on the image data, and the deployment request is sent to the production environment for verification by the production environment. After the deployment request is verified, a pull instruction for the image data is generated. Upon receiving a pull command from the production environment, the image data is sent to the production environment for deployment and operation.

2. The method according to claim 1, characterized in that, Upon receiving the response request from the development environment for the development program, the local verification function is triggered to verify the local environment and obtain the verification result, including: Configure the link address between the development environment and the development environment, and listen for response requests from the development environment for the development program based on the link address; Based on the response request, local verification and signature verification of the response request are performed to obtain the verification result.

3. The method according to claim 2, characterized in that, The connection address between the configuration and the development environment, based on which the response requests for the development program sent by the development environment are listened to, includes: Deploy the agent program, bind the agent program to the network interface, and configure the link address between the agent program and the development environment based on the network interface; Using the proxy program, the response requests sent by the development environment to the network interface for the development program are monitored through the link address.

4. The method according to claim 2, characterized in that, Before the response request for the development program from the development environment is detected based on the link address, the following is executed in the development environment: Submit the development program to the repository to generate a program push event; The program push event is serialized to generate a data packet in a predetermined format; A corresponding response request is generated based on the data packet, and the response request is sent to the link address.

5. The method according to claim 2, characterized in that, The step of performing local verification and signature verification of the response request based on the response request to obtain the verification result includes: Perform a security check on the local environment, and after confirming that the security check passes, extract the signature information from the response request; Obtain preset key data, and use the key data to decrypt the response request to determine the decryption information; The signature information is matched and verified with the decryption information to obtain the verification result.

6. The method according to claim 1, characterized in that, In response to a successful verification result, the system constructs image data corresponding to the development program, generates a deployment request based on the image data, and sends the deployment request to the production environment, including: In response to the verification result being successful, the data packet corresponding to the development program is determined, the data packet is parsed, and a task identifier is generated; Determine the target sandbox container corresponding to the task identifier, and control the target sandbox container to execute the startup process; In response to the successful startup of the target sandbox container, a temporary access token is requested using the target sandbox container; Using the target sandbox container, pull the development program corresponding to the response request, and build image data corresponding to the development program; Obtain the basic information of the image data, generate a deployment request based on the basic information and the temporary access token, and send the deployment request to the production environment.

7. The method according to claim 6, characterized in that, The step of determining the data packet corresponding to the development program, parsing the data packet, and generating a task identifier includes: Determine the data packet of the predetermined format corresponding to the development program; The key information in the data packet is parsed, and a task identifier is generated based on the key information.

8. The method according to claim 6, characterized in that, The step of determining the target sandbox container corresponding to the task identifier and controlling the target sandbox container to execute the startup process includes: Invoke the managed container engine and send the task identifier to the managed container engine; Using the managed container engine, the target sandbox container corresponding to the task identifier is determined from the container library, and the target sandbox container is controlled to execute the startup process.

9. The method according to claim 6, characterized in that, The process of obtaining basic information about the image data, generating a deployment request based on the basic information and the temporary access token, and sending the deployment request to the production environment includes: Obtain the offline private key, and use the offline private key to digitally sign the image data to obtain the signed image data; Open the communication network with the production environment, obtain the basic information of the image data, and generate an initial deployment request based on the basic information; The temporary access token is added to the initial deployment request to obtain a deployment request, which is then sent to the production environment. The step of receiving a pull command from the production environment and sending the image data to the production environment includes: Upon receiving a pull command from the production environment, the signed image data is sent to the production environment for signature verification. Once the verification is successful, the signed image data is deployed and run.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 9.

Images