los Sistema operativo de robot (ROS) ha impulsado a los innovadores durante una década. Sin embargo, a medida que más y más robots ROS llegan al mercado, los desarrolladores se enfrentan a nuevos desafíos en la entrega de sus aplicaciones. ¿Por qué empezamos a utilizar ROS y Docker? ¿Es cómodo? ¿Resuelve nuestros desafíos? ¿O es simplemente una herramienta de otro dominio que queremos integrar en un campo completamente diferente y posiblemente inadecuado?
Los contenedores Docker fueron desarrollados para el dominio elástico, para operaciones elásticas, para las nubes. Como resultado, existen varias fallas y lagunas en el uso de Docker cuando se trata de robótica o incluso dispositivos de IoT. Nuestro objetivo es destacar estas limitaciones para concienciar a los desarrolladores.
Tabla de Contenidos
El contenedor ROS Docker proporciona acceso al host y a los recursos
El mayor defecto de Docker en las aplicaciones robóticas es la capacidad de acceder al disco host y a los recursos privilegiados como los pines GPIO.
Docker pierde las interfaces dedicadas de alto nivel para acceder al hardware de bajo nivel. No contiene ningún mecanismo fácil de entender para proporcionar acceso a los recursos o permisos del host. Por lo tanto, los desarrolladores de hoy tienen que configurar esta comunicación asignando manualmente permisos específicos y detallados a un contenedor.
Por ejemplo, para obtener acceso a los pines GPIO en un host Linux, se debe usar la marca –device para acceder a todos / dev / gpio
Ejecutar un contenedor con una bandera privilegiada elimina la caja de arena protectora para el contenedor que se ejecuta en su robot. Dado que la bandera privilegiada se usa para acceder al PID del host desde el contenedor, un atacante que tiene una parada inicial en el contenedor puede escapar del entorno del contenedor y acceder a la computadora host con derechos de root.
Desafíos de gestión de red para ROS Docker
Cuando implementas en dispositivos, Docker Compose y la configuración de redes hacen que las cosas sean realmente difíciles de administrar. En pocas palabras, Docker hace que sea mucho más difícil coordinar los mecanismos tradicionales para configurar componentes de software complejos.
Para comunicarse entre sí, dos contenedores pueden comunicarse a través de la red o compartiendo archivos en el disco duro. La comunicación a través de la red permite que los contenedores envíen y reciban solicitudes a otras aplicaciones liberando puertos. Al compartir archivos en el disco, los contenedores de Docker se comunican leyendo y escribiendo archivos.
Sin embargo, dado que no hay interfaces predefinidas, debe configurar puentes, redes virtuales y nombres de host para que un contenedor Docker se comunique con otro. Si está utilizando el disco duro del host, se encontrará con los mismos problemas descritos en la sección anterior. En última instancia, en lugar de disfrutar de los beneficios de tener una organización que administre la infraestructura básica por usted, debe ceñirse a su implementación.
Los desafíos del mantenimiento de la seguridad de Docker aumentan con la implementación
La implementación de protocolos de mantenimiento de seguridad es un problema con o sin Docker. Escanear, identificar y parchear vulnerabilidades requiere mucho tiempo y trabajo. Pero esa es una barrera que todos debemos abordar (obtenga más información sobre Mantenimiento de seguridad para ROS).
Sin embargo, con Docker, los desarrolladores no reciben notificaciones cuando llega una actualización de seguridad o se pone a disposición una corrección CVE para los paquetes Debian utilizados en su contenedor. en contraste con otros Contenedores como broches, Docker no viene con un centro de notificaciones gratuito que notifica a los desarrolladores cuando hay una actualización disponible. Sabes cuándo actualizar algo o tienes que pagar una suscripción mensual para usar un centro de notificaciones de terceros.
Como resultado, los desarrolladores dejan en sus manos el manejo de estas actualizaciones de seguridad.
Como Docker especificado «Depende del usuario individual decidir si un CVE se aplica o no a la forma en que operan su servicio». Esto nos lleva de nuevo a asumir una responsabilidad significativa y efectiva sin antecedentes de seguridad.
Sin un centro de notificación gratuito y activo listo para usar y sin asistencia para solucionar estos problemas de seguridad, los usuarios de ROS Docker terminarán brindando soluciones en el campo que pondrán a sus usuarios en riesgo.
No hay actualizaciones transaccionales para ROS en Docker
¿Qué pasa si falla una actualización? ¿Si su robot se queda sin batería durante una actualización? O simplemente hay un error. Este ha sido recientemente el caso de IRobot, fabricante de Roomba. Una actualización de firmware provocó problemas de navegación en sus dispositivos y se necesitaron varias semanas para implementar una solución en todo el mundo.
La capacidad de retroceder automáticamente a versiones anteriores es extremadamente importante para los fabricantes de dispositivos. Pero también la capacidad de mantener la integridad de todos sus datos. Eso es algo que no se obtiene con los contenedores de Docker. Con Docker tiene dos escenarios, o funciona completamente con la nueva versión del software o no funciona y vuelve a donde comenzó antes. Debido a esto, los desarrolladores se quedan atascados en los datos de la nueva versión que deben migrarse manualmente a la versión anterior antes de revertir.
También se destruyen todos los archivos que estaban disponibles en la versión anterior. Por lo tanto, si tiene una base de datos y la base de datos se corrompe durante la actualización, no existe ningún mecanismo de seguridad para realizar una copia de seguridad antes de actualizar.
No hay actualizaciones delta para las aplicaciones ROS Docker
El ancho de banda es una limitación para los robots y tiene un costo asociado. Dependiendo de su aplicación, los robots suelen tener conexiones a Internet y planes de datos limitados, por lo que es fundamental conservar el ancho de banda en las actualizaciones. Por supuesto, las actualizaciones extensas también tienen un impacto en el consumo de energía.
Por eso tenemos paquetes delta; una actualización en la que el usuario solo tiene que descargar el código modificado, no el programa completo. Entonces, ¿qué pasa si su paquete es de 500 MB, pero un delta entre dos revisiones solo puede ser de 20 MB? Esa es una gran diferencia en términos de eficiencia y costos de ancho de banda. Las actualizaciones delta reducen los requisitos de ancho de banda en más del 95%. (Obtenga más información sobre cómo nuestras actualizaciones de Delta han ayudado a Cyberdyne)
Pero Docker no tiene actualizaciones delta. Entonces, si ha implementado con Docker, debe considerar el costo que representan sus actualizaciones.
La gestión de flotas de Docker es un desafío
Docker funciona bien para cargas de trabajo de corta duración. Piense en ello como un proceso sin servidor en el que piratea el código y simplemente lo ejecuta una vez en la nube y obtiene la respuesta. No es necesario que le des un nombre a este contenedor. Por que lo harias Es como ir al shell, registrar el nombre de lo que voy a hacer, escribir un comando y luego solicitar que se ejecute su registro. Los contenedores de Docker ahorran esto a los desarrolladores.
Sin embargo, para la gestión de flotas, necesita conocer el estado de su dispositivo. Si el software más reciente está actualizado, está probando una solución con un grupo de dispositivos o necesita la identificación de la computadora por razones operativas. Docker no ofrece esta identificación con la máquina lista para usar. Hay una separación entre el proceso y la máquina real porque en la nube no me importa si tengo 20 máquinas y quién aloja este proceso. Tú te encargas de la gestión de la flota.
La gente podría pensar que Kubernetes es la solución. Pero no lo es. Kubernetes se utiliza con éxito en sistemas de orquestación de contenedores para automatizar la implementación, el escalado y la gestión de aplicaciones informáticas. Es de código abierto y se usa ampliamente para ayudar en la subcontratación de centros de datos a proveedores de servicios de nube pública, o se puede usar para alojamiento web a gran escala. Kubernetes no es una solución para la gestión de flotas. Kubernetes está diseñado para un agregado de informática. La gestión de flotas de robótica no es un dispositivo informático. Es exactamente lo contrario de eso.
