Introduction

Hypper provides Kubernetes package management for cluster admins. It is a package manager built on Helm and inspired by other package managers like zypper.

How Hypper Differs From Helm

Why build a package manager on a package manager? Helm is a package manager that tries to make few assumptions. For example, Custom Resource Definitions (CRD)s are a Kubernetes resource that extend the Kubernetes API. They can be used in various ways and there are pitfalls with them. Helm makes very few assumptions when it comes to them. Hypper is going to make some different assumptions which will result in different features.

As differences between Hypper and Helm arise they will be documented along with the reasons for the difference. This is in an effort to provide clarity.

When features from Hypper can be upstreamed into Helm they will be. In that way, Hypper can act as a testing ground for Helm. We do not expect that every feature will fit in upstream Helm.

A second element in the difference is that Helm, as a package manager, does not handle environment deployment operations. Those are left to higher level tools like Helmfile (a push model like Ansible) and the Flux Helm Operator (a pull model like Chef). Helm expects higher level tools will use Helm and charts for operating in different environments.

Hypper makes some assumptions that move it more towards the environment management. This is in a different way from Helmfile or the Flux Helm Operator, but further than Helm nevertheless.

Hypper Features Not In Helm

Repeatable Install with defined Release Name and Namespace

When dealing with system level charts you may want to have them be installed in the same namespace or with the same release name everywhere. For example, when you install a cluster wide logging service. With Hypper, you can capture this information as an annotation and only specify a different one if you want to override the default. Then when you tell Hypper to install your service it will be installed to the same location, in a repeatable manner.

Shared Dependencies

Sometimes you want to have a shared system dependency. For example, you may want to have just a single Prometheus or Istio in a cluster. When you install an application that depends on this shared dependency you want to install it if not present and leverage the existing one if present.

The additional metadata to signify these relationships will be stored as Helm chart annotations.

Optional Shared Dependencies

There are occasions where you may want a shared dependency to be optional. Instead of being checked and installed all the time you want Hypper to prompt you about using it. Or, you can tell it what to do using flags.

Hypper provides this ability for the direct chart you want to install and the additional metadata is stored in annotations.

Client Application and Software Development Kit (SDK)

Hypper provides both a client application you can use in a terminal and a SDK in Go that you can use for the development of your applications. The documentation provided here primarily focuses on chart customizations for Hypper and the client application.

The SDK documentation can be found at pkg.go.dev/github.com/rancher-sandbox/hypper. The client source provides an example of using the SDK and is in the cmd sub-directory.

Installing Hypper

This guide shows how to install the Hypper CLI. Hypper can be installed either from source, or from pre-built binary releases.

From binary releases (Linux, macOS, Windows)

Every release of Hypper provides binaries for a variety of OSes. These binary versions can be manually downloaded and installed.

  • Download your desired version
  • Unpack it (tar -zxvf hypper-v0.0.2-linux-amd64.tar.gz)
  • Find the hypper binary in the unpacked directory, and move it to its desired destination (mv linux-amd64/hypper /usr/local/bin/hypper)

From there, you should be able to run the client and add the stable repo: see hypper help.

From script (Linux, macOS, windows)

Hypper now has an installer script that will automatically grab the latest version of hypper and install it locally.

You can fetch that script, and then execute it locally. It's well documented so that you can read through it and understand what it is doing before you run it.

$ curl -fsSL -o get_hypper https://raw.githubusercontent.com/rancher-sandbox/hypper/main/scripts/get-hypper
$ chmod 700 get_hypper
$ ./get-hypper

Yes, you can curl https://raw.githubusercontent.com/rancher-sandbox/hypper/main/scripts/get-hypper | bash if you want to live on the edge.

NOTE

For installing using the script you need bash, curl/wget, and tar (openssl and sudo are optional). Please check how you can install those requisites in your OS if needed.

From source (Linux, macOS, Windows)

Building Hypper from source is a bit more work, but the best way to test the latest (pre-release) Hypper version.

You must have a working Go environment (1.14+), and a POSIX environment with the proper tools installed (git, make).

For Windows, Hypper has been tested under cygwin and it compiles correctly.

$ git clone https://github.com/rancher-sandbox/hypper/hypper.git
$ cd hypper
$ make

If required, it will fetch the dependencies and cache them, and validate configuration. It will then compile hypper, and place it in bin/hypper (bin/hypper.exe for windows).

From development builds

In addition to releases you can download and install development snapshots of Hypper from Github Actions.

On each successful CI run, artifacts are stored for that run. Just download the binaries and follow the same steps as installing from binary releases.

NOTE

Development snapshots could be in a broken state, with missing functionality or breaking changes. We do not recommend using development snapshots on your production environment.

Conclusion

In most cases, installation is as simple as getting a pre-built hypper binary. This document covers additional cases for those who want to do more sophisticated things with Hypper.

Once you have the Hypper Client successfully installed, you can move on to the quickstart guide.

Quickstart

This guide covers how you can quickly get started using Hypper.

If you already know Helm, this will be a breeze, as Hypper follows Helm's workflow and extends its functionalities to install Helm charts that have been extended to work with Hypper.

Prerequisites

The following prerequisites are required:

  1. A Kubernetes cluster.
  2. A Chart repository to install charts from.

Install Hypper

See the installation guide.

Configuring Hypper by initializing repositories

Hypper enables you to deploy Helm and Hypper charts into your Kubernetes cluster. To simplify that, the best way is to add a chart repository, for example one with Helm charts:

$ hypper repo add bitnami https://charts.bitnami.com/bitnami

You can add several repositories. Let's add a repository containing charts with some Hypper functionality:

$ hypper repo add hypper-charts https://rancher-sandbox.github.io/hypper-charts/repo

Now, you can list the repositories that Hypper can install charts from:

$ hypper repo list
NAME            URL
bitnami         https://charts.bitnami.com/bitnami
hypper-charts   https://rancher-sandbox.github.io/hypper-charts/repo

Install an example Helm chart

To install a chart, you can run the hypper install command. Hypper has several ways to find and install a chart, but the easiest is to use a repository, in this case the Bitnami chart repository.

$ hypper install mariadb bitnami/mariadb
🛳  Installing chart "mariadb" as "mariadb" in namespace "default"…
👏 Done!

Whenever you install a chart, a new release is created. So one Helm chart can be installed multiple times into the same cluster. And each can be independently managed and upgraded.

Install an example Hypper chart

Hypper charts are supersets of Helm charts with more functionality, such as specifying default release name, namespace of installation, or installing shared-dependency charts automatically. They are thought to be installed system-wide in the cluster: 1 Hypper chart for all users of the cluster. Think of them as typical system OS libraries/services.

The commands are the same as you have already used:

$ hypper install hypper-charts/our-app
❓ Install optional shared dependency "rancher-tracing" of chart "demo"? [Y/n]:
y
The following charts are going to be installed:
our-app v0.1.0
 ├─ fleet v0.3.500
 └─ rancher-tracing v1.20.002

🛳  Installing chart "fleet" as "fleet" in namespace "fleet-system"…
🛳  Installing chart "rancher-tracing" as "rancher-tracing" in namespace "istio-system"…
🛳  Installing chart "our-app" as "our-app-name" in namespace "hypper"…
👏 Done!

This time, the chart got installed with a default name our-app-name, and into a default namespace hypper. Hypper to creates the namespace if it doesn't exist (you can pass --no-create-namespace if you don't want that). It also installed its defined shared and optional shared dependencies.

Learn about releases

It's easy to see what has been released with hypper:

$ hypper ls --all-namespaces
NAME            NAMESPACE       REVISION        UPDATED                                         STATUS          CHART                           APP VERSION
fleet           fleet-system    1               2021-05-18 15:44:16.11805509 +0200 CEST         deployed        fleet-0.3.500                   0.3.5
mariadb         default         1               2021-05-18 15:44:43.106328879 +0200 CEST        deployed        mariadb-9.3.11                  10.5.10
our-app-name    hypper          1               2021-05-18 15:44:18.687033582 +0200 CEST        deployed        our-app-0.0.2                   0.0.1
rancher-tracing istio-system    1               2021-05-18 15:44:18.592656807 +0200 CEST        deployed        rancher-tracing-1.20.002        1.20.0

Uninstall a release

To uninstall a release, use the hypper uninstall command:

$ hypper uninstall fleet -n fleet-system
🔥  uninstalling fleet
✅  release "fleet" uninstalled

This will uninstall fleet from Kubernetes, which will remove all resources associated with the release as well as the release history.

If the flag --keep-history is provided, release history will be kept. You will be able to request information about that release:

$ hypper status fleet -n fleet-system
NAME: fleet
LAST DEPLOYED: Fri Mar 12 12:14:28 2021
NAMESPACE: fleet-system
STATUS: uninstalled
REVISION: 1
TEST SUITE: None

Read the help text

To learn more about available Hypper commands, use hypper help, or type a command followed by the -h flag: hypper install -h.

This section contains some "How tos" that offer practical advice and detailed instruction in an activity.

Pulling charts to the local machine

Sometimes there is a need to modify charts from a repo or just have a look at what the chart is actually doing.

For that you can use hypper pull, which will download the chart to your local machine.

Pulling a chart

$ hypper pull hypper-charts/fleet
$ ls fleet*
fleet-0.3.500.tgz

Pulling a chart and extracting it

Usually, pull will download the tar.gz chart package, but you can use --untar so instead the package is extracted automatically.

$ hypper pull hypper-charts/fleet --untar
$ ls fleet/     
charts  Chart.yaml  templates  values.yaml

Pulling a specific chart version

Pull will automatically download the latest chart version, but you can use --version to get the specified version instead.

$ hypper pull hypper-charts/fleet --version 0.3.500
$ ls fleet*
fleet-0.3.500.tgz

Changing the output dir

By default, pull will download the chart into the current dir. Use the -d flag to set the output dir.

Note: The output dir needs to exist beforehand.

$ hypper pull hypper-charts/fleet -d chartslocal
$ ls chartslocal 
fleet-0.3.500.tgz

Pulling development versions

You can use the --devel flag to pull devel versions. By default, hypper won't download, search or list devel version unless specified by the flag.

$ hypper repo add rancher-charts https://charts.rancher.io
$ hypper pull rancher-charts/fleet --version 0.3.600-rc1 --devel
$ ls fleet*
fleet-0.3.600-rc1.tgz

How to expand a chart with Hypper annotations

Hypper charts build on top of Helm charts so any chart out there will work out of the box.

But we want to go further, we want to take advantage of Hypper features like release and namespace from annotations.

This is a simple as modifying our Chart.yaml to add to its annotations.

For example using the Mysql chart from Bitnami as example, these are the contents of Chart.yaml:

annotations:
  category: Database
apiVersion: v2
appVersion: 8.0.23
dependencies:
  - name: common
    repository: https://charts.bitnami.com/bitnami
    tags:
      - bitnami-common
    version: 1.x.x
description: Chart to create a Highly available MySQL cluster
home: https://github.com/bitnami/charts/tree/master/bitnami/mysql
icon: https://bitnami.com/assets/stacks/mysql/img/mysql-stack-220x234.png
keywords:
  - mysql
  - database
  - sql
  - cluster
  - high availability
maintainers:
  - email: containers@bitnami.com
    name: Bitnami
name: mysql
sources:
  - https://github.com/bitnami/bitnami-docker-mysql
  - https://mysql.com
version: 8.5.1

But we want to install it always on the same namespace called databases.

So we will expand the Chart.yaml to look like this:

annotations:
  category: Database
+ hypper.cattle.io/namespace: databases
apiVersion: v2
appVersion: 8.0.23
dependencies:
  - name: common
    repository: https://charts.bitnami.com/bitnami
    tags:
      - bitnami-common
    version: 1.x.x
description: Chart to create a Highly available MySQL cluster
home: https://github.com/bitnami/charts/tree/master/bitnami/mysql
icon: https://bitnami.com/assets/stacks/mysql/img/mysql-stack-220x234.png
keywords:
  - mysql
  - database
  - sql
  - cluster
  - high availability
maintainers:
  - email: containers@bitnami.com
    name: Bitnami
name: mysql
sources:
  - https://github.com/bitnami/bitnami-docker-mysql
  - https://mysql.com
version: 8.5.1

We added the hypper.cattle.io/namespace: databases to the annotation, so now when we install this chart with Hypper it will install into the proper namespace without any need to passing the value on the CLI:

$ hypper install mysql/                 
🛳  Installing chart "mysql" as "mysql" in namespace "databases"…
👏 Done!

See also how we didn't to specify any name for the release? Hypper is smart enough to try to obtain the name from the annotations (like the namespace!) and if it doesn't find it, it uses the name value on the Chart.yaml

If we wanted to specify the release name in the annotations as well, we just need to add hypper.cattle.io/release-name to the annotations as we did above with the namespace and hypper will take care of setting it!

How to lint a hypper chart

We just created or modified our chart or added annotations to take advantage of Hypper features but...how do we know those annotations are correct?

It's very simple, just run hypper lint against your chart, and it will verify that the chart is well-formed.

hypper lint runs both Helm checks and Hypper checks against the chart.

If the linter encounters things that will cause the chart to fail installation, it will emit [ERROR] messages. If it encounters issues that break with convention or recommendation, it will emit [WARNING] messages. For optional features, it will emit [INFO] messages.

First, lets add the hypper-charts repo, to obtain some chart examples:

$ hypper repo add hypper-charts 'https://rancher-sandbox.github.io/hypper-charts/repo'
"hypper-charts" has been added to your repositories
$ hypper repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "hypper-charts" chart repository
🛳  Update Complete.
$ hypper pull hypper-charts/our-app --untar

Now, let's lint. For example, linting against one of our test charts with Hypper annotations should produce a warning due to a missing icon:

$ hypper lint ./our-app
==> Linting our-app/
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed

While running it against a vanilla Helm chart with no extra Hypper annotations will emit several [INFO], recommending to set certain values that Hypper supports:

$ hypper repo add bitnami https://charts.bitnami.com/bitnami
"bitnami" has been added to your repositories

$ hypper repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "hypper-charts" chart repository
...Successfully got an update from the "bitnami" chart repository
🛳  Update Complete.

$ hypper pull bitnami/mariadb --untar

$ hypper lint ./mariadb
==> Linting ./mariadb
[INFO] Chart.yaml: Setting hypper.cattle.io/release-name in annotations is recommended
[INFO] Chart.yaml: Setting hypper.cattle.io/namespace in annotations is recommended
[INFO] Chart.yaml: Setting hypper.cattle.io/shared-dependencies in annotations is optional
[INFO] Chart.yaml: Setting hypper.cattle.io/optional-dependencies in annotations is optional

1 chart(s) linted, 0 chart(s) failed

Running against a shared-dependencies annotation that is malformed will emit an [ERROR]. Let's edit the MariaDB chart, so it has a wrong shared-dependencies stanza, for example. Make the ./mariadb/Chart.yaml look like this:

# this is a diff of ./mariadb/Cahrt.yaml

annotations:
  category: Database
+  hypper.cattle.io/shared-dependencies: |
+    - name: fleet
+      version: "this-is-incorrect-0.3.500"
+      repository: "https://rancher-sandbox.github.io/hypper-charts/repo"
apiVersion: v2
appVersion: 10.5.10
dependencies:
- name: common
  repository: https://charts.bitnami.com/bitnami
  tags:
  - bitnami-common
  version: 1.x.x
description: Fast, reliable, scalable, and easy to use open-source relational database
  system. MariaDB Server is intended for mission-critical, heavy-load production systems
  as well as for embedding into mass-deployed software. Highly available MariaDB cluster.
home: https://github.com/bitnami/charts/tree/master/bitnami/mariadb
icon: https://bitnami.com/assets/stacks/mariadb/img/mariadb-stack-220x234.png
keywords:
- mariadb
- mysql
- database
- sql
- prometheus
maintainers:
- email: containers@bitnami.com
  name: Bitnami
name: mariadb
sources:
- https://github.com/bitnami/bitnami-docker-mariadb
- https://github.com/prometheus/mysqld_exporter
- https://mariadb.org
version: 9.3.11


$ hypper lint ./mariadb
==> Linting ./mariadb
[INFO] Chart.yaml: Setting hypper.cattle.io/release-name in annotations is recommended
[INFO] Chart.yaml: Setting hypper.cattle.io/namespace in annotations is recommended
[INFO] Chart.yaml: Setting hypper.cattle.io/optional-dependencies in annotations is optional
[ERROR] Chart.yaml: Shared dependency version is broken: improper constraint: this-is-incorrect-0.3.500

Error: 1 chart(s) linted, 1 chart(s) failed

Now if you were to set some kind of automated CI in place to check for linting and are required to have Hypper annotations as mandatory, you can run hypper lint with the --strict flag so all warnings are marked as errors. For now, we don't have warning-level messages.

Searching for charts in repos

Search reads through all the repositories configured on the system, and looks for matches. Searching on these repositories uses the metadata stored on the system.

It will display the latest stable versions of the charts found.

$ hypper search repo fleet
NAME                            CHART VERSION   APP VERSION     DESCRIPTION
hypper-charts/fleet             0.3.500         0.3.5           Fleet Manager - GitOps at Scale
hypper-charts/fleet-agent       0.3.500         0.3.5           Fleet Manager Agent - GitOps at Scale
hypper-charts/fleet-crd         0.3.500         0.3.5           Fleet Manager CustomResourceDefinitions

By default, it will only show the latest version that match the keyword used. In order to see all versions you can use the -l flag.

$ hypper search repo fleet-agent -l
NAME                            CHART VERSION   APP VERSION     DESCRIPTION
hypper-charts/fleet-agent       0.3.500         0.3.5           Fleet Manager Agent - GitOps at Scale

You can also search for a specific chart version by using the --version VERSION flag..

Note that VERSION needs to be a valid SemVer version.

$ hypper search repo fleet-agent --version 0.3.500
NAME              	CHART VERSION	APP VERSION	DESCRIPTION                          
hypper/fleet-agent	0.3.500      	0.3.5      	Fleet Manager Agent - GitOps at Scale

It's also possible to pass the --regexp flag to use regexp in the search.

$ hypper search repo "fleet-" --regexp
NAME                            CHART VERSION   APP VERSION     DESCRIPTION
hypper-charts/fleet-agent       0.3.500         0.3.5           Fleet Manager Agent - GitOps at Scale
hypper-charts/fleet-crd         0.3.500         0.3.5           Fleet Manager CustomResourceDefinitions

If you want to search for development charts (only stable charts are shown by default), use the --devel flag to show those development charts.

$ hypper search repo fleet-agent --devel
NAME                            CHART VERSION   APP VERSION     DESCRIPTION
hypper-charts/fleet-agent       0.3.500         0.3.5           Fleet Manager Agent - GitOps at Scale

Working with shared dependencies

Hypper charts support the concept of shared dependency charts.

A chart declared as a shared dependency is a chart that more than one chart may depend on; once deployed, it can be reused by multiple other deployments. Charts deployed as shared dependencies are the analogous of system libraries in an OS: dependencies that are used by several consumers.

Creating a Hypper chart with shared dependencies

Let's create the simplest chart possible, and add charts as shared dependencies to it.

First, we create a simple empty chart:

$ helm create our-app

Now, we can edit ./our-app/Chart.yaml, and add some shared dependencies to it:

apiVersion: v2
name: our-app
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: 1.16.0
annotations:
+ hypper.cattle.io/shared-dependencies: |
+   - name: fleet
+     version: "^0.3.500"
+     repository: "https://rancher-sandbox.github.io/hypper-charts/repo"
+ hypper.cattle.io/optional-dependencies: |
+   - name: rancher-tracing
+     version: "^1.20.002"
+     repository: "https://rancher-sandbox.github.io/hypper-charts/repo"

Shared dependencies are just normal Helm Dependencies. As such, they are defined with:

  • The name field is the name of the chart you want.
  • The version field is the version of the chart you want.
  • The repository field is the full URL to the chart repository. Note that you must also use hypper repo add to add that repo locally. You might use the name of the repo instead of URL.

We can also add a default release name and namespace, where our-app and its shared-dependencies will get installed:

apiVersion: v2
name: our-app
description: A Helm chart for Kubernetes
type: application
version: 0.1.0
appVersion: 1.16.0
annotations:
+ hypper.cattle.io/namespace: hypper
+ hypper.cattle.io/release-name: our-app-name
  hypper.cattle.io/shared-dependencies: |
    - name: fleet
      version: "^0.3.500"
      repository: "https://rancher-sandbox.github.io/hypper-charts/repo"
  hypper.cattle.io/optional-dependencies: |
    - name: rancher-tracing
      version: "^1.20.002"
      repository: "https://rancher-sandbox.github.io/hypper-charts/repo"

To verify that we did create the correctly, let's lint it:

$ hypper lint ./our-app
==> Linting our-app
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed

Listing shared dependencies

Hypper's shared-dep list command will list the shared dependencies, its status, and other information:

$ hypper shared-deps list ./our-app
NAME            VERSION         REPOSITORY                                              STATUS          NAMESPACE       TYPE
fleet           ^0.3.500        https://rancher-sandbox.github.io/hypper-charts/repo    not-installed   fleet-system    shared
rancher-tracing ^1.20.002       https://rancher-sandbox.github.io/hypper-charts/repo    not-installed   istio-system    shared-optional

Deploying shared dependencies

Now, let's pretend that we had fleet already installed, so let's install it by hand.

First, add the repos of the fleet shared dependency, so they are found when installing manually.

Note that, when hypper installs the shared dependency on its own, you don't need to add the repos.

$ hypper repo add hypper-charts 'https://rancher-sandbox.github.io/hypper-charts/repo'
"hypper-charts" has been added to your repositories
$ hypper repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "hypper-charts" chart repository
🛳  Update Complete.

Now we install fleet:

$ hypper install hypper-charts/fleet -n fleet-system
🛳  Installing chart "fleet" as "fleet" in namespace "fleet-system"…
👏 Done!

That satisfies one shared dependency of our-app:

$ hypper shared-deps list ./our-app
NAME            VERSION         REPOSITORY                                              STATUS          NAMESPACE       TYPE
fleet           ^0.3.500        https://rancher-sandbox.github.io/hypper-charts/repo    deployed        fleet-system    shared
rancher-tracing ^1.20.002       https://rancher-sandbox.github.io/hypper-charts/repo    not-installed   istio-system    shared-optional

Then, we can install our-app, and any of its missing shared dependencies. By default, Hypper asks for each optional shared dependency if we want to install it or not:

$ hypper install ./our-app
❓ Install optional shared dependency "rancher-tracing" of chart "demo"? [Y/n]:
y
The following charts are going to be installed:
our-app v0.1.0
 ├─ fleet v0.3.500
 └─ rancher-tracing v1.20.002

🛳  Installing chart "fleet" as "fleet" in namespace "fleet-system"…
🛳  Installing chart "rancher-tracing" as "rancher-tracing" in namespace "istio-system"…
🛳  Installing chart "our-app" as "our-app-name" in namespace "hypper"…
👏 Done!

What has happened?

  1. Hypper has made sure that all declared shared dependencies of our-app are satisfied, installing those that are missing, and skipping those present. Since the chart of the shared dependency didn't have annotations for default namespace, it will install them on the dependent namespace.
  2. Since we haven't specified the release name or namespace in the command, Hypper has installed our-app in the default release-name (our-app-name) and namespace (hypper) we specified in the Hypper annotations.

Let's see:

$ ./bin/hypper shared-deps list ./our-app
NAME            VERSION         REPOSITORY                                              STATUS          NAMESPACE       TYPE
fleet           ^0.3.500        https://rancher-sandbox.github.io/hypper-charts/repo    deployed        fleet-system    shared
rancher-tracing ^1.20.002       https://rancher-sandbox.github.io/hypper-charts/repo    deployed        istio-system    shared-optional

$ hypper list -A
NAME            NAMESPACE       REVISION        UPDATED                                         STATUS          CHART                           APP VERSION
fleet           fleet-system    1               2021-05-17 17:32:45.889083671 +0200 CEST        deployed        fleet-0.3.500                   0.3.5
our-app-name    hypper          1               2021-05-17 17:35:13.517422915 +0200 CEST        deployed        our-app-0.0.2                   0.0.1
rancher-tracing istio-system    1               2021-05-17 17:35:13.311231418 +0200 CEST        deployed        rancher-tracing-1.20.002        1.20.0

Yay! they are all installed.

If you want, you can always install our-app without the shared-dependencies, by passing the flag --no-shared-deps. And you can either install all optional dependencies by default with --optional-deps=all, or skip them with --optional-deps=none.

Reference guides

You can find Golang reference guides in pkg.go.dev/github.com/rancher-sandbox/hypper, particularly for the Hypper library API.