Consider consuming upstream's static binaries about busybox HOT 14 CLOSED

from busybox.

$ docker build .
Sending build context to Docker daemon 984.6 kB
Step 1 : FROM scratch
 ---> 
Step 2 : COPY busybox-x86_64 /bin/busybox
 ---> Using cache
 ---> 92a2f6fae826
Step 3 : RUN busybox --install /bin
 ---> Using cache
 ---> e7f2a7233b3a
Step 4 : CMD sh
 ---> Running in fbc9a01b60c2
 ---> cad1d1fe033d
Removing intermediate container fbc9a01b60c2
Successfully built cad1d1fe033d
$ docker run -it --rm cad1d1fe033d
/ # ping google.com
PING google.com (172.217.4.174): 56 data bytes
64 bytes from 172.217.4.174: seq=0 ttl=50 time=22.284 ms
64 bytes from 172.217.4.174: seq=1 ttl=50 time=20.331 ms
64 bytes from 172.217.4.174: seq=2 ttl=50 time=22.942 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 20.331/21.852/22.942 ms
/ # 

from busybox.

https://busybox.net/downloads/binaries/1.26.1-i686/ has the other bits mentioned (ssl_helper, for example)

from busybox.

After doing a COPY of ssl_helper into /bin/, I can wget https URLs too (although there aren't any CA certificates in the image, so unless they're embedded into ssl_helper or wget itself, there wasn't really any actual cert verification involved). 😇

from busybox.

Heh:

/ # wget 'https://expired.badssl.com/' -O /dev/null
Connecting to expired.badssl.com (104.154.89.105:443)
null                 100% |*******************************|   469   0:00:00 ETA
/ # wget 'https://self-signed.badssl.com/' -O /dev/null
Connecting to self-signed.badssl.com (104.154.89.105:443)
null                 100% |*******************************|   477   0:00:00 ETA
/ # wget 'https://untrusted-root.badssl.com/' -O /dev/null
Connecting to untrusted-root.badssl.com (104.154.89.105:443)
null                 100% |*******************************|   575   0:00:00 ETA

from busybox.

Even with ssl_helper included, the image is ~2.148 MB

from busybox.

Comparisons:

busybox         uclibc          2a8159f2a446        15 minutes ago      1.11 MB
busybox         musl            813910e354b6        16 minutes ago      1.229 MB
busybox         glibc           38f42d82ac83        18 minutes ago      4.204 MB

from busybox.

Ah, the image is twice as big as I expected because the hard links are added in a separate layer from the busybox binary, so the image gets that binary twice. Hmm.

from busybox.

Ok, got it down to the expected ~986.2 kB by adding -s to the busybox --install line (so it uses symlinks instead of hard links).

from busybox.

New binaries were released in https://busybox.net/downloads/binaries/1.26.2-defconfig-multiarch/, so this is looking kind of promising. 😄

from busybox.

I was looking for a statically linked version of the busybox container and was going to submit an issue and then bumped into this issue.

I think it is still a good idea.

from busybox.

@kfox1111 I think you've misunderstood what this issue is about -- the binaries in the busybox image (minus the busybox:glibc variant) are already static binaries today:

FROM scratch
COPY --from=busybox /bin/busybox /bin/
RUN ["/bin/busybox", "--install"]
RUN echo 'it works!'

This issue is debating whether we should consume the binaries that upstream is publishing directly, which appear to still have drawbacks that make them less interesting.

from busybox.

Oh. that was not clear, as it mentions various libc's in the tags. (https://hub.docker.com/_/busybox) but none that is just static. I was looking for one with just a busybox binary in it. I assumed the various libc's were included in the containers. I guess latest works for me then. Thanks for the pointer.

from busybox.

The upstream binaries here are not comprehensive, so I think we're going to stick with our build-from-source methods for now. 👍

from busybox.