Supported docker-compose versions

openBalena
#1

Hi all,

Relative newbie to open balena - but I’m trying to make a new app to deploy a docker-compose file, but we need support for version 3.7. From changing the version numbers, it seems like the highest working version is 2.

Is there some way to work around this?

Our existing docker-compose.yml file requires features from 3.7…

#4

Hi Steve, there’s no way to work around Docker compose features that aren’t implemented but perhaps if you share specifically what you’re trying to do and what features you’re missing, we may be able to suggest a workaround for that. For reference, you can see what features are supported here: https://www.balena.io/docs/reference/supervisor/docker-compose/

#6

Thanks Chris,

I’m discussing this with our development team to see what we can do and if we are able to work around this limitation.

I should mention that we don’t want to build packages via openBalena - as we have our own CI system and CR that we can pull things from. As such, we only really need to push the docker-compose.yml to the device to be executed. All pulls can come from our existing infrastructure.

Right now, we’re using a base OS and implementing most things on our own - but our goal is to move to BalenaOS. Whilst this is kind of changing the topic, can you confirm that the A/B flashing works with OpenBalena and we are able to upgrade remote devices via openBalena using these features? I’m finding it difficult to find the correct documentation on various features.

#11

Hey Steve, let us know what exactly you need from 3.x to see if what you want to do is achievable, but since you’re doing the builds in a separate system, I assume it shouldn’t be an issue to just link the images in the docker-compose that you’ll push to openBalena.

Regarding A/B flashing, I assume you mean doing hostOS updates that support rollbacks? Currently that is not supported in openBalena (which is one of the reasons we still keep it in beta), at least without some manual on-device intervention using SSH, but it is definitely on the roadmap. You can find more info how to do it here: Roadmap for BalenaOS Updates in OpenBalena, but I’ll double-check with the team if that is still up to date.

#15

Hi there,

Just to clarify what my colleague said is still the most accurate method, though since it’s not “officially” supported your mileage may vary until that feature is fully implemented and we move out of beta.

Please do clarify what you mean about A/B flashing, in case we’ve misunderstood!

#17

Hi Matthew,

You’re right on the money regarding the A/B flashing - I guess I’m injecting the Android terms into the discussion due to the $prefixA and $prefixB partitions shown when mounting the SD card in a PC.

If I understand it right, this is the same method for updating the BalenaOS images (although having manual steps right now) - the update goes to the non-active ‘slot’ and is switched by a reboot after update.

I’m yet to sit down with our developers to see what specifics are in the docker-compose.yml we use, hopefully I’ll get to look at that today.

#18

Thanks for clarifying, your understanding of how balenaOS updates work under the hood is correct! Here’s a bit more about the other partitions and disk layout: https://www.balena.io/os/docs/architecture/#Image-Partition-Layout

Do let us know when you figure out what’s required in docker-compose!

#20

It seems the commands we use that are not currently supported are:

  • init: true
  • runtime: nvidia
  • bind mounts

Likely, these would allow our applications to run out of the box - however we do believe we may be able to work around the majority of these. These do however add a number of layers of complexity to the existing projects.

#21

Hey Steve

thanks for the additional info

  • for init:true I believe this should work as we have tini in balenaOS. see here . but i have no personally used this before
  • as for runtime: nvidia can you please clarify? do you want to use GPU found on the device? what device type are you using please?
  • As for bind mounts, are you expecting to mount arbitrary file or directory on the host machine into a container? we do not support that yet but mayeb some of the labels listed here would do the job? otherwise, you can find an example of a workaround here

hope this is helpful.

Cheers

#23

We’ll have to give it a try - we just looked at the differences between the v2 and v3.7 specification.

Yes, we need to use the GPU component as for cuda processing. The device is a nVidia Jetson Nano (SD card).

At the moment, we have a directory mapped in which contains all the config files. This is delivered with the docker-compose.yml file. I’ll pass the links above to our dev guys for comment. Some of them know the internals of Docker much better than I do.