A cloud-based Azure Container Registry (ACR) provides secure, reliable, and global distribution of artifacts. Today, customers are also extending their cloud solutions to the edge. Connected registry is an on-premises registry solution that synchronizes images and OCI artifacts with your cloud-based ACR. This on-premises registry operates with high availability and performance for your on-premises solution that depends on container workloads. Use Azure tools to deploy the connected registry on a server or device on your premises, such as IoT Edge. Read more at What is a connected registry?
Connected Registry Synchronization
A connected registry is an on-premises extension of an ACR that synchronizes selected repositories with the cloud registry. Once deployed, the instance regularly communicates with the cloud ACR in order to stay up to date. Synchronization is achieved through enqueued messages between the cloud and on-premises. A message can communicate several artifact events for tracked repositories, including push, delete, tag, and untag.
Once synchronization completes, the updated cloud registry artifacts are available on-premises. In addition to registry content updates, the deployed instance is notified of any configuration changes made in the cloud. These updates may include additions or removals of linked repositories, as well as adjustments to sync schedules. The connected registry is also informed of updates made to dependent resources, including client tokens, sync tokens, or child connected registries. Token messages may convey password rotation, permissions update, and token status update.
Control On-Premises to Cloud Communication
The following configurations are available to control when a connected registry syncs with the parent ACR. These properties can be updated on the connected registry as needed.
|
Property |
Description |
Range and Default |
|
Schedule |
Defines when a connected registry instance will start syncing with the parent ACR. The schedule is represented as a five-field CRON expression. |
Default: * * * * *, which indicates that the connected registry will continuously sync with the ACR, meaning it will communicate every minute. |
|
Sync Window |
ISO 8601 duration that defines how long a connected registry will sync with the ACR after the sync has started. Only required if the sync schedule is not continuous (“* * * * *”). |
Minimum: 1 hour Maximum: 7 days |
|
Message TTL |
ISO 8601 duration that defines the length of time a message will be kept for cloud-to-device and device-to-cloud communications. After the TTL expires and a message has not been delivered, it will be deleted. |
Minimum: 1 day Maximum: 90 days Default: 2 days |
Occasionally Connected Scenario
On-premises users fall into the occasionally connected scenario when they do not experience persistent connectivity to their premises. In this scenario, the connected registry can be leveraged since it can operate while disconnected for up to 90 days. While disconnected, the registry is still fully functionable and able to serve container images and artifacts.
The occasionally connected scenario includes at-sea operations where at-sea connectivity is expensive to maintain. The scenario extends to oil platforms and other remote scenarios where connectivity is limited and unreliable. In such cases, the user can schedule synchronization for the connected registry to avoid the need for expensive satellite connectivity. The local registry will only synchronize when the vessel is at port.
Scheduled Synchronization
Connected registry supports planned synchronization for occasionally connected scenarios. This ensures that the instance will only communicate with the cloud registry during scheduled windows of time. Outside of these time frames, the registry does not try to contact the cloud.
Let’s walk through an example scenario that can leverage scheduled synchronization. A cargo ship leaves port for a 20-day journey across the ocean, expecting to reach the destination port on the 15th of the month. It will stay in port for 10 days then make the same 20-day journey back. To avoid at-sea connectivity, the connected registry deployed on the vessel can only communicate with the cloud ACR when the ship is at port. The connected registry sync settings can be configured as follows:
- Schedule: “0 9 15 * *” indicates that the connected registry will start syncing at 9AM, on day 15th of the month.
- Sync Window: “P1D” indicates that the connected registry should continue syncing with the ACR for 24 hours after the sync starts.
- Message TTL: “P60D” indicates that any messages between the cloud and connected registry will wait for delivery for up to 60 days. We use a conservative message TTL in case the vessel takes longer than the scheduled 20 days to reach port.
The below sample creates a connected registry, “ship12registry”, in the Azure portal with the above sync configuration. The connected registry is configured to sync three repositories from the ACR that are used to deploy applications on the vessel. ReadOnly mode indicates that this connected registry allows pull-only functionality. For more information on operating modes, reference our public documentation. Learn more about creating a connected registry on the Azure portal at Create connected registry using the portal.
Scheduled Sync Recovery
If the connected registry is still offline at the time of a scheduled synchronization, the sync will not occur. The local registry has a concept of “recovery” where it can detect that a missed sync has occurred and next time the instance comes online, it will immediately sync with the cloud. After recovery, the next sync will still take place according to schedule.
It is recommended to configure the connected registry with a longer message TTL than one thinks is necessary. This helps ensure that whenever the registry establishes a connection with the cloud, messages are still available for delivery. Connected registry supports a maximum message TTL of 90 days. With this setting, a registry can be offline for 90 days with no messages lost and will be fully synchronized with the ACR when it comes online.
Example of Scheduled Synchronization and Recovery
This example uses the same scenario as above. There is a connected registry deployed on a cargo ship vessel that is scheduled to sync on the 15th day of the month at 9AM for a 24-hour sync window. The message TTL for this scenario is 60 days.
The following events take place:
- 9AM, Oct 15: The ship is in port and connected to internet. The connected registry syncs with the cloud registry at 9AM per the configured schedule and will continue until 9AM, Oct 16.
- 10AM, Oct 16: The ship leaves port at 10AM and disconnects from internet.
- 9AM, Nov 15: The ship is still at sea and not connected to internet. The connected registry tries to sync with the ACR per the configured schedule but cannot connect. The registry knows that it needs to perform a recovery sync next time it is online.
- 11 AM, Nov 18: The vessel arrives at port three days later.
- 12PM, Nov 18: The ship is at port and connects to internet. The connected registry detects that it missed a scheduled sync and immediately performs a sync with the cloud registry.
- 9AM, Dec 15: The shipping vessel is at port and connected to internet. The connected registry starts syncing at 9AM with the cloud registry per the configured schedule and will continue until 9AM, Dec 16.
After missing a scheduled sync, the connected registry will recover any missed messages whenever it gets online. After performing this recovery, the next scheduled sync will perform as usual if the connected registry is online. Since the message TTL for the connected registry is 60 days, the connected registry can recover all messages that were missed since the last sync.
Summary
Connected registry unlocks image availability at the edge, where connectivity is not always guaranteed. Users can rely on connected registry for highly performant and reliable on-premises content distribution.
Next Steps
Learn more about connected registry at https://aka.ms/acr/connected-registry. For more information on authentication and how to deploy a connected registry on-premises as an IoT Edge module, reference