Balena Supervisor: balena's agent on devices.
Go to file
Alexios Theodoros Brezas e3f480c217 Container restart policy specificiation.
Allow users to set container restart policy using environment variables.

RESIN_APP_RESTART_POLICY sets the name of the policy, and
if policy is "on-failure", optionally, RESIN_APP_RESTART_RETRIES
sets the maximum number of retries.

More information on docker docs:
https://docs.docker.com/engine/reference/run/#restart-policies-restart

One major change we introduce here is that the default policy is set
to always while we used to have the default "no".

We validate the arguments and pass retries parameter only for the case
of "on-failure" as specified in Docker API as of v1.19.
We could let docker handle the arguments directly, gaining
forwards-compatibility with any new features, but I opted
for an implementation that is as well-defined as possible.
2016-06-07 12:49:30 -03:00
automation Add alpine supervisor build info 2016-05-17 11:59:39 +07:00
config/supervisor Reorganize files, and purge sends 404 when there's no directory. 2015-10-13 13:43:36 -03:00
docs Changelog and docs for /v1/images/load 2016-05-19 13:27:59 +00:00
gosuper Finish log to display setting. Add logging to host config. Save host config before rebooting. Allow applying boot config to RPi3. 2016-03-23 12:21:15 -03:00
src Container restart policy specificiation. 2016-06-07 12:49:30 -03:00
tools/dind Fix bash check for preloaded images, -eq is for integers. 2016-05-01 11:01:23 -07:00
.dockerignore Add a script to retry docker push when deploying 2015-10-13 13:45:04 -03:00
.editorconfig add editor config 2015-10-13 13:39:37 -03:00
.gitattributes Add a .gitattributes file to make sure files for use on linux have linux style line-endings. 2015-10-13 13:03:14 -03:00
.gitignore Refactor bootstrapper. Run preloaded supervisor dind. Change dind configs to be ignored and document how to populate them. 2015-10-13 13:45:05 -03:00
01_nodoc Save space by using a dpkg config to avoid installing unnecessary docs/locales. 2015-10-13 13:36:13 -03:00
CHANGELOG.md 1.10.1 2016-06-07 11:30:44 -03:00
coffeelint.json add coffeelint 2015-10-13 13:39:37 -03:00
Dockerfile.alpine.amd64 Add changelog for alpine super and fix version reporting 2016-05-19 16:25:49 +00:00
Dockerfile.alpine.armv7hf Add changelog for alpine super and fix version reporting 2016-05-19 16:25:49 +00:00
Dockerfile.alpine.i386 Add changelog for alpine super and fix version reporting 2016-05-19 16:25:49 +00:00
Dockerfile.alpine.rpi Add changelog for alpine super and fix version reporting 2016-05-19 16:25:49 +00:00
Dockerfile.amd64 Remove even more old terminal related stuff. 2016-04-18 18:13:23 +01:00
Dockerfile.armel Remove even more old terminal related stuff. 2016-04-18 18:13:23 +01:00
Dockerfile.armv7hf Remove even more old terminal related stuff. 2016-04-18 18:13:23 +01:00
Dockerfile.i386 Remove even more old terminal related stuff. 2016-04-18 18:13:23 +01:00
Dockerfile.rpi Remove even more old terminal related stuff. 2016-04-18 18:13:23 +01:00
empty.tar Speed up rsync diff application 2016-01-28 11:08:42 -03:00
entry.alpine.sh Log useful supervisor info to stdout/stderr 2016-05-30 16:51:27 +03:00
entry.sh Log useful supervisor info to stdout/stderr 2016-05-30 16:51:27 +03:00
LICENSE.md Add license and reorganize README headings 2015-10-27 11:07:46 -03:00
Makefile Merge pull request #134 from resin-io/alpine 2016-05-18 11:59:32 -03:00
package.json 1.10.1 2016-06-07 11:30:44 -03:00
postinstall.sh Save space by removing more npm install artifacts. 2015-10-13 13:36:13 -03:00
README.md Add Gitter badge 2016-01-11 16:07:13 -03:00
retry_docker_push.sh Quick fix: use quotes in bash comparison 2015-10-13 13:45:04 -03:00

Resin Supervisor Build status ![Tickets in progress](https://badge.waffle.io/resin-io/resin-supervisor.svg?label=in progress&title=Tickets in progress)

Join our online chat at Gitter chat

This is resin.io's Supervisor, a program that runs on IoT devices and has the task of running user Apps (which are Docker containers), and updating them as Resin's API informs it to.

The Supervisor is for now a node.js program, with a subset of its functionality implemented in Go.

We are currently rewriting the whole code in Go, so if you're interested in contributing, please checkout the corresponding branch and use that as a base for your PR's (unless it's a bug fix, in which case you can PR to master directly).

We are using waffle.io to manage our tickets / issues, so if you want to track our progress or contribute take a look at our board there.

Running supervisor locally

Deploy your local version to a Docker registry

We'll show how to use the DockerHub registry, but any other can be specified as part of the SUPERVISOR_IMAGE variable.

If you haven't done so yet, login to the registry:

docker login

Use your username and password as required.

Then deploy to a specific repo and tag, e.g.

make ARCH=amd64 SUPERVISOR_IMAGE=username/resin-supervisor:master deploy

This will build the Supervisor docker image if you haven't done it yet, and upload it to the registry. As we pointed out before, a different registry can be specified with the DEPLOY_REGISTRY env var.

Set up config.json

Add tools/dind/config.json file from a staging device image.

A config.json file can be obtained in several ways, for instance:

  • Download an Intel Edison image from staging, open config.img with an archive tool like peazip
  • Download a Raspberry Pi 2 image, flash it to an SD card, then mount partition 5 (resin-conf).

The config.json file should look something like this:

(Please note we've added comments to the JSON for better explanation - the actual file should be valid json without such comments)

{
	"applicationId": "2167", /* Id of the app this supervisor will run */
	"apiKey": "supersecretapikey", /* The API key for the Resin API */
	"userId": "141", /* User ID for the user who owns the app */
	"username": "gh_pcarranzav", /* User name for the user who owns the app */
	"deviceType": "intel-edison", /* The device type corresponding to the test application */
	"files": { /* This field is used by the host OS on devices, so the supervisor doesn't care about it */
		"network/settings": "[global]\nOfflineMode=false\n\n[WiFi]\nEnable=true\nTethering=false\n\n[Wired]\nEnable=true\nTethering=false\n\n[Bluetooth]\nEnable=true\nTethering=false",
		"network/network.config": "[service_home_ethernet]\nType = ethernet\nNameservers = 8.8.8.8,8.8.4.4"
	},
	"apiEndpoint": "https://api.resinstaging.io", /* Endpoint for the Resin API */
	"registryEndpoint": "registry.resinstaging.io", /* Endpoint for the Resin registry */
	"vpnEndpoint": "vpn.resinstaging.io", /* Endpoint for the Resin VPN server */
	"pubnubSubscribeKey": "sub-c-aaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", /* Subscribe key for Pubnub for logs */
	"pubnubPublishKey": "pub-c-aaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa", /* Publish key for Pubnub for logs */
	"listenPort": 48484, /* Listen port for the supervisor API */
	"mixpanelToken": "aaaaaaaaaaaaaaaaaaaaaaaaaa", /* Mixpanel token to report events */
}

Additionally, the uuid, registered_at and deviceId fields will be added by the supervisor upon registration with the resin API.

Start the supervisor instance

make ARCH=amd64 SUPERVISOR_IMAGE=username/resin-supervisor:master run-supervisor

This will setup a docker-in-docker instance with an image that runs the supervisor image.

Testing with preloaded apps

To test preloaded apps, add a tools/dind/apps.json file according to the preloaded apps spec.

It should look something like this:

(As before, please note we've added comments to the JSON for better explanation - the actual file should be valid json without such comments)

[{
	"appId": "2167", /* Id of the app we are running */
	"commit": "commithash", /* Current git commit for the app */
	"imageId": "registry.resinstaging.io/path/to/image", /* Id of the docker image for this app */
	"env": { /* Environment variables for the app */
		"KEY": "value"
	}
}]

Make sure the config.json file doesn't have uuid, registered_at or deviceId populated from a previous run.

Then run the supervisor like this:

make ARCH=amd64 PRELOADED_IMAGE=true \
	SUPERVISOR_IMAGE=username/resin-supervisor:master run-supervisor

This will make the docker-in-docker instance pull the image specified in apps.json before running the supervisor.

View the containers logs

docker exec -it resin_supervisor_1 journalctl -f

View the supervisor logs

docker exec -it resin_supervisor_1 /bin/bash
tail /var/log/supervisor-log/resin_supervisor_stdout.log -f

Stop the supervisor

make stop-supervisor

This will stop the container and remove it, also removing its volumes.

Working with the Go supervisor

The Dockerfile used to build the Go supervisor is Dockerfile.gosuper, and the code for the Go supervisor lives in the gosuper directory.

To build it, run:

make ARCH=amd64 gosuper

This will build and run the docker image that builds the Go supervisor and outputs the executable at gosuper/bin.

Adding Go dependencies

This project uses Godep to manage its Go dependencies. In order for it to work, this repo needs to be withing the src directory in a valid Go workspace. This can easily be achieved by having the repo as a child of a directory named src and setting the GOPATH environment variable to such directory's parent.

If these conditions are met, a new dependency can be added with:

go get github.com/path/to/dependency

Then we add the corresponding import statement in our code (e.g. main.go):

import "github.com/path/to/dependency"

And we save it to Godeps.json with:

cd gosuper
godep save -r ./...

(The -r switch will modify the import statement to use Godep's _workspace)

Testing

Gosuper

The Go supervisor can be tested by running:

make ARCH=amd64 test-gosuper

The test suite is at gosuper/main_test.go.

Integration test

The integration test tests the supervisor API by hitting its endpoints. To run it, first run the supervisor as explained in the first section of this document.

Once it's running, you can run the test with:

make ARCH=amd64 test-integration

The tests will fail if the supervisor API is down - bear in mind that the supervisor image takes a while to start the actual supervisor program, so you might have to wait a few minutes between running the supervisor and testing it. The test expects the supervisor to be already running the application (so that the app is already on the SQLite database), so check the dashboard to see if the app has already downloaded.

License

Copyright 2015 Rulemotion Ltd.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.