@lpierrat its all in here https://github.com/balena-io-playground/azure-iot-edge-v2
@shaunmulligan when you say that
balenaCloud doesn’t allow bind mounts to the hostOS
you mean that it supports only managed volume?
Hi @banto_78 , yes, balenaCloud only allows named volumes, but its not permitted to do random bind-mounts to the hostOS. So you couldn’t define something like :
volume: - /etc/os-release:/etc/os-release
the reason for not allowing random bind mounts is that we need to maintain a constant interface and can’t commit to keeping the hostOS filesystem naming and layout the same forever. Allowing those bindmounts opens the flood gates to incompatibilities when doing OS upgrades, so we need to keep the interface as well defined as possible and as loosely coupled with the OS as possible.
@shaunmulligan I am bit confused. Is for you managed volume == named volume ?
i.e. something managed completely by docker/balena-engine as:
/var/lib/docker/vfs/dir/“some volume ID”
is a bind mount. Are we aligned?
@banto_78, balena supports named volumes in a configuration such as the following, where “resin-data” is the name of the named volume:
version: '2' volumes: resin-data: services: example: build: ./example volumes: - 'resin-data:/data'
Above, note how the
volumes: key appears twice: first at the top of the file, where the named volume is declared. Then for each service, to make the previously declared volume available for use by that service.
As for bind mounts, balena’s platform does not allow arbitrary bind mounts to be specified in a docker-compose file. Only a few pre-defined bind mounts are available, through the use of “labels”, as listed and explained in the Labels section of the following page:
Reading Shaun’s message, I think he meant that
"/var/run/iotedge/mgmt.sock" could not be used as a bind mount because of the limitations explained above, plus the fact that
"/var/run/iotedge/mgmt.sock" does not exist in the balena host OS. I think Shaun alluded to the possibility of creating a named volume for use with an
edge-agent service that would be declared in the
docker-compose.yml file, such that
"/var/run/iotedge/mgmt.sock" would exist in the named volume rather than in the host OS.
@pdcastro thanks. So a named volumes in compose file is only possible if it is resin-data: ? If so, a test we can try is to see if we can change where edgeAgent is binding-mounting the container in a way that is going to bind in the resin-data location. What do you think?
iotedged can use IP addresses instead of UDS. See: https://github.com/Azure/iotedgedev/blob/master/docker/runtime/rund.sh as an example.
This can be used for development and testing but not a supported production configuration.
Do you mean this part here?
@banto-78 the restriction only applies to bind mounts. Named volumes are fully supported, see here: https://www.balena.io/docs/reference/supervisor/docker-compose/
Can you please explain in Balena what’s the difference between named volume and bind mount? And how are they configured? Because I do not find a way to compare it if i just look at Docker documentation.
A named volumes in compose file is only possible if it is resin-data: ?
iotedgedcan use IP addresses instead of UDS.
Are you referring to this part in the script https://github.com/Azure/iotedgedev/blob/master/docker/runtime/rund.sh to this part:
Sorry I just would like to be aligned with you 100%. And sorry if i mixed up questions.
Sorry for being confusing…
On a balenaOS device you can’t use bind-mounts because they mount files/directories from the host system into your container.
Named voluems refer to docker volumes, which are storage managed by the docker daemon that is independent from the host file system. You would typically use the to persist some app data during the lifetime of your container.
It’s confusing because in docker both concepts are mixed in with each-other by overloading the term
no. there is no naming restriction, you can call them anything you want
I can’t say anything about 3. that one would be for @vyalla - welcome to the forums btw o/
Ok I understand the definition now.
But where I still need your help with is to understand their syntax in the compose of Balena.
Where are they different? Is because in the first form resin-data is just a reference name or alias and NOT a real path? And of course I understand that the second form is not supported in BalenaOS.
That’s exactly correct. The Supervisor does not currently allow bind-mounts (which would mount a real path on balenaOS), whereas it does allow named-volumes, where it will dynamically create a volume for each volume defined which will then be attached to the service that references it.
Best regards, Heds