0
$\begingroup$

I was wondering if robotics applications can be deployed over docker, say on Qualcomm RB5.

I came across this whitepaper by Ubuntu Canonical. which argues that docker is not fit for IoT devices and recommends snap. What you think / your experience tells you? Have you evaluated docker vs snap vs something else?

Below is AI generated summary of the whitepaper for reference:

Paper argues that Docker, a popular container technology for cloud computing, has several limitations and drawbacks when it comes to deploying robotics applications on edge devices. Some of the main points are:

  • Docker lacks dedicated interfaces for accessing low-level hardware and host resources, such as GPIO pins, which are essential for robotics applications. This means that developers have to grant excessive privileges to Docker containers, which compromises their security and isolation.
    Q1. Did you find this any real issue? Or have you find any solution for this?
  • Docker makes it difficult to communicate and coordinate between multiple containers, which are often needed for complex robotics applications. Developers have to manually set up bridges, virtual networks, and hostnames to enable inter-container communication, which adds complexity and maintenance overhead.
    Q2. As far as my understanding goes, my application will run on single container. Have you ever required to run multiple containers on robots along with need to have communication between them? If yes, was it any serious issue or have you found any solution to it? (Apart from usual tooks like docker compose etc.)
  • Docker does not provide free security notifications or patches for the Debian packages used in its containers. This means that developers have to constantly monitor and update their containers to avoid vulnerabilities and breaches, which can be time-consuming and costly.
    Q3. Did you find this any real issue? Or have you find any solution for this? Also I quite didnt get this point. Why cant we have some mechanism to force robots periodically check for updated docker image and deploy it? Why need to monitor?
  • Docker does not support transactional updates or automatic rollbacks, which are crucial for ensuring the reliability and integrity of robotics applications. If an update fails or causes problems, there is no easy way to revert to a previous working state, and the data may be corrupted or lost.
    Q4. Cant we just have different docker image tags on same robot so that we can always rollback to last working docker image tag?
  • Docker does not support delta updates, which are updates that only download the code that has changed, not the whole program. This means that updating Docker containers consumes more bandwidth and power, which can be scarce and expensive for edge devices.
    Q5. Cant we have layered docker images? Like one image for environment setup based on which we can have another image for application setup? So for pushing update to application, we can simply update the application image tag. Am I wrong with this?
  • Docker does not provide tools for managing a fleet of devices, which is often needed for robotics applications. Developers have to use third-party services or solutions, such as Kubernetes or Balena, to monitor and orchestrate their devices, which can introduce vendor lock-in and additional costs.
    Q6. I quite didn't get this. Whats not possible with Kubernetes and those great monitoring stacks like say for example Prometheus-grafana stack? What tool we need to manage docker on robotics devices and how Kubernetes is not sufficient for it? Have you tried any other tool?

The whitepaper then introduces snap, a container solution designed for edge devices and integrated with ROS deployment. It claims that snap solves the issues of Docker by providing:

  • Dedicated interfaces for accessing low-level hardware and host resources, such as gpio, home, and content, which allow fine-grained and secure access to the device capabilities and data.
  • Easy and secure communication between snaps, which are automatically connected to the host network and can share code and data through content interfaces, without the need for manual configuration or bridging.
  • Free security notifications and patches for the staged packages used in snaps, which are provided by Canonical through Ubuntu Security Notices (USNs). Developers can opt-in to receive these notifications and apply the patches automatically or manually.
  • Transactional updates and automatic rollbacks, which ensure that snaps are updated atomically and reliably, and can revert to a previous working state if something goes wrong. Snaps also preserve the previous version of code and data, so that developers can safely move applications forwards and backwards in their version history.
  • Delta updates, which reduce the bandwidth and power consumption of updating snaps by only downloading the code that has changed, not the whole program. Delta updates have been shown to reduce bandwidth requirements by more than 95%.
  • Tools for managing a fleet of devices, such as channels, tracks, and branches, which allow developers to control the release and distribution of their snaps to different segments and clusters of devices. Snaps also come with the tools to monitor and schedule updates, and to perform health checks and diagnostics.

Q7. Do you have any other practical recommendation for / against docker for robotics application deployment at scale?

$\endgroup$
1
  • $\begingroup$ This asks many questions, some of which are fairly open to opinion/interpretation. Is there any way that you can make this a bit more focused? $\endgroup$
    – mjcarroll
    Jan 11 at 0:22

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.