An image management tool and method for dynamically managing image repositories

Abstract

This invention relates to the field of containerization technology, and more particularly to an image management tool and method for dynamically managing image repositories. The tool includes a front-end visual management interface via HTTP communication and a back-end data interaction module. The front-end is used for command interaction and result display, while the back-end interacts with the image repository via the Artifactory REST API. This tool is suitable for integration into CI / CD pipelines, container orchestration platforms, or deployment as a standalone tool within enterprise infrastructure. This invention's tool achieves remote automated management of image repositories through a front-end / back-end separation architecture and deep integration with the Artifactory REST API. The visual interface reduces operational complexity, and the multi-platform integration capability adapts to diverse operational scenarios, improving image management efficiency and deployment flexibility.

Description

Technical Field

[0001] This invention relates to the field of containerization technology, and in particular to an image management tool and method for dynamically managing image repositories. Background Technology

[0002] Currently, with the widespread adoption of containerization technology, Docker image repositories have become a core component of enterprise DevOps processes. For the management of mainstream repositories such as Artifactory, existing solutions largely rely on their native web interfaces or command-line tools. These methods have significant limitations in terms of tool architecture and usage patterns. Existing tools are typically monolithic or tightly coupled front-end and back-end designs, resulting in rigid deployment patterns that make it difficult to flexibly deploy independently or integrate into different automated pipelines according to actual operational needs. Operational interactions are primarily based on the repository's native general management interface, leading to cumbersome and inefficient steps for users when filtering images and performing batch operations. Furthermore, the functionality and deployment modes of existing tools are relatively limited, failing to meet the demands of enterprises' complex and ever-changing infrastructure environments and operational scenarios for flexible, efficient, and easily integrated image management tools.

[0003] Therefore, there is an urgent need to provide a technical solution to address the above problems. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides an image management tool and method for dynamically managing image repositories.

[0005] In a first aspect, the present invention provides an image management tool for dynamically managing image repositories, the technical solution of which is as follows:

[0006] The image management tool for dynamically managing image repositories includes:

[0007] A front-end visual management interface is used to receive user instructions and / or display the operation process or operation results;

[0008] The backend data interaction module is used to interact with the image repository using the Artifactory REST API to obtain image metadata, and / or to operate on the image metadata of the image repository;

[0009] The front-end visual management interface and the back-end data interaction module communicate using HTTP requests;

[0010] The image management tool can be integrated into the CI / CD pipeline of an enterprise-level DevOps platform, or into a container orchestration platform, or used as a standalone tool for managing Artifactory image repositories in enterprise private clouds or data center infrastructure.

[0011] The beneficial effects of the image management tool for dynamically managing image repositories according to the present invention are as follows:

[0012] The tool of this invention achieves remote automated management of image repositories through deep integration with the Artifactory REST API via a front-end and back-end separation architecture; it reduces operational complexity through a visual interface and adapts to diverse operation and maintenance scenarios through multi-platform integration capabilities, thereby improving image management efficiency and deployment flexibility.

[0013] Based on the above solution, the image management tool for dynamically managing image repositories of the present invention can be further improved as follows.

[0014] In one alternative approach, the front-end visual management interface is implemented using HTML, JavaScript, and CSS, and a responsive configuration panel is developed based on the Vue.js framework.

[0015] The backend data interaction module is implemented using PHP scripts and is used to call the Artifactory REST API and interact with the local image metadata database. The local image metadata database uses a MySQL database to store image metadata, operation logs, and risk score information.

[0016] Among the above-mentioned optional methods, the front-end uses the Vue.js framework to develop a responsive configuration panel, and the back-end is implemented using PHP scripts, interacting with a local mirror metadata database built on MySQL. This technology selection further enhances the system's usability: Vue.js's responsive features optimize the user configuration experience, supporting dynamic field folding and abnormal data highlighting, significantly enhancing human-computer interaction efficiency; the mature ecosystem combination of PHP and MySQL reduces development and maintenance costs, while MySQL efficiently supports the structured storage of mirror metadata, operation logs, and risk scores, providing a reliable persistence layer for incremental retrieval, multi-dimensional sorting and filtering, and data querying and updating of the accidental deletion risk assessment model, improving the system's data processing capabilities and response speed.

[0017] Secondly, the present invention provides an image management method based on an image management tool, the technical solution of which is as follows:

[0018] The backend data interaction module determines whether the local image metadata database supports the last_pull_timestamp and last_pull_version fields. If it does, it uses an incremental pull strategy to pull image metadata updated since the last synchronization from the image repository.

[0019] The image metadata is displayed through a front-end visual management interface based on a pre-defined management strategy, and the back-end data interaction module executes the corresponding image cleanup operations according to the cleanup rules in the management strategy.

[0020] The beneficial effects of the image management method based on an image management tool of the present invention are as follows:

[0021] The method of this invention achieves remote automated management of image repositories through deep integration of a front-end and back-end separation architecture with the Artifactory REST API; it reduces operational complexity through a visual interface and adapts to diverse operation and maintenance scenarios through multi-platform integration capabilities, thereby improving image management efficiency and deployment flexibility.

[0022] Based on the above scheme, the image management method based on the image management tool of the present invention can be further improved as follows.

[0023] In one alternative approach, if the local image metadata database does not support the last_pull_timestamp and last_pull_version fields, the backend data interaction module adds the last_pull_timestamp and last_pull_version fields to the local image metadata database.

[0024] The incremental pull strategy for retrieving updated image metadata from the image repository includes:

[0025] The backend data interaction module generates timestamp filtering parameters based on the last_pull_timestamp and / or generates version comparison conditions based on the last_pull_version, calls the Artifactory REST API and attaches the timestamp filtering parameters or the version comparison conditions to pull image metadata that has been updated since the last synchronization.

[0026] In the above optional methods, if the local mirror metadata database does not support key fields, the last_pull_timestamp and last_pull_version fields are dynamically added, and filter conditions are generated based on these fields to call the Artifactory REST API to achieve incremental pull. This avoids the high-frequency API calls and large data transfers caused by full synchronization, significantly reducing the load on the Artifactory server and network bandwidth usage. In particular, it greatly improves data synchronization efficiency when the repository is not frequently updated. At the same time, the automatic field adaptation mechanism enhances the tool's compatibility with different environment configurations.

[0027] In one alternative approach, before using an incremental pull strategy to pull image metadata updated since the last synchronization from the image repository, the method further includes:

[0028] The system receives configuration information triggered by the user through a front-end visual management interface and responds to the configuration information to perform configuration. The configuration information includes the filtering conditions for the mirrored data displayed on the page, the sorting rules based on the filtering conditions, and / or the display method.

[0029] When the backend data interaction module retrieves incremental image metadata, it processes it according to the filtering conditions and sorting rules through the frontend visual management interface, and then displays it visually according to the display method.

[0030] The visualized content includes the basic attributes of the image metadata and the risk score of the image metadata. The risk score is determined by the backend data interaction module using a pre-built accidental deletion risk assessment model.

[0031] Among the above optional methods, the image metadata is queried and displayed according to the sorting and filtering conditions configured by the user in the visualization interface. At the same time, the risk score calculated based on the accidental deletion risk assessment model is displayed. The combination of user-defined view and intelligent risk assessment enables operation and maintenance personnel to flexibly organize the information display priority as needed, and intuitively identify key images through risk scores. This effectively solves the defects of rigid information display and reliance on human experience judgment in traditional tools, and improves decision-making efficiency and accuracy.

[0032] In one optional approach, when the backend data interaction module retrieves incremental image metadata, during the processing via the frontend visual management interface according to the filtering conditions and sorting rules, the method further includes: the backend data interaction module obtaining a risk score based on a pre-built accidental deletion risk assessment model; specifically:

[0033] The backend data interaction module obtains the number of times the image is pulled and the creation time of the image corresponding to the image metadata, determines the pull frequency and image age, and performs normalization processing on them respectively to obtain the pull frequency value and image age value.

[0034] Based on the tag list in the image metadata, a pre-stored tag importance lookup table is queried to determine the tag importance value of the corresponding tag; wherein, when the image contains multiple tags, the highest value is taken as the tag importance value;

[0035] Based on preset weighting coefficients, the pull frequency value, the tag importance value, and the mirror age value are weighted and summed to obtain the risk score.

[0036] Among the above-mentioned optional methods, the frequency and age of the image are calculated by obtaining the number of times the image is pulled and the creation time, and then normalized. The tag weight is queried by combining the tag importance comparison table, and finally the risk score is obtained by weighted summation. A data-driven quantitative assessment model is constructed, which transforms the image activity, business value and life cycle into comparable numerical indicators. This overcomes the arbitrariness of subjective judgment in traditional management methods, realizes the standardization and objectification of risk assessment, and provides a reliable basis for subsequent graded protection.

[0037] In one optional approach, the backend data interaction module obtains the number of times the image is pulled and the creation time corresponding to the image metadata, calculates the pull frequency and image age, and performs normalization processing on each to obtain the pull frequency value and image age value, including:

[0038] The backend data interaction module divides the number of times the image metadata is pulled by a preset time window to obtain the pull frequency, and then normalizes the pull frequency by the maximum frequency among all images to obtain the pull frequency value.

[0039] The image age is determined based on the image creation time in the image metadata, and then normalized by dividing the image age by the maximum age among all images to obtain the image age value.

[0040] Among the above optional methods, the normalization calculation method specifically adopted provides reproducible and configurable scoring calculation details, making indicators of different dimensions comparable. At the same time, by selecting dynamic maximum values ​​or fixed thresholds, the model's adaptability to warehouses of different sizes is enhanced, ensuring the algorithm's feasibility and computational consistency in actual deployment.

[0041] In an alternative approach, the method further includes, before performing the corresponding image cleanup operation:

[0042] The backend data interaction module determines the image deletion strategy based on the risk score and performs corresponding image cleanup operations according to the deletion strategy; the deletion strategy includes at least one of direct deletion, requiring user confirmation, requiring secondary administrator confirmation, and pausing deletion and notifying the administrator.

[0043] Among the above-mentioned optional methods, the hierarchical deletion strategy based on risk score automatic mapping, such as direct deletion, user confirmation, administrator confirmation or pause notification, achieves fine-grained control of the cleanup operation. The corresponding security verification level is automatically matched according to the importance of the image, which not only ensures the rapid cleanup efficiency of low-value images, but also sets up multiple protection barriers for high-value images, thereby achieving an effective balance between storage optimization and business continuity.

[0044] In one alternative approach, the backend data interaction module performs corresponding image cleanup operations based on the deletion strategy, including:

[0045] When the deletion policy requires user confirmation or secondary administrator confirmation, a confirmation request is sent to the front-end visual management interface, and the Artifactory REST API is called to execute the deletion after receiving the confirmation instruction;

[0046] When the deletion policy is to pause deletion and notify the administrator, the current operation is paused, a notification is sent to the designated administrator, and the decision on whether to execute the deletion is made after receiving the administrator's approval instruction.

[0047] Among the above optional methods, a front-end confirmation pop-up or administrator email notification is triggered for different strategies, and the API is called to execute the deletion after receiving the instruction. The risk assessment results are transformed into a clear execution process. The human-machine collaboration mechanism ensures that high-risk operations are fully authorized, avoids accidental deletion accidents that may be caused by automated processes, and retains the flexibility of human intervention, which significantly improves the security, reliability and traceability of the operation.

[0048] In an alternative approach, after performing the image cleanup operation, the method further includes:

[0049] The backend data interaction module stores operation logs containing corresponding operation processes in the local mirror metadata database; these operation logs are used to support historical operation queries, audit trails, and data updates for the accidental deletion risk assessment model in the frontend visual management interface.

[0050] The operation log includes: operation identifier, image identifier, image version, risk score, operator, operation time, and operation result.

[0051] In the above-mentioned optional methods, the process data of each cleanup operation (including operation identifier, image information, risk score, etc.) is persisted to the local image metadata database, which builds a complete operation audit trail. This not only meets the enterprise's compliance review requirements, but also provides a data foundation for subsequent accountability and model iteration. At the same time, the log feedback mechanism continuously optimizes and evaluates the model parameters, forming a management closed loop.

[0052] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0053] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0054] Figure 1 This is a schematic diagram of the structure of an image management tool for dynamically managing an image repository according to the present invention;

[0055] Figure 2 This is a flowchart illustrating an image management method based on an image management tool according to the present invention.

[0056] Figure 3 This is a schematic diagram of the incremental retrieval process of image metadata according to the present invention;

[0057] Figure 4 This is a schematic diagram of the mirror version list and batch deletion operation interface of the present invention;

[0058] Figure 5 This is a schematic diagram of the risk-scoring-based mirror cleanup process of the present invention. Detailed Implementation

[0059] In the field of image repository management, image metadata refers to a collection of information describing the attributes of a Docker image, rather than the binary data of the image file itself. This includes key descriptive fields such as image name, version number, creation time, storage size, number of pulls, and tag list. Image cleanup operations refer to the batch deletion of historical or expired images. This operation directly determines storage resource utilization and operational costs, and is particularly important in production environments because accidentally deleting critical images can lead to major incidents such as CI / CD pipeline failures, inability to roll back in the production environment, and even business system unavailability.

[0060] Current technologies for image cleanup operations primarily rely on manual, one-by-one deletion or batch processing using scripts based on simple time rules. While Artifactory's native functionality provides a basic REST API interface, it lacks intelligent support for batch deletion. Users must manually assess the importance of images, which is inefficient and extremely risky. These traditional methods suffer from three core flaws: First, they are inefficient, failing to quickly filter images based on actual usage frequency and business value; second, the information presentation is incomplete, providing only a basic image list without in-depth analysis and visualization, making it difficult for users to quickly locate cleanupable objects; and third, they lack intelligent management strategies, failing to establish a quantitative evaluation mechanism to identify high-value images, making them highly susceptible to accidental deletion due to misjudgment.

[0061] To address the aforementioned drawbacks, the core idea of ​​this invention is to construct an automated operation tool based on the Artifactory REST API. This tool achieves comprehensive and persistent management of image information by establishing a local image metadata database and integrates a risk assessment model for accidental deletion to quantify the importance of images. Based on this risk score, a tiered deletion strategy is implemented. This invention centrally stores image metadata in a local MySQL database, combines it with a PHP backend for incremental retrieval and intelligent filtering, and provides configurable display and interactive capabilities in a front-end visual management interface. Finally, based on preset cleanup rules and risk score thresholds, it executes a multi-level protection mechanism including direct deletion, user confirmation, secondary administrator confirmation, and suspension of deletion with administrator notification. This effectively avoids the inherent defects of existing technologies, such as low efficiency of manual operation, limited information display, and lack of intelligent assessment, significantly improving the automation level and operational security of Docker image repositories.

[0062] It is worth noting that the technical principle of this invention differs fundamentally from traditional local file deletion tools (such as disk cleanup software). The latter directly manipulate the local operating system file system, handling static, stateless, ordinary files. This invention, however, is geared towards enterprise-level, containerized Docker image repository management. Its operations target logical image artifacts stored in a remote Artifactory service. Each management operation (such as querying or deleting) requires a network call to the standard Artifactory REST API, and must undergo strict authentication, permission verification, repository status confirmation, and API return result verification. This remote service-oriented, standard interface-based operation mode is the technological cornerstone of this tool's automation and integration capabilities.

[0063] Furthermore, Docker image management has significant business-specific characteristics, which determines that its cleanup work is fundamentally different from ordinary file cleanup. Docker images are typically large in size, resulting in high storage costs; frequent version iterations lead to a large accumulation of historical versions in the repository; and complex dependencies exist between images. More importantly, accidentally deleting a critical image currently in use in the production environment can cause CI / CD pipeline interruptions, irreversible production system rollbacks, and even business service unavailability, with high recovery costs and systemic impacts. Therefore, Docker image cleanup cannot be based solely on simple file "newness" or "size" rules, but must introduce an intelligent mechanism that comprehensively assesses its business importance and usage risks.

[0064] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0065] Figure 1 The diagram illustrates a structural schematic of an embodiment of an image management tool for dynamically managing image repositories provided by the present invention, as shown below. Figure 1 As shown, the tool includes:

[0066] A front-end visual management interface is used to receive user instructions and / or display the operation process or operation results;

[0067] The backend data interaction module is used to interact with the image repository using the Artifactory REST API to obtain image metadata, and / or to operate on the image metadata of the image repository;

[0068] The front-end visual management interface and the back-end data interaction module communicate using HTTP requests;

[0069] Image management tools can be integrated into the CI / CD pipeline of an enterprise-level DevOps platform, or into a container orchestration platform, or used as a standalone tool for managing Artifactory image repositories in enterprise private clouds or data center infrastructure.

[0070] It should be noted that this image management tool adopts a front-end and back-end separation architecture. Logically, it consists of a front-end visual management interface and a back-end data interaction module, forming a complete software system. In actual deployment, the front-end and back-end can be deployed on the same server or on different servers or container environments. However, it is important to clarify that the back-end module must run within the overall framework of this tool and cannot be used as an independent service separate from the front-end. The separation of front-end and back-end is mainly used to decouple the interface display from the core processing logic, thereby improving the system's deployment flexibility and configuration maintainability.

[0071] The front-end visual management interface is the sole entry point for users to interact with the image repository. Its functions include at least: receiving user-input operation commands, such as image filtering criteria, batch deletion requests, and visual configuration parameters; displaying the operation process status, such as incremental pull progress, risk score calculation details, and task execution log cleanup; and presenting operation result data, such as a list of successful / failed deletions, repository space release, and operation audit reports. Display formats include, but are not limited to, diverse visual elements such as tables, charts, pop-ups, and notification bars.

[0072] The backend data interaction module, as the core processing engine of the tool, has the following functions: It utilizes Artifactory's standardized REST API interface to remotely retrieve image metadata from the image repository via the network. This metadata includes descriptive information such as image name, version number, creation time, storage size, number of pulls, and tag list. It also calls the corresponding API endpoints to perform operations such as deletion, tagging, and attribute modification on the target image based on user commands from the frontend. Each API call undergoes authentication, permission verification, repository status confirmation, and result verification to ensure the security and accuracy of the operation.

[0073] Understandably, the front-end visual management interface and the back-end data interaction module communicate using HTTP requests, including but not limited to GET requests (for querying image information), POST requests (for submitting configurations or performing batch operations), and DELETE requests (for triggering image deletion). JSON is preferred as the communication data format to achieve lightweight data exchange.

[0074] Image management tools have multi-scenario integration capabilities, and their application forms include, but are not limited to: integration into the CI / CD pipeline of enterprise-level DevOps platforms (such as Jenkins, GitLab CI / CD), as a link in the automated process, automatically triggering image cleanup or status check tasks during pipeline execution; integration into container orchestration platforms (such as Kubernetes, Docker Swarm), as an operation and maintenance management plugin for cluster image repositories, combined with the deployment and operation and maintenance lifecycle of containerized applications, to ensure timely management and optimization of the images used; or as a standalone software tool, deployed in enterprise private clouds or data center infrastructure, specifically for the daily management of Artifactory image repositories.

[0075] The technical solution in this embodiment achieves remote automated management of image repositories through deep integration of a front-end and back-end separation architecture with the Artifactory REST API; it reduces operational complexity through a visual interface and adapts to diverse operation and maintenance scenarios through multi-platform integration capabilities, thereby improving image management efficiency and deployment flexibility.

[0076] In one alternative approach, the front-end visual management interface is implemented using HTML, JavaScript, and CSS, and a responsive configuration panel is developed based on the Vue.js framework.

[0077] The backend data interaction module is implemented using PHP scripts and is used to call the Artifactory REST API and interact with the local image metadata database. The local image metadata database uses a MySQL database to store image metadata, operation logs, and risk score information.

[0078] In a preferred embodiment, the front-end visual management interface is implemented using basic Web technologies such as HTML, JavaScript, and CSS, and further developed into a responsive configuration panel based on the Vue.js framework. Vue.js's responsive data binding feature ensures that the interface updates in real time when user configurations change, and its component-based architecture facilitates the reuse and expansion of functional modules, effectively supporting advanced interactive functions such as custom display of mirror metadata fields, dynamic pagination loading, and highlighting of abnormal data.

[0079] Specifically, the responsive configuration panel allows users to flexibly select the image metadata fields they want to display (such as image name, version number, creation time, storage size, tags, etc.) through visual forms (including checkboxes, drop-down menus, input boxes, etc.), set default sorting rules (such as descending order by creation time, ascending order by storage size) and filter conditions (such as "show only images within the last 30 days" or "storage size > 1GB"). After the user completes the configuration, it is saved to the local machine or the backend MySQL database. During subsequent queries, the backend PHP script dynamically generates SQL query statements based on the configuration and extracts the corresponding data from the MySQL database.

[0080] The backend data interaction module is implemented using the PHP scripting language, leveraging its mature web development ecosystem (especially its excellent compatibility with MySQL databases) to efficiently complete calls to the Artifactory REST API and local data persistence. The PHP backend mainly handles the following core logic:

[0081] The cURL library is used to initiate an HTTP request to call the Artifactory API to obtain image metadata; the received JSON-formatted metadata is then parsed, cleaned, and converted.

[0082] The incremental pull logic is executed, which means that based on the values ​​of the last_pull_timestamp and last_pull_version fields recorded in the local image metadata database (local MySQL database), the modified_since or version comparison filter conditions are dynamically generated to pull only the newly added or changed image data in the repository.

[0083] Implement paginated query loops and set a reasonable number of records per page (e.g., 100 records per page) to reduce the load of a single request; use batch insert or update methods to write the processed data to MySQL to avoid the overhead of repeated writes.

[0084] It should be noted that the local image metadata database is implemented using a MySQL relational database. Its storage content includes at least three main parts: an image metadata table (such as image_metadata, containing fields such as image_id, image_name, version, pull_count, created_time, size, and tags), a tag importance lookup table (such as tag_weights, containing tag_name and weight fields), and an operation log table (recording detailed information for each cleanup operation). The MySQL database uses primary key indexes and composite indexes to ensure fast response times in high-frequency query scenarios, and its transaction characteristics ensure the atomicity of batch deletion operations and log recording, thereby improving overall system stability and data consistency.

[0085] The `last_pull_timestamp` and `last_pull_version` fields maintained in the local image metadata database are crucial for incremental synchronization. If these two fields do not exist during database initialization, the tool will automatically create them and assign default values. After each successful pull of image metadata, the backend PHP script will write the current operation timestamp to `last_pull_timestamp` and the latest version information to `last_pull_version`, serving as the baseline for the next incremental pull. This avoids full synchronization and significantly improves data synchronization efficiency.

[0086] Figure 2 This diagram illustrates a flowchart of an embodiment of an image management method based on an image management tool provided by the present invention. Figure 2 As shown, this method is executed by an image management tool used for dynamic management of image repositories, and includes the following steps:

[0087] S1. The backend data interaction module determines whether the local image metadata database supports the last_pull_timestamp and last_pull_version fields. If it does, it uses an incremental pull strategy to pull the image metadata that has been updated since the last synchronization from the image repository.

[0088] It should be noted that the local image metadata database refers to the database deployed on the backend of this tool, used to persistently store descriptive information of images obtained from the image repository, and is specifically implemented using a MySQL relational database.

[0089] The `last_pull_timestamp` field is a timestamp field used in this database to record the last successful synchronization of image metadata from the image repository. The `last_pull_version` field is a field used to record the image version identifier corresponding to the last successful synchronization. These two fields together form the basis for determining the range of data updates.

[0090] Incremental pull strategy refers to a synchronization method that only retrieves image metadata that has changed (such as additions or modifications) in the image repository since the last synchronization baseline, rather than pulling all data each time. "Image metadata" refers to information describing the attributes of a Docker image, rather than the binary data of the image itself, and it includes at least the image name, version number, creation time, and storage size.

[0091] In the first optional method, the backend data interaction module determines whether the local image metadata database supports the last_pull_timestamp and last_pull_version fields. If it does, it uses an incremental pull strategy to pull the image metadata that has been updated since the last synchronization from the image repository.

[0092] The front-end visual management interface displays image metadata based on a pre-defined management strategy, and the back-end data interaction module executes corresponding image cleanup operations according to the cleanup rules in the management strategy.

[0093] The specific steps of S1 in this embodiment are as follows:

[0094] S11. Determine whether the last_pull_timestamp and last_pull_version fields already exist and are supported in the local image metadata database.

[0095] S12. If supported by the criteria in S11, an incremental pull strategy is adopted based on the last synchronization baseline recorded in these two fields. Specifically, a timestamp filter parameter for API queries is generated based on last_pull_timestamp, and version comparison conditions are generated based on last_pull_version.

[0096] S13. Call the Artifactory REST API and attach the filter parameters or comparison conditions generated in S12 to the request to pull the image metadata updated since the last synchronization from the specified image repository.

[0097] S14. Store the updated data retrieved in S13 into the local image metadata database or update it.

[0098] It should be noted that the timestamp filtering parameter is a query parameter used when calling the Artifactory REST API to filter artifacts (such as images) that have been modified after a specified time point. Common parameter names are "modified_since" or "lastModified", and its value is the time point recorded in the last_pull_timestamp field, which is usually in the format of an ISO8601 time string.

[0099] Version comparison criteria refer to the filtering logic used to identify images that have changed since a specific version identifier. This can be achieved by comparing the image's tag, digest, or internal version identifier. The specific criteria depend on the specific interface of the Artifactory API and its supported query capabilities. The fundamental purpose of these two parameters or conditions is the same: to serve as a benchmark for incremental synchronization, ensuring that API requests only return image metadata that has been updated since the last recorded time or version, thereby avoiding full data transfer.

[0100] S2. The front-end visual management interface displays the image metadata based on the pre-given management strategy, and the back-end data interaction module executes the corresponding image cleanup operation according to the cleanup rules in the management strategy.

[0101] It should be noted that the management strategy is a comprehensive set of configurations. It includes display configurations (such as field selection, sorting rules, and filtering conditions) to guide the front-end interface in querying and displaying image metadata, as well as cleanup rules (such as deletion conditions based on creation time, version number, or risk score) to define under what conditions certain operations should be performed on which images. The management strategy can be a system preset or can be customized and saved by the user through the front-end interface.

[0102] In this embodiment, the specific steps of S2 are as follows:

[0103] S21. Based on a pre-given or user-configured management strategy, query, sort, and filter the image metadata stored in the local image metadata database.

[0104] S22. Visualize the data processed in S21 in the front-end visual management interface.

[0105] S23. Based on the cleanup rules contained in the management strategy, the backend data interaction module performs the corresponding image cleanup operation on the images that meet the conditions.

[0106] S24. The cleanup operation includes batch deletion based on risk assessment. The backend data interaction module calls the risk assessment model to calculate a risk score for each image to be operated on, and uses the score to guide the operation strategy.

[0107] The technical solution in this embodiment achieves remote automated management of image repositories through deep integration of a front-end and back-end separation architecture with the Artifactory REST API; it reduces operational complexity through a visual interface and adapts to diverse operation and maintenance scenarios through multi-platform integration capabilities, thereby improving image management efficiency and deployment flexibility.

[0108] Based on the foregoing Figure 2 In practical applications, if the last_pull_timestamp and last_pull_version fields are not supported in step S1, please refer to [the relevant documentation]. Figure 3 As shown, it may include step S0, which is not shown in the figure below:

[0109] S0. If the local image metadata database does not support the last_pull_timestamp and last_pull_version fields, the backend data interaction module will add the last_pull_timestamp and last_pull_version fields to the local image metadata database.

[0110] An incremental pull strategy is used to pull updated image metadata from the image repository, including:

[0111] The backend data interaction module generates timestamp filtering parameters based on last_pull_timestamp and / or version comparison conditions based on last_pull_version, calls the Artifactory REST API and attaches the timestamp filtering parameters or version comparison conditions to pull image metadata that has been updated since the last synchronization.

[0112] It should be noted that if the specific fields `last_pull_timestamp` (last pull timestamp) and `last_pull_version` (last pull version) for recording the incremental synchronization baseline do not exist in the local mirror metadata database, an automatic initialization operation will be performed. These two fields will be created in the corresponding table structure of the local mirror metadata database and assigned initial values. The initial value of `last_pull_timestamp` can be set to the current system time or a sufficiently early fixed time point, and the initial value of `last_pull_version` can be set to an empty string or a specific initial version identifier. The purpose is to establish a clear starting baseline for subsequent incremental synchronization. "Field not supported" refers to a situation where executing an SQL query returns an empty result, or a query to the `information_schema` table confirms the field's absence.

[0113] It should be further explained that during initialization or detection, if the backend data interaction module finds that only one of the two fields, `last_pull_timestamp` and `last_pull_version`, exists in the corresponding table structure of the local mirror metadata database (i.e., partial support), this embodiment will still uniformly determine it as "unsupported". This is because a complete and reliable incremental synchronization baseline requires both a timestamp and a version identifier; a single field cannot ensure the accuracy and consistency of the incremental pull conditions. Therefore, the system will execute the same processing logic as when all fields are missing (step S0): the backend data interaction module will automatically add one or both missing fields to the database table structure and assign reasonable initial values ​​to all newly added fields. This mechanism ensures that the data foundation required for incremental synchronization is always complete, avoiding synchronization logic errors or data inconsistencies caused by incomplete fields, thereby guaranteeing the reliability of the subsequent incremental synchronization mechanism.

[0114] In this embodiment, the specific steps of S0 are as follows:

[0115] S01. Perform database table structure change operation, that is, add these two fields to the corresponding table (such as the op_log table used to record the synchronization status) and set reasonable initial values ​​for them.

[0116] S02. If both fields are supported, perform incremental data synchronization. Specifically, read the value of the last_pull_timestamp field from the local mirror metadata database and use it as a basis to generate a timestamp filtering parameter to be attached when calling the Artifactory REST API (for example, when requesting Artifactory's api / storage interfaces, append modified_since=).<last_pull_timestamp> parameter).

[0117] S03. Read the value of the last_pull_version field and generate version comparison conditions based on it (the specific implementation method can be determined according to the characteristics of the Artifactory API, such as by comparing the inventory summary or tag list of the mirror).

[0118] S04. Call the Artifactory REST API through the backend data interaction module (PHP script), and attach the aforementioned generated timestamp filtering parameters or version comparison conditions to the HTTP request to initiate a query to the mirror repository.

[0119] S05. The query retrieves only the metadata of the image whose attributes have been updated since the last record last_pull_timestamp (or last_pull_version), i.e., "the image metadata that has been updated since the last synchronization".

[0120] S06. To achieve efficient and stable data retrieval, utilize the API's pagination function to obtain data in batches through loop requests.

[0121] S07. Compare the retrieved incremental update data with the existing records in the local database, and only perform insert or update operations on newly added or changed records.

[0122] S08. After the synchronization task is successfully completed, update the time point of this synchronization completion and the latest version identifier processed to the last_pull_timestamp and last_pull_version fields to prepare for the next incremental synchronization.

[0123] It should be noted that if the user chooses not to add the above two fields, the image management tool will downgrade to a full pull strategy, pulling all image metadata from the Artifactory image repository.

[0124] In another alternative approach, before using an incremental pull strategy to pull image metadata updated since the last synchronization from the image repository, the method also includes:

[0125] A1. Receive configuration information triggered by the user through the front-end visual management interface, and respond to the configuration information to configure it. The configuration information includes the filtering conditions for the mirrored data in the page display, the sorting rules based on the filtering conditions, and / or the display method.

[0126] It should be noted that sorting rules refer to user-defined rules that determine the order in which image metadata is displayed, such as descending order by image creation time (newest first), ascending order by storage size, or alphabetical order by image name, etc.

[0127] Filtering criteria refer to user-defined rules used to filter out a specific subset from all image metadata. They can be set by combining any attributes of the image metadata, such as "only display images created within the last 30 days" or "only display images with a storage size greater than 1GB".

[0128] In this embodiment, the specific steps of A1 are as follows:

[0129] A11. Users can interact with the front-end visual management interface and customize the image metadata fields they wish to view. The image metadata fields include the basic attributes of the image metadata.

[0130] The basic attributes of the image metadata include, but are not limited to, image identifier, image name, version number, creation time, storage size, number of pulls, tag list, and other descriptive information synchronized from the Artifactory image repository and stored in the local MySQL database.

[0131] A12. Users can set specific sorting rules, filtering conditions, and / or display methods in the front-end visual management interface.

[0132] A13. The front-end visual management interface saves user-defined field selections, sorting rules, and filtering conditions as configuration information.

[0133] The configuration information can be stored in a local image metadata database or in the front-end local storage. The front-end visual management interface can be a configuration panel developed based on Vue.js.

[0134] A2. When the backend data interaction module pulls the incremental image metadata, it processes it according to the filtering conditions and sorting rules through the frontend visual management interface, and displays it visually according to the display method.

[0135] It should be noted that visualization refers to displaying structured image metadata and its associated risk scores, such as... Figure 4 As shown, graphical user interface (GUI) elements, such as tables, lists, and charts, are presented to users in the front-end visual management interface, enabling them to browse, analyze, and make decisions intuitively.

[0136] In this embodiment, the specific steps of A2 are as follows:

[0137] A21. When the backend data interaction module retrieves incremental image metadata and the user triggers data viewing or interface refresh, the backend data interaction module dynamically generates the corresponding database query statement based on the saved configuration information.

[0138] A22. The backend data interaction module executes a query from the local image metadata database to obtain an image metadata result set that fully conforms to the sorting rules and filtering conditions.

[0139] A23. The backend data interaction module returns the query result set to the frontend visual management interface.

[0140] A24. After receiving the data, the front-end visual management interface sorts it according to the sorting rules set by the user.

[0141] A25. The front-end visual management interface renders and displays data in one or more visual formats according to the display method set by the user.

[0142] The visualization format includes, but is not limited to, sortable and paginated tables.

[0143] The visualization includes the basic attributes of the image metadata and the risk score of the image metadata. The risk score is determined by the backend data interaction module using a pre-built accidental deletion risk assessment model.

[0144] It should be noted that the risk score is a value calculated using a mistaken deletion risk assessment model. It is used to quantify the business risks that may be caused by the deletion of the image. The higher the score, the more important the image is and the greater the risk of mistaken deletion.

[0145] The accidental deletion risk assessment model is a mathematical model that quantifies the importance of an image based on three dimensions: image fetching frequency, tag importance, and creation time, using a weighted summation algorithm. This model is pre-set in the backend PHP code, and the weight coefficients can be dynamically adjusted. Its output is the risk score, which is used to drive the subsequent graded protection mechanism.

[0146] In this embodiment, the image metadata result set not only includes the basic attributes of the image selected by the user, but also includes the risk score of each image.

[0147] The risk score is calculated by the backend data interaction module using a pre-built accidental deletion risk assessment model.

[0148] When rendering and displaying the front-end visual management interface, a dedicated "Risk Score" column is set up in the table to show the risk score of each image.

[0149] The front-end visual management interface uses visual differentiation based on the numerical range of risk scores to improve user experience. This visual differentiation includes, but is not limited to, highlighting rows with high scores or providing quick filter buttons based on score ranges.

[0150] In the third optional method, when the backend data interaction module retrieves incremental image metadata, during the processing through the frontend visual management interface according to filtering conditions and sorting rules, the method also includes: the backend data interaction module obtaining a risk score based on a pre-built accidental deletion risk assessment model; specifically:

[0151] B1. The backend data interaction module obtains the image metadata corresponding to the number of times the image is pulled and the creation time, determines the pull frequency and image age, and performs normalization processing on them respectively to obtain the pull frequency value and image age value.

[0152] It should be noted that the design philosophy of the accidental deletion risk assessment model is to comprehensively quantify the deletion risk of images through a configurable, multi-dimensional weighted assessment framework. In the most generalized model framework, multiple dimensions can be considered, including but not limited to: image pull activity (time factor), downstream project citation status (citation factor), version stage (e.g., development / testing / production) (version factor), storage space usage (space factor), and tag standardization. Its general calculation principle can be expressed as: Risk Score = α × Time Factor + β × Citation Factor + γ × Version Factor + δ × Space Factor + ... Wherein, α, β, γ, δ, etc., represent the configurable weight coefficients corresponding to each dimension. Enterprises can flexibly adjust these coefficients based on their own operational experience and business scenarios, reflecting the model's adaptability and scalability. To achieve a balance between assessment effectiveness and data acquisition feasibility, this invention focuses on three core and easily quantifiable dimensions: pull frequency (comprehensively reflecting activity and time factors), tag importance (directly reflecting version stage and business criticality), and image age, and constructs a specific scoring algorithm accordingly. Specifically, the accidental deletion risk assessment model is a quantitative scoring model built on three dimensions: image usage activity, business value, and time decay. This model calculates the risk score of each image through a weighted summation algorithm, objectively reflecting the criticality of the image in a numerical range of 0-100. The higher the score, the more important the image is, and the greater the potential business impact after accidental deletion.

[0153] The number of pulls refers to the cumulative number of times an image has been pulled from the Artifactory image repository to the local or downstream system. This data is obtained through the stats endpoint of the Artifactory REST API and stored in the pull_count field of the local MySQL database, directly reflecting the frequency of image usage.

[0154] Image creation time refers to the timestamp of the first time the image is pushed to the Artifactory repository. This timestamp is automatically generated by Artifactory and recorded in the created_time field of the image metadata, reflecting the lifecycle stage of the image.

[0155] In one optional approach, based on step B1 above, the backend data interaction module obtains the number of times the image is pulled and the creation time corresponding to the image metadata, calculates the pull frequency and image age, and performs normalization processing on them respectively to obtain the pull frequency value and image age value, including:

[0156] The backend data interaction module divides the number of pulls in the image metadata by a preset time window to obtain the pull frequency, and then normalizes the pull frequency by the maximum frequency among all images to obtain the pull frequency value.

[0157] The image age is determined based on the image creation time in the image metadata, and then normalized by dividing the image age by the maximum age among all images to obtain the image age value.

[0158] In this embodiment, the specific steps of B1 are as follows:

[0159] B11. The backend data interaction module queries the pull_count and created_time field values ​​of the image from the image_metadata table in the local image metadata database.

[0160] B12. The backend data interaction module calculates the pull frequency based on the pull_count value. Specifically, the pull_count value is divided by a preset time window (e.g., 30 days) to obtain the pull frequency.

[0161] It should be noted that the preset time window refers to the standardized time period used to calculate the pull frequency. In the model, it is set to 30 days by default. This value is determined based on the mirror iteration cycle of typical enterprises and statistical significance.

[0162] B13. The backend data interaction module calculates the image age based on the created_time value, specifically the difference between the current time and created_time.

[0163] B14. The backend data interaction module normalizes the pull frequency obtained in step B12 by dividing it by the maximum frequency of all images in the repository to obtain the normalized pull frequency value (Normalized_Pull_Frequency).

[0164] It should be noted that the maximum frequency among all images refers to the maximum pull frequency of all images in the current Artifactory repository. This value is dynamically calculated using the SQL statement `SELECT MAX(pull_count / 30) FROM image_metadata`, or set to a fixed threshold of 100 pulls / day to avoid the influence of outliers. The maximum age among all images refers to the maximum age of images in the current repository. This value is dynamically calculated using the SQL statement `SELECT MAX(DATEDIFF(NOW(),created_time)) FROM image_metadata`, or set to a fixed threshold of 365 days to simplify calculations based on business scenarios.

[0165] B15. The backend data interaction module normalizes the image age obtained in step B13 by dividing the image age by the maximum age of all images in the warehouse and performing a 1-(age / maximum age) operation to obtain the normalized image age value (Normalized_Age).

[0166] B2. Based on the tag list in the image metadata, query the pre-stored tag importance lookup table to determine the tag importance value of the corresponding tag; where, when the image contains multiple tags, take the highest value as the tag importance value;

[0167] It should be noted that the tag list refers to the set of identifiers (or one or more text tags attached to a Docker image) assigned to an image when it is built or pushed, such as "production", "stable", "dev", etc., which are used to identify the purpose, environment or version stage of the image.

[0168] The tag importance mapping table is a predefined mapping table persistently stored in the `tag_weights` table of a local MySQL database. It maps common image tags to a weight value representing their business importance; a higher weight indicates that the image corresponding to that tag is generally more critical. The default settings are: production weight 1.0, stable weight 0.8, testing weight 0.4, dev weight 0.2, and none weight 0.0, which can be adjusted. When an image contains multiple tags, the highest weight value is taken as its tag importance value.

[0169] In this embodiment, the specific steps of B2 are as follows:

[0170] B21. The backend data interaction module queries the tags field value of the image from the image_metadata table in the local image metadata database.

[0171] B22. The backend data interaction module parses the tags field value to obtain the tag list for this image.

[0172] B23. The backend data interaction module queries the pre-stored tag importance comparison table (e.g., the tag_weights table in MySQL) to determine the weight value corresponding to each tag in the tag list.

[0173] B24. When a mirror contains multiple tags, the backend data interaction module takes the highest weight value as the final tag importance value (Tag_Weight).

[0174] B3. Based on preset weighting coefficients, the pull frequency value, tag importance value, and mirror age value are weighted and summed to obtain a risk score.

[0175] It should be noted that the preset weight coefficients refer to the importance ratio values ​​assigned to the three evaluation dimensions of pull frequency, tag importance and mirror age before the weighted summation calculation. Their sum is usually 1. These coefficients can be configured and adjusted according to the operation and maintenance strategies of different enterprises.

[0176] The preset weights in the tag importance lookup table (e.g., production=1.0, stable=0.8, etc.) are predefined absolute values ​​used to directly quantify the business importance of a specific mirror tag itself. They reflect the relative criticality of common tags such as "production," "stable," "testing," and "dev" in business scenarios. The "W1, W2, W3" mentioned later are weighting coefficients in the risk assessment model, used to balance the relative contributions of three different dimensions of assessment indicators—retrieval frequency, tag importance (i.e., the weight value obtained from the query), and mirror age—to the final risk score during comprehensive calculation. That is, tag weights (e.g., 1.0, 0.8) are the raw scores based on business semantics input to the model; while W1, W2, and W3 are parameters within the model used to adjust the weights of each input dimension.

[0177] In this embodiment, the specific steps of B3 are as follows:

[0178] B31. The backend data interaction module substitutes the normalized pull frequency value (Normalized_Pull_Frequency) obtained in step B1, the tag importance value (Tag_Weight) obtained in step B2, and the normalized mirror age value (Normalized_Age) into the core weighted formula of risk assessment for weighted summation to calculate the risk score (Risk_Score).

[0179] The weighted summation formula is:

[0180] Risk_Score=(W1×Normalized_Pull_Frequency)+(W2×Tag_Weight)+(W3×Normalized_Age);

[0181] Wherein, W1, W2, and W3 represent preset weight coefficients corresponding to pull frequency, tag importance, and mirror age, respectively. The default weight coefficients are set as follows: W1=0.3 for pull frequency, W2=0.5 for tag importance, and W3=0.2 for mirror age.

[0182] Through this weighted summation calculation, a comprehensive risk score is finally obtained. It should be further noted that the three-dimensional risk assessment model (pulling frequency, tag importance, and mirror age) in this embodiment is the core foundation of this invention. Based on this, those skilled in the art can expand the model by adding factor dimensions according to the generalized assessment framework described above (including time factors, citation factors, version factors, spatial factors, etc.). Such equivalent modifications still fall within the scope of this invention's technical concept.

[0183] In the fourth alternative approach, the method further includes the following steps before performing the corresponding image cleanup operation:

[0184] C1. The backend data interaction module determines the image deletion strategy based on the risk score and performs corresponding image cleanup operations according to the deletion strategy. The deletion strategy includes at least one of the following: direct deletion, requiring user confirmation, requiring secondary confirmation from the administrator, and pausing deletion and notifying the administrator.

[0185] It should be noted that determining the image deletion strategy based on risk scores means mapping a quantified risk score (Risk_Score) calculated through a erroneous deletion risk assessment model to several predefined discrete operation levels, with each level corresponding to a specific deletion strategy. The deletion strategy defines the degree of automation, the required level of interactive confirmation, and the notification mechanism when performing cleanup operations on the target image.

[0186] In this embodiment, the following four strategies are mainly included: "Direct Deletion" strategy, which means that the deletion operation is performed automatically without any additional manual confirmation; "User Confirmation Required" strategy, which means that a confirmation request must be sent to the current operator (user) before deletion can be performed, and the deletion can only be performed after permission is obtained; "Administrator Secondary Confirmation Required" strategy, which means that before deletion can be performed, not only the current user's confirmation is required, but also confirmation from an administrator with higher privileges is required; "Pause Deletion and Notify Administrator" strategy, which means that the automatic execution process is paused, the deletion is not performed immediately, but a notification (such as an email) is sent to a designated administrator, and the administrator is waited for intervention, review and final approval before deciding whether to perform the deletion.

[0187] In this embodiment, as Figure 5 As shown, the specific steps for C1 are as follows:

[0188] C11. The backend data interaction module compares the calculated risk score (Risk_Score) of the target image with a set of preset risk level threshold ranges.

[0189] The preset risk level threshold range is set as follows: 0 to 50 points corresponds to "low risk", 51 to 80 points corresponds to "medium risk", 81 to 90 points corresponds to "high risk", and 91 to 100 points corresponds to "extremely high risk".

[0190] C12. The backend data interaction module automatically determines the deletion strategy corresponding to the image based on the threshold range into which the score falls.

[0191] The specific mapping relationship between ratings and policies is as follows: "low risk" corresponds to the "direct deletion" policy, "medium risk" corresponds to the "user confirmation required" policy, "high risk" corresponds to the "administrator secondary confirmation required" policy, and "extremely high risk" corresponds to the "suspend deletion and notify the administrator" policy.

[0192] C13. The backend data interaction module drives the subsequent cleanup operation process based on the predefined logic of the determined deletion strategy.

[0193] Specifically, for the "direct deletion" strategy, the backend data interaction module will automatically and without interruption call the Artifactory REST API to perform the deletion operation.

[0194] For the other three strategies involving confirmation, the backend data interaction module will trigger the corresponding interaction process.

[0195] In the fifth optional method, the backend data interaction module performs corresponding image cleanup operations according to the deletion policy, including:

[0196] When the deletion policy requires user confirmation or secondary administrator confirmation, a confirmation request is sent to the front-end visual management interface, and the Artifactory REST API is called to execute the deletion after receiving the confirmation instruction;

[0197] When the deletion policy is to pause deletion and notify the administrator, the current operation is paused, a notification is sent to the designated administrator, and the decision on whether to execute the deletion is made after receiving the administrator's approval instruction.

[0198] It should be noted that sending a confirmation request to the front-end visual management interface means that the back-end generates a structured request message containing details of the image to be deleted (such as name, version, risk score, etc.) and pushes it to the front-end visual management interface through communication channels such as HTTP response or WebSocket.

[0199] Receiving a confirmation instruction means that after the front-end visual management interface displays the confirmation dialog box, it captures the user's action event of clicking the "Confirm" button and sends the event information back to the back-end.

[0200] Sending a notification to a designated administrator typically refers to sending an alert message containing operation details and an approval link to a pre-defined administrator contact via email, instant messaging, or an internal ticketing system.

[0201] Receiving an administrator approval instruction refers to the "approval" or "rejection" decision signal received by the administrator after accessing the system approval interface through a link in the notification or replying to an email in a specific format.

[0202] In this embodiment, for the other three confirmation-related strategies in step C13 mentioned above, the backend data interaction module will trigger the corresponding interaction process, specifically including:

[0203] For policies requiring "user confirmation" or "administrator secondary confirmation," when the risk score triggers either of these policies, the backend data interaction module (PHP script) immediately constructs a confirmation request. This request includes key information such as the mirror identifier, risk score, and suggested actions, and sends it to the frontend visual management interface. Upon receiving the request, the frontend interface displays it to the current user in the form of a modal pop-up (dialog) or a prominent prompt bar, requesting the user's confirmation whether to continue deleting.

[0204] For the "user confirmation required" strategy, after obtaining confirmation from the current user, the frontend sends the confirmation command back to the backend, which then calls the Artifactory REST API to execute the deletion. For the "administrator secondary confirmation required" strategy, after obtaining the first round of confirmation from the current user, a secondary confirmation request to a higher-level administrator will be generated (the process is similar to the initial confirmation), or the designated administrator will be notified simultaneously, requiring them to approve the request through the management interface. The backend will only ultimately call the delete API after obtaining confirmation commands from both the user and the administrator (or only the administrator, depending on the configuration).

[0205] For the "Pause Deletion and Notify Administrator" policy, all subsequent automated operations for that image in the current cleanup task will be immediately suspended. Simultaneously, a notification will be sent to one or more administrators based on pre-configured contact information. This notification typically includes the complete image context, the basis for the risk score calculation, and a dedicated link to the system for approval. The process then enters a waiting state until an explicit "Approval to Execute" instruction is received from the administrator via the approval interface. If approval is received, deletion continues; if rejection is received or no response is received within a timeout period, the deletion operation for that image is canceled, and the reason can be recorded. During execution, regardless of whether deletion is ultimately performed, the policy judgment result, operation type, and operator information are recorded in the `operation_log` table to achieve complete audit trail.

[0206] In the sixth alternative approach, after performing the image cleanup operation, the method also includes:

[0207] D1. The backend data interaction module stores the operation logs that record the corresponding operation process in the local mirror metadata database. The operation logs are used to support the historical operation query, audit tracking and data update of the accidental deletion risk assessment model in the front-end visual management interface.

[0208] The operation log includes: operation identifier, image identifier, image version, risk score, operator, operation time, and operation result.

[0209] It should be noted that the operation log refers to a structured record of the complete context of each image cleanup operation (including attempts and final executions). It is not stored in temporary files or memory, but is persistently stored in a dedicated table in the local image metadata database (such as a MySQL database), for example, the `operation_log` table.

[0210] Historical operation query refers to the ability of authorized users (such as administrators) to retrieve and view all past operation records through a front-end visual management interface, based on conditions such as time range, operator, and image name.

[0211] Audit trails refer to the use of immutable log records containing complete operational chain information to meet the needs of enterprises for tracing operational behaviors and determining responsibility during internal compliance reviews, security audits, or incident debriefings.

[0212] Data updates for the accidental deletion risk assessment model refer to the model's ability to utilize data such as the frequency of mirror pulls recorded in historical logs (implied in the operation records) and the correspondence between deletion operations and risk scores as training samples or feedback data for continuously optimizing model parameters (such as weight coefficients and thresholds) or verifying the effectiveness of the model.

[0213] In this embodiment, the specific steps of D1 are as follows:

[0214] D11. After each image cleanup operation (regardless of whether the deletion is ultimately successful), once the backend data interaction module completes the interaction and API call with the frontend according to the deletion strategy, the logging process will be triggered immediately, regardless of whether the operation is successful, failed, or canceled by the user / administrator.

[0215] D12. Collect all key information involved in this operation and build a structured log record;

[0216] This record can be stored in the operation_log table and must contain at least the following fields:

[0217] Operation identifier: A generated unique ID used to identify this operation instance;

[0218] Image identifier refers to the unique identifier of the image being operated on in the local database (such as image_id); image version refers to the specific version number or tag of the image being operated on.

[0219] Risk score refers to the score (Risk_Score) of the image calculated by the accidental deletion risk assessment model before this operation decision.

[0220] Operator refers to the user account identifier that initiates or confirms the operation; operation time refers to the point in time when the operation is finally submitted or executed.

[0221] Operation results are used to record the final status of this cleanup operation, such as "deletion successful", "deletion failed (reason: API not responding)", "user canceled", "administrator rejected", etc.

[0222] D13. Use database operations (such as SQL INSERT statements) to persist the complete log record into the specified log table of the local mirror metadata database.

[0223] This process ensures that every attempt to change the mirror repository is documented.

[0224] It should be noted that after the image cleanup operation is completed, the backend data interaction module records the operation results (including the list of successfully deleted images, the total amount of storage space released, and the operation time) in the operation log table, and synchronously updates the status markers of the remaining images in the local image metadata database. After receiving the operation completion signal from the backend, the frontend visual management interface automatically triggers the data refresh process, re-queries the metadata snapshot of the current image repository from the local image metadata database, and displays the cleaned repository status with differentiated visual elements (such as color to distinguish deleted items and animation to show the space release effect), including the list of remaining images, the latest storage usage statistics, and the risk score distribution, thereby providing users with real-time operation feedback and a repository health overview.

[0225] The cleaned-up repository status display refers to the visual management interface on the front end, which intuitively presents the current actual status of the image repository after the cleanup operation by re-querying the local image metadata database and rendering the updated data set. The displayed content includes at least the basic attributes of the remaining images, the risk score, and the amount of storage space released in this operation, so that users can confirm the operation effect and evaluate the results of the repository optimization.

[0226] The steps for implementing the corresponding functions of each parameter and step in the image management method based on the image management tool in this embodiment can be referred to the parameters and modules in the above embodiment of the image management tool for dynamically managing image repositories, and will not be repeated here.

[0227] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, the invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0228] Any combination of one or more computer-readable media can be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0229] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. An image management tool for dynamically managing image repositories, characterized in that: A front-end visual management interface is used to receive user instructions and / or display the operation process or operation results; The backend data interaction module is used to interact with the image repository using the Artifactory REST API to obtain image metadata, and / or to operate on the image metadata of the image repository; The front-end visual management interface and the back-end data interaction module communicate using HTTP requests; The image management tool can be integrated into the CI / CD pipeline of an enterprise-level DevOps platform, or into a container orchestration platform, or used as a standalone tool for managing Artifactory image repositories in enterprise private clouds or data center infrastructure.

2. The image management tool according to claim 1, characterized in that: The front-end visual management interface is implemented using HTML, JavaScript, and CSS, and a responsive configuration panel is developed based on the Vue.js framework; The backend data interaction module is implemented using PHP scripts and is used to call the Artifactory REST API and interact with the local image metadata database. The local image metadata database uses a MySQL database to store image metadata, operation logs, and risk score information.

3. An image management method based on the image management tool of claim 1, characterized in that, include: The backend data interaction module determines whether the local image metadata database supports the last_pull_timestamp and last_pull_version fields. If it does, it uses an incremental pull strategy to pull image metadata updated since the last synchronization from the image repository. The image metadata is displayed through a front-end visual management interface based on a pre-defined management strategy, and the back-end data interaction module executes the corresponding image cleanup operations according to the cleanup rules in the management strategy.

4. The mirror management method according to claim 3, characterized in that: If the local image metadata database does not support the last_pull_timestamp and last_pull_version fields, the backend data interaction module adds the last_pull_timestamp and last_pull_version fields to the local image metadata database. The incremental pull strategy for retrieving updated image metadata from the image repository includes: The backend data interaction module generates timestamp filtering parameters based on the last_pull_timestamp and / or generates version comparison conditions based on the last_pull_version, calls the Artifactory REST API and attaches the timestamp filtering parameters or the version comparison conditions to pull image metadata that has been updated since the last synchronization.

5. The mirror management method according to claim 3, characterized in that, Before using an incremental pull strategy to pull image metadata updated since the last synchronization from the image repository, the method further includes: The system receives configuration information triggered by the user through a front-end visual management interface and responds to the configuration information to perform configuration. The configuration information includes the filtering conditions for the mirrored data displayed on the page, the sorting rules based on the filtering conditions, and / or the display method. When the backend data interaction module retrieves incremental image metadata, it processes it according to the filtering conditions and sorting rules through the frontend visual management interface, and then displays it visually according to the display method. The visualized content includes the basic attributes of the image metadata and the risk score of the image metadata. The risk score is determined by the backend data interaction module using a pre-built accidental deletion risk assessment model.

6. The mirror management method according to claim 5, characterized in that, When the backend data interaction module retrieves incremental image metadata, during the processing through the frontend visual management interface according to the filtering conditions and sorting rules, the method further includes: the backend data interaction module obtaining a risk score based on a pre-built accidental deletion risk assessment model; specifically: The backend data interaction module obtains the number of times the image is pulled and the creation time of the image corresponding to the image metadata, determines the pull frequency and image age, and performs normalization processing on them respectively to obtain the pull frequency value and image age value. Based on the tag list in the image metadata, a pre-stored tag importance lookup table is queried to determine the tag importance value of the corresponding tag; wherein, when the image contains multiple tags, the highest value is taken as the tag importance value; Based on preset weighting coefficients, the pull frequency value, the tag importance value, and the mirror age value are weighted and summed to obtain the risk score.

7. The mirror management method according to claim 6, characterized in that, The backend data interaction module obtains the number of times the image is pulled and the creation time corresponding to the image metadata, calculates the pull frequency and image age, and performs normalization processing on them respectively to obtain the pull frequency value and image age value, including: The backend data interaction module divides the number of times the image metadata is pulled by a preset time window to obtain the pull frequency, and then normalizes the pull frequency by the maximum frequency among all images to obtain the pull frequency value. The image age is determined based on the image creation time in the image metadata, and then normalized by dividing the image age by the maximum age among all images to obtain the image age value.

8. The mirror management method according to claim 6, characterized in that, Before performing the corresponding image cleanup operation, the method further includes: The backend data interaction module determines the image deletion strategy based on the risk score and performs corresponding image cleanup operations according to the deletion strategy; the deletion strategy includes at least one of direct deletion, requiring user confirmation, requiring secondary administrator confirmation, and pausing deletion and notifying the administrator.

9. The mirror management method according to claim 8, characterized in that, The backend data interaction module performs corresponding image cleanup operations according to the deletion strategy, including: When the deletion policy requires user confirmation or secondary administrator confirmation, a confirmation request is sent to the front-end visual management interface, and the Artifactory REST API is called to execute the deletion after receiving the confirmation instruction; When the deletion policy is to pause deletion and notify the administrator, the current operation is paused, a notification is sent to the designated administrator, and the decision on whether to execute the deletion is made after receiving the administrator's approval instruction.

10. The mirror management method according to claim 8, characterized in that, After performing the image cleanup operation, the method further includes: The backend data interaction module stores operation logs containing corresponding operation processes in the local mirror metadata database; these operation logs are used to support historical operation queries, audit trails, and data updates for the accidental deletion risk assessment model in the frontend visual management interface. The operation log includes: operation identifier, image identifier, image version, risk score, operator, operation time, and operation result.

Images