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/deploy-confidential-applications.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ author: PatAltimore
5
5
ms.service: iot-edge
6
6
services: iot-edge
7
7
ms.topic: conceptual
8
-
ms.date: 01/27/2021
8
+
ms.date: 04/08/2024
9
9
ms.author: patricka
10
10
---
11
11
@@ -15,7 +15,7 @@ ms.author: patricka
15
15
16
16
Azure IoT Edge supports confidential applications that run within secure enclaves on the device. Encryption provides security for data while in transit or at rest, but enclaves provide security for data and workloads while in use. IoT Edge supports Open Enclave as a standard for developing confidential applications.
17
17
18
-
Security has always been an important focus of the Internet of Things (IoT) because often IoT devices are often out in the world rather than secured inside a private facility. This exposure puts devices at risk for tampering and forgery because they are physically accessible to bad actors. IoT Edge devices have even more need for trust and integrity because they allow for sensitive workloads to be run at the edge. Unlike common sensors and actuators, these intelligent edge devices are potentially exposing sensitive workloads that were formerly only run within protected cloud or on-premises environments.
18
+
Security is an important focus of the Internet of Things (IoT) because often IoT devices are often out in the world rather than secured inside a private facility. This exposure puts devices at risk for tampering and forgery because they are physically accessible to bad actors. IoT Edge devices have even more need for trust and integrity because they allow for sensitive workloads to be run at the edge. Unlike common sensors and actuators, these intelligent edge devices are potentially exposing sensitive workloads that were formerly only run within protected cloud or on-premises environments.
19
19
20
20
The [IoT Edge security manager](iot-edge-security-manager.md) addresses one piece of the confidential computing challenge. The security manager uses a hardware security module (HSM) to protect the identity workloads and ongoing processes of an IoT Edge device.
21
21
@@ -27,7 +27,7 @@ Confidential applications are encrypted in transit and at rest, and only decrypt
27
27
28
28
The developer creates the confidential application and packages it as an IoT Edge module. The application is encrypted before being pushed to the container registry. The application remains encrypted throughout the IoT Edge deployment process until the module is started on the IoT Edge device. Once the confidential application is within the device's TEE, it is decrypted and can begin executing.
29
29
30
-
:::image type="content" source="./media/deploy-confidential-applications/confidential-applications-encrypted.png" alt-text="Diagram that show confidential applications are encrypted within IoT Edge modules until deployed into the secure enclave.":::
30
+
:::image type="content" source="./media/deploy-confidential-applications/confidential-applications-encrypted.png" alt-text="Diagram that shows confidential applications are encrypted within IoT Edge modules until deployed into the secure enclave.":::
31
31
32
32
Confidential applications on IoT Edge are a logical extension of [Azure confidential computing](../confidential-computing/overview.md). Workloads that run within secure enclaves in the cloud can also be deployed to run within secure enclaves at the edge.
33
33
@@ -44,7 +44,7 @@ The Open Enclave repository also includes samples to help developers get started
44
44
45
45
## Hardware
46
46
47
-
Currently, [TrustBox by Scalys](https://scalys.com/) is the only device supported with manufacturer service agreements for deploying confidential applications as IoT Edge modules. The TrustBox is built on The TrustBox Edge and TrustBox EdgeXL devices both come pre-loaded with the Open Enclave SDK and Azure IoT Edge.
47
+
Currently, [TrustBox by Scalys](https://scalys.com/) is the only device supported with manufacturer service agreements for deploying confidential applications as IoT Edge modules. The TrustBox is built on The TrustBox Edge and TrustBox EdgeXL devices both come preloaded with the Open Enclave SDK and Azure IoT Edge.
48
48
49
49
For more information, see [Getting started with Open Enclave for the Scalys TrustBox](https://aka.ms/scalys-trustbox-edge-get-started).
50
50
@@ -54,4 +54,4 @@ When you're ready to develop and deploy your confidential application, the [Micr
54
54
55
55
## Next steps
56
56
57
-
Learn how to start developing confidential applications as IoT Edge modules with the [Open Enclave extension for Visual Studio Code](https://github.com/openenclave/openenclave/tree/master/devex/vscode-extension)
57
+
Learn how to start developing confidential applications as IoT Edge modules with the [Open Enclave extension for Visual Studio Code](https://github.com/openenclave/openenclave/tree/master/devex/vscode-extension).
The IoT Edge runtime components, IoT Edge hub and IoT Edge agent, produce built-in metrics in the [Prometheus exposition format](https://prometheus.io/docs/instrumenting/exposition_formats/). Access these metrics remotely to monitor and understand the health of an IoT Edge device.
18
+
The IoT Edge runtime components, IoT Edge hub, and IoT Edge agent, produce built-in metrics in the [Prometheus exposition format](https://prometheus.io/docs/instrumenting/exposition_formats/). Access these metrics remotely to monitor and understand the health of an IoT Edge device.
19
19
20
-
You can use your own solution to access these metrics. Or, you can use the [metrics-collector module](https://azuremarketplace.microsoft.com/marketplace/apps/microsoft_iot_edge.metrics-collector) which handles collecting the built-in metrics and sending them to Azure Monitor or Azure IoT Hub. For more information, see [Collect and transport metrics](how-to-collect-and-transport-metrics.md).
20
+
You can use your own solution to access these metrics. Or, you can use the [metrics-collector module](https://azuremarketplace.microsoft.com/marketplace/apps/microsoft_iot_edge.metrics-collector), which handles collecting the built-in metrics and sending them to Azure Monitor or Azure IoT Hub. For more information, see [Collect and transport metrics](how-to-collect-and-transport-metrics.md).
21
21
22
-
As of release 1.0.10, metrics are automatically exposed by default on **port 9600** of the **edgeHub** and **edgeAgent** modules (`http://edgeHub:9600/metrics` and `http://edgeAgent:9600/metrics`). They aren't port mapped to the host by default.
22
+
Metrics are automatically exposed by default on **port 9600** of the **edgeHub** and **edgeAgent** modules (`http://edgeHub:9600/metrics` and `http://edgeAgent:9600/metrics`). They aren't port mapped to the host by default.
23
23
24
24
Access metrics from the host by exposing and mapping the metrics port from the module's `createOptions`. The example below maps the default metrics port to port 9601 on the host:
25
25
@@ -55,7 +55,7 @@ Metrics contain tags to help identify the nature of the metric being collected.
55
55
|-|-|
56
56
| iothub | The hub the device is talking to |
57
57
| edge_device | The ID of the current device |
58
-
| instance_number | A GUID representing the current runtime. On restart, all metrics will be reset. This GUID makes it easier to reconcile restarts. |
58
+
| instance_number | A GUID representing the current runtime. On restart, all metrics are reset. This GUID makes it easier to reconcile restarts. |
59
59
60
60
In the Prometheus exposition format, there are four core metric types: counter, gauge, histogram, and summary. For more information about the different metric types, see the [Prometheus metric types documentation](https://prometheus.io/docs/concepts/metric_types/).
61
61
@@ -69,7 +69,7 @@ The **edgeHub** module produces the following metrics:
69
69
|`edgehub_messages_received_total`|`route_output` (output that sent message)<br> `id`| Type: counter<br> Total number of messages received from clients |
70
70
|`edgehub_messages_sent_total`|`from` (message source)<br> `to` (message destination)<br>`from_route_output`<br> `to_route_input` (message destination input)<br> `priority` (message priority to destination) | Type: counter<br> Total number of messages sent to clients or upstream<br> `to_route_input` is empty when `to` is $upstream |
|`edgehub_message_size_bytes`|`id`<br> | Type: summary<br> Message size from clients<br> Values may be reported as `NaN` if no new measurements are reported for a certain period of time (currently 10 minutes); for `summary` type, corresponding `_count` and `_sum` counters will be emitted. |
72
+
|`edgehub_message_size_bytes`|`id`<br> | Type: summary<br> Message size from clients<br> Values may be reported as `NaN` if no new measurements are reported for a certain period of time (currently 10 minutes); for `summary` type, corresponding `_count` and `_sum` counters are emitted. |
73
73
|`edgehub_gettwin_duration_seconds`|`source` <br> `id`| Type: summary<br> Time taken for get twin operations |
74
74
|`edgehub_message_send_duration_seconds`|`from`<br> `to`<br> `from_route_output`<br> `to_route_input`| Type: summary<br> Time taken to send a message |
75
75
|`edgehub_message_process_duration_seconds`|`from` <br> `to` <br> `priority`| Type: summary<br> Time taken to process a message from the queue |
@@ -92,7 +92,7 @@ The **edgeAgent** module produces the following metrics:
92
92
|`edgeAgent_total_time_expected_running_seconds`|`module_name`| Type: gauge<br> The amount of time the module was specified in the deployment |
93
93
|`edgeAgent_module_start_total`|`module_name`, `module_version`| Type: counter<br> Number of times edgeAgent asked docker to start the module |
94
94
|`edgeAgent_module_stop_total`|`module_name`, `module_version`| Type: counter<br> Number of times edgeAgent asked docker to stop the module |
95
-
|`edgeAgent_command_latency_seconds`|`command`| Type: gauge<br> How long it took docker to execute the given command. Possible commands are: create, update, remove, start, stop, restart |
95
+
|`edgeAgent_command_latency_seconds`|`command`| Type: gauge<br> How long it took docker to execute the given command. Possible commands are: create, update, remove, start, stop, and restart |
96
96
|`edgeAgent_iothub_syncs_total`|| Type: counter<br> Number of times edgeAgent attempted to sync its twin with iotHub, both successful and unsuccessful. This number includes both Agent requesting a twin and Hub notifying of a twin update |
97
97
|`edgeAgent_unsuccessful_iothub_syncs_total`|| Type: counter<br> Number of times edgeAgent failed to sync its twin with iotHub. |
98
98
|`edgeAgent_deployment_time_seconds`|| Type: counter<br> The amount of time it took to complete a new deployment after receiving a change. |
Copy file name to clipboardExpand all lines: articles/iot-edge/how-to-continuous-integration-continuous-deployment.md
+4-4Lines changed: 4 additions & 4 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: Continuous integration and continuous deployment to Azure IoT Edge devices - Azure IoT Edge
2
+
title: Continuous integration and continuous deployment to Azure IoT Edge devices
3
3
description: Set up continuous integration and continuous deployment using YAML - Azure IoT Edge with Azure DevOps, Azure Pipelines
4
4
author: PatAltimore
5
5
6
6
ms.author: patricka
7
-
ms.date: 08/20/2019
7
+
ms.date: 04/08/2024
8
8
ms.topic: conceptual
9
9
ms.service: iot-edge
10
10
services: iot-edge
@@ -49,7 +49,7 @@ Unless otherwise specified, the procedures in this article do not explore all th
49
49
* A container registry where you can push module images. You can use [Azure Container Registry](../container-registry/index.yml) or a third-party registry.
50
50
* An active Azure [IoT hub](../iot-hub/iot-hub-create-through-portal.md) with at least two IoT Edge devices for testing the separate test and production deployment stages. You can follow the quickstart articles to create an IoT Edge device on [Linux](quickstart-linux.md) or [Windows](quickstart.md)
51
51
52
-
For more information about using Azure Repos, see [Share your code with Visual Studio and Azure Repos](/azure/devops/repos/git/share-your-code-in-git-vs)
52
+
For more information about using Azure Repos, see [Share your code with Visual Studio and Azure Repos](/azure/devops/repos/git/share-your-code-in-git-vs).
53
53
54
54
## Create a build pipeline for continuous integration
55
55
@@ -131,7 +131,7 @@ In this section, you create a new build pipeline. You configure the pipeline to
131
131
132
132
9. Select **Save** from the **Save and run** dropdown in the top right.
133
133
134
-
10. The trigger for continuous integration is enabled by default for your YAML pipeline. If you wish to edit these settings, select your pipeline and click**Edit** in the top right. Select **More actions** next to the **Run** button in the top right and go to **Triggers**. **Continuous integration** shows as enabled under your pipeline's name. If you wish to see the details for the trigger, check the **Override the YAML continuous integration trigger from here** box.
134
+
10. The trigger for continuous integration is enabled by default for your YAML pipeline. If you wish to edit these settings, select your pipeline and select**Edit** in the top right. Select **More actions** next to the **Run** button in the top right and go to **Triggers**. **Continuous integration** shows as enabled under your pipeline's name. If you wish to see the details for the trigger, check the **Override the YAML continuous integration trigger from here** box.
135
135
136
136
:::image type="content" source="./media/how-to-continuous-integration-continuous-deployment/check-trigger-settings.png" alt-text="Screenshot showing how to review your pipeline's trigger settings from the Triggers menu under More actions.":::
@@ -53,7 +53,7 @@ By default, this view shows the health of devices associated with the current Io
53
53
54
54
Use the **Settings** tab to adjust the various thresholds to categorize the device as Healthy or Unhealthy.
55
55
56
-
Click the **Details** button to see the device list with a snapshot of aggregated, primary metrics. Click the link in the **Status** column to view the trend of an individual device's health metrics or the device name to view its detailed metrics.
56
+
Select the **Details** button to see the device list with a snapshot of aggregated, primary metrics. Select the link in the **Status** column to view the trend of an individual device's health metrics or the device name to view its detailed metrics.
57
57
58
58
## Device details workbook
59
59
@@ -73,7 +73,7 @@ The device details workbook also integrates with the IoT Edge portal-based troub
73
73
74
74
The **Messaging** view includes three subsections: routing details, a routing graph, and messaging health. Drag and let go on any time chart to adjust the global time range to the selected range.
75
75
76
-
The **Routing** section shows message flow between sending modules and receiving modules. It presents information such as message count, rate, and number of connected clients. Click on a sender or receiver to drill in further. Clicking a sender shows the latency trend chart experienced by the sender and number of messages it sent. Clicking a receiver shows the queue length trend for the receiver and number of messages it received.
76
+
The **Routing** section shows message flow between sending modules and receiving modules. It presents information such as message count, rate, and number of connected clients. Select a sender or receiver to drill in further. Clicking a sender shows the latency trend chart experienced by the sender and number of messages it sent. Clicking a receiver shows the queue length trend for the receiver and number of messages it received.
77
77
78
78
The **Graph** section shows a visual representation of message flow between modules. Drag and zoom to adjust the graph.
79
79
@@ -114,7 +114,7 @@ See the generated alerts from [pre-created alert rules](how-to-create-alerts.md)
114
114
115
115
:::image type="content" source="./media/how-to-explore-curated-visualizations/how-to-explore-alerts.gif" alt-text="The alerts section of the fleet view workbook." lightbox="./media/how-to-explore-curated-visualizations/how-to-explore-alerts.gif":::
116
116
117
-
Click on a severity row to see alerts details. The **Alert rule** link takes you to the alert context and the **Device** link opens the detailed metrics workbook. When opened from this view, the device details workbook is automatically adjusted to the time range around when the alert fired.
117
+
Select a severity row to see alerts details. The **Alert rule** link takes you to the alert context and the **Device** link opens the detailed metrics workbook. When opened from this view, the device details workbook is automatically adjusted to the time range around when the alert fired.
![prmerger-automator[bot]](https://avatars.githubusercontent.com/u/22479449?v=4&size=40){kind=avatar}
0 commit comments