Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OTA Updates for IoT devices #45

Open
gswebspace opened this issue May 5, 2018 · 5 comments
Open

OTA Updates for IoT devices #45

gswebspace opened this issue May 5, 2018 · 5 comments

Comments

@gswebspace
Copy link

Hi,

Is it possible to use elliot to deploy application updates to many( > hundreds) remote IoT devices in a secure manner ?

Assuming the devices are connected to the internet after initial setup.

(something similar to https://mender.io server)

(The only manual user action required should be to provide the new build/image and group of devices to deploy the update to, on a web page to complete the update )

@ernoaapa
Copy link
Owner

Hi @gswebspace!
Sorry for the late response (need to find out why I don't get GitHub notifications about issues :/ ).

I have been thinking few variations how I should implement that into Eliot. There are some commercial options (like mender.io) but I would like to also keep the interface open and standardized so that it doesn't lock down the user to any specific provider. So that it would be pluggable one way or another.

I'm open to all kind of suggestions and ideas.

@jmorte
Copy link

jmorte commented Aug 9, 2018

Hi!

First of all, I want to say that I am fascinated with this project. I have some experience developing for IoT devices like raspberry, and this project is something really needed. I will try to dive into the code and help in everything I can.

About this issue, a solution could be to create a generic manager/broker service where devices could be attached to, all attached devices to it can be monitored and deployed. Obviously, this service should be running in a public server.

If you consider it interesting we can discuss more deeply

@gswebspace
Copy link
Author

Also since the new Raspberry Pi 3B+ came out with support for power over ethernet (PoE), There will be many such IoT devices connected to the internet in future.

Having large amount of devices to update manually is a pain. Especially if they are deployed in a place far from you. (Think different states and countries)

A secure (self-hosted) web interface for managing container image uploads and device monitoring can do the trick.

@jmorte
Copy link

jmorte commented Aug 9, 2018

Something like the manager/worker architecture used in docker swarm will suit perfectly. An HTTP API over the eliot engine to interact from a remote server would be nice.

@ernoaapa
Copy link
Owner

Hi @gswebspace and @jmorte!
Happily take more contributors into the project. Have been quite busy lately so havent had time to continue this project.

Simple HTTP API where Eliot engine fetch list of desired Pods regularly would be doable quite easily (actually I already implemented it once in the past).
The only challenge here is how we manage the desired state, because if there's the "remote Pods" what Eliot fetch over the HTTP and then there's the "local Pods" what are created with CLI.

I see few options:

  1. You need to select remote or CLI, either Eliot fetch the desired state over HTTP or you use the CLI to manage the Pods
  2. We mark the Pods to be created by remote state or CLI and you can manage the Pods only through the original source.

The second option quickly feels like good idea, but I'm not sure how confusing it is if you see the pods in eli get pods listing, but you cannot remove them.
The first option would be more easy. For example, cleaning up removed Pods would be really easy, just remove everything what is not part of the latest state. But not sure how nice it is if you cannot run ad-hoc Pods with CLI. For example, to debug something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants