This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
We’re excited to release Azure IoT Edge 1.4, a new long-term servicing (LTS) version, to provide a stable base on which to build your edge solutions. The 1.4 version will be fully supported through November 12, 2024 and is backward compatible with 1.1+ (Understand our product lifecycle). The companion release for Azure IoT Edge for Linux on Windows will be coming later this year.
What’s New?
This release expands on the features that were added since the last LTS with an additional focus on production readiness. This includes:
- integration with Azure Monitor,
- enabling hierarchies of IoT Edge devices,
- automatic cert renewal,
- support for EST,
- expanded platform support, and more.
The 1.4 release specifically brings:
Automatic image cleanup of unused Docker images by default
This has been the top feature ask on our feedback site. Over time as new deployments of IoT Edge modules are made and modules are removed, your device can accumulate unused Docker images that consume disk space and can ultimately lead to system instability. By default, IoT Edge now performs a regular, automated check to identify and remove such unused Docker images. Don’t worry, it will ignore images that are never required by an IoT Edge deployment (e.g. you’ve sideloaded them manually via the Docker CLI or some other mechanism). It only considers images to be unused when they were required for a previous IoT Edge deployment. The Production deployment checklist contains details on how to adjust the behavior if you want to change how frequently it runs or how aggressively it should remove unused images.
An option to download all modules in a deployment before (re)starting any
When IoT Edge processes a new deployment it will pull all modules and attempt to start them as soon as they’ve finished downloading. While this is fine in a traditional microservice-based architecture with loose coupling between modules, it can be problematic if module A has a dependency on module B and module B takes a lot longer to download. Just imagine losing connectivity after A is downloaded, but before B finishes so that module A starts up but has to wait and potentially retry indefinitely. Instead, you now have the option to require that before any module is (re)started all modules in the deployment must be successfully downloaded. In essence, your already running deployment will continue to run until the modules for the next deployment are on disk. To learn more see the docs on configuring how updates to modules are applied.
The ability to pass a custom JSON payload to DPS on provisioning
Sometimes DPS needs more data from devices to properly provision them to the right IoT Hub, and that data needs to be provided by the device. While the Azure IoT SDKs offered this already, it has been lacking on IoT Edge. Starting with 1.4 you can configure IoT Edge to read from a local JSON file on disk and send it to DPS as a custom payload (doc). Using IoT Edge with IoT Central? You can use it to enable automatic assignment of the device template for your IoT Edge devices by passing a model ID.
Use of the TCG TPM2 Software Stack
By using the TCG TSS 2.0 software stack we can offer more options for configuring IoT Edge with your TPM to deal with special situations. As an example, when using TPM attestation with DPS our prior implementation always attempted to persist the authentication key to a fixed location. With 1.4 you can choose a different index and avoid potential collisions when you expect that default slot will be used for something else. To learn more, refer to the TPM configuration options available in IoT Edge’s config.toml file.
Upgrading to the latest
If you’re upgrading from a prior version, be sure to check out the documentation to understand any changes that may affect you.
Resources
Azure IoT Edge | Documentation overview
Have a suggestion? Upvote or add it at https://aka.ms/iotedge-suggestion