Lack of support/ Quality of life for offline usage

[dansnipe]

When attempting to install chart in an offline environment, there are undeclared dependencies on kasm/share, and busy box. Additionally, the image registry is not made use of within the chart so non docker.io endpoints require the chart to be customised deeply to support independent repositories.

[mmcclaskey]

Thank you for the feedback, that makes sense.

[dansnipe]

Additionally, there appears to be an issue on deployment where the initialisation of the database can fail if passwords are not set to changeme, as the script in the db init container connects with a templates file, but never updates the yaml config where the passwords are stored and used to configure the instance.

[dansnipe]

Oh, and the usage of curl in the TPL files makes it challenging to use non docker.io sources, so suggest using a passed in repository value via a parameter of .repository, so the calls to the curl (wait for service to start) helper can the pass in the repository value from the values file.

[dansnipe]

Beyond that, think there’s an issue with initialisation where some containers are struggling to resolve internal dns. Suggest adding a toggled Boolean option for just using cluster ip addresses for all components, followed by a single ingress fqdn. Just to rule this kind of behaviour out when prototyping development and deployments.

[bscarbrough]

When attempting to install chart in an offline environment, there are undeclared dependencies on kasm/share, and busy box. Additionally, the image registry is not made use of within the chart so non docker.io endpoints require the chart to be customised deeply to support independent repositories.

I get your point about the use of busybox and curl, and I'll take care of those. However, I don't think I understand the issue with a custom/private Docker registry. In the values.yaml file, there is a section at the top for your Docker Registry/Repo login. You add the pullCredentials settings in the block below, and Helm will create a secret used by K8s to authenticate to your private registry.

  image:
    pullSecrets: ""
    pullPolicy: IfNotPresent
    restartPolicy: Always
    ## @param global.image.pullCredentials Global object to create Docker registry credentials
    ##  Example
    ##    pullCredentials:
    ##      registry: "docker.io/kasmweb"
    ##      username: "docker_username"
    ##      password: "dckr_pat_xxxxxxxxxxx"
    ##      email: "user@mail.com"
    ##      
    pullCredentials: {}

Once you add those credentials, you can modify the image: setting in the kasmApp.<kasm service name>.image: fields to reference your private registry image path. For example, if I were using an image in a gitlab registry, my values.yaml for those settings might look something like this (if your private registry doesn't require authentication, you can skip Login Credentials block).

Login Credentials

  image:
    pullSecrets: "regLogin"
    pullPolicy: IfNotPresent
    restartPolicy: Always
    pullCredentials:
      registry: "registry.gitlab.com"
      username: "gitlab_registry_username"
      password: "gitlab_registry_password"
      email: "gitlab_email@company.com"

Referencing the custom registry/image

The ellipses below are used to indicate additional data between blocks to reduce the amount of code for readability

kasmApp:
...
  kasmProxy:
    ...
    image: registry.gitlab.com/some/private/registry/path/kasm_proxy
    tag: tag_used_for_custom_image
    ...
  db:
    ...
    image: registry.gitlab.com/some/private/registry/path/kasm_postgres
    tag: tag_used_for_custom_image
    ...

Configuring it this way allows K8s to authenticate using the provided credentials, and defining the image: and `tag: fields for each image allows you to reference any path or tag you need to for your own registry.