Templates (Kubernetes)
Save valuable time and reduce the risk of errors from one centralized place. Templates enable you to customize everything needed to fit your pipeline needs. Define it once and use it multiple times!
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
In order to define a template in Kubeark, there are a few important object types that we need to consider:
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 |
Template group | The template group to which the new template will belong |
Cluster group | The cluster group to which the new template will belong |
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 -> Stop -> Terminate - This downscales to 0 all the resources that can be scaled to 0 (e.g. Deployments, StatefulSets, ReplicaSets, etc) |
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 |
Tags | Option to add a custom tag to your template for easy reference |
Description | Add a custom description about the template |
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 |
| |
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.
Form composer - When creating a template, you have the option to provide additional details using a form composer. The form composer can be used from the main template creation page by selecting the "Insert Field" button.
Here are some of the fields you can include:
- Key: A unique identifier or name for the field.
- Id: An identifier that helps uniquely identify the field within the form.
- Name: The name or label of the field as it will appear in the form.
- Title: A title or description that provides further information about the field's purpose.
- Input Type: Specifies the type of input expected in the field, such as "text" for plain text input.
- Min Length and Max Length: Define the minimum and maximum lengths allowed for the input in characters.
- Label: A descriptive label for the field, providing context or guidance to the user.
- Pattern: If applicable, a regular expression pattern that defines the expected format for the input.
- Value: An initial or default value for the field, if needed.
- Disabled: A boolean (true/false) value indicating whether the field is initially disabled or not editable.
- Required: A boolean value specifying whether the field must be filled out by the user
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.
Chart information - this section includes essential details related to charts and repositories in the context of Kubeark template creation
The arguments you can include:
- Chart Information Name: A user-defined name or identifier for the chart. It helps users easily recognize and reference the specific chart associated with the template.
- Repository Name: The name of the repository or source where the chart is hosted.
- Repository URL: The repository URL specifies the web address or location where the chart repository can be accessed.
- Path: The path field defines the directory or subdirectory within the repository where the specific chart files are located.
Additional parameters - Variables are used to generate random data. You can use them in the values field of the additional parametewrs section. You can combine them with any other values.
For example, {{set_string}}-test the result will be a random string followed by the word test. You can also use them in a payload from a value of extra arguments, combined with other values or predefined variables.
The following predefined variable categories are available:
->Infra
->User
->Function
Additional parameters can also be added, the platform supporting various formats such as string, numeric, JSON, Code, List or Boolean
