Can anyone help understand why the balenalib base images (for Beaglebone Green at least) are much larger than the base alpine images?
balena run balenalib/beaglebone-green-alpine:3.11: 60MB
balena run alpine:3.11: 4MB
I tried to use the plain alpine:3.11 image as the parent FROM image in a Dockerfile and it resulted in an amd64 image, rather than ARM.
If I use arm32v7/alpine:3.11 as the parent FROM image then the apk add commands in the Dockerfile fail as follows:
[Info] Building for armv7hf/beaglebone-green
[Info] Emulation is enabled
[Debug] Found build tasks:
[Debug] main: build [.]
[Debug] Resolving services with [beaglebone-green|armv7hf]
[Debug] Found project types:
[Debug] main: Architecture-specific Dockerfile
[Debug] Prepared tasks; building...
[Build] Built 1 service in 0:01
[Build] main [=========> ] 47% Step 11/23: standard_init_linux.go:211: exec user process caused "no such file or directory"
[Error] Build failed
The command '/bin/sh -c apk add avahi avahi-tools' returned a non-zero code: 1
Error: The command '/bin/sh -c apk add avahi avahi-tools' returned a non-zero code: 1
at Stream.<anonymous> (/snapshot/versioned-source/node_modules/resin-docker-build/build/builder.js:181:23)
I guess the balenalib images would make most sense if they were not so large, does anyone know why they might be so large vs plain alpine images?
But failing that, is it possible to do apk add (even if not install_packages) in a non-balenalib image?
Inside the balenalib/beaglebone-green-alpine:3.11 we do install some device specific packages so the size is larger than the barebone alpine linux image. If you need a smaller base images, I think you can start with the generic armv7hf base images (balenalib/armv7hf-alpine:3.11) which is 29.1 MB only.
Thanks a lot for the reply, that should be a good start.
The plain (not Balenalib) alpine:3.11 image is only 4MB vs 29MB. I have been able to download and run that from the target, but I’d like to be able to use it in a Dockerfile as well. Do you know why apk add fails in a Dockerfile based on plain alpine?
The error is:
The command '/bin/sh -c apk add avahi avahi-tools' returned a non-zero code: 1
Error: The command '/bin/sh -c apk add avahi avahi-tools' returned a non-zero code: 1
at Stream.<anonymous> (/snapshot/versioned-source/node_modules/resin-docker-build/build/builder.js:181:23)
The same command works if I base the Dockerfile on a Balenalib image.
If I use a non-Balenalib base image like this in a Dockerfile then adding any packages in the Dockerfile fails:
[Info] Building for armv7hf/beaglebone-green
[Build] Built 1 service in 0:01
[Build] main [=========> ] 47% Step 11/23: standard_init_linux.go:211: exec user process caused "no such file or directory"
[Error] Build failed
The command '/bin/sh -c install_packages avahi avahi-tools' returned a non-zero code: 1
If I use a Balenalib base image then apk add and install_packages work fine.
Thanks, yes I’m using apk add with the non-Balena ones. This one fails for me:
FROM arm32v7/alpine:3.11
RUN apk add avahi
Build:
[Build] haproxy Step 1/2 : FROM arm32v7/alpine:3.11
[Build] haproxy ---> c4fe9b047d15
[Build] haproxy Step 2/2 : RUN apk add avahi
[Build] haproxy ---> Running in 765a5a053ed0
[Build] haproxy standard_init_linux.go:211: exec user process caused "no such file or directory"
[Build] Built 10 services in 0:02
[Error] Deploy failed
The command '/bin/sh -c apk add avahi' returned a non-zero code: 1
[Build] haproxy Step 1/2 : FROM arm32v6/alpine:3.12
[Build] haproxy ---> 3ddac682c5b6
[Build] haproxy Step 2/2 : RUN apk add avahi
[Build] haproxy ---> Running in c6ce8f2f9c29
[Build] haproxy standard_init_linux.go:211: exec user process caused "no such file or directory"
[Build] Built 10 services in 0:05
[Error] Deploy failed
The command '/bin/sh -c apk add avahi' returned a non-zero code: 1
Hi there – one thing I’d like to clarify: can you please provide the whole command that you’re running, and where you’re running it (x86 laptop, on a Beaglebone, in a VM, etc)? I’m trying to determine if you are running balena build (which would build using the local Docker or balenaEngine daemon), balena push (which would use our own builders), or something else.
For the record, with this Dockerfile:
FROM arm32v6/alpine:3.12
RUN apk add avahi
and a test application named beagleboneApp, with device type beaglebone-green, I get the following results:
balena build -a beagleboneApp, run on my x86 laptop: main standard_init_linux.go:211: exec user process caused "exec format error". Exp[ected, since the architectures don’t match.
balena push beagleboneApp, run on my x86 laptop: pushes to balena builders and works – the VM running the build matches the architecture needed by the container.
(I don’t have a Beaglebone device, I’m afraid, so I can’t try this locally.)
Are you able to share details of how you’re doing this?
Ah, so we can’t do any package installation when using vanilla (non-Balenalib) base images in a Dockerfile? I thought the same sort of emulation / qemu tricks would be possible.
I’m building locally on an x86 laptop using: balena build --application test_app --emulated (test_app is for beaglebone_green)
I also get the same results for the following but it sounds like that is to be expected: balena build --deviceType beaglebone_green --arch armv7hf balena build --deviceType beaglebone_green --arch armv7hf --emulated
So if you want to take advantage of the smaller vanilla Alpine base image (4MB vs Balenalib’s 29MB) then you have to build on native ARM?
In general, the difference in the size is because balena base images add several packages to your image. Example:
Please note, that balenaCloud-managed devices use deltas in order to deliver updates to your application. Since those packages don’t change, they will not be included in the deltas. So unless the disk space is critical in your use case, those extra packages should not be a big issue.
Would you elaborate on your use case? How critical is the disk space?
Speaking about the builds, with the non-balena images, it’s also related to issues with multi-platform builds in the docker engine. We actually work on a change in balena CI that will leverage some docker experimental features and might also fix this use case as well. No promises though
