This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

KOSI

KOSI is a command line interface (CLI) used to securely create and deploy packages to clusters, nodes and other machines.
Try KOSI

Follow quickstart guides to learn how to securely deploy packages to clusters, nodes and other machines.

1 - Release Notes

Delve into our latest release notes, providing a comprehensive overview of the exciting updates and enhancements in our newest KOSI version.

1.1 - KOSI Versions

KOSI versions and deprication dates

Here are the current supported KOSI Versions. The list contains: The KOSI version, Supported KOSI language version, Supported KOSI plugins and the Deprication date of all KOSI versions. X of the versions must be X of the plugins

KOSI Supported KOSI language Supported KOSI plugins Deprecation date
KOSI 2.12.X v1.0.0 Plugins 1.7.X TBD
KOSI 2.11.X v1.0.0 Plugins 1.6.X 01.11.2025
KOSI 2.10.X v0.1.0 Plugins 1.5.X 12.03.2025

1.2 - KOSI 2.12.0.19

Changelog KOSI 2.12.0.19

New

  • Added Licence verification
  • Increase Upload-size for packages to 3Gb

Change

  • Clientrequest timeouts set to 60 seconds
  • Changed the image format on push to OCI

Update

  • Update Dependencies
  • Update plugins

Bugfix

  • KOSI lint linting package.yaml correctly
  • fixed templating in lists
  • fixed issue when pushing image to localregistry and not being authorized
  • fixed an issue where kosi install with multiple value-files was not possible

BREAKING CHANGE

KOSI 2.12.0 does not support the old dispatcher url. it requires the new dispatcher: dispatcher.kubeops.net/v4/dispatcher.

Changelog Plugins 1.7.0

New

  • set plugin: for setting variables

Change

  • move some messages from info to debug in template-plugin and if-plugin
  • change file destination from pia ssh-mode from /home/pia to /var/kubeops/pia

Update

  • Update Dependencies

Bugfix

  • fixed an issue that kosi plugin pull command requires retag buts optional
  • fixed an issue that kosi plugin pull was not able to pull packages.
  • fixed an issue that kubectl run operation was not executed correctly.

1.3 - KOSI 2.12.0.13_Beta0

Changelog KOSI 2.12.0.13_Beta1

New

  • Added Licence verification
  • Increase Upload-size for packages to 3Gb

Change

  • Clientrequest timeouts set to 60 seconds
  • Changed the image format on push to OCI

Update

  • Update Dependencies
  • Update plugins

Bugfix

  • KOSI lint linting package.yaml correctly
  • fixed templating in lists
  • fixed issue when pushing image to localregistry and not being authorized
  • fixed an issue where kosi install with multiple value-files was not possible

BREAKING CHANGE

KOSI 2.12.0 does not support the old dispatcher url. it requires the new dispatcher: dispatcher.kubeops.net/v4/dispatcher.

Changelog Plugins 1.7.0

New

  • set plugin: for setting variables

Change

  • move some messages from info to debug in template-plugin and if-plugin
  • change file destination from pia ssh-mode from /home/pia to /var/kubeops/pia

Update

  • Update Dependencies

Bugfix

  • fixed an issue that kosi plugin pull command requires retag buts optional
  • fixed an issue that kosi plugin pull was not able to pull packages.
  • fixed an issue that kubectl run operation was not executed correctly.
  • fixed an issue that cmd plugin could not work if SHELL env was not set.

1.4 - KOSI 2.12.0.12_Beta0

Changelog KOSI 2.12.0.12_Beta0

New

  • Added Licence verification
  • Increase Upload-size for packages to 3Gb

Change

  • Clientrequest timeouts set to 60 seconds
  • Changed the image format on push to OCI

Update

  • Update Dependencies
  • Update plugins

Bugfix

  • KOSI lint linting package.yaml correctly
  • fixed templating in lists
  • fixed issue when pushing image to localregistry and not being authorized
  • fixed an issue where kosi install with multiple value-files was not possible

BREAKING CHANGE

KOSI 2.12.0 does not support the old dispatcher url. it requires the new dispatcher: dispatcher.kubeops.net/v4/dispatcher.

Changelog Plugins 1.7.0

New

  • set plugin: for setting variables

Change

  • move some messages from info to debug in template-plugin and if-plugin
  • change file destination from pia ssh-mode from /home/pia to /var/kubeops/pia

Update

  • Update Dependencies

1.5 - KOSI 2.12.0.12_Alpha1

Changelog KOSI 2.12.0.12_Alpha1

New

  • Added Licence verification
  • Increase Upload-size for packages to 3Gb

Change

  • Clientrequest timeouts set to 60 seconds
  • Changed the image format on push to OCI

Update

  • Update Dependencies
  • Update plugins

Bugfix

  • KOSI lint linting package.yaml correctly
  • fixed templating in lists
  • fixed issue when pushing image to localregistry and not being authorized
  • fixed an issue where kosi install with multiple value-files was not possible

BREAKING CHANGE

KOSI 2.12.0 does not support the old dispatcher url. it requires the new dispatcher: dispatcher.kubeops.net/v4/dispatcher.

Changelog Plugins 1.7.0

New

  • set plugin: for setting variables

Change

  • move some messages from info to debug in template-plugin and if-plugin
  • change file destination from pia ssh-mode from /home/pia to /var/kubeops/pia

Update

  • Update Dependencies

1.6 - KOSI 2.12.0.11_Alpha0

Changelog KOSI 2.12.0.11_Alpha0

New

  • Added Licence verification
  • Increase Upload-size for packages to 3Gb

Change

  • Clientrequest timeouts set to 60 seconds
  • Changed the image format on push to OCI

Update

  • Update Dependencies
  • Update plugins

Bugfix

  • KOSI lint linting package.yaml correctly
  • fixed templating in lists
  • fixed issue when pushing image to localregistry and not being authorized

BREAKING CHANGE

KOSI 2.12.0 does not support the old dispatcher url. it requires the new dispatcher: dispatcher.kubeops.net/v4/dispatcher.

Changelog Plugins 1.7.0

New

  • set plugin: for setting variables

Change

  • move some messages from info to debug in template-plugin and if-plugin
  • change file destination from pia ssh-mode from /home/pia to /var/kubeops/pia

Update

  • Update Dependencies

1.7 - KOSI 2.11.8

Changelog KOSI 2.11.8.0

Update

  • update supported plugins to 1.6.8
  • update dependencies

Bugfix

  • fixed an issue where the user don´t get any notification, that image push failed
  • fixed an issue where kosi install with multiple value-files was not possible

Changelog Plugins 1.6.8

Update

  • Update Dependencies

Bugfix

  • fixed an issue that kosi plugin pull command requires retag buts optional
  • fixed an issue that kosi plugin pull was not able to pull packages.
  • fixed an issue that kubectl run operation was not executed correctly.
  • fixed an issue that cmd plugin could not work if SHELL env was not set.

1.8 - KOSI 2.11.7

Changelog KOSI 2.11.7.1

Update

  • update supported plugins to 1.6.7
  • update dependencies

Bugfix

  • fixed an issue where the user don´t get any notification, that image push failed
  • fixed an issue where kosi install with multiple value-files was not possible

Changelog Plugins 1.6.7

Change

  • Move some messages from info to debug in template-plugin and if-plugin
  • KOSI plugin local package paths now working proberly

Update

  • Update Dependencies

1.9 - KOSI 2.11.6

Changelog KOSI 2.11.6.1

Update

  • update supported plugins to 1.6.6
  • update dependencies

Bugfix

  • fixed an issue where the user don´t get any notification, that image push failed

Changelog Plugins 1.6.6

Change

  • Move some messages from info to debug in template-plugin and if-plugin
  • KOSI plugin local package paths now working proberly

Update

  • Update Dependencies

1.10 - KOSI 2.11.5

Changelog KOSI 2.11.5.1

Update

  • update supported plugins to 1.6.5

Change

  • fixed templating in lists

Known Issues

  • digists as string templating in lists could be recognized as int.

1.11 - KOSI 2.11.4

Changelog KOSI 2.11.4.0

Bugfix

  • KOSI lint linting package.yaml correctly

1.12 - KOSI 2.11.3

Changelog KOSI 2.11.3.0

Change

  • Change image format for pushing packages to registry to OCI.

Known Issues

  • KOSI lint just linting a package.kosi for linting package.yaml it will throw an unable to cast exception.

1.13 - KOSI 2.11.2

Changelog KOSI 2.11.2.0

Fixed

  • Fixed an issue where invalid permissions was not displayed correctly

1.14 - KOSI 2.11.1

Changelog KOSI 2.11.1.1

Fixed

  • Fixed an issue where duplicate podman errors could be occured

1.15 - KOSI 2.11.0

Changelog KOSI 2.11.0

New

  • added kosi language version check
  • increase user experience, with removing the single, double-quote scenario
  • added Debian-package support for KOSI.
  • Batchengine V2 Plugin Support
  • kubeops commons remove observer method

Update

  • update KOSI plugin
  • update KOSI Basic Plugins
  • update KOSI Professional Plugins
  • update KOSI Enterprise Plugins

Fixed

  • bugfix unable to cast object of type Tree to Boolean
  • bugfix podman push force compression
  • bugfix kosi tmp path
  • bugfix missleading error for removing package when not logged in
  • bugfix missleading error for using encrypted files as value files and vice versa
  • bugfix consider KUBEOPSROOT environment variable at Installation
  • bugfix immutable image sha tag

1.16 - KOSI 2.11.0 Beta1

Changelog KOSI 2.11.0_Beta1

New

  • added kosi language version check
  • increase user experience, with removing the single, double-quote scenario
  • added Debian-package support for KOSI.
  • Batchengine V2 Plugin Support
  • kubeops commons remove observer method

Update

  • update KOSI plugin
  • update KOSI Basic Plugins
  • update KOSI Professional Plugins
  • update KOSI Enterprise Plugins

Fixed

  • bugfix unable to cast object of type Tree to Boolean
  • bugfix podman push force compression
  • bugfix kosi tmp path
  • bugfix missleading error for removing package when not logged in
  • bugfix missleading error for using encrypted files as value files and vice versa
  • bugfix consider KUBEOPSROOT environment variable at Installation
  • bugfix immutable image sha tag

1.17 - KOSI 2.11.0 Beta0

Changelog KOSI 2.11.0 Beta0

New

  • added kosi language version check
  • increase user experience, with removing the single, double-quote scenario
  • added Debian-package support for KOSI.
  • Batchengine V2 Plugin Support
  • kubeops commons remove observer method

Update

  • update KOSI plugin
  • update KOSI Basic Plugins
  • update KOSI Professional Plugins
  • update KOSI Enterprise Plugins

Fixed

  • bugfix unable to cast object of type Tree to Boolean
  • bugfix podman push force compression
  • bugfix kosi tmp path
  • bugfix missleading error for removing package when not logged in
  • bugfix missleading error for using encrypted files as value files and vice versa
  • bugfix consider KUBEOPSROOT environment variable at Installation

1.18 - KOSI 2.11.0 Alpha1

Changelog KOSI 2.11.0 Alpha1

New

  • added kosi language version check
  • increase user experience, with removing the single, double-quote scenario
  • added Debian-package support for KOSI.
  • Batchengine V2 Plugin Support
  • kubeops commons remove observer method

Update

  • update KOSI plugin
  • update KOSI Basic Plugins
  • update KOSI Professional Plugins
  • update KOSI Enterprise Plugins

Fixed

  • bugfix unable to cast object of type Tree to Boolean
  • bugfix podman push force compression
  • bugfix kosi tmp path
  • bugfix missleading error for removing package when not logged in
  • bugfix missleading error for using encrypted files as value files and vice versa
  • bugfix consider KUBEOPSROOT environment variable at Installation

1.19 - KOSI 2.11.0 Alpha0

Changelog KOSI 2.11.0 Alpha0

New

  • added kosi language version check
  • increase user experience, with removing the single, double-quote scenario
  • added Debian-package support for KOSI.

1.20 - KOSI 2.10.4

Changelog KOSI 2.10.4

Change

  • Change image format for pushing packages to registry to OCI.

1.21 - KOSI 2.10.3

Changelog KOSI 2.10.3.0

Fixed

  • Fixed an issue where invalid permissions was not displayed correctly

1.22 - KOSI 2.10.2

Changelog KOSI 2.10.2

Fixed

  • Fixed an issue where duplicate podman errors could be occured

1.23 - KOSI 2.10.1

Changelog KOSI 2.10.1

Fixed

  • bugfix immutable image sha tag
  • Fixed an issue where image could be pushed comprimized

1.24 - KOSI 2.10.0 Beta0

Changelog KOSI 2.10.0_Beta0

New

  • KOSI proxy functionality
  • new KOSI package version: kubernative/kubeops/sina/user/v4
  • image SHA256 support in new package version

Update

  • update .NET framework
  • update KOSI plugin
  • update KOSI Basic Plugins
  • update KOSI Professional Plugins
  • update KOSI Enterprise Plugins

Fixed

  • Fixed an issue in push - command, which caused a missleading error message.
  • Fixed an issue in the housekeeping functionality, that prevent working properly.
  • fixed an issue in kosi pull -r -t, where images could not be pushed
  • fixed an issue in kosi pull does not retag correctly if using kosi proxy
  • fixed an issue in package.kosi where templating of lists was not working

1.25 - KOSI 2.10.0 Alpha3

Changelog KOSI 2.10.0_Alpha3

New

  • KOSI proxy functionality
  • new KOSI package version: kubernative/kubeops/sina/user/v4
  • image SHA256 support in new package version

Update

  • update .NET framework
  • update KOSI plugin
  • update KOSI Basic Plugins
  • update KOSI Professional Plugins
  • update KOSI Enterprise Plugins

Fixed

  • Fixed an issue in push - command, which caused a missleading error message.
  • Fixed an issue in the housekeeping functionality, that prevent working properly.
  • fixed an issue in kosi pull -r -t, where images could not be pushed
  • fixed an issue in kosi pull does not retag correctly if using kosi proxy
  • fixed an issue in package.kosi where templating of lists was not working

1.26 - KOSI 2.10.0 Alpha1

Changelog KOSI 2.10.0_Alpha1

New

  • KOSI proxy functionality
  • new KOSI package version: kubernative/kubeops/sina/user/v4
  • image SHA256 support in new package version

Update

  • update .NET framework
  • update KOSI plugin
  • update KOSI Basic Plugins
  • update KOSI Professional Plugins
  • update KOSI Enterprise Plugins

Fixed

  • Fixed an issue in push - command, which caused a missleading error message.
  • Fixed an issue in the housekeeping functionality, that prevent working properly.
  • Fixed an issue in kosi pull -r -t, where images could not be pushed

1.27 - KOSI 2.10.0 Alpha0

Changelog KOSI 2.10.0_Alpha0

New

  • KOSI proxy functionality
  • new KOSI package version: kubernative/kubeops/sina/user/v4
  • image SHA256 support in new package version

Update

  • update .NET framework
  • update KOSI plugin
  • update KOSI Basic Plugins
  • update KOSI Professional Plugins
  • update KOSI Enterprise Plugins

Fixed

  • Fixed an issue in push - command, which caused a missleading error message.
  • Fixed an issue in the housekeeping functionality, that prevent working properly.

1.28 - KOSI 2.9.6

Changelog KOSI 2.9.6.0

Change

  • Change image format for pushing packages to registry to OCI.

1.29 - KOSI 2.9.5

Changelog KOSI 2.9.5

Fixed

  • Fixed an issue where duplicate podman errors could be occured

1.30 - KOSI 2.9.4

Changelog KOSI 2.9.4

Fixed

  • Fixed an issue where image could be pushed compressed

1.31 - KOSI 2.9.3

Changelog KOSI 2.9.3

Fixed

  • Fixed some missleading error messages for install, update and delete

1.32 - KOSI 2.9.2

KOSI 2.9.2

Changelog KOSI 2.9.2

Bugfix
  • Fixed an issue where KOSI was still running successfully even if a image could not be pulled

Changelog template-plugin

Bugfix
  • Fixed an issue where the template file was written in json instead of yaml

1.33 - KOSI 2.9.2 Beta1

Changelog KOSI 2.9.2_Beta1

Fixed

  • Fixed an issue in push - command, which caused a missleading error message.
  • Fixed an issue in the housekeeping functionality, that prevent working properly. –>

1.34 - KOSI 2.9.2 Beta0

Changelog KOSI 2.9.2_Beta0

Fixed

  • Fixed an issue where KOSI was still running successfully even if a image could not be pulled
  • Fixed an issue where images where only pushed once
  • Fixed an issue where update could be executed with an invalid deployment name
  • Fixed an issue where delete could be executed with an invalid deployment name

1.35 - KOSI 2.9.1

KOSI 2.9.1

Changelog KOSI 2.9.1

Update
  • update nuget packages
  • update kosi plugin

1.36 - KOSI 2.9.0

KOSI 2.9.0

Changelog KOSI 2.9.0

New
  • SINA renamed to KOSI
  • new code format for creating packages named package.kosi
  • added the possibility to use sha tag values
  • added an image-clean-up, if you use retagging in KOSI
  • added KOSI remove - command, for removing your own packages from the hub
  • added checking syntax of new package.kosi and lint for package.yaml

1.37 - KOSI 2.9.0 Alpha6

KOSI 2.9.0 Alpha6

Changelog KOSI 2.9.0 Alpha6

New
  • SINA renamed to KOSI
  • new code format for creating packages named package.kosi
  • added the possibility to use sha tag values.
  • added an image-clean-up if you use retagging in KOSI
  • added KOSI remove - command, for removing your own packages from the hub
Bugfix
  • fix bug where package could not be found in workspace
  • fix bug with pull package and checksum compare
  • fix bug with formatted string
  • fix bug with expiration time of the login token

1.38 - KOSI 2.9.0 Alpha5

KOSI 2.9.0 Alpha5

Changelog KOSI 2.9.0 Alpha5

New
  • SINA renamed to KOSI
  • new code format for creating packages named package.kosi
  • added the possibility to use sha tag values.
  • added an image-clean-up if you use retagging in KOSI
  • added KOSI remove - command, for removing your own packages from the hub
Bugfix
  • fix bug where package could not be found in workspace
  • fix bug with pull package and checksum compare
  • fix bug with formatted string

1.39 - KOSI 2.9.0 Alpha1

KOSI 2.9.0 Alpha1

Changelog KOSI 2.9.0 Alpha1

New
  • SINA renamed to KOSI
  • new code format for creating packages named package.kosi
  • added the possibility to use sha tag values.
  • added an image-clean-up if you use retagging in KOSI
  • added KOSI remove - command, for removing your own packages from the hub
Bugfix
  • fix bug where package could not be found in workspace

1.40 - KOSI 2.9.0 Alpha0

KOSI 2.9.0 Alpha0

Changelog KOSI 2.9.0 Alpha0

New
  • SINA renamed to KOSI
  • new code format for creating packages named package.kosi
  • added the possibility to use sha tag values.
  • added an image-clean-up if you use retagging in KOSI
  • added KOSI remove - command, for removing your own packages from the hub

2 - Getting Started

Embark on your journey into the world of KOSI with this comprehensive guide, designed to help you seamlessly navigate its powerful features and functionalities.

2.1 - About Kosi

Get to know KOSI - the secure software installer for packages for Kubernetes clusters.

What is KOSI

KOSI is a professional software installation tool tailored for Kubernetes clusters. Its primary function is to streamline the process of defining, installing, and overseeing self-contained packages within Kubernetes environments. These packages are versatile and can be adjusted to suit various requirements and configurations.

By packaging applications and their associated Kubernetes resources into KOSI-packages, developers can easily share and distribute their applications. Users can then use KOSI to install, upgrade, and manage these charts, making it easier to deploy complex applications in Kubernetes environments.

KOSI uses a quick-to-learn command line interface (CLI).

Why use KOSI?

KOSI, drawing inspiration from Helms user-friendly design, empowers software developers to craft comprehensive packages. These packages can encompass multiple artifacts and essential dependencies, consolidated into a single KOSI package.

When deploying software into your environments, you simply retrieve this package from the KubeOps hub. KOSI efficiently manages all pertinent dependencies, ensuring smooth installation processes.

This makes the process of installing software with KOSI into your cluster simplified, secure and flawless.

Highlights

  • Supports Images and Artifacts in one Package - KOSI stands out among other package managers because of its distinctive capability to help you package images alongside other artifacts within the same package.
  • Self-Contained Packages - KOSIs capacity to generate a single self-contained package eradicates the possibility of human errors stemming from manual processing during software deployment.
  • Customizable Plugins - KOSI offers pre-built plugins that facilitate the execution of several common tasks directly through KOSI packages. Additionally, you can effortlessly access additional plugins via our KubeOps hub.
  • Scalable and Secure - KOSI enables you to distribute your software even in complex environments, where outgoing proxies restrict broad internet access.
  • Integration and Support of other Tools - KOSI seamlessly integrates with Helm, Podman and Docker, ensuring compatibility across various containerized environments. This compatibility allows users to leverage the strengths of Helms package management capabilities and Dockers containerization technology within the KOSI ecosystem. By supporting these widely used tools, KOSI enhances flexibility and efficiency in deploying and managing software across diverse infrastructure setups.

Click here to download and get started with KOSI now.

2.2 - About KubeOps Licences

Get to know all about KubeOps Licences

About KubeOps Licences

For KubeOps 1.7+ licences are required. KubeOps is a tool set which consists of 3 tools: KOSI, KubeOps Platform (Compliance and Compliance + VM). In the table you can see which functions are accessable with given licence.

If you create an account, you get a free 10 days trail-version of our licences.

KubeOps KOSI

Functions KOSI-Essential KOSI-Enterprise
Push Packages
Pull Packages
List Packages
Install Packages
Update Packages
Delete Packages
Remove Packages
Encrypt Value-files
Lint Packages
Use Private Registry-space
Use Private Hub
Build *Basic Packages
Build **Advanced Packages
Price FREE Contact Sales
* Basic Packages: Package-build-process is limited by the basic plugins. Click Here
** Advanced Packages: Package-build-process hase full access to all plugins. Click Here

KubeOps Platform

Functions Compliance Compliance + VM
Cluster Lifecycle Management
- Build Cluster
- Build Airgap Cluster
Security Hardening
Cloud Native VM Hypervisor
Price Contact Sales Contact Sales

2.3 - Installation Guide

This guide shows how to install the KOSI command line interface.

In this quickstart you will learn about:

  • KOSI system requirements
  • how to install required software
  • how to use the official KubeOps Website to download KOSI
  • how to install KOSI

KOSI seamlessly integrates with other package management software such as Helm and Podman. To ensure compatibility across different containerized environments, KOSI requires the installation of this software.

After the installation, KOSI is available as command line interface.

Prerequisites

To get the most out of this guide, the following requirements should be met:

  • basic understanding of Linux environments, bash / shell
  • administrator privileges (root)

Step 1 - System Requirements

Make sure you have prepared the listed requirements before installing KOSI.

KOSI is designed to work with the latest versions of the following operating systems:

Operating system Red Hat Enterprise Linux (Version 8.2 or newer)
Diskspace 500 MB

Step 2 - Install Helm

To ensure compatibility across different containerized environments, KOSI requires the installation of Helm (version 3 or newer).

Helm provides several options for installing, e.g. via binaries or script. For more information about Helm, see its official documentation.

In this quickstart we recommend the installation via script.

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

Step 3 - Install Podman

To ensure compatibility across different containerized environments, KOSI requires the installation of Podman (latest version).

Install Podman using the inbuilt package manager.

sudo dnf install -y podman

Step 4 - Install KOSI

With Helm and Podman installed, the next step is to download and install KOSI.

Downloading KOSI

Login into your KubeOps account. If you don‘t already have an account, you can create it by using the KubeOps website.

Download your desired version of the KOSI package file (.rpm) from the official download page.

Installing KOSI

Install KOSI using the inbuilt package manager. Replace <path> and <kosi_rpm> with the respective path and file name of the KOSI package file.

sudo dnf install -y <path>/<kosi_rpm>
Verify your Installation

To verify the installation of KOSI on your system, use the command kosi version.

kosi version

The output displays the KOSI version along with relevant information. It confirms the successful installation of KOSI.

KOSI version: 2.11.0.11_Beta0_1723014878
This work is licensed under Creative Commons Attribution - NoDerivatives 4.0 International License(see https://creativecommons.org/licenses/by-nd/4.0/legalcode for more details). ©KubeOps GmbH, Hinter Stöck 17, 72406 Bisingen - Germany, 2024

2.4 - KubeOps Migration

Get to know all about the migration and which steps you have to keep in mind if you use KubeOps tools.

About KubeOps Migration

For KubeOps 1.7+ licences are required. KubeOps is a tool set which consists of 3 tools: KOSI, KubeOps Platform (Compliance and Compliance + VM). Since 1.7 the background process is diffrent then in the older versions. To use your account in the future you have to do some steps to migrate your account.

KubeOps Account

If you had created your account before March 2025 you have to do the steps of the migration. The most of the steps will be done from us but some steps have to be done by you:

IMPORTANT: This steps are only necessary if you want to use tools of the KubeOps 1.7+ and does not have any effect on Versions below 1.7.

  • Every user before march 2025 have to choose a new password, due to a change in our login process. On your next login attempt you will be forced to choose a new password.

  • If you want to use the KubeOps tools you have to login into the kubeops-registry first. A guide will help you Here.

  • We created new hub and registry spaces, so you have to upload you old packages into your brand new private space. The public hub is no longer available. If you have problems with migrating your packages to the new hub send us an E-Mail for technical support and we will help you. Existing permissions will be migrated to the new system.

IMPORTANT: Both systems are not synced so you have to do uploads on both if you want them hold in sync.

2.5 - Creating a Basic KOSI-Package and Deployment

Learn how to create a basic KOSI-package.

In this quickstart you will learn about:

  • how to get to know KOSI-packages
  • add repositories and download helm charts
  • create a KOSI-package
  • configure a KOSI-package to deploy a demo WordPress page
  • optional: install and deploy the KOSI-package to a cluster

Prerequisites

To get the most out of this guide, the following requirements should be met:

  • KOSI is installed, see KOSI Installation Guide
  • basic understanding of Kubernetes, network clusters and tools such as Helm or Podman
  • basic understanding of Linux environments, bash / shell
  • administrator privileges (root) are granted

Step 1 - Create a KOSI-Package

After the installation, KOSI is available as command line interface.

Login into the machine where KOSI is installed.

Create a new folder and use the command kosi create to create a default KOSI-package with pre-built files.

mkdir ~/kosi-demo
cd ~/kosi-demo

kosi create

Example output:

2024-08-07 13:49:00 Info:      KOSI version: 2.11.0.11_Beta0_1723014878
2024-08-07 13:49:00 Info:      Write package.kosi to /root/kosi-demo
2024-08-07 13:49:00 Info:      Write template.yaml to /root/kosi-demo
2024-08-07 13:49:00 Info:      Write logo.png to /root/kosi-demo
2024-08-07 13:49:00 Info:      Write docs.tgz to /root/kosi-demo
File Description
package.kosi Contains the „logic“ of the package.
template.yml A template file for configurations and the templating engine.
logo.png A logo for the package. replace this with your desired logo (png format).
docs.tgz Contains your documentaion of your package.

Step 2 - Understand the Package Logic

The package.kosi file contains the „logic“ of the package. This file uses the kosi format which itself uses the highly expressive KOSI Language.

Among other things the package.kosi file defines:

  • a preambel for meta data and descriptions
  • a files section to - manages files, such as templates, to be included and target files
  • a set of commands - for example „install“ or „upgrade“ which work as scripts within the kosi file

Templates make it possible to use variantes for your packages. For example, you want to reuse a package for different environments. Templates also allow to parse additional „value files“ as command line arguments.

Advanced templating makes it possible to split one large value files into smaller ones. In this case we use some of the defaultvalues but all values will be transfered.

Step 3 - Modify the Template File

For the transfer of values into a package, a valuestemplate.yaml file is needed.

Use an editor to edit the file:

nano ~/kosi-demo/valuestemplate.yaml

To get the most out of this guide, add the following lines:

{{values}}

This command will allow to parse the values of the file values.yaml. On installing, the file values.yaml will be automatically transcluded into the cluster. This is helpful to reuse a package for different environments.

Notice the exact same naming of the command with the file.

Step 4 - Add Necessary Repositories and Pull Charts

In this guide we want to create a KOSI-package containing a demo WordPress page. Therefore you need to add the necessary repository via helm. Afterwards you need to pull the desired version of the helm chart.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm pull bitnami/wordpress --version 21.0.6

Step 5 - Configure the Package

Configure the package to inlucde the valuestemplate.yaml file. Also add commands for install, update, and delete.

Use an editor to edit the file:

nano ~/kosi-demo/package.kosi

To get the most out of this guide, overwrite the file with the following lines:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v3";
name = "wordpressdemo";
description = "Deploys a wordpress helm chart";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    wordpressvaluestemplate= "valuestemplate.yaml";
    chart = "wordpress-21.0.6.tgz";
}


install
{
    template(tmpl="valuestemplate.yaml";target="wordpressvalues.yaml");
    helm(command="upgrade";tgz="wordpress-21.0.6.tgz";values="['wordpressvalues.yaml']";deploymentName="wordpressdemo";namespace="wordpressdemo";flags="['--create-namespace',' --install']");
}

update
{
    template(tmpl="valuestemplate.yaml";target="wordpressvalues.yaml");
    helm(command="upgrade";tgz="wordpress-21.0.6.tgz";values="['wordpressvalues.yaml']";deploymentName="wordpressdemo";namespace="wordpressdemo";flags="['--create-namespace',' --install']");
}

delete
{
    cmd(command="echo delete wordpressdemo helm deployment.");
    helm(command="delete";deploymentName="wordpressdemo";namespace="wordpressdemo";flags="['--wait']");
    cmd(command="echo delete wordpressdemo namespace.");
    cmd(command="kubectl delete namespace wordpressdemo");
}

Step 6 - Create Package Documentation

It is always a good practice to document your packages.

Within your package folder, create a docs folder:

mkdir -p ~/kosi-demo/docs

Create a simple README file (for example markdown format) and write some helpful descriptions. For example:

echo „My first KOSI-package. Contains a demo WordPress page.“ > ~/kosi-demo/docs/README.md

Afterwards you need to compress the whole docs folder using the tgs format.

cd ~/kosi-demo/
tar -cvzf docs.tgz docs/

These docs will be included when building the deployable package file.

Step 7 - Build the Package

When the package.kosi is finished and the documentation is done, the KOSI-package can be built. Navigate to the package folder and simply use the kosi build command.

cd ~/kosi-demo/
kosi build

During the build process, the files package.tgz and package.yaml are created.

Step 8 - Setting Values for the Package

To install the package.tgz, you need the package itself and some values. Among other things, you need to define the nodePorts for http at 30123. This node port will be needed to access and test your WordPress page.

In a previous step we made the package reuseable by using the valuestemplate.yaml file. This files expects a values.yaml file as command line argument.

Use an editor to edit the file:

nano ~/kosi-demo/values.yaml

To get the most out of this guide, add the following lines:

global:
    storageClass: rook-cephfs
service:
    type: NodePort
    nodePorts:
        http: 30123
mariadb:
    enabled: true
    auth:
        rootPassword: topsecretChangeMe
        password: secretChangeMe
    primary:
        persistence:
            enabled: true
            storageClass: rook-cephfs
            accessModes:
                - ReadWriteOnce
persistence:
    enabled: true
    storageClass: rook-cephfs

Optional Step 9 - Installing the Package and Deploy to Cluster

As recommended you need a running Kubernetes cluster to install and deploy your new KOSI-package. You must also be logged in to the Admin machine where you have created the KOSI-package. To set up a cluster easily and conveniently, you can use kubeopsctl (see kubeopsctl documentation).

Navigate to your built KOSI-package. Install the package and pass the prepared values.yaml file as command line argument.

cd ~/kosi-demo
kosi install -p package.tgz -f values.yaml

Optional Step 10 - Test the WordPress Page

After you deployed the KOSI-package you can test the access via your cluster to the WordPress page.

Depending on your setup you need the following:

  • the IP or hostname of a master node
  • tunneling or expossing of ports according to the nodePorts as set in values.yaml

In this guides we set 30123 as nodePort. For example, in your browser navigate to:

http://master1:30123

3 - How to Guides

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!

3.1 - How to install KOSI as a user

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.

How to install KOSI as a user

This guide shows you how to install KOSI as a user. KOSI can be downloaded only from our official website.

Prerequisites

  • Operating System: A machine running RHEL 8.

  • Helm: Must be installed on your machine. Refer to the Helm Official Documentation.

  • 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 properly configured. For more details, refer to this GitHub tutorial.

    Installation on RHEL8:

    sudo dnf install podman
    

Important: Only supports secure registries. If you use an insecure registry, it is important to list your registry as an insecure registry in registry.conf (/etc/containers/registries.conf).

Installation Steps

  1. Download the KOSI RPM:

    • Log in to your KubeOps account.
    • Download your desired version of the KOSI RPM from the official download page.
  2. Install the KOSI RPM on your admin node:
    Run the following commands:

    echo 'export KUBEOPSROOT=/home/<user>/kubeops' >> $HOME/.bashrc
    source $HOME/.bashrc
    sudo dnf install <path_to_rpm>/<kosi_file_name>.rpm
    

    Note:

    • 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 stores 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.

Run the following commands to update:

echo 'export KUBEOPSROOT=/home/<user>/kubeops' >> $HOME/.bashrc
source $HOME/.bashrc
cp -r /var/kubeops/kosi/config.yaml $KUBEOPSROOT/kosi/config.yaml
cp -r /var/kubeops/kosi/deployment.yaml $KUBEOPSROOT/kosi/deployment.yaml
cp -r /var/kubeops/plugins $KUBEOPSROOT/

Note: For a clean installation, it is not necessary to move the deployment.yaml.

Check Installation

To verify that KOSI is installed correctly on your machine, simply run:

kosi version

A successful installation will display version details, it will look like this:

2024-08-07 13:49:00 Info:      KOSI version: 2.11.0.11_Beta0_1723014878
2024-08-07 13:49:00 Info:      This work is licensed under Creative Commons Attribution - NoDerivatives 4.0 International License(see https://creativecommons.org/licenses/by-nd/4.0/legalcode for more details).
2024-08-07 13:49:00 Info:      © KubeOps GmbH, Hinter Stöck 17, 72406 Bisingen - Germany, 2023

3.2 - SSO with KOSI and Harbor

With KOSI-2.12.X we change some in the authentication process for the whole KubeOps brand. We are using now a SSO to interact with kubeops.net and our registry.

How to register an KubeOps account

Due to the Single-Sign-On (SSO) with KOSI 2.12.X, there are several ways to register an account. These are the two possibilities:

Register account via KubeOps.net

This is the usual way to register a user account. Scroll to the bottom of the page in the Download Area and click the SSO-Login button. You will be redirected to the SSO page where you can REGISTER a new user account.

Registration

Register account via KubeOps-registry

Alternatively, you can register a user account by using the KubeOps-Registry page. Click on LOGIN WITH keycloak. You will be redirected to the SSO page where you can REGISTER a new user account.

Registration

How to use KOSI

After successful registration, you must log in once into the KubeOps-Registry. Once logged in, you can switch to KOSI 2.12.X and use it as normal.

How to manually push images in my 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

  1. Click on your username and select User Profile.

    User Profile

  2. On the User Profile page, you can copy or change your CLI secret if needed.

    CLI secret

Now you can push your image using the CLI secret:

podman login registry.kubeops.net -u <username> -p <CLI_secret>

Note: Replace <username> with your KubeOps username and <CLI_secret> with your actual CLI secret.

3.3 - Install package from Hub

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.

Installing KOSI packages from KubeOps Hub

To install KOSI packages from the KubeOps Hub on your machines, follow these steps:

  1. 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.)

  2. Install the Package:
    Copy the installation address of the desired package and use it with the kosi install command:

    [root@localhost ~]# kosi install --hub <hubname> <installation address>
    

Note: The --hub parameter is used to install packages from the software Hub.

To be able to install a package from the software Hub, you must be logged in as a user.

Install from Private Hub

Example:
The package livedemo of user kosi with version 2.7.1 is to be installed from the private software Hub:

[root@localhost ~]# kosi install kosi/livedemo:2.7.1

Install from Public Hub

Example:
The package livedemo of user kosi with version 2.7.1 is to be installed from the public software Hub:

[root@localhost ~]# kosi install --hub public kosi/livedemo:2.7.1

Install along with yaml files

The -f parameter is used to provide YAML files from the user.

[root@localhost ~]# kosi install <package> -f <user.yaml>

Example:
The package livedemo of user kosi with version 2.7.1 is installed from the public software Hub with user-specific YAML files:

[root@localhost ~]# kosi install --hub public kosi/livedemo:2.7.1 -f userfile1.yaml

Install in specific namespace

The --namespace flag allows you to specify a Kubernetes namespace for the installation.

[root@localhost ~]# kosi install --hub <hubname> <package> --namespace <namespace>

Example:
The package livedemo of user kosi with version 2.7.1 is installed from the public software Hub in a custom Kubernetes namespace:

[root@localhost ~]# kosi install --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the default namespace will be used.


Install with specific deployment name

The --dname flag allows you to assign a specific name to the deployment.

[root@localhost ~]# kosi install --hub <hubname> <package> --dname <deploymentname>

Example:
The package livedemo of user kosi with version 2.7.1 is installed from the public software Hub with a deployment name set:

[root@localhost ~]# kosi install --hub public kosi/livedemo:2.7.1 --dname MyDeployment

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

  1. Download the Package:
    Use kosi pull on a machine with an internet connection to download the package:
[root@localhost ~]# kosi pull [package name from hub] -o [your preferred name] --hub public
  1. Transfer the Package:
    Move the downloaded package to the machine without an internet connection (which has KubeOps installed).

  2. Install the Package:
    Install the transferred package with the following command:

[root@localhost ~]# kosi install -p [package name]

3.4 - 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.10.0 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:

KOSI Basic Plugins Version 1.6.X

kosi search --hub kosi-basic
2024-08-07 13:47:02 Info:      KOSI version: 2.11.0.11_Beta0_1723014878
| User | Name          | Version     | Description        | Install                        |
|------|---------------|-------------|--------------------|--------------------------------|
| kosi | basic-plugins | 1.5.0_beta0 | KOSI Basic Plugins | kosi/basic-plugins:1.5.0_beta0 |
| kosi | basic-plugins | 1.5.0       | KOSI Basic Plugins | kosi/basic-plugins:1.5.0       |
| kosi | basic-plugins | 1.4.0       | KOSI Basic Plugins | kosi/basic-plugins:1.4.0       |
| kosi | basic-plugins | 1.6.0_Beta0 | KOSI Basic Plugins | kosi/basic-plugins:1.6.0_Beta0 |
| kosi | basic-plugins | 1.4.2       | KOSI Basic Plugins | kosi/basic-plugins:1.4.2       |
| kosi | basic-plugins | 1.4.1       | KOSI Basic Plugins | kosi/basic-plugins:1.4.1       |

This package contains the following plugins:

Plugin Version
template 1.6.0
helm 1.6.0
print 1.6.0

KOSI Professional Plugins Version 1.6.X

kosi search --hub kosi-professional
2024-08-07 13:47:36 Info:      KOSI version: 2.11.0.11_Beta0_1723014878
| User | Name                 | Version     | Description               | Install                               |
|------|----------------------|-------------|---------------------------|---------------------------------------|
| kosi | professional-plugins | 1.5.0_beta0 | KOSI Professional Plugins | kosi/professional-plugins:1.5.0_beta0 |
| kosi | professional-plugins | 1.4.0       | KOSI Professional Plugins | kosi/professional-plugins:1.4.0       |
| kosi | professional-plugins | 1.5.0       | KOSI Professional Plugins | kosi/professional-plugins:1.5.0       |
| kosi | professional-plugins | 1.4.2       | KOSI Professional Plugins | kosi/professional-plugins:1.4.2       |
| kosi | professional-plugins | 1.4.1       | KOSI Professional Plugins | kosi/professional-plugins:1.4.1       |
| kosi | professional-plugins | 1.6.0_Beta0 | KOSI Professional Plugins | kosi/professional-plugins:1.6.0_Beta0 |

This are the plugins which the packages contains:

Plugin Version
template 1.6.0
helm 1.6.0
print 1.6.0
kubectl 1.6.0
bash 1.6.0
cmd 1.6.0
sh 1.6.0
editfile 1.6.0
fprint 1.6.0
if 1.6.0
loop 1.6.0
kosi 2.11.0.10
merge 1.6.0
exit 1.6.0
setfact 1.6.0

KOSI Enterprise Plugins Version 1.6.X

kosi search --hub kosi-enterprise
2024-08-07 13:47:59 Info:      KOSI version: 2.11.0.11_Beta0_1723014878
| User | Name               | Version     | Description                  | Install                             |
|------|--------------------|-------------|------------------------------|-------------------------------------|
| kosi | enterprise-plugins | 1.5.0       | KOSI Enterprise Plugins      | kosi/enterprise-plugins:1.5.0       |
| kosi | piaoperator        | 1.4.0       | Pia Operator Install Package | kosi/piaoperator:1.4.0              |
| kosi | enterprise-plugins | 1.4.2       | KOSI Enterprise Plugins      | kosi/enterprise-plugins:1.4.2       |
| kosi | enterprise-plugins | 1.5.0_beta0 | KOSI Enterprise Plugins      | kosi/enterprise-plugins:1.5.0_beta0 |
| kosi | enterprise-plugins | 1.4.0       | KOSI Enterprise Plugins      | kosi/enterprise-plugins:1.4.0       |
| kosi | enterprise-plugins | 1.6.0_Beta0 | KOSI Enterprise Plugins      | kosi/enterprise-plugins:1.6.0_Beta0 |
| kosi | enterprise-plugins | 1.4.1       | KOSI Enterprise Plugins      | kosi/enterprise-plugins:1.4.1       |

This package contains the following plugins:

Plugin Version
template 1.6.0
helm 1.6.0
print 1.6.0
kubectl 1.6.0
bash 1.6.0
cmd 1.6.0
sh 1.6.0
editfile 1.6.0
fprint 1.6.0
if 1.6.0
loop 1.6.0
kosi 2.11.0.10
merge 1.6.0
exit 1.6.0
setfact 1.6.0
auditlog 1.6.0
chmod 1.6.0
copy 1.6.0
firewall 1.6.0
firewallD 1.6.0
containerd 1.6.0
containerruntime 1.6.0
hostname 1.6.0
iptables 1.6.0
kubeadm 1.6.0
osCheck 1.6.0
packagemanager 1.6.0
pia 1.6.0
service 1.6.0
sudo 1.6.0

How to install the Plugins

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.

kosi install --hub=<pluginhub> user/packagename:version

Example: The package enterprise-plugins of the user kosi with the version 1.6.0_Beta0 is to be installed from the kosi-enterprise hub.

kosi install --hub=kosi-enterprise kosi/enterprise-plugins:1.6.0_Beta0 
Note: You can also use the Install Tab from the output to help with installation.

3.5 - How to build a KOSI package

Building a KOSI package is an easy and efficient way to build your own packages. This guide outlines the essential steps and commands to help you successfully build your KOSI package.

How to build your own KOSI package

This guide shows you how to create a KOSI package. KOSI can be downloaded only from our official website.

Prerequisites

Before you begin, check the following prerequisites:

  1. A machine with any of the following operating systems
    • RHEL 8
  2. A text editor (Vi, VIM, Nano, etc.)
  3. An internet connection for downloading images or Helm charts
  4. All prerequisites for the KOSI installation

The package base

Using the kosi create command, all base components for building your package are generated.

kosi create

Output:

2024-08-07 13:29:40 Info:      KOSI version: 2.11.0.11_Beta0_1723014878
2024-08-07 13:29:41 Info:      Write package.kosi to /root/demo
2024-08-07 13:29:41 Info:      Write template.yaml to /root/demo
2024-08-07 13:29:41 Info:      Write logo.png to /root/demo
2024-08-07 13:29:41 Info:      Write docs.tgz to /root/demo

The package logic

The core of your package is defined in the package.kosi file. To build the package, you need additional files such as a Helm chart and a valuestemplate.yaml file. In this example, default values from the Bitnami WordPress Helm chart are used. A simple valuestemplate.yaml is required to build the package.

A valuestemplate.yaml

{{values}}

A Helm chart is required as well. Download the Bitnami WordPress Helm chart from ArtifactHub and prepare your values.yaml based on the default values. You can get both here.

A helm chart and values

helm repo add bitnami https://charts.bitnami.com/bitnami
helm pull bitnami/wordpress --version 21.0.6

Note: This chart is not for production. It is only for demo purposes.

In the following example, the chart and the valuestemplate.yaml are added to the package.kosi. To convert the values, you need to call the template plugin, there you have to set the tmpl file and a target. Advanced templating makes it possible to split one large value file into smaller ones. In this case we use some of the default values but all values will be transfered.
To execute the helm install/upgrade operation, the helm plugin has to be called and for the target file is needed for the values.
You can also write update and remove operations for your package like in the example.
A clean is done in the remove section. With the helm plugin the helm deployment is removed and the cmd plugin call will remove the namespace.

A package.kosi example

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "wordpressdemo";
description = "Deploys a wordpress helm chart";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    wordpressvaluestemplate = "valuestemplate.yaml";
    chart = "wordpress-21.0.6.tgz";
}

install
{
    template
    (
        tmpl = "valuestemplate.yaml";
        target = "wordpressvalues.yaml";
    );

    helm
    (
        command = "upgrade";
        tgz = "wordpress-21.0.6.tgz";
        values = "['wordpressvalues.yaml']";
        deploymentName = "wordpressdemo";
        namespace = "wordpressdemo";
        flags = "['--create-namespace ', '--install']";
    );
}

update
{
    template
    (
        tmpl = "valuestemplate.yaml";
        target = "wordpressvalues.yaml";
    );

    helm
    (
        command = "upgrade";
        tgz = "wordpress-21.0.6.tgz";
        values = "['wordpressvalues.yaml']";
        deploymentName = "wordpressdemo";
        namespace = "wordpressdemo";
        flags = "['--create-namespace ', '--install']";
    );
}

delete
{
    cmd(command = "echo delete worpressdemo helm deployment.");

    helm
    (
        command = "delete";
        deploymentName = "worpressdemo";
        namespace = "wordpressdemo";
        flags="['--wait']";
    );

    cmd(command="echo delete worpressdemo namespace.");

    cmd(command="kubectl delete namespace worpressdemo");
}

Note: For more information about the package.kosi file, click here.

Build the package

When the package.kosi file is complete, build the package. During the build process, a package.tgz archive and a package.yaml file are created. To build your KOSI package, simply use the following command:

kosi build

Note: The package.yaml file is generated only once. If a package.yaml already exists, KOSI will not generate a new one.

Install the package

To install your package, you need both the package.tgz and a values.yaml file containing the necessary configuration values. Typically, values are derived from the chart’s default values.

A values.yaml example

global:
  storageClass: rook-cephfs
service:
  type: NodePort
  nodePorts:
    http: 30123
mariadb:
  enabled: true
  auth:
    rootPassword: topsecretChangeMe
    password: secretChangeMe
  primary:
    persistence:
      enabled: true
      storageClass: rook-cephfs
      accessModes:
        - ReadWriteOnce
persistence:
  enabled: true
  storageClass: rook-cephfs

To install the package, use the kosi install command.
The -p parameter is set for a local package.
The -f parameter is set to hand over value files to the package.

kosi install -p package.tgz -f values.yaml

In this case, the output of the chart will describe your next steps:

kosi install -p package.tgz -f values1.yaml
2024-08-07 13:47:34 Info:      KOSI version: 2.11.0.11_Beta0_1723014878
2024-08-07 13:47:35 Info:      template write to /var/kubeops/kosi/e628d035-4700-4f55-a9ac-ab9217b8e79f/wordpressvalues.yaml
2024-08-07 13:47:35 Info:      run cmd plugin
2024-08-07 13:47:35 Info:      use plugin bash if available
2024-08-07 13:47:35 Info:      Executing with non sudo privilegs
2024-08-07 13:47:36 Info:      Release "wordpressdemo" does not exist. Installing it now.
NAME: wordpressdemo
LAST DEPLOYED: Tue Mar 26 10:47:35 2024
NAMESPACE: wordpressdemo
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: wordpress
CHART VERSION: 21.0.6
APP VERSION: 6.4.3

** Please be patient while the chart is being deployed **

Your WordPress site can be accessed through the following DNS name from within your cluster:

    wordpressdemo.wordpressdemo.svc.cluster.local (port 80)

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL by running these commands:

   export NODE_PORT=$(kubectl get --namespace wordpressdemo -o jsonpath="{.spec.ports[0].nodePort}" services wordpressdemo)
   export NODE_IP=$(kubectl get nodes --namespace wordpressdemo -o jsonpath="{.items[0].status.addresses[0].address}")
   echo "WordPress URL: http://$NODE_IP:$NODE_PORT/"
   echo "WordPress Admin URL: http://$NODE_IP:$NODE_PORT/admin"

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

  echo Username: user
  echo Password: $(kubectl get secret --namespace wordpressdemo wordpressdemo -o jsonpath="{.data.wordpress-password}" | base64 -d)

WARNING: There are "resources" sections in the chart not set. Using "resourcesPreset" is not recommended for production. For production installations, please set the following values according to your workload needs:
  - resources
+info https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

2024-08-07 13:47:36 Info:      Helm upgrade successfully.
2024-08-07 13:47:36 Info:      Installation successful

3.6 - 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 by downloading the appropriate RPM file and installing it on your system.

How to update KOSI

This guide shows you how to update KOSI. KOSI can be downloaded only from our official website.

Prerequisites

Before you begin, check the following prerequisites:

Before you begin, check the following prerequisites:

  1. A machine with the RHEL 8 operating system.

  2. You must have Helm installed on your machine.

    Refer to the Helm Official Documentation for the Installation Guide.

  3. For KOSI versions, you must have Podman installed on your machine.

    Note: Before installing Podman, make sure that the number of user namespaces (max_user_namespaces) is specified on your system if you are a non-root user.
    For more information, follow this GitHub link.

    To install podman use command:

    sudo dnf install podman
    

    Important: KOSI supports only secure registries. If you use an insecure registry, it is important to list your registry as an insecure registry in the registry.conf file located at /etc/containers/registries.conf.

Update Steps

Every release of KOSI provides an RPM file for manual installation. You need to log in to your KubeOps account to download the RPM.

  1. Create a KubeOps Account:
    If you haven’t already, create a KubeOps account on the KubeOps website and log in to your account.

  2. Download the RPM:
    Download your desired version of the KOSI RPM file from our official download page:
    https://kubeops.net/products/downloads/kosi-downloads-en

  3. Update the KOSI RPM:
    On your admin node, update KOSI by installing the new RPM, which will override the existing version. Run the following command:

 sudo dnf install <path to rpm>/<kosi file name>

Note:

  • Replace <path_to_rpm> with the directory path where the file is located.
  • Replace <kosi_file_name> with the exact file name of the RPM (including the .rpm extension).

3.7 - How to install KOSI Proxy

The KOSI Proxy allows fetching packages and container images while blocking uploads to the internet and limiting access to a HUB. This guide details the installation and configuration steps for KOSI Proxy.

How to install KOSI Proxy

This guide shows you how to install the KOSI Proxy.

Architecture

The diagram shows the architecture of the KOSI Proxy.
Packages and container images can be fetched via the KOSI Proxy.
Uploading packages and container images to the internet is blocked.
Access can be limited to a HUB.

KOSI Proxy

Prerequisites

To install the KOSI Proxy you need a dedicated VM with RHEL8 OS and root access.
Minimum requirements for the VM are:

  • 4 CPU
  • 8 GB RAM
  • 50 GB Disk

The following software must be installed on this VM:

  • docker
  • docker compose
  • kosi
# docker
subscription-manager register
subscription-manager refresh
subscription-manager attach --auto
dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo
dnf repolist -v
dnf install docker-ce
systemctl enable docker --now
systemctl status docker

# docker compose
curl -L "https://github.com/docker/compose/releases/download/v2.24.5/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose 

# kosi
dnf install -y kosi*.rpm

#### Set KOSI config  hub in __/var/kubeops/kosi/config.yaml__  
```yaml
apiversion: kubernative/sina/config/v2

spec:
  hub: https://hub.kubernative.net/v4/dispatcher/ # <- set hub
  plugins: /var/kubeops/plugins/
  workspace: /tmp/kosi/process/
  logging: info
  housekeeping: false
  proxy: false # <- mandatory if kosi version >= 2.10.*

Install KOSI Proxy

If all prerequisites are met, the KOSI Proxy can be installed.
A values.yaml file is required for KOSI Proxy installation.
Below is an example values.yaml configuration for the environment:

# Proxy host IP address
proxyIP: 10.2.10.99

# Preprod config values
proxyPassthrough: preprod
proxyRegistry: registry.preprod.kubernative.net
aspnetcoreEnvironment: Development

# Prod config values
#proxyPassthrough: prod
#proxyRegistry: registry1.kubernative.net
#aspnetcoreEnvironment: Production

After the values.yaml file has been created, the KOSI Proxy can be installed via a kosi package.
The KOSI Proxy is installed in ~/kosi-proxy.

kosi install --hub public kubeops/kosi-proxy:2.10.0-alpha0 -f values.yaml

Start KOSI Proxy:

cd ~/kosi-proxy
docker-compose up -d

Configure KOSI Proxy (Advanced)

The KOSI Proxy is already configured during installation; however, additional parameters can be adjusted.

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 and kubeops are set.

{
  "Logging": {
    "LogLevel": {
      "Microsoft": "Warning",
      "System": "Warning",
      "Microsoft.Hosting.Lifetime": "Information",
      "Kubeops": "Debug"
    },
    "Console": {
      "FormatterName": "simple",
      "FormatterOptions": {
        "SingleLine": false,
        "TimestampFormat": "HH:mm:ss ",
        "ColorBehavior": "Enabled",
        "UseUtcTimestamp": false
      }
    }
  },
  "AllowedHosts": "*",
  "Config": {
    "RepositoryPath": "/service/repository",
    "PermissionServiceUrl": "http://permission-v4/",
    "ProxyPassthroughUrl": "https://hub.preprod.kubernative.net/v4/download/",
    "GuestQuota": 1000000,
    "HubWhitelist": "kosi, kubeops"
  }
}

Install Harbor

Harbor is used as the registry endpoint in this setup.

1. Download installer

Download the Harbor offline installer:

# harbor
cd ~
curl -L https://github.com/goharbor/harbor/releases/download/v2.9.2/harbor-offline-installer-v2.9.2.tgz | tar -xvzf -
cd ~/harbor
cp harbor.yml.tmpl harbor.yml
2. Configure harbor.yml values

Edit the harbor.yml

Change:

hostname: 10.2.10.99  # line 5
insecure: true        # line 101 

Comment out:

#  port: 443                            # line 15
#  certificate: /your/certificate/path  # line 17
#  private_key: /your/private/key/path  # line 18
3. Run install script:
cd ~/harbor
./install.sh

Configure Harbor

1. Port Forward

To log in to Harbor, port 80 of the proxy host must be forwarded.
Example of port forwarding with ssh. Please adjust the values accordingly.

ssh -i "C:\Users\<user>\.ssh\id_rsa" -J <user>@10.9.112.19 -L 8080:10.2.10.99:80 root@10.2.10.99

You can then log in to Harbor -> http://localhost:8080
Default credentials:

  • User: admin
  • Initial Password: Harbor12345
2. Add Registry Endpoint

In Harbor, navigate to Administration → Registries → New Endpoint.

Harbor Registry Endpoint

Key Value
Provider Harbor
Name Preprod
Description [optional]
Endpoint URL https://registry.preprod.kubernative.net
Access ID kubeops
Access Secret [enter kubeops password]
Verify Remote Cert true
3. Add Project

In Harbor, navigate to Project → New Project.

Harbor Project

Key Value
Project Name kubeops
Access Level false
Project quota limits -1
Proxy Cache true
Endpoint https://registry.preprod.kubernative.net

Manage applications with docker compose

1. KOSI Proxy

KOSI Proxy is installed in the folder ~/kosi-proxy.

cd ~/kosi-proxy

# show kosi proxy containers
docker compose ps

# show kosi proxy logs 
docker compose logs -f

# stop kosi proxy
docker compose down

# start kosi proxy
docker compose up -d
2. Harbor

Harbor is installed in the folder ~/harbor.

cd ~/harbor

# show harbor containers
docker compose ps

# show harbor logs 
docker compose logs -f

# stop harbor
docker compose down

# start harbor
docker compose up -d

3.8 - How to template within the package.kosi

How to template within the package.kosi"

TBA

3.9 - 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.

Creating Kosi package

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.

[root@localhost ~]# 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 field
name: kosi-example-packagev3 # Required field
description: kosi-example-package # Required field
version: 0.1.0 # Required field
includes:  # 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.io
      image: nginx
      tag: latest
docs: docs.tgz
logo: logo.png
installation: # Required field
  includes: # Optional field: When "files" or "containers" are needed.
    files: # Optional field:
      - input # Reference to includes
    containers: # Optional field:
      - example # Reference to includes
  tasks: 
    - cmd:
        command: "touch ~/kosiExample1"
update: # Required field
  includes: # Optional field: When "files" or "containers" are needed.
    files: # Optional field:
      - input # Reference to includes
    containers: # Optional field:
      - example # Reference to includes
  tasks:
    - cmd:
        command: "touch ~/kosiExample2"
delete: # Required field
  includes: # Optional field: When "files" or "containers" are needed.
    files: # Optional field:
      - input # Reference to includes
    containers: # Optional field:
      - example # Reference to includes
  tasks:
    - 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.

[root@localhost ~]# 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.

4 - Plugins

Here you will find a detailed list and description of all our Kosi plugins.

Plugin References

How to access the plugins

All plugins are available as KOSI packages in the KubeOpsHub. Our plugins are grouped into several KOSI packages described below. To see our KOSI packages in the KubeOpsHub use the command:

Search for kubeops-plugins

kosi search --ps kubeops --hub public

Install for kubeops-plugins

kosi install --hub=public <user/packagename:version> 

The plugins are automatically placed in the associated directory($KUBEOPSROOT/plugins) and can be used directly.

Plugin packages

In this section you can find the plugin packages and the documentation for each plugin.

4.1 - auditLog-1.7.0

Kosi Plugin auditLog Version 1.7.0

Summary

The auditLog plugin enables or disables audit logging for your Kubernetes cluster. This plugin allows you to control logging settings and define paths for policy and log storage.

Keys

Key Description
state Mandatory Set to on to enable or off to disable audit logging for the cluster.
policyPath Mandatory Specifies the directory where the policy.yaml file is stored.
logPath Mandatory Defines the directory where the audit.log file will be saved.

Example 1 - enable auditLog

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    auditLog
    (
        state = "on"; 
        policyPath = "/root/test/policyDir/";
        logPath = "/root/test/logging/";
    );
}

Example 2 - disable auditLog

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    auditLog
    (
        state = "off"; 
        policyPath = "/root/test/policyDir/";
        logPath = "/root/test/logging/";
    );
}

4.2 - bash-1.7.0

KOSI Plugin bash Version 1.7.0

Summary

The bash plugin allows users to execute shell commands within a Bash environment. It is useful for running system commands, scripting automation tasks, or performing custom operations that require command-line execution within a KOSI package. This plugin ensures that commands are executed inside a Bash shell, which provides compatibility with shell scripting syntax and built-in commands. Supports command chaining using ;.

Keys

Key Description
command Mandatory Contains a string representing a bash command or a sequence of commands to be executed. Multiple commands can be specified, separated by a semicolon (;).

Examples

Example 1

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

install
{
    cmd(command = "echo Using the bash plugin.");

    bash(command = "echo Hello World!");
}

Output

2025-02-26 15:17:00 Info:      use plugin bash if available
2025-02-26 15:17:00 Info:      Executing with non sudo privilegs
2025-02-26 15:17:00 Info:      Using the bash plugin.

2025-02-26 15:17:00 Info:      Executing with non sudo privilegs
2025-02-26 15:17:00 Info:      Hello World!

2025-02-26 15:17:00 Info:      Installation successful.

Example 2

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

install
{
    cmd(command = "echo Using the bash plugin.");

    bash(command = "echo 1.Hello;echo 2.World;echo 3.Hello World.");
} 

Output

2025-02-26 15:18:28 Info:      run cmd plugin
2025-02-26 15:18:28 Info:      use plugin bash if available
2025-02-26 15:18:28 Info:      Executing with non sudo privilegs
2025-02-26 15:18:28 Info:      Using the bash plugin.

2025-02-26 15:18:28 Info:      Executing with non sudo privilegs
2025-02-26 15:18:28 Info:      1.Hello
2.World
3.Hello World.

2025-02-26 15:18:28 Info:      Installation successful.

Example 3

Using bash with the set and if plugins

This example shows the interaction of several plug-ins. In this example, we use the bash plugin together with the set and if plugins to check a condition (which is set before) before executing a bash command:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-bash-if";
description = "Example using bash with set and if";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

install
{
    set
    (
        variable = "myVar";
        value = "Hello";
    );

    if (condition = "$vars.myVar$ = 'Hello'") then
    {
        bash(command = "echo Variable is 'Hello'");
    }
    else
    {
        bash(command = "echo Variable is not 'Hello'");
    }
}

Expected Output

If myVar is Hello:

2025-02-26 15:18:28 Info:      Variable is 'Hello'

If myVar is not Hello:

2025-02-26 15:18:28 Info:      Variable is not 'Hello'

4.3 - chmod-1.7.0

KOSI Plugin chmod Version 1.7.0

Summary

The chmod plugin allows you to modify access permissions for a specified file or directory. By defining a path, state, and mode, you can change file permissions using the Linux chmod command.

  • The state value can be either file or directory. If directory is specified, the plugin applies permissions recursively.
  • The mode value represents the permission settings in the standard numerical format used in Linux.
  • If necessary, you can run chmod with sudo, requiring a password set by the root user.

Keys

Key Description
path Mandatory Absolute path of the file or directory whose permissions you want to change.
state Mandatory Set to file or directory depending on whether the path is a file or directory.
mode Mandatory Permission mode using the Linux numeric syntax (supports three-digit and four-digit octal representation).
sudo optional Set to true to use sudo for the chmod command.
sudoPassword optional Password for executing sudo commands. A root user must assign this password to a non-root user beforehand.

Note: If you’re not yet familiar with Linux permissions, check out this short introduction from RedHat.

Example 1 - Changing file permissions

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = "echo Changing file permissions using the chmod-plugin");
    chmod
    (
        path = "/user/myuser/myUserApp.sh";
        state = "file";
        mode = "777"
    );
}

Example 2 - Changing directory permissions with sudo

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install 
{
    cmd(command = "echo Changing directory permissions using the chmod-plugin");
    chmod
    (
        path = "/root"; 
        state = "directory"; 
        mode = "777"; 
        sudo = "true"; 
        sudoPassword = "myPassword";
    );
    bash(command = "ls -la /root");
}

Example 3 - Restricting permissions to read-only

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install 
{
    cmd(command = "echo Restricting file permissions using chmod-plugin");
    chmod
    (
        path = "/user/myuser/myUserApp.sh"; 
        state = "file"; 
        mode = "444";
    );
}

4.4 - cmd-1.7.0

KOSI Plugin cmd Version 1.7.0

Summary

The cmd plugin allows execution of Linux shell commands within a deployment configuration. It relies on either the bash or sh plugin to process commands, depending on availability. If the bash plugin is present, it will be used; otherwise, the sh plugin will handle execution.

Plugin dependencies

If you want to use the plugin cmd you need one of following plugins:

Why is the bash or sh Plugin Required?

The cmd plugin itself does not execute commands directly. Instead, it acts as a wrapper, passing the specified command to a shell environment. Since bash and sh are the most common shell interpreters in Linux, the plugin requires at least one of them to function properly.

Keys

Key Description
command Mandatory set this to a command for the bash or the sh terminal .

Note: The command has to be surrounded by double quotes, otherwise it will not be recognized.

Usage

Example 1 - Executing a single commands

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input="template.yaml";
}

containers =
{
    example=["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = "echo Using the cmd-plugin");
    cmd(command = "echo Hello World");
}

Expected Output

This will be printed to the console:

2023-12-01 10:44:30 Info:      use plugin bash if available
Using the cmd-plugin
Hello World

Example 2 - Multiple commands

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = "echo Using the cmd-plugin");
    cmd(command = "echo Hello World! '>' test.txt");
    cmd(command = "cat test.txt");
}

Expected Output

A file named test.txt is created and “Hello World!” is written to the file.
The second command outputs the contents of the file.

2023-12-01 11:06:17 Info:      run cmd plugin
Using the cmd-plugin
2023-12-01 11:06:17 Info:      run cmd plugin
Hello World!

Example 3 - Creating and listing a directory

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}
install
{
    cmd(command = "mkdir -p /tmp/mydirectory");
    cmd(command = "ls -la /tmp/mydirectory");
}

4.5 - containerd-1.7.0

KOSI Plugin containerd Version 1.7.0

Summary

The containerd plugin allows you to manage your container runtime efficiently. It provides options to execute commands with or without flags and enables gathering information about the current container runtime status.

Keys

Key Description
command Mandatory The command you want to execute inside the container.
containerName - The name of the container or the temporary name of a created cluster.*1
destImage - The new image name for tagging srcImage.
execID - The ID or name of your execution.*2
flag - Stores information on enabled options. Examples include -a or –all for listing all containers, or -n or –last for the last container in the list. Multiple flags can be appended.
sudo - Can be true or false. If true, the plugin executes with sudo privileges.
sudoPassword - The password for executing the command with sudo privileges.
srcImage - The image you want to pull, push, or tag.
option Mandatory Specifies the operation to execute (e.g., run, ps, images, exec).

Available Operations:

  • ps - Lists all existing containers.
  • images - Lists all existing images.
  • run - Starts a container.
  • status - Displays the state of the container runtime (e.g., active).
  • exec - Executes a command inside a running container.
  • tag - Renames an image (e.g., docker tag ).
  • pull - Pulls a specified image.
  • push - Pushes a specified image.
  • stop - Stops a given container.
  • start - Starts a given container.
  • deleteCon - Deletes a specified container.

*1:Note: For containerd, containers do not have names, only IDs. When using startTask, stopTask, or deleteTask, containerName is treated as the task name.

*2:Note: Only required for execution commands with containerd.

Example 1 - List Running Containers (ps)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        option = "ps"; 
        flag = "--last";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 2 - List All Images

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        option = "images"; 
        flag = "--all";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 3 - Run a Container

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        option = "run"; 
        flag = "-w /path/to/dir/ -i -t";
        srcImage = "registry.kubernative.net/lima:v0.8.0";
        containerName = "myFirstContainer";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 4 - Check Container Runtime Status

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        option = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 5 - Execute a Command in a Running Container

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        option = "exec"; 
        execID = "exec1";
        containerName = "registry.kubernative.net/lima:v0.8.0";
        command = "mkdir /tmp/testdir";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 6 - Tag an Image

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        option = "tag"; 
        srcImage = "registry.kubernative.net/lima:v0.8.0";
        destImage = "yourRegistry/yourName:v0.8.0";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 7 - Pull or Push an Image

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        option = "pull/push"; 
        srcImage = "registry.kubernative.net/lima:v0.8.0";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 8 - Delete a Container

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        option = "deleteCon"; 
        containerName = "myFirstContainer";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 9 List Running Tasks (psTask)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        type = "containerd"; 
        option = "psTask";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 10 Manage Tasks (stopTask / startTask / deleteTask)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerd
    (
        option = "stopTask / startTask / seleteTask"; 
        containerName = "task1";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Notes

  • Ensure that all required parameters are provided for each operation.
  • Using sudo=true requires sudoPassword to be set.
  • The containerName for containerd may refer to a container ID or task name, depending on the operation.

4.6 - Plugin References

Plugin References

How to access the plugins

All plugins are available as KOSI packages in the KubeOpsHub. Our plugins are grouped into several KOSI packages described below. To see our KOSI packages in the KubeOpsHub use the command:

KOSI 2.4.0 or higher
kosi search --ps kubeops --hub public
KOSI 2.4.0 or higher
kosi install --hub=public <user/packagename:version> 

The plugins are automatically placed in the associated directory($KUBEOPSROOT/plugins) and can be used directly.

Plugin packages

In this section you can find the plugin packages and the documentation for each plugin.

kubeops-basic-plugins

These plugins are part of the kubeops-basic-plugins package.

[Plugin copy]( “Plugin copy”)

[Plugin editFile]( “Plugin editFile”)

[Plugin fPrint]( “Plugin fPrint”)

[Plugin hostname]( “Plugin hostname”)

[Plugin if]( “Plugin if”)

[Plugin loop]( “Plugin loop”)

[Plugin osCheck]( “Plugin osCheck”)

[Plugin packagemanager]( “Plugin packagemanager”)

[Plugin service]( “Plugin service”)

[Plugin sudo]( “Plugin sudo”)

kubeops-kubernetes-plugins

These plugins are part of the kubeops-kubernetes-plugins package.

[Plugin auditLog]( “Plugin auditLog”)

[Plugin kubeadm]( “Plugin kubeadm”)

[Plugin kubectl]( “Plugin kubectl”)


pre-installed plugins

These plugins are installed with the installation of KOSI.

[Plugin bash]( “Plugin bash”)

[Plugin chmod]( “Plugin chmod”)

[Plugin cmd]( “Plugin cmd”)

[Plugin helm]( “Plugin helm”)

[Plugin print]( “Plugin print”)

[Plugin sh]( “Plugin sh”)

[Plugin template]( “Plugin template”)

[Plugin kosi]( “Plugin kosi”)

4.7 - containerRuntime-1.7.0

KOSI Plugin containerRuntime Version 1.7.0

Summary

The ContainerRuntime plugin allows you to manage container runtimes efficiently. It provides options to execute commands with or without flags and retrieve runtime status information. Supported runtimes include Docker, CRI-O, and containerd.

Plugin requirements

To use the ContainerRuntime plugin, you need the following dependencies installed:

  • Docker
  • CRI-O
  • Contianerd

Keys

Key Description
command Mandatory Specifies the command to execute inside the container.
containerConfig - Configuration file (JSON or YAML) for container creation. Example: containerConfiguration.json or containerConfiguration.yaml.
containerName - Name of the container in which the command will be executed.
destImage - New image name when tagging an existing image.
execID - ID or name of the execution (only for containerd execution commands).
flag - Options to enable specific command behaviors (e.g., -a or –all). Multiple flags can be used.
runtime - Temporarily stores the runtime type when the key containerRuntime is set to status.
srcImage - Source image for pull, push, or tag operations.
sudo - If true, the plugin executes with sudo privileges.
sudoPassword - Mandatory if sudo is set to true.
type - Specifies the container runtime type. If unspecified, the plugin detects the running runtime automatically. Docker is preferred if multiple runtimes are active.
option Mandatory Specifies the operation to execute.

Supported option Values

Option Description
ps Lists all existing containers.
images Lists all available container images.
run Starts a container.
status Displays the runtime state (e.g., “active” if running).
exec Executes a command within a running container.
tag Renames an image (e.g., docker tag oldImage newImage).
pull Pulls a specified image.
push Pushes a specified image. (Not available in CRI-O.)
stop Stops a specified container.
start Starts a specified container.
deleteCon Deletes a specified container.

ContainerD-Specific Commands

Option Description
psTask Lists all existing tasks for containerd.
startTask Starts a task from a given container.
stopTask Stops a specified task.
deleteTask Deletes a specified task.

podConfig and containerConfig

These keys specify JSON or YAML configuration files required for pod creation (e.g., podConfiguration.json or podConfiguration.yaml).

Example 1 - List Running Containers (ps)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "docker / crio / containerd"; 
        option = "ps";
        flag = "--last";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 2 - List Images (images)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "docker / crio / containerd"; 
        option = "images";
        flag = "--all";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 3 - Run a Container (run)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "docker / crio / containerd"; 
        option = "run";
        flag = "-w /path/to/dir/ -i -t";
        srcImage = "registry.kubernative.net/lima:v0.8.0";
        containerName = "myFirstContainer";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 4 - Run a CRI-O Pod

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "crio"; 
        option = "run";
        containerConfig = "/root/podConfig.json / .yaml";
        podConfig = "/root/podConfig.json / .yaml";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 5 - Check Runtime Status (status)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "docker / crio / contianerd"; 
        option = "status";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 6 - Execute a Command in Containerd (exec)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "contianerd"; 
        option = "exec";
        execID = "exec1";
        containerName = "registry.kubernative.net/lima:v0.8.0";
        command = "mkdir /tmp/testdir";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 7 - Execute a Command in Docker / CRI-O (exec)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
} 

install
{
    containerruntime
    (
        type = "docker / crio"; 
        option = "exec";
        containerName = "registry.kubernative.net/lima:v0.8.0";
        command = "mkdir /tmp/testdir";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 8 - Tag an Image (tag)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "docker / containerd"; 
        option = "tag";
        srcImage = "registry.kubernative.net/lima:v0.8.0"; 
        destImage = "yourRegistry/yourName:v0.8.0";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 9 Start, Stop, or Delete a Container (deleteCon, start, stop)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "docker / crio / containerd"; 
        option = "deleteCon / start / stop";
        containerName = "myFirstContainer";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 10 - Pull or Push an Image (pull, push)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "docker / crio / containerd"; 
        option = "pull / push";
        srcImage = "registry.kubernative.net/lima:v0.8.0";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Note: CRI-O does not support the push and tag operations.

ContainerD-Specific Commands

Example 11 List Tasks (psTask)

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "containerd"; 
        option = "psTask";
        flag = "--all";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 12 Start, Stop, or Delete a Task

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    containerruntime
    (
        type = "containerd"; 
        option = "startTask /stopTask / deleteTask";
        flag = "--null-io";
        containerName = "myFirstTask";
        runtime = "status";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

4.8 - copy-1.7.0

KOSI Plugin copy Version 1.7.0

Summary

The copy plugin allows you to copy either a single file or an entire directory, including all its contents, recursively. It provides options to control overwriting behavior when files already exist in the destination.

Keys

Key Description
src Mandatory Specifies the absolute path of the source file or directory to be copied.
dest Mandatory Specifies the absolute path of the destination file or directory where the source will be copied.
overwrite true/false Controls whether existing files in the destination should be replaced.
  • If set to true, any file in the destination with the same name will be replaced.
  • If set to false, an error will be thrown if the file already exists in the destination.
  • If no file with the same name exists, the file will be copied normally, regardless of the overwrite setting.

⚠️ Warning: Overwritten data will be permanently lost and cannot be recovered! Proceed with caution. ⚠️

Usage

Example 1 - Copy file

The following example demonstrates how to copy a single file from a source location to a destination.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    copy
    (
        src = "/absolute/path/to/file"; 
        dest = "/absolute/path/to/the/dest/file";
        overwrite = "true/false";
    );
}

Note: Copying a file will not change its name. The destination file will retain the same name as the source file unless explicitly changed in the dest parameter.

Example 2 - Copy folder

The following example demonstrates how to copy a folder from a source location to a destination.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    copy
    (
        src = "/absolute/path/to/folder"; 
        dest = "/absolute/path/to/the/dest/folder";
        overwrite = "true/false";
    );
}

Example 3 - Copying multiple files with a specific extension

The following example copies all .txt files from the source directory to the destination directory.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = "echo Copying all .txt files from source to destination");
    copy
    (
        src = "/absolute/path/to/source/*.txt"; 
        dest = "/absolute/path/to/destination/"; 
        overwrite = "true/false";
    );
}

4.9 - editFile-1.7.0

KOSI Plugin editFile Version 1.7.0

Summary

The editFile Plugin enables modifications to YAML and text files by allowing users to add, overwrite, or delete specific content. It provides precise control over file edits by targeting YAML keys or specific line numbers in text files.

Keys

operation (required)

Defines the type of modification to be performed. This key accepts one of the following three modes:

Key Description
add Inserts a new value at the specified key (YAML) or line (text).
overwrite Replaces the value of a specified key (YAML) or line (text).
delete Removes a key (YAML) or deletes an entire line (text).

add

Adds a value to a specified key in a YAML file or a specific line in a text file.

  • For YAML files: You must specify the key where the new value should be added.
  • For text files: You must specify the line number where the new text should be inserted.

For example:

- editFile:
    operation: add
    fileType: text
    filePath: "/root/KosiPlugin/script.text"
    key: "spec.clusterMaster.toAdd"
    value: Hier steht ein Text

The key toAdd will be created / written into the file as a subtree of clusterMaster with the given value.

overwrite

Replaces the existing value at a specified key (YAML) or line (text).

Note: add and overwrite work the same for yaml.

delete

Removes a key (YAML) or deletes an entire line (text).

  • For YAML files: The key and its associated value will be removed.
  • For text files: The specified line will be deleted, and subsequent lines will shift up.

filePath (required)

Set the absolute pathe to the file to be edited as the value of this key.

fileType (required)

Defines the type of file being edited.

  • Set to “yaml” for YAML files.
  • Set to “text” for plain text files.

key

This is a mandatory key for yaml files.

This key allows you to specify the key you want to add, overwrite or delete in your yaml file.
Key is based on JSON Path.

For example:

key: "spec.clusterName"

This example shows the value of key, if you want to edit the key clusterName with the parent spec.

Note: If you have a list the key would be as followd:

key: "spec.clusterName.list.[0].Name"

line

This is a mandatory key for text files.

Allows you to set the line number where the operation gets executed.

value (required)

Defines the new value to be written into the file.

  • For text files, use \n to indicate a new line and \t for indentation.
  • For YAML files, this is the value assigned to the specified key.

For example:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    editFile
    (
        operation = "overwrite"; 
        fileType = "text";
        filePath = "/root/KosiPlugin/script.txt";
        line = "3";
        value = "Hier steht ein Text \n
                 \t clusterName: hier steht ein Name \n
                 \t hostips: \n
                 \t \t ips: \n
                 \t \t \t - 192.168.79.130";
    );
}

For yaml files, the whole string is set as the value for the given key.

For text files, when using add, the text will inserted beginning at line. For every newline in value a new line will be added to te file.
When using overwrite, the value will be split into multiple lines and every line in the input will replace one line in the old file starting at line.

Make sure that there are enough lines to overwrite

Examples for yaml files

example file

spec:
  clusterMaster:
    someText: this is an example
    toOverwrite: this will be gone

Example 1 - add new text

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
} 

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    editFile
    (
        operation = "add"; 
        fileType = "text";
        filePath = "/root/KosiPlugin/example.yaml";
        key = "spec.clusterMaster.toAdd";
        value = "this is ne text";
    );
}

Result:

spec:
  clusterMaster:
    someText: this is an example
    toOverwrite: heir steht text
    toAdd: this is new text

Example 2 - overwrite text

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    editFile
    (
        operation = "overwrite"; 
        fileType = "yaml";
        filePath = "/root/KosiPlugin/example.yaml";
        key = "spec.clusterMaster.toOverwrite";
        value = "this replaced the old text";
    );
}

Result:

spec:
  clusterMaster:
    someText: this is an example
    toOverwrite: this replaced the old text

Example 3 - delete text

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    editFile
    (
        operation = "delete"; 
        fileType = "yaml";
        filePath = "/root/KosiPlugin/example.yaml";
        key = "spec.clusterMaster.toOverwrite";
    );
}

Result:

spec:
  clusterMaster:
    someText: this is an example

Examples for text files

example file

bucket list:
 - item 1
 - item 2
 - item 3

Example 1 - add new text

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    editFile
    (
        operation = "add"; 
        fileType = "text";
        filePath = "/root/KosiPlugin/example.txt";
        line = '"5"';
        value = '" - item 4"';
    );
}

Result:

bucket list:
 - item 1
 - item 2
 - item 3
 - item 4

Example 2 - overwrite text

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    editFile
    (
        operation = "overwrite"; 
        fileType = "text";
        filePath = "/root/KosiPlugin/example.txt";
        line = "4";
        value = " - item 3";
    );
}

Result:

bucket list:
 - item 1
 - item 2
 - new item 3

Example 3 - delete text

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    editFile
    (
        operation = "delete"; 
        fileType = "text";
        filePath = "/root/KosiPlugin/example.txt";
        line = "3";
    );
}

Result:

bucket list:
 - item 1
 - item 3

4.10 - firewall-1.7.0

KOSI Plugin Firewall Version 1.7.0

Required Plugins

  • osCheck
  • firewallD
  • IPTables

Summary

The Firewall Plugin allows you to manage your firewall settings efficiently. You can open or close ports, enable or disable the firewall, and retrieve the current firewall status. The plugin currently supports two firewall types:

Keys

Key Description
type Mandatory Specifies the firewall type to which actions will be applied (firewalld or iptables).
action Mandatory Defines the action to be performed (e.g., enable, disable, open, or close ports).
ports Mandatory Required when opening or closing ports. Accepts a list of ports in the format: “ports” or “ports-range”/protocol.
getFirewallStatus Mandatory Stores the firewall status, which can be either “running” or “not running”. If both firewalld and iptables are running, firewalld is selected.

Example

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    firewall
    (
        type = "firewalld";
        action = "close / open / disable";
        ports = "['5555/tcp','6666/tcp','8888-9999/udp']";
        getFirewallStatus = "status";
    );

    fprint
    (
        message = "The firewall is {0}"; 
        variables = "['status']";
    );
}

4.11 - firewallD-1.7.0

KOSI Plugin FirewallD Version 1.7.0

Required Plugins

  • firewallD

Summary

The FirewallD Plugin allows you to manage your firewall settings efficiently. You can open or close ports, enable or disable the firewall, and retrieve the current firewall status. The plugin currently supports two firewall types:

Keys

Key Description
action Mandatory Defines the action to be performed (e.g., enable, disable, open, or close ports).
ports Mandatory Required when opening or closing ports. Accepts a list of ports in the format: “ports” or “ports-range”/protocol.
getFirewallStatus Mandatory Stores the firewall status, which can be either “running” or “not running”. If both firewalld and iptables are running, firewalld is selected.

Example

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    firewallD
    (
        action = "open";
        ports = "['5555/tcp','6666/tcp','8888-9999/udp']";
        getFirewallStatus = "status";
    );
}

4.12 - fprint-1.7.0

KOSI Plugin fprint Version 1.7.0

Summary

The fprint plugin functions similarly to the print plugin by allowing messages to be displayed as key-value pairs. However, fprint extends this functionality by enabling the inclusion of variables from other plugins, which are also printed as part of the message.

For details on handling variables from other plugins, see the loop-plugin Reference.

Keys

Key Description
message Mandatory A string that represents the command-line output message.
variables - A list of strings representing variable names. If these variables were created by other plugins, fprint will retrieve and include their values in the message.

Example

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    set
    (
        variable = "name";
        value = "root";
    );

    set
    (
        variable = "ips";
        value = "0.0.0.0";
    );

    fprint
    (
        message = "Hello {0} with the ips {1}"; 
        variables = "['vars.name','vars.ips']";
    );
}

4.13 - helm-1.7.0

KOSI Plugin Helm Version 1.7.0

Summary

The Helm Plugin allows users to manage Helm packages. It enables the installation, upgrade, and deletion of Helm charts via KOSI package.

The Key Features are:

  • Install Helm charts with custom values and additional flags.
  • Upgrade existing Helm deployments.
  • Delete Helm deployments.
  • Supports namespace customization.
  • Allows the use of multiple values files for configuration.

Keys

Key Required Description
command Yes Defines the operation to perform. Possible values: install, upgrade or delete.
tgz Yes (only for install and upgrade) The filename of the Helm chart archive (.tgz).
values Optional A list of YAML files containing configuration values for the Helm chart.
flags Optional Additional Helm command flags.
namespace Optional, Default: default The Kubernetes namespace in which to deploy the chart.
deploymentName Yes (only for upgrade and delete) Specifies the name of the Helm release. If omitted during installation, a random name will be generated.

Important Notes:

  • A helmvalues.yaml file must be present in the execution directory when running KOSI install commands.
  • The Helm .tgz package (Helm chart) must be included in the files tree inside the includes tree.
  • KOSI’s --dname argument is not related to Helm’s deploymentName parameter. --dname in KOSI is used to define a KOSI deployment name, whereas deploymentName in the Helm plugin specifies the Helm release name.
  • Helm charts and values files (.tgz and .yaml) can be obtained from sources like ArtifactHub, or you can package your own Helm chart using helm package. Knowledge of Helm is required here.

Examples

Example 1 - Helm Install

This command deploys a Helm chart to a Kubernetes cluster.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "helm-installation-example";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    guestbook = "guestbook.tgz";
    values1 = "gbValues.yaml";
    values2 = "values2.yaml";
}

install
{
    cmd(command="echo Installing Helm chart...");

    helm
    (
        command = "install";
        tgz = "guestbook.tgz";
        values = "['gbValues.yaml','values2.yaml']";
        deploymentName = "guestbook";
        namespace = "dev";
    );
}

Explanation

  • The guestbook.tgz Helm chart is installed.
  • Values files (gbValues.yaml and values2.yaml) customize the deployment.
  • The Helm release is named guestbook in the dev namespace.
  • The cmd plugin ensures a status message is displayed before execution.

Example 2 - Helm Upgrade

Upgrades an existing Helm release to a new version or updates its values.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "helm-upgrade-example";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    guestbook = "guestbook.tgz";
    values1 = "gbValues.yaml";
    values2 = "values2.yaml";
}

update
{
    cmd(command = "echo Upgrading Helm chart...");

    helm
    (
        command = "upgrade";
        tgz = "guestbook.tgz";
        values = "['gbValues.yaml','values2.yaml']";
        deploymentName = "guestbook";
        namespace = "dev";
    );
}

Explanation

  • Upgrades the existing guestbook Helm release using an updated guestbook.tgz chart.
  • New configuration values are applied from gbValues.yaml and values2.yaml.

Example 3 - Helm Delete

Deletes a Helm release from the Kubernetes cluster.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "helm-delete-example";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    guestbook = "guestbook.tgz";
    values1 = "gbValues.yaml";
    values2 = "values2.yaml";
}

delete
{
   cmd(command = "echo Deleting Helm chart...");

   helm
   (
      command = "delete";
      deploymentName = "guestbook";
      namespace = "dev";
      flags = "['--wait']";
  );
}

Explanation

  • Deletes the guestbook release from the dev namespace.
  • The --wait flag ensures the command waits for all resources to be fully removed.

4.14 - hostname-1.7.0

KOSI Plugin hostname Version 1.7.0

Summary

The hostname plugin for KOSI allows users to manage and modify the hostname of a machine dynamically. It provides functionalities to:

  • Retrieve and store the current hostname in an internal variable.
  • Permanently set a new hostname.
  • Use a previously stored hostname variable to restore the hostname.
  • Optionally execute hostname changes with elevated privileges (sudo).

This plugin is particularly useful in automated deployments, system provisioning, or scenarios where hostnames need to be dynamically managed during a KOSI package installation.

Keys

Key Required Description
get Optional* Retrieves the current hostname and saves it in a variable for later use. This variable remains accessible until the KOSI session ends.
set Optional* Sets the machine’s hostname to the specified value.
setVar Optional* Sets the hostname using a previously stored variable from the internal storage.
sudo Optional If set to true, the plugin will execute commands with sudo privileges.
sudoPassword Yes if sudo is true The password required for executing sudo commands.

Note:

  • * One of the keys must be present. (Either get, set or setVar)
  • The sudoPassword is mandatory if sudo is enabled, ensuring the required privileges for modifying system settings.

Examples

Example 1 - Retrieve and Store the Current Hostname

This example retrieves the current hostname and saves it in the internal variable oldHostname. The variable can be used later within the same KOSI session.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    hostname
    (
        get = "oldHostname";
        sudo = "true";
        sudoPassword = "YourSecurePassword";
    );
}

Example 2 - Set a New Hostname

This example sets the machine’s hostname to master permanently.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    hostname
    (
        set = "master";
        sudo = "true";
        sudoPassword = "YourSecurePassword";
    );
}

After execution, the system’s hostname will be permanently changed to master.

Example 3 - Restore a Previously Stored Hostname

If a hostname was previously retrieved and stored in oldHostname, this example restores it.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    hostname
    (
        setVar = "oldHostname";
        sudo = "true";
        sudoPassword = "YourSecurePassword";
    );
}

This is particularly useful in rollback scenarios where a hostname needs to be reverted to its original value after temporary changes.

Example 4 - Using hostname Plugin with other plugins

Using hostname with the if and print plugins

This example shows the interaction of several plugins. In this example, we use the hostname plugin together with the if and print plugins to check whether it is the correct hostname and to output a specific message and perform a corresponding action:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-hostname-if-print";
description = "Example using hostname with if and print";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    hostname(get = "oldHostname");

    if (condition = "$oldHostname$ = 'myHostname'") then
    {
        print(message = "The hostname myHostname should not be taken, so the hostname is changed to myVeryVeryNewHostname..");

        hostname
        (
            set = "myVeryVeryNewHostname";
            sudo = "true";
            sudoPassword = "SecurePassword";
        );
    }
    else
    {
        print(message = "The hostname is OK, do not make any changes.");
    }
}

Expected Behavior

If hostname is myHostname:

2025-02-26 15:18:28 Info:      The hostname myHostname should not be taken, so the hostname is changed to myVeryVeryNewHostname..
  • The hostname is changed to myVeryVeryNewHostname.

Otherwise:

2025-02-26 15:18:28 Info:      The hostname is OK, do not make any changes.
  • As we have not specified anything else in the else part of the if plugin, nothing else happens in the else part.

4.15 - if-1.7.0

KOSI Plugin if Version 1.7.0

Summary

The ‘if’ Plugin for KOSI packages enables the introduction of conditional control flow into your workflow. This plugin allows you to define logic that executes specific actions based on whether a given condition is met. It functions similarly to traditional programming if-else statements, where:

  • If the specified condition evaluates to true, a designated block of actions is executed.
  • Else (optional): If the condition evaluates to false, an alternative set of actions can be executed instead.

This functionality provides greater flexibility and decision-making capabilities within KOSI packages, allowing workflows to dynamically adapt based on real-time conditions.

Keys

Key Description
condition Mandatory set to a string that will be evaluated as an expression.
Condition is based on net5.0 DataColumn expressions and follows almost the same syntax. The only difference are plugin variables can also be used in the condition
then Mandatory defines the block of commands that execute if the ‘condition’ evaluates to true. Commands inside the then block will run sequentially when the condition holds true.
else Optional defines an alternative block of commands that execute if the ‘condition’ evaluates to false. If omitted, no alternative actions will take place when the condition is false.

Syntax to access plugin variables inside condition :

When using the set plugin:

condition = "$vars.variableName$"

When using other plugins that set variables (for example osCheck):

condition = "$variableName$"

Syntax to access KOSI templating of values.yaml inside condition :

condition = '{{values.variable}}'

Example

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    guestbook = "guestbook.tgz";
    gbValues = "gbValues.yaml";
    values2 = "values2.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = "echo Using the if plugin.");

    if(condition = "'{{values.myVar}}' < 0") then
    {
        print(message = "myVar is less than 0.");
    }
    else
    {
        print(message = "myVar is equal or greater than 0.");
    }
    
    print(message = "This will always print.");
}

Result

[ 06/22/2021 16:56:54 Info    default ] myVar is equal or more than 0 
[ 06/22/2021 16:56:54 Info    default ] this will always print

or

[ 06/22/2021 16:57:37 Info    default ] myVar is less than 0 
[ 06/22/2021 16:57:37 Info    default ] this will always print

All expressions are expected to evaluate to either ‘True’ or ‘False’ otherwise the ‘if’ plugin will exit with an error.

4.16 - ipTables-1.7.0

KOSI Plugin IPTables Version 1.7.0

Required Software

  • iptables

Summary

With this plugin you can manage iptables. You can either open/close ports or disable/enable it. Additionally it is possible to gather information about the iptables status.

Keys

Key Description
action Mandatory Similiar to the service Plugin you can enable and disable iptables as well as open and close ports.
ports If you want to open or close any ports the key ports which requires a list ("ports" or "ports-range"/protocol) is mandatory. Any ports like in the schema above are valid.
getFirewallStatus set to a variable name in which status of the iptables will be stored. The status will be either: "running" / "not running"

Example

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    iptables
    (
        action="close / open / disable";
        ports="['5555/tcp','6666/tcp','8888-9999/udp']";
        getFirewallStatus="status"
    );
}

4.17 - kosi-2.12.0

KOSI Plugin kosi Version 2.12.0

Summary

The kosi plugin provides a means to use features of kosi within a kosi plugin. It enables automation of various package operations, such as logging into a registry, pulling packages, installing, updating, and deleting them within a Kubernetes cluster.

With the kosi plugin, you can:

  • Automatically authenticate to a package registry (hub)
  • Install packages
  • Update already installed packages
  • Delete deployed packages
  • Pull packages for offline usage or custom deployment scenarios

This plugin is particularly useful for automating deployment workflows, ensuring that Kubernetes resources are managed efficiently.

Keys

Depending on the command being executed, different keys must be set. Below is a list of available keys:

Key Required Default Value Description
command Yes - Specifies the KOSI command to execute (login, install, update, delete, pull).
userVar Yes (for login) - The username for authentication.
passwordVar Yes (for login) - The password in plain text for authentication.
userHub Yes - The user hub (registry) to interact with. Use public for public repositories.
sourcePath Yes (for install, delete, update) - The package name or path to install, update, or delete.
sourceRegistry Yes (for install, delete, update) - The registry where the package is located.
local Optional (for install, delete, update) false Either a package from a hub or a local KOSI package.
deploymentName Optional Package name Name assigned to the deployed package in the cluster. Required for updates.
nameSpace Optional default Kubernetes namespace where the package is deployed.
package Yes (for pull) - Name of the package to pull.
packageDestinationPath Yes (for pull) - Path where the pulled package should be saved.
destinationRegistry Optional (for pull) - Destination registry if retagging is enabled.
targetRegistry Optional (for pull) - Target registry for retagged images.
retag Optional false Whether to retag images when pulling.
values Optional - A list of values equivalent to the -f option in KOSI CLI.

Features

Login

Login enables you to log in to your KubeOps user account. This is required to upload packages to a hub and to download packages from a private hub.
Both the username and password must be entered in plain text in package.yaml.

Install

The install command can be used to download and install packages from any registry. If this is a public package you have to set your userHub to “public”. Otherwise you have to set the userHub, where the package is located. In addition, the namespace in which the package is to be installed can be specified and the name of the deployed package in the cluster can be changed.

Update

The update command updates an already installed KOSI package. For update, the installation and the update package have to be the same name. Update will be defined in the package.yaml (example 3 - Update). If this is a public package you have to set your userHub to “public”. Otherwise you have to set the userHub, where the package is located

Delete

The delete command can be used to delete packages from any registry. The command delete expected parameters like sourcePath, sourceRegistry and deploymentName, which are also marked as required. If this is a public package you have to set your userHub to “public”. Otherwise you have to set the userHub, where the package is located

The nameSpace parameter can be used to specify the name of the package to be deleted.

Pull

The pull command can be used to pull packages from any registry. The command pull expected parameters like package, packageDestinationPath and userHub, which are also marked as mandatory. If you want to pull your images in your own registry you can use the destinationRegistry parameter. If you want to pull your images in your own registry and change your deployment automatically you can use destinationRegistry and targetRegistry. In both scenarios you have to use the retag parameter.

Examples

Example 1 - Login

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    kosi
    (
        command = "login";
        userVar = "exampleUser";
        passwordVar = "examplePW";
        hub = "http://dispatcher.kubeops.net/dispatcher/";
    );
}

Example 2 - Install

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    kosi
    (
        command = "install";
        sourcePath = "kosi/kubeops-kubernetes-plugins:0.0.1";
        sourceRegistry = "registry1.kubeops.net";
        deploymentName = "kubernetes-plugins";
        hub = "http://dispatcher.kubeops.net/dispatcher/";
        nameSpace = "kosi";
        values = "['values.yaml']";
        userHub = "public";
        local = "false";
    );
}

Example 3 - Install local package

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    kosi
    (
        command = "install";
        sourcePath = "/root/kosi-test/package.tgz";
        sourceRegistry = "registry1.kubeops.net";
        deploymentName = "kubernetes-plugins";
        hub = "http://dispatcher.kubeops.net/dispatcher/";
        nameSpace = "kosi";
        values = "['values.yaml']";
        userHub = "public";
        local = "true";
    );
}

Example 4 - Update

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

update
{
    kosi
    (
        command = "update";
        sourcePath = "/root/kosi-test/package.tgz";
        sourceRegistry = "registry1.kubeops.net";
        deploymentName = "kubernetes-plugins";
        hub = "http://dispatcher.kubeops.net/dispatcher/";
        nameSpace = "kosi";
        values = "['values.yaml']";
        userHub = "public";
        local = "true";
    );
}

Example 5 - Delete

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

delete
{
    kosi
    (
        command = "delete";
        sourcePath = "/root/kosi-test/package.tgz";
        sourceRegistry = "registry1.kubeops.net";
        deploymentName = "kubernetes-plugins";
        hub = "http://dispatcher.kubeops.net/dispatcher/";
        nameSpace = "kosi";
        values = "['values.yaml']";
        userHub = "public";
        local = "true";
    );
}

Example 6 - Pull with retag

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    kosi
    (
        command = "pull";
        hub = "http://dispatcher.kubeops.net/dispatcher/";
        package = "lima/kubernetes:1.24.7";
        packageDestinationPath = "/root/kubernetes-1.24.7/package.tgz";
        destinationRegistry = "localhost:5000/myimages";
        targetRegistry = "myregistry.net/myimages";
        retag = "true";
    );
}

Example 7 - Using Kosi Plugin with other plugins

Using kosi with the osCheck, if and print plugins

This example shows the interaction of several plugins. In this example, we use the kosi plugin together with the osCheck, if and print plugins to check whether it is the correct operating system and to output a specific message as well as to execute a corresponding Kosi install operation with the kosi plugin:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-kosi-oscheck-if-print";
description = "Example using kosi with oscheck and if and print";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    inputRhel = "rhel8.yaml";
    inputOtherOS = "otherOs.yaml";
}

install
{
    osCheck
    (
        getOSVar = "os";
        getOSVersionVar = "version";
    );

    if (condition = "$os$ = 'Red Hat Enterprise Linux'") then
    {
        print(message = "Performing Kosi install for RHEL 8..");
        kosi
        (
            command = "install";
            sourcePath = "/root/kosi-test/rhel8/package.tgz";
            sourceRegistry = "registry1.kubeops.net";
            deploymentName = "rhel8-kosi";
            hub = "http://dispatcher.kubeops.net/dispatcher/";
            nameSpace = "kosi";
            values = "['rhel8.yaml']";
            userHub = "public";
            local = "true";
        );
    }
    else
    {
        print(message = "Other OS recognized instead of RHEL 8, performing alternative Kosi install..");
        kosi
        (
            command = "install";
            sourcePath = "/root/kosi-test/otherOs/package.tgz";
            sourceRegistry = "registry1.kubeops.net";
            deploymentName = "otherOs-kosi";
            hub = "http://dispatcher.kubeops.net/dispatcher/";
            nameSpace = "kosi";
            values = "['otherOs.yaml']";
            userHub = "public";
            local = "true";
        );
    }
}

Expected Behavior

If os is Red Hat Enterprise Linux:

2025-02-26 15:18:28 Info:      Performing Kosi install for RHEL 8..
  • The local Kosi package /root/kosi-test/rhel8/package.tgz is installed with the values rhel8.yaml.

Otherwise:

2025-02-26 15:18:28 Info:      Other OS recognized instead of RHEL 8, performing alternative Kosi install..
  • The local Kosi package /root/kosi-test/otherOs/package.tgz is installed with the values otherOs.yaml.

4.18 - kubeadm-1.7.0

KOSI Plugin kubeadm Version 1.7.0

Summary

This plugin can be used to execute kubeadm commands.

Keys

Key Description
action - Action performed when upgrade is used as an operation.
kubeadmVersion - Any offical verb supported by Kubernetes is allowed when you try the operation “config” or “can-i”
outputVar Mandatory Save the output of the executed command in the offered variable.
sudo - Can be true or false. If it is true the Plugin will be executet with sudo privileges.
sudoPassword - If you use sudo, sudoPassword will be mandatory.
phase - Phase which will be initialized when using init phase as an operation.
token - Save the token of the token create command in the offered variable.
operation - The operations shown above are currently supported when using the kubeadm plugin. Depending on the operation the following inputs are required:
  • Operation “version” requires kubeadmVersion to save the output kubeadmVersion. It’s recommended to use the flag -o short to get only the Version as output.
  • Operation “init phase” requires a phase. E.g certs or kubeconfig.
  • Operation “token create” requires a token to save the created token into a variable.
  • Operation “upgrade” requires an action. E.g plan oder apply.

action

Action performed when upgrade is used as an operation.

kubeadmVersion

Any offical verb supported by Kubernetes is allowed when you try the operation “config” or “can-i”

operation

The operations shown above are currently supported when using the kubeadm plugin. Depending on the operation the following inputs are required:

  • Operation “version” requires kubeadmVersion to save the output kubeadmVersion. It’s recommended to use the flag -o short to get only the Version as output.
  • Operation “init phase” requires a phase. E.g certs or kubeconfig.
  • Operation “token create” requires a token to save the created token into a variable.
  • Operation “upgrade” requires an action. E.g plan oder apply.

Example

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/kosi/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
  input="template.yaml";
}

containers =
{
    example=["docker.io", "nginx", "latest"];
}

install
{
    kubeadm(
      operation="version"/"reset"/"init"/"init phase"/"token create"/"upgrade";
      kubeadmVersion="version";
      phase="kubelet-start"/"certs"/"kubeconfig"/"control-plane"/"...";
      action="plan"/"apply"/"node"/"apply v1.22.x"/"...";
      flag="-f PathToYAML -n kube-system -o wide"/"...";
      outputVar: "outputStorage";
      token="kubeadmToken";
      sudo="true";
      sudoPassword="Drowssap");
}

4.19 - kubectl-1.7.0

KOSI Plugin Kubectl Version 1.7.0

Summary

The kubectl plugin allows to interact with Kubernetes clusters by executing kubectl commands within a KOSI package. This plugin provides a convenient way to manage Kubernetes resources, retrieve information and execute administrative tasks directly within a KOSI package. It supports various kubectl operations, including retrieving, creating, updating, and deleting Kubernetes resources.

The plugin integrates seamlessly with Kubernetes by supporting all official resource types and their associated subcommands. Additionally, it allows users to save command outputs as variables or files and provides the option to execute commands with elevated privileges using sudo.

Keys

Key Required Description
operation Yes Specifies the kubectl subcommand to execute, such as get, apply, delete, etc.
resource Yes (for most operations) Defines the type of Kubernetes resource being operated on (e.g., pod, service, deployment).
resourceName Optional Specifies the name(s) of the resource(s) to target. Names are case-sensitive. If omitted, the command applies to all resources of the given type.
flags Optional Additional flags for the kubectl command. If using -f, an absolute file path must be provided. Multiple flags should be separated by spaces. Example: "-f /path/to/file.yaml -A -o wide".
verb Optional Specifies an additional action supported by Kubernetes, such as can-i for checking permissions. Used in combination with relevant operations.
outputVar Optional Stores the command output in a variable for use in subsequent operations within the KOSI package.
outputFile Optional Saves the output of the command to a specified absolute file path.
sudo Optional Set to true to execute the command with sudo privileges.
sudoPassword Yes (if sudo is enabled) Specifies the password required for sudo execution.

Notes:

  • Ensure that the Kubernetes cluster is accessible from the system where KOSI is running.
  • When using sudo, ensure the correct password is provided, or configure NOPASSWD for the executing user in the system’s sudoers file.
  • The plugin supports all standard Kubernetes resources and their associated operations.
  • Use outputVar or outputFile to capture command outputs for further processing.

Examples

Example 1 - Retrieving Information About a Specific Pod

This example retrieves details about a specific pod called testDeployment in the kube-system namespace. The output is stored in a variable and saved to a file.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    kubectl
    (
        operation = "get";
        resource = "pods";
        resourceName = "testDeployment";
        flags = "-n kube-system -o wide";
        outputVar = "outputGet";
        outputFile = "/root/outputKubectlGet.txt";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 2 - Checking User Permissions

This example checks whether the current user has permission to list pods in the cluster using the can-i command.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
  input = "template.yaml";
}

install
{
    kubectl
    (
        operation = "auth";
        verb = "can-i";
        flags = "list pods";
        outputVar = "permissionCheck";
    );
}

Example 3 - Applying a Configuration File

This example applies a Kubernetes manifest file located at /home/user/deployment.yaml.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    kubectl
    (
        operation = "apply";
        flags = "-f /home/user/deployment.yaml";
    );
}

Example 4 - Deleting Multiple Pods

This example deletes two specific pods named example-pod1 and example-pod2 with sudo privileges.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    kubectl
    (
        operation = "delete";
        resource = "pod";
        resourceName = "example-pod1 example-pod2";
        sudo = "true";
        sudoPassword = "Drowssap";
    );
}

Example 5 - Saving Output to a File

This example retrieves a list of all services and saves the output to a file at /var/log/kubectl_services.log.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    kubectl
    (
        operation = "get";
        resource = "services";
        flags = "-A";
        outputFile = "/var/log/kubectl_services.log";
    );
}

4.20 - loop-1.7.0

KOSI Plugin loop Version 1.7.0

Summary

The loop plugin enables repeated execution of specific parts of your KOSI package YAML while iterating over a list. It functions similarly to a “for each” loop in other programming languages. During each iteration, an iterator variable holds the current element from the list, allowing dynamic access within the looped section.

Keys

Key Description
iterator Mandatory Specifies the variable name that will hold the current item in the list during each loop iteration. Must be a valid string representing a variable name.
list Mandatory when listVar is not set Defines an inline list in YAML format that will be iterated over. Cannot be used together with listVar.
listVar Mandatory when list is not set Specifies a pre-defined variable (set by another plugin) that contains a list. Allows looping over dynamic lists instead of hardcoded values.

Example 1 - Iterating Over a List

In this example, the loop iterates over a predefined list [1,2,3], and the number iterator variable holds the current item in each iteration.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}


install 
{  
    loop
    (
        iterator = "number";
        list = "[1,2,3]";
    )
    {
        fprint
        (
            message = "Hello {0}";
            variables ="[number]";
        );
    }
}
[ 06/18/2021 13:04:29 Info    default ] Hello 1
[ 06/18/2021 13:04:29 Info    default ] Hello 2
[ 06/18/2021 13:04:29 Info    default ] Hello 3

4.21 - merge-1.7.0

KOSI Plugin Merge Version 1.7.0

Summary

The Merge plugin for KOSI enables the merging of XML files, allowing users to combine multiple XML sources into a single target file within a KOSI package.

The plugin supports merging a single XML file into another or merging all XML files within a specified directory into a target file. Additionally, users can create a backup of the original target file before applying the merge, ensuring data safety.

Features

  • Merges XML files: Supports merging one or multiple XML source files into a target XML file.
  • Directory merging support: Merges all XML files from a specified directory into the target file.
  • Backup creation: Optionally stores a backup of the target file before merging.

Keys

Key Required Description
file1 Yes The target XML file where the merge operation will be applied.
file2 Yes The source XML file or directory containing multiple XML files to be merged into file1.
backupPath Optional If specified, a backup of file1 will be created in this location before merging.

Notes

  • If file2 is a single file, that file will be merged into file1.
  • If file2 is a directory, all XML files within that directory will be merged into file1.
  • The plugin only supports XML files at this time. Other file formats are not supported.

Examples

Example 1 - Merging a single XML file into another

This example merges /root/config-update.xml into /root/config.xml, while keeping a backup of /root/config.xml in the /root/backup/ directory.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{  
    merge
    (
      file1 = "/root/config.xml";
      file2 = "/root/config-update.xml";
      backupPath = "/root/backup/";
    );
}

Example 2 - Merging all XML files from a directory into a target file

In this case, the plugin merges all XML files located in /root/xml-updates/ into /root/main-config.xml. A backup of /root/main-config.xml is created in /root/backup/ before applying the merge.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{  
    merge
    (
        file1 = "/root/main-config.xml";
        file2 = "/root/xml-updates/";
        backupPath = "/root/backup/";
    );
}

Example 3 - Merging without backup

This example merges /root/new-settings.xml into /root/settings.xml without creating a backup.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{  
    merge
    (
        file1 = "/root/settings.xml";
        file2 = "/root/new-settings.xml";
    );
}

4.22 - osCheck-1.7.0

KOSI Plugin osCheck Version 1.7.0

Summary

The osCheck plugin is used to detect the operating system name and version on which the plugin is executed. This information is stored in temporary variables, making it available for use by other plugins, such as fPrint. By utilizing osCheck, users can dynamically access OS details within their KOSI packages, enabling better system-specific configurations and logging.

Keys

Key Description
getOSVar Mandatory Set a variable name in which the OS name should be stored.
getOSVersionVar Mandatory Set a variable name in which the OS version should be stored.

Examples

Example 1

In the example below, the OS name will be stored in the temporary variable os, and the version name in the variable version. The fprint plugin has been added to generate console output, displaying the detected OS name and version.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install 
{  
    osCheck
    (
        getOSVar = "os";
        getOSVersionVar = "version";
    );

    fprint
    (
        message = "The OS system is {0} in version {1}.";
        variables = "[os,version]"
    );
}

Expected Output

2025-01-31 16:56:23 Info:      KOSI version: 2.11.3.0_1734015070
2025-01-31 16:56:24 Info:      The OS system is Red Hat Enterprise Linux in version 8.9.
2025-01-31 16:56:24 Info:      Installation successful.

Example 2

Using osCheck with the if and print plugins

This example shows the interaction of several plug-ins. In this example, we use the osCheck plugin together with the if and print plugins to check the condition whether it is the correct operating system and output a message accordingly:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-oscheck-if";
description = "Example using oscheck with if";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

install
{
    osCheck
    (
        getOSVar = "os";
        getOSVersionVar = "version";
    );

    if (condition="$os$ = 'Red Hat Enterprise Linux'") then
    {
        print(message = "This is the expected OS.");
    }
    else
    {
        print(message = "Wrong OS.");
    }
}

Expected Output

If os is ‘Red Hat Enterprise Linux’:

2025-02-26 15:18:28 Info:      This is the expected OS.

Otherwise:

2025-02-26 15:18:28 Info:      Wrong OS.

4.23 - packagemanager-1.7.0

KOSI Plugin Packagemanager Version 1.7.0

Summary

The Packagemanager Plugin provides a possibility for managing software packages on supported Linux distributions within a KOSI package. With this plugin users can:

  • Install new software packages.
  • Update installed packages to the latest versions.
  • Remove software packages that are no longer needed.
  • List installed packages.
  • Search for available packages in the package repository.

Supported Linux Distributions

Currently, this plugin supports only CentOS and uses the YUM package manager for executing package-related operations.

Keys

Key Mandatory Description
operation Yes Defines the action to be performed. Acceptable values: install, update, remove, list, search.
packages Yes Specifies the package(s) to be managed. Multiple packages can be specified as a space-separated string.
flags Optional Optional flags for the package manager (e.g., -y for automatic confirmation, -v for verbose output).
sudo Optional Set to true to execute the command with elevated privileges. Default is false.
sudoPassword Yes (if sudo is true) Required if sudo is set to true. Specifies the password for executing commands with elevated privileges.

Examples

The following examples demonstrate different package management tasks using the Package Manager Plugin on a CentOS system.

Example 1 - Install a Package or Multiple Packages

Installs nano and containerd-1.4.10 using yum.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install
{  
    packagemanager
    (
        operation = "install";
        packages = "nano containerd-1.4.10";
        sudo = "true";
        sudoPassword = "mySecurePassword";
    );
}

Example 2 - Update a Package or Multiple Packages

Updates docker and containerd to the latest versions.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install
{  
    packagemanager
    (
        operation = "update";
        packages = "docker containerd";
        sudo = "true";
        sudoPassword = "mySecurePassword";
    );
}

Example 3 - Remove a Package

Removes nano from the system.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install
{  
    packagemanager
    (
        operation = "remove";
        packages = "nano";
        sudo = "true";
        sudoPassword = "mySecurePassword";
    );
}

Example 4 - List Installed Packages

Lists all installed packages related to containerd.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install
{  
    packagemanager
    (
        operation = "list";
        packages = "containerd";
        sudo = "true";
        sudoPassword = "mySecurePassword";
    );
}

Example 5 - Search for a Package

Searches for available kubernetes packages in the YUM repository.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install
{  
    packagemanager
    (
        operation = "search";
        packages = "kubernetes";
        sudo = "true";
        sudoPassword = "mySecurePassword";
    );
}

Example 6 - Consecutive Operations with Different Flags

Performs consecutive list operations on kubeadm, one with default settings and another with additional flags.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install
{  
    packagemanager
    (
        operation = "list";
        packages = "kubeadm";
        sudo = "true";
        sudoPassword = "mySecurePassword";
    );

    packagemanager
    (
        operation = "list";
        packages = "kubeadm";
        flags = "-y -v";
        sudo = "true";
        sudoPassword = "mySecurePassword";
    );
}

Example 7 - Using Packagemanager Plugin with other plugins

Using packagemanager with the osCheck, if and print plugins

This example shows the interaction of several plugins. In this example, we use the packagemanager plugin together with the osCheck, if and print plugins to check whether it is the correct operating system and to output a specific message and execute a corresponding Packagemanager operation with the packagemanager plugin:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagemanager-oscheck-if-print";
description = "Example using packagemanager with oscheck and if and print";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

install
{
    osCheck
    (
        getOSVar = "os";
        getOSVersionVar = "version";
    );

    if (condition = "$os$ = 'CentOS 7'") then
    {
        print(message="Performing Packagemanager operation for CentOS 7..");

        packagemanager
        (
            operation = "install";
            packages = "nano containerd-1.4.10";
            sudo = "true";
            sudoPassword = "mySecurePassword";
        );
    }
    else
    {
        print(message="Other OS recognized instead of CentOS 7, skipping");
    }
}

Expected Behavior

If os is CentOS 7:

2025-02-26 15:18:28 Info:      Performing Packagemanager operation for CentOS 7..
  • The nano and containerd-1.4.10 software packages are installed on the machine.

Otherwise:

2025-02-26 15:18:28 Info:      Other OS recognized instead of CentOS 7, skipping
  • As we have not specified anything else in the else part of the if plugin, nothing else happens in the else part.

4.24 - pia-1.7.0

KOSI Plugin PIA Version 1.7.0

Summary

The PIA plugin (Plugin-based Infrastructure Administrator) is designed to automate administrative tasks in Kubernetes clusters by enabling remote command execution and file transfers. It operates in two modes:

  • SSH Mode: Executes commands and transfers files via SSH, requiring a specified user with appropriate permissions.
  • K8s Mode: Uses the Kubernetes Mode (kubectl) to create and deploy custom resources for execution by the PIA operator.

This plugin simplifies managing multiple nodes, making it useful for executing system configurations, software deployments, and maintenance tasks across a cluster.

Keys

Key Required Description
mode Yes Defines how PIA operates. Possible values: ssh or k8s.
nodes Yes (or only labels) Specifies target nodes where commands should be executed. Either nodes or labels must be set.
labels Yes (or only nodes) Defines node selection via labels instead of explicit node names. Either nodes or labels must be set.
files Optional Lists files to be uploaded before executing the command. Files in ssh mode are uploaded to PIAROOT, located at KUBEOPSROOT/pia.
command Yes Specifies the command to be executed on the target nodes.
user Yes in ssh mode Defines the user for SSH connections. Typically requires root privileges.

Notes:

  • The user key is only applicable in SSH mode.
  • The default path for KUBEOPSROOT is /var/kubeops - in this case the PIAROOT is in /var/kubeops/pia.

Examples

Example 1 - SSH Mode

In this example, the PIA plugin transfers template.yaml to specified nodes and executes a command under the root user.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    pia
    (
        mode = "ssh";
        nodes = "['cluster2master1', 'cluster2master2']";
        files = "['template.yaml']";
        command = "echo Hello World";
        user = "root";
    );
}

Expected Behavior

  • The template.yaml file is uploaded to PIAROOT, located at KUBEOPSROOT/pia on cluster2master1 and cluster2master2.
  • The command echo Hello World is executed on each node using SSH.
  • The connection is established under the root user.

Recommendation: The specified user should have root privileges to execute administrative commands effectively.

Example 2 - K8s Mode

In Kubernetes mode, the PIA plugin deploys a custom resource that gets processed by the PIA operator.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    pia
    (
        mode = "k8s";
        nodes = "['cluster2master1','cluster2master2']";
        files = "['template.yaml']";
        command = "echo Hello World";
    );
}

Expected Behavior

  • The plugin generates a customresource.yaml in the KUBEOPSROOT/pia directory.
  • The template.yaml file is uploaded.
  • A Kubernetes Custom Resource is deployed, which the PIA operator processes.

Sample installation log:

[root@cluster2admin1 Test_Pia-Plugin]# kosi install -p package.tgz
2024-01-24 12:12:03 Info:      KOSI version: 2.9.0_Beta0_1704450448
2024-01-24 12:12:05 Info:      template.yaml start uploading to webserver.
2024-01-24 12:12:05 Info:      template.yaml successfully uploaded to webserver.
pia.kubeops.net/example-pia created
2024-01-24 12:12:08 Info:      Installation successful

Example 3 - Using PIA Plugin with other plugins

Using pia with the osCheck, if and print plugins

This example shows the interaction of several plugins. In this example, we use the pia plugin together with the osCheck, if and print plugins to check whether it is the correct operating system and to output a specific message and execute a corresponding PIA operation with the pia plugin:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-pia-oscheck-if-print";
description = "Example using pia with oscheck and if and print";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    inputRhel = "rhel8.yaml";
    inputOtherOS = "otherOs.yaml";
}

install
{
    osCheck(getOSVar = "os"; getOSVersionVar = "version");

    if (condition = "$os$ = 'Red Hat Enterprise Linux'") then
    {
        print(message = "Performing PIA operation for RHEL 8..");
        pia
        (
            mode = "ssh";
            nodes = "['cluster2master1']";
            files = "['rhel8.yaml']";
            command = "echo Hello RHEL 8";
            user = "rhel8User";
        );
    }
    else
    {
        print(message = "Other OS recognized instead of RHEL 8, performing alternative PIA operation..");
        pia
        (
            mode = "ssh";
            nodes = "['cluster2master1']";
            files = "['otherOs.yaml']";
            command = "echo Hello other OS";
            user = "otherUser";
        );
    }
}

Expected Behavior

If os is Red Hat Enterprise Linux:

2025-02-26 15:18:28 Info:      Performing PIA operation for RHEL 8..
  • The rhel8.yaml file is uploaded to cluster2master1.
  • The command echo Hello RHEL 8 is executed on each node using SSH.
  • The connection is established under the rhel8User user.

Otherwise:

2025-02-26 15:18:28 Info:      Other OS recognized instead of RHEL 8, performing alternative PIA operation..
  • The otherOs.yaml file is uploaded to cluster2master1.
  • The command echo Hello other OS is executed on each node using SSH.
  • The connection is established under the otherUser user.

PIA Operator (Plugin-based Infrastructure Administrator)

Additional Information

The PIA operator processes Kubernetes-based PIA tasks by handling deployed Custom Resources.

Note: The following information does not refer directly to the PIA plug-in, but to the CRD via PIA operator and serves as additional information on the functionality of PIA and as a possible alternative use.

Installation

  1. Create values.yaml with registry credentials:
pullsecretRegistry: "https://registry.preprod.kubernative.net"
pullsecretUser: "<username>"
pullsecretPassword: "<userpassword>"
piaWebserverNodePort: 31213

Explanation:

  • pullsecretUser and pullsecretPassword are authentication credentials for the image registry.
  • piaWebserverNodePort defines the NodePort service for the PIA web server, which is used to manage uploaded files.
  1. Install the PIA operator:
kosi install --hub public kubeops/piaoperator:0.1.0 -f values.yaml

Verifying Deployment

After installation, check if the operator is running:

kubectl get pods -n pia-test

Using the PIA Operator

There are two ways to use the operator:

  1. Via the PIA plugin (as shown in the examples above).
  2. By manually deploying a Custom Resource Definition (CRD).

Example: Pia Custom Resource

apiVersion: kubeops.net/v1alpha1
kind: Pia
metadata:
  name: hello-world
  namespace: pia-test
spec:
  command: "echo Hello world; sleep 60;"
  jobId: abcdef
  nodes:
  - cluster2worker1
  - cluster2worker3
  labels:
  #- kubeops-zone=zone2
  files:
  #- file1

4.25 - print-1.7.0

KOSI Plugin Print Version 1.7.0

Summary

The Print plugin for KOSI allows users to display messages on the command line during a KOSI package operation. It is particularly useful for debugging, logging, or providing status updates within a KOSI package. You can print multiple messages in succession if needed.

Best Practices

  • Use the Print plugin to make your KOSI packages more user-friendly by providing status updates and progress messages.
  • Avoid excessive printing, which may clutter the terminal output; focus on critical information.
  • Messages are logged with timestamps, making them useful for debugging and tracking execution flow.

Keys

Key Mandatory Description
message Yes The text message to be displayed on the command line.

Examples

Example 1 - Printing a single message

This example demonstrates how to print a single message to the command line.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = "echo Starting the KOSI install package execution...");

    print(message = "Execution has started successfully.");
}

Output

Starting the KOSI install package execution...
2023-12-01 13:38:14 Info: Execution has started successfully.

Example 2 - Printing multiple messages

In this example, multiple messages are printed during different stages of execution.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = "echo Initializing installation process...");

    print(message = "Step 1: Checking prerequisites...");

    print(message = "Step 2: Downloading required files...");

    print(message = "Step 3: Installation in progress...");

    print(message = "Installation completed successfully.");
}

Output

Initializing installation process...
2023-12-01 13:41:20 Info: Step 1: Checking prerequisites...
2023-12-01 13:41:21 Info: Step 2: Downloading required files...
2023-12-01 13:41:23 Info: Step 3: Installation in progress...
2023-12-01 13:41:25 Info: Installation completed successfully.

Note: The example above does not download and install anything, it only shows a best practice example with the print plugin.

4.26 - service-1.7.0

KOSI Plugin Service Version 1.7.0

Summary

The Service plugin allows you to manage system services by starting, stopping, restarting and checking their status. It acts as a wrapper for the systemctl command, which is commonly used on Linux-based systems to control services.

This plugin is particularly useful for managing important services such as web servers (e.g. nginx, httpd), databases (e.g. mysql, postgresql) and other system daemons within a KOSI package, if the desired service is available on your system.

With the Service plugin, you can:

  • Start a service to ensure it is running.
  • Stop a service to terminate its execution.
  • Restart a service to apply configuration changes.
  • Check the status of a service to verify its current state.

Keys

Key Required Description
name Yes Specifies the name of the service to be managed.
state Yes Defines the operation to perform on the service. Supported values: start, stop, restart, status.
sudo Optional If set to true, the command will be executed with elevated privileges.
sudoPassword Yes if sudo is true Provides the password for sudo authentication.

Examples

Note: The services in the following examples assume that the corresponding services exist in the system.

Example 1 - Start a Service

This example starts the Apache HTTP Server (httpd).

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    service
    (
        name = "httpd";
        state = "start";
        sudo = "true";
        sudoPassword = "securePassword";
    );
}

Example 2 - Stop a Service

This example stops the Apache HTTP Server.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    service
    (
        name = "httpd";
        state = "stop";
        sudo = "true";
        sudoPassword = "securePassword";
    );
}

Example 3 - Restart a Service

Restarting a service can be useful after configuration changes.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    service
    (
        name = "httpd";
        state = "restart";
        sudo = "true";
        sudoPassword = "securePassword";
    );
}

Example 4 - Check Service Status

This command checks whether the httpd service is currently running.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    service
    (
        name = "httpd";
        state = "status";
        sudo = "true";
        sudoPassword = "securePassword";
    );
}

Example 5 - Using Service Plugin with other plugins

Using service with the osCheck, if and print plugins

This example shows the interaction of several plugins. In this example, we use the service plugin together with the osCheck, if and print plugins to check whether it is the correct operating system and to output a specific message and execute a corresponding operation with the service plugin:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-service-oscheck-if-print";
description = "Example using service with oscheck and if and print";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    osCheck
    (
        getOSVar = "os";
        getOSVersionVar = "version";
    );

    if (condition = "$os$ = 'Red Hat Enterprise Linux'") then
    {
        print(message = "Performing stop service for RHEL 8..");

        service
        (
            name = "rhelService";
            state = "stop";
            sudo = "true";
            sudoPassword = "securePassword";
        );
    }
    else
    {
        print(message = "Other OS recognized instead of RHEL 8, performing stop for an alternative service..");
      
        service
        (
            name = "differentService";
            state = "stop";
            sudo = "true";
            sudoPassword = "securePassword";
        );
    }
}

Expected Behavior

If os is Red Hat Enterprise Linux:

2025-02-26 15:18:28 Info:      Performing stop service for RHEL 8..
  • The rhelService service has been stopped.

Otherwise:

2025-02-26 15:18:28 Info:      Other OS recognized instead of RHEL 8, performing stop for an alternative service..
  • The differentService service has been stopped.

4.27 - set-1.7.0

KOSI Plugin Set Version 1.7.0

Changelog Plugin set 1.7.0

New

  • set variables inside a KOSI process

Summary

The ‘set’ Plugin allows you to set variables inside a KOSI process to get access for other plugin calls.

Keys

Key Description
variable Mandatory The variable name for accessing the variable.
value Mandatory The value of the variable.

Syntax to access plugin variables inside KOSI:

{{ vars.myvariable }}

values.yaml

usecase: "user" #or "kubeops"

Example Package

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-set-demo-package";
description = "kosi-set-demo-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    set
    (
        variable = "kubeopsvariable";
        value = "Hello KubeOps";
    );

    set
    (
        variable = "uservariable";
        value = "Hello User, you use the set-plugin";
    );

    set
    (
        variable = "ifcondition";
        value = "{{ values.usecase }}";
    );

    if(condition = "$vars.ifcondition$ = 'user'";) then
    {
        print(message = "Your ifcondition-variable: {{ vars.ifcondition }}");
        print(message = "Your usecase-values: {{ values.usecase }}");
        print(message = "Your user-variable: {{ vars.uservariable}}");
    } else
    {
        print(message = "Your ifcondition-variable: {{ vars.ifcondition }}");
        print(message = "Your usecase-values: {{ values.usecase }}");
        print(message = "Your kubeops-variable:{{ vars.kubeopsvariable }}");
    }
    print(message = "This will always print.");
}

Result

[root@localhost]# kosi install -p package.tgz -f values.yaml
2025-03-10 11:30:56 Info:      KOSI version: 2.12.0.10
2025-03-10 11:30:57 Info:      Your ifcondition-variable: user
2025-03-10 11:30:57 Info:      Your usecase-values: user
2025-03-10 11:30:57 Info:      Your user-variable: Hello User, you use the set-plugin
2025-03-10 11:30:57 Info:      This will always print.
2025-03-10 11:30:57 Info:      Installation successful.

or with usecase => kubeops

[root@localhost]# kosi install -p package.tgz -f values.yaml
2025-03-10 11:22:04 Info:      KOSI version: 2.12.0.10
2025-03-10 11:22:05 Info:      Your ifcondition-variable: kubeops
2025-03-10 11:22:05 Info:      Your usecase-values: kubeops
2025-03-10 11:22:05 Info:      Your kubeops-variable:Hello KubeOps
2025-03-10 11:22:05 Info:      This will always print.
2025-03-10 11:22:05 Info:      Installation successful.

4.28 - sh-1.7.0

KOSI Plugin sh Version 1.7.0

Summary

The sh plugin is used to execute shell commands. It allows users to define commands that will be executed in a shell environment during the execution of a kosi package. This plugin is useful for automating system administration tasks, configuring environments, or executing necessary shell operations within a controlled setup.

It supports executing single commands as well as multiple commands separated by a semicolon (;). Additionally, the plugin provides an option to execute commands with elevated privileges (sudo).

Keys

Key Description
command Mandatory Contains a string representing a shell command or a sequence of commands to be executed. Multiple commands can be specified, separated by a semicolon (;).
sudo Optional Set to true to execute the plugin with sudo privileges.
sudoPassword Mandatory if you use sudo Set sudo password. Only required, if the key sudo is set to true.

Examples

Example 1 - Execute a single command

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-shell-package";
description = "kosi-example-shell-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

install
{
    sh(command = "echo hello world");
}

Example 2 - Execute multiple commands

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-shell-package";
description = "kosi-example-shell-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

install
{
    sh(command = "echo foo; echo bar");
}

Example 3 - Execute command with sudo

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-shell-package";
description = "kosi-example-shell-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

install 
{
    sh(
        command = "reboot now";
        sudo = "true";
        sudoPassword = "topsecret";
    );
}

Example 4 - Using sh with the set and if plugins

This example shows the interaction of several plug-ins. In this example, we use the sh plugin together with the set and if plugins to check a condition (which is set before) before executing a shell command:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-shell-if";
description = "Example using sh with set and if";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

install
{
    set
    (
        variable = "myVar";
        value = "Hello";
    );

    if (condition = "$vars.myVar$ = 'Hello'") then
    {
        sh(command = "echo Variable is 'Hello'");
    }
    else
    {
        sh(command = "echo Variable is not 'Hello'");
    }
}

Expected Output

If myVar is Hello:

2025-02-26 15:18:28 Info:      Variable is 'Hello'

If myVar is not Hello:

2025-02-26 15:18:28 Info:      Variable is not 'Hello'

4.29 - sudo-1.7.0

KOSI Plugin sudo Version 1.7.0

Summary

The sudo plugin allows executing commands with elevated (sudo) rights within a KOSI package. This is necessary for operations that require administrative privileges, such as modifying system files or managing users.

The sudo plugin wraps other plugin calls that need elevated permissions. When using sudo, commands inside its block are executed with superuser privileges.

The sudo plugin requires a sudo password unless NOPASSWD is configured for the executing user. The NOPASSWD option can be set in the /etc/sudoers file to allow password-less sudo execution for specific users or commands.

Keys

Key Description
password Mandatory if NOPASSWD is not set Set sudo password.

Examples

Example 1

The following example demonstrates how to use the sudo plugin to create a new user with administrative privileges:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install 
{ 
    cmd(command = "echo --- Using the sudo plugin. ---");

    sudo(password = "myPassword")
    {
        bash(command = "echo The password is correct, the new user is now created!");
        cmd(command = "useradd newuser");
    }

    cmd(command = "echo --- End. ---");
}

Where to Set NOPASSWD

The NOPASSWD option can be set in the /etc/sudoers file or in a separate file under /etc/sudoers.d/. To allow a user to run sudo commands without entering a password, add the following line:

username ALL=(ALL) NOPASSWD: ALL

Replace username with the actual user’s name.

Supported Plugins

The sudo plugin can be used with the following plugins that often require elevated privileges:

4.30 - template-1.7.0

KOSI Plugin Template Version 1.7.0

Summary

The KOSI Template Plugin allows users to process and generate configuration files based on predefined templates. By specifying a template file (tmpl) and a target file (target), the plugin dynamically replaces placeholders with actual values retrieved from various sources, such as the KOSI package itself or user-defined values.

This plugin is particularly useful when you need to create configuration files dynamically by integrating predefined values into a structured template. It enables flexibility and automation in generating configuration files for different environments.

How It Works

The template file (tmpl) consists of placeholders enclosed in double curly braces ({{ }}). These placeholders reference values from configuration files such as the KOSI package itself or user-defined .yaml files. When the plugin processes the template, it replaces these placeholders with the actual values and saves the result in the specified target file.

The plugin utilizes the Scriban templating engine to replace placeholders. Try Scriban Online.

You can use dot notation to navigate through the YAML structure:

  • The root keyword for the KOSI package itself is package.
  • The root keyword for user-defined YAML files is values.

Keys

Key Mandatory Description
tmpl Yes Specifies the template file (YAML format) that contains placeholders.
target Yes Defines the output file where the processed template will be saved. This can be a relative or absolute path.

Examples

Example 1 - Basic Usage

This example demonstrates how to use the template plugin to generate a configuration file from a template.

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-package";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

install
{
    template
    (
        tmpl = "template.yaml";
        target = "result.yaml";
    );
}

Example 2 - Using the Template Engine

Consider the following template.yaml file:

api: {{package.apiversion}}
package:
  name: {{package.name}}
  version: {{package.version}}
  input_file: {{package.includes.files.input}}
  container_registry: {{package.includes.containers.example.registry}}
values:
  primary_ip: {{values.ipNormal}}
  first_listed_ip: {{values.IPList[0]}}

Corresponding package.kosi Example:

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    template
    (
        tmpl = "template.yaml";
        target = "/user/output/result.yaml";
    );
}

Corresponding values.yaml Example:

IPList:
  - "127.0.0.1"
  - "192.128.16.1"
  - "192.128.18.14"
ipNormal: "12.10.45.23"

After we have built the KOSI package with kosi build, we install the created package and include the values.yaml by executing kosi install -p package.tgz -f values.yaml.

Expected Output in result.yaml

After executing the KOSI install command, result.yaml would contain:

api: kubernative/kubeops/sina/user/v4
package:
  name: kosi-example-packagev3
  version: 0.1.0
  input_file: template.yaml
  container_registry: docker.io
values:
  primary_ip: 12.10.45.23
  first_listed_ip: 127.0.0.1

Example 3 - YAML Path Navigation

As already explained in the summary, you can use dot notation to navigate through the YAML structure.

To access values from the KOSI package itself (package.kosi):

name: {{package.name}}

To reference a deeply nested value, use dot notation:

input_file: {{package.includes.files.input}}

The input-element in the KOSI package is accessible with package.includes.files.input, because the input element is nested inside the files tree, which itself is part of the includes hierarchy.

4.31 - writeplugin

how to write a plugin

A plugin is a task a task that can be executed in a kosi package. The Plugins are selsected in the tasks tree in the batch.yaml. The plugin gets passed a parameter tree, which can be read in the plugin.

classes in the plugin

There are two important classes: the version class and the info class. An overview of the versions of the plugins is in the info class. The class must inherit from the iplugininfo class. a forwarding to the individual version classes is important: Also there is a function which returns a list with all versions of the plugin.

The Logic of the plugin lies in run method in the version class.
The run method gets a sandbox and the parameter-tree passed.

public void Run(ISandbox sandbox, ITree parameter) {

the lint function of the version class checks the tree for the plugin if the parameter-tree is correct. A function for returning the name and version of The plugin is also obligatory.

Sandbox is a class which contains data for the plugin. An example would be the storage space of the package.yaml, which defines the kosi package. You can also set variables in the sandbox.

ITree config = sandbox.GetVariable("config");

You can also get an instance of the logger from the sandbox. with the getlogginmanager() method you can access the logger.

sandbox.GetLoggingManager().Debug1("plugin-template", $"run template plugin");

The method after get logging menager determines the logging level. There are four logging levels:

  • info
  • debug1
  • debug2
  • debug3

The first parameter determines the channel. It is recommended that you name it after your plugin. The message for the logging is the second parameter.

The sandbox can create a instance of a fio file, which can be written on hard disk. This fio file has a Tree, which can be modified with the fio-tool.

IFile templateYaml = sandbox.NewFio();

the element of the tree can be accessed with the fio-tool. Fio is included in the toolchain.dll. These Tree have elements and/or subtrees. A element in Fio has only one key and an associated value.

string kosiFileName = (string)templateyaml.GetElement($"apiversion").Value;

when you want to access a subtree, you can use a point structure.

string kosiFileName = (string)templateyaml.GetElement($"import.files.{fileElement}").Value;

In contrast, a subtree can have multiple elements with associated values. “Value” is the keyword for using the value of the element-key.

ITree mergeduservalues = config.GetSubTree("mergedFioFiles");

You have to possibility to use other plugins, the sandbox has also the runPLugin() function. In this example we use the print plugin with a tree as a parameter for the print plugin. The tree have to be the same as the tree you use within the run tree in the batch.yaml for the plugin.

sandbox.RunPlugin("print", parameter);

the parameter-tree can be created with fio. the name of the plguin does not have to be within the parameter-tree. Fio has the option to set parameters, so for example the creation of the parameter-tree for the print-plugin can be like that:

Itree parameter = new Tree();
parameter.setElement("message","now the print plugin can be run!");
sandbox.RunPlugin("print", parameter);

5 - Reference

In the reference you will find the full Kosi documentation as well as the file formats and the KOSI Language Reference.

5.1 - Fileformats

Fileformats in KOSI

This Guide shows you all the different kind of fileformats KOSI uses and how to use them.

KOSI config.yaml

Default-installation-location for: /var/kubeops/kosi/config.yaml
Location for usage: $KUBEOPSROOT/kosi/config.yaml

The config.yaml file contains all necessary files for networking and logging. For example, config.yaml contains the hub from which the packages are downloaded. If you have custom values for your config you have to put these in the $KUBEOPSROOT/kosi/config.yaml.
If KOSI can not find the config.yaml, it will use default like the example.

Example:

apiversion: kubernative/sina/config/v2                # Shows the supported API-Version
spec:                                            
  hub: https://hub.kubernative.net/v4/dispatcher/     # Adress to the KOSI online hub
  plugins: /kubeops/kosi/kosi-plugins/                # Location of the KOSI-Plugins
  workspace: /tmp/kosi/process/                       # Workspace Path 
  logging: info                                       # Loglevel options: info (default), warning, error, debug1, debug2, debug3
  housekeeping: true                                  # Housekeeping options: true (all temporary created files and images (-r flag) will be deleted), false (all temporary created files and images won't be deleted)

If you want to use your own Hub you can create a user-specific config.yaml file. The original file can be changed too, but it is not recommended.

KOSI values.yaml

In KOSI there are two ways to template values and one of them is using a values.yaml the other is using the template.yaml. In a normal values.yaml you can do value templating like in helm.

Example:

In the example is a package.kosi with an if-plugin call, where the condition is templated.

values.yaml

firstparam: 1
secondparam: 2

More information about the if-plugin can be find here if-plugin Reference.

package.kosi

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install 
{
    cmd(command = "echo using if plugin");

    if (condition = "{{values.firstparam}}<2") then
    {
        cmd(command = "echo using templated values.")
        cmd(command = "echo {{values.firstparam}} is smaller than 2");
    }
    else
    {
        cmd(command = "echo {{values.firstparam}} is bigger than 2");
    }
}
More information about the KOSI language can be found here KOSI Language Reference.

KOSI template.yaml

In KOSI there are two ways to template values and one of them is using a template .yaml the other is using the values.yaml. This type of templating works with the template-plugin.

For more information about the template syntax check the Scriban documentation (https://github.com/scriban/scriban/blob/master/doc/language.md) and try it out in the online demo (https://scribanonline.azurewebsites.net).

Example:

package:
  file: {{package.includes.files.input}}

KOSI package.kosi

The package.kosi defines properties of a KOSI package (.tgz). A default package.kosi is created after a kosi create-command.

Metadata

There are a few metadata and they are mandatory.

Parameter Description
languageversion KOSI language version specification.
apiversion KOSI package version sepcification.
name Set the name of the package, which will displayed on the hub.
description Set the description of the package, which will displayed on the hub.
version Set the description of the package, which will displayed on the hub.
docs A Tgz with the documentation of the package, which contains Markdown files.
logo A PNG for a logo of the package.

IMPORTANT: Only use a fully lowercase as name for your package.
Note: Do not change name for logo.png and docs.tgz.
Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

The containers element is used for docker images. The methods which are used in the package.
The files element describes the files which are inluded in the KOSI package.
The installation tree describes the tasks (KOSI plugins), which are executed with the kosi install command.
The update tree describes the tasks (KOSI plugins), which are executed with the kosi update command.
The delete tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

Example

languageversion = "0.1.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = "touch ~/kosiExample1");
}

update
{
    cmd(command = "touch ~/kosiExample2");
}

delete
{
    cmd(command = "rm ~/kosiExample1");
    cmd(command = "rm ~/kosiExample2");
}
More information about the KOSI language can be find here KOSI Language Reference.

KOSI package.yaml

The package.yaml defines properties of a KOSI package (.tgz). A package.yaml is created after a kosi build-command with a valid package.kosi file.

Metadata

There are a few metadata and they are mandatory.

Parameter Description
languageversion KOSI language version specification.
apiversion KOSI package version sepcification.
name Set the name of the package, which will displayed on the hub.
description Set the description of the package, which will displayed on the hub.
version Set the version of the package, which will displayed on the hub.
docs A Tgz with the documentation of the package, which contains Markdown files.
logo A PNG for a logo of the package.

IMPORTANT: Only use a fully lowercase as name for your package.
Note: Do not change name for logo.png and docs.tgz.
Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

The includes.containers element is used for docker images. The methods which are used in the package.
The includes.files element describes the files which are inluded in the KOSI package.
The installation tree describes the tasks (KOSI plugins), which are executed with the kosi install.tasks command.
The update.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi update command.
The delete.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

# languageversion: "0.1.0"
apiversion: "kubernative/kubeops/sina/user/v4"
name: "kosi-example-packagev3"
description: "kosi-example-package"
version: "0.1.0"
docs: "docs.tgz"
logo: "logo.png"
includes:
  files:
    input: "template.yaml"
  containers:
    example:
      registry: "docker.io"
      image: "nginx"
      tag: "latest"
installation:
  tasks:
    - cmd:
        command: "touch ~/kosiExample1"
update:
  tasks:
    - cmd:
        command: "touch ~/kosiExample2"
delete:
  tasks:
    - cmd:
        command: "rm ~/kosiExample1"
    - cmd:
        command: "rm ~/kosiExample2"

KOSI package.tgz

The KOSI package contains all metadata and installation, update and delete tasks. A package.tgz is created after a kosi build-command with a valid package.kosi file. The package.tgz is the artefact that will pushed on the KubeOpsHub. There are some default files, that are always included in the KOSI package, beside your included files.
A package.tgz is created after a kosi build-command with a valid package.kosi or package.yaml file.

Note: package.kosi will be preferred in the building process

File Description
docs.tgz A Tgz with the documentation of the package, which contains Markdown files.
logo.png A PNG for a logo of the package.
package.yaml KOSI language translated package.yaml for task. execution.
template.yaml KOSI template.yaml for templating values.

5.2 - KOSI Language Reference

This Guide explains the basic Structure of the package.kosi File using the if and cmd Plugins

package.kosi File

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v4";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files = 
{
    input = "template.yaml";
}

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

install 
{
    cmd(command = "echo using if plugin");

    if (condition = "{{values.firstparam}}<2") then
    {
        cmd(command = "echo using templated values.")
        cmd(command = "echo {{values.firstparam}} is smaller than 2");
    }
    else
    {
        cmd(command = "echo {{values.firstparam}} is bigger than 2");
    }
}
More information about each KOSI Plugin and their use can be found here Plugins.

Metadata

There are a few metadata and they are mandatory.

Parameter Description
languageversion KOSI language version specification.
apiversion KOSI package version sepcification.
name Set the name of the package, which will displayed on the hub.
description Set the description of the package, which will displayed on the hub.
version Set the description of the package, which will displayed on the hub.
docs A Tgz with the documentation of the package, which contains Markdown files.
logo A PNG for a logo of the package.
files = 
{
    input = "template.yaml";
}

The includes.files element describes the files which are inluded in the KOSI package.

containers = 
{
    example = ["docker.io", "nginx", "latest"];
}

The includes.containers element is used for docker images. The methods which are used in the package.

install 
{
    cmd(command = "echo using if plugin");

    if (condition = "{{values.firstparam}}<2") then
    {
        cmd(command = "echo using templated values.")
        cmd(command = "echo {{values.firstparam}} is smaller than 2");
    }
    else
    {
        cmd(command = "echo {{values.firstparam}} is bigger than 2");
    }
}

In this section the logic of the used Pulgins is described.

The cmd Plugin is for executing commands in the commandline and the if Plugin is for creating conditions, under which other plugins are executed.

The main used Trees are Install for installing a new package, Update for updating Packages and Uninstall for uninstalling packages.

5.3 - Full Documentation KOSI-2.12.x

KubeOps KOSI

How to use KOSI

This guide explains how to use KOSI with detailed instructions and examples.

General commands

Overview of all KOSI commands

kosi:
  Kosi is a SoftwareINstAller for kubernetes cluster

Usage:
  Kosi [options] [command]

Options:
  --version         Show version information
  -?, -h, --help    Show help and usage information

Commands:
  login                    logs you in
  search                   Shows you all the available packages on the softwarehub
  build                    Creates your final kosi.package
  push                     Push package.tgz to KubeOps Hub.
  pull <package>           Downloads an existing package from the hub without installing.
  install <packagename>    install a .tgz file and if it is required, download it
  update <packagename>     update a .tgz file and if it is required, download it
  delete <packagename>     run delete section of a .tgz file and if it is required, download it
  list                     List packages from storage
  lint                     lint your files for your .tgz package
  create                   Creates a package.kosi and a template.yaml for you to manipulate
  version                  Basic infos about KOSI
  logout                   Logout
  remove <package>         Gives you the possibility to remove packages from the hub, if you have write permissions.
  encrypt                  Gives you the possibility to encrypt your values with a password.
  check <hash>             check your local package hash

Command ‘kosi –help’

The command kosi --help gives you an overview of all available commands:

kosi --help

Alternatively, you can also enter kosi or kosi -? in the command line.

Command ‘kosi version’

The kosi version command shows you the current version of KOSI.

kosi version

The output should be:

2025-03-18 08:07:41 Info:      KOSI version: 2.12.0.11
2025-03-18 08:07:41 Info:      Latest KOSI-package-apiversion is: kubernative/kubeops/sina/user/v4
2025-03-18 08:07:41 Info:      Latest KOSI-lanugage-version is: 1.0.0
2025-03-18 08:07:41 Info:      This work is licensed under Creative Commons Attribution - NoDerivatives 4.0 International License(see https://creativecommons.org/licenses/by-nd/4.0/legalcode for more details).
2025-03-18 08:07:41 Info:      © KubeOps GmbH, Hinter Stöck 17, 72406 Bisingen - Germany, 2025

Command ‘kosi create’

Note: The command works in the current directory.

The command kosi create creates four files (package.kosi, template.yaml, logo.png and docs.tgz) in the current directory. These files can be edited by the user.

The template.yaml is required if the template engine Scriban is to be used.

The logo.png is a package-thumbnail with the size of 50x50px

The docs.tgz is a zipped directory with the documentation of the package. The documentation of the package is written down in markdown. The file for the documentation is called readme.md.

Note: Please name your markdown files inside docs.tgz without a version-tag (docs/documentation-1.0.0.md).

kosi create

Created files:

  • package.kosi
  • template.yaml
  • logo.png - For showing logo on the KubeOpsHub.
  • docs.tgz - For showing documentation on the KubeOpsHub.

Command ‘kosi build’

Note: The command works in the current working directory.

Note: If you have no package.kosi file in your current working directory, KOSI will pick a package.yaml file.

Note: Name your package in the package.kosi in full lower case.

Note: Don´t change the name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without a version-tag (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

The kosi build command creates the necessary yaml files for building a package:

kosi build

All files specified in the package.kosi are combined together with the package.yaml to form a KOSI package.

The package.yaml is only generated once, if it is not available. If the package.yaml already exists the package.yaml will not be generated.

Command ‘kosi lint’

The kosi lint command is used to check whether the contents of the package.yaml or package.kosi files are valid:

kosi lint

Command ‘kosi login’

The kosi login command logs on to the KubeOps services. The account name is required for this command.

Note: To push packages into the hub, you need to create an account here first. Note: We recommend lowercase usernames for your kubeops-accounts.

After the flag -u type your username. Afterwards you will be asked to enter your password.

kosi login -u <username>

The parameter -p is used to enter the password in the command directly, but it is important to know that the password will be shown in plain text. This parameter can help with the automation of KOSI commands.

kosi login -u <username> -p <password>

-u flag

The -u parameter is used to specify the user name.

kosi login -u

This parameter is required.

-p flag

The -p parameter is used to specify the password.

kosi login -p

This parameter is not required. We recommend to use this parameter only if it is absolutely necessary.

Command ‘kosi logout’

The kosi logout command logs out from the KubeOps services.

Note: To logout from the KubeOps services, you have to be logged in.

kosi logout

Command ‘kosi push’

The kosi push command uploads KOSI packages to the KubeOps Hub:

kosi push --hub <hubname>

Note: In order to upload KOSI packages, you first have to log in using the kosi login command.

Note: The package name is case-sensitive and should be lowercase.

–hub flag

The --hub parameter is used to upload KOSI packages to a specific hub, e.g. in this example we upload our KOSI package to the myhub hub.

kosi push --hub myhub

Command ‘kosi pull’

The kosi pull command downloads a specific KOSI package from the hub without installing it directly.

kosi pull --hub <hubname> <packagename> -o <desired name>

Note: kosi pull downloads the package to the current directory.

Note: The downloaded packages can be transferred to machines without internet access via USB, for example.

Note: The package name is case-sensitive and should be lowercase.

Example:

kosi pull --hub myhub donald/kosi-print-test:0.0.1 -o printpackage

Note: The -o option specifies a name that the package will have after download. The file automatically gets the .tgz extension. The -o option is not optional.

–hub flag

The --hub parameter is used to download KOSI packages to a specific hub, e.g. in this example we are pulling our KOSI package from the myhub hub.

kosi pull --hub myhub kubeops/harbor:1.1.0  

-r flag

The parameter r can be used to pull the docker images which are included in the package to a given local docker registry.

kosi pull --hub <hubname> <packagename> -o <desired name> -r <local.docker.registry>

Note: kosi pull downloads the package and pulls the required docker images to the given local docker registry.

Example:

kosi pull --hub myhub kubeops/harbor:1.1.0   -o harborpackage -r 127.0.0.1:5000

Note: After the kosi pull --hub myhub kubeops/harbor:1.1.0 -o printpackage -r 127.0.0.1:5000 command you can use kosi install -p printpackage.tgz to use the docker image from your local docker registry.

Note: You can now install your packages including docker images without internet connection from your local machine.

-t flag

For the szenario that the registry of the cluster is exposed to the admin via a network internal domain name, but this name can’t be resolved by the nodes, the flag -t can be used, to use the cluster internal hostname of the registry.

kosi pull --hub <hubname> <packagename> -o <desired name> -r <local.docker.registry> -t <cluster.internal.registry>

Note: local.docker.registry is the same registry as cluster.internal.registry but with a different hostname.

Example:

kosi pull --hub myhub kubeops/harbor:1.1.0 -o harborpackage -r myregistry:5000 -t clusterregistry:5000

IMPORTANT: -t flag can only be used in combination with the -r flag.

KOSI_retag_registry

The kosi search command displays all available packages of your own private hub. Only the logged in user can see the packages on his private hub. The User column contains the name of the creator of the package.
The Name column contains the name of the package.
The Version column contains the version of the package.
The Description column contains the description of the package.
The Install column contains a string consisting of the name of the creator, name and version of the package. This string can be copied and used for the kosi install command.

kosi search --hub <hubname>

Example: User donald is logged in and wants to get the packets from his private hub:

kosi search --hub donald
| User   | Name         | Version | Description                      |Install                    |
|--------|--------------|---------|----------------------------------|---------------------------|                  
| donald | private-kosi | 0.0.1   | private installation             | donald/private-kosi:0.0.1 |                                       
| donald | private-test | 0.0.1   | private package                  | donald/private-test:0.0.1 |
| donald | livedemo     | 2.7.2   | welcome to kosi                  | donald/livedemo:2.7.1     | 

–ps flag

The --ps parameter can be used to filter for keywords that refer to all five columns. It is also possible to filter by individual word components:

kosi search --hub <hubname> --ps <name>

Example:
In this case, all packets containing the word private are displayed:

kosi search --hub donald --ps private
| User   | Name         | Version | Description                      |Install                    |
|--------|--------------|---------|----------------------------------|---------------------------|                  
| donald | private-kosi | 0.0.1   | private installation             | donald/private-kosi:0.0.1 |                                       
| donald | private-test | 0.0.1   | private package                  | donald/private-test:0.0.1 |                                        

–hub flag

In addition, there is an option to search for packages on a specific hub using the --hub parameter. You need no login to search in the myhub hub.

kosi search --hub myhub
| User   | Name         | Version | Description                      |Install                  |
|--------|--------------|---------|----------------------------------|-------------------------|
| kosi   | lima         | 0.6.2   | installs LIMA                    | kosi/lima:0.6.2         |
| kosi   | installation | 0.0.1   | kosi create example package.yaml | kosi/installation:0.0.1 |  
| donald | elk-kosi     | 0.0.1   | ELK installation                 | donald/elk-kosi:0.0.1   |
| donald | prod-test    | 0.0.1   | test for prod                    | donald/prod-test:0.0.1  | 
| lima   | lima         | 0.6.0   | installs LIMA                    | lima/lima:0.6.0         |
                                     

The parameters --hub and --ps can be combined for a targeted search in the kosi hub:

kosi search --hub <hubname> --ps <package_name>

Example:
The user kosi wants to display all packages in the kosi hub with the term “lima”.

kosi search --hub kosi  --ps lima
| User | Name         | Version | Description                      |Install                  |
|------|--------------|---------|----------------------------------|-------------------------|
| kosi | lima         | 0.6.2   | installs LIMA                    | kosi/lima:0.6.2         |
| kosi | lima         | 0.7.1   | installs LIMA                    | kosi/lima:0.7.1         |
                                     

Command ‘kosi encrypt’

The kosi encrypt command is used to encrypt YAML files with AES-256-CBC:

-f flag

The parameter -f must be used to use yaml files from the user.

This parameter is required.

kosi encrypt -f <user.yaml>

Note: The -f parameter can be specified any number of times to use any number of files.

kosi encrypt -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: Once your file is encrypted you can not decrypt it with KOSI for get an decrypted file. KOSI do this on runtime, if you use this file.

Command ‘kosi install’

The kosi install command installs a KOSI package:

kosi install --hub <hubname> <package>

The string of the column Install in the output of kosi search is required:

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the myhub Hub:

kosi install --hub myhub kosi/livedemo:2.7.1 

–hub flag

The --hub parameter must be used to install packages from the software hub. Only the logged in user can install the packages from the software hub.

kosi install --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the myhub Software Hub:

kosi install --hub myhub kosi/livedemo:2.7.1

-p flag

The “p” parameter must be used to install local packages. For “p” parameter you need no --hub:

kosi install -p package.kosi

-f flag

The parameter f must be used to use .yaml files from the user.

kosi install <package> -f <user.yaml>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the myhub software hub and user specific files are to be used for the installation:

kosi install --hub myhub kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameter.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi install <package> --cf <encryptedUser.yaml>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the myhub software hub and user specific encrypted files are to be used for the installation:

kosi install --hub myhub kosi/livedemo:2.7.1 --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml --cf encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files.
Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi install --hub myhub kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a Kubernetes namespace in which the installation is to be performed.

kosi install --hub <hubname> <package> --namespace <namespace>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the myhub software hub and a custom kubernetes namespace is used:

kosi install --hub myhub kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the namespace default will be used.

–dname flag

The parameter dname can be used to save the package under a specific name.

kosi install --hub <hubname> <package> --dname <deploymentname>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the myhub software hub and a deployment name is set:

kosi install --hub myhub kosi/livedemo:2.7.1 --dname MyDeployment

Note: If no --dname parameter is specified, a random deployment name will be generated. Note: Deploymentnames are unique, the installation will stop if the deploymentname already exists.
Note: The deployment name is stored in the file /<user>/var/kubeops/kosi/deployment.yaml.

Command ‘kosi list’

The kosi list command lists all installed KOSI packages:

kosi list
 KOSI version: 2.10.0_preAlpha0
| Deployment       | Package                           | PublicHub | Hub    |
|------------------|-----------------------------------|-----------|--------|
| kosiinstallslima | kosi/lima:0.6.2                   |           | private|
| kosicreatetest   | kosi/kosi-create:0.0.1            |           | public |
| plugininstall    | local/kubeops-basic-plugins:0.4.0 |           | local  |

Command ‘kosi update’

The kosi update command updates an already installed KOSI package:

For update, the installation and the update package have to be the same name. Update will be defined in the package.yaml.

kosi update --hub <hubname> --dname <deploymentname> <package>

The string of the column Install in the output of kosi search is required:

Example: The installation of the package lima from the user kosi with version 0.6.2 and deployment name kosiInstallsLima is updated by a package from the myhub Software Hub from kosi.:

kosi update --hub myhub --dname kosiInstallsLima kosi/kosi/lima:0.6.2 

–hub flag

The --hub parameter must be used to update packages from the software hub. Only the logged in user can update the packages from the software hub.

kosi update --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be updated from the myhub Software Hub:

kosi update --hub myhub kosi/livedemo:2.7.1
```create:0.0.1

-p flag

The “p” parameter must be used to update the installation from a local package. For “p” parameter you need no --hub parameter:

kosi update -p package.tgz

-f flag

The parameter f must be used to use yaml files from the user.

kosi update --hub <hubname> <package> -f <user.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the myhub software hub and user specific files are to be used for the update progress:

kosi update --hub myhu kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameters.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi update --hub <hubname> <package> --cf <encryptedUser.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the myhub software hub and user specific encrypted files are to be used for the update progress:

kosi update --hub myhub kosi/livedemo:2.7.1 --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml --cf encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files. Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi update --hub myhub kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a kubernetes namespace in which the update is to be performed.

kosi update --hub <hubname> <package> --namespace <namespace>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the myhub software hub and a custom kubernetes namespace is used:

kosi update --hub myhub kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the default namespace will be used.

–dname flag

The parameter dname can be used to update the deployment by name.

kosi update --hub <hubname> <package> --dname <deploymentname>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the myhub software hub and a deployment name is set:

kosi update --hub myhub kosi/livedemo:2.7.1 --dname MyDeployment

Command ‘kosi delete’

The kosi delete command deletes an already installed KOSI package:

For delete, the installation and the update package have to be the same name. Delete will be defined in the package.yaml.

kosi delete --hub <hubname> --dname <deploymentname> <package>

The string of the column Install in the output of kosi search is required:

Example: The installation of the package lima from the user kosi with version 0.6.2 and deployment name kosiInstallsLima is deleted by a package from the myhub Software Hub from kosi.:

kosi delete --hub myhub --dname kosiInstallsLima kosi/kosi/lima:0.6.2 

–hub flag

The --hub parameter must be used to use the delete section of packages from the software hub. Only the logged in user can use the delete section of packages from the software hub.

kosi delete --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be updated from the myhub Software Hub:

kosi delete --hub myhub kosi/livedemo:2.7.1
```create:0.0.1
```-create:0.0.1

-p flag

The “p” parameter must be used to delete the installation from a local package. For “p” parameter you need no --hub parameter:

kosi delete -p package.tgz

-f flag

The parameter f must be used to use yaml files from the user.

kosi delete --hub <hubname> <package> -f <user.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the myhub software hub and user specific files are to be used for the delete progress:

kosi delete --hub myhub kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameter.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi delete --hub <hubname> <package> -f <encryptedUser.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the myhub software hub and user specific encrypted files are to be used for the delete progress:

kosi delete --hub myhub kosi/livedemo:2.7.1 -f encryptedUserfile1.yaml -f encryptedUserfile2.yaml -f encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files. Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi delete --hub myhub kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a kubernetes namespace in which to perform the deletion.

kosi delete --hub <hubname> <package> --namespace <namespace>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the myhub software hub and a custom kubernetes namespace is used:

kosi delete --hub myhub kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the default namespace will be used.

–dname flag

The parameter dname can be used to delete the deployment by name.

kosi delete --hub <hubname> <package> --dname <deploymentname>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the myhub software hub and a deployment name is set:

kosi delete --hub myhub kosi/livedemo:2.7.1 --dname MyDeployment

Command ‘kosi remove’

The kosi remove command removes a KOSI package from the hub:

Note: Only logged users can delete there OWN packages on their OWN hubs.

kosi remove --hub <hubname> <package>

Note: the package you want to remove can be found in the output of the kosi search command, more precisely in the install column

Example: The package livedemo of the user kosi with version 2.7.1 will be removed from the myhub hub:

kosi remove --hub myhub kosi/livedemo:2.7.1 

Note: If your package already deleted, the command will try do delete your package successfully. Deleting non-existing packages does not cause any errors.

Command ‘kosi check’

The kosi check command is used to compare a local kosi package with a sha256 Checksum.

kosi check -p <localpackagename> <sha256 hash>

Example:

kosi check -p examplepackage c83f3db9639e175f82e7d07d342533866873e2d9ca2f0fd5ee607ea395417edb

File Formats

package.kosi

This file defines properties of the KOSI package. This file is created after the kosi create command. The package.kosi 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. The includes.containers element is 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. There is also a description, which will be shown in the kosi search command. The includes.files element describes the files which are inluded in the KOSI package. The installation.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi install command. The update.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi update command.The delete.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

IMPORTANT: To get your package please enter a fully lowercase name for your package.

Note: Do not change name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v3";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
  input="template.yaml";
}

containers =
{
    example=["docker.io", "nginx", "latest"];
}

install
{
    cmd(command="touch ~/kosiExample1");
}

update
{
    cmd(command="touch ~/kosiExample2");
}

delete
{
    cmd(command="rm ~/kosiExample1");
    cmd(command="rm ~/kosiExample2");
}

package.yaml

This file defines properties of the KOSI package. This file is created after the kosi build command. 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. The includes.containers element is 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. There is also a description, which will be shown in the kosi search command. The includes.files element describes the files which are inluded in the KOSI package. The installation.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi install command. The update.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi update command.The delete.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

IMPORTANT: The apiversion has been changed from …/user/v2 to …/user/v3. The Image Key has been split into to seperate Keys registry and image.

IMPORTANT: To get your package please enter a fully lowercase name for your package.

Note: Do not change name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

# languageversion: "0.1.0"
apiversion: "kubernative/kubeops/sina/user/v3"
name: "kosi-example-packagev3"
description: "kosi-example-package"
version: "0.1.0"
docs: "docs.tgz"
logo: "logo.png"
includes:
  files:
    input: "template.yaml"
  containers:
    example:
      registry: "docker.io"
      image: "nginx"
      tag: "latest"
installation:
  tasks:
    - cmd:
        command: "touch ~/kosiExample1"
update:
  tasks:
    - cmd:
        command: "touch ~/kosiExample2"
delete:
  tasks:
    - cmd:
        command: "rm ~/kosiExample1"
    - cmd:
        command: "rm ~/kosiExample2"

default.yaml

The default.yaml in a package.tgz is used for setting default variables. In case you use the -f parameter in install, update or delete, the file which you address is merged with the default.yaml. If you have the same keys but different values in both files, your adressed file will overwrite the values set by the default.yaml.

config.yaml

Location for: /var/kubeops/kosi/config.yaml

The config.yaml file contains all necessary files for networking and logging. For example, config.yaml contains the hub from which the packages are downloaded.

apiversion: kubernative/kosi/config/v2           # Shows the supported API-Version
spec:                                            
  hub: https://hub.kubernative.net/dispatcher/      # Adress to the KOSI online hub
  plugins: /kubeops/kosi/kosi-plugins/                      # Location of the KOSI-Plugins
  registry: registry1.kubernative.net/             # Registry, where Docker-images will be pulled to (kosi pull)
  workspace: /tmp/kosi/process/                    # Workspace Path 
  logging: info                                    # Loglevel options: info (default), warning, error, debug1, debug2, debug3
  housekeeping: true                               # Housekeeping options: true (all temporary created folders will be deleted), false (all temporary created folders won't be deleted)

KOSI uses Workspaces for processing the packages. These workspaces can be deleted if you using CLI-commands and setting the housekeeping to true. Plugins also will operate in this workspace.

Usage

To keep KOSI running there has to be a valid config.yaml file.
After installing KOSI, a valid config.yaml file is created under the location /var/kubeops/kosi/config.yaml. If you want to use your own Hub you can create a user-specific config.yaml file. The original file can be changed too, but it is not recommended.

$KUBEOPSROOT Variable

The $KUBEOPSROOT environment variable stores the location of the KOSI plugins and the config.yaml. To use the variable, the config.yaml and the plugins have to be copied manually.
So for example:

cp -r /var/kubeops/kosi/config.yaml /home/<user>/kubeopsrootdir/kosi/config.yaml
rm -rf /var/kubeops/kosi
cp -r /var/kubeops/plugins /home/<user>/kubeopsrootdir/plugins
rm -rf /var/kubeops/plugins

If you want to use the config file and plugins with a user you have to go through these steps.

How to use templating within the package.kosi

This is an example of how templating in a package.kosi is working with kosi 2.10.x

First we need to create this package.kosi:

# languageversion: "0.1.0"
apiversion = "kubernative/kubeops/sina/user/v3";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
  input="template.yaml";
}

containers =
{
    example=["docker.io", "nginx", "latest"];
}

install
{
    cmd(command='"echo using templatep plugin."');
    template(tmpl='{{package.includes.files.input}}';target='{{values.target}}');
}

update
{
    cmd(command='"touch ~/kosiExample2"');
    template(tmpl='{{package.includes.files.input}}';target='{{values.target}}');
}

delete
{
    cmd(command='"rm ~/kosiExample1"');
    cmd(command='"rm ~/kosiExample2"');
}

Now we create a template.yaml:

package:
  file: {{package.includes.files.input}}
  uservalues: {{values.example}}

Next we create a default.yaml:

example: example
target: target.yaml

Please make sure that you create all these files in the same directory.

Now we are ready to create a kosi package. For this we need the following command:

kosi build

Next we can run the installation section we have defined in the package.yaml with the following command:

kosi install -p package.tgz --dname example

We can check the result in the directory $KUBEOPSROOT/kosi/tmp.

The file of interest is the target.yaml. But most of the time this file is not in tmp Folder . In this case, type the command find / -name target.yaml to find the location of the target.yaml file.

the content of target.yaml is:

package:
  file: template.yaml
  uservalues: example

So what exactly happened?
In the package.yaml you can see that we use {{package.includes.files.input}} for defining the template.yaml as value for the key tmpl. You can use any value of the package.yaml but make sure that the path to the value is correct and starts with package.. This is the indicator for using a variable from the package.yaml.

You can also see that we use {{values.target}} for defining the target.yaml as value for the key target. If you wonder where the target.yaml is coming from you can check the default.yaml. If you want to use a variable from the default.yaml or from a file specified with the parameter -f make sure that the path to the value is correct and starts with values..

For more information about the template syntax check the Scriban documentation (https://github.com/scriban/scriban/blob/master/doc/language.md) and try it out in the online demo (https://scribanonline.azurewebsites.net).

Plugins

With the installation of KOSI a handful of plugins are included. Which plugins are included can be seen under “pre-installed plugins” in the Plugin References

5.4 - Full Documentation KOSI-2.11.x

KubeOps KOSI

How to use KOSI

This guide explains how to use KOSI with detailed instructions and examples.

General commands

Overview of all KOSI commands

kosi:
  Kosi is a SoftwareINstAller for kubernetes cluster

Usage:
  Kosi [options] [command]

Options:
  --version         Show version information
  -?, -h, --help    Show help and usage information

Commands:
  login                    logs you in
  search                   Shows you all the available packages on the softwarehub
  build                    Creates your final kosi.package
  push                     Push package.tgz to KubeOps Hub.
  pull <package>           Downloads an existing package from the hub without installing.
  install <packagename>    install a .tgz file and if it is required, download it
  update <packagename>     update a .tgz file and if it is required, download it
  delete <packagename>     run delete section of a .tgz file and if it is required, download it
  list                     List packages from storage
  lint                     lint your files for your .tgz package
  create                   Creates a package.kosi and a template.yaml for you to manipulate
  version                  Basic infos about KOSI
  logout                   Logout
  remove <package>         Gives you the possibility to remove packages from the hub, if you have write permissions.
  encrypt                  Gives you the possibility to encrypt your values with a password.
  check <hash>             check your local package hash

Command ‘kosi –help’

The command kosi --help gives you an overview of all available commands:

kosi --help

Alternatively, you can also enter kosi or kosi -? in the command line.

Command ‘kosi version’

The kosi version command shows you the current version of KOSI.

kosi version

The output should be:

[ 12/03/2021 10:13:20 Debug1  default ] Check OS Support...
[ 12/03/2021 10:13:20 Debug1  default ] set Loglevel info
Version: 2.11.3.0
This work is licensed under Creative Commons Attribution - NoDerivatives 4.0 International License(see https://creativecommons.org/licenses/by-nd/4.0/legalcode for more details).
©KubeOps GmbH, Hinter Stöck 17, 72406 Bisingen - Germany, 2022

Command ‘kosi create’

Note: The command works in the current directory.

The command kosi create creates four files (package.kosi, template.yaml, logo.png and docs.tgz) in the current directory. These files can be edited by the user.

The template.yaml is required if the template engine Scriban is to be used.

The logo.png is a package-thumbnail with the size of 50x50px

The docs.tgz is a zipped directory with the documentation of the package. The documentation of the package is written down in markdown. The file for the documentation is called readme.md.

Note: Please name your markdown files inside docs.tgz without a version-tag (docs/documentation-1.0.0.md).

kosi create

Created files:

  • package.kosi
  • template.yaml
  • logo.png - For showing logo on the KubeOpsHub.
  • docs.tgz - For showing documentation on the KubeOpsHub.

Command ‘kosi build’

Note: The command works in the current working directory.

Note: If you have no package.kosi file in your current working directory, KOSI will pick a package.yaml file.

Note: Name your package in the package.kosi in full lower case.

Note: Don´t change the name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without a version-tag (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

The kosi build command creates the necessary yaml files for building a package:

kosi build

All files specified in the package.kosi are combined together with the package.yaml to form a KOSI package.

The package.yaml is only generated once, if it is not available. If the package.yaml already exists the package.yaml will not be generated.

Command ‘kosi lint’

The kosi lint command is used to check whether the contents of the package.yaml or package.kosi files are valid:

kosi lint

Command ‘kosi login’

The kosi login command logs on to the KubeOps services. The account name is required for this command.

Note: To push packages into the hub, you need to create an account here first. Note: We recommend lowercase usernames for your kubeops-accounts.

After the flag -u type your username. Afterwards you will be asked to enter your password.

kosi login -u <username>

The parameter -p is used to enter the password in the command directly, but it is important to know that the password will be shown in plain text. This parameter can help with the automation of KOSI commands.

kosi login -u <username> -p <password>

-u flag

The -u parameter is used to specify the user name.

kosi login -u

This parameter is required.

-p flag

The -p parameter is used to specify the password.

kosi login -p

This parameter is not required. We recommend to use this parameter only if it is absolutely necessary.

Command ‘kosi logout’

The kosi logout command logs out from the KubeOps services.

Note: To logout from the KubeOps services, you have to be logged in.

kosi logout

Command ‘kosi push’

The kosi push command uploads KOSI packages to the KubeOps Hub:

kosi push --hub <hubname>

Note: In order to upload KOSI packages, you first have to log in using the kosi login command.

Note: The package name is case-sensitive and should be lowercase.

–hub flag

The --hub parameter is used to upload KOSI packages to a specific hub, e.g. in this example we upload our KOSI package to the public hub.

kosi push --hub public

Command ‘kosi pull’

The kosi pull command downloads a specific KOSI package from the hub without installing it directly.

kosi pull --hub <hubname> <packagename> -o <desired name>

Note: kosi pull downloads the package to the current directory.

Note: The downloaded packages can be transferred to machines without internet access via USB, for example.

Note: The package name is case-sensitive and should be lowercase.

Example:

kosi pull --hub public donald/kosi-print-test:0.0.1 -o printpackage

Note: The -o option specifies a name that the package will have after download. The file automatically gets the .tgz extension. The -o option is not optional.

–hub flag

The --hub parameter is used to download KOSI packages to a specific hub, e.g. in this example we are pulling our KOSI package from the public hub.

kosi pull --hub public kubeops/harbor:1.1.0  

-r flag

The parameter r can be used to pull the docker images which are included in the package to a given local docker registry.

kosi pull --hub <hubname> <packagename> -o <desired name> -r <local.docker.registry>

Note: kosi pull downloads the package and pulls the required docker images to the given local docker registry.

Example:

kosi pull --hub public kubeops/harbor:1.1.0   -o harborpackage -r 127.0.0.1:5000

Note: After the kosi pull kubeops/harbor:1.1.0 -o printpackage -r 127.0.0.1:5000 command you can use kosi install -p printpackage.tgz to use the docker image from your local docker registry.

Note: You can now install your packages including docker images without internet connection from your local machine.

-t flag

For the szenario that the registry of the cluster is exposed to the admin via a network internal domain name, but this name can’t be resolved by the nodes, the flag -t can be used, to use the cluster internal hostname of the registry.

kosi pull --hub <hubname> <packagename> -o <desired name> -r <local.docker.registry> -t <cluster.internal.registry>

Note: local.docker.registry is the same registry as cluster.internal.registry but with a different hostname.

Example:

kosi pull --hub public kubeops/harbor:1.1.0 -o harborpackage -r myregistry:5000 -t clusterregistry:5000

IMPORTANT: -t flag can only be used in combination with the -r flag.

KOSI_retag_registry

The kosi search command displays all available packages of your own private hub. Only the logged in user can see the packages on his private hub. The User column contains the name of the creator of the package.
The Name column contains the name of the package.
The Version column contains the version of the package.
The Description column contains the description of the package.
The Install column contains a string consisting of the name of the creator, name and version of the package. This string can be copied and used for the kosi install command.

kosi search --hub <hubname>

Example: User donald is logged in and wants to get the packets from his private hub:

kosi search --hub donald
| User   | Name         | Version | Description                      |Install                    |
|--------|--------------|---------|----------------------------------|---------------------------|                  
| donald | private-kosi | 0.0.1   | private installation             | donald/private-kosi:0.0.1 |                                       
| donald | private-test | 0.0.1   | private package                  | donald/private-test:0.0.1 |
| donald | livedemo     | 2.7.2   | welcome to kosi                  | donald/livedemo:2.7.1     | 

–ps flag

The --ps parameter can be used to filter for keywords that refer to all five columns. It is also possible to filter by individual word components:

kosi search --hub <hubname> --ps <name>

Example:
In this case, all packets containing the word private are displayed:

kosi search --hub donald --ps private
| User   | Name         | Version | Description                      |Install                    |
|--------|--------------|---------|----------------------------------|---------------------------|                  
| donald | private-kosi | 0.0.1   | private installation             | donald/private-kosi:0.0.1 |                                       
| donald | private-test | 0.0.1   | private package                  | donald/private-test:0.0.1 |                                        

–hub flag

In addition, there is an option to search for packages on a specific hub using the --hub parameter. You need no login to search in the public hub.

kosi search --hub public
| User   | Name         | Version | Description                      |Install                  |
|--------|--------------|---------|----------------------------------|-------------------------|
| kosi   | lima         | 0.6.2   | installs LIMA                    | kosi/lima:0.6.2         |
| kosi   | installation | 0.0.1   | kosi create example package.yaml | kosi/installation:0.0.1 |  
| donald | elk-kosi     | 0.0.1   | ELK installation                 | donald/elk-kosi:0.0.1   |
| donald | prod-test    | 0.0.1   | test for prod                    | donald/prod-test:0.0.1  | 
| lima   | lima         | 0.6.0   | installs LIMA                    | lima/lima:0.6.0         |
                                     

The parameters --hub and --ps can be combined for a targeted search in the kosi hub:

kosi search --hub <hubname> --ps <package_name>

Example:
The user kosi wants to display all packages in the kosi hub with the term “lima”.

kosi search --hub kosi  --ps lima
| User | Name         | Version | Description                      |Install                  |
|------|--------------|---------|----------------------------------|-------------------------|
| kosi | lima         | 0.6.2   | installs LIMA                    | kosi/lima:0.6.2         |
| kosi | lima         | 0.7.1   | installs LIMA                    | kosi/lima:0.7.1         |
                                     

Command ‘kosi encrypt’

The kosi encrypt command is used to encrypt YAML files with AES-256-CBC:

-f flag

The parameter -f must be used to use yaml files from the user.

This parameter is required.

kosi encrypt -f <user.yaml>

Note: The -f parameter can be specified any number of times to use any number of files.

kosi encrypt -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Command ‘kosi install’

The kosi install command installs a KOSI package:

kosi install --hub <hubname> <package>

The string of the column Install in the output of kosi search is required:

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public Hub:

kosi install --hub public kosi/livedemo:2.7.1 

–hub flag

The --hub parameter must be used to install packages from the software hub. Only the logged in user can install the packages from the software hub.

kosi install --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public Software Hub:

kosi install --hub public kosi/livedemo:2.7.1

-p flag

The “p” parameter must be used to install local packages. For “p” parameter you need no --hub:

kosi install -p package.kosi

-f flag

The parameter f must be used to use .yaml files from the user.

kosi install <package> -f <user.yaml>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and user specific files are to be used for the installation:

kosi install --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameter.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi install <package> --cf <encryptedUser.yaml>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and user specific encrypted files are to be used for the installation:

kosi install --hub public kosi/livedemo:2.7.1 --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml --cf encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files.
Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi install --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a Kubernetes namespace in which the installation is to be performed.

kosi install --hub <hubname> <package> --namespace <namespace>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and a custom kubernetes namespace is used:

kosi install --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the namespace default will be used.

–dname flag

The parameter dname can be used to save the package under a specific name.

kosi install --hub <hubname> <package> --dname <deploymentname>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and a deployment name is set:

kosi install --hub public kosi/livedemo:2.7.1 --dname MyDeployment

Note: If no --dname parameter is specified, a random deployment name will be generated. Note: Deploymentnames are unique, the installation will stop if the deploymentname already exists.
Note: The deployment name is stored in the file /<user>/var/kubeops/kosi/deployment.yaml.

Command ‘kosi list’

The kosi list command lists all installed KOSI packages:

kosi list
 KOSI version: 2.10.0_preAlpha0
| Deployment       | Package                           | PublicHub | Hub    |
|------------------|-----------------------------------|-----------|--------|
| kosiinstallslima | kosi/lima:0.6.2                   |           | private|
| kosicreatetest   | kosi/kosi-create:0.0.1            |           | public |
| plugininstall    | local/kubeops-basic-plugins:0.4.0 |           | local  |

Command ‘kosi update’

The kosi update command updates an already installed KOSI package:

For update, the installation and the update package have to be the same name. Update will be defined in the package.yaml.

kosi update --hub <hubname> --dname <deploymentname> <package>

The string of the column Install in the output of kosi search is required:

Example: The installation of the package lima from the user kosi with version 0.6.2 and deployment name kosiInstallsLima is updated by a package from the private Software Hub from kosi.:

kosi update --hub public --dname kosiInstallsLima kosi/kosi/lima:0.6.2 

–hub flag

The --hub parameter must be used to update packages from the software hub. Only the logged in user can update the packages from the software hub.

kosi update --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be updated from the public Software Hub:

kosi update --hub public kosi/livedemo:2.7.1
```create:0.0.1

-p flag

The “p” parameter must be used to update the installation from a local package. For “p” parameter you need no --hub parameter:

kosi update -p package.tgz

-f flag

The parameter f must be used to use yaml files from the user.

kosi update --hub <hubname> <package> -f <user.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and user specific files are to be used for the update progress:

kosi update --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameters.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi update --hub <hubname> <package> --cf <encryptedUser.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and user specific encrypted files are to be used for the update progress:

kosi update --hub public kosi/livedemo:2.7.1 --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml --cf encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files. Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi update --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a kubernetes namespace in which the update is to be performed.

kosi update --hub <hubname> <package> --namespace <namespace>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and a custom kubernetes namespace is used:

kosi update --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the default namespace will be used.

–dname flag

The parameter dname can be used to update the deployment by name.

kosi update --hub <hubname> <package> --dname <deploymentname>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and a deployment name is set:

kosi update --hub public kosi/livedemo:2.7.1 --dname MyDeployment

Command ‘kosi delete’

The kosi delete command deletes an already installed KOSI package:

For delete, the installation and the update package have to be the same name. Delete will be defined in the package.yaml.

kosi delete --hub <hubname> --dname <deploymentname> <package>

The string of the column Install in the output of kosi search is required:

Example: The installation of the package lima from the user kosi with version 0.6.2 and deployment name kosiInstallsLima is deleted by a package from the public Software Hub from kosi.:

kosi delete --hub public --dname kosiInstallsLima kosi/kosi/lima:0.6.2 

–hub flag

The --hub parameter must be used to use the delete section of packages from the software hub. Only the logged in user can use the delete section of packages from the software hub.

kosi delete --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be updated from the public Software Hub:

kosi delete --hub public kosi/livedemo:2.7.1
```create:0.0.1
```-create:0.0.1

-p flag

The “p” parameter must be used to delete the installation from a local package. For “p” parameter you need no --hub parameter:

kosi delete -p package.tgz

-f flag

The parameter f must be used to use yaml files from the user.

kosi delete --hub <hubname> <package> -f <user.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and user specific files are to be used for the delete progress:

kosi delete --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameter.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi delete --hub <hubname> <package> -f <encryptedUser.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and user specific encrypted files are to be used for the delete progress:

kosi delete --hub public kosi/livedemo:2.7.1 -f encryptedUserfile1.yaml -f encryptedUserfile2.yaml -f encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files. Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi delete --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a kubernetes namespace in which to perform the deletion.

kosi delete --hub <hubname> <package> --namespace <namespace>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and a custom kubernetes namespace is used:

kosi delete --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the default namespace will be used.

–dname flag

The parameter dname can be used to delete the deployment by name.

kosi delete --hub <hubname> <package> --dname <deploymentname>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and a deployment name is set:

kosi delete --hub public kosi/livedemo:2.7.1 --dname MyDeployment

Command ‘kosi remove’

The kosi remove command removes a KOSI package from the hub:

Note: Only logged users can delete there own packages on their own hubs.

kosi remove --hub <hubname> <package>

Note: the package you want to remove can be found in the output of the kosi search command, more precisely in the install column

Example: The package livedemo of the user kosi with version 2.7.1 will be removed from the public hub:

kosi remove --hub public kosi/livedemo:2.7.1 

Note: If your package already deleted, the command will try do delete your package successfully. Deleting non-existing packages does not cause any errors.

Command ‘kosi check’

The kosi check command is used to compare a local kosi package with a sha256 Checksum.

kosi check -p <localpackagename> <sha256 hash>

Example:

kosi check -p examplepackage c83f3db9639e175f82e7d07d342533866873e2d9ca2f0fd5ee607ea395417edb

File Formats

package.kosi

This file defines properties of the KOSI package. This file is created after the kosi create command. The package.kosi 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. The includes.containers element is 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. There is also a description, which will be shown in the kosi search command. The includes.files element describes the files which are inluded in the KOSI package. The installation.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi install command. The update.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi update command.The delete.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

IMPORTANT: To get your package please enter a fully lowercase name for your package.

Note: Do not change name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

languageversion = "1.0.0";
apiversion = "kubernative/kubeops/sina/user/v3";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = "touch ~/kosiExample1");
}

update
{
    cmd(command=  "touch ~/kosiExample2");
}

delete
{
    cmd(command = "rm ~/kosiExample1");
    cmd(command = "rm ~/kosiExample2");
}

package.yaml

This file defines properties of the KOSI package. This file is created after the kosi build command. 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. The includes.containers element is 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. There is also a description, which will be shown in the kosi search command. The includes.files element describes the files which are inluded in the KOSI package. The installation.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi install command. The update.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi update command.The delete.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

IMPORTANT: The apiversion has been changed from …/user/v2 to …/user/v3. The Image Key has been split into to seperate Keys registry and image.

IMPORTANT: To get your package please enter a fully lowercase name for your package.

Note: Do not change name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

# languageversion: "0.1.0"
apiversion: "kubernative/kubeops/sina/user/v3"
name: "kosi-example-packagev3"
description: "kosi-example-package"
version: "0.1.0"
docs: "docs.tgz"
logo: "logo.png"
includes:
  files:
    input: "template.yaml"
  containers:
    example:
      registry: "docker.io"
      image: "nginx"
      tag: "latest"
installation:
  tasks:
    - cmd:
        command: "touch ~/kosiExample1"
update:
  tasks:
    - cmd:
        command: "touch ~/kosiExample2"
delete:
  tasks:
    - cmd:
        command: "rm ~/kosiExample1"
    - cmd:
        command: "rm ~/kosiExample2"

default.yaml

The default.yaml in a package.tgz is used for setting default variables. In case you use the -f parameter in install, update or delete, the file which you address is merged with the default.yaml. If you have the same keys but different values in both files, your adressed file will overwrite the values set by the default.yaml.

config.yaml

Location for: /var/kubeops/kosi/config.yaml

The config.yaml file contains all necessary files for networking and logging. For example, config.yaml contains the hub from which the packages are downloaded.

apiversion: kubernative/kosi/config/v2           # Shows the supported API-Version
spec:                                            
  hub: https://hub.kubernative.net/dispatcher/      # Adress to the KOSI online hub
  plugins: /kubeops/kosi/kosi-plugins/                      # Location of the KOSI-Plugins
  registry: registry1.kubernative.net/             # Registry, where Docker-images will be pulled to (kosi pull)
  workspace: /tmp/kosi/process/                    # Workspace Path 
  logging: info                                    # Loglevel options: info (default), warning, error, debug1, debug2, debug3
  housekeeping: true                               # Housekeeping options: true (all temporary created folders will be deleted), false (all temporary created folders won't be deleted)

Usage

To keep KOSI running there has to be a valid config.yaml file.
After installing KOSI, a valid config.yaml file is created under the location /var/kubeops/kosi/config.yaml. If you want to use your own Hub you can create a user-specific config.yaml file. The original file can be changed too, but it is not recommended.

$KUBEOPSROOT Variable

The $KUBEOPSROOT environment variable stores the location of the KOSI plugins and the config.yaml. To use the variable, the config.yaml and the plugins have to be copied manually.
So for example:

cp -r /var/kubeops/kosi/config.yaml /home/<user>/kubeopsrootdir/kosi/config.yaml
rm -rf /var/kubeops/kosi
cp -r /var/kubeops/plugins /home/<user>/kubeopsrootdir/plugins
rm -rf /var/kubeops/plugins

If you want to use the config file and plugins with a user you have to go through these steps.

How to use templating within the package.kosi

This is an example of how templating in a package.kosi is working with kosi 2.10.x

First we need to create this package.kosi:

# languageversion: "0.1.0"
apiversion = "kubernative/kubeops/sina/user/v3";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
    input = "template.yaml";
}

containers =
{
    example = ["docker.io", "nginx", "latest"];
}

install
{
    cmd(command = '"echo using templatep plugin."');

    template
    (
        tmpl = '{{package.includes.files.input}}';
        target = '{{values.target}}';
    );
}

update
{
    cmd(command = '"touch ~/kosiExample2"');

    template
    (
        tmpl = '{{package.includes.files.input}}';
        target = '{{values.target}}';
    );
}

delete
{
    cmd(command = '"rm ~/kosiExample1"');
    cmd(command = '"rm ~/kosiExample2"');
}

Now we create a template.yaml:

package:
  file: {{package.includes.files.input}}
  uservalues: {{values.example}}

Next we create a default.yaml:

example: example
target: target.yaml

Please make sure that you create all these files in the same directory.

Now we are ready to create a kosi package. For this we need the following command:

kosi build

Next we can run the installation section we have defined in the package.yaml with the following command:

kosi install -p package.tgz --dname example

We can check the result in the directory $KUBEOPSROOT/kosi/tmp.

The file of interest is the target.yaml. But most of the time this file is not in tmp Folder . In this case, type the command find / -name target.yaml to find the location of the target.yaml file.

the content of target.yaml is:

package:
  file: template.yaml
  uservalues: example

So what exactly happened?
In the package.yaml you can see that we use {{package.includes.files.input}} for defining the template.yaml as value for the key tmpl. You can use any value of the package.yaml but make sure that the path to the value is correct and starts with package.. This is the indicator for using a variable from the package.yaml.

You can also see that we use {{values.target}} for defining the target.yaml as value for the key target. If you wonder where the target.yaml is coming from you can check the default.yaml. If you want to use a variable from the default.yaml or from a file specified with the parameter -f make sure that the path to the value is correct and starts with values..

For more information about the template syntax check the Scriban documentation (https://github.com/scriban/scriban/blob/master/doc/language.md) and try it out in the online demo (https://scribanonline.azurewebsites.net).

Plugins

With the installation of KOSI a handful of plugins are included. Which plugins are included can be seen under “pre-installed plugins” in the Plugin References

5.5 - Full Documentation KOSI-2.10.x

KubeOps KOSI

How to use KOSI

This guide explains how to use KOSI with detailed instructions and examples.

General commands

Overview of all KOSI commands

kosi:
  Kosi is a SoftwareINstAller for kubernetes cluster

Usage:
  Kosi [options] [command]

Options:
  --version         Show version information
  -?, -h, --help    Show help and usage information

Commands:
  login                    logs you in
  search                   Shows you all the available packages on the softwarehub
  build                    Creates your final kosi.package
  push                     Push package.tgz to KubeOps Hub.
  pull <package>           Downloads an existing package from the hub without installing.
  install <packagename>    install a .tgz file and if it is required, download it
  update <packagename>     update a .tgz file and if it is required, download it
  delete <packagename>     run delete section of a .tgz file and if it is required, download it
  list                     List packages from storage
  lint                     lint your files for your .tgz package
  create                   Creates a package.kosi and a template.yaml for you to manipulate
  version                  Basic infos about KOSI
  logout                   Logout
  remove <package>         Gives you the possibility to remove packages from the hub, if you have write permissions.
  encrypt                  Gives you the possibility to encrypt your values with a password.
  check <hash>             check your local package hash

Command ‘kosi –help’

The command kosi --help gives you an overview of all available commands:

kosi --help

Alternatively, you can also enter kosi or kosi -? in the command line.

Command ‘kosi version’

The kosi version command shows you the current version of KOSI.

kosi version

The output should be:

[ 12/03/2021 10:13:20 Debug1  default ] Check OS Support...
[ 12/03/2021 10:13:20 Debug1  default ] set Loglevel info
Version: 2.10.0_Beta0
This work is licensed under Creative Commons Attribution - NoDerivatives 4.0 International License(see https://creativecommons.org/licenses/by-nd/4.0/legalcode for more details).
©KubeOps GmbH, Hinter Stöck 17, 72406 Bisingen - Germany, 2022

Command ‘kosi create’

Note: The command works in the current directory.

The command kosi create creates four files (package.kosi, template.yaml, logo.png and docs.tgz) in the current directory. These files can be edited by the user.

The template.yaml is required if the template engine Scriban is to be used.

The logo.png is a package-thumbnail with the size of 50x50px

The docs.tgz is a zipped directory with the documentation of the package. The documentation of the package is written down in markdown. The file for the documentation is called readme.md.

Note: Please name your markdown files inside docs.tgz without a version-tag (docs/documentation-1.0.0.md).

kosi create

Created files:

  • package.kosi
  • template.yaml
  • logo.png - For showing logo on the KubeOpsHub.
  • docs.tgz - For showing documentation on the KubeOpsHub.

Command ‘kosi build’

Note: The command works in the current working directory.

Note: If you have no package.kosi file in your current working directory, KOSI will pick a package.yaml file.

Note: Name your package in the package.kosi in full lower case.

Note: Don´t change the name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without a version-tag (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

The kosi build command creates the necessary yaml files for building a package:

kosi build

All files specified in the package.kosi are combined together with the package.yaml to form a KOSI package.

The package.yaml is only generated once, if it is not available. If the package.yaml already exists the package.yaml will not be generated.

Command ‘kosi lint’

The kosi lint command is used to check whether the contents of the package.yaml file are valid:

kosi lint

Command ‘kosi login’

The kosi login command logs on to the KubeOps services. The account name is required for this command.

Note: To push packages into the hub, you need to create an account here first. Note: We recommend lowercase usernames for your kubeops-accounts.

After the flag -u type your username. Afterwards you will be asked to enter your password.

kosi login -u <username>

The parameter -p is used to enter the password in the command directly, but it is important to know that the password will be shown in plain text. This parameter can help with the automation of KOSI commands.

kosi login -u <username> -p <password>

-u flag

The -u parameter is used to specify the user name.

kosi login -u

This parameter is required.

-p flag

The -p parameter is used to specify the password.

kosi login -p

This parameter is not required. We recommend to use this parameter only if it is absolutely necessary.

Command ‘kosi logout’

The kosi logout command logs out from the KubeOps services.

Note: To logout from the KubeOps services, you have to be logged in.

kosi logout

Command ‘kosi push’

The kosi push command uploads KOSI packages to the KubeOps Hub:

kosi push --hub <hubname>

Note: In order to upload KOSI packages, you first have to log in using the kosi login command.

Note: The package name is case-sensitive and should be lowercase.

–hub flag

The --hub parameter is used to upload KOSI packets from a specific hub, e.g. in this example we upload our KOSI packet to the public hub.

kosi push --hub public

Command ‘kosi pull’

The kosi pull command downloads a specific KOSI package from the hub without installing it directly.

kosi pull --hub <hubname> <packagename> -o <desired name>

Note: kosi pull downloads the package to the current directory.

Note: The downloaded packages can be transferred to machines without internet access via USB, for example.

Note: The package name is case-sensitive and should be lowercase.

Example:

kosi pull --hub public donald/kosi-print-test:0.0.1 -o printpackage

Note: The -o option specifies a name that the package will have after download. The file automatically gets the .kosi extension. The -o option is not optional.

–hub flag

The --hub parameter is used to download KOSI packages to a specific hub, e.g. in this example we are pulling our KOSI package from the public hub.

kosi pull --hub public kubeops/harbor:1.1.0  

-r flag

The parameter r can be used to pull the docker images which are included in the package to a given local docker registry.

kosi pull --hub <hubname> <packagename> -o <desired name> -r <local.docker.registry>

Note: kosi pull downloads the package and pulls the required docker images to the given local docker registry.

Example:

kosi pull --hub public kubeops/harbor:1.1.0   -o harborpackage -r 127.0.0.1:5000

Note: After the kosi pull kubeops/harbor:1.1.0 -o printpackage -r 127.0.0.1:5000 command you can use kosi install -p printpackage.tgz to use the docker image from your local docker registry.

Note: You can now install your packages including docker images without internet connection from your local machine.

-t flag

For the szenario that the registry of the cluster is exposed to the admin via a network internal domain name, but this name can’t be resolved by the nodes, the flag -t can be used, to use the cluster internal hostname of the registry.

kosi pull --hub <hubname> <packagename> -o <desired name> -r <local.docker.registry> -t <cluster.internal.registry>

Note: local.docker.registry is the same registry as cluster.internal.registry but with a different hostname.

Example:

kosi pull --hub public kubeops/harbor:1.1.0 -o harborpackage -r myregistry:5000 -t clusterregistry:5000

IMPORTANT: -t flag can only be used in combination with the -r flag.

KOSI_retag_registry

The kosi search command displays all available packages of your own private hub. Only the logged in user can see the packages on his private hub. The User column contains the name of the creator of the package.
The Name column contains the name of the package.
The Version column contains the version of the package.
The Description column contains the description of the package.
The Install column contains a string consisting of the name of the creator, name and version of the package. This string can be copied and used for the kosi install command.

kosi search --hub <hubname>

Example: User donald is logged in and wants to get the packets from his private hub:

kosi search --hub donald
| User   | Name         | Version | Description                      |Install                    |
|--------|--------------|---------|----------------------------------|---------------------------|                  
| donald | private-kosi | 0.0.1   | private installation             | donald/private-kosi:0.0.1 |                                       
| donald | private-test | 0.0.1   | private package                  | donald/private-test:0.0.1 |
| donald | livedemo     | 2.7.2   | welcome to kosi                  | donald/livedemo:2.7.1     | 

–ps flag

The --ps parameter can be used to filter for keywords that refer to all five columns. It is also possible to filter by individual word components:

kosi search --hub <hubname> --ps <name>

Example:
In this case, all packets containing the word private are displayed:

kosi search --hub donald --ps private
| User   | Name         | Version | Description                      |Install                    |
|--------|--------------|---------|----------------------------------|---------------------------|                  
| donald | private-kosi | 0.0.1   | private installation             | donald/private-kosi:0.0.1 |                                       
| donald | private-test | 0.0.1   | private package                  | donald/private-test:0.0.1 |                                        

–hub flag

In addition, there is an option to search for packages on a specific hub using the --hub parameter. You need no login to search in the public hub.

kosi search --hub public
| User   | Name         | Version | Description                      |Install                  |
|--------|--------------|---------|----------------------------------|-------------------------|
| kosi   | lima         | 0.6.2   | installs LIMA                    | kosi/lima:0.6.2         |
| kosi   | installation | 0.0.1   | kosi create example package.yaml | kosi/installation:0.0.1 |  
| donald | elk-kosi     | 0.0.1   | ELK installation                 | donald/elk-kosi:0.0.1   |
| donald | prod-test    | 0.0.1   | test for prod                    | donald/prod-test:0.0.1  | 
| lima   | lima         | 0.6.0   | installs LIMA                    | lima/lima:0.6.0         |
                                     

The parameters --hub and --ps can be combined for a targeted search in the kosi hub:

kosi search --hub <hubname> --ps <package_name>

Example:
The user kosi wants to display all packages in the kosi hub with the term “lima”.

kosi search --hub kosi  --ps lima
| User | Name         | Version | Description                      |Install                  |
|------|--------------|---------|----------------------------------|-------------------------|
| kosi | lima         | 0.6.2   | installs LIMA                    | kosi/lima:0.6.2         |
| kosi | lima         | 0.7.1   | installs LIMA                    | kosi/lima:0.7.1         |
                                     

Command ‘kosi encrypt’

The kosi encrypt command is used to encrypt YAML files with AES-256-CBC:

-f flag

The parameter -f must be used to use yaml files from the user.

This parameter is required.

kosi encrypt -f <user.yaml>

Note: The -f parameter can be specified any number of times to use any number of files.

kosi encrypt -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Command ‘kosi install’

The kosi install command installs a KOSI package:

kosi install --hub <hubname> <package>

The string of the column Install in the output of kosi search is required:

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the private Hub:

kosi install --hub public kosi/livedemo:2.7.1 

–hub flag

The --hub parameter must be used to install packages from the software hub. Only the logged in user can install the packages from the software hub.

kosi install --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public Software Hub:

kosi install --hub public kosi/livedemo:2.7.1

-p flag

The “p” parameter must be used to install local packages. For “p” parameter you need no --hub:

kosi install -p package.kosi

-f flag

The parameter f must be used to use .yaml files from the user.

kosi install <package> -f <user.yaml>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and user specific files are to be used for the installation:

kosi install --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameter.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi install <package> --cf <encryptedUser.yaml>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and user specific encrypted files are to be used for the installation:

kosi install --hub public kosi/livedemo:2.7.1 --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml --cf encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files.
Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi install --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a Kubernetes namespace in which the installation is to be performed.

kosi install --hub <hubname> <package> --namespace <namespace>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and a custom kubernetes namespace is used:

kosi install --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the namespace default will be used.

–dname flag

The parameter dname can be used to save the package under a specific name.

kosi install --hub <hubname> <package> --dname <deploymentname>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and a deployment name is set:

kosi install --hub public kosi/livedemo:2.7.1 --dname MyDeployment

Note: If no --dname parameter is specified, a random deployment name will be generated. Note: Deploymentnames are unique, the installation will stop if the deploymentname already exists.
Note: The deployment name is stored in the file /<user>/var/kubeops/kosi/deployment.yaml.

Command ‘kosi list’

The kosi list command lists all installed KOSI packages:

kosi list
 KOSI version: 2.10.0_Beta0
| Deployment       | Package                           | PublicHub | Hub    |
|------------------|-----------------------------------|-----------|--------|
| kosiinstallslima | kosi/lima:0.6.2                   |           | private|
| kosicreatetest   | kosi/kosi-create:0.0.1            |           | public |
| plugininstall    | local/kubeops-basic-plugins:0.4.0 |           | local  |

Command ‘kosi update’

The kosi update command updates an already installed KOSI package:

For update, the installation and the update package have to be the same name. Update will be defined in the package.yaml.

kosi update --hub <hubname> --dname <deploymentname> <package>

The string of the column Install in the output of kosi search is required:

Example: The installation of the package lima from the user kosi with version 0.6.2 and deployment name kosiInstallsLima is updated by a package from the private Software Hub from kosi.:

kosi update --hub public --dname kosiInstallsLima kosi/kosi/lima:0.6.2 

–hub flag

The --hub parameter must be used to update packages from the software hub. Only the logged in user can update the packages from the software hub.

kosi update --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be updated from the public Software Hub:

kosi update --hub public kosi/livedemo:2.7.1
```create:0.0.1

-p flag

The “p” parameter must be used to update the installation from a local package. For “p” parameter you need no --hub parameter:

kosi update -p package.tgz

-f flag

The parameter f must be used to use yaml files from the user.

kosi update --hub <hubname> <package> -f <user.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and user specific files are to be used for the update progress:

kosi update --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameters.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi update --hub <hubname> <package> --cf <encryptedUser.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and user specific encrypted files are to be used for the update progress:

kosi update --hub public kosi/livedemo:2.7.1 --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml --cf encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files. Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi update --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a kubernetes namespace in which the update is to be performed.

kosi update --hub <hubname> <package> --namespace <namespace>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and a custom kubernetes namespace is used:

kosi update --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the default namespace will be used.

–dname flag

The parameter dname can be used to update the deployment by name.

kosi update --hub <hubname> <package> --dname <deploymentname>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and a deployment name is set:

kosi update --hub public kosi/livedemo:2.7.1 --dname MyDeployment

Command ‘kosi delete’

The kosi delete command deletes an already installed KOSI package:

For delete, the installation and the update package have to be the same name. Delete will be defined in the package.yaml.

kosi delete --hub <hubname> --dname <deploymentname> <package>

The string of the column Install in the output of kosi search is required:

Example: The installation of the package lima from the user kosi with version 0.6.2 and deployment name kosiInstallsLima is deleted by a package from the private Software Hub from kosi.:

kosi delete --hub public --dname kosiInstallsLima kosi/kosi/lima:0.6.2 

–hub flag

The --hub parameter must be used to use the delete section of packages from the software hub. Only the logged in user can use the delete section of packages from the software hub.

kosi delete --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be updated from the public Software Hub:

kosi delete --hub public kosi/livedemo:2.7.1
```create:0.0.1
```-create:0.0.1

-p flag

The “p” parameter must be used to delete the installation from a local package. For “p” parameter you need no --hub parameter:

kosi delete -p package.tgz

-f flag

The parameter f must be used to use yaml files from the user.

kosi delete --hub <hubname> <package> -f <user.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and user specific files are to be used for the delete progress:

kosi delete --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameter.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi delete --hub <hubname> <package> -f <encryptedUser.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and user specific encrypted files are to be used for the delete progress:

kosi delete --hub public kosi/livedemo:2.7.1 -f encryptedUserfile1.yaml -f encryptedUserfile2.yaml -f encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files. Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi delete --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a kubernetes namespace in which to perform the deletion.

kosi delete --hub <hubname> <package> --namespace <namespace>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and a custom kubernetes namespace is used:

kosi delete --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the default namespace will be used.

–dname flag

The parameter dname can be used to delete the deployment by name.

kosi delete --hub <hubname> <package> --dname <deploymentname>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and a deployment name is set:

kosi delete --hub public kosi/livedemo:2.7.1 --dname MyDeployment

Command ‘kosi remove’

The kosi remove command removes a KOSI package from the hub:

Note: Only logged users can delete there own packages. Users must have write-permissions.

kosi remove --hub <hubname> <package>

Note: the package you want to remove can be found in the output of the kosi search command, more precisely in the install column

Example: The package livedemo of the user kosi with version 2.7.1 will be removed from the public hub:

kosi remove --hub public kosi/livedemo:2.7.1 

Note: If your package already deleted, the command will try do delete your package successfully. Deleting non-existing packages does not cause any errors.

Command ‘kosi check’

The kosi check command is used to compare a local kosi package with a sha256 Checksum.

kosi check -p <localpackagename> <sha256 hash>

Example:

kosi check -p examplepackage c83f3db9639e175f82e7d07d342533866873e2d9ca2f0fd5ee607ea395417edb

File Formats

package.kosi

This file defines properties of the KOSI package. This file is created after the kosi create command. The package.kosi 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. The includes.containers element is 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. There is also a description, which will be shown in the kosi search command. The includes.files element describes the files which are inluded in the KOSI package. The installation.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi install command. The update.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi update command.The delete.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

IMPORTANT: To get your package please enter a fully lowercase name for your package.

Note: Do not change name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

languageversion = "0.1.0";
apiversion = "kubernative/kubeops/sina/user/v3";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
  input="template.yaml";
}

containers =
{
    example=["docker.io", "nginx", "latest"];
}

install
{
    cmd(command='"touch ~/kosiExample1"');
}

update
{
    cmd(command='"touch ~/kosiExample2"');
}

delete
{
    cmd(command='"rm ~/kosiExample1"');
    cmd(command='"rm ~/kosiExample2"');
}

package.yaml

This file defines properties of the KOSI package. This file is created after the kosi build command. 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. The includes.containers element is 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. There is also a description, which will be shown in the kosi search command. The includes.files element describes the files which are inluded in the KOSI package. The installation.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi install command. The update.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi update command.The delete.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

IMPORTANT: The apiversion has been changed from …/user/v2 to …/user/v3. The Image Key has been split into to seperate Keys registry and image.

IMPORTANT: To get your package please enter a fully lowercase name for your package.

Note: Do not change name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

# languageversion: "0.1.0"
apiversion: "kubernative/kubeops/sina/user/v3"
name: "kosi-example-packagev3"
description: "kosi-example-package"
version: "0.1.0"
docs: "docs.tgz"
logo: "logo.png"
includes:
  files:
    input: "template.yaml"
  containers:
    example:
      registry: "docker.io"
      image: "nginx"
      tag: "latest"
installation:
  tasks:
    - cmd:
        command: "touch ~/kosiExample1"
update:
  tasks:
    - cmd:
        command: "touch ~/kosiExample2"
delete:
  tasks:
    - cmd:
        command: "rm ~/kosiExample1"
    - cmd:
        command: "rm ~/kosiExample2"

default.yaml

The default.yaml in a package.tgz is used for setting default variables. In case you use the -f parameter in install, update or delete, the file which you address is merged with the default.yaml. If you have the same keys but different values in both files, your adressed file will overwrite the values set by the default.yaml.

config.yaml

Location for: /var/kubeops/kosi/config.yaml

The config.yaml file contains all necessary files for networking and logging. For example, config.yaml contains the hub from which the packages are downloaded.

apiversion: kubernative/kosi/config/v2           # Shows the supported API-Version
spec:                                            
  hub: https://hub.kubernative.net/dispatcher/      # Adress to the KOSI online hub
  plugins: /kubeops/kosi/kosi-plugins/                      # Location of the KOSI-Plugins
  registry: registry1.kubernative.net/             # Registry, where Docker-images will be pulled to (kosi pull)
  workspace: /tmp/kosi/process/                    # Workspace Path 
  logging: info                                    # Loglevel options: info (default), warning, error, debug1, debug2, debug3
  housekeeping: true                               # Housekeeping options: true (all temporary created folders will be deleted), false (all temporary created folders won't be deleted)

Usage

To keep KOSI running there has to be a valid config.yaml file.
After installing KOSI, a valid config.yaml file is created under the location /var/kubeops/kosi/config.yaml. If you want to use your own Hub you can create a user-specific config.yaml file. The original file can be changed too, but it is not recommended.

$KUBEOPSROOT Variable

The $KUBEOPSROOT environment variable stores the location of the KOSI plugins and the config.yaml. To use the variable, the config.yaml and the plugins have to be copied manually.
So for example:

cp -r /var/kubeops/kosi/config.yaml /home/<user>/kubeopsrootdir/kosi/config.yaml
rm -rf /var/kubeops/kosi
cp -r /var/kubeops/plugins /home/<user>/kubeopsrootdir/plugins
rm -rf /var/kubeops/plugins

If you want to use the config file and plugins with a user you have to go through these steps.

How to use templating within the package.kosi

This is an example of how templating in a package.kosi is working with kosi 2.10.x

First we need to create this package.kosi:

# languageversion: "0.1.0"
apiversion = "kubernative/kubeops/sina/user/v3";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
  input="template.yaml";
}

containers =
{
    example=["docker.io", "nginx", "latest"];
}

install
{
    cmd(command='"echo using templatep plugin."');
    template(tmpl='{{package.includes.files.input}}';target='{{values.target}}');
}

update
{
    cmd(command='"touch ~/kosiExample2"');
    template(tmpl='{{package.includes.files.input}}';target='{{values.target}}');
}

delete
{
    cmd(command='"rm ~/kosiExample1"');
    cmd(command='"rm ~/kosiExample2"');
}

Now we create a template.yaml:

package:
  file: {{package.includes.files.input}}
  uservalues: {{values.example}}

Next we create a default.yaml:

example: example
target: target.yaml

Please make sure that you create all these files in the same directory.

Now we are ready to create a kosi package. For this we need the following command:

kosi build

Next we can run the installation section we have defined in the package.yaml with the following command:

kosi install -p package.tgz --dname example

We can check the result in the directory $KUBEOPSROOT/kosi/tmp.

The file of interest is the target.yaml. But most of the time this file is not in tmp Folder . In this case, type the command find / -name target.yaml to find the location of the target.yaml file.

the content of target.yaml is:

package:
  file: template.yaml
  uservalues: example

So what exactly happened?
In the package.yaml you can see that we use {{package.includes.files.input}} for defining the template.yaml as value for the key tmpl. You can use any value of the package.yaml but make sure that the path to the value is correct and starts with package.. This is the indicator for using a variable from the package.yaml.

You can also see that we use {{values.target}} for defining the target.yaml as value for the key target. If you wonder where the target.yaml is coming from you can check the default.yaml. If you want to use a variable from the default.yaml or from a file specified with the parameter -f make sure that the path to the value is correct and starts with values..

For more information about the template syntax check the Scriban documentation (https://github.com/scriban/scriban/blob/master/doc/language.md) and try it out in the online demo (https://scribanonline.azurewebsites.net).

Plugins

With the installation of KOSI a handful of plugins are included. Which plugins are included can be seen under “pre-installed plugins” in the Plugin References

5.6 - Full Documentation KOSI-2.9.x

KubeOps KOSI

How to use KOSI

This guide explains how to use KOSI with detailed instructions and examples.

General commands

Overview of all KOSI commands

kosi:
  Kosi is a SoftwareINstAller for kubernetes cluster

Usage:
  Kosi [options] [command]

Options:
  --version         Show version information
  -?, -h, --help    Show help and usage information

Commands:
  login                    logs you in
  search                   Shows you all the available packages on the softwarehub
  build                    Creates your final kosi.package
  push                     Push package.tgz to KubeOps Hub.
  pull <package>           Downloads an existing package from the hub without installing.
  install <packagename>    install a .tgz file and if it is required, download it
  update <packagename>     update a .tgz file and if it is required, download it
  delete <packagename>     run delete section of a .tgz file and if it is required, download it
  list                     List packages from storage
  lint                     lint your files for your .tgz package
  create                   Creates a package.kosi and a template.yaml for you to manipulate
  version                  Basic infos about KOSI
  logout                   Logout
  remove <package>         Gives you the possibility to remove packages from the hub, if you have write permissions.
  encrypt                  Gives you the possibility to encrypt your values with a password.
  check <hash>             check your local package hash

Command ‘kosi –help’

The command kosi --help gives you an overview of all available commands:

kosi --help

Alternatively, you can also enter kosi or kosi -? in the command line.

Command ‘kosi version’

The kosi version command shows you the current version of KOSI.

kosi version

The output should be:

[ 12/03/2021 10:13:20 Debug1  default ] Check OS Support...
[ 12/03/2021 10:13:20 Debug1  default ] set Loglevel info
Version: 2.9.0_Alpha0
This work is licensed under Creative Commons Attribution - NoDerivatives 4.0 International License(see https://creativecommons.org/licenses/by-nd/4.0/legalcode for more details).
©KubeOps GmbH, Hinter Stöck 17, 72406 Bisingen - Germany, 2022

Command ‘kosi create’

Note: The command works in the current directory.

The command kosi create creates four files (package.kosi, template.yaml, logo.png and docs.tgz) in the current directory. These files can be edited by the user.

The template.yaml is required if the template engine Scriban is to be used.

The logo.png is a package-thumbnail with the size of 50x50px

The docs.tgz is a zipped directory with the documentation of the package. The documentation of the package is written down in markdown. The file for the documentation is called readme.md.

Note: Please name your markdown files inside docs.tgz without a version-tag (docs/documentation-1.0.0.md).

kosi create

Created files:

  • package.kosi
  • template.yaml
  • logo.png - For showing logo on the KubeOpsHub.
  • docs.tgz - For showing documentation on the KubeOpsHub.

Command ‘kosi build’

Note: The command works in the current working directory.

Note: If you have no package.kosi file in your current working directory, KOSI will pick a package.yaml file.

Note: Name your package in the package.kosi in full lower case.

Note: Don´t change the name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without a version-tag (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

The kosi build command creates the necessary yaml files for building a package:

kosi build

All files specified in the package.kosi are combined together with the package.yaml to form a KOSI package.

The package.yaml is only generated once, if it is not available. If the package.yaml already exists the package.yaml will not be generated.

Command ‘kosi lint’

The kosi lint command is used to check whether the contents of the package.yaml file are valid:

kosi lint

Command ‘kosi login’

The kosi login command logs on to the KubeOps services. The account name is required for this command.

Note: To push packages into the hub, you need to create an account here first. Note: We recommend lowercase usernames for your kubeops-accounts.

After the flag -u type your username. Afterwards you will be asked to enter your password.

kosi login -u <username>

The parameter -p is used to enter the password in the command directly, but it is important to know that the password will be shown in plain text. This parameter can help with the automation of KOSI commands.

kosi login -u <username> -p <password>

-u flag

The -u parameter is used to specify the user name.

kosi login -u

This parameter is required.

-p flag

The -p parameter is used to specify the password.

kosi login -p

This parameter is not required. We recommend to use this parameter only if it is absolutely necessary.

Command ‘kosi logout’

The kosi logout command logs out from the KubeOps services.

Note: To logout from the KubeOps services, you have to be logged in.

kosi logout

Command ‘kosi push’

The kosi push command uploads KOSI packages to the KubeOps Hub:

kosi push --hub <hubname>

Note: In order to upload KOSI packages, you first have to log in using the kosi login command.

Note: The package name is case-sensitive and should be lowercase.

–hub flag

The --hub parameter is used to upload KOSI packets from a specific hub, e.g. in this example we upload our KOSI packet to the public hub.

kosi push --hub public

Command ‘kosi pull’

The kosi pull command downloads a specific KOSI package from the hub without installing it directly.

kosi pull --hub <hubname> <packagename> -o <desired name>

Note: kosi pull downloads the package to the current directory.

Note: The downloaded packages can be transferred to machines without internet access via USB, for example.

Note: The package name is case-sensitive and should be lowercase.

Example:

kosi pull --hub public donald/kosi-print-test:0.0.1 -o printpackage

Note: The -o option specifies a name that the package will have after download. The file automatically gets the .kosi extension. The -o option is not optional.

–hub flag

The --hub parameter is used to download KOSI packages to a specific hub, e.g. in this example we are pulling our KOSI package from the public hub.

kosi pull --hub public kubeops/harbor:1.1.0  

-r flag

The parameter r can be used to pull the docker images which are included in the package to a given local docker registry.

kosi pull --hub <hubname> <packagename> -o <desired name> -r <local.docker.registry>

Note: kosi pull downloads the package and pulls the required docker images to the given local docker registry.

Example:

kosi pull --hub public kubeops/harbor:1.1.0   -o harborpackage -r 127.0.0.1:5000

Note: After the kosi pull kubeops/harbor:1.1.0 -o printpackage -r 127.0.0.1:5000 command you can use kosi install -p printpackage.tgz to use the docker image from your local docker registry.

Note: You can now install your packages including docker images without internet connection from your local machine.

-t flag

For the szenario that the registry of the cluster is exposed to the admin via a network internal domain name, but this name can’t be resolved by the nodes, the flag -t can be used, to use the cluster internal hostname of the registry.

kosi pull --hub <hubname> <packagename> -o <desired name> -r <local.docker.registry> -t <cluster.internal.registry>

Note: local.docker.registry is the same registry as cluster.internal.registry but with a different hostname.

Example:

kosi pull --hub public kubeops/harbor:1.1.0 -o harborpackage -r myregistry:5000 -t clusterregistry:5000

IMPORTANT: -t flag can only be used in combination with the -r flag.

KOSI_retag_registry

The kosi search command displays all available packages of your own private hub. Only the logged in user can see the packages on his private hub. The User column contains the name of the creator of the package.
The Name column contains the name of the package.
The Version column contains the version of the package.
The Description column contains the description of the package.
The Install column contains a string consisting of the name of the creator, name and version of the package. This string can be copied and used for the kosi install command.

kosi search --hub <hubname>

Example: User donald is logged in and wants to get the packets from his private hub:

kosi search --hub donald
| User   | Name         | Version | Description                      |Install                    |
|--------|--------------|---------|----------------------------------|---------------------------|                  
| donald | private-kosi | 0.0.1   | private installation             | donald/private-kosi:0.0.1 |                                       
| donald | private-test | 0.0.1   | private package                  | donald/private-test:0.0.1 |
| donald | livedemo     | 2.7.2   | welcome to kosi                  | donald/livedemo:2.7.1     | 

–ps flag

The --ps parameter can be used to filter for keywords that refer to all five columns. It is also possible to filter by individual word components:

kosi search --hub <hubname> --ps <name>

Example:
In this case, all packets containing the word private are displayed:

kosi search --hub donald --ps private
| User   | Name         | Version | Description                      |Install                    |
|--------|--------------|---------|----------------------------------|---------------------------|                  
| donald | private-kosi | 0.0.1   | private installation             | donald/private-kosi:0.0.1 |                                       
| donald | private-test | 0.0.1   | private package                  | donald/private-test:0.0.1 |                                        

–hub flag

In addition, there is an option to search for packages on a specific hub using the --hub parameter. You need no login to search in the public hub.

kosi search --hub public
| User   | Name         | Version | Description                      |Install                  |
|--------|--------------|---------|----------------------------------|-------------------------|
| kosi   | lima         | 0.6.2   | installs LIMA                    | kosi/lima:0.6.2         |
| kosi   | installation | 0.0.1   | kosi create example package.yaml | kosi/installation:0.0.1 |  
| donald | elk-kosi     | 0.0.1   | ELK installation                 | donald/elk-kosi:0.0.1   |
| donald | prod-test    | 0.0.1   | test for prod                    | donald/prod-test:0.0.1  | 
| lima   | lima         | 0.6.0   | installs LIMA                    | lima/lima:0.6.0         |
                                     

The parameters --hub and --ps can be combined for a targeted search in the kosi hub:

kosi search --hub <hubname> --ps <package_name>

Example:
The user kosi wants to display all packages in the kosi hub with the term “lima”.

kosi search --hub kosi  --ps lima
| User | Name         | Version | Description                      |Install                  |
|------|--------------|---------|----------------------------------|-------------------------|
| kosi | lima         | 0.6.2   | installs LIMA                    | kosi/lima:0.6.2         |
| kosi | lima         | 0.7.1   | installs LIMA                    | kosi/lima:0.7.1         |
                                     

Command ‘kosi encrypt’

The kosi encrypt command is used to encrypt YAML files with AES-256-CBC:

-f flag

The parameter -f must be used to use yaml files from the user.

This parameter is required.

kosi encrypt -f <user.yaml>

Note: The -f parameter can be specified any number of times to use any number of files.

kosi encrypt -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Command ‘kosi install’

The kosi install command installs a KOSI package:

kosi install --hub <hubname> <package>

The string of the column Install in the output of kosi search is required:

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the private Hub:

kosi install --hub public kosi/livedemo:2.7.1 

–hub flag

The --hub parameter must be used to install packages from the software hub. Only the logged in user can install the packages from the software hub.

kosi install --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public Software Hub:

kosi install --hub public kosi/livedemo:2.7.1

-p flag

The “p” parameter must be used to install local packages. For “p” parameter you need no --hub:

kosi install -p package.kosi

-f flag

The parameter f must be used to use .yaml files from the user.

kosi install <package> -f <user.yaml>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and user specific files are to be used for the installation:

kosi install --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameter.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi install <package> --cf <encryptedUser.yaml>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and user specific encrypted files are to be used for the installation:

kosi install --hub public kosi/livedemo:2.7.1 --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml --cf encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files.
Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi install --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a Kubernetes namespace in which the installation is to be performed.

kosi install --hub <hubname> <package> --namespace <namespace>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and a custom kubernetes namespace is used:

kosi install --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the namespace default will be used.

–dname flag

The parameter dname can be used to save the package under a specific name.

kosi install --hub <hubname> <package> --dname <deploymentname>

Example: The package livedemo of the user kosi with version 2.7.1 is to be installed from the public software hub and a deployment name is set:

kosi install --hub public kosi/livedemo:2.7.1 --dname MyDeployment

Note: If no --dname parameter is specified, a random deployment name will be generated. Note: Deploymentnames are unique, the installation will stop if the deploymentname already exists.
Note: The deployment name is stored in the file /<user>/var/kubeops/kosi/deployment.yaml.

Command ‘kosi list’

The kosi list command lists all installed KOSI packages:

kosi list
 KOSI version: 2.9.0_preAlpha0
| Deployment       | Package                           | PublicHub | Hub    |
|------------------|-----------------------------------|-----------|--------|
| kosiinstallslima | kosi/lima:0.6.2                   |           | private|
| kosicreatetest   | kosi/kosi-create:0.0.1            |           | public |
| plugininstall    | local/kubeops-basic-plugins:0.4.0 |           | local  |

Command ‘kosi update’

The kosi update command updates an already installed KOSI package:

For update, the installation and the update package have to be the same name. Update will be defined in the package.yaml.

kosi update --hub <hubname> --dname <deploymentname> <package>

The string of the column Install in the output of kosi search is required:

Example: The installation of the package lima from the user kosi with version 0.6.2 and deployment name kosiInstallsLima is updated by a package from the private Software Hub from kosi.:

kosi update --hub public --dname kosiInstallsLima kosi/kosi/lima:0.6.2 

–hub flag

The --hub parameter must be used to update packages from the software hub. Only the logged in user can update the packages from the software hub.

kosi update --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be updated from the public Software Hub:

kosi update --hub public kosi/livedemo:2.7.1
```create:0.0.1

-p flag

The “p” parameter must be used to update the installation from a local package. For “p” parameter you need no --hub parameter:

kosi update -p package.tgz

-f flag

The parameter f must be used to use yaml files from the user.

kosi update --hub <hubname> <package> -f <user.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and user specific files are to be used for the update progress:

kosi update --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameters.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi update --hub <hubname> <package> --cf <encryptedUser.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and user specific encrypted files are to be used for the update progress:

kosi update --hub public kosi/livedemo:2.7.1 --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml --cf encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files. Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi update --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a kubernetes namespace in which the update is to be performed.

kosi update --hub <hubname> <package> --namespace <namespace>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and a custom kubernetes namespace is used:

kosi update --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the default namespace will be used.

–dname flag

The parameter dname can be used to update the deployment by name.

kosi update --hub <hubname> <package> --dname <deploymentname>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is updated by a package from the public software hub and a deployment name is set:

kosi update --hub public kosi/livedemo:2.7.1 --dname MyDeployment

Command ‘kosi delete’

The kosi delete command deletes an already installed KOSI package:

For delete, the installation and the update package have to be the same name. Delete will be defined in the package.yaml.

kosi delete --hub <hubname> --dname <deploymentname> <package>

The string of the column Install in the output of kosi search is required:

Example: The installation of the package lima from the user kosi with version 0.6.2 and deployment name kosiInstallsLima is deleted by a package from the private Software Hub from kosi.:

kosi delete --hub public --dname kosiInstallsLima kosi/kosi/lima:0.6.2 

–hub flag

The --hub parameter must be used to use the delete section of packages from the software hub. Only the logged in user can use the delete section of packages from the software hub.

kosi delete --hub <hubname> <package>

Example: The package livedemo of the user kosi with version 2.7.1 is to be updated from the public Software Hub:

kosi delete --hub public kosi/livedemo:2.7.1
```create:0.0.1
```-create:0.0.1

-p flag

The “p” parameter must be used to delete the installation from a local package. For “p” parameter you need no --hub parameter:

kosi delete -p package.tgz

-f flag

The parameter f must be used to use yaml files from the user.

kosi delete --hub <hubname> <package> -f <user.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and user specific files are to be used for the delete progress:

kosi delete --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml -f userfile3.yaml

Note: The -f parameter can be specified any number of times to use any number of files. Note: The -f parameter can also be combined with the --hub parameter.

–cf flag

The parameter --cf must be used to use encrypted yaml files from the user.

kosi delete --hub <hubname> <package> -f <encryptedUser.yaml>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and user specific encrypted files are to be used for the delete progress:

kosi delete --hub public kosi/livedemo:2.7.1 -f encryptedUserfile1.yaml -f encryptedUserfile2.yaml -f encryptedUserfile3.yaml

Note: The --cf parameter can be specified any number of times to use any number of encrypted files. Note: The --cf parameter can also be combined with the --hub parameter.
Note: The --cf parameter can also be combined with the -f parameter.

IMPORTANT: If you combine -f with --cf, you must specify the -f parameter first before specifying --cf!

Example:

kosi delete --hub public kosi/livedemo:2.7.1 -f userfile1.yaml -f userfile2.yaml --cf encryptedUserfile1.yaml --cf encryptedUserfile2.yaml

–namespace flag

The namespace parameter can be used to specify a kubernetes namespace in which to perform the deletion.

kosi delete --hub <hubname> <package> --namespace <namespace>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and a custom kubernetes namespace is used:

kosi delete --hub public kosi/livedemo:2.7.1 --namespace MyNamespace

Note: If no --namespace parameter is specified, the default namespace will be used.

–dname flag

The parameter dname can be used to delete the deployment by name.

kosi delete --hub <hubname> <package> --dname <deploymentname>

Example: The installation of the package livedemo of the user kosi with version 2.7.1 is deleted by a package from the public software hub and a deployment name is set:

kosi delete --hub public kosi/livedemo:2.7.1 --dname MyDeployment

Command ‘kosi remove’

The kosi remove command removes a KOSI package from the hub:

Note: Only logged users can delete there own packages. Users must have write-permissions.

kosi remove --hub <hubname> <package>

Note: the package you want to remove can be found in the output of the kosi search command, more precisely in the install column

Example: The package livedemo of the user kosi with version 2.7.1 will be removed from the public hub:

kosi remove --hub public kosi/livedemo:2.7.1 

Note: If your package already deleted, the command will try do delete your package successfully. Deleting non-existing packages does not cause any errors.

Command ‘kosi check’

The kosi check command is used to compare a local kosi package with a sha256 Checksum.

kosi check -p <localpackagename> <sha256 hash>

Example:

kosi check -p examplepackage c83f3db9639e175f82e7d07d342533866873e2d9ca2f0fd5ee607ea395417edb

File Formats

package.kosi

This file defines properties of the KOSI package. This file is created after the kosi create command. The package.kosi 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. The includes.containers element is 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. There is also a description, which will be shown in the kosi search command. The includes.files element describes the files which are inluded in the KOSI package. The installation.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi install command. The update.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi update command.The delete.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

IMPORTANT: To get your package please enter a fully lowercase name for your package.

Note: Do not change name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

languageversion = "0.1.0";
apiversion = "kubernative/kubeops/sina/user/v3";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
  input="template.yaml";
}

containers =
{
    example=["docker.io", "nginx", "latest"];
}

install
{
    cmd(command='"touch ~/kosiExample1"');
}

update
{
    cmd(command='"touch ~/kosiExample2"');
}

delete
{
    cmd(command='"rm ~/kosiExample1"');
    cmd(command='"rm ~/kosiExample2"');
}

package.yaml

This file defines properties of the KOSI package. This file is created after the kosi build command. 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. The includes.containers element is 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. There is also a description, which will be shown in the kosi search command. The includes.files element describes the files which are inluded in the KOSI package. The installation.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi install command. The update.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi update command.The delete.tasks tree describes the tasks (KOSI plugins), which are executed with the kosi delete command.

IMPORTANT: The apiversion has been changed from …/user/v2 to …/user/v3. The Image Key has been split into to seperate Keys registry and image.

IMPORTANT: To get your package please enter a fully lowercase name for your package.

Note: Do not change name for logo.png and docs.tgz

Note: Please name your markdown files inside docs.tgz without versions (docs/documentation-1.0.0.md).

IMPORTANT: Please name your packages without docker tags (:v1.0.0).

# languageversion: "0.1.0"
apiversion: "kubernative/kubeops/sina/user/v3"
name: "kosi-example-packagev3"
description: "kosi-example-package"
version: "0.1.0"
docs: "docs.tgz"
logo: "logo.png"
includes:
  files:
    input: "template.yaml"
  containers:
    example:
      registry: "docker.io"
      image: "nginx"
      tag: "latest"
installation:
  tasks:
    - cmd:
        command: "touch ~/kosiExample1"
update:
  tasks:
    - cmd:
        command: "touch ~/kosiExample2"
delete:
  tasks:
    - cmd:
        command: "rm ~/kosiExample1"
    - cmd:
        command: "rm ~/kosiExample2"

default.yaml

The default.yaml in a package.tgz is used for setting default variables. In case you use the -f parameter in install, update or delete, the file which you address is merged with the default.yaml. If you have the same keys but different values in both files, your adressed file will overwrite the values set by the default.yaml.

config.yaml

Location for: /var/kubeops/kosi/config.yaml

The config.yaml file contains all necessary files for networking and logging. For example, config.yaml contains the hub from which the packages are downloaded.

apiversion: kubernative/kosi/config/v2           # Shows the supported API-Version
spec:                                            
  hub: https://hub.kubernative.net/dispatcher/      # Adress to the KOSI online hub
  plugins: /kubeops/kosi/kosi-plugins/                      # Location of the KOSI-Plugins
  registry: registry1.kubernative.net/             # Registry, where Docker-images will be pulled to (kosi pull)
  workspace: /tmp/kosi/process/                    # Workspace Path 
  logging: info                                    # Loglevel options: info (default), warning, error, debug1, debug2, debug3
  housekeeping: true                               # Housekeeping options: true (all temporary created folders will be deleted), false (all temporary created folders won't be deleted)

Usage

To keep KOSI running there has to be a valid config.yaml file.
After installing KOSI, a valid config.yaml file is created under the location /var/kubeops/kosi/config.yaml. If you want to use your own Hub you can create a user-specific config.yaml file. The original file can be changed too, but it is not recommended.

$KUBEOPSROOT Variable

The $KUBEOPSROOT environment variable stores the location of the KOSI plugins and the config.yaml. To use the variable, the config.yaml and the plugins have to be copied manually.
So for example:

cp -r /var/kubeops/kosi/config.yaml /home/<user>/kubeopsrootdir/kosi/config.yaml
rm -rf /var/kubeops/kosi
cp -r /var/kubeops/plugins /home/<user>/kubeopsrootdir/plugins
rm -rf /var/kubeops/plugins

If you want to use the config file and plugins with a user you have to go through these steps.

How to use templating within the package.kosi

This is an example of how templating in a package.kosi is working with kosi 2.9.x

First we need to create this package.kosi:

# languageversion: "0.1.0"
apiversion = "kubernative/kubeops/sina/user/v3";
name = "kosi-example-packagev3";
description = "kosi-example-package";
version = "0.1.0";
docs = "docs.tgz";
logo = "logo.png";

files =
{
  input="template.yaml";
}

containers =
{
    example=["docker.io", "nginx", "latest"];
}

install
{
    cmd(command='"echo using templatep plugin."');
    template(tmpl='{{package.includes.files.input}}';target='{{values.target}}');
}

update
{
    cmd(command='"touch ~/kosiExample2"');
    template(tmpl='{{package.includes.files.input}}';target='{{values.target}}');
}

delete
{
    cmd(command='"rm ~/kosiExample1"');
    cmd(command='"rm ~/kosiExample2"');
}

Now we create a template.yaml:

package:
  file: {{package.includes.files.input}}
  uservalues: {{values.example}}

Next we create a default.yaml:

example: example
target: target.yaml

Please make sure that you create all these files in the same directory.

Now we are ready to create a kosi package. For this we need the following command:

kosi build

Next we can run the installation section we have defined in the package.yaml with the following command:

kosi install -p package.tgz --dname example

We can check the result in the directory $KUBEOPSROOT/kosi/tmp.

The file of interest is the target.yaml. But most of the time this file is not in tmp Folder . In this case, type the command find / -name target.yaml to find the location of the target.yaml file.

the content of target.yaml is:

package:
  file: template.yaml
  uservalues: example

So what exactly happened?
In the package.yaml you can see that we use {{package.includes.files.input}} for defining the template.yaml as value for the key tmpl. You can use any value of the package.yaml but make sure that the path to the value is correct and starts with package.. This is the indicator for using a variable from the package.yaml.

You can also see that we use {{values.target}} for defining the target.yaml as value for the key target. If you wonder where the target.yaml is coming from you can check the default.yaml. If you want to use a variable from the default.yaml or from a file specified with the parameter -f make sure that the path to the value is correct and starts with values..

For more information about the template syntax check the Scriban documentation (https://github.com/scriban/scriban/blob/master/doc/language.md) and try it out in the online demo (https://scribanonline.azurewebsites.net).

Plugins

With the installation of KOSI a handful of plugins are included. Which plugins are included can be seen under “pre-installed plugins” in the Plugin References