How to specify architecture in Balena Deploy

General
1

Hello,

I am using a CI tool to build and deploy both arm and x86 images to docker hub. When deploying with balena deploy it pulls the x86 image. Is there a way to force balena to pull the arm based image?

3

Hey there, are the images you are pulling multiarch images? Could you provide the full balena CLI command and an example Dockerfile with the related FROM line?

I suspect you are running into this issue here but I would like to confirm that the scenario is the same.

Also I should clarify that balena deploy does not push images to Dockerhub, but pushes them to our internal registry to be deployed as apps on balenaCloud.

5

Yes they are multiarch images that are deployed on Dockerhub. I am using a variation of the following docker-compose.yml file:

version: "2.1"

services:
  test1:
    image: "dockerhub/example:latest"
    container_name: test1
    devices:
      - '/dev/ttyACM0:/dev/ttyACM0'

  test2:
    image: "dockerhub/example2:latest"
    container_name: test2
    restart: unless-stopped
    volumes:
      - test-data:/data

volumes:
    test-data:
      driver: local

I believe that I am running into that same issue. Is there a work around for now? Could I push the images to the balena registry? I am using openbalena btw.

6

I think the best workaround for now would be to use the specific image sha256 for the target architecture. For example:

netdata/netdata@sha256:b192922c4c1ecb3462326826d44d00d45e42703acaa57a935efedf555dbc32da

There is also the platform: field in docker-compose you could use.

I’m not 100% sure platform: will be respected by balena deploy but in the worst case you could run a compose build/pull first, then a balena deploy and it will happily push the images you already pulled/built.

docker-compose pull
balena deploy <app>

Either of these methods should work until we have worked out the required CLI change.

1 Like
8

Thank you! I am now no longer receiving the exec format error I was getting before with the x86 images. However, it seems like the service is stuck repeating the following error:

 Starting service 'test2 sha256:1ba6981063449c80303a14265c574954f8ca88ceeddd42a9326fbf5eeb7e0e2f'

This is most likely unrelated

9

Hi Michael,

What is the CMD instruction on your dockerfile? If the command terminates immediately you will see the console reporting Service exited and since your docker-compose is configured to restart: unless-stopped the engine will restart it immediately, explaining the behavior you are seeing. If you remove the unless-stopped you should see the container stopping once and showing as stopped on the dashboard.

Let us know if that helps you

11

@pipex thank you for your help! I believe that the issue might be related to devices listed in my devices section. Would the container fail to start if that device is not plugged in/in use? The system works perfectly on one pi but not the other. The only differences being one is dev, one is prod and the aforementioned device being unplugged.

12

With “device being unplugged” you mean /dev/ttyACM0 which you reference in your compose file? Then yes, if that’s unavailable the container should not start

14

@Hades32 Thank you for your response! I believe this has been resolved by How to specify architecture in Balena Deploy - #6 by klutchell I am unsure how to mark it as the solution though

16

Hey @mchonaker, just a heads up that CLI releases v12.49.0 or later should attempt to pull the correct target architecture if all the images in the compose file are multi-arch.

However if even one of the images is single-arch it will not set the platform flag during pull, and it will print some warnings to this effect. So mixed compose files are not as well supported and we have to make certain assumptions before quietly injecting the --platform flag to the host Docker daemon.

Also if my workaround of pulling the images manually before running a build/deploy works for you that is still an option.