A container image distribution and deployment method and system of an ASIC edge device under an offline condition

Abstract

This invention provides a method and system for container image distribution and deployment under offline conditions on ASIC edge devices. The container image distribution and deployment method includes the following steps: On the build side, obtain a layer list and content hash of multiple application candidate images, and identify a set of common dependency layers; persist the set of common dependency layers to a read-only partition of the ASIC edge device, and simultaneously generate a local index; On the build side, construct an incremental application layer and generate a distribution list for the incremental application layer; Distribute the incremental application layer and distribution list to the ASIC edge device via offline media; Verify the offline-distributed incremental application layer and distribution list; if the verification fails, reject the deployment; if the verification passes, perform container deployment; Based on the distribution list, query the local index to obtain the set of common dependency layers, and then combine the set of common dependency layers and the incremental application layer into a container image with a root file system and deploy it. This invention can significantly reduce the amount of data distributed offline.

Description

Technical Field

[0001] This invention relates to the field of container deployment technology, and more specifically to a method and system for distributing and deploying container images under offline conditions of ASIC edge devices. Background Technology

[0002] In edge scenarios such as smart security, industrial quality inspection, rail transit, and energy inspection, edge device products equipped with ASIC inference acceleration chips (such as edge inference boxes, edge all-in-one machines, and vehicle computing units) are often deployed in isolated networks, in the wild, or in vehicle environments. These devices are often unable to connect to the network for extended periods or have only extremely low bandwidth, and the on-site maintenance window is short and available storage is limited.

[0003] In contrast, under stable network conditions, general-purpose architecture servers or edge gateways such as x86 / ARM typically pull container images directly from remote image repositories and rely on node-side image layer caching for reuse and acceleration. GPU architectures, in centralized data centers or network-connected environments, can also achieve online distribution and version control through a unified image repository and runtime extensions. However, on offline or weakly networked ASIC edge devices, images cannot be stably pulled from the source, and node-side caches struggle to maintain continuous synchronization with the central repository. Furthermore, the large size of underlying dependencies such as ASIC driver-related user-space components, inference runtime libraries, and operator libraries, coupled with strong coupling to device firmware / driver versions, leads to more pronounced issues in offline image delivery, including redundant dependency transmissions, redundant storage, and low update efficiency. This makes it difficult to achieve a balance between data volume, speed, storage, and reliability in offline delivery. Summary of the Invention

[0004] To address the problems in the prior art, this invention provides a method and system for distributing and deploying container images under offline conditions for ASIC edge devices. This method can significantly reduce the amount of data distributed offline, improve the speed and stability of offline deployment, and ensure the trustworthiness of packets sent on offline media through signature verification and security checks. This facilitates traceability and operation and maintenance auditing, resulting in higher security.

[0005] The present invention provides a method for distributing and deploying container images under offline conditions of ASIC edge devices, comprising the following steps:

[0006] S1: Obtain a list of layers and content hashes for multiple application candidate images on the build side, and identify a set of common dependency layers;

[0007] S2: Package the common dependency layer collection into a read-only format and sign it, then persist it to the read-only partition of the ASIC edge device, while generating a local index;

[0008] S3: When a new container image needs to be deployed, an incremental application layer is built on the build side, and a distribution list of the incremental application layer is generated.

[0009] S4: Deploy the incremental application layer and distribution list to the ASIC edge device via offline media; S5: Verify the incremental application layer and distribution list deployed offline. If the verification fails, the deployment is rejected. If the verification passes, proceed to step S6.

[0010] S6: Container Deployment: Based on the distribution manifest, query the local index to obtain the common dependency layer set, and then combine the common dependency layer set with the incremental application layer into a container image of the root file system and deploy it.

[0011] Furthermore, it also includes step S7: start the container, if the start is abnormal, restore the old version or refuse to deploy and report the reason, and periodically perform garbage collection on the old incremental application layer.

[0012] Furthermore, in step S1, for the multiple application candidate images obtained, the set of common dependency layers is identified by the layer reuse frequency in the statistical layer list. The specific processing method is as follows:

[0013] (1) Count the number of times each layer l appears in multiple application candidate images, freq(l), where l is a positive integer;

[0014] (2) When the number of times freq(l) is greater than the first threshold and the volume size(l) of each layer is greater than the second threshold, it is retained as a candidate common dependency layer;

[0015] (3) Sort the candidate common dependency layers and select the top K or top N candidate common dependency layers whose cumulative volume reaches the third threshold as the common dependency layer set base_layers.

[0016] Furthermore, step (2) also includes the condition: layers whose content hash remains unchanged within consecutive version windows are retained as candidate public dependency layers.

[0017] Furthermore, in step S4, the incremental application layer is distributed in chunks and carries a chunk index.

[0018] Furthermore, in step S4, large files in the incremental application layer data packets are divided into content-defined blocks, while the remaining data is divided into fixed blocks. At the same time, the block index is constructed using a segmented digest or Merkle tree structure that enables on-demand verification and partial retransmission.

[0019] Furthermore, in step S5, the local existing blocks are verified based on the block index. If more than one block is missing, a missing block set is generated. Then, based on the missing block set, the interrupted resume import is performed.

[0020] Furthermore, the offline medium includes redundant blocks or erasure coding blocks. When there is a set of missing blocks, the ASIC edge device initiates block requests to multiple neighboring nodes in parallel for the same missing block and selects the missing block based on the best result.

[0021] This invention also provides a container image distribution and deployment system for offline conditions of ASIC edge devices, used to implement the container image distribution and deployment method for offline conditions of ASIC edge devices, including:

[0022] Image layer analyzer: used to obtain a list of layers and content hashes of multiple application candidate images on the build side, and identify a set of common dependency layers;

[0023] Common dependency layer solidification module: used to package the common dependency layer collection into a read-only format and sign it, then solidify it to the read-only partition of the ASIC edge device, while generating a local index;

[0024] Incremental application layer build module: used to build the incremental application layer on the build side when a new container image needs to be deployed, and to generate the distribution list of the incremental application layer;

[0025] Local Mirror Cache and Index Module: This module maintains the index table for local indexes and provides a local query interface.

[0026] Deployment agent module: used to verify the incremental application layer and distribution list distributed offline, query the local index to hit the common dependency layer, and complete the container image synthesis and container startup scheduling of the root file system;

[0027] Container runtime integration layer: used to enhance the container runtime's parsing logic for the local layer, and prioritize loading common dependency layers from the local index when creating an image or starting a container;

[0028] Security verification module: Used to perform security verification on public dependency layer data packets, incremental application layer data packets and distribution manifests.

[0029] Furthermore, it also includes a monitoring and alarm module, which records the deployment process, running status and abnormal events, and triggers the restoration of the old version and garbage collection strategy.

[0030] Compared with the prior art, the beneficial effects of the present invention are:

[0031] 1. This invention solidifies the long-term unchanging underlying dependencies into a common dependency layer, and the application only distributes incremental application layers, reducing repeated transmission and significantly reducing the amount of offline distributed data;

[0032] 2. This invention prioritizes the local dependency layer on the device side and quickly synthesizes a runnable root file system, shortening deployment latency and reducing manual operations, effectively improving the speed and stability of offline deployment.

[0033] 3. This invention supports lightweight offline updates. Application upgrades only require the transmission of the incremental application layer and its distribution list, avoiding the retransmission of the complete image and improving iteration frequency and efficiency.

[0034] 4. This invention ensures the reliability of packets sent on offline media through signature verification and integrity verification chains, which facilitates traceability and operation and maintenance auditing, and effectively enhances the security of offline deployment. Attached Figure Description

[0035] To more clearly illustrate the solutions in this invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0036] Figure 1 This is a flowchart of the method of the present invention;

[0037] Figure 2 This is a block diagram of the container image distribution and deployment system of the present invention. Detailed Implementation

[0038] Unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings are used to distinguish different objects, not to describe a particular order.

[0039] In this invention, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment to other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this invention can be combined with other embodiments.

[0040] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0041] like Figure 1As shown, the container image distribution and deployment method for ASIC edge devices under offline conditions of the present invention includes the following steps:

[0042] S1: Obtain a list of layers and content hashes for multiple application candidate images on the build side, and identify a set of common dependency layers;

[0043] S2: Package the common dependency layer collection into a read-only format and sign it, then persist it to the read-only partition of the ASIC edge device, while generating a local index;

[0044] S3: When a new container image needs to be deployed, an incremental application layer is built on the build side, and a distribution list of the incremental application layer is generated.

[0045] S4: Deploy the incremental application layer and distribution list to the ASIC edge device via offline media; S5: Verify the incremental application layer and distribution list deployed offline. If the verification fails, the deployment is rejected. If the verification passes, proceed to step S6.

[0046] S6: Container Deployment: Based on the distribution manifest, query the local index to obtain the common dependency layer set, and then combine the common dependency layer set with the incremental application layer into a container image of the root file system and deploy it.

[0047] Preferably, the present invention further includes step S7: automatically starting the container; if the startup is abnormal, restoring the old version or refusing deployment and reporting the reason; and periodically performing garbage collection on the old incremental application layer.

[0048] The deployment of this invention does not rely on online retrieval from the public network or a central repository. Instead, it reads the distribution package from offline media, such as USB flash drives, temporary LANs on the tooling machine, offline artifact packages, or the device-side local artifact library, under offline or weak network conditions. This package is then imported into the device-side local content-addressed storage (CAS) and indexing system. Subsequently, the container runtime integration layer completes the deployment based on the required layer data from the index. This allows the invention to be applicable to scenarios where devices are unable to connect to the network for extended periods or have extremely low bandwidth, and where on-site maintenance windows are short and available storage is limited.

[0049] Compared with the prior art, the present invention has the following advantages:

[0050] 1. This invention solidifies the long-term unchanging underlying dependencies into a common dependency layer, and the application only distributes incremental application layers, reducing repeated transmission and significantly reducing the amount of offline distributed data;

[0051] 2. This invention prioritizes the local dependency layer on the device side and quickly synthesizes a runnable root file system, shortening deployment latency and reducing manual operations, effectively improving the speed and stability of offline deployment.

[0052] 3. This invention supports lightweight offline updates. Application upgrades only require the transmission of the incremental application layer and its distribution list, avoiding the retransmission of the complete image and improving iteration frequency and efficiency.

[0053] 4. This invention ensures the reliability of packets sent on offline media through signature verification and integrity verification chains, which facilitates traceability and operation and maintenance auditing, and effectively enhances the security of offline deployment.

[0054] like Figure 2 As shown, this example also provides a container image distribution and deployment system under offline conditions of ASIC edge devices, used to implement the container image distribution and deployment method under offline conditions of ASIC edge devices, including:

[0055] Image layer analyzer: used to obtain a list of layers and content hashes of multiple application candidate images on the build side, and identify a set of common dependency layers;

[0056] Common dependency layer solidification module: used to package the common dependency layer collection into a read-only format and sign it, then solidify it to the read-only partition of the ASIC edge device, while generating a local index;

[0057] Incremental application layer build module: used to build the incremental application layer on the build side when a new container image needs to be deployed, and to generate the distribution list of the incremental application layer;

[0058] Local Mirror Cache and Index Module: This module maintains the index table for local indexes and provides a local query interface.

[0059] Deployment agent module: used to verify the incremental application layer and distribution list distributed offline, query the local index to hit the common dependency layer, and complete the container image synthesis and container startup scheduling of the root file system;

[0060] Container runtime integration layer: used to enhance the parsing logic of the container runtime for the local layer, and to load the common dependency layer from the local index first when creating an image or starting a container, avoiding remote fetching or repeated imports;

[0061] The local priority resolution of the container runtime integration layer can at least satisfy the following: when the distribution manifest of the application to be deployed declares the list of dependency layers, the runtime or its integration layer first queries the local index to obtain the path and directly mounts it as lowerdir; only when the index is missing or the verification fails will it enter the branch of importing offline packages and rejecting deployment and issuing an alert, so as to avoid rolling back to the full image transfer.

[0062] Security verification module: Used to perform security verification on public dependency layer data packets, incremental application layer data packets and distribution manifests. The security verification includes signature verification, hash verification and audit logs to ensure trustworthiness of offline distribution.

[0063] Furthermore, it also includes a monitoring and alarm module, which records the deployment process, running status and abnormal events, and triggers the restoration of the old version and garbage collection strategy to free up storage space.

[0064] This invention constructs a side-image layer analyzer to extract the common dependency layer and solidify it into a device-side read-only shared layer. It uses a local image cache and index module to provide deterministic hit capability for content hashing to local paths. It uses a deployment agent to complete the closed-loop execution of verification-hit-composition-startup under offline conditions. It uses a container runtime integration layer to implement a local priority resolution strategy. Thus, the offline distribution of this invention changes from complete image transport to a combined offline deployment mechanism of common dependency layer reuse and incremental application layer distribution. It can achieve verifiable, rollbackable, secure and reliable container images, and can repeatedly obtain consistent deployment and running results under the same common dependency layer version and the same incremental application layer package.

[0065] The execution method of the present invention will be described in detail below with reference to specific modules.

[0066] In step S1, the image layer analyzer identifies the set of common dependency layers for the multiple application candidate images obtained by statistically analyzing the layer reuse frequency in the layer list. The specific processing method is as follows:

[0067] (1) Count the number of times each layer l appears in multiple application candidate images, freq(l), where l is a positive integer;

[0068] (2) When the number of times freq(l) is greater than the first threshold and the volume size(l) of each layer is greater than the second threshold, it is retained as a candidate common dependency layer;

[0069] (3) Sort the candidate common dependency layers and select the top K or top N layers whose cumulative volume reaches the third threshold T. vol The candidate common dependency layers are set as base_layers.

[0070] This example sorts candidate common dependency layers by score(l) = freq(l)·size(l) or other monotonic scores. To avoid solidifying a large number of small layers and increasing indexing and management overhead, the score(l) in this example favors highly reusable and large-volume layers to maximize deduplication and transmission savings. The quantity K and the third threshold T... vol The number of common dependency layers and the upper limit of the cumulative volume of common dependency layers are controlled separately, so that the common dependency layers are fixed within the controllable device storage boundary.

[0071] Furthermore, when similar but not stable dependencies exist in different application images, judging common dependencies solely by frequency of occurrence may cause the set of common dependencies to fluctuate with the application set, increasing the complexity of fixation and rollback. Therefore, to balance the stability of common dependency identification with misjudgment control, this example introduces stability constraints and blacklists / whitelists in addition to the number of occurrences freq(l): layers whose content hashes remain unchanged within consecutive version windows are included in the candidate common dependency layers, layers with high change rates (e.g., layers with frequent configuration / model updates) are forcibly excluded; and tightly coupled stable layers such as drivers / runtime libraries are forcibly included, making the fixation of common dependencies more deterministic.

[0072] In step S2, after the common dependency layer set is built on the build side, a signed common dependency layer package (base_pack) is generated. On the device side, the common dependency layers (base_layers) are solidified as read-only shared layers, mounted in read-only mode (e.g., SquashFS), and a content addressing index is established to generate layer metadata. The common dependency layer solidification format can also be EROFS / DM-Verity images or other equivalent read-only solutions.

[0073] The local index in this example can include the following set of fields: layer_id, content_hash, signature, path, base_tag, created_at, ref_count, and readonly mode. The device-side local image cache and index module in this example also maintains an index table including layer_id, path / hash / signature, etc., providing a local query interface to support a deployment strategy prioritizing local hits. The local index can be implemented using SQLite, key-value storage, or a pure file metadata table, implementing queries that use content_hash / signature as the verification anchor and support local-priority hit queries.

[0074] In step S3, when building the application image, this invention only generates an incremental application layer containing application logic, model files, and configuration, without repeatedly carrying the content of the common dependency layer, and generates a corresponding distribution manifest. In this example, the distribution manifest at least declares base_layers / app_layer / content_hashes / signature, and includes driver_version_rule (driver version constraint rule) / abi_id (application binary interface identifier) ​​to constrain ASIC dependency consistency.

[0075] In step S4, the incremental application layer is distributed in chunks, carrying a chunk index. Smaller offline chunk granularity results in better deduplication, but increases the size of the chunk index and raises verification / addressing overhead. To ensure deployment within device resource boundaries, this example employs a combination of fixed-size chunks and Content-Defined Chunk (CDC) for chunking. CDC is used for large files to improve cross-version deduplication, while fixed chunks are used for other data to control the index size. Simultaneously, the chunk index uses segmented summaries or a Merkle tree structure to support on-demand verification and partial retransmission, avoiding full scans during each import.

[0076] In step S5, the Deploy Agent (device-side) module receives the incremental application layer package and Manifest (distribution list) distributed offline, performs signature verification and integrity verification, queries the local index to find common dependency layers, and completes root file system synthesis and container startup scheduling. In scenarios using offline media such as USB flash drive copying or temporary links on a workpiece, single-source data corruption can lead to import failure. Therefore, in this example, the incremental application layer package app_pack preferably includes redundant chunks or erasure coding chunks, and uses chunk hashes and checksums to constrain data consistency. When generating the chunk set missing_chunks, the device side simultaneously records the set of available sources, pulls the same missing chunk from multiple peers (neighbor nodes) in parallel, and converges based on the best verification result, making the import robust even when the offline link is unstable.

[0077] The deployment agent module performs signature and content hash verification, and performs consistency checks on the fields driver_version_rule / abi_id. If the requirements are not met, deployment is rejected or rollback is performed.

[0078] In step S6, after the verification is passed, the deployment agent module queries the local index according to the distribution manifest to find all common dependency layers base_layers, and synthesizes the root file system rootfs_merged with the common dependency layers as the lowerdir and the incremental application layers as the upperdir.

[0079] In step S7, the deployment agent module calls the container runtime to create and start the container, and the monitoring and alarm module records the startup results and running metrics. When a startup anomaly occurs, an audit is recorded and the system rolls back according to the A / B Slot strategy or the old version. In offline scenarios, deployment failures cannot be quickly repaired online, so a semi-updated state needs to be avoided. Therefore, the deployment agent module performs pre-verification (signature / hash / dependency closure / ASIC compatibility rules) and cold start self-checks before switching the effective slot; it only submits the slot switch when the verification passes and the audit chain is complete; if an anomaly occurs shortly after the switch, it rolls back to the previous slot precisely according to metadata such as the base_tag and retains the evidence chain to ensure recoverability.

[0080] When the device adopts a dual-slot (A / B Slot) strategy, the deployment agent module imports the new version of app_layer and its metadata into a non-current active slot. After completing the signature / hash / driver rule consistency verification and the container cold start self-test passes, it atomically switches the active slot. If an anomaly occurs after the switch, it rolls back to the previous slot and retains the audit record, thereby achieving a fast-recovery and traceable update closed loop in offline scenarios.

[0081] When a device recovers from offline status and accesses an available link, the deployment agent module can perform differential synchronization and version alignment operations without affecting the operation of the currently active slots. Based on the current Manifest and local CAS / index, it only synchronizes the missing block hashes and their metadata digests, and updates the version graph and audit records after synchronization. When an inconsistency is detected between the target version and the local base_tag, it only synchronizes the required incremental application layer blocks and minimizes the metadata closure, avoiding a rollback to full image / full packet transmission during the network recovery phase. This extends the offline closed-loop deployment to low-overhead alignment after network recovery, making it compatible with more scenarios.

[0082] In summary, the present invention has the following innovative features:

[0083] 1. Public Dependency Layer Solidification: The public dependency layer (base_layers) is solidified in read-only format on an independent partition or read-only directory on the device side, serving as a long-term, stable dependency foundation shared across applications and avoiding duplicate usage. To prevent the shared attributes of the public dependency layer from being damaged during offline maintenance or accidental operations, this invention can impose read-only constraints on the solidification and loading of the public dependency layer, and force the use of read-only mount parameters during mounting; the deployment proxy module verifies that the mount point of the public dependency layer is in a read-only state and that its content_hash / signature / base_tag is consistent with the index before synthesis. If these conditions are not met, synthesis is rejected and a rollback or alarm is triggered, thereby ensuring the determinism and verifiability of the public dependency layer under cross-application reuse conditions.

[0084] 2. Incremental application layer construction: Each application update only adds or replaces the incremental application layer app_layer, and stores it in the local CAS with content hash deduplication, without copying the common dependency layer into the application layer to form a complete image copy.

[0085] When an offline artifact package contains common dependency layer content equivalent to base_layers, it is not written to the incremental application layer storage path. Instead, its hash reference is registered and the solidified common dependency layer is reused. When the corresponding base_tag has not been solidified on the device side, the processing branch of solidifying the common dependency layer first and then importing the incremental application layer is entered, or the deployment is rejected and the reason is returned. This effectively suppresses duplicate occupation in the long term on storage-constrained ASIC edge devices.

[0086] 3. Combined loading: During the deployment phase, the runtime integration layer uses the common dependency layer as the lowerdir and the incremental application layer as the upperdir to perform OverlayFS synthesis, thereby loading the two layer sets at runtime. On the device side, only one copy of the common dependency layer and multiple copies of the application incremental application layer are retained in the long term, saving storage space.

[0087] For x86 / ARM servers or conventional edge gateways with good network conditions and sufficient storage, the common practice is to import a complete image or create a complete image cache copy on the node side with each delivery. This makes the problems of repeated dependency transmission, repeated storage occupation and version drift more acute. This invention anchors the underlying dependencies stably in the device through public dependency layer solidification and trusted verification chain, and realizes high-frequency updates through incremental application layer. This makes it more suitable for the long-term operation and maintenance of ASIC edge terminals in offline or weak network conditions, and can significantly reduce offline distribution time and storage occupation.

[0088] The specific embodiments described above are preferred embodiments of the present invention and are not intended to limit the specific scope of the present invention. The scope of the present invention includes, but is not limited to, these specific embodiments. All equivalent changes made in accordance with the present invention are within the protection scope of the present invention.

Claims

1. A method for distributing and deploying container images under offline conditions of ASIC edge devices, characterized in that, Includes the following steps: S1: Obtain a list of layers and content hashes for multiple application candidate images on the build side, and identify a set of common dependency layers; S2: Package the common dependency layer collection into a read-only format and sign it, then persist it to the read-only partition of the ASIC edge device, while generating a local index; S3: When a new container image needs to be deployed, an incremental application layer is built on the build side, and a distribution list of the incremental application layer is generated. S4: Deploy incremental application layers and distribution lists to ASIC edge devices via offline media; S5: Verify the incremental application layer and distribution list issued offline. If the verification fails, reject the deployment. If the verification passes, proceed to step S6. S6: Container Deployment: Based on the distribution manifest, query the local index to obtain the set of common dependency layers, then combine the set of common dependency layers with the incremental application layer into a container image with the root file system and deploy it. In step S1, for the multiple application candidate images obtained, the common dependency layer set is identified by the layer reuse frequency in the statistical layer list. The specific processing method is as follows: (1) Count the number of times each layer l appears in multiple application candidate images, freq(l), where l is a positive integer; (2) When the number of times freq(l) is greater than the first threshold and the volume size(l) of each layer is greater than the second threshold, it is retained as a candidate common dependency layer; (3) Sort the candidate common dependency layers and select the top K or top N candidate common dependency layers whose cumulative volume reaches the third threshold as the common dependency layer set base_layers. Step (2) also includes the condition: retaining layers whose content hash remains unchanged within consecutive version windows as candidate public dependency layers.

2. The method for distributing and deploying container images under offline conditions for ASIC edge devices according to claim 1, characterized in that: It also includes step S7: start the container, if the start is abnormal, restore the old version or refuse to deploy and report the reason, and periodically perform garbage collection on the old incremental application layer.

3. The method for distributing and deploying container images under offline conditions for ASIC edge devices according to claim 1, characterized in that: In step S4, the incremental application layer is distributed in blocks and carries a block index.

4. The method for distributing and deploying container images under offline conditions for ASIC edge devices according to claim 3, characterized in that: In step S4, large files in the incremental application layer data packets are divided into content-defined blocks, while the remaining data is divided into fixed blocks. At the same time, the block index adopts a segmented digest or Merkle tree structure that can verify and retransmit locally as needed.

5. The method for distributing and deploying container images under offline conditions for ASIC edge devices according to claim 4, characterized in that: In step S5, the local block is checked based on the block index. If more than one block is missing, a missing block set is generated. Then, based on the missing block set, the interrupted resume import is performed.

6. The method for distributing and deploying container images under offline conditions for ASIC edge devices according to claim 5, characterized in that: The offline medium includes redundant blocks or erasure coding blocks. When there is a set of missing blocks, the ASIC edge device initiates block requests to multiple neighboring nodes in parallel for the same missing block and selects the missing block based on the best result.

7. A container image distribution and deployment system for offline conditions of ASIC edge devices, used to implement the container image distribution and deployment method for offline conditions of ASIC edge devices as described in any one of claims 1-6, characterized in that, include: Image layer analyzer: used to obtain a list of layers and content hashes of multiple application candidate images on the build side, and identify a set of common dependency layers; Common dependency layer solidification module: used to package the common dependency layer collection into a read-only format and sign it, then solidify it to the read-only partition of the ASIC edge device, while generating a local index; Incremental application layer build module: used to build the incremental application layer on the build side when a new container image needs to be deployed, and to generate the distribution list of the incremental application layer; Local Mirror Cache and Index Module: This module maintains the index table for local indexes and provides a local query interface. Deployment agent module: used to verify the incremental application layer and distribution list distributed offline, query the local index to hit the common dependency layer, and complete the container image synthesis and container startup scheduling of the root file system; Container runtime integration layer: used to enhance the container runtime's parsing logic for the local layer, and prioritize loading common dependency layers from the local index when creating an image or starting a container; Security verification module: Used to perform security verification on public dependency layer data packets, incremental application layer data packets and distribution manifests.

8. The container image distribution and deployment system for ASIC edge devices under offline conditions according to claim 7, characterized in that: It also includes a monitoring and alarm module, which records the deployment process, running status and abnormal events, and triggers the restoration of the old version and garbage collection strategy.

Images