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

Se aplica a: IoT Edge 1.5

Importante

IoT Edge 1.5 LTS es la versión compatible. IoT Edge 1.4 LTS finaliza su 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 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 del dispositivo

Los dispositivos IoT Edge pueden ser cualquier cosa desde 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.

• 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. A continuación, se declara ese certificado de autoridad de certificación en el entorno de ejecución de IoT Edge en el archivo de configuración. Para desarrollo y pruebas, el entorno de ejecución de IoT Edge crea certificados temporales si no se declara ningún certificado 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 Uso de certificados de Azure IoT Edge.

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 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, 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 entidad de certificación

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

Otras formas de actualizar IoT Edge requieren 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

Se requiere un motor de contenedor 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 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 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 red.

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

• protocolo 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, es posible que tenga que configurar el agente de IoT Edge para que use AMQP a través de WebSocket (AMQPWS) para establecer la conexión inicial a IoT Hub.

Una vez que el dispositivo IoT Edge se conecte, continúe configurando la variable UpstreamProtocol para ambos módulos en tiempo de ejecución en implementaciones futuras. Por ejemplo, consulte Configuración de un dispositivo IoT Edge para comunicarse 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	cierto
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	7 días
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.

nombre de dominio completo (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. 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 con 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, esto puede hacer que el dispositivo se llene de 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 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 eficiente de IoT Edge, integre 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 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, le indicamos que use 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 una entidad 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 desasistidas, como lo hacen los dispositivos IoT Edge. También puede usar tokens definidos para el repositorio, que le permiten crear identidades de larga o corta duración que solo existen en el Azure Container Registry donde se crean y, al definir el alcance, acceder 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 hacen lo siguiente:

• 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.

Nota:

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 Azure Portal, en Configuración, seleccione Claves de acceso.

Limitación del 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 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.
• Vea cómo IoT Edge admite la integración continua y la implementación continua.