Additional OpenVPN Connections and External Volumes

Folks,

Again bear with me as I’m postulating things.

Two questions as I look into Balena as a solution for our next gen. of Managed Devices.
My understanding is that the best practice for Balena (and Docker in General) is to minimize activity on the Host OS as much as possible. Under this premise.

a) I need additional VPN connections to be deployed.

Will deploying an OVPN container on top of the BalenaOS and it’s own VPN connection cause grief?Am I best to simply work on the Host OS (obviously prefer not to).

b) I’m coming from an “appliance” type platform history. On these appliances we have a filesystem path that contains the meat of the devices management tools etc etc. I would like to be able to treat this filesystem path i.e. “/opt/ourtoolset” as a image/container onto itself so that it can be tagged/patched/upgraded and downgraded easily. In essence a pre-populated volume that simply get’s pulled like all the other layers when deploying containers onto the host. In reading up on Docker it appears that an External Volume might do the trick. If I’ve managed to make my needs at all clear :wink: any guidance would be appreciated. Also I would need some on device persistence as well so I this “containerized” volume would also need to be able to interact with other containers.

Thoughts

Colin

Hey Colin happy to help with the postulating.
a.) I think you should be fine to run OVPN in your container we have a few customers doing similar things and shouldn’t cause any issues and definitely preferable than trying to do that in the hostOS (which we don’t support)
b.) I am not sure I completely understand this one perhaps because I don’t have a good sense of what an “Appliance” type platform is and how they are managed. However anything that needs to be updated across the fleet and is not specific state to the device should exist in the docker image (containers filesystem) and be encode in the Dockerfile. Volumes as I understand them should be used for the persisted state for your containers so things like SQL database ,etc. From the sounds of it you would want to just do something like COPY /opt/ourtoolset /opt/ourtoolset in your dockerfile that you push out to the fleet and that will update the toolset on devices.

Yea, I’m just in the process of getting my head around moving from a monolithic image and the container approach.

The toolset will need to be potentially used by more than 1 container so need to think of it as a global volume.

Thanks again.

C

We also provide a shared data volume also, which all containers can access for sharing file data and obviously they can all talk to each other using the local Docker bridge network.