Use pre build multiarch image from docker hub

Product support
1

Trying to use my own multi-arch image that I have built with the new docker buildx command and pushed to docker hub.
From the docs so far I understand that I need to use belena push, but it seems that doesn’t use the existing image, but still somehow builds a new image as when running the logs show standard_init_linux.go:207: exec user process caused "exec format error".

I can run this image fine on another Rpi with Hypriot OS

docker-compose file

version: "2.1"

services:
  lora-connect:
    image: arribada/lora-connect
    ports:
    - "8070:8070"

The reason why I want to use this image and not the usual balena build process is because it will also be used on a AMD64 bit machine and having the multi arch image with the same Dockerfile is quite convenient.

Is there such a workflow to only use an existing images and avoid any builds all together?

2

Hi yes this is a bug with our builder backend where it gets confused and the device pulls the wrong architecture. You should be able to use local mode until we fix it on our side

5

Thanks for the update, will try it. Please ping me when it should be fixed to try again.

6

Will do o/

8

btw what is the expected behavior ?

When I have the service defined to use an image in the compose file it just pulls it from docker hub or it first pulls it in your registry and than the device pulls these from your registry?

When I inspected the images on the PI after balena deploy I noticed that they are named differently than the ones I have uploaded to docker hub.

9

Hey, when you define an existing image in your docker-compose file and deploy, it will first pull the image to your local docker daemon if it does not exist, and then push it to our registries. We do this so that we have a single trusted location where devices can download images from.

What specifically do you mean when you say what is the expected behaviour? Do you mean when a multi-arch image exists at the given location? If so, the behaviour we would want is for the builder and cli to do the correct negotiation for manifest files, and download the correct version, but this currently is not implemented.

11

yes this is what I meant, whether it is expected that the downloaded images on the devices come from your server or directly from docker hub.

Local mode works fine. Thanks

12

Hi,
Good that at least local mode works atm. We will update this thread as soon as the bug is fixed on our side.

14

btw is there a github issues or some other way of tracking this?

If not is someone already working on it or still just on the bugfix queue?

One problem I am facing with local mode are the env variables.

15

@krasi-georgiev, thanks for reporting and keeping track of this issue. We already had a GitHub issue in a private repo (for balena’s cloud builders), but I have now also created a CLI issue (because of the “balena push” command) for increased visibility: balena push selects incorrect image (multiarch images, Docker manifest) · Issue #1408 · balena-io/balena-cli · GitHub

As far as I can tell, the issue is in a backlog and work has not yet started on it (so yes, it’s in a bugfix queue…).

By the way, I wonder if the balena deploy command (instead of balena push) would be any more successful in your multiarch case:

However I mention it without knowledge that it would actually provide any better results. It does skip much of the cloud builder processing behind balena push, so it’s also not just a random suggestion…

One problem I am facing with local mode are the env variables.

Is the problem that… env vars are not supported? On this point, I’ll ask @CameronDiver if he has any advice.

18

I have now also created a CLI issue (because of the “balena push” command) for increased visibility: balena push selects incorrect image (multiarch images, Docker manifest) · Issue #1408 · balena-io/balena-cli · GitHub

Thanks I subscribed.

By the way, I wonder if the balena deploy command (instead of balena push ) would be any more successful in your multiarch case:

I tried it but no luck still deploys the wrong images.

Is the problem that… env vars are not supported? On this point, I’ll ask @CameronDiver if he has any advice.

yes , and local mode is only available in dev images. In general it is ok as a temporary workaround, but can’t be used for real deployments.

19

The multiarch images can be balena deployed (or even balena pushed) if you specify the correct sha256 I believe, i.e. instead of repo/image, you would do repo/image@sha256:<digest> for the correct architecture.

This is obviously not as nice as the manifest negotiation we do plan to add, but it should be a workaround for now.

I’m not 100% following on the issue you’re having with env vars, could you clarify please?

21

I’m not 100% following on the issue you’re having with env vars, could you clarify please?

I am not sure about the expected workflow with the env vars. Do I need to add these to the compose file and than add those to my local machine so that they get expanded and when using a production image do I need to remove these from the compose file or they will get overwritten by the values set on the balena portal?
I think there were some other issues, but can’t remember now. Will add an update if I remember.

The multiarch images can be balena deploy ed (or even balena push ed) if you specify the correct sha256 I believe, i.e. instead of repo/image , you would do repo/image@sha256:<digest> for the correct architecture.

that is great workaround, thanks for that!

23

Hello!

I am not sure about the expected workflow with the env vars. Do I need to add these to the compose file and than add those to my local machine so that they get expanded and when using a production image do I need to remove these from the compose file or they will get overwritten by the values set on the balena portal?

Yes, that’s exactly correct. If you specify the envvars in the compose file when using local mode, these will be used by balenaEngine on the device and correctly injected into your container. In production mode, any envvars set of an application or device will override those set in the docker-compose file.

Best regards,

Heds

25

It seems that the env substitution doesn’t work as expected.

version: "2.1"

services:
  env-config:
    image: arribada/env-config
    environment:
      PROMETHEUS_CONFIG: "${PROMETHEUS_CONFIG}"

I tried few different variation, but {PROMETHEUS_CONFIG} never gets substituted and inside the container it is just as PROMETHEUS_CONFIG="{PROMETHEUS_CONFIG}".

I don’t want to put the text directly as this is checked out in github so it will expose secrets and configs.

26

Opened another issue to that can track this separately.