endpoints-runtime:2 containers are very large (1.34GB)

[timburks]

I noticed that the ESPv2 containers are much larger than the ones for ESPv1:

$ docker images
REPOSITORY                                   TAG             IMAGE ID       CREATED          SIZE
gcr.io/endpoints-release/endpoints-runtime   2               9af8d1152fa8   4 months ago     1.34GB
gcr.io/endpoints-release/endpoints-runtime   1               52a065a2c843   2 years ago      170MB

Nearly all of this is due to the envoy binary:

$ docker run -t -i --entrypoint /bin/sh gcr.io/endpoints-release/endpoints-runtime:2
/ $ ls -l /bin/envoy
-r-xr-xr-x    1 root     root     1183328376 Oct 17 18:14 /bin/envoy

As a test, I ran strip on the envoy binary and the result was much smaller.

$ docker run -t -i --entrypoint /bin/sh ghcr.io/timburks/esp-v2:latest
/ $ ls -l /bin/envoy
-r-xr-xr-x    1 root     root      34366336 Feb 19 22:05 /bin/envoy

$ docker images
REPOSITORY                                   TAG             IMAGE ID       CREATED          SIZE
ghcr.io/timburks/esp-v2                      latest          81c2c28ace54   46 minutes ago   218MB

What do you think about adding strip to the official build process?

[fredo838]

The actual impact of the images being so large, is that it makes the cold start time in Google Cloud Run for the espv2 containers about ~1.5s.

[fredo838]

You can do it yourself with this Dockerfile:

FROM gcr.io/endpoints-release/endpoints-runtime-serverless:2 as strip
USER root
RUN apk update && apk add binutils
RUN strip /bin/envoy

FROM scratch
COPY --from=strip / /
ENV ENDPOINTS_SERVICE_PATH /etc/endpoints/service.json
COPY service.json ${ENDPOINTS_SERVICE_PATH}
RUN chown -R envoy:envoy ${ENDPOINTS_SERVICE_PATH} && chmod -R 755 ${ENDPOINTS_SERVICE_PATH}
USER envoy
ENV ESPv2_ARGS ^++^--cors_preset=basic
ENTRYPOINT ["/env_start_proxy.py"]

This will generate a version which is ~180Mb in size and still works on Google Cloud Run.

[fredo838]

I tested the latency on Google Cloud Run, seems like I'm still getting the same latencies, so I guess it's not that big of an issue. I was wrong!