Templates (Kubernetes)

Save valuable time and reduce the risk of errors from one centralized place

Note: Templates enable you to customize everything needed to fit your pipeline needs. Define it once and use it multiple times!
Overview
Collaboration, communication, and integration play a vital role in achieving success in the DevOps landscape. By focusing on these elements, teams can enhance their performance and ensure the quality of their processes and pipeline. These aspects are critical for achieving high performance and quality assurance, and by optimizing them, teams can experience a positive impact on their overall efficiency and effectiveness.
With this in mind, Kubeark makes use of Templates. Templates in Kubeark are pre-constructed configurations that include all the resources necessary to run a specific workload or application. They are designed to save time and reduce errors when scaling, by providing all the necessary infrastructure, platform, and software components. They are easy for users to implement and get started with.
The Templates page within the Kubeark Platform offers an intuitive, easy-to-use interface for defining and managing templates. 
There are two types of templates that Kubeark uses to enable a smooth experience with your projects. Going further, let's see what these are:
Manifests: A Kubernetes manifests represents the specification of an API object in JSON or YAML format. In a manifest you can specify a desired state of an object that Kubernetes will create and maintain when the manifest is applied to the specific Kubernetes cluster.
Charts: A chart represents a collection of files that describe a related set of Kubernetes API objects or resources. The template language of a chart is implemented in typed Go programming language.
How to use?
In order to define a template, there are two important object types that we need to consider:
1.First, we have the Arguments .These are mandatory inputs that need to be provided in order to define a functional deployment. Arguments will enable you to define what values can be passed along to your pipeline.
Argument
Description
Name 
This is the unique name of the defined template
Status 
The template status is an unique value from an allowed list of values. These can be:
->Active - Production ready
->Disabled - In development
Scope
This is a boolean value which defines the type of template based on your collaboration preferences or needs:
-> public - the endpoint is exposed in the      public templates list
-> private - templates are exposed internal only
Owner
This field defines the user which created the template
manifest 
The Kubernetes manifest which will be created by the deployment action.
Note: Not required if a chart template is used
chart 
The chart template which will be created by the deployment action
Note: Not required if a Kubernetes manifest is added
default_time
Represents the default time until an environment_action is triggered. The logic behind this parameters is that we want on-demand disposable containers triggered by external or internal actions like paying an invoice, closing or opening a contract, etc
additional_time 
Represents an additional time when the default time is reached. This is used as a failsafe mechanism before triggering the environment_action
grace_time 
Represents the grace period before the environment is deleted or terminated
environment_action
This argument allows adding business logic for the environments lifecycle, and can be defined through:
-> terminate - This is when the environment is terminated when the default_time, additional_time and grace_time reach 0 seconds
-> manual - Manual trigger
-> stop  - This downscales to 0 all the resources that can be scaled to 0 (e.g. Deployments, StatefulSets, ReplicaSets, etc)
-> details - Represents the description of the current defined template
2.  Extra-Arguments. These are additional arguments that can be added which offer you more control over the values that can be passed to your pipeline. They are designed to encapsulate dynamic or specific template arguments. 
Extra arguments
Description
extra_args 
Additional arguments added  in template in order to deploy the defined solution and achieve a desired state
Example: Let's consider a web service solution with an ingress where a different ingress endpoint for each deployment is required. Here you will define an argument with a default value which can be overridden at the deployment step.
form_params
These are extra arguments which are mapped with "extra_args" values and can be public.
In form_params you can define how the public form can be shown on the external lading page integrated with KubeArk Platform.
Example: Let's consider an ingress.hostname parameter. We will define ingress.hostname as a parent key, and the values contained represents a set of key-value pairs defining an html input form. All the HTML valid forms are accepted as key-value pairs.
​
Below you will find a sample Template payload:
{
    "name":"wordpress",
    "status": "active",
    "owner":"need_to_add_an_account",
    "public": true,
    "manifest": {},
    "chart": {
        "name": "wordpress",
        "repo": "bitnami",
        "repo_url": "https://charts.bitnami.com/bitnami",
        "path": ""
    },
    "extra_args": {
        "ingress.enabled": "False",
        "ingress.ingressClassName": "nginx",
        "ingress.hostname": "your_ingress_hostname",
        "persistence.enabled": "false",
        "persistence.size": "1Gi",
        "mariadb.primary.persistence.enabled": "false",
        "wordpressPassword": "your_wordpress_password",
        "mariadb.auth.rootPassword": "your_mariadb_rootpassword",
        "mariadb.auth.password": "your_mariadb_password",
        "test_empty_arg": "empty"
        },
    "form_params": {
        "ingress.hostname": {
            "input_type": "text",
            "default_value": "your_ingress_default_value",
            "value": "",
            "label": "Website hostname",
            "required": true,
            "id": "hostname",
            "name": "DNS name",
            "minlength": 4,
            "maxlength": 12,
            "size": 10,
            "pattern": "[A-Za-z].[A-Za-z]{12}",
            "title": "12 alpha characters."
​
        },
        "wordpressPassword": {
            "input_type": "password",
            "default_value": "",
            "value": "",
            "label": "Website password",
            "id": "wordpressPassword",
            "name": "Admin password"
        }
    },
    "details": "details about your template",
    "default_time": 30,
    "additional_time":15,
    "environment_action": "terminate",
    "grace_time": 20
}

Argument	Description
`Name`	This is the unique name of the defined template
`Status`	The template status is an unique value from an allowed list of values. These can be: ->`Active` - Production ready ->`Disabled` - In development
`Scope`	This is a boolean value which defines the type of template based on your collaboration preferences or needs: -> `public` - the endpoint is exposed in the public `templates` list -> `private` - `templates` are exposed internal only
`Owner`	This field defines the `user` which created the template
`manifest`	The Kubernetes manifest which will be created by the deployment action. Note: Not required if a chart template is used
`chart`	The chart template which will be created by the deployment action Note: Not required if a Kubernetes manifest is added
`default_time`	Represents the default time until an `environment_action` is triggered. The logic behind this parameters is that we want on-demand disposable containers triggered by external or internal actions like paying an invoice, closing or opening a contract, etc
`additional_time`	Represents an additional time when the default time is reached. This is used as a failsafe mechanism before triggering the `environment_action`
`grace_time`	Represents the grace period before the environment is `deleted` or `terminated`
`environment_action`	This argument allows adding business logic for the environments lifecycle, and can be defined through: -> `terminate` - This is when the environment is terminated when the `default_time, additional_time` and `grace_time` reach 0 seconds -> `manual` - Manual trigger -> `stop` - This downscales to 0 all the resources that can be scaled to 0 (e.g. `Deployments`, `StatefulSets`, `ReplicaSets`, etc) -> `details` - Represents the description of the current defined template

Extra arguments	Description
`extra_args`	Additional arguments added in `template` in order to deploy the defined solution and achieve a desired state Example: Let's consider a web service solution with an ingress where a different ingress endpoint for each deployment is required. Here you will define an argument with a default value which can be overridden at the deployment step.
`form_params`	These are extra arguments which are mapped with "extra_args" values and can be public. In `form_params` you can define how the public form can be shown on the external lading page integrated with KubeArk Platform. Example: Let's consider an ingress.hostname parameter. We will define ingress.hostname as a parent key, and the values contained represents a set of key-value pairs defining an html input form. All the HTML valid forms are accepted as key-value pairs.

Environments Menu - Previous

Kubernetes

Template Versions

Last modified 17d ago