Thanks for the info.
In terms of it being ‘a little off’, that did indeed end up being a Portainer related issue. I had hidden the containers related to Balena using Portainers labels, and subsequently Portainer hadn’t handled the associated images very well. I logged it with Portainer: https://github.com/portainer/portainer/issues/3565
So far so good, things seem to be running well, and your confirmation that Supervisor won’t intervene in these created containers is reassuring.
Deploying containers through Portainer and adding a Balena label doesn’t seem to take affect, for example the Supervisor doesn’t become available with “io.balena.features.supervisor-api”: “1”. It does though if I redeploy one of the images that are on the device as part of its initial Balena Push, and repurpose them with new labels. This is actually a benefit for me, but wasn’t what I had anticipated. It seems when I do this manually without Portainer it doesn’t take affect either, not sure if that is expected? Is there something injected into the containers built with Balena Push that makes them work with the labels?
Would rather the title of this thread now be Portainer related, but unfortunately can’t seem to change it.
For those searching Portainer, here is the Docker Compose that worked for me:
version: '2.1'
services:
portainer:
ports:
- '9000:9000'
labels:
io.balena.features.balena-socket: '1'
volumes:
- 'portainer:/data'
image: portainer/portainer
command: -H unix:///var/run/balena-engine.sock
volumes:
portainer: