-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split the Gitpod app from the Workspace images in the KOTS installer #10359
Comments
When this ticket is accepted, the first stage should be to download the bundle, remove the Personally, I don't think we should invest much time in this if the potential results are not significant (we can debate what "significant" means of course) |
Removing all IDEs except vscode and switching to workspace-base instead of full, I was able to re-compression the airgap bundle to 2.7gb. The VSCode web IDE image is 700mb while the VScode remote image is 14mb, so doesn't make sense to remove the remote image. That would get to a "hello $gitpod" level of use. |
Experimented with a script that creates an air-gap bundle with images that have changed between two releases only: https://github.com/gitpod-io/gitpod/compare/clu/diff-airgap-bundle Still in an experimental state. However, looks quite promising. We could add something like this to our build pipeline to create airgap diff bundles for each release. |
I had a bit of brainwave about this the other day and suspect this might be a good way to go. The first step would be to remove all the The second step would be to do something with the
Realistically, what we need is something between the two - perhaps a My suggestion is to have a
The This would have the effect of reducing the size of the airgap bundle to it's smallest possible size and, because Docker pull/push is correctly cached, it would reduce the time in downloading unnecessary images. |
Thanks for your input, Simon. I would like to add my thoughts on some weak points of this approach that we should consider for the final concept.
That means even for the first install, you need to push the air-gap bundle and need the additional step of pushing the Gitpod images.
Could we expect, that there is always a computer that has access to the public registries as well as the private registries (in order to pull and push images)? I mean, downloading an image bundle and copying it via Mitigation: You export the images on your local computer and copy them to the machine in the air-gap network to push them.
The weak point here is that you rely on the local Docker cache. If you prune the Docker cache of your laptop or another colleague is pulling the images, then the cache will not help, right? With my experiment above, I created a list of images that differ between 2 versions. That would solve the issue of relying on the Docker cache. |
The biggest issue with this approach is that we need to build such a bundle that is customer-specific. We could prepare it in a werft job but adding the user-specific app.tar.gz needs some kind of web service (or we need to build a dedicated bundle for each customer in advance and upload it to a bucket). Alternative approach: We let build a minimal air-gap bundle with KOTS (without the additional images) as Simon proposed above. Additionally, we build a small CLI tool that pulls the images that have changed between 2 versions (the diff – similar to my experimental script above) and that adds these images to the downloaded air-gap bundle (with tar). With that approach, they would get a personalized, minimal air-gap bundle that they can copy / upload and use with KOTS. That would move the air-gap bundle creation from a web service to the local computer of the customer. Advantage:
Still a weak point: Needs an additional step for all installations (even the first one). Disadvantage: We need to build and distribute a CLI tool (however, could also be part of the installer if we really want to avoid this). |
@corneliusludmann sorry, I missed your response earlier.
Yes, that's a downside to my approach. The intention is the increased speed is enough of a mitigation - I can see that one person may think so and another may think not.
Partly. We could add a check in the script so that, if the tag exists in the registry, it doesn't pull it down in the first place. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Is your feature request related to a problem? Please describe
The latest airgap bundle is now 11GB, because of how the Replicated web installation works, users are required to upload the entire .airgap file to the UI even if they've already staged the images. This is because the application payload is in the same bundle as the images.
The massive airgap bundle size means that doing any deployment with airgap is slow and difficult, especially when using the web UI which is required if you're not familiar with the CLI only methods to perform an installation (or upgrade).
ie, intellij java image is 3gb, what use of this is to a vscode only installation?
Related to #10298 as we'd need to support having different registries for different purposes in Gitpod - one for workspaces vs one for hosting Gitpod's specific images.
Describe the behaviour you'd like
Only the very minimal base image should ship with the installer, so that upgrades and installations don't require pushing > 8gb of unnecessary images. The configuration of the default image and registry should be exposed as well, so users can change this as they go.
Documentation on how to pull/push other workspace images should be provided as an alternative. Workspace images could be populated with other registry mirroring systems since in essence it is requiring the users to grab
latest
of the workspace images (which is what we do when we build an airgap anyway).Related Context
The text was updated successfully, but these errors were encountered: