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! 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 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 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 does it work? in order to define a template in kubeark, there are a few important object types that we need to consider the main arguments section 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 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 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