You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/iot-edge/how-to-store-data-blob.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,11 +1,11 @@
1
1
---
2
-
title: Store block blobs on devices - Azure IoT Edge | Microsoft Docs
3
-
description: Understand tiering and time-to-live features, see supported blob storage operations, and connect to your blob storage account.
2
+
title: Store block blobs on Azure IoT Edge devices
3
+
description: Understand how to use Azure Blob Storage on IoT Edge including features, supported blob storage operations, and connecting to your blob storage account.
4
4
author: PatAltimore
5
5
ms.author: patricka
6
6
ms.reviewer: arduppal
7
-
ms.date: 12/13/2019
8
-
ms.topic: conceptual
7
+
ms.date: 06/06/2024
8
+
ms.topic: concept-article
9
9
ms.service: iot-edge
10
10
ms.custom: linux-related-content
11
11
services: iot-edge
@@ -37,7 +37,7 @@ The **deviceToCloudUpload** feature is a configurable functionality. This functi
37
37
38
38
This module uses block level upload, when your blob consists of blocks. Here are some of the common scenarios:
39
39
40
-
* Your application updates some blocks of a previously uploaded block blob or appends new blocks to an append blob, this module uploads only the updated blocks and not the whole blob.
40
+
* Your application updates some blocks of a previously uploaded block blob or appends new blocks to an append blob. This module uploads only the updated blocks and not the whole blob.
41
41
* The module is uploading blob and internet connection goes away, when the connectivity is back again it uploads only the remaining blocks and not the whole blob.
42
42
43
43
If an unexpected process termination (like power failure) happens during a blob upload, all blocks due for the upload are uploaded again once the module comes back online.
@@ -75,7 +75,7 @@ The name of this setting is `deviceToCloudUploadProperties`. If you're using the
75
75
| Property | Possible Values | Explanation |
76
76
| ----- | ----- | ---- |
77
77
| uploadOn | true, false | Set to `false` by default. If you want to turn on the feature, set this field to `true`. <br><br> Environment variable: `deviceToCloudUploadProperties__uploadOn={false,true}`|
78
-
| uploadOrder | NewestFirst, OldestFirst | Allows you to choose the order in which the data is copied to Azure. Set to `OldestFirst` by default. The order is determined by last modified time of Blob. <br><br> Environment variable: `deviceToCloudUploadProperties__uploadOrder={NewestFirst,OldestFirst}`|
78
+
| uploadOrder | NewestFirst, OldestFirst | Allows you to choose the order in which the data is copied to Azure. Set to `OldestFirst` by default. The order is determined by last modified time of blob. <br><br> Environment variable: `deviceToCloudUploadProperties__uploadOrder={NewestFirst,OldestFirst}`|
79
79
| cloudStorageConnectionString ||`"DefaultEndpointsProtocol=https;AccountName=<your Azure Storage Account Name>;AccountKey=<your Azure Storage Account Key>;EndpointSuffix=<your end point suffix>"` is a connection string that allows you to specify the storage account to which you want your data uploaded. Specify `Azure Storage Account Name`, `Azure Storage Account Key`, `End point suffix`. Add appropriate EndpointSuffix of Azure where data is uploaded, it varies for Global Azure, Government Azure, and Microsoft Azure Stack. <br><br> You can choose to specify Azure Storage SAS connection string here. But you have to update this property when it expires. SAS permissions may include create access for containers and create, write, and add access for blobs. <br><br> Environment variable: `deviceToCloudUploadProperties__cloudStorageConnectionString=<connection string>`|
80
80
| storageContainersForUpload | `"<source container name1>": {"target": "<target container name>"}`,<br><br> `"<source container name1>": {"target": "%h-%d-%m-%c"}`, <br><br> `"<source container name1>": {"target": "%d-%c"}` | Allows you to specify the container names you want to upload to Azure. This module allows you to specify both source and target container names. If you don't specify the target container name, it's automatically assigned a container name such as `<IoTHubName>-<IotEdgeDeviceID>-<ModuleName>-<SourceContainerName>`. You can create template strings for target container name, check out the possible values column. <br>* %h -> IoT Hub Name (3-50 characters). <br>* %d -> IoT Edge Device ID (1 to 129 characters). <br>* %m -> Module Name (1 to 64 characters). <br>* %c -> Source Container Name (3 to 63 characters). <br><br>Maximum size of the container name is 63 characters. The name is automatically assigned the target container name if the size of container exceeds 63 characters. In this case, name is trimmed in each section (IoTHubName, IotEdgeDeviceID, ModuleName, SourceContainerName) to 15 characters. <br><br> Environment variable: `deviceToCloudUploadProperties__storageContainersForUpload__<sourceName>__target=<targetName>` |
81
81
| deleteAfterUpload | true, false | Set to `false` by default. When set to `true`, the data automatically deletes when the upload to cloud storage is finished. <br><br> **CAUTION**: If you're using append blobs, this setting deletes append blobs from local storage after a successful upload, and any future Append Block operations to those blobs will fail. Use this setting with caution. Don't enable this setting if your application does infrequent append operations or doesn't support continuous append operations<br><br> Environment variable: `deviceToCloudUploadProperties__deleteAfterUpload={false,true}`. |
description: Manages the IoT Edge device security stance and the integrity of security services.
2
+
title: Azure IoT Edge security manager and module runtime
3
+
description: Understand how Azure IoT Edge security manager and module runtime enable IoT Edge device security and the integrity of security services.
4
4
services: iot-edge
5
5
keywords: security, secure element, enclave, TEE, IoT Edge
6
6
author: PatAltimore
7
7
ms.author: patricka
8
8
ms.reviewer: eustacea
9
-
ms.date: 05/27/2022
9
+
ms.date: 06/06/2024
10
10
ms.topic: conceptual
11
11
ms.service: iot-edge
12
12
---
@@ -84,7 +84,7 @@ The cloud interface enables access to cloud services that complement device secu
84
84
85
85
The management API is called by the IoT Edge agent when creating/starting/stopping/removing an IoT Edge module. The module runtime stores "registrations" for all active modules. These registrations map a module's identity to some properties of the module. For example, these module properties include the process identifier (pid) of the process running in the container and the hash of the docker container's contents.
86
86
87
-
These properties are used by the workload API (described below) to verify that the caller is authorized for an action.
87
+
These properties are used by the workload API to verify that the caller is authorized for an action.
88
88
89
89
The management API is a privileged API, callable only from the IoT Edge agent. Since the IoT Edge module runtime bootstraps and starts the IoT Edge agent, it verifies that the IoT Edge agent hasn't been tampered with, then it can create an implicit registration for the IoT Edge agent. The same attestation process that the workload API uses also restricts access to the management API to only the IoT Edge agent.
90
90
@@ -118,7 +118,7 @@ The IoT Edge security manager implements the Trusted Platform Module and PKCS#11
118
118
119
119
## Secure silicon root of trust hardware
120
120
121
-
Secure silicon is necessary to anchor trust inside the IoT Edge device hardware. Secure silicon come in variety to include Trusted Platform Module (TPM), embedded Secure Element (eSE), Arm TrustZone, Intel SGX, and custom secure silicon technologies. The use of secure silicon root of trust in devices is recommended given the threats associated with physical accessibility of IoT devices.
121
+
Secure silicon is necessary to anchor trust inside the IoT Edge device hardware. Secure silicon come in variety to include Trusted Platform Module (TPM), embedded Secure Element (eSE), Arm TrustZone, Intel SGX, and custom secure silicon technologies. The use of secure silicon root of trust in devices is recommended given the threats associated with physical accessibility of IoT devices.
122
122
123
123
The IoT Edge security manager aims to identify and isolate the components that defend the security and integrity of the Azure IoT Edge platform for custom hardening. Third parties, like device makers, should make use of custom security features available with their device hardware.
There are three forms of nested virtualization compatible with Azure IoT Edge for Linux on Windows. Users can choose to deploy through a local virtual machine (using Hyper-V hypervisor), VMware Windows virtual machine or Azure Virtual Machine. This article will provide users clarity on which option is best for their scenario and provide insight into configuration requirements.
17
+
There are three forms of nested virtualization compatible with Azure IoT Edge for Linux on Windows. Users can choose to deploy through a local virtual machine (using Hyper-V hypervisor), VMware Windows virtual machine, or Azure Virtual Machine. This article provides clarity on which option is best for their scenario and provide insight into configuration requirements.
19
18
20
19
> [!NOTE]
21
20
> Ensure to enable one [networking option](/virtualization/hyper-v-on-windows/user-guide/nested-virtualization#networking-options) for nested virtualization. Failing to do so will result in EFLOW installation errors.
Copy file name to clipboardExpand all lines: articles/iot-edge/production-checklist.md
+8-10Lines changed: 8 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,10 @@
1
1
---
2
-
title: Prepare to deploy your solution in production - Azure IoT Edge
3
-
description: Learn how to take your Azure IoT Edge solution from development to production, including setting up your devices with the appropriate certificates and making a deployment plan for future code updates.
2
+
title: Prepare your Azure IoT Edge solution for production
3
+
description: Ready your Azure IoT Edge solution for production. Learn how to set up your devices with certificates and make a deployment plan for future updates.
4
4
author: PatAltimore
5
5
6
6
ms.author: patricka
7
-
ms.date: 07/22/2022
7
+
ms.date: 06/06/2024
8
8
ms.topic: conceptual
9
9
ms.service: iot-edge
10
10
services: iot-edge
@@ -84,7 +84,7 @@ Once your IoT Edge device connects, be sure to continue configuring the Upstream
84
84
85
85
### Be consistent with upstream protocol
86
86
87
-
If you configured the IoT Edge agent on your IoT Edge device to use a different protocol than the default AMQP, then you should declare the same protocol in all future deployments. For example, if your IoT Edge device is behind a proxy server that blocks AMQP ports, you probably configured the device to connect over AMQP over WebSocket (AMQPWS). When you deploy modules to the device, configure the same AMQPWS protocol for the IoT Edge agent and IoT Edge hub, or else the default AMQP will override the settings and prevent you from connecting again.
87
+
If you configured the IoT Edge agent on your IoT Edge device to use a different protocol than the default AMQP, then you should declare the same protocol in all future deployments. For example, if your IoT Edge device is behind a proxy server that blocks AMQP ports, you probably configured the device to connect over AMQP over WebSocket (AMQPWS). When you deploy modules to the device, configure the same AMQPWS protocol for the IoT Edge agent and IoT Edge hub, or else the default AMQP overrides the settings and prevents you from connecting again.
88
88
89
89
You only have to configure the UpstreamProtocol environment variable for the IoT Edge agent and IoT Edge hub modules. Any additional modules adopt whatever protocol is set in the runtime modules.
90
90
@@ -177,7 +177,7 @@ In some cases, for example when dependencies exist between modules, it may be de
177
177
178
178
A tag is a docker concept that you can use to distinguish between versions of docker containers. Tags are suffixes like **1.5** that go on the end of a container repository. For example, **mcr.microsoft.com/azureiotedge-agent:1.5**. Tags are mutable and can be changed to point to another container at any time, so your team should agree on a convention to follow as you update your module images moving forward.
179
179
180
-
Tags also help you to enforce updates on your IoT Edge devices. When you push an updated version of a module to your container registry, increment the tag. Then, push a new deployment to your devices with the tag incremented. The container engine will recognize the incremented tag as a new version and will pull the latest module version down to your device.
180
+
Tags also help you to enforce updates on your IoT Edge devices. When you push an updated version of a module to your container registry, increment the tag. Then, push a new deployment to your devices with the tag incremented. The container engine recognizes the incremented tag as a new version and pulls the latest module version down to your device.
181
181
182
182
#### Tags for the IoT Edge runtime
183
183
@@ -192,7 +192,7 @@ IoT Edge does not remove volumes attached to module containers. This behavior is
192
192
193
193
### Store runtime containers in your private registry
194
194
195
-
You know how to store container images for custom code modules in your private Azure registry, but you can also use it to store public container images such as the **edgeAgent** and **edgeHub** runtime modules. Doing so may be required if you have very tight firewall restrictions as these runtime containers are stored in the Microsoft Container Registry (MCR).
195
+
You know how to store container images for custom code modules in your private Azure registry, but you can also use it to store public container images such as the **edgeAgent** and **edgeHub** runtime modules. Doing so may be required if you have tight firewall restrictions as these runtime containers are stored in the Microsoft Container Registry (MCR).
196
196
197
197
The following steps illustrate how to pull a Docker image of **edgeAgent** and **edgeHub** to your local machine, retag it, push it to your private registry, then update your configuration file so your devices know to pull the image from your private registry.
198
198
@@ -405,7 +405,7 @@ When you're testing an IoT Edge deployment, you can usually access your devices
405
405
406
406
### Set up default logging driver
407
407
408
-
By default, the Moby container engine does not set container log size limits. Over time, this can lead to the device filling up with logs and running out of disk space. Configure your container engine to use the [`local` logging driver](https://docs.docker.com/config/containers/logging/local/) as your logging mechanism. `Local` logging driver offers a default log size limit, performs log-rotation by default, and uses a more efficient file format which helps to prevent disk space exhaustion. You may also choose to use different [logging drivers](https://docs.docker.com/config/containers/logging/configure/) and set different size limits based on your need.
408
+
By default, the Moby container engine does not set container log size limits. Over time, this can lead to the device filling up with logs and running out of disk space. Configure your container engine to use the [`local` logging driver](https://docs.docker.com/config/containers/logging/local/) as your logging mechanism. `Local` logging driver offers a default log size limit, performs log-rotation by default, and uses a more efficient file format, which helps to prevent disk space exhaustion. You may also choose to use different [logging drivers](https://docs.docker.com/config/containers/logging/configure/) and set different size limits based on your need.
409
409
410
410
#### Option: Configure the default logging driver for all container modules
411
411
@@ -500,9 +500,7 @@ To authenticate using a service principal, provide the service principal ID and
500
500
501
501
* For the password or client secret, specify the service principal password.
502
502
503
-
<br>
504
-
505
-
To create repository-scoped tokens, please follow [create a repository-scoped token](../container-registry/container-registry-repository-scoped-permissions.md).
503
+
To create repository-scoped tokens, follow [create a repository-scoped token](../container-registry/container-registry-repository-scoped-permissions.md).
506
504
507
505
To authenticate using repository-scoped tokens, provide the token name and password that you obtained after creating your repository-scoped token. Specify these credentials in the deployment manifest.
0 commit comments