kURL Airgap Bundle - include Helm CLI?

Great question from today

I have components in my application that rely on the Helm CLI being present on the host (ideally in /usr/bin but can be flexible there. I’d rather not re-work my build pipeline to package this into my docker images that need access to the Helm CLI at deployment time.

Is there a good way to have the kURL airgap bundle include a helm CLI and install it somewhere on the host? At which path would that binary be installed?

In theory you could put a wrapper around the kURL airgap bundle that includes the helm cli. But that might be adding a second layer around the existing tar.gz.
How about using the Helm docker container as part of your application. And if you need to invoke the helm cli, you run it as a k8s Job with the image:

@jdewinne are you aware of any way to do this using the helm addon in kURL to pre-install the CLI?

The helm addon for kURL is currently in alpha. It doesn’t support Airgap at the moment. So I don’t think that is a valid option.

Cool thanks – I’ll proceed with the first solution them :slightly_smiling_face:

As a vendor wanting to make airgap slightly less difficult for my customer, I’m also interested in bundling random CLI stuff somehow. Helm yes, for airgap+helm situations but also: support-bundle and preflight and others.

@Mitch What do you mean with bundling random CLI stuff? Like binaries, that need to land on some node and/or client host?
The download portal does contain the binaries for running the support-bundle and preflight as kubectl plugins. Are those the ones you’re looking for?

Sounds like maybe one tarball with the following would be useful?

  • kots CLI binary
  • preflight and support-bundle binaries
  • default yaml spec\ for preflight.yaml and the support-bundle.yaml used in kubectl kots support-bundle https://kots.io
  • maybe even the kots app airgap release and license file for the customer? to allow for a one-line airgap existing cluster install once the bundle is untarred?

How about a simple script that packages all these? That way, you can re-run the script each time there’s a new version, and share it with any prospect for initial install.

Another use case for this maybe a installer patch file. You may have a customer with a unique set of requirements that means you have to modify your kURL spec. You could create a patch file to set the specific configurations for that customer. Being able to include that file reduces the need to track a separate file.