tetratelabs / archive-envoy

Archive of Envoy® release binaries
Apache License 2.0
11 stars 4 forks source link

Fix for extracting linux binaries from container image. #35

Closed cpakulski closed 2 years ago

cpakulski commented 2 years ago

To avoid hardcoding info about container layering, the following logic has been added for linux platform:

Fixes: #34 (partially) Signed-off-by: Christoph Pakulski christoph@tetrate.io

codefromthecrypt commented 2 years ago

doing it this way is more complicated and inefficient than removing the --created-by-pattern entirely. I'd recommend that instead if you feel strongly about no maintenance.

codefromthecrypt commented 2 years ago

the "not selecting layers approach" (aka just remove the --created-by-pattern) is fine for the main envoy image. You can verify in docker history the layers prior to the one containing the binary are tiny, and particularly when its -q flag is retained car will stop scanning once it finds the binaries. This is also fine for the debug image because the huge layer is actually the one with the binaries in it.

$ docker history envoyproxy/envoy:v1.22.0
IMAGE          CREATED       CREATED BY                                      SIZE      COMMENT
bfb5e3005bf8   3 weeks ago   CMD ["envoy" "-c" "/etc/envoy/envoy.yaml"]      0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   ENTRYPOINT ["/docker-entrypoint.sh"]            0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   EXPOSE map[10000/tcp:{}]                        0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   RUN /bin/sh -c adduser --group --system envo…   44.2kB    buildkit.dockerfile.v0
<missing>      3 weeks ago   COPY /docker-entrypoint.sh / # buildkit         750B      buildkit.dockerfile.v0
<missing>      3 weeks ago   COPY /etc/envoy/envoy.yaml /etc/envoy/envoy.…   1.82kB    buildkit.dockerfile.v0
<missing>      3 weeks ago   COPY /usr/local/bin/su-exec /usr/local/bin/ …   19.1kB    buildkit.dockerfile.v0
<missing>      3 weeks ago   COPY /usr/local/bin/envoy* /usr/local/bin/ #…   59.4MB    buildkit.dockerfile.v0
<missing>      3 weeks ago   RUN /bin/sh -c mkdir -p /etc/envoy # buildkit   0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   RUN /bin/sh -c apt-get update && apt-get upg…   6.83MB    buildkit.dockerfile.v0
<missing>      4 weeks ago   /bin/sh -c #(nop)  CMD ["bash"]                 0B        
<missing>      4 weeks ago   /bin/sh -c #(nop) ADD file:8a4ddbd462c1dd201…   63.2MB    

In other words, the above shows why avoiding selection of layers is fine on linux.

PS. This isn't ideal for the windows image because there are huge layers in front of the envoy binary. In any case, this drift didn't effect windows and also even if drift affects windows it may change other things, such as the path to the binary.

The more unnecessary layers, especially big ones this scans through, the higher chance the job will flake, resulting in having to re-run it, which isn't a big deal, but also not ideal. Usually there aren't any changes to the docker layout in envoy, so maintenance is infrequent.

cpakulski commented 2 years ago

Thanks for reviewing and additional info about the layering. I will change it for linux to run without selecting the layer. The other option would be to have a list of layer names and try them one by one. If they do not exist, issue a warning and extract the image without selecting the layer. Possible improvement for the future.

codefromthecrypt commented 2 years ago

thanks for the attention in learning this stuff @cpakulski