we are a research group and are currently using Raspbian 64-Bit with docker on our machines. Is it possible to use balena base images without the balenaOS?
Our setup:
Raspbian 64-Bit
Docker (Not the balenaEngine)
Balena base-images
Because we tried to use some of those: https://www.balena.io/docs/reference/base-images/base-images-ref/#raspberry-pi-4-using-64bit-os but all of them don’t seem to run. Everytime we want to use a RUN in a dockerfile (We tried different commands even if it’s a simple xxx --version) there is always an EXITCODE 159 at the build command. If we try to use “normal” base images they run without any issues.
The balena base images should be fine with either balenaEngine or Docker so I’m not sure what might cause the issue here. Can you please start a container with the base image above by doing docker run and run some commands from inside the container to check what’s wrong with it?
Something that jumps out at me is the architecture that your Docker version is reporting. I’m assuming you’re trying to build this on the Pi4 from the screenshot? Because you’re trying to use 64bit base images, you’ll need to use an aarch64 version of Docker to do so else of course you will only be able to use 32bit Arm base images.
Looking at the screenshot you’ve provided, it appears the Docker architecture version is linux/arm and notlinux/arm64 (from the docker version output).
This suggests to me you’re Raspbian, which I believe is still only 32 bit (though I think there are 64bit kernel releases for it now). It might be worth investigating switching to the 64bit kernel, or possibly building on a VM with 64bit support (I think there are some RPi4 64bit builders in Qemu images, too).
The kernel is 64bit, but the user space is still 32bit, that might be the issue … I don’t know if i can fix that, but if so i will post an update around next week. Thank you for your help!
Hi @all,
as i wrote last week here a “quick” reply - (sorry, got a little more text):
We changed the OS to BalenaOS, 64 Bit are working without any struggles, works almost without issues (see below). We are currently pushing local, but we will propably at least also investigate BalenaCloud to deploy our applications/microservices.
A short overview about what our project is currently doing, each now using Balena base images (We were able to shrink the used space by 70%):
Jupyter (One is used as a “webservice” with jupyter_kernel_gateway and one as a notebook viewer service)
Node
OPCUA
MongoDB (Sadly currently not using a balena base image)
Multiple OPC UA server
UnityWebGL with OPC UA connections
(Maybe also redirecting RaspPy sensor data inside a container, need to check if we can access sensor data inside docker at all)
I love that local livepush ability with balena-cli! We are now currently also able to develop on multiple OS (Win10, MacOS) without caring about the infrastructure behind, no setting up on every developer machine after installing docker.
Some issues currently (not critical, just to sum them up):
We can’t use balena.local, i guess it’s an issue with dns, we have to use the ipv4 adress to push
No host-volumes, we use them to develop on our docker containers (node_modules, Hot-Reloading) on our host. Current workaround: We comment out the volumes in our docker-compose.yml when we are deploying to a pi. Because of that we had to add the files, that would have been added by the mount, to the dockerfile build process.
Everytime one of our mongo container stops (planned), it always restarts automatically on Pi. Stopped that behaviour with restart: on-failure in docker-compose.yml. Adding this here because the behaviour is different to the one if started in Docker Win10.
I’ll just quickly go through each of your issues with a suggestion:
I’m guessing you’re using a university wifi network for local mode? Is it possible that all mDNS is blocked? I used to maintain a wifi network for a university and we blocked all peer-to-peer traffic, so this wouldn’t be unprecedented. Can you ping the devices using their mDNS hostname? (ie ping <device_short_uuid>.local) from a shell while connected to the same network).
You’re right that you cannot define volumes that connect to your local development environment, however you can created named volumes in the docker-compose.yml in which to store artifacts like node modules so that they persist across rebuilds.
You’re right that Balena’s service restart behaviour differs from that of docker’s. It makes more sense in our domain to assume that the user always wants their services to restart by default.
I agree absolutely that balena’s service restart behaviour makes sense. I just wondered at first and couldn’t find a notice in the documentation, but maybe I didn’t search long enough / wrong places.
Saw named volumes, thank you
About <device_short_uuid>.local: I am currently testing at home but the same happens at university too (via ethernet).
Maybe i wrote it a little missleading: I can do a balena scan:
And I can ping it:
I also can execute the command: balena push 2917fe1.local
But as soon as balena starts building I get an error:
If I execute the command: balena push 192.168.0.39
Balena can build those images without any issues.
I’m going to raise an issue against the balenaCLI repository to track this. Are you running 32 or 64 bit windows? How did you install balena CLI - using npm or our prebuilt binary? If you installed it with npm can I please have your node and npm versions?
Hey, my assumption here is that docker for windows (or our node module that communicates with docker does not like the .local address for the daemon, even though the CLI is happy with it. You should be able to use the IP address given by balena scan until we’ve identified and fixed the problem.
