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

Se aplica a: IoT Edge 1.5 IoT Edge 1.4

Importante

IoT Edge 1.5 LTS e IoT Edge 1.4 LTS son versiones compatibles. IoT Edge 1.4 LTS finaliza el ciclo de vida el 12 de noviembre de 2024. Si está usando una versión anterior, consulte Actualización de IoT Edge.

Cuando esté listo para llevar su solución IoT Edge desde el desarrollo hasta la producción, asegúrese de que está configurada para un rendimiento continuo.

La información proporcionada en este artículo no es la misma para todo. Para ayudarle con la prioridad, cada sección comienza con listas que dividen el trabajo en dos secciones: importante para completar antes de pasar a producción, o útil para que se sepa.

Configuración del dispositivo

Los dispositivos IoT Edge pueden ser cualquier cosa, desde un dispositivo Raspberry Pi a un portátil o una máquina virtual que se ejecuta en un servidor. Es posible que tenga acceso al dispositivo ya sea físicamente o mediante una conexión virtual, o que esté aislado durante períodos prolongados de tiempo. En cualquier caso, debe asegurarse de que está configurado para funcionar correctamente.

• Importante

  • Instalar certificados de producción
  • Disponer de un plan de administración de dispositivos
  • Usar Moby como motor de contenedor. Si usa acoples de Ubuntu Core, el acople de Docker se atenderá mediante Canonical y se admitirá en escenarios de producción.

• Útil

  • Elegir el protocolo ascendente

Instalar certificados de producción

Cada dispositivo IoT Edge en producción necesita un certificado de la entidad de certificación (CA) instalado en él. Este certificado de entidad de certificación se declara en el entorno de ejecución de Azure IoT Edge en el archivo de configuración. En escenarios de desarrollo y prueba, el entorno de ejecución de IoT Edge crea certificados temporales si no se declara ningún certificado en el archivo de configuración. Sin embargo, estos certificados temporales expiran después de tres meses y no son seguros para escenarios de producción. Para escenarios de producción, debe proporcionar su propio certificado CA de Edge, ya sea de una autoridad de certificación autofirmada o comprado a una autoridad de certificación comercial.

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

Para más información sobre cómo instalar certificados en un dispositivo IoT Edge y hacerles referencia desde el archivo de configuración, consulte Administración de certificados en un dispositivo IoT Edge.

Disponer de un plan de administración de dispositivos

Antes de poner cualquier dispositivo en producción, debe saber cómo va a 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 entidad de certificación

Device Update for IoT Hub es un servicio que permite implementar actualizaciones por vía inalámbrica (OTA) para los dispositivos de IoT.

Los métodos alternativos para actualizar IoT Edge requieren el acceso físico o SSH al dispositivo IoT Edge. Para obtener más información, vea Actualización del entorno de ejecución de IoT Edge. 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

Tener un motor de contenedor es un requisito previo para cualquier dispositivo IoT Edge. El motor moby se admite en producción. Si usa acoples de Ubuntu Core, el acople de Docker se atenderá mediante Canonical y se admitirá en escenarios de producción. Otros motores de contenedor, como Docker, funcionan con IoT Edge y es correcto 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 con 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 cambiarlo en función de la configuración de la red.

Los dos módulos del entorno de ejecución tienen la variable de entorno UpstreamProtocol. Los valores válidos para la variable son:

• MQTT
• AMQP
• MQTTWS
• AMQPWS

Configure la variable UpstreamProtocol para el agente de IoT Edge en el archivo de configuración del propio dispositivo. Por ejemplo, si el dispositivo IoT Edge está detrás de un servidor proxy que bloquea los puertos AMQP, puede que necesite configurar el agente de IoT Edge para que utilice AMQP sobre WebSocket (AMQPWS) para establecer la conexión inicial con IoT Hub.

Una vez que el dispositivo IoT Edge se conecte, asegúrese de continuar con la configuración de la variable UpstreamProtocol para ambos módulos del entorno de ejecución en futuras implementaciones. Un ejemplo de este proceso se muestra en Configuración de un dispositivo de IoT Edge para que se comunique a través de un servidor proxy.

Implementación

• Útil
  • Ser coherente con el protocolo ascendente
  • Configuración de almacenamiento de host para módulos del sistema
  • Reducir el espacio de memoria utilizado por el centro de IoT Edge
  • Uso de imágenes de módulo correctas en manifiestos de implementación
  • Tener en cuenta los límites de tamaño de los gemelos al usar módulos personalizados
  • Configuración del procedimiento para aplicar las actualizaciones a los módulos

Ser coherente con el protocolo ascendente

Si ha configurado el agente de IoT Edge en su dispositivo IoT Edge para utilizar un protocolo diferente al AMQP predeterminado, debe declarar el mismo protocolo en todas las futuras implementaciones. Por ejemplo, si el dispositivo IoT Edge está detrás de un servidor proxy que bloquea los puertos AMQP, probablemente ha configurado el dispositivo para que se conecte a través de 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, o bien, el AMQP predeterminado invalida la configuración y evita que se conecte de nuevo.

Solo tiene que configurar la variable de entorno UpstreamProtocol para el agente de IoT Edge y el centro de IoT Edge. Cualquier módulo adicional adopta cualquier protocolo que se establezca en los módulos del entorno de ejecución.

Un ejemplo de este proceso se muestra en Configuración de un dispositivo de IoT Edge para que se comunique a través de un servidor proxy.

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

Los módulos del agente y del centro de IoT Edge usan almacenamiento local para mantener el estado y permiten 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.

Reducir el espacio de memoria utilizado por el centro de IoT Edge

Si va a implementar dispositivos restringidos con memoria disponible limitada, puede configurar el centro de IoT Edge para que se ejecute con una capacidad más optimizada y utilice menos espacio en disco. Sin embargo, estas configuraciones limitan el rendimiento del centro de IoT Edge, por lo que debe encontrar el equilibrio adecuado para su solución.

No optimizar el rendimiento en dispositivos restringidos

El centro de IoT Edge está optimizado para el rendimiento de manera predeterminada e 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 va a implementar dispositivos con recursos limitados, es posible que quiera establecer la variable de entorno OptimizeForPerformance en false en el centro de IoT Edge.

Cuando OptimizeForPerformance se establece en 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 forma de optimizar el rendimiento del centro de IoT Edge y reducir su uso de memoria es desactivar los encabezados del protocolo de cualquier protocolo que no utilicen su solución.

Los encabezados del protocolo se configuran mediante el establecimiento de variables de entorno booleanas para el módulo del centro de IoT Edge en los manifiestos de implementación. 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 mensajes temporalmente si no se pueden entregar a IoT Hub por cualquier razón. Puede configurar el tiempo que el centro de IoT Edge conserva los mensajes no entregados antes de dejarlos expirar. Si tiene problemas de memoria en el dispositivo, puede reducir 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 se usa una imagen de módulo vacía o incorrecta, el agente de Edge vuelve a intentar cargar la imagen, lo que hace que se genere 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 se actualiza una implementación, el agente de Edge 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, por ejemplo, cuando existen dependencias entre módulos, puede ser conveniente descargar primero todas las imágenes de módulo actualizadas antes de reiniciar cualquier módulo en ejecución. Este comportamiento de actualización de módulo se puede configurar estableciendo una variable ModuleUpdateMode de entorno del Agente de IoT Edge en el valor WaitForAllPullsde cadena. 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

• Importante
  • Usar etiquetas para administrar versiones
  • Administración de volúmenes
• Útil
  • Almacenar los contenedores del entorno de ejecución en el registro privado
  • Configuración de la recolección de elementos no utilizados de imagen

Usar etiquetas para administrar versiones

Una etiqueta es un concepto de Docker que puede utilizar para distinguir entre versiones de contenedores 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 cambiarse para que apunten a otro contenedor en cualquier momento, por lo que su equipo debe acordar una convención a seguir a medida que actualice las imágenes de sus módulos.

Las etiquetas también le ayudan a aplicar las actualizaciones en sus 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 Azure IoT Edge

Las imágenes del Agente de IoT Edge y 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, se actualizan los módulos del entorno de ejecución a la versión más reciente. Las implementaciones de Azure Portal tienen como valor predeterminado las etiquetas 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 cambiará después de su lanzamiento inicial. Puede declarar un nuevo número de versión del manifiesto de implementación cuando esté listo para actualizar. Este enfoque se sugiere con fines de producción.

Administración de volúmenes

IoT Edge no quita volúmenes conectados 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 se dejan sin usar, puede provocar el agotamiento del espacio en disco y los errores del sistema posteriores. Si usa volúmenes de Docker en su escenario, le recomendamos que use herramientas de Docker como eliminación de volúmenes de Docker o docker volume rm para quitar los volúmenes sin usar, 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 privado de Azure, pero también puede usarlo para almacenar imágenes de contenedor públicas, como edgeAgent y edgeHub módulos en tiempo de ejecución. Es posible que sea necesario hacerlo si tiene restricciones de firewall estrictas, ya que estos contenedores en tiempo de ejecución se almacenan en Microsoft Container Registry (MCR).

En los pasos siguientes se muestra cómo extraer una imagen de Docker de edgeAgent y edgeHub a 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 el dispositivo IoT Edge para cambiar el archivo de configuración para que sepa sobre la imagen del 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, vea:

• Configuración del agente de IoT Edge
• Agente de Azure IoT Edge
• Centro de Azure IoT Edge

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

La recolección de elementos no utilizados de imagen es una característica de IoT Edge v1.4 y versiones posteriores para limpiar de manera automática imágenes de Docker que ya no usan los módulos de IoT Edge. Solo elimina las imágenes de Docker que ha extraído el entorno de ejecución de Azure IoT Edge como parte de una implementación. La eliminación de imágenes de Docker no utilizadas ayuda a ahorrar espacio en disco.

La característica se implementa en el componente de host de IoT Edge y el servicio aziot-edged, y está habilitada de manera predeterminada. La limpieza se realiza todos los días a medianoche (hora local del dispositivo) y quita las imágenes de Docker no utilizadas que se usaron hace siete días. Los parámetros para controlar el comportamiento de limpieza se establecen en config.toml y se explican más adelante en esta sección. Si no se especifican parámetros en el archivo de configuración, se aplicarán los valores predeterminados.

Por ejemplo, a continuación se muestra la sección de recolección de elementos no utilizados de imagen config.toml 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 y se pueden establecer de manera individual para cambiar la configuración predeterminada.

Parámetro	Descripción	Obligatorio	Valor predeterminado
enabled	Habilita la recolección de elementos no utilizados de imagen. Puede optar por deshabilitar la característica mediante el cambio de esta configuración a false.	Opcionales	true
cleanup_recurrence	Controla la frecuencia de periodicidad de la tarea de limpieza. Debe especificarse como un múltiplo de días y no puede ser inferior a un día. Por ejemplo: 1d, 2d, 6d, etc.	Opcionales	1d
image_age_cleanup_threshold	Define el umbral mínimo de antigüedad de las imágenes no utilizadas antes de considerar la posibilidad de realizar la limpieza y debe especificarse en días. Puede especificar 0d para limpiar las imágenes en cuanto se quiten de la implementación. Las imágenes se consideran no utilizadas después de que se hayan quitado de la implementación.	Opcionales	7d
cleanup_time	Hora del día, en la hora local del dispositivo, cuando se ejecuta la tarea de limpieza. Debe tener el formato HH:MM de 24 horas.	Opcionales	00:00

Redes

• Útil
  • Revisar 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

Revisar configuración de entrada y salida

Los canales de comunicación entre Azure IoT Hub e IoT Edge siempre están configurados para que sean la salida. Para la mayoría de los escenarios de IoT Edge, solo se necesitan 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 Azure IoT Edge necesita conectarse con IoT Hub para recuperar la información de configuración del dispositivo y para enviar mensajes y telemetría. Y si utiliza el aprovisionamiento automático, IoT Edge debe conectarse al servicio de aprovisionamiento de dispositivos. 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 agregar en la lista de permitidos las conexiones hechas desde dispositivos IoT Edge, revise la siguiente lista de componentes de IoT Edge:

• El agente de IoT Edge abre una conexión AMQP/MQTT persistente con IoT Hub, posiblemente a través de WebSockets.
• El centro de IoT Edge abre una única conexión AMQP persistente o varias conexiones MQTT con IoT Hub, posiblemente a través de WebSockets.
• El servicio IoT Edge realiza las llamadas HTTPS intermitentes a IoT Hub.

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

Registros de contenedor

El motor de contenedor realiza llamadas a registros de contenedor a través de HTTPS. Para recuperar las imágenes de contenedor del entorno de ejecución de Azure IoT Edge, el FQDN es 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	Uso
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 deltas de imágenes de Azure Container Registry desde Blob Storage
*.azure-devices.net	5671, 8883, 4431	Acceso de IoT Hub
*.docker.io	443	Acceso a Docker Hub (opcional)

¹ 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 se puede ejecutar a través de un túnel WebSocket.

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 más información, consulte Descripción de la dirección IP del centro de IoT.

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

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

Nota:

Para proporcionar un FQDN coherente entre los puntos de conexión de REST y de datos, a partir del 15 de junio de 2020 el punto de conexión de datos de Microsoft Container Registry cambiará de *.cdn.mscr.io a *.data.mcr.microsoft.com
Para obtener más información, consulte Configuración de las 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 IoT de Azure. 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	Uso
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 sus dispositivos se van a implementar en una red que utiliza un servidor proxy, deben ser capaces de comunicarse a través del proxy para llegar a IoT Hub y a los registros de contenedor. Para más información, consulte Configuración de un dispositivo de IoT Edge para que se comunique 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 de contenedor iniciados por el motor.

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"]
   }
   

Administración de soluciones

• Útil
  • 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 utiliza journals como controlador de registro predeterminado. Puede usar la herramienta de línea de comandos journalctl para consultar los registros del demonio.

A partir de la versión 1.2, IoT Edge se basa en varios demonios. Aunque los registros de cada demonio se pueden consultar individualmente con journalctl, los comandos iotedge system proporcionan una manera cómoda de 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
  

Cuando está probando una implementación de IoT Edge, normalmente puede acceder a sus dispositivos para recuperar registros y solucionar problemas. En un escenario de implementación, es posible que no tenga esa opción. Considere cómo va a recopilar información sobre los dispositivos en producción. Una opción es usar un módulo de registro que recoge información de los otros módulos y la envía a la nube. Un ejemplo de un módulo de registro es logspout-loganalytics o puede diseñar el suyo propio.

Configurar el controlador de registro predeterminado

De manera predeterminada, el motor del contenedor Moby no establece límites de tamaño de registro de contenedor. Con el tiempo, esto puede hacer que el dispositivo se llene con registros y se quede sin espacio en disco. Configure el motor del contenedor para usar el controlador de registro local como mecanismo de registro. 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 optar por usar otros 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

Puede configurar el motor del contenedor para que use un controlador de registro específico si establece el valor de log driver en el nombre del controlador de registro de daemon.json. 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 llamado daemon.json y colóquelo en la siguiente ubicación:

• /etc/docker/

El motor del contenedor debe reiniciarse para que los cambios surtan efecto.

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

Puede hacerlo en el elemento 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 diario de systemd estableciendo journald como 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 el escenario de implementación más eficiente de IoT Edge, considere la posibilidad de integrar la implementación de producción en las canalizaciones de pruebas y de CI/CD. Azure IoT Edge admite varias plataformas de CI/CD, incluida Azure DevOps. Para más información, consulte Integración continua e implementación continua en Azure IoT Edge.

Consideraciones sobre la seguridad

• Importante
  • Administrar el acceso al registro de contenedor
  • Limitación del acceso del contenedor a los recursos de host

Administrar el acceso al registro de contenedor

Antes de implementar módulos en dispositivos de producción IoT Edge, asegúrese de controlar el acceso al registro de contenedor para que las personas ajenas no puedan acceder a las imágenes de contenedor o realizar cambios en ellas. Use un registro de contenedores privado para administrar las imágenes de contenedor.

En los tutoriales y otra documentación, le indicamos que utilice las mismas credenciales de registro de contenedor en el dispositivo IoT Edge que en la máquina de desarrollo. Estas instrucciones solo pretenden ayudarle a configurar entornos de pruebas y desarrollo con mayor facilidad, y no deben seguirse en un escenario de producción.

Para obtener un acceso más seguro al registro, tiene una selección de opciones de autenticación. Un método de autenticación conocido y recomendado consiste en usar una entidad de servicio de Active Directory que sea adecuada para que las aplicaciones o los servicios extraigan imágenes de contenedor de forma automática o cualquier otra forma desatendida (sin supervisión directa), como lo hacen los dispositivos IoT Edge. Otra opción es usar tokens con ámbito de repositorio, que permiten crear identidades de larga o corta duración que solo existen en la instancia de Azure Container Registry en la que se crearon y el acceso de ámbito a nivel de repositorio.

Para crear una entidad de servicio, ejecute los dos scripts como se describe en Creación de una entidad de servicio. Estos scripts realizan las siguientes tareas:

• El primer script crea la entidad de servicio. Devuelve el id. de 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 concederlos a la entidad de servicio, que se puede ejecutar posteriormente si es necesario. Se recomienda aplicar el rol de usuario acrPull para el parámetro role. Para obtener una lista de roles, consulte Roles y permisos de Azure Container Registry.

Para autenticarse con una entidad de servicio, proporcione el id y la contraseña de la entidad de servicio que obtuvo del primer script. Especifique estas credenciales en el 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 la contraseña que obtuvo después de crear el token con ámbito de repositorio. Especifique estas credenciales 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.

Nota:

Después de implementar una autenticación de seguridad mejorada, deshabilite el valor Usuario administrador para que el acceso de nombre de usuario y contraseña predeterminados deje de estar disponible. En el registro de contenedor en Azure Portal, seleccione del menú del panel izquierdo, dentro de Configuración, la opción Claves de acceso.

Limitación del acceso del contenedor a los recursos de host

Para equilibrar los recursos de host compartidos entre los módulos, se recomienda establecer límites en el consumo de recursos por módulo. Estos límites garantizan que un módulo no pueda consumir demasiada memoria o uso de CPU e impiden que otros procesos se ejecuten en el dispositivo. La plataforma IoT Edge no limita los recursos de los módulos de forma predeterminada, ya que para saber cuántos recursos necesita un módulo determinado para ejecutarse de forma óptima es necesario realizar pruebas.

Docker proporciona algunas restricciones que se pueden usar para limitar 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.

Estas restricciones se pueden aplicar a módulos individuales mediante el uso de opciones de creación en manifiestos de implementación. Para más información, consulte Configuración de las opciones de creación de contenedores para módulos de IoT Edge.

Pasos siguientes

• Más información acerca de la implementación automática de IoT Edge.
• Consulte como IoT Edge admite la integración continua e implementación continua.