Compartir a través de


Preparación para implementar la solución de IoT Edge en producción

Se aplica a:IoT Edge 1.5 checkmark IoT Edge 1.5

Important

IoT Edge 1.5 LTS es la versión compatible. IoT Edge 1.4 LTS alcanzó el final del ciclo de vida el 12 de noviembre de 2024. Si usa una versión anterior, consulte Update IoT Edge.

Cuando esté listo para tomar la solución de IoT Edge de desarrollo a producción, asegúrese de que está configurada para el rendimiento continuo.

No toda la información de este artículo es igualmente importante. Para ayudarle a priorizar, cada sección comienza con listas que dividen el trabajo en dos grupos: importante completar antes de ir a producción o útil para saberlo.

Configuración de dispositivos

Los dispositivos de IoT Edge pueden ser cualquier cosa, desde un Raspberry Pi hasta un portátil o una máquina virtual que se ejecuta en un servidor. Puede acceder al dispositivo físicamente o a través de una conexión virtual, o bien puede aislarse durante períodos prolongados. En cualquier caso, asegúrese de que está configurado para que funcione correctamente.

  • Important

    • Instalar certificados de producción
    • Disponer de un plan de administración de dispositivos
    • Use Moby como motor de contenedor. Si usa los snaps de Ubuntu Core, Canonical proporciona el snap de Docker y lo soporta para escenarios de producción.
  • Helpful

    • Elegir el protocolo ascendente

Instalar certificados de producción

Cada dispositivo Edge de IoT en producción necesita tener instalado un certificado de autoridad de certificación (CA) de dispositivo. Declare el certificado CA al entorno de ejecución de IoT Edge dentro del archivo de configuración. En el caso del desarrollo y las pruebas, el entorno de ejecución de IoT Edge crea certificados temporales si no declara certificados en el archivo de configuración. Pero estos certificados temporales expiran después de tres meses y no son seguros para escenarios de producción. En escenarios de producción, proporcione su propio certificado CA de Edge, ya sea de una entidad de certificación autofirmada o comprado a una entidad de certificación comercial.

Para comprender el rol del certificado de entidad de certificación perimetral, consulte Cómo Azure IoT Edge usa certificados.

Para obtener más información sobre cómo instalar certificados en un dispositivo IoT Edge y hacer referencia a ellos desde el archivo de configuración, consulte Administrar certificado en un dispositivo IoT Edge.

Disponer de un plan de administración de dispositivos

Antes de poner cualquier dispositivo en producción, tenga en cuenta cómo administrará las actualizaciones futuras. Para un dispositivo IoT Edge, la lista de componentes que se van a actualizar puede incluir:

  • Firmware del dispositivo
  • Bibliotecas de sistema operativo
  • Motor de contenedor, como Moby
  • IoT Edge
  • Certificados de Autoridad Certificadora

Device Update for IoT Hub es un servicio que permite implementar actualizaciones inalámbricas (OTA) para los dispositivos de IoT Edge.

Otras formas de actualizar IoT Edge requieren acceso físico o SSH al dispositivo IoT Edge. Para obtener más información, consulte Update the IoT Edge runtime. Para actualizar varios dispositivos, considere la posibilidad de agregar los pasos de actualización a un script o de usar una herramienta de automatización como Ansible.

Motor de contenedor

Se requiere un motor de contenedor para cualquier dispositivo IoT Edge. El motor moby se admite en producción. Si usa los snaps de Ubuntu Core, Canonical proporciona el snap de Docker y lo soporta para escenarios de producción. Otros motores de contenedor, como Docker, funcionan con IoT Edge y está bien usar estos motores para el desarrollo. El motor moby se puede redistribuir cuando se usa con Azure IoT Edge y Microsoft proporciona servicio para este motor.

Elegir el protocolo ascendente

Puede configurar el protocolo (que determina el puerto usado) para la comunicación ascendente a IoT Hub tanto para el agente de IoT Edge como para el centro de IoT Edge. El protocolo predeterminado es AMQP, pero es posible que desee cambiar ese protocolo en función de la configuración de red.

Ambos módulos en tiempo de ejecución tienen una UpstreamProtocol variable de entorno. Los valores válidos para esta variable son:

  • MQTT
  • AMQP
  • MQTTWS
  • AMQPWS

Configure la variable UpstreamProtocol para el agente de IoT Edge en el archivo de configuración en el propio dispositivo. Por ejemplo, si el dispositivo de IoT Edge está detrás de un servidor proxy que bloquea los puertos AMQP, es posible que tenga que configurar el agente de IoT Edge para usar AMQP a través de WebSocket (AMQPWS) para establecer la conexión inicial a IoT Hub.

Una vez que se conecte el dispositivo IoT Edge, continúe configurando la variable UpstreamProtocol para ambos módulos en tiempo de ejecución en futuras implementaciones. Por ejemplo, consulte Configure un dispositivo IoT Edge para comunicarse a través de un servidor proxy.

Deployment

  • Helpful
    • Sea coherente con el protocolo ascendente.
    • Configure el almacenamiento de host para los módulos del sistema.
    • Reduzca el espacio de memoria utilizado por el centro de IoT Edge.
    • Use imágenes de módulo correctas en manifiestos de implementación.
    • Tenga en cuenta los límites de tamaño de los gemelos al usar módulos personalizados.
    • Configure cómo se aplican las actualizaciones a los módulos.

Ser coherente con el protocolo ascendente

Si configura el agente de IoT Edge en el dispositivo IoT Edge para que use un protocolo diferente al predeterminado AMQP, declare el mismo protocolo en todas las implementaciones futuras. Por ejemplo, si su dispositivo IoT Edge está detrás de un servidor proxy que bloquea los puertos AMQP, probablemente configuró el dispositivo para conectarse mediante AMQP sobre WebSocket (AMQPWS). Al implementar módulos en el dispositivo, configure el mismo protocolo AMQPWS para el agente de IoT Edge y el centro de IoT Edge. De lo contrario, el AMQP predeterminado invalida la configuración y evita que se vuelva a conectar.

Solo necesita configurar la variable de entorno UpstreamProtocol para los módulos del agente de IoT Edge y del concentrador de IoT Edge. Los módulos adicionales heredan el protocolo establecido en los módulos en tiempo de ejecución.

Se proporciona un ejemplo de este proceso en Configure un dispositivo IoT Edge para comunicarse a través de un servidor proxy.

Configuración de almacenamiento de host para módulos del sistema

Los módulos de centro y agente de IoT Edge usan almacenamiento local para mantener el estado y habilitar la mensajería entre módulos, dispositivos y la nube. Para mejorar la confiabilidad y el rendimiento, configure los módulos del sistema para usar el almacenamiento en el sistema de archivos del host.

Para obtener más información, vea Almacenamiento de host para módulos del sistema.

Reducción del espacio de memoria usado por el centro de IoT Edge

Si va a implementar dispositivos restringidos con memoria limitada, configure el hub de IoT Edge para que se ejecute de manera más eficiente y use menos espacio en disco. Sin embargo, esta configuración limita el rendimiento del centro de IoT Edge, por lo que debe encontrar el equilibrio adecuado que funcione para la solución.

No optimizar el rendimiento en dispositivos restringidos

El centro de IoT Edge está optimizado para el rendimiento de forma predeterminada, por lo que intenta asignar grandes fragmentos de memoria. Esta configuración puede causar problemas de estabilidad en dispositivos más pequeños como el Raspberry Pi. Si implanta dispositivos con recursos restringidos, establezca la variable de entorno en OptimizeForPerformancefalse en el hub de IoT Edge.

Cuando configuras OptimizeForPerformance a true, el encabezado del protocolo MQTT usa PooledByteBufferAllocator, que tiene un mejor rendimiento, pero asigna más memoria. El asignador no funciona bien en sistemas operativos de 32 bits o en dispositivos con poca memoria. Además, cuando se optimiza para el rendimiento, RocksDb asigna más memoria para su rol como proveedor de almacenamiento local.

Para más información, consulte Problemas de estabilidad en dispositivos más pequeños.

Deshabilitar los protocolos no utilizados

Otra manera de optimizar el rendimiento del centro de IoT Edge y reducir su uso de memoria es desactivar los encabezados de protocolo para los protocolos que no use en la solución.

Establezca variables de entorno booleanas para el módulo de IoT Edge hub en los manifiestos de implementación para configurar cabezas de protocolo. Las tres variables son:

  • amqpSettings__enabled
  • mqttSettings__enabled
  • httpSettings__enabled

Las tres variables tienen dos caracteres de subrayado y se pueden establecer como verdadero o falso.

Reducir el tiempo de almacenamiento para los mensajes

El módulo del centro de IoT Edge almacena los mensajes temporalmente si no puede entregarlos a IoT Hub por cualquier motivo. Puede configurar cuánto tiempo el hub de IoT Edge retiene los mensajes no entregados antes de que expiren. Si tiene problemas de memoria en el dispositivo, reduzca el valor timeToLiveSecs en el módulo gemelo del centro de IoT Edge.

El valor predeterminado del parámetro timeToLiveSecs es de 7200 segundos, es decir, dos horas.

Uso de imágenes de módulo correctas en manifiestos de implementación

Si usa una imagen de módulo vacía o incorrecta, el agente de Edge reintenta para cargar la imagen. Este proceso de reintento genera tráfico adicional. Agregue las imágenes correctas al manifiesto de implementación para evitar generar tráfico innecesario.

No use versiones de depuración de las imágenes de módulo.

Al pasar de escenarios de prueba a escenarios de producción, recuerde quitar las configuraciones de depuración de los manifiestos de implementación. Compruebe que ninguna de las imágenes de módulo en los manifiestos de implementación tiene el sufijo .debug. Si agregó opciones de creación para exponer puertos en los módulos de depuración, quite también estas opciones.

Tener en cuenta los límites de tamaño de los gemelos al usar módulos personalizados

El manifiesto de implementación que contiene módulos personalizados forma parte del gemelo EdgeAgent. Revise la limitación del tamaño del módulo gemelo.

Si implementa un gran número de módulos, podría agotar este límite de tamaño de gemelo. Considere algunas mitigaciones comunes a este límite estricto:

  • Almacene cualquier configuración en el módulo gemelo personalizado, que tiene su propio límite.
  • Almacene alguna configuración que apunte a una ubicación sin espacio limitado (es decir, a un almacén de blobs).

Configuración del procedimiento para aplicar las actualizaciones a los módulos

Cuando actualiza una implementación, Edge Agent recibe la nueva configuración como una actualización gemela. Si la nueva configuración tiene imágenes de módulo nuevas o actualizadas, el agente de Edge procesará secuencialmente cada módulo de manera predeterminada:

  1. La imagen actualizada se descarga
  2. El módulo en ejecución se detiene
  3. Se inicia una nueva instancia de módulo
  4. Se procesa la siguiente actualización del módulo

En algunos casos, como cuando existen dependencias entre módulos, es posible que quiera descargar primero todas las imágenes de módulo actualizadas antes de reiniciar los módulos en ejecución. Puede configurar este comportamiento de actualización del módulo estableciendo una variable de entorno del agente de IoT Edge ModuleUpdateMode en el valor de cadena WaitForAllPulls. Para obtener más información, consulte Variables de entorno de IoT Edge.

"modulesContent": {
    "$edgeAgent": {
        "properties.desired": {
            ...
            "systemModules": {
                "edgeAgent": {
                    "env": {
                        "ModuleUpdateMode": {
                            "value": "WaitForAllPulls"
                        }
                    ...

Administración de contenedores

  • Important
    • Use etiquetas para administrar versiones.
    • Administrar volúmenes.
  • Helpful
    • Almacene contenedores de ejecución en su registro privado.
    • Configure la recolección de elementos no utilizados de imagen.

Usar etiquetas para administrar versiones

Una etiqueta es un concepto de Docker que se puede usar para distinguir entre versiones de contenedores de Docker. Las etiquetas son sufijos como 1.5 que van al final de un repositorio de contenedor. Por ejemplo, mcr.microsoft.com/azureiotedge-agent:1.5. Las etiquetas son mutables y pueden cambiar para que apunten a otro contenedor en cualquier momento, por lo que el equipo debe aceptar una convención que debe seguir a medida que actualice las imágenes del módulo avanzando.

Las etiquetas también le ayudan a aplicar actualizaciones en los dispositivos IoT Edge. Cuando inserte una versión actualizada de un módulo en el registro de contenedor, aumente la etiqueta. A continuación, inserte una nueva implementación a sus dispositivos con la etiqueta incrementada. El motor de contenedor reconoce la etiqueta incrementada como una nueva versión y extrae la versión más reciente del módulo hasta el dispositivo.

Etiquetas para el entorno de ejecución de IoT Edge

El agente de IoT Edge y las imágenes del centro de IoT Edge se etiquetan con la versión de IoT Edge a la que están asociadas. Hay dos maneras diferentes de usar etiquetas con las imágenes del entorno de ejecución:

  • Etiquetas graduales: use solo los dos primeros valores del número de versión para obtener la imagen más reciente que coincida con esos dígitos. Por ejemplo, la versión 1.5 se actualiza cada vez que hay una nueva versión para que apunte a la versión 1.5.x más reciente. Si el entorno de ejecución del contenedor en el dispositivo IoT Edge extrae la imagen de nuevo, los módulos en tiempo de ejecución se actualizan a la versión más reciente. Las implementaciones desde el portal de Azure utilizan de forma predeterminada implementaciones graduales. Este enfoque se sugiere con fines de desarrollo.

  • Etiquetas específicas: use los tres valores del número de versión para establecer explícitamente la versión de la imagen. Por ejemplo, 1.5.0 no cambia después de su lanzamiento inicial. Cuando esté listo para actualizar, declara un nuevo número de versión en el manifiesto de implementación. Este enfoque se recomienda para fines de producción.

Administración de volúmenes

IoT Edge no elimina volúmenes adjuntos a contenedores de módulos. Este comportamiento es por diseño, ya que permite conservar los datos entre instancias de contenedor, como escenarios de actualización. Sin embargo, si estos volúmenes no se usan, pueden provocar agotamiento del espacio en disco y errores de sistema posteriores. Si utiliza volúmenes de Docker en su escenario, use herramientas de Docker como docker volume prune y docker volume rm para eliminar los volúmenes no utilizados, especialmente en escenarios de producción.

Almacenar los contenedores del entorno de ejecución en el registro privado

Sabe cómo almacenar imágenes de contenedor para módulos de código personalizados en el registro de Azure privado, pero también puede usarlo para almacenar imágenes de contenedor públicas, como los módulos en tiempo de ejecución edgeAgent y edgeHub. Si tiene restricciones de firewall estrictas, es posible que tenga que almacenar estos contenedores en tiempo de ejecución en el registro privado porque normalmente se almacenan en Microsoft Container Registry (MCR).

En los pasos siguientes se muestra cómo extraer una imagen de Docker de edgeAgent y edgeHub en la máquina local, volver a etiquetarla, insertarla en el registro privado y, a continuación, actualizar el archivo de configuración para que los dispositivos sepan extraer la imagen del registro privado.

  1. Extraiga la imagen de Docker edgeAgent del registro de Microsoft. Actualice el número de versión si es necesario.

    # Pull edgeAgent image
    docker pull mcr.microsoft.com/azureiotedge-agent:1.5
    
    # Pull edgeHub image
    docker pull mcr.microsoft.com/azureiotedge-hub:1.5
    
  2. Enumere todas las imágenes de Docker, busque las imágenes edgeAgent y edgeHub y copie sus identificadores de imagen.

    docker images
    
  3. Vuelva a etiquetar las imágenes de edgeAgent y edgeHub. Reemplace los valores entre corchetes por los suyos propios.

    # Retag your edgeAgent image
    docker tag <my-image-id> <registry-name/server>/azureiotedge-agent:1.5
    
    # Retag your edgeHub image
    docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.5
    
  4. Inserte las imágenes edgeAgent y edgeHub en el registro privado. Reemplace el valor entre corchetes por el suyo propio.

    # Push your edgeAgent image to your private registry
    docker push <registry-name/server>/azureiotedge-agent:1.5
    
    # Push your edgeHub image to your private registry
    docker push <registry-name/server>/azureiotedge-hub:1.5
    
  5. Actualice las referencias de imagen en el archivo deployment.template.json del edgeAgent y edgeHub módulos del sistema, reemplazando mcr.microsoft.com por su propio "nombre de registro/servidor" para ambos módulos.

  6. Abra un editor de texto en su dispositivo IoT Edge para modificar el archivo de configuración de modo que tenga conocimiento de la imagen de su registro privado.

    sudo nano /etc/aziot/config.toml
    
  7. En el editor de texto, cambie los valores de la imagen en [agent.config]. Reemplace los valores entre corchetes por los suyos propios.

    [agent.config]
    image = "<registry-name/server>/azureiotedge-agent:1.5"
    
  8. Si el registro privado requiere autenticación, establezca los parámetros de autenticación en [agent.config.auth].

    [agent.config.auth]
    serveraddress = "<login-server>" # Almost always equivalent to <registry-name/server>
    username = "<username>"
    password = "<password>"
    
  9. Guarde los cambios y salga del editor de texto.

  10. Aplique el cambio de configuración de IoT Edge.

    sudo iotedge config apply
    

    El entorno de ejecución de IoT Edge se reinicia.

Para más información, consulte:

Configuración de la recolección de elementos no utilizados de imagen

La recolección de imágenes basura es una característica de IoT Edge v1.4 y versiones posteriores que limpia automáticamente las imágenes de Docker que los módulos de IoT Edge ya no utilizan. Solo elimina imágenes de Docker que el entorno de ejecución de IoT Edge extrae como parte de una implementación. La eliminación de imágenes de Docker no utilizadas ayuda a ahorrar espacio en disco.

El servicio aziot-edged, que es el componente host de IoT Edge, implementa esta característica y la habilita de forma predeterminada. El proceso de limpieza se ejecuta todos los días a medianoche (hora local del dispositivo) y quita las imágenes de Docker no usadas que se usaron hace siete días. Establezca los parámetros para controlar el comportamiento de limpieza en el archivo config.toml y en esta sección se explican. Si no especifica parámetros en el archivo de configuración, se aplican los valores predeterminados.

Por ejemplo, la siguiente sección config.toml muestra la configuración de la recolección de basura de imagen con valores predeterminados:

[image_garbage_collection]
enabled = true
cleanup_recurrence = "1d"
image_age_cleanup_threshold = "7d" 
cleanup_time = "00:00"

En la tabla siguiente se describen los parámetros de recolección de elementos no utilizados de imagen. Todos los parámetros son opcionales. Establézcalos individualmente para cambiar la configuración predeterminada.

Parameter Description Required Valor predeterminado
enabled Habilita la recolección de basura de imágenes. Puede deshabilitar la característica estableciendo este valor en false. Optional true
cleanup_recurrence Controla la frecuencia con la que se ejecuta la tarea de limpieza. Especifique este valor como un múltiplo de días y no puede ser inferior a un día.

Por ejemplo: 1d, 2d, 6d, etc.
Optional 1d
image_age_cleanup_threshold Defina el umbral mínimo de edad de las imágenes no utilizadas antes de considerarlas para su eliminación. Especifique este valor en días. Puede especificar 0d para limpiar las imágenes tan pronto como se eliminen de la implementación.

Las imágenes se consideran sin usar después de que se eliminan de la implementación.
Optional 7d
cleanup_time Hora del día en que se ejecuta la tarea de limpieza, según la hora local del dispositivo. Debe tener el formato HH:MM de 24 horas. Si el dispositivo no está en línea, la tarea de limpieza no se ejecuta. La tarea se ejecuta en la siguiente programación cleanup_time si el dispositivo está en línea en ese momento. Optional 00:00

Networking

  • Helpful
    • Revisión de la configuración de entrada y salida
    • Permitir conexiones desde dispositivos IoT Edge
    • Configurar la comunicación a través un servidor proxy
    • Establecer el servidor DNS en la configuración del motor de contenedor

Revisión de la configuración de entrada y salida

Siempre configuras los canales de comunicación entre Azure IoT Hub y IoT Edge para que sean salientes. Para la mayoría de los escenarios de IoT Edge, solo son necesarias tres conexiones. El motor de contenedor necesita conectarse con el registro (o registros) de contenedor que contiene las imágenes del módulo. El entorno de ejecución de IoT Edge debe conectarse con IoT Hub para recuperar la información de configuración del dispositivo y enviar mensajes y telemetría. Si usa el aprovisionamiento automático, IoT Edge debe conectarse al servicio Device Provisioning. Para más información, consulte Reglas de configuración de puertos y firewall.

Permitir conexiones desde dispositivos IoT Edge

Si la configuración de red requiere que permita explícitamente conexiones desde dispositivos IoT Edge, revise la siguiente lista de componentes de IoT Edge:

  • IoT Edge Agent abre una conexión AMQP o MQTT persistente a IoT Hub, posiblemente a través de WebSockets.
  • IoT Edge hub abre una única conexión AMQP persistente o varias conexiones MQTT a IoT Hub, posiblemente a través de WebSockets.
  • IoT Edge service realiza llamadas HTTPS intermitentes a IoT Hub.

En los tres casos, el nombre de dominio completo (FQDN) coincide con el patrón \*.azure-devices.net.

Registro de contenedores

El motor de contenedor realiza llamadas a registros de contenedor a través de HTTPS. Para recuperar las imágenes de contenedor en tiempo de ejecución de IoT Edge, el FQDN se mcr.microsoft.com. El motor de contenedor se conecta a otros registros tal y como se ha configurado en la implementación.

Esta lista de comprobación es un punto de partida para las reglas de firewall:

FQDN (* = carácter comodín) Puertos TCP salientes Usage
mcr.microsoft.com 443 Registro de contenedor de Microsoft
*.data.mcr.microsoft.com 443 Punto de conexión de datos que proporciona entrega de contenido.
*.cdn.azcr.io 443 Implementación de módulos desde Marketplace en dispositivos
global.azure-devices-provisioning.net 443 Acceso a Device Provisioning Service (opcional)
*.azurecr.io 443 Registros de contenedores personales y de terceros
*.blob.core.windows.net 443 Descargar diferenciales de imágenes de Azure Container Registry desde el almacenamiento de blobs
*.azure-devices.net 5671, 8883, 4431 Acceso al IoT Hub
*.docker.io 443 acceso Docker Hub (opcional)

1 Abra el puerto 8883 para MQTT seguro o el puerto 5671 para AMQP seguro. Si solo puede realizar conexiones a través del puerto 443, cualquiera de estos protocolos puede ejecutarse a través de un túnel WebSocket.

Sugerencia

Para una seguridad más estricta, reemplace los FQDN con caracteres comodín por puntos de conexión específicos siempre que sea posible. Por ejemplo, reemplace *.azure-devices.net con <your-hub-name>.azure-devices.net. Reemplace *.azurecr.io por <your-registry-name>.azurecr.io. Los equipos de seguridad de la empresa suelen rechazar reglas de caracteres comodín, por lo que debe planificar el uso de FQDN específicos en producción.

Puesto que la dirección IP de un centro de IoT puede cambiar sin previo aviso, use siempre el FQDN para la configuración de la lista de permitidos. Para obtener más información, consulte Introducción a la dirección IP del IoT Hub.

Algunas de estas reglas de firewall se heredan de Azure Container Registry. Para obtener más información, consulte Configurar reglas para acceder a un registro de contenedor de Azure detrás de un firewall.

Puede habilitar puntos de conexión de datos dedicados en el registro de contenedor de Azure para evitar la inclusión en la lista de permitidos comodín de la *.blob.core.windows.net FQDN. Para más información, consulte Habilitación de puntos de conexión de datos dedicados.

Note

Para proporcionar un FQDN coherente entre los puntos de conexión REST y de datos, a partir del 15 de junio de 2020, el punto de conexión de datos de Microsoft Container Registry cambia de *.cdn.mscr.io a *.data.mcr.microsoft.com.
Para obtener más información, consulte Configuración de reglas de firewall de cliente de Microsoft Container Registry.

Si no quiere configurar el firewall para permitir el acceso a los registros de contenedores públicos, puede almacenar las imágenes en el registro de contenedor privado, como se describe en Almacenar los contenedores del entorno de ejecución en el registro privado.

Azure IoT Identity Service

El IoT Identity Service proporciona servicios criptográficos y de aprovisionamiento para dispositivos Azure IoT. El servicio de identidad comprueba si la versión instalada es la versión más reciente. La comprobación usa los siguientes FQDN para comprobar la versión.

FQDN Puertos TCP salientes Usage
aka.ms 443 Dirección URL de vanidad que proporciona redireccionamiento al archivo de versión
raw.githubusercontent.com 443 El archivo de versión del servicio de identidad hospedado en GitHub

Configurar la comunicación a través un servidor proxy

Si está implementando los dispositivos en una red que utiliza un servidor proxy, deben comunicarse a través del proxy para acceder a IoT Hub y registros de contenedores. Para obtener más información, consulte Configurar un dispositivo IoT Edge para comunicarse a través de un servidor proxy.

Establecer el servidor DNS en la configuración del motor de contenedor

Especifique el servidor DNS para su entorno en la configuración del motor de contenedor. La configuración del servidor DNS se aplica a todos los módulos contenedores que inicia el motor de ejecución.

  1. En el directorio del /etc/docker dispositivo, edite el archivo daemon.json. Cree el archivo si no existe.

  2. Agregue la clave dns y establezca la dirección del servidor DNS en un servicio DNS accesible públicamente. Si el dispositivo perimetral no puede acceder a un servidor DNS público, use una dirección de servidor DNS accesible en la red. Por ejemplo:

    {
        "dns": ["1.1.1.1"]
    }
    

    En el caso de las redes corporativas o privadas que bloquean dns externo, use el servidor DNS interno en su lugar:

    {
        "dns": ["10.0.0.53"]
    }
    

Administración de soluciones

  • Helpful
    • Configurar los registros y diagnósticos
    • Configurar el controlador de registro predeterminado
    • Considerar la posibilidad de pruebas y canalizaciones de CI/CD

Configurar los registros y diagnósticos

En Linux, el demonio de IoT Edge usa diarios como controlador de registro predeterminado. Usa la herramienta de línea de comandos journalctl para consultar los registros del servicio de sistema.

A partir de la versión 1.2, IoT Edge se basa en varios demonios. Aunque puede consultar individualmente los registros de cada demonio mediante journalctl, use los iotedge system comandos para consultar los registros combinados.

  • Comando iotedge consolidado:

    sudo iotedge system logs
    
  • Comando journalctl equivalente:

    journalctl -u aziot-edge -u aziot-identityd -u aziot-keyd -u aziot-certd -u aziot-tpmd
    

Al probar una implementación de IoT Edge, normalmente se accede a los dispositivos para recuperar registros y solucionar problemas. En un escenario de implementación, es posible que no tenga esa opción. Considere cómo recopilará información sobre sus dispositivos que están en producción. Una opción es usar un módulo de registro que recopila información de otros módulos y la envía a la nube. Por ejemplo, use logspout-loganalytics o diseñe el suyo propio.

Configurar el controlador de registro predeterminado

De manera predeterminada, el motor de contenedor de Moby no establece límites de tamaño de registro de contenedor. Con el tiempo, esta configuración predeterminada puede hacer que el dispositivo se rellene con registros y se agote el espacio en disco. Configure el motor del contenedor para usar el controlador de registro local como mecanismo de registro. El local controlador de registro ofrece un límite de tamaño de registro predeterminado, realiza la rotación de registros de forma predeterminada y usa un formato de archivo más eficaz, lo que ayuda a evitar el agotamiento del espacio en disco. También puede usar diferentes controladores de registro y establecer diferentes límites de tamaño en función de sus necesidades.

Opción: configure el controlador de registro predeterminado para todos los módulos de contenedor

Establezca el motor de contenedor para que use un controlador de registro específico estableciendo el valor de log driver en el nombre del controlador de registro en el daemon.json archivo. En el ejemplo siguiente se establece el controlador de registro predeterminado en el controlador de registro local (recomendado).

{
    "log-driver": "local"
}

También puede configurar las claves log-opts para usar los valores adecuados en el archivo daemon.json. En el ejemplo siguiente se establece el controlador de registro en local y se establecen las opciones max-size y max-file.

{
    "log-driver": "local",
    "log-opts": {
        "max-size": "10m",
        "max-file": "3"
    }
}

Agregue o anexe esta información a un archivo denominado daemon.json y colóquela en la siguiente ubicación:

  • /etc/docker/

Reinicie el motor de contenedores para que se apliquen los cambios.

Opción: Ajuste de la configuración de registro para cada módulo de contenedor

Establezca estas opciones en createOptions de cada módulo. Por ejemplo:

"createOptions": {
    "HostConfig": {
        "LogConfig": {
            "Type": "local",
            "Config": {
                "max-size": "10m",
                "max-file": "3"
            }
        }
    }
}

Opciones adicionales en sistemas Linux

  • Configure el motor del contenedor para enviar registros al systemd de estableciendo journald como el controlador de registro predeterminado.

  • Quite periódicamente los registros antiguos del dispositivo mediante la instalación de una herramienta de logrotate. Utilice la siguiente especificación de archivo:

    /var/lib/docker/containers/*/*-json.log{
         copytruncate
         daily
         rotate7
         delaycompress
         compress
         notifempty
         missingok
    }
    

Considerar la posibilidad de pruebas y canalizaciones de CI/CD

Para la implementación más eficaz de IoT Edge, integre su implementación de producción en las pruebas y en las pipelines de CI/CD. Azure IoT Edge admite varias plataformas de CI/CD, incluida la Azure DevOps. Para obtener más información, consulte Integración continua y despliegue continuo en Azure IoT Edge.

Consideraciones de seguridad

  • Important
    • Administre el acceso al registro de contenedor.
    • Limite el acceso de contenedor a los recursos del host.

Administrar el acceso al registro de contenedor

Antes de implementar módulos en dispositivos IoT Edge de producción, asegúrese de controlar el acceso al registro de contenedor para que los externos no puedan acceder a las imágenes de contenedor ni cambiarlas. Use un registro de contenedores privado para administrar las imágenes de contenedor.

En los tutoriales y otra documentación, se usan las mismas credenciales del registro de contenedor en el dispositivo IoT Edge que en la máquina de desarrollo. Estas instrucciones le ayudan a configurar entornos de desarrollo y pruebas más fácilmente y no son para su uso en producción.

Para obtener acceso más seguro al registro, elija entre varias opciones de autenticación. El uso de un principal de servicio de Active Directory es un método popular y recomendado para que las aplicaciones o servicios extraigan imágenes de contenedor automáticamente y de manera desatendida, como lo hacen los dispositivos IoT Edge. También puede usar tokens con ámbito de repositorio, que le permiten crear identidades de larga o corta duración que solo existen en el Registro de Contenedores de Azure donde los crea y tienen acceso al nivel de repositorio.

Para crear una entidad de servicio, ejecute los dos scripts descritos en Creación de una entidad de servicio. Estos scripts realizan los pasos siguientes:

  • El primer script crea la entidad de servicio. Muestra el identificador de la entidad de servicio y la contraseña de la entidad de servicio. Almacene estos valores de forma segura en los registros.

  • El segundo script crea asignaciones de roles para conceder a la entidad de servicio. Ejecútelo posteriormente si es necesario. Use el rol de usuario acrPull para el role parámetro . Para obtener una lista de roles, consulte Roles y permisos de Azure Container Registry.

Para autenticarse mediante una entidad de servicio, proporcione el identificador de la entidad de servicio y las credenciales de contraseña del primer script del manifiesto de implementación.

  • Como nombre de usuario o id. de cliente, especifique el identificador de la entidad de servicio.

  • Como contraseña o secreto de cliente, especifique la contraseña de la entidad de servicio.

Para crear tokens con ámbito de repositorio, siga crear un token con ámbito de repositorio.

Para autenticarse mediante tokens con ámbito de repositorio, proporcione el nombre del token y las credenciales de contraseña que obtenga después de crear el token con ámbito de repositorio en el manifiesto de implementación.

  • Para el nombre de usuario, especifique el nombre de usuario del token.

  • Para la contraseña, especifique una de las contraseñas del token.

Note

Después de implementar una autenticación de seguridad mejorada, deshabilite la configuración del usuario administrador para que el nombre de usuario y la contraseña predeterminados no estén disponibles. Puede encontrar la configuración del registro de contenedor en el portal de Azure, en Settings, seleccione Access Keys.

Limitar el acceso del contenedor a los recursos de host

Para equilibrar los recursos de host compartidos entre módulos, establezca límites en el uso de recursos para cada módulo. Estos límites aseguran que un módulo no puede usar demasiada memoria o CPU y evitar que otros procesos se ejecuten en el dispositivo. De forma predeterminada, la plataforma IoT Edge no limita los recursos de los módulos porque necesita probar para saber cuánto recurso necesita ejecutar un módulo correctamente.

Docker le permite limitar los recursos, como la memoria y el uso de CPU. Para obtener más información, vea Opciones del entorno de ejecución con memoria, CPU y GPU.

Puede aplicar estas restricciones a módulos individuales mediante el uso de opciones de creación en manifiestos de implementación. Para obtener más información, consulte Cómo configurar las opciones de creación de contenedores para los módulos de IoT Edge.

Por ejemplo, para limitar un módulo a 256 MB de memoria y 1 núcleo de CPU:

"createOptions": {
    "HostConfig": {
        "Memory": 268435456,
        "NanoCPUs": 1000000000
    }
}

Pasos siguientes