Welcome to our comprehensive How-To Guide for using kosi. Whether youre a beginner aiming to understand the basics or an experienced user looking to fine-tune your skills, this guide is designed to provide you with detailed step-by-step instructions on how to navigate and utilize all the features of kosi effectively.
In the following sections, you will find everything from initial setup and configuration, to advanced tips and tricks that will help you get the most out of the software. Our aim is to assist you in becoming proficient with kosi, enhancing both your productivity and your user experience.
Lets get started on your journey to mastering kosi!
1 - How to manually push images to your KubeOps-Registry project space
Quick Guide, how you can push your own images to your KubeOps-Registry project space.
How to manually push images to your KubeOps-Registry project space
To manually push container images into your KubeOps-Registry project space, you need to use your Harbor CLI secret for authentication when using podman.
How to get your CLI secret
Click on your username and select User Profile.
On the User Profile page, you can copy or change your CLI secret if needed.
Note: Replace <username> with your KubeOps username and <CLI_secret> with your actual CLI secret.
How to push your image
After logging in, tag your image with the registry path of your KubeOps-Registry project space:
Important: In most cases, you do not need to push images manually. You can specify a local or remote image directly in your KOSI package, for example docker.io/library/nginx:latest or my-app:v1.12.1. When KOSI pushes the package, it rewrites the image reference in the package to the pushed registry image under registry.kubeops.net. After that, you can use the rewritten and pushed image in your KOSI package.
Note: Replace <local_image>, <project>, <image> and <tag> with your actual values.
podman tag <local_image>:<tag> registry.kubeops.net/<project>/<image>:<tag>
Example:
podman tag my-app:v1.12.1 registry.kubeops.net/my-project/my-app:v1.12.1
A brief overview of how you can access the kubeops-community packages.
This documentation describes how to search for, install, and manage packages from the kubeops-community hub using the Kosi CLI.
Searching for Packages
To list all available packages within the KubeOps community, you use the search command.
Command:
kosi search --hub kubeops-community
Example Output:
User
Name
Version
Description
Install
kubeops-community
hashicorp-vault
0.32.0
Official HashiCorp Vault Chart
kubeops-community/hashicorp-vault:0.32.0
kubeops-community
jenkins
5.8.142
Deploys jenkins via helm
kubeops-community/jenkins:5.8.142
kubeops-community
elasticsearch
8.5.1
Deploys elasticsearch via helm
kubeops-community/elasticsearch:8.5.1
Note: This overview shows you the exact path needed for the installation step in addition to the package name and version.
Installing Packages
Once you have found a suitable package, you can deploy it into your Kubernetes cluster using the install command. You can assign a specific name to your deployment using the --dname flag.
To view all currently installed packages and their deployment names, use the list command. The deployment name is required for updates and deletions.
Command:
kosi list
Example Output:
Deployment
Package
PublicHub
Hub
hashicorp-vault
kubeops-community/hashicorp-vault:0.32.0
kubeops-community
jenkins
kubeops-community/jenkins:5.8.142
kubeops-community
elasticsearch
kubeops-community/elasticsearch:8.5.1
kubeops-community
Updating and Deleting Packages
To modify or remove an existing deployment, use the update or delete commands and include the --dname flag to specify which deployment you are targeting.
Updating a Package
The update command executes the update logic and updates the deployment in the Kubernetes cluster.
Setting up KOSI on RHEL systems requires a few key steps, including downloading the RPM file and configuring your environment. Here’s a quick guide to help you through the process.
This guide explains how to install KOSI as a user. KOSI can only be downloaded from our official website.
Podman:
KOSI requires Podman to be installed on your machine.
Note
If you are a non-root user, ensure that the number of user namespaces (max_user_namespaces) is configured correctly. For more details, refer to this GitHub tutorial.
Install on RHEL9:
sudo dnf install podman
⚠ Caution
KOSI supports only secure registries. If you use an insecure registry, you must explicitly add it as an insecure registry in registries.conf (/etc/containers/registries.conf).
Installation Steps
Download the KOSI RPM:
Log in to your KubeOps account.
Download your desired version of the KOSI RPM from the official download page.
Install the KOSI RPM on your admin node:
Run the following commands:
Replace <path_to_rpm> with the directory path where the file is located.
Replace <kosi_file_name> with the exact RPM file name (including the .rpm extension).
$KUBEOPSROOT Variable
The $KUBEOPSROOT environment variable defines the location of the KOSI plugins, deployment.yaml, and config.yaml.
If you change the KUBEOPSROOT variable after installation, you must manually copy the updated deployment.yaml, config.yaml, and plugins.
This guide explains how to use Variables that are set by KOSI plugins inside your KOSI package.
KOSI plugins can produce internal variables during execution, which you can reference in subsequent steps of your package (for example in conditions or output messages). The following guide explains how to use variables set by various KOSI plugins and how to consume them using e.g. the if and fprint plugins (which allow conditional logic and formatted output, respectively).
Plugins that set Variables
Several plugins store their results in named variables. These include:
Firewall / Firewalld / IPTables – All three firewall plugins support a key like getFirewallStatus = "<var>". For example:
This stores the firewall status ("running" or "not running") into the variable status. You can then reference this status variable in later steps.
Hostname – The hostname plugin can get the current hostname into a variable or set a new hostname from a variable. Its keys are: get = "<var>" to save the current hostname and setVar = "<var>" to restore from a saved variable. For example:
hostname(get="oldHostname");
This saves the machine’s current hostname into the variable oldHostname.
kubeadm – The kubeadm plugin runs kubeadm commands. Its outputVar = "<var>" option captures the command’s output into a variable. For example:
This saves the kubectl get pods output into podsOutput. You can then use podsOutput in subsequent steps.
osCheck – The osCheck plugin detects the OS name and version. It has two keys: getOSVar="<var>" for the OS name and getOSVersionVar="<var>" for the OS version. For example:
This stores the OS name in osName and the version in osVersion.
set – The set plugin lets you define arbitrary variables. Use variable="<name>"; value="<something>" to create a variable. For example:
set(variable="envType";value="production");
This creates a variable named envType with value "production". Variables set by the set plugin are accessed via vars.<variableName>.
Referencing Plugin Variables
KOSI provides two main ways to use these variables:
Conditional checks with the if plugin: The if plugin evaluates an expression and branches accordingly. In the condition string, you can include plugin variables by name, enclosed in $...$. For example:
For variables set via the set plugin, access them as $vars.<name>$, e.g. $vars.envType$.
Formatted output with the fprint plugin: The fprint plugin prints a message and can include plugin-variable values. You provide a list of variable names in its variables key and placeholders {0}, {1}, etc. in the message. For example:
fprint(message="Firewall status is {0}";variables="['status']";);
For variables from the set plugin:
set(variable="userName";value="Alice");set(variable="userIP";value="10.0.0.1");fprint(message="User {0} has IP {1}";variables="['vars.userName','vars.userIP']";);
Installing KOSI packages from the KubeOps Hub simplifies the installation of packages and programs within a Kubernetes cluster. This guide outlines the steps for installing packages from public and private hubs, including offline installations.
To install KOSI packages from the KubeOps Hub on your machines, follow these steps:
Search for the Package:
Use the kosi search command to find the desired package on the KubeOps Hub.
(Refer to kosi search for more info.)
Install the Package:
Copy the installation address of the desired package and use it with the kosi install command:
If no --dname parameter is specified, a random deployment name will be generated.
Note: The deployment name is stored in the file /home/<user>/var/kubeops/kosi/deployment.yaml.
In these few steps, you can successfully install and use a KOSI package.
For additional functionality and features provided by KOSI, always refer to the Full Documentation.
Install on a machine with no internet connection
Download the Package:
Use kosi pull on a machine with an internet connection to download the package:
kosi pull [package name from hub] -o [your preferred name] --hub public
Transfer the Package:
Move the downloaded package to the machine without an internet connection (which has KubeOps installed).
Install the Package:
Install the transferred package with the following command:
kosi install -p [package name]
6 - How to install and access the Plugins from the Hub
Installing and accessing plugins from the KubeOpsHub are straightforward steps to improve your KOSI experience. Below, you’ll find a guide on how to install and access the desired plugins.
How to access the Plugins
Note: Be sure you have a supported KOSI version 2.12.X or higher.
All plugins are available as KOSI packages in the KubeOpsHub. Our plugins are grouped into several KOSI packages. To view the available packages, use the command:
After installing the plugins with our KOSI install command, the plugins are automatically placed in the associated directory ($KUBEOPSROOT/plugins) and can be used directly.
Note: You can also use the Install Tab from the output to help with installation.
7 - How to update KOSI
Updating KOSI is a straightforward process that ensures you have the latest features and security enhancements. Follow this guide to update KOSI automatically, via the package repository, or by downloading the appropriate RPM/DEB file manually.
This guide shows you how to update KOSI. KOSI can be updated via the package repository, updated automatically, or downloaded from our official website for manual installation.
Prerequisites
Before you begin, make sure the following prerequisites are met:
KOSI is designed to work with the latest versions of the following operating systems:
OS
Diskspace
Red Hat Enterprise Linux 9.6 and 9.7
500 MB
Ubuntu 24.04.02
500 MB
OpenSUSE MicroOS 20260630 (rolling release)
500 MB
⚠ Warning
Only RHEL 9.6 and 9.7 are supported. Make sure the OS version is pinned to prevent accidental updates to an unsupported version, as this may break the cluster.
KOSI supports only secure registries. If you use an insecure registry, you must explicitly add it as an insecure registry in registries.conf (/etc/containers/registries.conf).
Update Methods
You have multiple options to update KOSI, depending on your system setup and preferences.
Method 1: Automatic Update Check via Config
With KOSI config v3, a new update check feature is introduced. By default, it is disabled (checkforupdates: false).
Important: This feature is not currently supported by OpenSUSE MicroOS.
If you set checkforupdates: true, KOSI will automatically check the kubeops-repo package repository for new versions after every successful KOSI command. If a new version is available, KOSI will prompt you and ask if you want to proceed with the update.
Here is the complete config.yaml:
# file $KUBEOPSROOT/kosi/config.yamlapiversion:kubernative/sina/config/v3spec:hub:https://dispatcher.kubeops.net/v4/dispatcher/# <-- set hub urlplugins:<your kubeopsroot>/plugins/# <-- set the path to your plugin folder (~ for home or $KUBEOPSROOT don't work, it has to be the full path)workspace:/tmp/kosi/process/logging:infohousekeeping:falseproxy:falsecheckforupdates:false# <-- set to 'true' to enable update checks
Method 2: Update via Package Repository
If you have included the KubeOps package repository in your OS, you can quickly update KOSI using the standard package manager.
Update the KOSI Package:
On your admin node, update KOSI by installing the new package. This will replace the existing version. Run the following command:
# download kosi deb manually and install withsudo dpkg --install kosi-2.15.0.4_Beta0_amd64.deb # <- Replace the file with the one you downloaded.
# download kosi rpm manually and install withsudo rpm --install kosi-2.15.0.4_Beta0-0.x86_64.rpm # <- Replace the file with the one you downloaded.
A direct update on OpenSUSE MicroOS is not possible, so you have to repeat the installation steps.
1. Install KOSI
# download kosi rpm manually and install withsudo transactional-update pkg install --no-confirm --allow-unsigned-rpm --force kosi-2.15.0.4_Beta0-0.x86_64.rpm # <- Replace the file with the one you downloaded.sudo reboot now # need reboot after transactional update!sudo mkdir -p /var/kubeops/plugins
sudo cp /.snapshots/$(sudo ls -1 /.snapshots | sed '$!d')/snapshot/var/kubeops/plugins/*.dll /var/kubeops/plugins/
sudo mkdir -p /var/kubeops/kosi
sudo cp /.snapshots/$(sudo ls -1 /.snapshots | sed '$!d')/snapshot/var/kubeops/kosi/config.yaml /var/kubeops/kosi/
2. Set the KUBEOPSROOT env var
Set KUBEOPSROOT and XDG_RUNTIME_DIR in ~/.bashrc
Note These are not console commands. The following entries must be added to the end of your ~/.bashrc file.
# file ~/.bashrc# Append these values to the end of your ~/.bashrc fileexportKUBEOPSROOT=/home/<yourUser>/kubeops
exportXDG_RUNTIME_DIR=$KUBEOPSROOT
Check to see if the environment variables are still set correctly. They may be being overwritten.
echo$KUBEOPSROOTecho$XDG_RUNTIME_DIR
Check to see if the config.yaml file is still correct. It may have been overwritten.
cat $KUBEOPSROOT/kosi/config.yaml
8 - How to create SBOM for kosi packages (kosi tools sbom)
A guide on how to use the kosi tools sbom command to generate a Software Bill of Materials (SBOM) for local and hub packages.
How to use KOSI Tools SBOM
This guide shows you how to use the kosi tools sbom command to generate and display a Software Bill of Materials (SBOM) for KOSI packages. You can generate SBOMs for both locally available packages and packages hosted on a hub.
⚠ Warning
Currently kosi tools sbom can only be used by a privileged user (root) and in a non-airgap environment.
Prerequisites
Before you begin, make sure the following prerequisites are met:
Supported Operating Systems: KOSI tools are tested and supported on the following operating systems:
Ubuntu 24.04
Red Hat Enterprise Linux (RHEL) 9.6
Syft Installation: To execute the sbom command, you must have Syft installed on your machine.
A privileged user (root) and a non-airgap environment.
Installing Syft
You can easily install Syft on our supported systems using wget to download the specific package format for your OS.
# Define the Syft version (check GitHub for the current release)# https://github.com/anchore/syft/releases/SYFT_VERSION="1.46.0"# Download the .deb package with wgetwget https://github.com/anchore/syft/releases/download/v${SYFT_VERSION}/syft_${SYFT_VERSION}_linux_amd64.deb
# Install the downloaded packagesudo dpkg --install syft_${SYFT_VERSION}_linux_amd64.deb
# Define the Syft version (check GitHub for the current release)# https://github.com/anchore/syft/releases/SYFT_VERSION="1.46.0"# Download the .rpm package with wgetwget https://github.com/anchore/syft/releases/download/v${SYFT_VERSION}/syft_${SYFT_VERSION}_linux_amd64.rpm
# Install the downloaded packagesudo dnf install syft_${SYFT_VERSION}_linux_amd64.rpm
Note
Alternatively, you can install Syft universally using their official installation script:
wget -qO- https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin
Usage Options
The command syntax for generating an SBOM is as follows:
kosi tools sbom [options][<package>]
Available Arguments and Options
Option
Description
<package>
The name or path of the package.
-p, --local-package <p>
Show SBOM from a local package file (e.g., a .tgz archive).
--hub
Show SBOM directly from a package located in the KOSI hub.
-?, -h, --help
Show help and usage information.
Examples
To generate an SBOM for a package that has already been downloaded to your local file system, use the -p (or --local-package) flag followed by the file name:
To generate an SBOM for a package that is hosted on the KOSI hub without downloading it manually, specify the package name and use the --hub flag to specify the hub name:
The KOSI Proxy allows you to fetch packages and container images while blocking uploads to the internet and restricting access to a hub. This guide explains the installation and configuration steps for KOSI Proxy.
How to install KOSI Proxy
This guide shows you how to install the KOSI Proxy. The KOSI Proxy enables controlled access to packages and container images by allowing downloads while blocking uploads to the internet. This guide describes how to install, configure, and operate the KOSI Proxy and Harbor registry integration.
Architecture
The following diagram shows the architecture of the KOSI Proxy.
Packages and container images can be fetched through the KOSI Proxy.
Uploading packages and container images to the internet is blocked.
Access can also be restricted to a HUB.
Prerequisites
To install the KOSI Proxy, you need a dedicated VM running RHEL9 OS and root access.
The minimum VM requirements are:
4 CPUs
8 GB RAM
50 GB disk space
The following software must be installed on this VM:
Once all prerequisites are met, you can install the KOSI Proxy.
A values.yaml file is required for KOSI Proxy installation.
Below is an example values.yaml configuration for the environment:
# Proxy host IP addressproxyIP:10.2.10.99# Preprod config valuesproxyPassthrough:preprodproxyRegistry:registry.preprod.kubeops.netaspnetcoreEnvironment:Development# Prod config values#proxyPassthrough: prod#proxyRegistry: registry.kubeops.net#aspnetcoreEnvironment: Production
Note
Use the values for the environment you are deploying to.
For preprod, use the preprod registry and preprod config values.
For prod, use the prod registry and prod config values.
After creating the values.yaml file, the KOSI Proxy can be installed using a kosi package.
The KOSI Proxy will be installed in ~/kosi-proxy
# install kosi enterprise pluginskosi install --hub kosi-enterprise kosi/enterprise-plugins:2.2.0_Alpha4
# kosi login with your userkosi login -u <user>
# install kosi proxy with values.yamlkosi install --hub kubeops kubeops/kosi-proxy:2.13.0.1_Alpha7 -f values.yaml
Start the KOSI Proxy:
cd ~/kosi-proxy
docker compose up -d
Configure KOSI Proxy (Advanced)
The KOSI Proxy is already configured during installation; however, you can adjust additional parameters if needed.
1. Hub Whitelist
The hub whitelist can be configured in the app settings file ~/kosi-proxy/data/download-v4/appsettings.json.
By default the hubs kosi, kubeops and kosi-enterprise are set.
KOSI Proxy is installed in the folder ~/kosi-proxy.
cd ~/kosi-proxy
# show kosi proxy containersdocker compose ps
# show kosi proxy logs docker compose logs -f
# stop kosi proxydocker compose down
# start kosi proxydocker compose up -d
2. Harbor
Harbor is installed in the folder ~/harbor.
cd ~/harbor
# show harbor containersdocker compose ps
# show harbor logs docker compose logs -f
# stop harbordocker compose down
# start harbordocker compose up -d
10 - How to template within the package.kosi
TBA
11 - Create Kosi package
Creating a KOSI package is an easy and efficient way to create your own packages. This guide outlines the essential steps and commands to help you successfully create your KOSI package.
Note: This guide requires a KOSI enterprise license.
kosi create
To create a Kosi package, you must first run the kosi create command in your directory.
The kosi create command creates four files (package.yaml, template.yaml, logo.png and docs.tgz) in the current directory. These files can be edited.
kosi create
Created files:
package.yaml - Defines properties of the Kosi package. (see below)
template.yaml - Required if the template engine Scriban is to be used.
logo.png - A package-thumbnail with the size of 50x50px, for showing logo on the KubeOpsHub.
docs.tgz - A zipped directory with the documentation of the package, for showing documentation on the KubeOpsHub.
The documentation of the package is written in markdown. The file for the documentation is called readme.md.
To edit the markdown, you can unzip the docs.tgz in your directory with the command tar -xzf docs.tgz and zip it again with the command tar -czf docs.tgz docs/ after you finished.
Note: Please name your markdown files inside docs.tgz without a version-tag (docs/documentation-1.0.0.md).
Do not change the file names of any of the files above generated with the kosi create command.
package.yaml
The package.yaml defines a package in a specific version as well as the tasks needed to install it. The tasks which are used in the package.yaml are plugins, which can be created by the user.
Elements:
includes.files: Describes the files which are inluded in the Kosi package.
includes.containers: Used for docker images. A container for the docker images will be created when the kosi install, kosi update or kosi delete command is used.
installation.tasks: The tree describes the tasks (Kosi plugins), which are executed with the kosi install command.
update.tasks: The tree describes the tasks (Kosi plugins), which are executed with the kosi update command.
delete.tasks: The tree describes the tasks (Kosi plugins), which are executed with the kosi delete command.
IMPORTANT: It is required to enter the package name in lowercase.
Do not use any docker tags (:v1.0.0) in your package name.
Example package.yaml
apiversion:kubernative/kubeops/sina/user/v4# Required fieldname:kosi-example-packagev3# Required fielddescription:kosi-example-package# Required fieldversion:0.1.0# Required fieldincludes: # Required field:When "files" or "containers" are needed.files: # Optional field:IF file is attached, e.g. "rpm, .extension"input:"template.yaml"containers: # Optional field:When "containers" are needed.example:registry:docker.ioimage:nginxtag:latestdocs:docs.tgzlogo:logo.pnginstallation:# Required fieldincludes: # Optional field:When "files" or "containers" are needed.files:# Optional field:- input# Reference to includescontainers:# Optional field:- example# Reference to includestasks:- cmd:command:"touch ~/kosiExample1"update:# Required fieldincludes: # Optional field:When "files" or "containers" are needed.files:# Optional field:- input# Reference to includescontainers:# Optional field:- example# Reference to includestasks:- cmd:command:"touch ~/kosiExample2"delete:# Required fieldincludes: # Optional field:When "files" or "containers" are needed.files:# Optional field:- input# Reference to includescontainers:# Optional field:- example# Reference to includestasks:- cmd:command:"rm ~/kosiExample1"- cmd:command:"rm ~/kosiExample2"
kosi build
Now, after you created and edited the files from kosi create, you can simply build a Kosi package by just running the kosi build command in your directory.
kosi build
All files specified in the package.yaml are combined together with the package.yaml to form a kosi package.
In these few steps, you can successfully create and use the kosi package. This is the basic functionality offered by Kosi.
You can always explore Full Documentation to go through all the functionality and features provided by Kosi.