We envisage our devices being flashed to a ‘landing’ application. From here we are intending to do some provisioning checks, and also potentially negotiation for credentials such as certificates (i.e. obtaining an AWS IoT Core certificate).
The eventual application that is intended for the device may vary, but the means for cloud communication (i.e. via these obtained credentials) is consistent. We intend to switch the device to a specific application, but would like to do some of these preliminary steps before then such that the application can have certificates in place when starting.
I have noted from documentation :
Warning: For devices running balenaOS version 2.12.0 and above, data in persistent storage (named volumes) is automatically purged when a device is moved to a new application.
Is there a way for storing data that survives beyond a device being moved to a new application?
We’d like to have shared files such as a certificate from a named volume, setup in one application, to a different container started in a switched to application.
Hello Louis, at the moment this is not possible. If you want to permanently store data created by an app, you should store or copy it to an external storage via mount (at the moment can’t be a docker volume).
Tell us more about your use case, and device being used, so maybe we can take it into account in the future.
Hi @mpous, thanks for coming back to me. We were looking at the provisioning process for our devices. When we setup the device, we don’t know what Application will be placed on it, but we wanted to still be able to identify it and communicate with the Cloud. We have been looking at AWS IoTCore for this, and had thought that we could use an embedded bootstrap certificate to obtain a full certificate for communication whilst still using an initial landing/provisioning Balena Application.
When we eventually put this at a customer site and choose the Application to switch to, we were hoping to still be able to use this provisioned certificate that was obtained securely, having our MQTT bridge in the destination application then start up successfully referencing these ready and waiting certificates.
However, if this certificate was obtained via an application container doing the exchange, it would normally reside on a docker volume as I understand? We thought that maybe if this container remained in each of our application stacks it might be able to maintain this volume, and us use this container. I now understand this is not possible.
You mention that we should store it via mounted external storage. How would we make this visible to the container? Would bind mounts not be needed to make mounted external storage accessible to the container - I had thought these weren’t supported either?
Thanks for sharing your use case, that is very helpful for us.
On mounting an external storage medium, if the container is run as privileged, the /dev/ system becomes available to the container, which means you can call mount for the external device. That’s the reason you don’t need bind mounts.