Automated container image replication management

Abstract

In some aspects, a computing system can include a replication module that can automate a replication of a container image from a source registry to a target registry. The replication module can access an event associated with the container image stored in the source registry. The replication module can extract event data associated with the event. The replication module can be configured to replicate the container image to a destination repository in the target registry. The replication module can determine whether the destination repository exists in the target registry and can generate the destination repository in the target registry if the destination repository does not exist. Based on the destination repository existing in the target registry, the replication module can generate a copy of the container image in the destination repository. The copy of the container image can include an image digest identifying the container image in the source registry.

Description

Attorney Docket No 096923-1460694AUTOMATED CONTAINER IMAGE REPLICATION MANAGEMENTTechnical Field

[0001] The present disclosure relates generally to distributed computing environments. More specifically, but not by way of limitation, this disclosure relates to automated container image replication across different registries.Background

[0002] Software services, such as applications or microservices, can be deployed inside containers within a computing environment. A container is a relatively isolated virtual environment created by leveraging resource isolation features (e.g., cgroups or namespaces) of a kernel. Containers are deployed from image files using a container engine. These image files are often referred to as container images.Summary

[0003] Various aspects of the present disclosure provide systems and methods for automated container image replication across different registries. In one example, a computer-implemented method is performed by one or more processing devices. The computer-implemented process includes accessing, by a replication module, an event associated with a container image of one or more container images stored in a source registry. Additionally, the computer-implemented process includes extracting, by the replication module, event data associated with the event. Further, the computer-implemented process includes determining, by the replication module and based on the event data, whether a destination repository exists in a target registry to which the container image is to be replicated. The computer-implemented process additionally includes, in response to determining that the destination repository exists in the target registry, replicating, by the replication module, the container image by generating a copy of the container image in the destination repository. The copy of the container image can include an image digest identifying the container image stored in the source registry.

[0004] In another example, a system includes a processor and a memory device in which instructions executable by the processor are stored for causing the processor to perform various operations. The processor can access an event associated with a container image of one or more container images stored in a source registry. Additionally, the processor can extract event data associated with the event. Further, the processor can determine, based on131014210V.1Attorney Docket No 096923-1460694the event data, whether a destination repository' exists in a target registry to which the container image is to be replicated. The processor additionally can, in response to determining that the destination repository exists in the target registry, replicate the container image by generating a copy of the container image in the destination repository. The copy of the container image can include an image digest identifying the container image stored in the source registry.

[0005] In yet another example, a non-transitory computer-readable storage medium has program code that is executable by a processor to cause a computing device to perform various operations. The operations can include accessing, by a replication module, an event associated with a container image of one or more container images stored in a source registry'. Additionally, the operations can include extracting, by the replication module, event data associated with the event. Further, the operations can include determining, by the replication module and based on the event data, whether a destination repository exists in a target registry to which the container image is to be replicated. The operations additionally can include, in response to determining that the destination repository’ exists in the target registry, replicating, by the replication module, the container image by generating a copy of the container image in the destination repository. The copy of the container image can include an image digest identifying the container image stored in the source registry'.

[0006] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification, any or all draw ings, and each claim.

[0007] The foregoing, together with other features and examples, will become more apparent upon referring to the following specification, claims, and accompanying drawings.Brief Description of the Drawings

[0008] FIG. 1 is a block diagram depicting an example of an operating environment in which a container replication computing system can manage a respective replication of one or more container images stored in a source registry according to certain aspects of the present disclosure.

[0009] FIG. 2 is a flow chart depicting an example of a process for replicating one or more container images in a source registry to a target registry according to certain aspects of the present disclosure.231014210V.1Attorney Docket No 096923-1460694

[0010] FIG. 3 is a block diagram of an example of a computing environment to implement a failover process between a primary instance and a secondary instance of a replication module according to certain aspects of the present disclosure.

[0011] FIG. 4 is a block diagram depicting an example of a computing system suitable for implementing aspects of the techniques and technologies presented herein.Detailed Description

[0012] Certain aspects and examples of the present disclosure relate to managing container image replication in different registries. A container image can be a file executable to generate a container that can provide a relatively isolated virtual environment in a computing system. In particular, the container image can include instructions to build one or more container layers that form the container. A container registry can store one or more container images, which can facilitate container deployment or management. For instance, a user can upload the container images to the container registry and include a respective image tag to organize the container images. Each container registry can include one or more repositories that can include a respective collection of related container images. For instance, a repository' can store a set of container images that each correspond to a different version of the same application or service that can be deployed in a container. Different hosting environments can be used to provide container registries to store the container images. Additionally, duplicate versions of container images can be stored in different container registries in different locations. Accordingly, in some cases, a user may use multiple container registries to store container images such that certain container registries can include copies of the same container images. Container image replication can enable deployment of containers to different computing environments. Additionally, replicating the container images can provide redundancy to protect against data loss or network outages, such as when container registries in a certain location are offline or otherwise unavailable.

[0013] Disclosed examples provide systems and methods for automatically replicating container images across different container registries. In some examples, users can choose to use multiple container registries to store and manage their container images. The container registries selected by the users can be hosted by different hosting environments. The different hosting environments can each provide container registries with different features, such as with respect to security, support for other types of files in addition to container images, etc. But implementing multiple container registries and using different hosting331014210V.1Attorney Docket No 096923-1460694environments can contribute to data fragmentation where data is stored across multiple systems or locations. Managing and replicating container images across fragmented infrastructure environments can be difficult. In particular, different types of container registries can be implemented in combination. Examples of the container registries can include multi-cloud registries, hybrid cloud registries, or on-premises registries. The different types of container registries can provide different levels of security, scalability, or other suitable features. Additionally, certain container registries can be hosted by different hosting environments. For example, some users may privately host certain container registries while using other cloud registries hosted by external cloud providers. As a result, maintaining consistent, secure, and updated container image across different container registries can be complex and resource-intensive. Certain aspects described herein for automated container image replication can address one or more issues identified herein.

[0014] In one example, a user may use container registries hosted by disparate hosting environments, such as different cloud providers. Scalability of cloud computing can enable a large quantity of container images to be stored and managed using container registries managed by cloud providers, which can complicate container replication. Multi-registry management and replication of the container images can be difficult at least in part due to differences in infrastructure among container registries hosted by different hosting environments. In particular, the different hosting environments can lack standardization with respect to formatting or configuring the container registries, which can make it difficult to manage container images across different hosting environments and can necessitate manual in ten ention. For example, a developer may need to manually enter one or more lines of code to link container registries together for replication and to create registries or repositories to store replicated container images. Additionally, it can be difficult to ensure that the container images replicated across different container registries are consistent and secure, such as having the same content and access controls implemented across the different container registries. Disclosed examples herein describe a replication module that can automate the replication of container image across different container registries.

[0015] To overcome the above-described problems, aspects of the present disclosure relate to automatically replicating container images across different container registries. The different container registries can be hosted by different computing systems, such as cloud systems, software-as-a-service (SaaS) systems, on-premises systems, or a combination thereof. Aspects of the present disclosure can be used to implement an event-driven system that can replicate a container image between a source registry and a target registry regardless 431014210V.1Attorney Docket No 096923-1460694of a respective hosting environment of the container registries. Additionally, aspects of the present disclosure can reduce manual intervention involved in container image replication. As an example, the replication module can automatically generate a suitable repositor}' to store a replicated container image, thereby minimizing manual intervention to configure the suitable repository. Reducing manual intervention can also reduce a likelihood of errors and streamline the replication of the container images.

[0016] In some examples, a container replication system can implement event-driven replication in which the container replication system performs a replication process to replicate a container image from a source registry to a target registry. In particular, the container replication system can perform the replication process based on an event occurring in the source registry. The container replication system can include an event subscription module that can subscribe to events associated with container images stored in the source registry. As an example, the event can correspond to a new container image being uploaded to the source registry. As another example, the event can correspond to an existing container image stored in the source registry being updated or modified. The event subscription module can communicate with other components of the container replication system to initiate the replication process based on the event. The replication process being event-driven can enable real-time updates to the target registry' and ensure that a latest or most current version of the container images in the source registry is available in the target registry without manual intervention.

[0017] In some examples, the container replication system can include a replication module that can perform the replication process. In some implementations, the event subscription module can communicate with the replication module regarding the event of the source registry. Once the event is received or otherwise accessed, the replication module can obtain event data related to the event. Using the event data, the replication module can determine whether to create a suitable repository in the target registry. In particular, the replication module can verify whether the suitable repository' already exists in the target registry. If the suitable repository’ is absent from the target registry, the replication module can create the suitable repository, such as based on the event data, and then proceed with the replication process. Conversely, if the suitable repository is present in the target registry, the replication module can directly proceed with replicating the container image to the target registry.

[0018] In some examples, the container replication system can include multiple instances of the replication module, such as to provide redundancy if one instance of the replication 531014210V.1Attorney Docket No 096923-1460694module fails or is otherwise unavailable. For example, the container replication system can host or run a primary instance of the replication module using a virtual machine. One or more additional virtual machines can host a respective secondary instance of the replication module. In some examples, each secondary instance can be hosted in a different availability zone. Accordingly, a disruption affecting the availability of the primary instance is unlikely to affect all of the secondary instances. In some implementations, if the primary instance of the replication module becomes unavailable, a secondary instance of the replication module can take over the replication process.

[0019] In some examples, the container replication system can include a health monitoring module that can monitor the availability of the primary instance to ensure that the replication process is implemented. Availability of the primary instance can be monitored using a periodic or continuous stream of messages. The health monitoring module can receive the messages from the virtual machine hosting the primary instance of the replication module. The messages can indicate that the primary instance is active or otherwise available. If the health monitoring module detects a discrepancy in the messages, the container replication system can implement a failover mechanism to switch from the primary instance to a secondary instance such that replication of the container images in the source registry can continue. As an example, if the health monitoring module identifies an unexpected disruption or delay in the stream of messages, the health monitoring module can determine that the primary instance is unavailable and initiate the failover mechanism. In some examples, once the primary instance is available again, the virtual machine can resume transmission of the messages to the health monitoring module. The container replication system then can enable the primary instance to resume responsibility of performing the replication process.

[0020] In some examples, the container replication system can include a synchronization module that can perform a synchronization process. In particular, the synchronization module can perform the synchronization process to prepare the target registry for ongoing replication. For example, the replication module can perform the replication process in response to events of the source registry. The source registry can include a number of existing container images stored in the source registry that are not replicated to the target registry' due to a lack of events associated with these existing container images. Until an event corresponding to the existing container images occurs, the replication module may not replicate the existing container images to the target registry. Accordingly, the synchronization module can perform the synchronization process to ensure that the existing 631014210V.1Attorney Docket No 096923-1460694container images of the source registry are copied to the target registry. In other words, the synchronization module can prepare the target registry by ensuring that the target registry includes the same container images as the source registry, which can facilitate future or subsequent replications.

[0021] In some examples, the container replication system can log replication activities in a logging database, such as to provide an audit trail for auditing purposes. For example, the logging database can store one or more data entries related to the replication activities. The data entries can store information that can be used to verify whether the replication of a particular container image in the source registry' is successful. For example, a particular data entry can include a name of a container image in the source registry that was replicated, a repository of the target registry in which a copy of the container image was created, a replication date or time when the copy was created, etc. In some examples, the container replication system can include a logging module that can be integrated with the logging bases to maintain the data entries stored in the logging database.

[0022] In some examples, the container replication system can include a security framework to implement access control. For example, the security framework can use identify and access management (IAM) roles to assign specific permissions to allow trusted entities to perform actions related to accessing cloud sendees. As another examples, the security framework can employ workload identity federation to grant permissions to access certain components of the container replication system, such as the source registry or the logging database. In some implementations, such as for auditing purposes, the security framework can use access control to prevent unauthorized modifications to the logging database.

[0023] Certain aspects described herein provide improvements to container image replication. For instance, the systems and methods described herein can enable changes to one container registry to be replicated to one or more other container registries. Entities often use multiple cloud providers for various services, such as to host container registries. Managing container images across different cloud computing environments hosted by the cloud providers can be challenging, such as with respect to ensuring that the container images are consistent and secure. The different cloud computing environments can have different infrastructures, resulting in variable configurations across different container registries. Accordingly, ty pical container image replication can involve manual intervention to manually configure a target registry to ensure that the target registry is suitably configured to store a replicated container image. Disclosed systems and methods can implement automated 731014210V.1Attorney Docket No 096923-1460694replication of container images from a source registry to the target registry where each container registry is associated with a different hosting environment. The systems and methods described herein can minimize manual intervention, such as by implementing a replication module that can automatically generate a suitable repository in the target registry to store a replicated container image. In particular, the replication module can automatically configure the suitable repository such that little to no manual setup is implemented. This can reduce a likelihood of error while reducing operational overhead.

[0024] These illustrative examples are given to introduce the reader to the general subject matter discussed here and are not intended to limit the scope of the disclosed concepts. The following sections describe various additional features and examples with reference to the drawings in which like numerals indicate like elements, and directional descriptions are used to describe the illustrative examples but, like the illustrative examples, should not be used to limit the present disclosure.

[0025] Referring now to the drawings, FIG. 1 is a block diagram depicting an example of an operating environment 100 in which a container replication computing system 102 can manage a respective replication of one or more container images 104A stored in a source registry 106. FIG. 1 depicts examples of hardware components of the container replication computing system 102, according to some aspects of the present disclosure. The container replication computing system 102 can be a specialized computing system that may be used to replicate the container images 104A across various container registries. For example, the container replication computing system 102 can replicate a container image 104A stored in the source registry' 106 such that a copy of the container image 104A is stored in a target registry 108. The copy of the container image 104A is referred to herein as a replicated container image 104B. The container replication computing system 102 can include executable instructions stored in one or more non-transitory computer-readable storage media. The container replication computing system 102 can also include one or more processing devices that are capable of executing program code to perform operations described herein.

[0026] In some implementations, the source registry 106 and the target registry 108 can be separate container registries that can be used to store, access, or distribute the container images 104. Each container registry' can include one or more repositories. As shown, the source registry 106 can include a source repository' 110, and the target registry 108 can include a destination repository 112. A repository can include a subset of related container images in a particular container registry. For example, a repository can include a set of 831014210V.1Attorney Docket No 096923-1460694related container images corresponding to different versions of the same application or service. As another example, a repository can include a set of related container images sharing the same name while being assigned different image tags. Each container image can be a static, executable file that can include one or more files, libraries, dependencies, metadata, or a combination thereof. The container images 104 can be executed to run or generate a respective container in a computing environment.

[0027] Although a single target registry 108 is shown in FIG. 1, it will be appreciated that the container replication computing system 102 can copy the container images 104A of the source registry 106 to more than one target registry. For example, each target registry can correspond to a different host entity (e.g., different organizations or companies). Different types of container registries are possible. For example, the container registries can be public container registries, private container registries, or a combination thereof. In contrast to public container registries, private container registries can provide security7or privacy, such as by implementing access control management, authentication systems, or auditability7tools. Additionally, the container registries can be hosted using different hosting environments. For example, the container registries can be hosted remotely (e.g., cloud registries or software-as-a-service (SaaS) registries), hosted locally (e g., on-premises registries), or a combination thereof.

[0028] As shown, the container replication computing system 102 can include an event subscription module 114. The event subscription module 114 can monitor one or more events 1 1 associated with the source registry7106. The events 116 can correspond to occurrences of one or more actions related to the container replication computing system 102 that can cause a respective responsive action to be automatically implemented by the container replication computing system 102 when a particular event occurs. Examples of the events 116 can include a creation of a new container image in the source registry7106, a creation of a new image tag in the source registry 106, etc. For example, a user associated with the source registry 106 can upload a new container image to store in the source registry 106. The new container image being uploaded to the source registry 106 can cause the container replication computing system 102 to automatically replicate the new container image to one or more target registries, such as the target registry 108 shown in FIG. 1. In some implementations, an image tag can be a human-readable identifier (e.g., a sequence of alphanumeric characters) that can be included as part of a container image 104. For example, the image tag can be part of a name of the container image 104. Additionally or alternatively, the image tag can specify a version of the container image 104. The container images 104A-B in the container 931014210V.1Attorney Docket No 096923-1460694registries can be grouped based on a respective image tag. For example, a subset of the container images 104A-B having the same image tag can be deployed together. The image tag can be a mutable reference such that a particular container image referenced by the image tag can change.

[0029] In some examples, the event subscription module 114 can monitor the source registry 106 by subscribing to the events 116 generated by the source registry 106. For example, the event subscription module 115 can be a subscriber in a publish-subscribe messaging service, while the source registry 106 can function as a publisher. The publish-subscribe messaging sendee can include a particular communication channel associated with the source registry 106 that the event subscription module 114 can subscribe to and obtain information related to the events 116 of the source registry 106. In some implementations, the particular communication channel may provide information related to events pertaining to a creation or modification of the container images 104A in the source registry' 106. Other techniques can be implemented by the event subscription module 114 to monitor the source registry 106.

[0030] In some examples, the event subscription module 114 can communicate with a replication module 118 of the container replication computing system 102 to initiate a replication process associated with a specific container image stored in the source registry' 106. For example, the event subscription module 114 can function as a publisher that can provide information related to the events 116 to the replication module 118. The event subscription module 114 may selectively communicate with the replication module 118 regarding certain events related to creating or updating the container images 104A of the source registry 106. In other examples, the replication module 118 can directly subscribe to the events 116 of the source registry 106. The replication module 118 can subscribe to receive or otherwise access a subset of the events 116 pertaining to creating or updating the container images 104A of the source registry 106.

[0031] Once a particular event is published, the replication module 118 can obtain event data 120 associated with the particular event. For example, the replication module 118 may receive the particular event from the event subscription module 114 or from the source registry' 106. After receiving the particular event, the replication module 118 can parse the particular event to extract the event data 120 (e.g., metadata) related to the specific container image associated with the particular event. As an example, the event data 120 can include a name or another suitable identifier of the specific container image, a location (e.g., a specific1031014210V.1Attorney Docket No 096923-1460694repository in the source registry 106) of the specific container image, a file size of the specific container image, or a combination thereof.

[0032] Based on the event data 120, the replication module 118 can verify whether the target registry 108 includes the destination repository 112 to store the replicated container image 104B. The destination repository 112 can be a repository' in the target registry 108 that can store one or more other container images that are related to the container image 104A in the source registry- 106. In some implementations, the destination repository 112 can be configured to share certain features of the source repository 110 corresponding to the container image 104 A. In some examples, the replication module 118 may determine whether the target registry 108 has an existing repository. For example, if the target registry 108 is newly created, the target registry 108 may lack any existing repositories including the destination repository 112. In other examples, the replication module 118 can determine yvhether the destination repository- 112 exists in the target registry 108 based on a name of the container image 104 A. For example, the name of the container image 104 A can be defined by a particular repository in the source registry 106 yvith which the container image 104A is associated. Based on the name of the container image 104A, the replication module 118 can determine whether an existing repository in the target registry 108 can function as the destination repository 112. For example, the replication module 118 can use the name of the container image 104A to determine whether a related container image associated with the container image 104A has already been copied to the target registry 108. If the related container image has been copied to a particular repository of the target registry 108, the replication module 118 can designate the particular repository as the destination repository 112 and create a copy of the container image 104A in the particular repository.

[0033] If the replication module 118 determines that the target registry 108 includes the destination repository 112, the replication module 118 can replicate the container image 104 A to the target registry’ 108. In particular, the replication module 118 can store a copy of the specific container image (e.g., the replicated container image 104B) in the destination repository 112 of the target registry 108. Conversely, if the replication module 118 determines that the target registry 108 lacks the destination repository 112, the replication module 118 can automatically generate the destination repository 112 in the target registry 108. Accordingly, the replication module 118 can eliminate or minimize manual configuration of repositories in the target registry 108, which can simplify- the replication of the container image 104 A and reduce a likelihood of errors. Once the destination repository1131014210V.1Attorney Docket No 096923-1460694112 is available in the target registry 108, the replication module 118 can store the replicated container image 104B in the destination repository 112.

[0034] In some examples, each replicated container image 104B can include a respective image digest 122. The image digest 122 can be an immutable identifier of a corresponding container image. Each replicated container image 104B and a corresponding container image 104A in the source registry 106 can have matching image digests. In some implementations, the image digest 122 can be a document that can include a reference to one or more components of the container image 104A copied to the target registry 108. For example, the image digest 122 can indicate a configuration object (e.g., a JavaScript Object Notation (JSON) file) of the container image 104 A. The configuration object can define one or more properties of the container image 104A, such as with respect to an operating system (e.g., version, features, etc.), exposed ports, volumes, or other suitable configuration properties. As another example, the image digest 122 can reference one or more container layers of the container image 104 A. Each container layer can correspond to a respective file system modification, such as an addition or a deletion. In certain aspects, the image digest 122 can indicate an order in which to stack the container layers of the container image 104 A.

[0035] In some examples, the replication module 118 may receive or otherwise access certain events involving a modification to the container image 104A. For example, an updated version of the container image 104A can be uploaded to the source registry 106. As another example, the container image 104 A may be removed or deleted from the source registry 106. Once the container image 104A is updated, the container replication computing system 102 can update each copy of the container image 104 A, such as the replicated container image 104B in the target registry' 108. The replication module 118 can use the image digest of the container image 104A to locate the replicated container image 104B. As described herein, the replicated container image 104B can have the same image digest as the container image 104 A. Accordingly, the replication module 118 can identify a subset of replicated container images overseen by the container replication computing system 102 that share the image digest of the container image 104 A. Once the replication module 118 locates the replicated container image 104B, the replication module 118 can apply the modification to the replicated container image 104B to match the container image 104 A in the source registry' 106. For example, if the modification involves the updated version of the container image 104A, the replication module 118 can update the replicated container image 104B to match the updated version of the container image 104 A in the source registry 106. As another example, if the modification involves removing the container image 104A from the 1231014210V.1Attorney Docket No 096923-1460694source registry 106, the replication module 118 can remove the replicated container image 104B from the target registry 108.

[0036] Additionally, the replication module 118 can log replication activity to a logging database 124, such as for auditing or monitoring purposes. In some examples, the container replication computing system 102 can include a logging module 126 communicatively coupled with the logging database 124. The logging module 126 can communicate with the logging database 124, such as using a retrieval request, to retrieve information stored in the logging database 124. Additionally, the logging module 126 can provide information to store in the logging database 124. For example, the logging module 126 can record the generation of the replicated container image 104B to the logging database 124. The logging database 124 can store one or more transfer records 128 that can each correspond to a respective replication of a corresponding container image of the source registry 106. The replication activity can include generating the replicated container image 104B in the target registry7108, subsequent modifications to the replicated container image 104B in response to modifications to the container image 104A, or a combination thereof. In some implementations, the transfer records 128 can include information related to the respective replication of the container images 104A. For example, the transfer records 128 can indicate which container image 104A was replicated, a particular destination repository7or target registry7of the replicated container image 104B, the image digest 122 of the replicated container image 104B, etc. The transfer records 128 can facilitate or contribute to compliance with security or operational requirements. In some examples, the transfer records 128 of the logging database 124 can be used to verify or trace the replication of the container images 104 A.

[0037] In some embodiments, the container replication computing system 102 can include a synchronization module 130 that can implement a synchronization process with respect to the container image(s) 104A stored in the source registry 106. The synchronization module 130 can implement the synchronization process to prepare the target registry 108 for subsequent replications. As an example, the synchronization module 130 can copy one or more existing container images from the source registry 106 to the target registry 108 such that a respective copy of each container image in the source registry 106 is included in the target registry 108. In particular, the synchronization module 130 can determine a difference between the source registry 106 and the target registry7108 relating to a subset of the container images 104A being unavailable in the target registry7108. In other words, the synchronization module 130 can determine that the target registry7108 lacks a respective copy of the subset of the container images 104A. The synchronization module 130 then can 1331014210V.1Attorney Docket No 096923-1460694generate the respective copy of each container image of the subset in the target registry' 108 as part of the synchronization process. Accordingly, by implementing the synchronization process, the target registry 108 can include a respective copy of each container image available in the source registry7106 at a time of performing the synchronization process. After the synchronization process is completed, the container replication computing system 102 can account for modifications to the source registry 106 with respect to the container images 104A by having the replication module 118 perform the subsequent replications. As described herein, the subsequent replications can be an ongoing process where the replication module 118 can update the target registry 108 based on the events 116 of the source registry7106.

[0038] Each communication within the operating environment 100 may occur over one or more data networks 132, such as a public data network, a private data network, or some combination thereof. A data network may include one or more of a variety of different ty pes of networks, including a wireless network, a wired network, or a combination of a wired and wireless network. Examples of suitable networks include the Internet, a personal area network, a local area network (“LAN”), a wide area network (“WAN”), or a wireless local area network (“WLAN”). A wireless network may include a wireless interface or a combination of wireless interfaces. A wired network may include a wired interface. The wired or wireless networks may be implemented using routers, access points, bridges, gateways, or the like, to connect devices in the data network.

[0039] The number of components (e.g., modules, devices, etc.) depicted in FIG. 1 is provided for illustrative purposes. Different numbers of components may be used. For example, while certain devices, modules, services, or systems are shown as single components in FIG. 1, multiple components may instead be used to implement these devices, modules, services, or systems. Similarly, devices, modules, services, or systems that are shown as separate, such as the event subscription module 114 and the replication module 118, may be instead implemented in a single device, module, service, or system.

[0040] FIG. 2 is a flow chart depicting an example of a process 200 for replicating one or more container images 104A in a source registry 106 to a target registry 108. In some examples, the target registry 108 can be hosted by a distributed computing environment (e.g., a cloud environment) or a local computing system (e.g., an on-premises environment). One or more computing devices implement operations depicted in FIG. 2 by executing suitable program code (e.g.. a replication module 118 of FIG. 1). For illustrative purposes, the1431014210V.1Attorney Docket No 096923-1460694process 200 is described with reference to certain examples depicted in the figures. Other implementations, however, are possible.

[0041] At block 202, the process 200 involves receiving or otherwise accessing, by the replication module 118, an event 116 associated with a container image 104A stored in the source registry 106 monitored by the event subscription module 114. In some examples, the event subscription module 114 can subscribe to communication related to the source registry 106. Accordingly, in some implementations, the replication module 118 can receive the event 116 from the event subscription module 114. For example, the communication can be directly provided to the event subscription module 114 by the source registry 106. Additionally or alternatively, the communication can be provided by a messaging service, such as a publish-subscribe messaging service. In some implementations, the event subscription module 114 can receive a notification once the event 116 occurs. As an example, the event subscription module 114 may be notified about a change to the source registry 106, such as a new container image being uploaded or an existing container image being updated (e g., modified or deleted). By way of example, the event subscription module 114 can be configured to receive communication via a webhook. A source repository 110 storing the container image 104A can include a webhook to cause the event subscription module 114 to perform an action in response to the event 116 occurring in the source repository 110. In particular, the webhook can send a POST request to provide data related to the event 116 to the event subscription module 114. After being notified about the event 116, the event subscription module 114 can communicate with the replication module 1 18, such as by transmitting the event 116 to the replication module 118. Accordingly, the replication module 118 can receive or otherwise access the event 116.

[0042] At block 204, the process 200 involves extracting, by the replication module 118, event data 120 associated with the event 116. In some examples, the replication module 118 can parse the event data 120 based on communication received from the event subscription module 114, the source registry 106, or a combination thereof. For example, the replication module 118 can receive or access the POST request directly from the webhook and parse the POST request to extract the event data 120. The POST request can include information related to the container image 104A modified or uploaded to the source registry 106. Examples of the information can include a name or owner of the container image 104A, description of the event 116, repository location or repository name of the source repository 110 that the container image 104A is associated with, etc.1531014210V.1Attorney Docket No 096923-1460694

[0043] At block 206, the process 200 involves determining, by the replication module 118 and based on the event data 120, whether the destination repositor}’ 112 exists in the target registry 108. In some examples, the replication module 118 can determine whether the destination repository 112 exists using a name of the container image 104 A. In particular, the name of the container image 104A can indicate the source repository 110 of the source registry 106 that is associated with the container image 104A. Based on the container image 104 A, the replication module 118 can identify the source repository 110 and determine whether there is a similar or matching repository that exists in the target registry 108. For example, the replication module 118 can perform a similarity’ search (e.g., a string similarity search) based on the name of the container image 104 A to determine whether the destination repository 112 exists in the target registry’ 108. The name of the container image 104A can be compared to each name of a respective repository in the target registry 108. A similarity score generated by the similarity search that is below a predefined threshold may indicate that the target registry 108 lacks the destination repository’ 112. Conversely, the similarity score meeting or exceeding the predefined threshold can indicate that the destination repository 112 exists in the target registry 108.

[0044] At block 208, the process 200 involves, in response to determining that the destination repository’ 112 exists in the target registry’ 108, replicating, by the replication module 118, the container image 104A by generating the copy of the container image 104 A in the destination repository 112 as a replicated container image 104B. The replicated container image 104B can include an image digest 122 that can be used to identity the container image 104A stored in the source registry’ 106. For example, the image digest 122 of the replicated container image 104B can correspond to or match an image digest of the container image 104A. The image digest 122 can be immutable or remain unchanged after replication, which can enable the image digest 122 to function as a suitable identifier to link the replicated container image 104B to the container image 104A.

[0045] In some examples, one or more subsequent modifications to the container image 104A in the source registry’ 106 may occur after the container image 104A is replicated to the target registry 108. For example, a new version of the container image 104 A can be uploaded to the source registry 106. In response to receiving or otherwise accessing a neyv event related to a subsequent modification to the container image 104A, the replication module 118 can identity' any replicated container images related to the container image 104A (e.g., the replicated container image 104B) using the image digest 122. The replication module 118 then can apply the subsequent modification to the replicated container images related to the 1631014210V.1Attorney Docket No 096923-1460694container image 104A that may be stored in the target registry' 108 or other registries. Accordingly, using the image digest 122, the replication module 118 can continually propagate changes applied to the container image 104 A to each replicated container image generated based on the container image 104A.

[0046] At block 210, the process 200 involves, in response to determining that the destination repository 112 does not exist in the target registry 108. generating, by the replication module 118, the destination repository 112 in the target registry 108. The replication module 118 can automatically configure the destination repository 112 to forgo manual intervention to create the destination repository' 112. For example, the replication module 118 can determine a configuration of the source repository 110 of the container image 104A in the source registry 106 and apply the configuration to generate the destination repository 112 in the target registry 108. The replication module 118 can preserve or mirror certain features of the configuration of the source repository' 110, such as with respect to access control, when configuring the destination repository' 112. In some examples, the replication module 118 can apply a rule set to convert the configuration of the corresponding repository to a suitable configuration to create the destination repository 112. Accordingly, the replication module 118 can minimize manual intervention to set up or configure repositories of the target registry 108. After generating the destination repository' 112, the replication module 118 can generate and store the replicated container image 104B in the generated destination repository 112. As described herein, the replicated container image 104B can be a copy of the container image 104 A that is stored in the destination repository 112, such as to provide redundancy in case the container image 104A is unavailable or inaccessible. In some examples, the process 200 can proceed to block 208 to replicate the container image 104A in the destination repository 112 after the destination repository’ 112 is generated at block 210.

[0047] Referring now to FIG. 3, a block diagram depicting an example of a computing environment 300 to implement a failover process between a primary instance 302A and a secondary instance 302B of a replication module 118 is presented. For illustrative purposes, the computing environment 300 is described with reference to certain examples depicted in other figures (e.g., FIG. 1). In some cases, the components depicted in FIG. 3 may be part of the operating environment 100 of FIG. 1, such as part of the container replication computing system 102. Other implementations, however, are possible.

[0048] As described herein, the container replication computing system 102 can include the replication module 118 to replicate a container image from a source registry to a target 1731014210V.1Attorney Docket No 096923-1460694registry. In some examples, the container replication computing system 102 can include a single instance of the replication module 118. In other examples, the container replication computing system 102 can include multiple instances or copies of the replication module 118. Having multiple instances of the replication module 118 can ensure that replication of the container images in the source registry remains available in an event of one instance of the replication module 118 being inaccessible. As shown in FIG. 3, the container replication computing system 102 described herein can include a health monitoring module 304 that can monitor a respective availability of each instance of the replication module 118. In some examples, the health monitoring module 304 can be communicatively coupled with each instance of the replication module 118. The health monitoring module 304 can receive periodic or continuous communication (e.g., one or more messages 306) related to each instance 302 of the replication module 118. Based on the messages 306 or lack thereof, the health monitoring module 304 can determine whether a particular instance of the replication module 118 is available or active.

[0049] In some examples, the container replication computing system 102 can include one or more virtual machines 308 that can each host a respective instance of the replication module 118. In other words, the primary instance 302A and the secondary instance 302B of the replication module 118 can each be hosted separately. Although FIG. 3 is generally described with respect to virtual machines, it will be appreciated that other suitable isolated computing environments, such as containers, are also possible. In some examples, each virtual machine can be associated with a respective availability’ zone. As shown in FIG. 3, a first virtual machine 308A hosting a primary instance 302A of the replication module 118 can be associated with a first availability7zone 310A. A second virtual machine 308B hosting a secondary instance 302B of the replication module 118 can be associated with a second availability zone 310B. Although a single secondary7instance of the replication module 118 is shown in FIG. 3, it wall be appreciated that multiple secondary7instances are possible. Each availability zone can be a physically separate zone that can have a separate set of resources (e.g., power source, network, cooling system, etc.) to support a respective virtual machine. In other words, each availability zone can be located in separate geographical locations while not sharing any service-critical resources with each other. Logical and resource separation of the availability7zones 310 can ensure availability7of at least one instance of the replication module 118 even if one or more other instances are unavailable (e.g., offline for maintenance, compromised by a malicious actor, etc.).1831014210V.1Attorney Docket No 096923-1460694

[0050] Each virtual machine can be communicatively coupled with the health monitoring module 304 to transmit the messages 306 to the health monitoring module 304. In some examples, the virtual machines 308 can transmit a respective set of messages at periodic intervals, such as every five minutes, every hour, etc. The periodic intervals can be predefined or specific to each virtual machine. Accordingly, the health monitoring module 304 can expect to receive a set of messages 306 from a particular virtual machine within a specific time window (e.g., within the next ten minutes). The messages 306 from the virtual machines 308 can function as a measure of availability related to each instance of the replication module 118. In other words, the health monitoring module 304 can determine or verify whether a particular virtual machine and its instance 302 of the replication module 118 is available. As an example, if the health monitoring module 304 fails to receive the messages 306 from the first virtual machine 308A within a particular time window' specific to the first virtual machine 308A, the health monitoring module 304 can determine that the first virtual machine 308A is unavailable. The primary instance 302A of the replication module 118 hosted by the first virtual machine 308A may also be unavailable, such as due to the first virtual machine 308A being unavailable. Conversely, if the health monitoring module 304 receives the messages 306 from the first virtual machine 308A within the particular time window', the health monitoring module 304 can verify that the first virtual machine 308A and the primary instance 302A are currently running or otherwise active.

[0051] In some examples, to ensure availability and reliability of the replication module 1 18, the health monitoring module 304 can initiate a failover process to switch from the primary instance 302A to a secondary' instance 302B of the replication module 118. Other discrepancies related to the messages 306 may cause the health monitoring module 304 to initiate the failover process. For example, the health monitoring module 304 may be configured to receive the messages 306 in a particular format. If the health monitoring module 304 receive messages in a different or incorrect format from the first virtual machine 308A, the health monitoring module 304 may initiate the failover process.

[0052] In some implementations, the failover process can involve modifying a respective status of the primary instance 302A and the secondary instance 302B of the replication module 118. The respective status of the instances 302A-B can indicate which instance is currently handling or responsible for performing replication processes. For example, an active status can be assigned to a particular instance of the replication module 118 that is currently responsible for performing the replication processes. The remaining instances of the replication module can be assigned an inactive status. As an example, the health 1931014210V.1Attorney Docket No 096923-1460694monitoring module 304 can modify an active status of the primary instance 302A to an inactive status based on the first virtual machine 308A being unavailable. Additionally, the health monitoring module 304 can adjust an inactive status of the secondary instance 302B to the active status as part of the failover process such that the secondary instance 302B take over performing the replication processes. Accordingly, the secondary' instance 302B can handle replicating each container image 104 of the source registry to a respective target registry.

[0053] Any suitable computing system or group of computing systems can be used to perform the operations described herein. For example, FIG. 4 is a block diagram depicting an example of a computing device 400, which can be used to implement the container replication computing system 102 of FIG. 1. The computing device 400 can include various devices for communicating with other devices in the operating environment 100, as described with respect to FIG. 1. The computing device 400 can include various devices for performing one or more operations described above with respect to FIGS. 1-3.

[0054] The computing device 400 can include a processor 402 that is communicatively coupled to a memory 404 (e.g.. a memory device or another suitable storage medium). The processor 402 executes computer-executable program code stored in the memory 404, accesses information stored in the memory' 404, or both. Program code may include machine-executable instructions that may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory’ sharing, message passing, token passing, network transmission, among others.

[0055] Examples of a processor 402 include a microprocessor, an application-specific integrated circuit, a field-programmable gate array, or any other suitable processing device. The processor 402 can include any number of processing devices, including one. The processor 402 can include or communicate with a memory 404. The memory 404 stores program code that, when executed by the processor 402, causes the processor to perform the operations described in this disclosure.

[0056] The memory 404 can include any suitable non-transitory computer-readable storage medium. The computer-readable medium can include any electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable 2031014210V.1Attorney Docket No 096923-1460694program code or other program code. Non-limiting examples of a computer-readable medium include a magnetic disk, memory chip, optical storage, flash memory, storage class memory, ROM, RAM, an ASIC, magnetic storage, or any other medium from which a computer processor can read and execute program code. The program code may include processor-specific program code generated by a compiler or an interpreter from code written in any suitable computer-programming language. Examples of suitable programming language include Hadoop, C, C++. C#, Visual Basic. Java, Python. Perl, JavaScript. ActionScript, etc.

[0057] The computing device 400 may also include a number of external or internal devices such as input or output devices. For example, the computing device 400 is shown with an input / output interface 408 that can receive input from input devices or provide output to output devices. A bus 406 can also be included in the computing device 400. The bus 406 can communicatively couple one or more components of the computing device 400.

[0058] The computing device 400 can execute program code 414 that includes components of the container replication computing system 102, such as the event subscription module 114, the replication module 118. and / or the synchronization module 130. The program code 414 for the components of the container replication computing system 102 may be resident in any suitable computer-readable medium and may be executed on any suitable processing device. For example, as depicted in FIG. 4, the program code 414 for the components of the container replication computing system 102 can reside in the memory 404 at the computing device 400 along with the program data 416 associated with the program code 414, such as the transfer records 128 of the logging database 124. Executing the components of the container replication computing system 102 can configure the processor 402 to perform the operations described herein. In some examples, the program code 414 includes the event subscription module 114, the replication module 118, the synchronization module 130, or a combination thereof.

[0059] In some aspects, the computing device 400 can include one or more output devices. One example of an output device is the network interface device 410 depicted in FIG. 4. A network interface device 410 can include any device or group of devices suitable for establishing a wired or wireless data connection to one or more data networks described herein. Non-limiting examples of the network interface device 410 include an Ethernet network adapter, a modem, etc.

[0060] Another example of an output device is the presentation device 412 depicted in FIG. 4. A presentation device 412 can include any device or group of devices suitable for 2131014210V.1Attorney Docket No 096923-1460694providing visual, auditory, or other suitable sensory output. Non-limiting examples of the presentation device 412 include a touchscreen, a monitor, a speaker, a separate mobile computing device, etc. In some aspects, the presentation device 412 can include a remote client-computing device that communicates with the computing device 400 using one or more data networks described herein. In other aspects, the presentation device 412 can be omitted.

[0061] The foregoing description of some examples has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Numerous modifications and adaptations thereof will be apparent to those skilled in the art without departing from the spirit and scope of the disclosure.31014210V.1

Claims

1. Attorney Docket No. 096923-1460694Claims1. A computer-implemented method, in which one or more processing device perform operations comprising:accessing, by a replication module, an event associated with a container image of one or more container images stored in a source registry;extracting, by the replication module, event data associated with the event; determining, by the replication module and based on the event data, whether a destination repository exists in a target registry to which the container image is to be replicated; andin response to determining that the destination repository exists in the target registry, replicating, by the replication module, the container image by generating a copy of the container image in the destination repository, the copy of the container image comprising an image digest identifying the container image stored in the source registry.

2. The computer-implemented method of claim 1, further comprising:accessing, by the replication module and from an event subscription module, another event indicating that an additional update to the container image in the source registry' has occurred, wherein the source registry is monitored by the event subscription module;identifying, by the replication module and based on the image digest of the container image, the copy of the container image stored in the target registry; andsubsequent to identifying the copy of the container image, applying, by the replication module, the additional update related to the other event to the copy of the container image.

3. The computer-implemented method of claim 1, wherein the replication module has a primary instance and one or more secondary' instances that are each hosted separately, and wherein, in response to detecting that the primary instance is unavailable, a failover process is automatically initiated such that a particular secondary instance of the one or more secondary’ instances takes over replicating each container image of the one or more container images to a respective target registry'.

4. The computer-implemented method of claim 3, wherein detecting that the primary' instance of the replication module is unavailable comprises:2331014210V.1Attorney Docket No. 096923-1460694determining that a virtual machine hosting the primary' instance of the replication module has failed to transmit a message indicating availability- of the primary instance of the replication module; anddetermining, based on the virtual machine failing to transmit the message, that the primary instance of the replication module is unavailable.

5. The computer-implemented method of claim 1, further comprising:recording the generation of the copy of the container image in the destination repository to a logging database comprising one or more transfer records, wherein each transfer record corresponds to a respective replication of the one or more container images.

6. The computer-implemented method of claim 1, further comprising, prior to accessing the event:determining a difference between the source registry and the target registry, wherein the difference relates to a subset of the one or more container images being unavailable in the target registry; andgenerating, by a synchronization module, a respective copy of each container image of the subset in the target registry' as part of a synchronization process such that the target registry' comprises the respective copy of each container image of the source registry.

7. The computer-implemented method of claim 1 , further comprising:in response to determining that the destination repository' is absent from the target registry, generating the destination repository in the target registry based on a configuration of a source repository storing the container image in the source registry.

8. A system comprising:a processor; anda memory device in which instructions executable by the processor are stored for causing the processor to:access, by a replication module, an event associated with a container image of one or more container images stored in a source registry';extract, by the replication module, event data associated with the event;2431014210V.1Attorney Docket No. 096923-1460694determine, by the replication module and based on the event data, whether a destination repository exists in a target registry to which the container image is to be replicated: andin response to determining that the destination repository exists in the target registry, replicate, by the replication module, the container image by generating a copy of the container image in the destination repository, the copy of the container image comprising an image digest identifying the container image stored in the source registry.

9. The system of claim 8, wherein the instructions further cause the processor to:access, by the replication module and from an event subscription module, another event indicating that an additional update to the container image in the source registry has occurred, wherein the source registry is monitored by the event subscription module;identify, by the replication module and based on the image digest of the container image, the copy of the container image stored in the target registry; andsubsequent to identifying the copy of the container image, apply, by the replication module, the additional update related to the other event to the copy of the container image.

10. The system of claim 8. wherein the replication module has a primary instance and one or more secondary instances that are each hosted separately, and wherein, in response to detecting that the primary instance is unavailable, a failover process is automatically initiated such that a particular secondary’ instance of the one or more secondary’ instances takes over replicating each container image of the one or more container images to a respective target registry.

11. The system of claim 10, wherein detecting that the primary' instance of the replication module is unavailable comprises:determining that a virtual machine hosting the primary’ instance of the replication module has failed to transmit a message indicating availability of the primary instance of the replication module: anddetermining, based on the virtual machine failing to transmit the message, that the primary' instance of the replication module is unavailable.

12. The system of claim 8, wherein the instructions further cause the processor to:2531014210V.1Attorney Docket No. 096923-1460694record the generation of the copy of the container image in the destination repository to a logging database comprising one or more transfer records, wherein each transfer record corresponds to a respective replication of the one or more container images.

13. The system of claim 8, wherein the instructions further cause the processor to, prior to accessing the event:determine a difference between the source registry and the target registry, wherein the difference relates to a subset of the one or more container images being unavailable in the target registry; andgenerate, by a synchronization module, a respective copy of each container image of the subset in the target registry as part of a synchronization process such that the target registry comprises the respective copy of each container image of the source registry.

14. The system of claim 8, wherein the instructions further cause the processor to:in response to determining that the destination repository is absent from the target registry, generate the destination repository in the target registry based on a configuration of a source repository storing the container image in the source registry.

15. A non-transitory computer-readable storage medium having program code that is executable by a processor to cause a computing device to perform operations, the operations comprising:accessing, by a replication module, an event associated with a container image of one or more container images stored in a source registry;extracting, by the replication module, event data associated with the event; determining, by the replication module and based on the event data, whether a destination repository exists in a target registry to which the container image is to be replicated; andin response to determining that the destination repository exists in the target registry, replicating, by the replication module, the container image by generating a copy of the container image in the destination repository, the copy of the container image comprising an image digest identifying the container image stored in the source registry.

16. The non-transitory computer-readable storage medium of claim 15. wherein the operations further comprise:2631014210V.1Attorney Docket No. 096923-1460694accessing, by the replication module and from an event subscription module, another event indicating that an additional update to the container image in the source registry has occurred, wherein the source registry is monitored by the event subscription module;identifying, by the replication module and based on the image digest of the container image, the copy of the container image stored in the target registry7; andsubsequent to identifying the copy of the container image, applying, by the replication module, the additional update related to the other event to the copy of the container image.

17. The non-transitory computer-readable storage medium of claim 15, wherein the replication module has a primary instance and one or more secondary instances that are each hosted separately, and wherein, in response to detecting that the primary instance is unavailable, a failover process is automatically initiated such that a particular secondary7instance of the one or more secondary7instances takes over replicating each container image of the one or more container images to a respective target registry.

18. The non-transitory computer-readable storage medium of claim 17, wherein detecting that the primary instance of the replication module is unavailable comprises:determining that a virtual machine hosting the primary7instance of the replication module has failed to transmit a message indicating availability of the primary instance of the replication module; anddetermining, based on the virtual machine failing to transmit the message, that the primary' instance of the replication module is unavailable.

19. The non-transitory computer-readable storage medium of claim 15. wherein the operations further comprise:recording the generation of the copy7of the container image in the destination repository7to a logging database comprising one or more transfer records, wherein each transfer record corresponds to a respective replication of the one or more container images.

20. The non-transitory computer-readable storage medium of claim 15, wherein the operations further comprise, prior to accessing the event:determining a difference between the source registry and the target registry7, wherein the difference relates to a subset of the one or more container images being unavailable in the target registry; and2731014210V.1Attorney Docket No. 096923-1460694generating, by a synchronization module, a respective copy of each container image of the subset in the target registry as part of a synchronization process such that the target registry comprises the respective copy of each container image of the source registry.2831014210V.1

Images