How to have persistent storage named volumes not get wiped through moving device to different applications

Product support
1

Hi,

I have set up a named volume on my Balena service which configures persistent storage for a directory path, (https://www.balena.io/docs/learn/develop/runtime/#storage). The named volume persists throughout new deployments, but it does not persist throughout moving the device from application to application.

How can I configure the Dockerfile or docker-compose so that the volume persists throughout moving the device from application to application?

Thanks

6

Hello,

It’s currently not possible to persist the storage between application moves. That being said, we’ll forward this request to the team.

8

Hello, is there a new state on the request to the team?

Our use-case will be:
All customers getting a base application, containing data collection and persistence (“named volumes”).
Customers on a premium paid plan should get the same base app, but in addition some containers doing edge computing stuff with the persisted data. Those premium customers are quite rare, so maybe just 5-10% will use this service.

Solution 1:
Maintaining one app for all and set the premium containers to ON/OFF by using device environment variables depending on the customers subscription status.
Drawback:

  • All customers have to download the really big Python+Pandas+and so on images.
  • All customers will “suffer” a very often update process due to the iterative development of those algorithms. Even if those delta updates are quite small, still every unneeded update process can cause problems and will generate a lot of traffic on Balena side.
  • From dev ops point of view those devices are the ones to monitor on a very frequent base, so would be easier to gather all of them in a separate app.

Solution 2:
Maintain different applications for base and premium services and move the devices back and forth triggered by customers subscription.
Drawback:

  • Persistence is lost on every subscription change (not a viable solution)

I know that it might be disturbing other use-cases where the apps are totally different from each other, but a new opt-in for keeping volumes will not break old behaviour.
In addition (extra bonus) to this, maybe identical service images will even keep their service container. I don’t know if a completely new deployed database container will always be able to continue with an old volume…