Skip to content
This repository has been archived by the owner on Dec 18, 2024. It is now read-only.

Simplify kuksa-client docker build and reducing resulting image size #683

Conversation

SebastianSchildt
Copy link
Contributor

@SebastianSchildt SebastianSchildt commented Oct 6, 2023

This fixes #682

On a high level

  • switch to a glibc build
  • this reduced build times as grpc wheels exist
  • as a side effect the existing glibc wheels are already small
  • using pyinstaller only ship the parts of python necessary to run the client, thus reducing size over using a python base image

This fixes the huge size of the arm image, while at the same time even reducing the amd64 image compared to master

Arm64 size now

ttl.sh/kuksa.val/kuksa-client-ff43b39d56fff605c6330c078dea4b383cade50f        latest                 e2dce0b872fd   About a minute ago   73.1MB

@SebastianSchildt SebastianSchildt force-pushed the fix/kuksa-client-container-image-size branch from 74cfdd1 to 988d523 Compare October 6, 2023 14:15
@SebastianSchildt SebastianSchildt marked this pull request as ready for review October 6, 2023 14:19
RUN apk update && apk add git alpine-sdk linux-headers
RUN pip install --upgrade pip build

FROM python:3.10-slim-bookworm as build
Copy link
Contributor

@erikbosch erikbosch Oct 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we possibly document our strategy (and experiences) for Docker environments somewhere. Like, should we stop using alpine everywhere? Today we have a quite big mix, and are there not some possible benefits of using the same environment as often as possible?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"probably", although I think it might differ depending on technology

So "historically" there was Alpine used, as for the C++ Val-Server it really made a difference size-wise.

For Python based things the savings are not that large, and using glibc builds are just easiest. Current stable debian just seems a common choice in many docker workloads. The solution here basically already includes learnings from the past , e.g. the pyinstaller technique from DBC feeder, except it does not condense all pyinstaller collected things in one file (as it does not offer benefits inside a container, but a runtime penalty unpacking it)

For rust it is a bit different, as we are using "from scratch" images (e.g. only one binary in the container, no distro), and glibc isn't really suited to be statically linked - you CAN do it, but then some rust crates/dependecies break that, hence we have MUSL there.

tldr; We should, I think this on represents our current "best practice" in pyhton, and maybe we should adapt our python stuff

Copy link
Contributor

@erikbosch erikbosch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a very basic check:

  • Download container
  • Start it and verify that KUKSA client starts and connect successfully to Databroker (insecure mode)
    That worked, that is good enough for me

@SebastianSchildt
Copy link
Contributor Author

I tested secure. lgtm.

@SebastianSchildt SebastianSchildt merged commit d228999 into eclipse:master Oct 10, 2023
5 checks passed
@SebastianSchildt SebastianSchildt deleted the fix/kuksa-client-container-image-size branch October 10, 2023 14:02
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

kuksa-client docker > 400MB on ARM
2 participants