Open edsiper opened 1 year ago
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
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.
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 ?
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
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)
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.
@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)
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.
we need to find a way to reduce this image size, its too big and takes a lot to deploy it first time.
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).
@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:
Including the functionality directly is probably the best engineering solution but has some complexity:
@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:
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.
The main calyptia/core-docker-desktop image size is
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.