Image size is 479MB

[edsiper]

The main calyptia/core-docker-desktop image size is 479MB:

calyptia/core-docker-desktop        1.0.1               62c33894e1a3   6 hours ago     479MB

The purpose of the docker extension is to simplify the onboarding or demoing the product to prospects, if the user needs to download 0.5G is not the way to go.

Vivo image is also around 571MB.

Let's fix this.

[patrick-stephens]

It used to be twice as big!

I do agree but from my perspective I think this needs front end to look at, the only stuff in it now are the CLI and kubectl binaries plus the UI packages. If we can shrink the UI footprint that may help.

Fundamentally we have to provide binaries for all targets in the image (Windows, Linux and macOS) as that is how the extension will work so we cannot shrink these.

The removal of kubectl may help: #92

[patrick-stephens]

Looking at the breakdown of layers, it potentially is down to the base image:

The main other stuff is the binaries which we cannot shrink.

[patrick-stephens]

Not the base image, that's only 7Mb.

I think this is down to the inclusion of those binaries and that is fundamental to how the extension works @edsiper, it is not a simple image to run in the cluster but instead an image that runs but also provides native binaries to install on the host. It therefore has to include all possible host binaries plus everything to run in the cluster.

Looking at the image directly the size of the filesystem does not match the size of the image so there are some other things to include.

/ # du -h .
206.0M  /

However, a lot is covered by the binaries themselves:

/ # du -h linux/
48.1M   linux/
/ # du -h darwin/
50.8M   darwin/
/ # du -h windows/
48.3M   windows/

We're looking at removing kubectl but we will still have the CLI - potentially we could refactor things to get everything running in the cluster but it involves moving CLI or UI code into this container. @nicolasparada can you see any quick wins here to reduce size other than #92 ?

[patrick-stephens]

Yeah investigation with Dive shows it is the binaries: docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive calyptia/core-docker-desktop:1.0.1

Let's re-check after #92 is complete to see. We also need to automate the update of the CLI version used, it is currently fixed at 0.41

[edsiper]

I see between both core-extension and Vivo is around 1GB, binaries should be per container/layer thats other way to reduce the size (similar to how it works for different architectures)

[nicolasparada]

Vivo is a node.js server. It could be rewriten in go so we don't need to ship v8. Tho vivo is based on fluentbit image...

In general there is too much stuff in all of this. Sure we can trim stuff down but I don't thing it will be too much.

[edsiper]

@nicolasparada do we need to re-write the whole UI under a different framework to accomplish that ? (I am ignorant on how go + frontend works together)

[patrick-stephens]

I see between both core-extension and Vivo is around 1GB, binaries should be per container/layer thats other way to reduce the size (similar to how it works for different architectures)

Unfortunately that's not how it works for extensions, the container includes the binary for the host and is made available to it by Docker Desktop. We have a single container that then allows us to invoke the binary from the host to then run commands in the cluster, this allows us to reuse the CLI binary without reimplementing an in cluster alternative. We could do that but it's some work.

[edsiper]

92 kubectl is around 50M.

we need to find a way to reduce this image size, its too big and takes a lot to deploy it first time.

[tarruda]

I think we can still optimize vivo image a bit, it seems I made a mistake when bundling the next app in the image by adding the whole .next directory (output of next build). From this example it seems we should not copy the whole directory, which contains cache with a few dozen mb that are not needed in production.

From docker web page, the vivo image is currently ~160mb:

I think with some tweaks we might be able to reduce it to ~110mb. This article suggests we can further reduce it by using alpine as the base image instead of the official node.js images (apparently even node-slim is big).

[patrick-stephens]

@tarruda can you raise a separate issue for Vivo? Let's not confuse things in this one.

@edsiper I agree this is a good idea to reduce the size so will include on the backlog but at a lower priority than the other features we need to achieve short term. #92 will drop the image size - note that this is 3 * 50 Mb so 150 Mb total (we have a binary per OS target).

Currently the only supported option to deploy and query core instances is from a binary on the host and that is specifically what is inflating the size of the image. Therefore we have a few options:

• Make a smaller CLI binary just with the commands we require.
• Support functionality directly within the container running in the cluster.

Including the functionality directly is probably the best engineering solution but has some complexity:

• Do we just include the Golang CLI directly in the container? Just one copy for the target container.
• Is this a good first target for the operator to work on? The UI still needs to query and interact with it though.
• Do we try to replicate its behaviour in the current React code (is that possible to interact with K8S)?
• What additional privileges or configuration are required for the container and are they supported by Docker Desktop? (Can we update RBAC, etc.)?
• Longer term maintenance of whatever solution we go for (including the host binary follows our current approach everywhere and is well tested).

[patrick-stephens]

@edsiper also to focus on the specific issue raised here: the downloadable size is not 0.5Gb, that is the extracted size on disk. The compressed size that is required is ~130Mb:

[patrick-stephens]

Similarly for Vivo @tarruda the downloadable size is ~160Mb

Extracted size on disk can be significantly more, particularly if you start doing some funny things with layers.