Method, device, equipment and medium for pushing image of space-time domain service

Abstract

The present invention provides a method, device, equipment and medium for pushing images of spatiotemporal domain services, and relates to the field of containerization technology, including: obtaining a compressed package containing a spatiotemporal domain service executable file and an image Dockerfile file, and uploading it to a host machine; configuring the environment information of the host container according to the file address of the compressed package to start the host container in the host machine; starting the Docker daemon process inside the host container, and executing the image creation task and the image push task based on the compressed package through the Docker daemon process to push the created Docker image to a target image warehouse. The present invention can significantly improve the problems of high environmental dependence, resource competition and performance problems, higher security risks, poor portability and reusability, and scalability limitations, thereby providing a more stable, secure, and scalable container construction and push solution.

Description

Technical Field

[0001] The present invention relates to the field of containerization technology, and in particular to a method, device, equipment and medium for pushing a space-time domain service image. Background Art

[0002] With the rapid development of cloud computing technology, Docker containerization technology has become the mainstream way of application deployment in the space-time field. As an important part of container technology, container images provide a reliable, efficient and consistent operating environment for applications. The Docker container image repository provides unified storage and management capabilities for container images. For application containerization deployment, application developers pushing application container images to the image repository is a prerequisite for realizing application containerization deployment.

[0003] In the space-time domain, when implementing containerization technology, the traditional process usually includes the following steps: passing in executable files and image metadata information, building images by calling the Docker API, and pushing Docker images to the image repository. However, this process faces the following key challenges in actual applications, and needs to be optimized to improve efficiency and stability.

[0004] 1. High environmental dependency: Spatiotemporal data processing often relies on specific libraries, tools, and data processing frameworks. These dependencies may behave inconsistently in different environments, making it more complicated to manage these dependencies. Differences in environmental configurations can easily lead to abnormal container image builds.

[0005] 2. Resource competition and performance issues: Data in the spatiotemporal field are usually high-resolution satellite images, complex geographic information system data, and real-time streaming data. These data are large in volume and computationally intensive. When the image is built directly on the host machine, this high load will lead to system resource constraints, which in turn affects the operation of other important services, especially when multiple large files or real-time data streams need to be processed simultaneously.

[0006] 3. Higher security risk: Spatiotemporal data usually contains sensitive geographic information and strategic data, which face relatively high security requirements during transmission and storage. If it is operated directly on the host machine, if there is a security vulnerability, it may lead to data leakage or system intrusion, especially when dealing with cross-network transmission or multi-user access, the security risk is higher.

[0007] 4. Poor portability and reusability: Spatiotemporal data processing involves complex data pipelines and specific processing tool chains, which are difficult to reuse in different environments. If it depends on the host environment configuration, it may be necessary to reconfigure all dependencies when migrating to a new environment, resulting in poor portability. At the same time, the consistency of the build and push process in different environments is difficult to ensure, and reusability is also limited.

[0008] 5. Scalability limitations: Data processing requirements in the spatiotemporal domain are highly scalable, especially when multiple data sources or concurrent tasks need to be processed simultaneously. Traditional methods are often limited by the performance of a single machine and cannot meet the expansion requirements under high load conditions. In addition, as the amount and complexity of data increases, a single host machine build environment is difficult to expand to support more task processing. Summary of the invention

[0009] In view of this, the purpose of the present invention is to provide a method, device, equipment and medium for pushing service images in the space-time domain, which can significantly improve the problems of high environmental dependence, resource competition and performance issues, higher security risks, poor portability and reusability, and scalability limitations, thereby providing a more stable, secure and scalable container construction and push solution.

[0010] In a first aspect, an embodiment of the present invention provides a method for pushing a spatiotemporal domain service image, including:

[0011] Obtain a compressed package containing the spatiotemporal domain service executable file and the image Dockerfile file, and upload the compressed package to the host machine;

[0012] Configure the environment information of the host container according to the file address of the compressed package in the host machine, so as to start the host container in the host machine according to the environment information;

[0013] Start the Docker daemon process inside the host container, and use the Docker daemon process to perform image creation and image push tasks based on the compressed package to push the created Docker image to the target image repository. The Docker daemon process inside the host container is completely isolated from the Docker daemon process on the host machine.

[0014] In one embodiment, configuring environment information of a host container according to a file address of a compressed package in a host machine, so as to start the host container in the host machine according to the environment information, includes:

[0015] The file address of the compressed package in the host machine, as well as the image metadata information, image repository connection information, and message center connection information are used as the host container's environment information;

[0016] After the environment information is configured, execute the Docker startup command to start the host container in the host machine according to the environment information.

[0017] In one embodiment, the Docker daemon process executes the image creation task and the image push task based on the compressed package to push the created Docker image to the target image repository, including:

[0018] Create a Docker client instance inside the host container, and connect the Docker client instance to the Docker daemon process inside the host container;

[0019] Generate a build context based on the compressed package and environment information, and transmit the build context to the Docker daemon through the Docker client instance;

[0020] Create a Docker image based on the build context through the Docker daemon;

[0021] Through the Docker client instance and Docker daemon, according to the image repository connection information in the environment information, push the Docker image to the target image repository;

[0022] If the Docker image is pushed successfully, the host container is terminated in the host machine.

[0023] In one embodiment, generating a build context based on the compressed package and the environment information, and transmitting the build context to the Docker daemon through the Docker client instance includes:

[0024] Based on the file address, copy the compressed package from the host machine to the specified location in the host container, and decompress the copied compressed package to obtain the spatiotemporal domain service executable file and the image Dockerfile file;

[0025] Generate a build context based on the spatiotemporal domain service executable file, image Dockerfile file, and environment information;

[0026] Compress the build context into an archive file and transfer the archive file to the Docker daemon through the Docker client instance.

[0027] In one implementation, the Docker image is pushed to the target image repository through the Docker client instance and the Docker daemon according to the image repository connection information in the environment information, including:

[0028] Through the Docker client instance, the Docker image is associated with its corresponding image identifier to obtain the image data;

[0029] Through the Docker daemon, the image data fragments are pushed to the target image repository according to the image repository connection information in the environment information.

[0030] In one embodiment, the method further comprises:

[0031] Dynamic monitoring based on pre-configured exception handling mechanisms, and generating messages when abnormal situations are detected. Abnormal situations include at least host container startup failure, Docker image creation failure, and Docker image push failure.

[0032] According to the message center connection information in the environment information, the message is sent to the target message center, so that an exception notification is performed based on the message through the target message center.

[0033] In one embodiment, the method further comprises:

[0034] The image metadata information in the environment information is adjusted based on the message to achieve closed-loop feedback of the image metadata information.

[0035] In a second aspect, an embodiment of the present invention further provides a space-time domain service image push device, including:

[0036] The file upload module is used to obtain the compressed package containing the spatiotemporal domain service executable file and the image Dockerfile file, and upload the compressed package to the host machine;

[0037] A container startup module, used to configure the environment information of the host container according to the file address of the compressed package in the host machine, so as to start the host container in the host machine according to the environment information;

[0038] The image creation and push module is used to start the Docker daemon process inside the host container, and execute the image creation task and image push task based on the compressed package through the Docker daemon process to push the created Docker image to the target image repository. The Docker daemon process inside the host container is completely isolated from the Docker daemon process on the host machine.

[0039] The embodiment of the present invention provides a method, device, equipment and medium for pushing images of spatiotemporal domain services. First, a compressed package containing a spatiotemporal domain service executable file and an image Dockerfile file is obtained, and the compressed package is uploaded to a host machine; then, the environment information of the host container is configured according to the file address of the compressed package in the host machine, so as to start the host container in the host machine according to the environment information; finally, the Docker daemon process is started inside the host container, and the image creation task and the image push task are executed based on the compressed package by the Docker daemon process, so as to push the created Docker image to the target image warehouse, and the Docker daemon process inside the host container is completely isolated from the Docker daemon process on the host machine. The above method starts the host container inside the host machine, and further starts the Docker daemon process in the host container, and uses the Docker daemon process to realize image creation and image push. Compared with the traditional technology of directly operating the Docker daemon process on the host machine, the embodiment of the present invention can significantly improve the problems of high environmental dependence, resource competition and performance problems, higher security risks, poor portability and reusability, and scalability limitations, thereby providing a more stable, secure and scalable container construction and push solution.

[0040] Other features and advantages of the present invention will be described in the following description, and partly become apparent from the description, or understood by practicing the present invention. The purpose and other advantages of the present invention are realized and obtained by the structures particularly pointed out in the description, claims and drawings.

[0041] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0043] Figure 1 A schematic diagram of a flow chart of a method for pushing a spatiotemporal domain service image according to an embodiment of the present invention;

[0044] Figure 2 A schematic diagram of the overall process of a space-time domain service image push method provided by an embodiment of the present invention;

[0045] Figure 3A schematic diagram of key steps for executing a host container task provided by an embodiment of the present invention;

[0046] Figure 4 A schematic diagram of an image building process provided by an embodiment of the present invention;

[0047] Figure 5 A schematic diagram of the structure of a space-time domain service image push device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0048] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution of the present invention will be clearly and completely described in combination with the embodiments below. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0049] At present, application developers or application systems push Docker container images to image warehouses through Docker Client or Docker API. Among them, when using Docker Client to push images, it is necessary to install Docker Client software on the user side, log in to the image warehouse as a specified user by executing the docker login command, and then execute the docker build command to build the container image, and push the built container image to the image warehouse through the docker push command. When using the Docker API to push images, the system implements the functions of Docker image warehouse login, container image building and container image push by calling a series of Docker APIs. However, the above technical means all have high environmental dependence, resource competition and performance problems, higher security risks, poor portability and reusability, and scalability limitations. Based on this, the present invention implements a method, device, equipment and medium for pushing images of spatiotemporal service images, which can not only effectively solve the above problems, but also make full use of Docker's isolation and construction efficiency, and provide a more stable, secure and scalable container construction and push solution. The embodiment of the present invention is particularly suitable for coping with the needs of complex data processing in the spatiotemporal field, ensuring that efficient and reliable services can still be maintained under high load and complex environments.

[0050] To facilitate understanding of this embodiment, a space-time domain service image push method disclosed in an embodiment of the present invention is first described in detail. Figure 1 The flowchart of a method for pushing a spatiotemporal domain service image is shown, and the method mainly includes the following steps S102 to S106:

[0051] Step S102, obtaining a compressed package including the spatiotemporal domain service executable file and the image Dockerfile file, and uploading the compressed package to the host machine.

[0052] In one example, a compressed package containing the executable file and Dockerfile file of the spatiotemporal domain service is prepared, uploaded to the host machine, and the file address of the compressed package in the host machine is recorded; at the same time, the image metadata information such as the image name and label is determined, and the image metadata information is saved in the database.

[0053] Step S104, configuring the environment information of the host container according to the file address of the compressed package in the host machine, so as to start the host container in the host machine according to the environment information.

[0054] In one example, the host container's environment information is configured, including the file address of the compressed package in the host machine, image metadata information, connection information pointing to the Harbor image repository and message center, etc., to ensure that the host container has all the dependencies required to build and push the image; after the host container's environment information is configured, the Docker startup command is automatically executed to start the host container in the host machine.

[0055] Step S106, starting the Docker daemon process inside the host container, and executing the image creation task and the image push task based on the compressed package through the Docker daemon process to push the created Docker image to the target image repository.

[0056] Among them, the Docker daemon process inside the host container is completely isolated from the Docker daemon process on the host machine. In one example, the decompression operation is performed on the compressed package inside the host container, and the container nesting (DinD) technology is used to build the Docker image inside the host container, and the built image is pushed to the specified Harbor image repository and other tasks. Specifically, the container nesting technology is used to start the Docker daemon process inside the host container, and then the Docker daemon process is used to perform the image creation task and the image push task for the decompressed compressed package, so as to push the created Docker image to the target image repository.

[0057] Furthermore, in this process, each step is accompanied by a strict exception handling and status notification mechanism to ensure that any potential problems can be discovered and handled in a timely manner.

[0058] Furthermore, the metadata status of the image is updated through asynchronous message notification, forming a complete data closed loop from building to pushing.

[0059] The spatiotemporal domain service image push method provided in the embodiment of the present invention starts a host container inside the host machine, and further starts a Docker daemon process in the host container, and uses the Docker daemon process to implement image creation and image push. Compared with the traditional technology of directly operating the Docker daemon process on the host machine, the embodiment of the present invention can significantly improve the problems of high environmental dependence, resource competition and performance issues, higher security risks, poor portability and reusability, and scalability limitations, thereby providing a more stable, secure, and scalable container construction and push solution.

[0060] For ease of understanding, the embodiments of the present invention provide Figure 2 The overall process diagram of a space-time domain service image push method shown in the figure includes: image data preparation, host container configuration machine startup, host container task execution, exception handling and status notification, closed-loop feedback and image status synchronization. Specifically:

[0061] The first step is to prepare the image data: collect and organize all the files required to build the Docker image of the spatiotemporal domain service, compress them into a compressed package file, and upload the compressed package file to the host. At the same time, it is also necessary to determine the image metadata information such as the image name and label, and save these image metadata to the database. The output data is the compressed package file address and the image identification metadata.

[0062] In the specific implementation, you need to prepare a compressed package containing the executable file of the spatiotemporal domain service and the image Dockerfile and other files. Dockerfile plays a key role in this process. It not only defines the steps for building the image, but also specifies the dependent libraries, tools, and data processing frameworks that need to be installed. In addition, at this stage, you also need to clarify the image metadata information such as the name and label of the image, and save this image metadata information to the database. This image metadata information will serve as the unique identifier of the image in the entire system for subsequent storage, retrieval, and management. This step ensures that all data is fully prepared and accurate, laying a solid foundation for the subsequent image construction.

[0063] The second step is to configure the host container's environment information: Use the file address of the compressed package in the host machine, as well as the image metadata information, image repository connection information, and message center connection information as the host container's environment information; after the environment information configuration is completed, execute the Docker startup command to start the host container in the host machine according to the environment information.

[0064] In one example, the environment information includes the file address of the compressed package, the image identifier in the image metadata information, the image repository connection information, and the message center connection information, etc., to ensure that the host container has all the dependencies required to build and push the image. After the host container's environment information is configured, the system automatically executes the Docker command to start the host container. This step ensures data consistency and accessibility.

[0065] In the specific implementation, the configured host container environment information includes: the file address of the aforementioned compressed package, the image identifier in the image metadata information, and the connection information of external systems such as the Harbor image repository and the message center; the above information is configured as the environment variables of the host container.

[0066] After the host container configuration is completed, the system automatically executes the Docker startup command to start the host container. During the startup process, the system dynamically adjusts the startup configuration according to the specific task requirements, such as allocating different memory and CPU limits according to the resource requirements of the service, and mounting the necessary dependencies and configuration files. If the startup fails, it will retry 6 times. If all startups fail, it will enter the exception handling and status notification process.

[0067] The third step is the host container task execution: decompress the compressed package file of the image information inside the host container, use the DinD (Docker in Docker) container nesting technology to build the space-time domain service Docker image, and push the built image to the specified Harbor image repository and other tasks.

[0068] In one implementation, after the host container is successfully started and running, the DinD (Docker in Docker) container nesting technology is used, that is, a technology that runs another Docker daemon and client inside a standard Docker container. This Docker container is called the host container, and the other Docker daemon running inside is called the Docker internal daemon. When the host container is started, the Docker internal daemon is started inside the container and runs as a background process. This internal daemon manages all Docker operations inside the container (executes Docker commands) and provides an independent container environment, that is, isolated host containers.

[0069] Execute Docker commands inside the isolated host container to complete tasks such as building and pushing the space-time domain service image. This approach ensures the independence of operations while avoiding potential impact on the host environment.

[0070] For details, see Figure 3The schematic diagram of the key steps of executing a host container task is shown, including image building task initialization, image building, image pushing, container termination, etc. For ease of understanding, an embodiment of the present invention provides a specific implementation method of starting a Docker daemon process inside a host container, executing an image creation task and an image pushing task based on a compressed package through the Docker daemon process, and pushing the created Docker image to a target image repository, including:

[0071] (1) Image building task initialization: After the host container is started, it will read configuration information from the environment variables (env) contained in the host container's environment information. This information includes the file address of the image information compression package, the image identifier, the Harbor image repository information (such as the image repository address, authentication information, etc.), the message center connection information, etc., and initialize the DinD environment, that is, start a Docker daemon inside the host container. This daemon is completely isolated from the Docker daemon on the host. The method to achieve this isolation includes using independent network and storage space in the host container, not sharing the Docker socket with the host Docker, and ensuring that the Docker daemon inside the container runs in an environment isolated from the host. The Docker socket is the interface for communication between the Docker daemon and the client, through which Docker commands can be transmitted and executed. The Docker daemon inside the host container is mainly responsible for image building, image push and other operations in the container, as well as providing the Docker API interface, while the Docker daemon on the host is responsible for managing the Docker resources on the entire host operating system. Isolation is mainly used to avoid potential security risks and prevent operations within the container from affecting the host's Docker environment, such as container escape attacks, and to ensure that resources and services between different environments do not interfere with each other, thereby improving system stability and security.

[0072] (2) Image building, see Figure 4 The schematic diagram of an image building process shown includes copying the image information compression package file, creating a Docker client instance inside the host container, building the context and sending it to the Docker daemon process, building the image, and status notification.

[0073] For ease of understanding, see (2.1) to (2.3) below:

[0074] (2.1) Create a Docker client instance inside the host container, and the Docker client instance connects to the Docker daemon inside the host container.

[0075] In one example, a Docker client instance is created inside a host container using the Docker API, and a connection is made to the Docker daemon inside the host container through the client instance.

[0076] The specific steps include: installing the official Go Docker SDK in the host container, then starting the Docker daemon in the host container and ensuring that it listens on the Unix socket / var / run / docker.sock. Next, create a Docker client instance using the Docker SDK by specifying the socket path. Once the Docker client instance is created, you can execute various Docker commands, such as container management and image operations, through the Docker daemon inside the host container, thereby interacting and managing the Docker environment in the host container.

[0077] (2.2) Generate a build context based on the compressed package and environment information, and transmit the build context to the Docker daemon through the Docker client instance. Specifically:

[0078] (I) Based on the file address, copy the compressed package from the host machine to the specified location in the host container, and perform a decompression operation on the copied compressed package to obtain the spatiotemporal domain service executable file and the image Dockerfile file.

[0079] According to the file address of the aforementioned compressed package (including the Dockerfile file, the spatiotemporal domain service executable file, etc.), copy the compressed package from the host machine to the specified location in the host container. After the copying is completed, decompress the compressed package file.

[0080] (ii) Generate a build context based on the spatiotemporal domain service executable file, the image Dockerfile file, and the environment information, compress the build context into an archive file, and transfer the archive file to the Docker daemon through the Docker client instance.

[0081] In one example, inside the host container, the Dockerfile file and the spatiotemporal domain service executable file are packaged into a build context. The specific operation is to place all the files and directories required for building the image, including the Dockerfile, spatiotemporal domain service executable file, configuration files, etc., in a single directory. The purpose of the build context is to provide all the files required for the Docker image building process, which will be sent to the Docker daemon inside the host container for reference during the image building process.

[0082] Typically, this build context directory is compressed into a tar archive file and passed to the API of the Docker client instance through the standard input stream (stdin), which then sends this tar archive file to the Docker daemon running inside the host container to start the image building process.

[0083] (2.3) Create a Docker image based on the build context through the Docker daemon.

[0084] In one example, an image building operation is performed within a host container using an image building function of a Docker client instance.

[0085] Specifically, the image building methods provided by the Docker client instance inside the created host container are implemented through the Docker API. These methods are interfaces provided by the Go Docker SDK for communicating with the Docker daemon. When performing the image building operation, the method receives the build context (usually a tar archive file) as input data and passes it to the Docker daemon. The Docker daemon then parses the Dockerfile file and creates the image according to the steps defined in it. The output data is the Docker image ID or error information after the build is completed, which is used for subsequent operations.

[0086] Furthermore, if the image building succeeds or fails, the status information of the success or failure of the image building is sent through the message center inside the host container.

[0087] (3) Image push: Push the Docker image to the target image repository through the Docker client instance and the Docker daemon according to the image repository connection information in the environment information. In one embodiment, the Docker client instance is used to associate the Docker image with its corresponding image identifier to obtain the image data; then, the Docker daemon is used to push the image data fragments to the target image repository according to the image repository connection information in the environment information.

[0088] In actual applications, after the image is successfully built, the image push function of the Docker client instance is used inside the host container to push the image to the Harbor image repository. The image push method of the Docker client instance inside the host container is provided through the Docker API and implemented by the Go Docker SDK. These methods allow the Docker client to communicate with the Docker daemon and perform push operations.

[0089] When executing the push operation, the image push method will accept the image name and the target repository address as input data. The Docker client instance will associate the image name with the locally stored image content, and then upload the image data fragments to the specified Harbor image repository through the Docker daemon inside the host container. The output data is usually feedback information on the push progress or the image URL returned after a successful push. If an error occurs, the corresponding error information will be returned.

[0090] The output of this function obtains the push status and handles any errors if necessary, which can be used for subsequent exception handling and status notification.

[0091] (4) Container termination: If the Docker image is successfully pushed, the host container is terminated in the host machine. In one example, after the image is successfully pushed, the container will automatically perform resource recycling operations to release the occupied system resources, that is, close the host container.

[0092] Compared with services in other fields, spatiotemporal services usually rely on complex geographic information system libraries, special tools and data processing frameworks, which makes the environment configuration requirements more demanding. Traditional implementations directly operate the host Docker, which easily leads to multiple services sharing the same Docker instance, thereby increasing the risk of dependency conflicts and resource competition. In addition, this sharing mode brings serious security risks, such as privilege escalation attacks, unauthorized resource access and malicious code execution. Especially in the spatiotemporal field, these security risks are more significant when processing sensitive geographic data. After adopting the technology of the embodiment of the present invention, the construction and push process is carried out in an isolated container environment, avoiding direct operation and competition on host resources, and improving the safety of operations. Through the efficient performance of the Docker Golang SDK API, the speed of image construction and push is significantly accelerated, while ensuring the independence, stability and reliability of spatiotemporal services in a complex dependency environment, thereby achieving more efficient and secure containerized operations.

[0093] In summary, the third step, the space-time domain service usually involves a large number of executable files and complex dependencies. Traditional container technology builds images by directly mounting the Docker socket of the host machine. This method has potential security risks and environmental pollution problems, because all containers share the same Docker daemon, which may cause dependency conflicts or permission problems between different services. The embodiment of the present invention adopts DinD technology, which realizes the isolation of the container environment and the host machine by starting an independent Docker daemon inside the host container and using a separate Docker socket for communication. This method ensures the independence of the image construction environment, so that the construction process of the space-time domain service will not affect or interfere with the operation of the host machine or other containers, especially when high security and environmental isolation are required. In addition, this technology can better manage and monitor the specific dependencies of the space-time domain service, avoid conflicts with other services, and ensure that the automation process of building and pushing is safer and more reliable. This step realizes the automated construction and push from code to image.

[0094] The fourth step is to introduce an exception handling and status notification mechanism. During the image building and push process, each step is accompanied by a strict exception handling and status notification mechanism. The system will dynamically monitor the execution of each sub-step. Once an exception is detected, such as build failure, push interruption, etc., the system will immediately trigger the preset exception handler and notify the message center of the current status. This mechanism ensures that the system can quickly respond to and handle various status changes, enhancing the robustness and maintainability of the system.

[0095] In one embodiment, dynamic monitoring is first performed based on a preconfigured exception handling mechanism, and a message is generated when an abnormal situation is monitored. The abnormal situation includes at least failure to start the host container, failure to create the Docker image, and failure to push the Docker image; then, according to the message center connection information in the environment information, the message is sent to the target message center, so that the target message center performs exception notification based on the message.

[0096] Specifically, during the image building and image push execution process, whether it is successfully completed or encounters an abnormal situation, real-time notification is sent by sending RabbitMQ message middleware. This mechanism ensures that the system can respond quickly and handle various state changes, enhancing the robustness and maintainability of the system.

[0097] During the image building and pushing process, the system needs to dynamically monitor each sub-step in order to handle possible exceptions in a timely manner. To this end, the system has designed an exception handling mechanism and status notification function in each sub-step. Once an exception occurs, the system can automatically handle it and notify the relevant monitoring system or user of the current status in a timely manner. This dynamic monitoring and exception handling mechanism can ensure the smooth progress of the entire building and pushing process, and improve the transparency and reliability of the system.

[0098] The fifth step is to modify the metadata information such as the stored image status through the message feedback of the message center, thus forming a closed loop of data. Through this closed-loop feedback mechanism, the status of the entire process of image building and pushing can be updated in a timely manner. This not only helps maintain the consistency of the system, but also provides reliable data support for subsequent auditing, tracking and troubleshooting.

[0099] In one implementation, the mirror metadata information in the environment information may be adjusted based on the message to implement closed-loop feedback of the mirror metadata information.

[0100] Specifically, the message center data sent in step 4 is consumed in step 5. According to the received message content, the mirror status information in the database is updated.

[0101] The last step is to modify the image metadata status stored in the first step through the message feedback from the message center, thus forming a closed loop of data. Through this closed-loop feedback mechanism, the system can ensure that the entire process of image building and pushing is accurately recorded and the metadata status is updated in a timely manner. This not only helps maintain the consistency of the system, but also provides reliable data support for subsequent auditing, tracking, and troubleshooting.

[0102] In summary, the embodiment of the present invention provides a method and system for building and pushing images of spatiotemporal domain services based on Docker container nesting technology, using Docker-in-Docker (DinD) container nesting technology, combined with the Golang API Client officially provided by Docker, compared with the traditional way of directly operating the host Docker, it shows significant advantages in the containerization process of spatiotemporal domain services, especially when dealing with the complexity of dependent environments, large file processing and high performance requirements. The method provided by the embodiment of the present invention has at least the following characteristics:

[0103] 1. Complexity of dependency environment: Spatiotemporal services usually rely on complex GIS libraries, special tools and data processing frameworks. In traditional technologies, multiple services share Docker instances on the host machine, which easily leads to dependency conflicts and inconsistent environments. The technology provided by the embodiments of the present invention ensures that each container has independent Docker process resources and will not be interfered with by other services by performing build and push operations in an isolated container environment. This isolation greatly simplifies the management of complex dependency environments and improves the stability and reliability of the system.

[0104] 2. Large file processing: The space-time field often needs to process large-scale geographic data files, which places high performance and resource requirements on containerized operations. When processing large files, the traditional image construction method is prone to performance bottlenecks caused by resource competition due to the sharing of host resources. Under the technology provided by the embodiment of the present invention, all operations are completed inside the host container, avoiding direct competition for host resources, thereby improving the efficiency of large file processing and system stability. The efficiency of the Golang API further improves the speed of reading, compressing, building and pushing large files, ensuring high performance when processing large data sets.

[0105] 3. Performance requirements: In the spatiotemporal domain, processing geographic data often requires efficient resource management and computing power. Traditional technologies, due to their reliance on host Docker instances, are prone to bottlenecks in resource usage, affecting overall performance. However, through the technology provided by the embodiments of the present invention, the image building and push inside the host container are performed in an isolated environment, resource allocation is clearer, resource conflicts are avoided, and the efficient calling of the Golang API further optimizes the performance of containerized operations, meeting the demand for high-performance computing in the spatiotemporal domain.

[0106] 4. Security: Traditional technologies operate Docker directly on the host machine, which poses great security risks, including potential privilege escalation attacks and unauthorized resource access risks. In contrast, the technology provided by the embodiments of the present invention greatly reduces these security risks by operating in an isolated host container environment, especially providing higher security when processing sensitive geographic information.

[0107] Based on this, the embodiment of the present invention provides a containerization process for space-time domain services, which significantly improves the independence of space-time domain service image construction and push, the efficiency of large file processing, the optimization of system performance, and the enhancement of security. It is an ideal solution for dealing with space-time domain service image construction and push.

[0108] Based on the above-mentioned embodiment, the embodiment of the present invention provides a device for pushing a service image in a time-space domain, see Figure 5The schematic diagram of the structure of a space-time domain service image push device is shown, and the device mainly includes the following parts:

[0109] The file upload module 502 is used to obtain a compressed package containing the spatiotemporal domain service executable file and the image Dockerfile file, and upload the compressed package to the host machine;

[0110] A container startup module 504 is used to configure the environment information of the host container according to the file address of the compressed package in the host machine, so as to start the host container in the host machine according to the environment information;

[0111] The image creation and push module 506 is used to start the Docker daemon process inside the host container, and execute the image creation task and the image push task based on the compressed package through the Docker daemon process to push the created Docker image to the target image repository. The Docker daemon process inside the host container is completely isolated from the Docker daemon process on the host machine.

[0112] The spatiotemporal domain service image push method provided in the embodiment of the present invention starts a host container inside the host machine, and further starts a Docker daemon process in the host container, and uses the Docker daemon process to implement image creation and image push. Compared with the traditional technology of directly operating the Docker daemon process on the host machine, the embodiment of the present invention can significantly improve the problems of high environmental dependence, resource competition and performance issues, higher security risks, poor portability and reusability, and scalability limitations, thereby providing a more stable, secure, and scalable container construction and push solution.

[0113] In one implementation, the container startup module 504 is specifically used to:

[0114] The file address of the compressed package in the host machine, as well as the image metadata information, image repository connection information, and message center connection information are used as the host container's environment information;

[0115] After the environment information is configured, execute the Docker startup command to start the host container in the host machine according to the environment information.

[0116] In one implementation, the image creation and push module 506 is specifically used to:

[0117] A client creation unit is used to create a Docker client instance inside a host container, and the Docker client instance is connected to the Docker daemon process inside the host container;

[0118] A build context generation unit, used to generate a build context based on the compressed package and environment information, and transmit the build context to the Docker daemon through the Docker client instance;

[0119] The image creation unit is used to create a Docker image based on the build context through the Docker daemon;

[0120] The image push unit is used to push the Docker image to the target image repository according to the image repository connection information in the environment information through the Docker client instance and the Docker daemon process;

[0121] The container termination unit is used to terminate the host container in the host machine if the Docker image is successfully pushed.

[0122] In one implementation, the construction context generation unit is specifically used to:

[0123] Based on the file address, copy the compressed package from the host machine to the specified location in the host container, and decompress the copied compressed package to obtain the spatiotemporal domain service executable file and the image Dockerfile file;

[0124] Generate a build context based on the spatiotemporal domain service executable file, image Dockerfile file, and environment information;

[0125] Compress the build context into an archive file and transfer the archive file to the Docker daemon through the Docker client instance.

[0126] In one implementation, the image push unit is specifically used for:

[0127] Through the Docker client instance, the Docker image is associated with its corresponding image identifier to obtain the image data;

[0128] Through the Docker daemon, the image data fragments are pushed to the target image repository according to the image repository connection information in the environment information.

[0129] In one embodiment, an exception handling and status notification module is also included, which is used to:

[0130] Dynamic monitoring based on pre-configured exception handling mechanisms, and generating messages when abnormal situations are detected. Abnormal situations include at least host container startup failure, Docker image creation failure, and Docker image push failure.

[0131] According to the message center connection information in the environment information, the message is sent to the target message center, so that an exception notification is performed based on the message through the target message center.

[0132] In one embodiment, a closed-loop feedback and mirror state synchronization module is also included, which is used to:

[0133] The image metadata information in the environment information is adjusted based on the message to achieve closed-loop feedback of the image metadata information.

[0134] The device provided in the embodiment of the present invention has the same implementation principle and technical effects as those of the aforementioned method embodiment. For the sake of brief description, for matters not mentioned in the device embodiment, reference may be made to the corresponding contents in the aforementioned method embodiment.

[0135] An embodiment of the present invention provides an electronic device. Specifically, the electronic device includes a processor and a storage device. The storage device stores a computer program, and when the computer program is executed by the processor, it executes the method described in any one of the above-mentioned implementation methods.

[0136] The electronic device provided by the embodiment of the present invention includes: a processor, a memory, a bus and a communication interface, wherein the processor, the communication interface and the memory are connected via the bus; the processor is used to execute an executable module stored in the memory, such as a computer program.

[0137] The memory may include high-speed random access memory (RAM), and may also include non-volatile memory, such as at least one disk storage. The communication connection between the system network element and at least one other network element is realized through at least one communication interface (which may be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. may be used.

[0138] The bus may be an ISA bus, a PCI bus or an EISA bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one bidirectional arrow is used, but it does not mean that there is only one bus or one type of bus.

[0139] Among them, the memory is used to store the program, and the processor executes the program after receiving the execution instruction. The method executed by the device for flow process definition disclosed in any embodiment of the above-mentioned embodiment of the present invention can be applied to the processor or implemented by the processor.

[0140] The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the hardware integrated logic circuit in the processor or the instruction in the form of software. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present invention can be implemented or executed. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor. The steps of the method disclosed in the embodiment of the present invention can be directly embodied as a hardware decoding processor to execute, or the hardware and software modules in the decoding processor can be executed. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0141] The computer program product of the readable storage medium provided in the embodiment of the present invention includes a computer-readable storage medium storing program code, and the instructions included in the program code can be used to execute the methods described in the previous method embodiments. The specific implementation can be referred to the previous method embodiments, which will not be repeated here.

[0142] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., which can store program codes.

[0143] Finally, it should be noted that the above-described embodiments are only specific implementations of the present invention, which are used to illustrate the technical solutions of the present invention, rather than to limit them. The protection scope of the present invention is not limited thereto. Although the present invention is described in detail with reference to the above-described embodiments, ordinary technicians in the field should understand that any technician familiar with the technical field can still modify the technical solutions recorded in the above-described embodiments within the technical scope disclosed by the present invention, or can easily think of changes, or make equivalent replacements for some of the technical features therein; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A method for pushing a space-time domain service image, characterized in that: include: Obtain a compressed package containing the spatiotemporal domain service executable file and the image Dockerfile file, and upload the compressed package to the host machine; configuring environment information of a host container according to a file address of the compressed package in the host machine, so as to start the host container in the host machine according to the environment information; Starting a Docker daemon process inside the host container, and executing an image creation task and an image push task based on the compressed package through the Docker daemon process to push the created Docker image to a target image repository, wherein the Docker daemon process inside the host container is completely isolated from the Docker daemon process on the host machine; Executing an image creation task and an image push task based on the compressed package through the Docker daemon process to push the created Docker image to a target image repository, including: creating a Docker client instance inside the host container, the Docker client instance connecting to the Docker daemon process inside the host container; generating a build context based on the compressed package and the environment information, and transmitting the build context to the Docker daemon process through the Docker client instance; creating a Docker image based on the build context through the Docker daemon process; pushing the Docker image to a target image repository through the Docker client instance and the Docker daemon process according to the image repository connection information in the environment information; if the Docker image is successfully pushed, terminating the host container in the host machine; Generate a build context based on the compressed package and the environment information, and transmit the build context to the Docker daemon through the Docker client instance, including: based on the file address, copy the compressed package from the host machine to a specified location in the host container, and perform a decompression operation on the copied compressed package to obtain the spatiotemporal domain service executable file and the image Dockerfile file; generate a build context based on the spatiotemporal domain service executable file, the image Dockerfile file and the environment information; compress the build context into an archive file, and transmit the archive file to the Docker daemon through the Docker client instance; The method further comprises: pushing the Docker image to a target image repository through the Docker client instance and the Docker daemon according to the image repository connection information in the environment information, including: associating the Docker image with its corresponding image identifier to obtain image data through the Docker client instance; and pushing the image data fragments to a target image repository through the Docker daemon according to the image repository connection information in the environment information.

2. The method for pushing a spatiotemporal domain service image according to claim 1, characterized in that: Configuring environment information of a host container according to a file address of the compressed package in the host machine, so as to start the host container in the host machine according to the environment information, includes: The environment information of the host container is obtained according to the file address of the compressed package in the host machine, as well as the image metadata information, the image repository connection information, and the message center connection information; After the environment information is configured, a Docker startup command is executed to start the host container in the host machine according to the environment information.

3. The space-time domain service image push method according to claim 1, characterized in that: The method further comprises: Dynamic monitoring is performed based on a pre-configured exception handling mechanism, and a message is generated when an abnormal situation is monitored, wherein the abnormal situation at least includes failure to start the host container, failure to create the Docker image, and failure to push the Docker image; The message is sent to a target message center according to the message center connection information in the environment information, so that an abnormality notification is performed based on the message through the target message center.

4. The method for pushing a spatiotemporal domain service image according to claim 3, characterized in that: The method further comprises: The mirror metadata information in the environment information is adjusted based on the message to achieve closed-loop feedback of the mirror metadata information.

5. A space-time domain service image push device, characterized in that: The device is used to implement the space-time domain service image push method according to claim 1, and the device includes: A file upload module is used to obtain a compressed package containing the spatiotemporal domain service executable file and the image Dockerfile file, and upload the compressed package to the host machine; a container startup module, configured to configure environment information of a host container according to a file address of the compressed package in the host machine, so as to start the host container in the host machine according to the environment information; The image creation and push module is used to start the Docker daemon process inside the host container, and execute the image creation task and the image push task based on the compressed package through the Docker daemon process to push the created Docker image to the target image repository. The Docker daemon process inside the host container is completely isolated from the Docker daemon process on the host machine.

6. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores computer executable instructions that can be executed by the processor, and the processor executes the computer executable instructions to implement the method according to any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions prompt the processor to implement the method according to any one of claims 1 to 4.

Images