Hierarchical Deployment of IoT Edge with ACR Connected Registry

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.


ACR connected registry is Azure Container Registry’s on-premises extension allowing customers to bring the registry and its capabilities closer to their edge devices. In this article, we will discuss how the ACR connected registry solution can simplify the management of container images in hierarchical IoT Edge deployments and enable IoT administrators to achieve unified control over the lifecycle of container images.


Recap of IoT Edge Hierarchical Deployment

IoT Edge hierarchical deployment is a top-down layered deployment of IoT Edge devices enabling north-south communication between them. The lower layers on the deployment cannot communicate directly with the cloud and need to go through the layer above.

Let us consider the following example, where an image simulated temperature sensor is pushed to Azure container registry and eventually made available on the lower layer IoT Edge device.




The Image is first downloaded to top layer IoT Edge device from the cloud ACR. Once available on the top layer, the deployment of lower layer IoT Edge device triggers a registry request to fetch the image from top layer. The lower layers request registry content from the parent on “/v2” endpoint. These requests from the lower layer device are routed to the registry module through the IoT Edge API proxy module. For more details on IoT Edge Hierarchical deployments, please follow the tutorial provided by Azure IoT here.


IoT Edge Hierarchical Deployment with Connected Registry

As described in this document, IoT Edge modules are the fundamental functional units of IoT Edge devices, and they run as containers that provide various services. Connected registry runs as a separate edge module on Azure IoT Edge devices that provide the functionality of automatically synchronizing container images with the cloud ACR and storing them for downstream usage.

The module assumes two responsibilities:

  1. Act as a client to synchronize images from the parent device or the cloud ACR.
  2. Act as a server for requests from local clients or from downstream IoT Edge devices.

The deployment with ACR connected registry is shown below.




It should be noted that the ACR connected registry module plays the role of a registry intended to synchronize images with the parent and to serve the images for local usage and downstream child IoT Edge device. The synchronization can be controlled at the repository level and can be scheduled using a Cron expression.


How the ACR Connected Registry Work in IoT Edge Scenarios?


ACR Connected Registry as a Client

As a client, the ACR connected registry periodically polls the parent and looks for new content to synchronize. It handles the responsibility of updating the list of local container images and synchronizing them with the parent. The polling is http based and can be controlled using the synchronization schedule (Scheduled Synchronization of Registry Artifacts for Shipping Scenarios) for the connected registry. Along with images, the client also synchronizes authentication tokens and configuration for the connected registry module from the parent. The parent is either another IoT Edge device or the cloud ACR in the case of top-level root IoT Edge device.

Also, during the synchronization, the connected registry module posts status updates (along with locally pushed images, if ReadWrite mode is used) to the parent.


ACR Connected Registry as a Server

As noted earlier, in a hierarchical deployment, the ACR connected registry module is paired with IoT API proxy module to act as a server. The API proxy module is configured to redirect requests to “/acr” and “/v2” endpoints on the device to the connected registry module. Endpoint “/acr” is to serve connected registry specific requests from the client and endpoint “/v2” is to serve the manifests and image layers. The CONNECTED_ACR_ROUTE_ADDRESS is the connected registry endpoint which is configured in the IoT API proxy deployment manifest as explained in the next section. The API proxy configuration for the connected registry module is shown below.




#if_tag ${CONNECTED_ACR_ROUTE_ADDRESS} location /v2 { resolver; proxy_http_version 1.1; proxy_pass http://${CONNECTED_ACR_ROUTE_ADDRESS}; } location /acr { resolver; proxy_http_version 1.1; proxy_pass http://${CONNECTED_ACR_ROUTE_ADDRESS}; } #endif_tag ${CONNECTED_ACR_ROUTE_ADDRESS}





Understanding the Deployment Manifest for IoT Edge with Connected Registry Module

The module deployment for Azure IoT Edge is managed using a manifest as described here. To deploy the ACR connected registry on an IoT Edge device, the connected registry module and API proxy module are added to the deployment manifest as shown in Tutorial - Deploy a connected registry to a nested IoT Edge device - Azure Container Registry.

The connected registry module section of the manifest consists of the connection string required to start and activate the connected registry. The settings section contains information about the image, port bindings, certs, and data storage mount information to be used by the connected registry.




"connected-registry": { "settings": { "image": "$upstream/acr/connected-registry:0.5.0", "createOptions": "{\"HostConfig\":{\"Binds\":[\"/home/azureuser/connected-registry:/var/acr/data\"]}, {\"PortBindings\": {\"8080/tcp\": [{\"HostPort\": \"8080\"}]}}}" }, "type": "docker", "env": { "ACR_REGISTRY_CONNECTION_STRING": { "value": "ConnectedRegistryName=myconnectedmirror;SyncTokenName=myconnectedmirror-sync-token; SyncTokenPassword=xxxxx;ParentGatewayEndpoint=$IOTEDGE_PARENTHOSTNAME;ParentEndpointProtocol=https" } }, "status": "running", "restartPolicy": "always", "version": "1.0" }




In the above example, the image acr/connected-registry:0.5.0 fetched from upstream is used for the connected registry. The createOptions sections binds the path /home/azureuser/connected-registry on host to be used as data path /var/acr/data on the container. It also consists of the port to be used for the ACR connected registry module. In this case port 8080 is mapped to the connected registry and it can also be changed as per the user requirement.


The IoT API proxy module is configured to run on port 443 and the user needs to make sure that the same port is not used by other modules like hub on the IoT Edge. The deployment manifest for IoT API proxy is shown below, Please note the port 8080 configured on connected-registry module is used by the IoT API proxy module to redirect the requests.




"IoTEdgeApiProxy": { "settings": { "image": "$upstream/azureiotedge-api-proxy:1.1.2", "createOptions": "{\"HostConfig\": {\"PortBindings\": {\"443/tcp\": [{\"HostPort\": \"443\"}]}}}" }, "type": "docker", "version": "1.0", "env": { "NGINX_DEFAULT_PORT": { "value": "443" }, "CONNECTED_ACR_ROUTE_ADDRESS": { "value": "connectedRegistry:8080" }, "BLOB_UPLOAD_ROUTE_ADDRESS": { "value": "AzureBlobStorageonIoTEdge:11002" } }, "status": "running", "restartPolicy": "always", "startupOrder": 3 }




It is worth noting that the integration of connected registry with IoT API proxy allows the connected registry to use the certificates that are deployed for the IoT API proxy on Azure IoT Edge devices.



To conclude, ACR connected registry is an extension of Azure Container Registry allowing you to automatically synchronize updates and manage container images on Azure IoT Edge devices. It enables advanced hierarchical scenarios that are already deployed in manufacturing and other industrial settings.

To learn more about the ACR Connected Registry, please follow What is a connected registry - Azure Container Registry | Microsoft Docs

To learn how our partner Codit used the connected registry to deploy containerized applications on shipping vessels, please check their blog post How the Azure connected Container Registry Helps to Connect Vessels.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.