Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Nebula Container Orchestrator: Orchestrating IoT

DZone's Guide to

Nebula Container Orchestrator: Orchestrating IoT

Keeping IoT devices up to date is always a challenge, but a new open source project called Nebula hopes to orchestrate Docker containers for updates.

· IoT Zone ·
Free Resource

There's no question IoT is the future. In recent years, we have seen IoT devices creeping into every facet of our lives. Everything from door locks to fridges are becoming "smart", but as with every new technology, new challenges arise, and some of the challenges with IoT devices include how to manage them? How do you deploy a new version to that fancy new smart fridge your company designed when they are located in thousands of houses around the globe?

Traditional orchestration solutions (Mesos/Kubernetes/Swarm/etc...) are designed to squeeze as many containers onto the same set of servers as possible in order to lower costs and, as a byproduct of their design, aren’t really well-suited to work with their workers being distributed through high latency links (like the Internet). Unfortunately, this makes them less than ideal to manage IoT devices, which are frequently connected to the Internet directly and can never share resources among apps.

To answer this need, I started a FOSS project named Nebula container orchestration. The project's ultimate goal is to be a Docker orchestrator for IoT devices and distributed services (like CDN or edge computing). In the end, Nebula allows you to have the ability to simultaneously update tens of thousands of IoT devices all around the globe with a single API call, allowing devs and ops to treat IoT devices like another distributed Dockerized app.

Nebula architecture can best be described in the flow of creating a new service:

Image title

An admin uses the Control API service to create a new Nebula app configuration (via API, SDK, or CLI). For example, an app named “test” has the following config:

{
	"starting_ports": [
		80
	],
	"containers_per": {
		"server": 1
	},
	"env_vars": {
		"MYENV": "env_value"
	},
	"docker_image": "my_registry:5000/my_iot_device:v3",
	"running": true,
	"volumes": [
		"/tmp:/tmp/1",
		"/var/tmp/:/var/tmp/1:ro"
	],
	"network_mode": "bridge",
	"privileged": false,
	"devices": [
		"/dev/sdc:/dev/xvdc:rwm"
	]
}


The API service updates the Nebula MongoDB backend with the new app config and simultaneously creates a new RabbitMQ fanout exchange for that app.

From this point, every IoT device that is turned on with a Nebula worker-manager container on it configured with the APP_NAME="test" envvar will be managed by Nebula to ensure it always matches the correct Nebula app config.

Upon boot, every worker-manager creates a RabbitMQ queue for each app set to run on it.

The worker-manager then pulls the latest config from MongoDB and starts/stops work containers as needed to match the required config.

From this point on, the worker-manager listens to the RabbitMQ queues it created earlier. Any update to the app config in Nebula (new container tag, envvar change, etc.) will be immediately pushed to all of the relevant workers, thus ensuring all of your IoT devices will always be up to date with the latest config. It’s also possible to restart/stop/start all of the IoT devices simultaneously. Currently, each restart also re-pulls the Docker containers for the app so it can also be used to update a container version without changing tags.

You can read more about Nebula via the official documentation or check out the GitHub or DockerHub repos.

Topics:
iot frameworks ,docker orchestration ,nebula ,iot

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}