Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The Rollout Deployment chart deploys an advanced version of deployment that supports Blue/Green and Canary deployments. For functioning, it requires a rollout controller to run inside the cluster.
You can define application behavior by providing information in the following sections:
Super-admins can lock keys in rollout deployment template to prevent non-super-admins from modifying those locked keys. Refer Lock Deployment Configuration to know more.
Devtron uses helm charts for the deployments. And we are having multiple chart versions based on features it is supporting with every chart version.
One can see multiple chart version options available in the drop-down. you can select any chart version as per your requirements. By default, the latest version of the helm chart is selected in the chart version option.
Every chart version has its own YAML file. Helm charts are used to provide specifications for your application. To make it easy to use, we have created templates for the YAML file and have added some variables inside the YAML. You can provide or change the values of these variables as per your requirement.
If you want to see Application Metrics (as an example, Status codes 2xx, 3xx, 5xx; throughput, and latency etc.) for your application, then you need to select the latest chart version.
Note: Application Metrics are not supported for the Chart version older than 3.7 version.
Some of the use-cases which are defined on the Deployment Template (YAML file) may not be applicable to configure for your application. In such cases, you can do the basic deployment configuration for your application on the Basic GUI section instead of configuring the YAML file.
The following fields are provided on the Basic GUI section:
Click Save Changes.
If you want to do additional configurations, then click Advanced (YAML) for modifications.
Note: If you change any values in the Basic GUI, then the corresponding values will be changed in YAML file also.
This defines the ports on which application services will be exposed to other services.
EnvVariables provide run-time information to containers and allow to customize how the application works and the behavior of the applications on the system.
Here we can pass the list of env variables , every record is an object which contain the name of variable along with value.
To set environment variables for the containers that run in the Pod.
IMP Docker image should have env variables, whatever we want to set.
But ConfigMap and Secret are the preferred way to inject env variables. You can create this in App Configuration Section.
It is a centralized storage, specific to k8s namespace where key-value pairs are stored in plain text.
It is a centralized storage, specific to k8s namespace where we can store the key-value pairs in plain text as well as in encrypted(Base64) form.
IMP All key-values of Secret and CofigMap will reflect to your application.
If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count. The default value of "MaxSurge: " is 25%.
This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
Startup Probe in Kubernetes is a type of probe used to determine when a container within a pod is ready to start accepting traffic. It is specifically designed for applications that have a longer startup time.
This is connected to HPA and controls scaling up and down in response to request load.
fullnameOverride replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses {app-name}-{environment-name} as release fullname.
Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
imagePullSecrets contains the docker credentials that are used for accessing a registry.
regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/ .
the hostAliases field is used in a Pod specification to associate additional hostnames with the Pod's IP address. This can be helpful in scenarios where you need to resolve specific hostnames to the Pod's IP within the Pod itself.
This allows public access to the url. Please ensure you are using the right nginx annotation for nginx class. The default value is nginx.
Legacy deployment-template ingress format
This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to true.
To wait for given period of time before switch active the container.
These define minimum and maximum RAM and CPU available to the application.
Resources are required to set CPU and memory usage.
Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
Requests are what the container is guaranteed to get.
This defines annotations and the type of service, optionally can define name also.
Note - If loadBalancerSourceRanges is not set, Kubernetes allows traffic from 0.0.0.0/0 to the LoadBalancer / Node Security Group(s).
It is required when some values need to be read from or written to an external disk.
It is used to provide mounts to the volume.
Spec is used to define the desire state of the given container.
Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
Taints are the opposite, they allow a node to repel a set of pods.
A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
This is used to give arguments to command.
It contains the commands to run inside the container.
Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to true.
It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case.It describes the state of the prometheus.
Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the GracePeriod.
A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
It is used for providing server configurations.
It gives the details for deployment.
It gives the set of targets to be monitored.
It is used to configure database migration.
These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
Application metrics can be enabled to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency.
It gives the realtime metrics of the deployed applications
A service account provides an identity for the processes that run in a Pod.
When you access the cluster, you are authenticated by the API server as a particular User Account. Processes in containers inside pod can also contact the API server. When you are authenticated as a particular Service Account.
When you create a pod, if you do not create a service account, it is automatically assigned the default service account in the namespace.
You can create PodDisruptionBudget for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, an application would like to ensure the number of replicas running is never brought below the certain number.
or
You can specify either maxUnavailable or minAvailable in a PodDisruptionBudget and it can be expressed as integers or as a percentage.
Envoy is attached as a sidecar to the application container to collect metrics like 4XX, 5XX, Throughput and latency. You can now configure the envoy settings such as idleTimeout, resources etc.
Alerting rules allow you to define alert conditions based on Prometheus expressions and to send notifications about firing alerts to an external service.
In this case, Prometheus will check that the alert continues to be active during each evaluation for 1 minute before firing the alert. Elements that are active, but not firing yet, are in the pending state.
Labels are key/value pairs that are attached to pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects.
Pod Annotations are widely used to attach metadata and configs in Kubernetes.
HPA, by default is configured to work with CPU and Memory metrics. These metrics are useful for internal cluster sizing, but you might want to configure wider set of metrics like service latency, I/O load etc. The custom metrics in HPA can help you to achieve this.
Wait for given period of time before scaling down the container.
If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
Once all the Deployment template configurations are done, click on Save to save your deployment configuration. Now you are ready to create Workflow to do CI/CD.
Helm Chart json schema is used to validate the deployment template values.
The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
Prerequisite: KEDA controller should be installed in the cluster. To install KEDA controller using Helm, navigate to chart store and search for keda chart and deploy it. You can follow this documentation for deploying a Helm chart on Devtron.
KEDA Helm repo : https://kedacore.github.io/charts
KEDA is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
Example for autoscaling with KEDA using Prometheus metrics is given below:
Example for autosccaling with KEDA based on kafka is given below :
Kubernetes NetworkPolicies control pod communication by defining rules for incoming and outgoing traffic.
Winter Soldier can be used to
cleans up (delete) Kubernetes resources
reduce workload pods to 0
NOTE: After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check the main repo
Given below is template values you can give in winter-soldier:
here is an example,
Above settings will take action on Sat and Sun from 00:00 to 23:59:59, and on Mon-Fri from 00:00 to 08:00 and 20:00 to 23:59:59. If action:sleep then runs hibernate at timeFrom and unhibernate at timeTo. If action: delete then it will delete workloads at timeFrom and timeTo. Here the action:scale thus it scale the number of resource replicas to targetReplicas: [1,1,1]. Here each element of targetReplicas array is mapped with the corresponding elements of array timeRangesWithZone/timeRanges. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')
AddTime - This can be used to add time. For eg AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h') ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
Now - This can be used to get current time.
CpuToNumber - This can be used to compare CPU. For eg any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')}) will check if any resource.requests is less than 60Mi.
A security context defines privilege and access control settings for a Pod or Container.
To add a security context for main container:
To add a security context on pod level:
You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
| Key | Descriptions |
|---|---|
| Fields | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Chart Version | Link |
|---|---|
| Key | Description |
|---|---|
| Key | values | Description |
|---|---|---|
Chart Version
Select the Chart Version using which you want to deploy the application.
Port
The internal HTTP port.
HTTP Request Routes
Enable the HTTP Request Routes to define Host and Path. By default, it is in disabled state.
Host: Domain name of the server.
Path: Path of the specific component in the host that the HTTP wants to access.
You can define multiple paths as required by clicking Add path.
CPU
The CPU resource as per the application.
RAM
The RAM resource as per the application.
Environment Variables (Key/Value)
Define key/value by clicking Add variable.
Key: Define the key of the environment.
Value: Define the value of the environment.
You can define multiple env variables by clicking Add variable.
envoyPort
envoy port for the container.
envoyTimeout
envoy Timeout for the container,envoy supports a wide range of timeouts that may need to be configured depending on the deployment.By default the envoytimeout is 15s.
idleTimeout
the duration of time that a connection is idle before the connection is terminated.
name
name of the port.
port
port for the container.
servicePort
port of the corresponding kubernetes service.
supportStreaming
Used for high performance protocols like grpc where timeout needs to be disabled.
useHTTP2
Envoy container can accept HTTP2 requests.
Path
It define the path where the liveness needs to be checked.
initialDelaySeconds
It defines the time to wait before a given container is checked for liveliness.
periodSeconds
It defines how often (in seconds) to perform the liveness probe.
successThreshold
It defines the number of successes required before a given container is said to fulfil the liveness probe.
timeoutSeconds
The maximum time (in seconds) for the probe to complete.
failureThreshold
The number of consecutive failures required to consider the probe as failed.
command
The mentioned command is executed to perform the livenessProbe. If the command returns a non-zero value, it's equivalent to a failed probe.
httpHeaders
Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe.
scheme
Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
tcp
The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy.
Path
It define the path where the readiness needs to be checked.
initialDelaySeconds
It defines the time to wait before a given container is checked for readiness.
periodSeconds
It defines how often (in seconds) to perform the readiness probe.
successThreshold
It defines the number of successes required before a given container is said to fulfill the readiness probe.
timeoutSeconds
The maximum time (in seconds) for the probe to complete.
failureThreshold
The number of consecutive failures required to consider the probe as failed.
command
The mentioned command is executed to perform the readinessProbe. If the command returns a non-zero value, it's equivalent to a failed probe.
httpHeaders
Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe.
scheme
Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
tcp
The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy.
Path
It define the path where the startup needs to be checked.
initialDelaySeconds
It defines the time to wait before a given container is checked for startup.
periodSeconds
It defines how often (in seconds) to perform the startup probe.
successThreshold
The number of consecutive successful probe results required to mark the container as ready.
timeoutSeconds
The maximum time (in seconds) for the probe to complete.
failureThreshold
The number of consecutive failures required to consider the probe as failed.
command
The mentioned command is executed to perform the startup probe. If the command returns a non-zero value, it's equivalent to a failed probe.
httpHeaders
Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe.
tcp
The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy.
enabled
Set true to enable autoscaling else set false.
MinReplicas
Minimum number of replicas allowed for scaling.
MaxReplicas
Maximum number of replicas allowed for scaling.
TargetCPUUtilizationPercentage
The target CPU utilization that is expected for a container.
TargetMemoryUtilizationPercentage
The target memory utilization that is expected for a container.
extraMetrics
Used to give external metrics for autoscaling.
enabled
Determines whether to create a ServiceAccount for pods or not. If set to true, a ServiceAccount will be created.
name
Specifies the name of the ServiceAccount to use.
annotations
Specify annotations for the ServiceAccount.
enabled
Enable or disable ingress
annotations
To configure some options depending on the Ingress controller
host
Host name
pathType
Path in an Ingress is required to have a corresponding path type. Supported path types are ImplementationSpecific, Exact and Prefix.
path
Path name
tls
It contains security details
enabled
Enable or disable ingress
annotations
To configure some options depending on the Ingress controller
host
Host name
pathType
Path in an Ingress is required to have a corresponding path type. Supported path types are ImplementationSpecific, Exact and Prefix.
path
Path name
pathType
Supported path types are ImplementationSpecific, Exact and Prefix.
tls
It contains security details
type
Select the type of service, default ClusterIP
annotations
Annotations are widely used to attach metadata and configs in Kubernetes.
name
Optional field to assign name to service
loadBalancerSourceRanges
If service type is LoadBalancer, Provide a list of whitelisted IPs CIDR that will be allowed to use the Load Balancer.
enabled
To enable or disable the command.
value
It contains the commands.
workingDir
It is used to specify the working directory where commands will be executed.
image_tag
It is the image tag
image
It is the URL of the image
istio
Istio enablement. When istio.enable set to true, Istio would be enabled for the specified configurations
authorizationPolicy
It allows you to define access control policies for service-to-service communication.
action
Determines whether to ALLOW or DENY the request based on the defined rules.
provider
Authorization providers are external systems or mechanisms used to make access control decisions.
rules
List of rules defining the authorization policy. Each rule can specify conditions and requirements for allowing or denying access.
destinationRule
It allows for the fine-tuning of traffic policies and load balancing for specific services. You can define subsets of a service and apply different traffic policies to each subset.
subsets
Specifies subsets within the service for routing and load balancing.
trafficPolicy
Policies related to connection pool size, outlier detection, and load balancing.
gateway
Allowing external traffic to enter the service mesh through the specified configurations.
host
The external domain through which traffic will be routed into the service mesh.
tls
Traffic to and from the gateway should be encrypted using TLS.
secretName
Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway.
peerAuthentication
It allows you to enforce mutual TLS and control the authentication between services.
mtls
Mutual TLS. Mutual TLS is a security protocol that requires both client and server, to authenticate each other using digital certificates for secure communication.
mode
Mutual TLS mode, specifying how mutual TLS should be applied. Modes include STRICT, PERMISSIVE, and DISABLE.
portLevelMtls
Configures port-specific mTLS settings. Allows for fine-grained control over the application of mutual TLS on specific ports.
selector
Configuration for selecting workloads to apply PeerAuthentication.
requestAuthentication
Defines rules for authenticating incoming requests.
jwtRules
Rules for validating JWTs (JSON Web Tokens). It defines how incoming JWTs should be validated for authentication purposes.
selector
Specifies the conditions under which the RequestAuthentication rules should be applied.
virtualService
Enables the definition of rules for how traffic should be routed to different services within the service mesh.
gateways
Specifies the gateways to which the rules defined in the VirtualService apply.
hosts
List of hosts (domains) to which this VirtualService is applied.
http
Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies.
Deployment Frequency
It shows how often this app is deployed to production
Change Failure Rate
It shows how often the respective pipeline fails.
Mean Lead Time
It shows the average time taken to deliver a change to production.
Mean Time to Recovery
It shows the average time taken to fix a failed pipeline.
minAvailable
Evictions are allowed as long as they leave behind 1 or more healthy pods of the total number of desired replicas.
maxUnavailable
Evictions are allowed as long as at most 1 unhealthy replica among the total number of desired replicas.
reference-chart_3-12-0
reference-chart_3-11-0
reference-chart_3-10-0
reference-chart_3-9-0
enabled
Enable or disable NetworkPolicy.
annotations
Additional metadata or information associated with the NetworkPolicy.
labels
Labels to apply to the NetworkPolicy.
podSelector
Each NetworkPolicy includes a podSelector which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty podSelector selects all pods in the namespace.
policyTypes
Each NetworkPolicy includes a policyTypes list which may include either Ingress, Egress, or both.
Ingress
Controls incoming traffic to pods.
Egress
Controls outgoing traffic from pods.
enabled
false,true
decide the enabling factor
apiVersion
pincher.devtron.ai/v1beta1, pincher.devtron.ai/v1alpha1
specific api version
action
sleep,delete, scale
This specify the action need to perform.
timeRangesWithZone:timeZone
eg:- "Asia/Kolkata","US/Pacific"
It use to specify the timeZone used. (It uses standard format. please refer this)
timeRangesWithZone:timeRanges
array of [ timeFrom, timeTo, weekdayFrom, weekdayTo]
It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges.
These settings will take action on Sat and Sun from 00:00 to 23:59:59,
targetReplicas
[n] : n - number of replicas to scale.
These is mandatory field when the action is scale
Default value is [].
fieldSelector
- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now())
These value will take a list of methods to select the resources on which we perform specified action .
Please configure Global Configurations before moving ahead with App Configuration
Parts of Documentation
In this section, we will provide information on the Build Configuration.
Build configuration is used to create and push docker images in the container registry of your application. You will provide all the docker related information to build and push docker images on the Build Configuration page.
Only one docker image can be created for multi-git repository applications as explained in the Git Repository section.
For build configuration, you must provide information in the sections as given below:
The following fields are provided on the Store Container Image section:
If you are using docker hub account, you need to enter the repository name along with your username. For example - If my username is kartik579 and repo name is devtron-trial, then enter kartik579/devtron-trial instead of only devtron-trial.
In order to deploy the application, we must build the container images to configure a fully operational container environment.
You can choose one of the following options to build your container image:
I have a Dockerfile
Create Dockerfile
Build without Dockerfile
A Dockerfile is a text document that contains all the commands which you can call on the command line to build an image.
With the option Create Dockerfile, you can create a Dockerfile from the available templates. You can edit any selected Dockerfile template as per your build configuration requirements.
With the option Build without Dockerfile, you can use Buildpacks to automatically build the image for your preferred language and framework.
You can add Key/Value pair by clicking Add argument.
Note This fields are optional. If required, it can be overridden at CI step.
Using this option, you can build images for a specific or multiple architectures and operating systems (target platforms). You can select the target platform from the drop-down list or can type to select a customized target platform.
Before selecting a customized target platform, please ensure that the architecture and the operating system are supported by the registry type you are using, otherwise build will fail. Devtron uses BuildX to build images for multiple target Platforms, which requires higher CI worker resources. To allocate more resources, you can increase value of the following parameters in the devtron-cm configmap in devtroncd namespace.
LIMIT_CI_CPU
REQ_CI_CPU
REQ_CI_MEM
LIMIT_CI_MEM
To edit the devtron-cm configmap in devtroncd namespace:
If target platform is not set, Devtron will build image for architecture and operating system of the k8s node on which CI is running.
The Target Platform feature might not work in minikube & microk8s clusters as of now.
It is is a collapsed view including the following parameters:
Key
Value
These fields will contain the key parameter and the value for the specified key for your docker build. This field is Optional. If required, this can be overridden at CI step.
Click Save Configuration.
A deployment configuration is a manifest of the application. It defines the runtime behavior of the application. You can select one of the default deployment charts or custom deployment charts which are created by super admin.
To configure a deployment chart for your application, do the following steps:
Go to Applications and create a new application.
Go to App Configuration page and configure your application.
On the Base Deployment Template page, select the drop-down under Chart type.
You can select a default deployment chart from the following options:
Deployment (Recommended)
Custom charts are added by users with super admin permission from the Custom charts section.
You can select the available custom charts from the drop-down list. You can also view the description of the custom charts in the list.
A custom chart can be uploaded by a super admin.
Enable show application metrics toggle to view the application metrics on the App Details page.
IMPORTANT: Enabling Application metrics introduces a sidecar container to your main container which may require some additional configuration adjustments. We recommend you to do load test after enabling it in a non-production environment before enabling it in production environment.
Select Save & Next to save your configurations.
Super-admins can lock keys in base deployment template to prevent non-super-admins from modifying those locked keys. Refer Lock Deployment Configuration to know more.
This chart deploys Job & CronJob. A Job is a controller object that represents a finite task and CronJob is used to schedule the creation of Jobs.
A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created. Suspeding a Job will delete its active Pods until the Job is resumed again.
| Key | Description |
|---|---|
A CronJob creates jobs on a repeating schedule. One Cronjob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule, written in Cron format. CronJobs are meant for performing regular scheduled actions such as backups, report generation, and so on. Each task must be configured to recur indefinitely (as an example: once a day / week / month). You can schedule the time within that interval when the job should start.
Super-admins can lock keys in Job & CronJob deployment template to prevent non-super-admins from modifying those locked keys. Refer Lock Deployment Configuration to know more.
This chart creates a deployment that runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. It does not support Blue/Green and Canary deployments.
This is the default deployment chart. You can select Deployment chart when you want to use only basic use cases which contain the following:
Create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
Declare the new state of the Pods. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
Rollback to an earlier Deployment revision if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
Scale up the Deployment to facilitate more load.
Use the status of the Deployment as an indicator that a rollout has stuck.
Clean up older ReplicaSets that you do not need anymore.
You can define application behavior by providing information in the following sections:
| Key | Descriptions |
|---|---|
Super-admins can lock keys in deployment template to prevent non-super-admins from modifying those locked keys. Refer Lock Deployment Configuration to know more.
This defines ports on which application services will be exposed to other services
To set environment variables for the containers that run in the Pod.
To set environment variables for the containers and fetching their values from pod-level fields.
If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count. The default value of "MaxSurge: " is 25%.
This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
You can create PodDisruptionBudget for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, an application would like to ensure the number of replicas running is never brought below the certain number.
or
You can specify either maxUnavailable or minAvailable in a PodDisruptionBudget and it can be expressed as integers or as a percentage.
You can create ambassador mappings to access your applications from outside the cluster. At its core a Mapping resource maps a resource to a service.
This is connected to HPA and controls scaling up and down in response to request load.
You can use flagger for canary releases with deployment objects. It supports flexible traffic routing with istio service mesh as well.
fullnameOverride replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses {app-name}-{environment-name} as release fullname.
Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
imagePullSecrets contains the docker credentials that are used for accessing a registry.
regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/ .
the hostAliases field is used in a Pod specification to associate additional hostnames with the Pod's IP address. This can be helpful in scenarios where you need to resolve specific hostnames to the Pod's IP within the Pod itself.
This allows public access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
Legacy deployment-template ingress format
This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to true.
To wait for given period of time before switch active the container.
These define minimum and maximum RAM and CPU available to the application.
Resources are required to set CPU and memory usage.
Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
Requests are what the container is guaranteed to get.
This defines annotations and the type of service, optionally can define name also.
It is required when some values need to be read from or written to an external disk.
It is used to provide mounts to the volume.
Spec is used to define the desire state of the given container.
Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
Taints are the opposite, they allow a node to repel a set of pods.
A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
This is used to give arguments to command.
It contains the commands for the server.
Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to true.
Container lifecycle hooks are mechanisms that allow users to define custom actions to be performed at specific stages of a container's lifecycle i.e. PostStart or PreStop.
It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case. It describes the state of the Prometheus.
Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the GracePeriod.
A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
It is used for providing server configurations.
It gives the details for deployment.
It gives the set of targets to be monitored.
It is used to configure database migration.
These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
KEDA is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
Example for autosccaling with KEDA using Prometheus metrics is given below:
Example for autosccaling with KEDA based on kafka is given below :
Kubernetes NetworkPolicies control pod communication by defining rules for incoming and outgoing traffic.
Winter Soldier can be used to
cleans up (delete) Kubernetes resources
reduce workload pods to 0
NOTE: After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check the main repo
Given below is template values you can give in winter-soldier:
here is an example,
Above settings will take action on Sat and Sun from 00:00 to 23:59:59, and on Mon-Fri from 00:00 to 08:00 and 20:00 to 23:59:59. If action:sleep then runs hibernate at timeFrom and unhibernate at timeTo. If action: delete then it will delete workloads at timeFrom and timeTo. Here the action:scale thus it scale the number of resource replicas to targetReplicas: [1,1,1]. Here each element of targetReplicas array is mapped with the corresponding elements of array timeRangesWithZone/timeRanges. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')
AddTime - This can be used to add time. For eg AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h') ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
Now - This can be used to get current time.
CpuToNumber - This can be used to compare CPU. For eg any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')}) will check if any resource.requests is less than 60Mi.
A security context defines privilege and access control settings for a Pod or Container.
To add a security context for main container:
To add a security context on pod level:
You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
It gives the realtime metrics of the deployed applications
If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
Once all the Deployment template configurations are done, click on Save to save your deployment configuration. Now you are ready to create Workflow to do CI/CD.
Helm Chart json schema is used to validate the deployment template values.
The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
Within the same application, you can override a container registry, container image and target platform during the build pipeline, which means the images built for non-production environment can be included to the non-production registry and the images for production environment can be included to the production registry.
To override a container registry, container image or target platform:
Go to Applications and select your application from the Devtron Apps tabs.
On the App Configuration tab, select Workflow Editor.
Open the build pipeline of your application.
Click Allow Override to:
Select the new container registry from the drop-down list.
Or, create and build the new container image with different options.
Or, set a new target platform from the drop-down list or enter a new target platform.
Click Update Pipeline.
The overridden container registry/container image location/target platform will be reflected on the Build Configuration page. You can also see the number of build pipelines for which the container registry/container image location/target platform is overridden.
The CI pipeline includes Pre and Post-build steps to validate and introduce checkpoints in the build process. The pre/post plugins allow you to execute some standard tasks, such as Code analysis, Load testing, Security scanning etc. You can build custom pre-build/post-build tasks or select one of the standard preset plugins provided by Devtron.
Preset plugin is an API resource which you can add within the CI build environment. By integrating the preset plugin in your application, it helps your development cycle to keep track of finding bugs, code duplication, code complexity, load testing, security scanning etc. You can analyze your code easily.
Devtron CI pipeline includes the following build stages:
Pre-Build Stage: The tasks in this stage run before the image is built.
Build Stage: In this stage, the build is triggered from the source code (container image) that you provide.
Post-Build Stage: The tasks in this stage are triggered once the build is complete.
Make sure you have CI build pipeline before you start configuring Pre-Build or Post-Build tasks.
Each Pre/Post-build stage is executed as a series of events called tasks and includes custom scripts. You can create one or more tasks that are dependent on one another for execution. In other words, the output variable of one task can be used as an input for the next task to build a CI runner. The tasks will run following the execution order.
The tasks can be re-arranged by drag-and-drop; however, the order of passing the variables must be followed.
You can create a task either by selecting one of the available preset plugins or by creating a custom script.
| Stage | Task |
|---|---|
Lets take Codacy as an example and configure it in the Pre-Build stage in the CI pipeline for finding bugs, detecting dependency vulnerabilities, and enforcing code standards.
Go to the Applications and select your application from the Devtron Apps tabs.
Go to the App Configuration tab, click Workflow Editor.
Select the build pipeline for configuring the pre/post-build tasks.
On the Edit build pipeline, in the Pre-Build Stage, click + Add task.
Select Codacy from PRESET PLUGINS.
Enter a relevant name or codacy in the Task name field. It is a mandatory field.
Enter a descriptive message for the task in the Description field. It is an optional field.
Note: The description is available by default.
In the Input Variables, provide the information in the following fields:
In Trigger/Skip Condition, set the trigger conditions to execute a task or Set skip conditions. As an example: CodacyEndpoint equal to https://app.codacy.com.
Note: You can set more than one condition.
In Pass/Failure Condition set the conditions to execute pass or fail of your build. As an example: Pass if number of issues equal to zero.
Note: You can set more than one condition.
Click Update Pipeline.
Go to the Build & Deploy, click the build pipeline and start your build.
Click Details on the build pipeline and you can view the details on the Logs.
On the Edit build pipeline screen, select the Pre-build stage.
Select + Add task.
Select Execute custom script.
The task type of the custom script may be a Shell or a Container image.
Select the Task type as Shell.
Consider an example that creates a Shell task to stop the build if the database name is not "mysql". The script takes 2 input variables, one is a global variable (DOCKER_IMAGE), and the other is a custom variable (DB_NAME) with a value "mysql". The task triggers only if the database name matches "mysql". If the trigger condition fails, this Pre-build task will be skipped and the build process will start. The variable DB_NAME is declared as an output variable that will be available as an input variable for the next task. The task fails if DB_NAME is not equal to "mysql".
Select Update Pipeline.
Here is a screenshot with the failure message from the task:
Select the Task type as Container image.
This example creates a Pre-build task from a container image. The output variable from the previous task is available as an input variable.
Select Update Pipeline.
Go to Preset Plugins section to know more about the available plugins
Trigger the CI pipeline
Workflow is a logical sequence of different stages used for continuous integration and continuous deployment of an application.
Click on New Build Pipeline to create a new workflow
On clicking New Build Pipeline, three options appear as mentioned below:
Continuous Integration: Choose this option if you want Devtron to build the image of source code.
Linked CI Pipeline: Choose this option if you want to use an image created by an existing CI pipeline in Devtron.
Incoming Webhook: Choose this if you want to build your image outside Devtron, it will receive a docker image from an external source via the incoming webhook.
Then, create CI/CD Pipelines for your application.
To know how to create the CI pipeline for your application, click on: Create CI Pipelines
To know how to create the CD pipeline for your application, click on: Create CD Pipelines
The StatefulSet chart in Devtron allows you to deploy and manage stateful applications. StatefulSet is a Kubernetes resource that provides guarantees about the ordering and uniqueness of Pods during deployment and scaling.
It supports only ONDELETE and ROLLINGUPDATE deployment strategy.
You can select StatefulSet chart when you want to use only basic use cases which contain the following:
Managing Stateful Applications: StatefulSets are ideal for managing stateful applications, such as databases or distributed systems, that require stable network identities and persistent storage for each Pod.
Ordered Pod Management: StatefulSets ensure ordered and predictable management of Pods by providing each Pod with a unique and stable hostname based on a defined naming convention and ordinal index.
Updating and Scaling Stateful Applications: StatefulSets support updating and scaling stateful applications by creating new versions of the StatefulSet and performing rolling updates or scaling operations in a controlled manner, ensuring minimal disruption to the application.
Persistent Storage: StatefulSets have built-in mechanisms for handling persistent volumes, allowing each Pod to have its own unique volume claim and storage. This ensures data persistence even when Pods are rescheduled or restarted.
Maintaining Pod Identity: StatefulSets guarantee consistent identity for each Pod throughout its lifecycle. This stability is maintained even if the Pods are rescheduled, allowing applications to rely on stable network identities.
Rollback Capability: StatefulSets provide the ability to rollback to a previous version in case the current state of the application is unstable or encounters issues, ensuring a known working state for the application.
Status Monitoring: StatefulSets offer status information that can be used to monitor the deployment, including the current version, number of replicas, and the readiness of each Pod. This helps in tracking the health and progress of the StatefulSet deployment.
Resource Cleanup: StatefulSets allow for easy cleanup of older versions by deleting StatefulSets and their associated Pods and persistent volumes that are no longer needed, ensuring efficient resource utilization.
Super-admins can lock keys in StatefulSet deployment template to prevent non-super-admins from modifying those locked keys. Refer Lock Deployment Configuration to know more.
This defines ports on which application services will be exposed to other services
It is used to get the name of Environment Variable name, Secret name and the Key name from which we are using the value in that corresponding Environment Variable.
It is used to get the name of Environment Variable name, Config Map name and the Key name from which we are using the value in that corresponding Environment Variable.
To set environment variables for the containers that run in the Pod.
These are all the configuration settings for the StatefulSet.
Mandatoryfields in statefulSetConfig is
Here is an explanation of each field in the statefulSetConfig :
volumeClaimTemplates: An array of volume claim templates that are used to create persistent volumes for the StatefulSet. Each volume claim template specifies the storage class, access mode, storage size, and other details of the persistent volume.
If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count. The default value of "MaxSurge: " is 25%.
This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
You can create ambassador mappings to access your applications from outside the cluster. At its core a Mapping resource maps a resource to a service.
This is connected to HPA and controls scaling up and down in response to request load.
fullnameOverride replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses {app-name}-{environment-name} as release fullname.
Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
imagePullSecrets contains the docker credentials that are used for accessing a registry.
regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/ .
This allows public access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
Legacy deployment-template ingress format
This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to true.
Istio is a service mesh which simplifies observability, traffic management, security and much more with it's virtual services and gateways.
To wait for given period of time before switch active the container.
These define minimum and maximum RAM and CPU available to the application.
Resources are required to set CPU and memory usage.
Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
Requests are what the container is guaranteed to get.
This defines annotations and the type of service, optionally can define name also.
It is required when some values need to be read from or written to an external disk.
It is used to provide mounts to the volume.
Spec is used to define the desire state of the given container.
Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
Taints are the opposite, they allow a node to repel a set of pods.
A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
This is used to give arguments to command.
It contains the commands for the server.
Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to true.
It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case.It describes the state of the prometheus.
Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the GracePeriod.
A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
It is used for providing server configurations.
It gives the details for deployment.
It gives the set of targets to be monitored.
It is used to configure database migration.
KEDA is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
Example for autosccaling with KEDA using Prometheus metrics is given below:
Example for autosccaling with KEDA based on kafka is given below :
Winter Soldier can be used to
cleans up (delete) Kubernetes resources
reduce workload pods to 0
NOTE: After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check the main repo
Given below is template values you can give in winter-soldier:
Here,
here is an example,
Above settings will take action on Sat and Sun from 00:00 to 23:59:59, and on Mon-Fri from 00:00 to 08:00 and 20:00 to 23:59:59. If action:sleep then runs hibernate at timeFrom and unhibernate at timeTo. If action: delete then it will delete workloads at timeFrom and timeTo. Here the action:scale thus it scale the number of resource replicas to targetReplicas: [1,1,1]. Here each element of targetReplicas array is mapped with the corresponding elements of array timeRangesWithZone/timeRanges. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')
AddTime - This can be used to add time. For eg AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h') ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
Now - This can be used to get current time.
CpuToNumber - This can be used to compare CPU. For eg any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')}) will check if any resource.requests is less than 60Mi.
A security context defines privilege and access control settings for a Pod or Container.
To add a security context for main container:
To add a security context on pod level:
You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
It gives the realtime metrics of the deployed applications
If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
Once all the Deployment template configurations are done, click on Save to save your deployment configuration. Now you are ready to create Workflow to do CI/CD.
Helm Chart json schema is used to validate the deployment template values.
The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
The 'GitOps Configuration' page appears only if the super-admin has enabled 'Allow changing git repository for application' in Global Configurations → GitOps.
This configuration is an extension of the GitOps settings present in Global Configurations of Devtron. Therefore, make sure you read it before making any changes to your app configuration.
The application-level GitOps configuration offers the flexibility to add a custom Git repo (as opposed to Devtron auto-creating a repo for your application).
Users need to have Admin permission or above (along with access to the environment and application) to configure user-defined Git repo.
Go to Applications → Devtron Apps (tab) → (choose your app) → App Configuration (tab) → GitOps Configuration.
Assuming a GitOps repo was not added to your application earlier, you get 2 options:
Auto-create repository - Select this option if you wish to proceed with the default behavior. It will create a repository automatically, named after your application with a prefix. Thus saving you the trouble of creating one manually.
Commit manifests to a desired repository - Select this option if you wish to add a custom repo that is already created with your Git provider. Enter its link in the Git Repo URL field.
GitOps repositories, whether auto-created by Devtron or added manually, are immutable. This means they cannot be modified after creation. The same is true if you have an existing CD pipeline that uses/used GitOps for deployment.
Click Save.
Note: In case you skipped the GitOps configuration for your application and proceeded towards the creation of a new CD pipeline(that uses GitOps), you will be prompted to configure GitOps as shown below:
You can deploy a helm chart using either Helm or GitOps. Let's assume you wish to deploy airflow chart.
Select the helm chart from the Chart Store.
Click Configure & Deploy.
After you enter the App Name, Project, and Environment; an option to choose the deployment approach (i.e., Helm or GitOps) would appear.
Select GitOps.
A modal window will appear for you to enter a Git repository. Just like Devtron Apps (step 2), you get two options:
Auto-create repository
Commit manifests to a desired repository
Enter your custom Git Repo URL, and click Save.
Next, you may proceed to deploy the chart.
Once you deploy a helm app with GitOps, you cannot change its GitOps repo.
To add secrets from AWS Secrets Manager, we need to create a generic Kubernetes secret for AWS authentication.
Create a Kubernetes secret in the namespace in which the application is to be deployed using base64 encoded AWS access-key and secret-access-key. You can use a Devtron generic chart for it.
Note: You don't have to create the Kubernetes secret every time you create external secret for the respective namespace.
After creating the generic secret, navigate to Secrets section of the application and follow the steps mentioned below :
1. Click Add Secret to add a new secret
2. Select AWS Secret Manager under External Secret Operator (ESO) from the dropdown of Data type
3. Configure the secret
4. Save the secret
ClusterSecretStore provides a secure and centralized storage solution for managing and accessing sensitive information, such as passwords, API keys, certificates, and other credentials, within a cluster or application environment.
Requirement: Devtron deployment template chart version should be 4.17 and above.
To setup ESO AWS secrets manager with Devtron using ClusterSecretsStore, follow the mentined steps:
1. Create a secret for AWS authentication
Create a Kubernetes secret in any namespace using base64 encoded AWS access-key and secret-access-key. You can use the devtron generic chart for this.
2. Create a ClusterSecretStore
Create a ClusterSecretStore using the secret created for AWS authentication in step 1.
3. Create a secret in the application using ESO AWS Secrets Manager
Go to the application where you want to create an external secret. Navigate to secrets section under application configuration and create a secret using ESO AWS Secrets Manager.
For Devtron version older than v0.4.0, please refer the CI Pipeline (legacy) page.
A CI Workflow can be created in one of the following ways:
Sync with Environment
Create a Job
Each method has different use-cases that can be tailored according the needs of the organization.
Build and Deploy from Source Code workflow allows you to build the container image from a source code repository.
From the Applications menu, select your application.
On the App Configuration page, select Workflow Editor.
Select + New Workflow.
Select Build and Deploy from Source Code.
Enter the following fields on the Create build pipeline window:
The Advanced CI Pipeline includes the following stages:
Pre-build stage: The tasks in this stage are executed before the image is built.
Build stage: In this stage, the build is triggered from the source code that you provide.
Post-build stage: The tasks in this stage will be triggered once the build is complete.
The Pre-build and Post-build stages allow you to create Pre/Post-Build CI tasks as explained here.
Go to the Build stage tab.
Source type
Branch Fixed
This allows you to trigger a CI build whenever there is a code change on the specified branch.
Enter the Branch Name of your code repository.
Branch Regex
Branch Regex allows users to easily switch between branches matching the configured Regex before triggering the build pipeline. In case of Branch Fixed, users cannot change the branch name in ci-pipeline unless they have admin access for the app. So, if users with Build and Deploy access should be allowed to switch branch name before triggering ci-pipeline, Branch Regex should be selected as source type by a user with Admin access.
For example if the user sets the Branch Regex as feature-*, then users can trigger from branches such as feature-1450, feature-hot-fix etc.
Pull Request
This allows you to trigger the CI build when a pull request is created in your repository.
Prerequisites
Configure the webhook for either GitHub or Bitbucket.
The Pull Request source type feature only works for the host GitHub or Bitbucket Cloud for now. To request support for a different Git host, please create a GitHub issue here.
To trigger the build from specific PRs, you can filter the PRs based on the following keys:
Select the appropriate filter and pass the matching condition as a regular expression (regex).
Devtron uses regexp library, view regexp cheatsheet. You can test your custom regex from here.
Select Create Pipeline.
Tag Creation
This allows you to trigger the CI build whenever a new tag is created.
Prerequisites
Configure the webhook for either GitHub or Bitbucket.
To trigger the build from specific tags, you can filter the tags based on the author and/or the tag name.
Select the appropriate filter and pass the matching condition as a regular expression (regex).
Select Create Pipeline.
The total timeout for the execution of the CI pipeline is by default set as 3600 seconds. This default timeout is configurable according to the use case (refer Build Infra).
Scan for Vulnerabilities
To perform the security scan after the container image is built, enable the Scan for vulnerabilities toggle in the build stage. Refer Security features to know more.
Custom Image Tag Pattern
This feature helps you apply custom tags (e.g., v1.0.0) to readily distinguish container images within your repository.
Enable the toggle button as shown below.
You can write an alphanumeric pattern for your image tag, e.g., test-v1.0.{x}. Here, 'x' is a mandatory variable whose value will incrementally increase with every build. You can also define the value of 'x' for the next build trigger in case you want to change it.
Click Update Pipeline.
Now, go to Build & Deploy tab of your application, and click Select Material in the CI pipeline.
Choose the git commit you wish to use for building the container image. Click Start Build.
The build will initiate and once it is successful the image tag would reflect at all relevant screens:
Build History
Docker Registry
CD Pipeline (Image Selection)
Build will fail if the resulting image tag has already been built in the past. This means if there is an existing image with tag test-v1.0.0, you cannot build another image having the same tag test-v1.0.0 in the same CI pipeline. This error might occur when you reset the value of the variable x or when you disable/enable the toggle button for Custom image tag pattern.
If one code is shared across multiple applications, Linked Build Pipeline can be used, and only one image will be built for multiple applications because if there is only one build, it is not advisable to create multiple CI Pipelines.
From the Applications menu, select your application.
On the App Configuration page, select Workflow Editor.
Select + New Workflow.
Select Linked Build Pipeline.
On the Create linked build pipeline screen:
Search for the application in which the source CI pipeline is present.
Select the source CI pipeline from the application that you selected above.
Enter a new name for the linked CI pipeline.
Click Create Linked CI Pipeline.
Thereafter, the source CI pipeline will indicate the number of Linked CI pipelines. Upon clicking it, it will display the child information as shown below. It reveals the applications and environments where Linked CI is used for deployment.
After creating a linked CI pipeline, you can create a CD pipeline.
Linked CI pipelines can't trigger builds. They rely on the source CI pipeline to build images. Trigger a build in the source CI pipeline to see the images available for deployment in the linked CI pipeline's CD stage.
For CI pipeline, you can receive container images from an external services via webhook API.
You can use Devtron for deployments on Kubernetes while using an external CI tool such as Jenkins or CircleCI. External CI feature can be used when the CI tool is hosted outside the Devtron platform. However, by using an external CI, you will not be able to use some of the Devtron features such as Image scanning and security policies, configuring pre-post CI stages etc.
To configure Git Repository, you can add any Git repository account (e.g., dummy account) and click Next.
To configure the Container Registry and Container Repository, you can leave the fields blank or simply add any test repository and click Save & Next.
On the Base Deployment Template page, select the Chart type from the drop-down list and configure as per your requirements and click Save & Next.
On the Workflow Editor page, click New Workflow and select Deploy image from external service.
On the Deploy image from external source page, provide the information in the following fields:
Click Create Pipeline. A new CI pipeline will be created for the external source. To get the webhook URL and JSON sample payload to be used in external CI pipeline, click Show webhook details.
On the Webhook Details page, you have to authenticate via API token to allow requests from an external service (e.g. Jenkins or CircleCI).
For authentication, only users with super-admin permissions can select or generate an API token:
You can either use Select API Token if you have generated an API Token under Global Configurations.
Or use Auto-generate token to generate the API token with the required permissions. Make sure to enter the token name in the Token name field.
To allow requests from the external source, you can request the API by using:
Webhook URL
cURL Request
HTTP Method: POST
API Endpoint: https://{domain-name}/orchestrator/webhook/ext-ci/{pipeline-id}
JSON Payload:
You can also select metadata to send to Devtron. Sample JSON will be generated accordingly. You can send the Payload script to your CI tools such as Jenkins and Devtron will receive the build image every time the CI pipeline is triggered or you can use the Webhook URL, which will build an image every time CI pipeline is triggered using Devtron Dashboard.
On the Jenkins dashboard, select the Jenkins job which you want to integrate with the Devtron dashboard.
Go to the Configuration > Build Steps, click Add build step, and then click Execute Shell.
Enter the cURL request command.
Make sure to enter the API token and dockerImage in your cURL command and click Save.
Now, you can access the images on the Devtron dashboard and deploy manually. In case, if you select Automatic deployment option, then your application will be deployed automatically everytime a new image is received.
Similarly, you can also integrate with external source such as CircleCI by:
Select the job on the CircleCI dashboard and click Configuration File.
On the respective job, enter the cURL command and update the API token and dockerImage in your cURL command.
You can update the configurations of an existing CI Pipeline except for the pipeline's name. To update a pipeline, select your CI pipeline. In the Edit build pipeline window, edit the required stages and select Update Pipeline.
You can only delete a CI pipeline if there is no CD pipeline created in your workflow.
To delete a CI pipeline, go to App Configurations > Workflow Editor and select Delete Pipeline.
If you choose Pull Request or Tag Creation as the source type, you must first configure the Webhook for GitHub/Bitbucket as a prerequisite step.
Go to the Settings page of your repository and select Webhooks.
Select Add webhook.
In the Payload URL field, enter the Webhook URL that you get on selecting the source type as "Pull Request" or "Tag Creation" in Devtron the dashboard.
Change the Content-type to application/json.
In the Secret field, enter the secret from Devtron the dashboard when you select the source type as "Pull Request" or "Tag Creation".
Under Which events would you like to trigger this webhook?, select Let me select individual events. to trigger the webhook to build CI Pipeline.
Select Branch or tag creation and Pull Requests.
Select Add webhook.
Go to the Repository settings page of your Bitbucket repository.
Select Webhooks and then select Add webhook.
Enter a Title for the webhook.
In the URL field, enter the Webhook URL that you get on selecting the source type as "Pull Request" or "Tag Creation" in the Devtron dashboard.
Select the event triggers for which you want to trigger the webhook.
Select Save to save your configurations.
Secrets and configmaps both are used to store environment variables but there is one major difference between them: Configmap stores key-values in normal text format while secrets store them in base64 encrypted form. Devtron hides the data of secrets for the normal users and it is only visible to the users having edit permission.
Secret objects let you store and manage sensitive information, such as passwords, authentication tokens, and ssh keys. Embedding this information in secrets is safer and more flexible than putting it verbatim in a Pod definition or in a container image.
Click Add Secret to add a new secret.
Specify the volume mount folder path in Volume Mount Path, a path where the data volume needs to be mounted. This volume will be accessible to the containers running in a pod.
For multiple files mount at the same location you need to check sub path bool field, it will use the file name (key) as sub path. Sub Path feature is not applicable in case of external configmap except AWS Secret Manager, AWS System Manager and Hashi Corp Vault, for these cases Name (Secret key) as sub path will be picked up automatically.
File permission will be provide at the configmap level not on the each key of the configmap. it will take 3 digit standard permission for the file.
Click Save Secret to save the secret.
You can see the Secret is added.
You can update your secrets anytime later, but you cannot change the name of your secrets. If you want to change your name of secrets then you have to create a new secret.
To update secrets, click the secret you wish to update.
Click Update Secret to update your secret.
You can delete your secret. Click your secret and click the delete sign to delete your secret.
There are five Data types that you can use to save your secret.
Kubernetes Secret: The secret that you create using Devtron.
Kubernetes External Secret: The secret data of your application is fetched by Devtron externally. Then the Kubernetes External Secret is converted to Kubernetes Secret.
AWS Secret Manager: The secret data of your application is fetched from AWS Secret Manager and then converted to Kubernetes Secret from AWS Secret.
AWS System Manager: The secret data for your application is fetched from AWS System Secret Manager and all the secrets stored in AWS System Manager are converted to Kubernetes Secret.
HashiCorp Vault: The secret data for your application is fetched from HashiCorp Vault and the secrets stored in HashiCorp Vault are converted to Kubernetes Secret.
Note: The conversion of secrets from various data types to Kubernetes Secrets is done within Devtron and irrespective of the data type, after conversion, the Pods access secrets normally.
Use this option to mount an existing Kubernetes Secret in your application pods. A Secret will not be created by system so please ensure that the secret already exist within the namespace else the deployment will fail.
The secret that is already created and stored in the environment and being used by Devtron externally is referred here as Kubernetes External Secret. For this option, Devtron will not create any secret by itself but they can be used within the pods. Before adding secret from kubernetes external secret, please make sure that secret with the same name is present in the environment. To add secret from kubernetes external secret, follow the steps mentioned below:
Navigate to Secrets of the application.
Click Add Secret to add a new secret.
Select Kubernetes External Secret from dropdown of Data type.
Provide a name to your secret. Devtron will search secret in the environment with the same name that you mention here.
Before adding any external secrets on Devtron, kubernetes-external-secrets must be installed on the target cluster. Kubernetes External Secrets allows you to use external secret management systems (e.g., AWS Secrets Manager, Hashicorp Vault, etc) to securely add secrets in Kubernetes.
To install the chart with the release named my-release:
To install the chart with AWS IAM Roles for Service Accounts:
To add secrets from AWS secret manager, navigate to Secrets of the application and follow the steps mentioned below :
Click Add Secret to add a new secret.
Select AWS Secret Manager from dropdown of Data type.
Provide a name to your secret.
Select how you want to use the secret. You may leave it selected as environment variable and also you may leave Role ARN empty.
In Data section, you will have to provide data in key-value format.
All the required field to pass your data to fetch secrets on Devtron are described below :
To add secrets in AWS secret manager, do the following steps :
Go to AWS secret manager console.
Click Store a new secret.
Add and save your secret.
To add secrets from Google Secrets Manager, follow the steps mentioned below :
1. Go to Google cloud console and create a Service Account.
2. Assign roles to the service account.
3. Add and create a new key.
5. Create a Kubernetes secret in the namespace in which the application is to be deployed using base64 encoded service account key.
You can use devtron generic chart for this.
6. After creating the generic secret, navigate to Secrets section of the application and click Add Secret to add a new secret.
7. Select Google Secrets Manager under External Secret Operator (ESO) from the dropdown of Data type.
8. Configure secret:
9. Save secret.
Prerequisites: Chart version should be > 4.14.0
External Secrets Operator is a Kubernetes operator that integrates external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret.
Before creating any external secrets on Devtron, External Secret Operator must be installed on the target cluster. External Secret Operator allows you to use external secret management systems (e.g., AWS Secrets Manager, Hashicorp Vault, Azure Secrets Manager, Google Secrets Manager etc.) to securely inject secrets in Kubernetes.
You can install External Secrets Operator using charts store:
Go to charts store.
Search chart with name external-secrets.
Deploy the chart.
CI Pipeline can be created in three different ways, , and .
Each of these methods have different use-cases which can be used according to the needs of the organization. Let’s begin with Continuous Integration.
Click on Continuous Integration, a prompt comes up in which we need to provide our custom configurations. Below is the description of some configurations which are required.
[Note] Options such as pipeline execution, stages and scan for vulnerabilities, will be visible after clicking on advanced options present in the bottom left corner.
Pipeline name is an auto-generated name which can also be renamed by clicking on Advanced options.
You can select the method you want to execute the pipeline. By default the value is automatic. In this case it will get automatically triggered if any changes are made to the respective git repository. You can set it to manual if you want to trigger the pipeline manually.
In source type, we can observe that we have three types of mechanisms which can be used for building your CI Pipeline. In the drop-down you can observe we have Branch Fixed, Pull Request and Tag Creation.
If you select the Branch Fixed as your source type for building CI Pipeline, then you need to provide the corresponding Branch Name.
Branch Name is the name of the corresponding branch (eg. main or master, or any other branch)
If you select the Pull Request option, you can configure the CI Pipeline using the generated PR. For this mechanism you need to configure a webhook for the repository added in the Git Material.
Prerequisites for Pull Request
If using GitHub - To use this mechanism, as stated above you need to create a webhook for the corresponding repository of your Git Provider. In Github to create a webhook for the repository -
Go to settings of that particular repository
Click on webhook section under options tab
In the Payload URL section, please copy paste the Webhook URL which can be found at Devtron Dashboard when you select source type as Pull Request as seen in above image.
Change content type to - application/json
Copy paste the Secret as well from the Dashboard when you select the source type as Pull Request
Now, scroll down and select the custom events for which you want to trigger the webhook to build CI Pipeline -
Check the radio button for Let me select individual events
Then, check the Branch or Tag Creation and Pull Request radio buttons under the individual events as mentioned in image below.
[Note] If you select Branch or Tag Creation, it will work for the Tag Creation mechanism as well.
After selecting the respective options, click on the generate the webhook button to create a webhook for your respective repository.
If using Bitbucket Cloud - If you are using Bitbucket cloud as your git provider, you need to create a webhook for that as we created for Github in the above section. Follow the steps to create webhook -
Go to Repository Settings on left sidebar of repository window
Click on Webhooks and then click on Add webhook as shown in the image.
Give any appropriate title as per your choice and then copy-paste the url which you can get from Devtron Dashboard when you select Pull Request as source type in case of Bitbucket Cloud as Git Host.
Check the Pull Request events for which you want to trigger the webhook and then save the configurations.
Filters
Now, coming back to the Pull Request mechanism, you can observe we have the option to add filters. In a single repository we have multiple PRs generated, so to have the exact PR for which you want to build the CI Pipeline, we have this feature of filters.
You can add a few filters which can be seen in the dropdown to sort the exact PR which you want to use for building the pipeline.
Below are the details of different filters which you can use as per your requirement. Please select any of the filters and pass the value in regex format as one has already given for example and then click on Create Pipeline.
The third option i.e, Tag Creation. In this mechanism you need to provide the tag name or author to specify the exact tag for which you want to build the CI Pipeline. To work with this feature as well, you need to configure the webhook for either Github or Bitbucket as we did in the previous mechanism i.e, Pull Request.
In this process as well you can find the option to filter the specific tags with certain filter parameters. Select the appropriate filter as per your requirement and pass the value in form of regex, one of the examples is already given.
Select the appropriate filter and pass the value in the form of regex and then click on Create Pipeline.
When you click on the advanced options button which can be seen at the bottom-left of the screen, you can see some more configuration options which includes pipeline execution, stages and scan for vulnerabilities.
There are 3 dropdowns given below:
Pre-build
Docker build
Post-build
(a) Pre-build
This section is used for those steps which you want to execute before building the Docker image. To add a Pre-build stage, click on Add Stage and provide a name to your pre-stage and write your script as per your requirement. These stages will run in sequence before the docker image is built. Optionally, you can also provide the path of the directory where the output of the script will be stored locally.
You can add one or more than one stage in a CI Pipeline.
(b) Docker build
Though we have the option available in the Docker build configuration section to add arguments in key-value pairs for the docker build image. But one can also provide docker build arguments here as well. This is useful, in case you want to override them or want to add new arguments to build your docker image.
(c) Post-build
The post-build stage is similar to the pre-build stage. The difference between the post-build stage and the pre-build stage is that the post-build will run when your CI pipeline will be executed successfully.
Adding a post-build stage is similar to adding a pre-build stage. Click on Add Stage and provide a name to your post-stage. Here you can write your script as per your requirement, which will run in sequence after the docker image is built. You can also provide the path of the directory in which the output of the script will be stored in the Remote Directory column. And this is optional to fill because many times you run scripts that do not provide any output.
NOTE:
(a) You can provide pre-build and post-build stages via the Devtron tool’s console or can also provide these details by creating a file devtron-ci.yaml inside your repository. There is a pre-defined format to write this file. And we will run these stages using this YAML file. You can also provide some stages on the Devtron tool’s console and some stages in the devtron-ci.yaml file. But stages defined through the Devtron dashboard are first executed then the stages defined in the devtron-ci.yaml file.
(b) The total timeout for the execution of the CI pipeline is by default set as 3600 seconds. This default timeout is configurable according to the use-case. The timeout can be edited in the configmap of the orchestrator service in the env variable env:"DEFAULT_TIMEOUT" envDefault:"3600"
Scan for vulnerabilities adds a security feature to your application. If you enable this option, your code will be scanned for any vulnerabilities present in your code. And you will be informed about these vulnerabilities. For more details please check doc
You have provided all the details required to create a CI pipeline, now click on Create Pipeline.
You can also update any configuration of an already created CI Pipeline, except the pipeline name. The pipeline name can not be edited.
Click on your CI pipeline, to update your CI Pipeline. A window will be popped up with all the details of the current pipeline.
Make your changes and click on Update Pipeline at the bottom to update your Pipeline.
You can only delete CI pipeline if you have no CD pipeline created in your workflow.
To delete a CI pipeline, go to the App Configurations and then click on Workflow editor
Click on Delete Pipeline at the bottom to delete the CD pipeline
The test cases given in the script will run before the test cases given in the devtron.ci.yaml
If one code is shared across multiple applications, Linked CI Pipeline can be used, and only one image will be built for multiple applications because if there is only one build, it is not advisable to create multiple CI Pipelines.
To create a Linked CI Pipeline, please follow the steps mentioned below :
Click on + New Build Pipeline button.
Select Linked CI Pipeline.
Select the application in which the source CI pipeline is present.
Select the source CI pipeline.
Provide a name for linked CI pipeline.
Click on Create Linked CI Pipeline button to create linked CI pipeline.
After creating a linked CI pipeline, you can create a CD pipeline. You cannot trigger build from linked CI pipeline, it can be triggered only from source CI pipeline. Initially you will not see any images to deploy in CD pipeline created from linked CI pipeline. Trigger build in source CI pipeline to see the images in CD pipeline of linked CI pipeline. After this, whenever you trigger build in source CI pipeline, the build images will be listed in CD pipeline of linked CI pipeline too.
You can use Devtron for deployments on Kubernetes while using your own CI tool such as Jenkins. External CI features can be used for cases where the CI tool is hosted outside the Devtron platform.
You can send the ‘Payload script’ to your CI tools such as Jenkins and Devtron will receive the build image every time the CI Service is triggered or you can use the Webhook URL which will build an image every time CI Service is triggered using Devtron Dashboard.
After your CI pipeline is ready, you can start building your CD pipeline. Devtron enables you to design your CD pipeline in a way that fully automates your deployments. Images from CI stage can be deployed to one or more environments through dedicated CD pipelines.
Click the '+' sign on CI Pipeline to attach a CD Pipeline to it.
A basic Create deployment pipeline window will pop up.
Here, you get three sections:
This section expects four inputs from you:
This option is available at the bottom of the Create deployment pipeline window.
Now, the window will have 3 distinct tabs, and you will see the following additions:
You can create or edit a deployment strategy in Advanced Options. Remember, only the default strategy will be used for deployment, so use the SET DEFAULT button to mark your preferred strategy as default after creating it.
If your deployment requires prior actions like DB migration, code quality check (QC), etc., you can use the Pre-deployment stage to configure such tasks.
Tasks
Here you can add one or more tasks. The tasks can be re-arranged using drag-and-drop and they will be executed sequentially.
Trigger Pre-Deployment Stage
ConfigMaps & Secrets
If you want to use some configuration files and secrets in pre-deployment stages or post-deployment stages, then you can use the ConfigMaps & Secrets options. You will get them as a drop-down in the pre-deployment stage.
Execute tasks in application environment
These Pre-deployment CD / Post-deployment CD pods can be created in your deployment cluster or the devtron build cluster. If your scripts/tasks has some dependency on the deployment environment, you may run these pods in the deployment cluster. Thus, your scripts (if any) can interact with the cluster services that may not be publicly exposed.
Some tasks require extra permissions for the node where Devtron is installed. However, if the node already has the necessary permissions for deploying applications, there is no need to assign them again. Instead, you can enable the Execute tasks in application environment option for the pre-CD or post-CD steps. By default, this option is disabled.
To enable the Execute tasks in application environment option, follow these steps:
Go to the chart store and search for the devtron-in-clustercd chart.
Configure the chart according to your requirements and deploy it in the target cluster.
After the deployment, edit the devtron-cm configmap and add the following key-value pair:
ORCH_HOST value should be same as of CD_EXTERNAL_LISTENER_URL value which is passed in values.yaml.
Delete the Devtron pod using the following command:
Again navigate to the chart store and search for the "migration-incluster-cd" chart.
Edit the cluster-name and secret name values within the chart. The cluster name refers to the name used when adding the cluster in the global configuration and for which you are going to enable Execute tasks in application environment option.
Deploy the chart in any environment within the Devtron cluster. Now you should be able to enable Execute tasks in application environment option for an environment of target cluster.
Pipeline name will be auto-generated; however, you are free to modify the name as per your requirement.
If you want only approved images to be eligible for deployment, enable the Manual approval for deployment option in the respective deployment pipeline. By doing so, unapproved images would be prevented from being deployed for that deployment pipeline.
Currently, only super-admins can enable or disable this option.
Users can also specify the number of approvals required for each deployment, where the permissible limit ranges from one approval (minimum) to six approvals (maximum). In other words, if the image doesn't get the specified number of approvals, it will not be eligible for deployment
To enable manual approval for deployment, follow these steps:
Click the deployment pipeline for which you want to enable manual approval.
Turn on the ‘Manual approval for deployment’ toggle button.
Select the number of approvals required for each deployment.
Enable the toggle button as shown below.
Click the edit icon.
You can write an alphanumeric pattern for your image tag, e.g., prod-v1.0.{x}. Here, 'x' is a mandatory variable whose value will incrementally increase with every pre or post deployment trigger (that option is also available to you). You can also define the value of 'x' for the next trigger in case you want to change it.
Click Update Pipeline.
Therefore, to eliminate the possibility of pulling an unintended image, Devtron offers the option to pull container images using digest and image tag.
An image digest is a unique and immutable SHA-256 string returned by the container registry when you push an image. So the image referenced by the digest will never change.
If you need to run any actions for e.g., closure of Jira ticket, load testing or performance testing, you can configure such actions in the post-deployment stages.
Post-deployment stages are similar to pre-deployment stages. The difference is, pre-deployment executes before the deployment, while post-deployment occurs after.
You can update the deployment stages and the deployment strategy of the CD Pipeline whenever you require it. However, you cannot change the name of a CD Pipeline or its Deployment Environment. If you want a new CD pipeline for the same environment, first delete the previous CD pipeline.
To update a CD Pipeline, go to the App Configurations section, Click on Workflow editor and then click on the CD Pipeline you want to Update.
Make changes as needed and click on Update Pipeline to update this CD Pipeline.
If you no longer require the CD Pipeline, you can also delete the Pipeline.
To delete a CD Pipeline, go to the App Configurations and then click on the Workflow editor. Now click on the pipeline you wish to delete. A pop-up having the CD details will appear. Verify the name and the details to ensure that you are not accidentally deleting the wrong CD pipeline and then click Delete Pipeline to delete it.
Deleting a CD pipeline also deletes all the K8s resources associated with it and will bring a disruption in the deployed micro-service. Before deleting a CD pipeline, please ensure that the associated resources are not being used in any production workload.
A deployment strategy is a method of updating, downgrading, or creating new versions of an application. The options you see under deployment strategy depend on the selected chart type (see fig 2). Below are some deployment configuration-based strategies.
Blue-green deployments involve running two versions of an application at the same time and moving traffic from the in-production version (the green version) to the newer version (the blue version).
A rolling deployment slowly replaces instances of the previous version of an application with instances of the new version of the application. Rolling deployment typically waits for new pods to become ready via a readiness check before scaling down the old components. If a significant issue occurs, the rolling deployment can be aborted.
Canary deployments are a pattern for rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers. The canary deployment serves as an early warning indicator with less impact on downtime: if the canary deployment fails, the rest of the servers aren't impacted.
The recreate strategy is a dummy deployment that consists of shutting down version 'A' and then deploying version 'B' after version 'A' is turned off.
A recreate deployment incurs downtime because, for a brief period, no instances of your application are running. However, your old code and new code do not run at the same time. It terminates the old version and releases the new one.
Unlike other strategies mentioned above, 'Recreate' strategy doesn't contain keys for you to configure.
Devtron supports attaching multiple deployment pipelines to a single build pipeline, in its workflow editor. This feature lets you deploy an image first to stage, run tests and then deploy the same image to production.
Please follow the steps mentioned below to create sequential pipelines:
After creating CI/build pipeline, create a CD pipeline by clicking on the + sign on CI pipeline and configure the CD pipeline as per your requirements.
To add another CD Pipeline sequentially after previous one, again click on + sign on the last CD pipeline.
Similarly, you can add multiple CD pipelines by clicking + sign of the last CD pipeline, each deploying in different environments.
The ConfigMap API resource holds key-value pairs of the configuration data that can be consumed by pods or used to store configuration data for system components such as controllers. ConfigMap is similar to Secrets, but designed to more conveniently support working with strings that do not contain sensitive information.
Click on Add ConfigMap to add a config map to your application.
You can configure a configmap in two ways-
(a) Using data type Kubernetes ConfigMap
(b) Using data type Kubernetes External ConfigMap
1. Data Type
Select the Data Type as Kubernetes ConfigMap, if you wish to use the ConfigMap created by Devtron.
2. Name
Provide a name to your configmap.
3. Use ConfigMap as
Here we are providing two options, one can select any of them as per your requirement
-Environment Variable as part of your configMap or you want to add Data Volume to your container using Config Map.
Environment Variable
Select this option if you want to add Environment Variables as a part of configMap. You can provide Environment Variables in key-value pairs, which can be seen and accessed inside a pod.
Data Volume
Select this option if you want to add a Data Volume to your container using the Config Map.
Key-value pairs that you provide here, are provided as a file to the mount path. Your application will read this file and collect the required data as configured.
4. Data
In the Data section, you provide your configmap in key-value pairs. You can provide one or more than one environment variable.
You can provide variables in two ways-
YAML (raw data)
GUI (more user friendly)
Once you have provided the config, You can click on any option-YAML or GUI to view the key and Value parameters of the ConfigMap.
Kubernetes ConfigMap using Environment Variable:
If you select Environment Variable in 3rd option, then you can provide your environment variables in key-value pairs in the Data section using YAML or GUI.
Data in YAML (please Check below screenshot)
Now, Click on Save ConfigMap to save your configmap configuration.
Kubernetes ConfigMap using Data Volume
Provide the Volume Mount folder path in Volume Mount Path, a path where the data volume needs to be mounted, which will be accessible to the Containers running in a pod.
You can add Configuration data as in YAML or GUI format as explained above.
You can click on YAML or GUI to view the key and Value parameters of the ConfigMap that you have created.
You can click on Save ConfigMap to save the configMap.
For multiple files mount at the same location you need to check sub path bool field, it will use the file name (key) as sub path. Sub Path feature is not applicable in case of external configmap.
File permission will be provide at the configmap level not on the each key of the configmap. It will take 3 digit standard permission for the file.
You can select Kubernetes External ConfigMap in the data type field if you have created a ConfigMap using the kubectl command.
By default, the data type is set to Kubernetes ConfigMap.
Kubernetes External ConfigMap is created using the kubectl create configmap command. If you are using Kubernetes External ConfigMap, make sure you give the name of ConfigMap the same as the name that you have given using kubectl create Configmap <configmap-name> <data source> command, otherwise, it might result in an error during the built.
You have to ensure that the External ConfigMap exists and is available to the pod.
The config map is created.
You can update your configmap anytime later but you cannot change the name of your configmap. If you want to change the name of the configmap then you have to create a new configmap. To update configmap, click on the configmap you have created make changes as required.
Click on Update Configmap to update your configmap.
You can delete your configmap. Click on your configmap and click on the delete sign to delete your configmap.
You will see all your environments associated with an application under the Environment Overrides section.
You can customize your Deployment template, ConfigMap, Secrets in Environment Overrides section to add separate customizations for different environments such as dev, test, integration, prod, etc.
If you want to deploy an application in a non-production environment and then in production environment, once testing is done in the non-production environment, then you do not need to create a new application for production environment. Your existing pipeline(non-production env) will work for both the environments with little customization in your deployment template under Environment overrides.
In a Non-production environment, you may have specified 100m CPU resources in the deployment template but in the Production environment, you may want to have 500m CPU resources as the traffic on Pods will be higher than traffic on non-production env.
Configuring the Deployment template inside Environment Overrides for a specific environment will not affect the other environments because Environment Overrides will configure deployment templates on environment basis. And at the time of deployment, it will always pick the overridden deployment template if any.
If there are no overrides specified for an environment in the Environment Overrides section, the deployment template will be the one you specified in the deployment template section of the app creation.
(Note: This example is meant only for a representational purpose. You can choose to add any customizations you want in your deployment templates in the Environment Overrides tab)
Any changes in the configuration will not be added to the template, instead, it will make a copy of the template and lets you customize it for each particular environment. And now this overridden template will be used only for the specified Environment.
This will save you the trouble to manually create deployment files separately for each environment. Instead, all you have to do is to change the required variables in the deployment template.
In the Environment Overrides section, click on Allow Override and make changes to your Deployment template and click on Save to save your changes of the Deployment template.
The basic deployment configuration which you specified on the Basic GUI section will be visible for you to customize for your environment.
If Basic is locked, you can modify the configurations on Advanced (YAML) which will be the default page.
Note: Delete Override will discard the current overrides and the base configuration will be applicable to the environment.
The same goes for ConfigMap and Secrets. You can also create an environment-specific configmap and Secrets inside the Environment override section.
Click on Update ConfigMap to update Configmaps.
Click on Update Secrets to update Secrets.
Since resources are created according to the configurations you enter, it's essential to restrict such configurations from direct modifications. For critical environments like production, it becomes necessary to introduce an approval flow for any edits made to the configuration files.
In Devtron, these configurations are present in the App Configuration tab of your application.
Any changes made to the following configurations will require approval if enabled:
Deployment Template
ConfigMaps
Secrets
This stands true for both: base configuration and respective environment-level configuration.
Only a super-admin, manager, and admin can edit the configuration values.
Let's assume you are the application admin and you wish to edit the deployment template of your environment (as an override).
Go to the App Configuration tab.
In Environment Overrides → (choose your environment) → Deployment Template
You can change the value of a key to a desired value as shown below. Once done, click the Save Changes… button.
If the configuration is protected, your changes won't be published right away. You can do either of the following:
Save as draft : Selecting this option will save your file as a draft. You and other users can view and edit the saved draft and propose it further for approval.
Save & Propose Changes : Selecting this option will propose your changes to a configuration approver for a review.
Since we are proposing the changes immediately, click Propose Changes.
You can also view the approver(s) if you wish.
The one who performs the edits cannot approve their own changes. A different user has to review and approve.
Only one draft can exist at time and you cannot create multiple drafts. In the top-right corner, you have the option to discard the draft if you don't wish to proceed with the edits you made.
Only a different super-admin user or someone (who is not amongst the editors of the draft), having Configuration approver access, can approve the changes made to the configuration files.
Go to the edited configuration file to review and approve the changes as shown below.
A super-admin can check whether a user has approval rights by going to Global Configurations → Authorization (dropdown) → User Permissions.
Once the approver validates and approves your configuration changes, you can proceed to deploy your application with the updated configuration.
Go to the Build & Deploy tab of your application.
Click Select Image in the deployment flow.
You can view an indicator at the bottom Config Diff from Last Deployed. Click Review to view the changes.
If the new configuration is not yet approved, the changes made to the config would not be visible during deployment, it would show No Config Diff from Last Deployed at the bottom. In that case, check whether your changes are present in the live config or not. If your changes are absent, chances are your draft is either pending for approval or rejected (discarded).
Once you have verified the changes, you can click Deploy.
If you don't wish to deploy with the new changes, you can choose Last deployed config from the available drop-down.
Only a super-admin can enable or disable the config protection.
Go to the App Configuration tab.
Click Protect Configuration.
Use the toggle button to enable the protection for the configuration of your choice (base/environment level). A protection badge would appear next to the chosen configuration.
Alternatively, unprotecting the configuration will lead to the discarding of unapproved drafts (if any).
Delete the Application, when you are sure you no longer need it.
Clicking on Delete Application will not delete your application if you have workflows in the application.
If your Application contains workflows in the Workflow Editor. So, when you click on Delete Application, you will see the following prompt.
Click on View Workflows to view and delete your workflows in the application.
To delete the workflows in your application, you must first delete all the pipelines (CD Pipeline, CI Pipeline or Linked CI Pipeline or External CI Pipeline if there are any).
After you have deleted all the pipelines in the workflow, you can delete that particular workflow.
Similarly, delete all the workflows in the application.
Now, Click on Delete Application to delete the application.
To incorporate secrets from HashiCorp Vault, you need to create a generic Kubernetes secret that will be used for vault authentication. This involves creating a Kubernetes secret in the specific namespace where your application will be deployed. The secret should store the base64-encoded password or token obtained from vault. To simplify the process, you can utilize the Devtron generic chart. An example yaml is given below:
Note: Please note that you don't need to create the Kubernetes secret every time you create an External Secret for the corresponding namespace.
Once you have created the generic secret, follow these steps in the application's Secrets section:
1. Create a new secret
To add a new secret to the application, go to the App Configuration section of the application. Then, navigate to the left pane and select the Secrets option and click the Add Secret button.
2. Select HashiCorp Vault as the External Secret Operator
After clicking the Add Secret button, select HashiCorp Vault from the dropdown menu for the Data type option. Provide a name for the secret you are creating, and then proceed to configure the external secret as described in the next step.
3. Configure the secret
To configure the external secret that will be fetched from HashiCorp Vault for your application, you will need to provide specific details using the following key-value pairs:
4. Save the secret
After configuring the external secret from HashiCorp Vault, proceed to save the secret by clicking the Save button.
By following the steps mentioned above and configuring these values correctly, you can seamlessly fetch and utilize external secrets from HashiCorp Vault within your application environment by deploying the application.
| Field | Description |
|---|---|
| Field | Description |
|---|---|
| Field | Description |
|---|---|
| Field | Description |
|---|---|
| Field | Description |
|---|---|
| Key | Descriptions |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | values | Description |
|---|---|---|
| Key | Description |
|---|---|
| Variable | Format | Description |
|---|---|---|
| Field name | Required/Optional | Field description |
|---|---|---|
| Field name | Required/Optional | Field description |
|---|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Key | values | Description |
|---|---|---|
| Key | Description |
|---|---|
| Key | Description |
|---|---|
| Field Name | Required/Optional | Description |
|---|---|---|
| Field Name | Required/Optional | Description |
|---|---|---|
| Filter key | Description |
|---|---|
| Filter key | Description |
|---|---|
| Fields | Description |
|---|---|
| Code | Description |
|---|---|
| Key | Description |
|---|
| Key | Description |
|---|
| Key | Description |
|---|
If you don't find any chart with this name i.e external-secrets, add chart repository using repository url https://charts.external-secrets.io. Please follow this for adding chart repository.
| Key | Description |
|---|
[Note] It only works if Git Host is Github or Bitbucket Cloud as of now. In case you need support for any other Git Host, please create a .
Devtron uses regexp library, view . You can test your custom regex from .
| Key | Description |
|---|
| Filter | Description |
|---|
Users can run the test case using the Devtron dashboard or by including the test cases in the devtron.ci.yaml file in the source git repository. For reference, check:
| Field | Description |
|---|
| Key | Description |
|---|
| Setting | Description | Options |
|---|
Devtron supports multiple deployment strategies depending on the .
Refer to know more about each strategy in depth.
The next section is and it comes with additional capabilities. However, if you don't need them, you may proceed with a basic CD pipeline and click Create Pipeline.
Refer the trigger types from .
Make sure you have added and in App Configuration.
Make sure your cluster has installed.
To know more about the approval process, refer .
This will be utilized only when an existing container image is copied to another repository using the . The image will be copied with the tag generated by the Image Tag Pattern you defined.
To know how and where this image tag would appear, refer
Although Devtron ensures that remain unique, the same cannot be said if images are pushed with the same tag to the same container registry from outside Devtron.
Users need to have Admin permission or above (along with access to the environment and application) to enable this option. However, this option will be non-editable in case the super-admin has enabled .
You can use in post deployments as well. The option to execute tasks in application environment is available too.
| Key | Description |
|---|
| Key | Description |
|---|
| Key | Description |
|---|
Does your app have different requirements for different environments? Read
| Key | Description |
|---|
If you want to configure Basic GUI at the application level, then you can provide the required information in the .
Super-admins can lock keys in deployment template to prevent non-super-admins from modifying those locked keys. Refer to know more.
If you want to configure your ConfigMap and secrets at the application level then you can provide them in and , but if you want to have environment-specific ConfigMap and secrets then provide them under the Environment override Section. At the time of deployment, it will pick both of them and provide them inside your cluster.
If you are not a super-admin, you cannot modify the locked keys in deployment template. Refer to know more.
| Key | Description |
|---|
Container Registry
Select the container registry from the drop-down list or you can click Add Container Registry. This registry will be used to store docker images.
Container Repository
Enter the name of your container repository, preferably in the format username/repo-name. The repository that you specify here will store a collection of related docker images. Whenever an image is added here, it will be stored with a new tag version.
Select repository containing Dockerfile
Select the Git checkout path of your repository. This repository is the same which you defined on the Git Repository section.
Dockerfile Path (Relative)
Enter a relative file path where your docker file is located in Git repository. Ensure that the dockerfile is available on this path. This is a mandatory field.
Language
Select the programming language (e.g., Java, Go, Python, Node etc.) from the drop-down list you want to create a dockerfile as per compatibility to your system.
Note We will be adding other programming languages in the future releases.
Framework
Select the framework (e.g., Maven, Gradle etc.) of the selected programming language.
Note We will be adding other frameworks in the future releases.
Select repository containing code
Select your code repository. This repository is the same which you defined on the Git Repository section.
Project Path (Relative)
In case of monorepo, specify the path of the project from your Git repository.
Language
Select the programming language (e.g., Java, Go, Python, Node, Ruby, PHP etc.) from the drop-down list you want to build your container image as per the compatibility to your system.
Note: We will be adding other programming languages in the future releases.
Version
Select a language version from the drop-down list. If you do not find the version you need, then you can update the language version in Build Env Arguments. You can also select Autodetect in case if you want Builder to detect version by itself or its default version.
Select a builder
A builder is an image that contains a set of buildpacks which provide your app's dependencies, a stack, and the OS layer for your app image. Select a buildpack provider from the following options:
Heroku: It compiles your deployed code and creates a slug, which is a compressed and pre-packaged copy of your app and also the runtime which is optimized for distribution to the dyno (Linux containers) manager. Learn more.
GCR: GCR builder is a general purpose builder that creates container images designed to run on most platforms (e.g. Kubernetes / Anthos, Knative / Cloud Run, Container OS, etc.). It auto-detects the language of your source code, and can also build functions compatible with the Google Cloud Function Framework. Learn more.
Paketo: Paketo buildpacks provide production-ready buildpacks for the most popular languages and frameworks to easily build your apps. Based on your application needs, you can select from Full, Base and Tiny. Learn more.
Key
Define the key parameter as per your selected language and builder. E.g., By default GOOGLE_RUNTIME_VERSION for GCR buildpack.
Note: If you want to define env arguments for PHP and Ruby languages after selecting Heroku builder, please make sure to refer respective Heroku Ruby Support and Heroku PHP Support documentation for runtime information.
Value
Define the value for the specified key. E.g. Version no.
activeDeadlineSeconds
Another way to terminate a Job is by setting an active deadline. Do this by setting the activeDeadlineSeconds field of the Job to a number of seconds. The activeDeadlineSeconds applies to the duration of the job, no matter how many Pods are created. Once a Job reaches activeDeadlineSeconds, all of its running Pods are terminated and the Job status will become type: Failed with reason: DeadlineExceeded.
backoffLimit
There are situations where you want to fail a Job after some amount of retries due to a logical error in configuration etc. To do so, set backoffLimit to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6. Failed Pods associated with the Job are recreated by the Job controller with an exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset when a Job's Pod is deleted or successful without any other Pods for the Job failing around that time.
completions
Jobs with fixed completion count - that is , jobs that have non null completions - can have a completion mode that is specified in completionMode.
parallelism
The requested parallelism can be set to any non-negative value. If it is unspecified, it defaults to 1. If it is specified as 0, then the Job is effectively paused until it is increased.
suspend
The suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false.
ttlSecondsAfterFinished
The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean up finished Jobs (either Complete or Failed) automatically by specifying the ttlSecondsAfterFinished field of a Job, as in this example. The TTL controller will assume that a resource is eligible to be cleaned up TTL seconds after the resource has finished, in other words, when the TTL has expired. When the TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete its dependent objects together with it. Note that when the resource is deleted, its lifecycle guarantees, such as finalizers, will be honored.
kind
As with all other Kubernetes config, a Job and cronjob needs apiVersion, kind.cronjob and job also needs a section fields which is optional . these fields specify to deploy which job (conjob or job) should be kept. by default, they are set job.
concurrencyPolicy
A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If concurrencyPolicy is set to Forbid and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed,Acceptable values: Allow / Forbid.
failedJobsHistoryLimit
The failedJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish.
restartPolicy
The spec of a Pod has a restartPolicy field with possible values Always, OnFailure, and Never. The default value is Always.The restartPolicy applies to all containers in the Pod. restartPolicy only refers to restarts of the containers by the kubelet on the same node. After containers in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s, 40s, …), that is capped at five minutes. Once a container has executed for 10 minutes without any problems, the kubelet resets the restart backoff timer for that container, Acceptable values: Always / OnFailure / Never.
schedule
To generate Cronjob schedule expressions, you can also use web tools like https://crontab.guru/.
startingDeadlineSeconds
If startingDeadlineSeconds is set to a large value or left unset (the default) and if concurrencyPolicy is set to Allow, the jobs will always run at least once.
successfulJobsHistoryLimit
The successfulJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish.
suspend
The suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false.
kind
As with all other Kubernetes config, a Job and cronjob needs apiVersion, kind.cronjob and job also needs a section fields which is optional . these fields specify to deploy which job (conjob or job) should be kept. by default, they are set cronjob.
Chart version
Select the Chart Version using which you want to deploy the application. Refer Chart Version section for more detail.
Basic Configuration
You can select the basic deployment configuration for your application on the Basic GUI section instead of configuring the YAML file. Refer Basic Configuration section for more detail.
Advanced (YAML)
If you want to do additional configurations, then click Advanced (YAML) for modifications. Refer Advanced (YAML) section for more detail.
Show application metrics
You can enable Show application metrics to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency.
Refer Application Metrics for more detail.
envoyPort
envoy port for the container
idleTimeout
the duration of time that a connection is idle before the connection is terminated
name
name of the port
port
port for the container
servicePort
port of the corresponding kubernetes service
nodePort
nodeport of the corresponding kubernetes service
supportStreaming
Used for high performance protocols like grpc where timeout needs to be disabled
useHTTP2
Envoy container can accept HTTP2 requests
Path
It define the path where the liveness needs to be checked
initialDelaySeconds
It defines the time to wait before a given container is checked for liveliness
periodSeconds
It defines the time to check a given container for liveness
successThreshold
It defines the number of successes required before a given container is said to fulfill the liveness probe
timeoutSeconds
It defines the time for checking timeout
failureThreshold
It defines the maximum number of failures that are acceptable before a given container is not considered as live
httpHeaders
Custom headers to set in the request. HTTP allows repeated headers, you can override the default headers by defining .httpHeaders for the probe.
scheme
Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
tcp
The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy.
Path
It define the path where the readiness needs to be checked
initialDelaySeconds
It defines the time to wait before a given container is checked for readiness
periodSeconds
It defines the time to check a given container for readiness
successThreshold
It defines the number of successes required before a given container is said to fulfill the readiness probe
timeoutSeconds
It defines the time for checking timeout
failureThreshold
It defines the maximum number of failures that are acceptable before a given container is not considered as ready
httpHeaders
Custom headers to set in the request. HTTP allows repeated headers, you can override the default headers by defining .httpHeaders for the probe.
scheme
Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
tcp
The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy.
minAvailable
Evictions are allowed as long as they leave behind 1 or more healthy pods of the total number of desired replicas.
maxUnavailable
Evictions are allowed as long as at most 1 unhealthy replica among the total number of desired replicas.
enabled
Set true to enable ambassador mapping else set false
ambassadorId
used to specify id for specific ambassador mappings controller
cors
used to specify cors policy to access host for this mapping
weight
used to specify weight for canary ambassador mappings
hostname
used to specify hostname for ambassador mapping
prefix
used to specify path for ambassador mapping
labels
used to provide custom labels for ambassador mapping
retryPolicy
used to specify retry policy for ambassador mapping
corsPolicy
Provide cors headers on flagger resource
rewrite
used to specify whether to redirect the path of this mapping and where
tls
used to create or define ambassador TLSContext resource
extraSpec
used to provide extra spec values which not present in deployment template for ambassador resource
enabled
Set true to enable autoscaling else set false
MinReplicas
Minimum number of replicas allowed for scaling
MaxReplicas
Maximum number of replicas allowed for scaling
TargetCPUUtilizationPercentage
The target CPU utilization that is expected for a container
TargetMemoryUtilizationPercentage
The target memory utilization that is expected for a container
extraMetrics
Used to give external metrics for autoscaling
enabled
Set true to enable canary releases using flagger else set false
addOtherGateways
To provide multiple istio gateways for flagger
addOtherHosts
Add multiple hosts for istio service mesh with flagger
analysis
Define how the canary release should progress and at what interval
annotations
Annotation to add on flagger resource
labels
Labels to add on flagger resource
appProtocol
Protocol to use for canary
corsPolicy
Provide cors headers on flagger resource
createIstioGateway
Set to true if you want to create istio gateway as well with flagger
headers
Add headers if any
loadtest
Enable load testing for your canary release
enabled
Determines whether to create a ServiceAccount for pods or not. If set to true, a ServiceAccount will be created.
name
Specifies the name of the ServiceAccount to use.
annotations
Specify annotations for the ServiceAccount.
enabled
Enable or disable ingress
annotations
To configure some options depending on the Ingress controller
path
Path name
host
Host name
tls
It contains security details
enabled
Enable or disable ingress
annotations
To configure some options depending on the Ingress controller
path
Path name
host
Host name
tls
It contains security details
enabled
To enable or disable the command
value
It contains the commands
containerSpec
containerSpec to define container lifecycle hooks configuration
lifecycle
Lifecycle hooks for the container
enabled
Set true to enable lifecycle hooks for the container else set false
postStart
The postStart hook is executed immediately after a container is created
httpsGet
Sends an HTTP GET request to a specific endpoint on the container
host
Specifies the host (example.com) to which the HTTP GET request will be sent
path
Specifies the path (/example) of the endpoint to which the HTTP GET request will be sent
port
Specifies the port (90) on the host where the HTTP GET request will be sent
preStop
The preStop hook is executed just before the container is stopped
exec
Executes a specific command, such as pre-stop.sh, inside the cgroups and namespaces of the container
command
The command to be executed is sleep 10, which tells the container to sleep for 10 seconds before it is stopped
image_tag
It is the image tag
image
It is the URL of the image
istio
Istio enablement. When istio.enable set to true, Istio would be enabled for the specified configurations
authorizationPolicy
It allows you to define access control policies for service-to-service communication.
action
Determines whether to ALLOW or DENY the request based on the defined rules.
provider
Authorization providers are external systems or mechanisms used to make access control decisions.
rules
List of rules defining the authorization policy. Each rule can specify conditions and requirements for allowing or denying access.
destinationRule
It allows for the fine-tuning of traffic policies and load balancing for specific services. You can define subsets of a service and apply different traffic policies to each subset.
subsets
Specifies subsets within the service for routing and load balancing.
trafficPolicy
Policies related to connection pool size, outlier detection, and load balancing.
gateway
Allowing external traffic to enter the service mesh through the specified configurations.
host
The external domain through which traffic will be routed into the service mesh.
tls
Traffic to and from the gateway should be encrypted using TLS.
secretName
Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway.
peerAuthentication
It allows you to enforce mutual TLS and control the authentication between services.
mtls
Mutual TLS. Mutual TLS is a security protocol that requires both client and server, to authenticate each other using digital certificates for secure communication.
mode
Mutual TLS mode, specifying how mutual TLS should be applied. Modes include STRICT, PERMISSIVE, and DISABLE.
portLevelMtls
Configures port-specific mTLS settings. Allows for fine-grained control over the application of mutual TLS on specific ports.
selector
Configuration for selecting workloads to apply PeerAuthentication.
requestAuthentication
Defines rules for authenticating incoming requests.
jwtRules
Rules for validating JWTs (JSON Web Tokens). It defines how incoming JWTs should be validated for authentication purposes.
selector
Specifies the conditions under which the RequestAuthentication rules should be applied.
virtualService
Enables the definition of rules for how traffic should be routed to different services within the service mesh.
gateways
Specifies the gateways to which the rules defined in the VirtualService apply.
hosts
List of hosts (domains) to which this VirtualService is applied.
http
Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies.
enabled
Enable or disable NetworkPolicy.
annotations
Additional metadata or information associated with the NetworkPolicy.
labels
Labels to apply to the NetworkPolicy.
podSelector
Each NetworkPolicy includes a podSelector which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty podSelector selects all pods in the namespace.
policyTypes
Each NetworkPolicy includes a policyTypes list which may include either Ingress, Egress, or both.
Ingress
Controls incoming traffic to pods.
Egress
Controls outgoing traffic from pods.
enabled
false,true
decide the enabling factor
apiVersion
pincher.devtron.ai/v1beta1, pincher.devtron.ai/v1alpha1
specific api version
action
sleep,delete, scale
This specify the action need to perform.
timeRangesWithZone:timeZone
eg:- "Asia/Kolkata","US/Pacific"
It use to specify the timeZone used. (It uses standard format. please refer this)
timeRangesWithZone:timeRanges
array of [ timeFrom, timeTo, weekdayFrom, weekdayTo]
It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges.
These settings will take action on Sat and Sun from 00:00 to 23:59:59,
targetReplicas
[n] : n - number of replicas to scale.
These is mandatory field when the action is scale
Default value is [].
fieldSelector
- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now())
These value will take a list of methods to select the resources on which we perform specified action .
Deployment Frequency
It shows how often this app is deployed to production
Change Failure Rate
It shows how often the respective pipeline fails
Mean Lead Time
It shows the average time taken to deliver a change to production
Mean Time to Recovery
It shows the average time taken to fix a failed pipeline
Pre-Build/Post-Build
Create a task using one of the Preset Plugins integrated in Devtron:
Create a task from Execute Custom script which you can customize your script with:
CodacyEndpoint
String
API endpoint for Codacy
GitProvider
String
Git provider for the scanning
CodacyApiToken
String
API token for Codacy. If it is provided, it will be used, otherwise it will be picked from Global secret (CODACY_API_TOKEN)
Organisation
String
Your Organization for Codacy
RepoName
String
Your Repository name
Branch
String
Your branch name
Task name
Required
A relevant name for the task
Description
Optional
A descriptive message for the task
Task type
Optional
Shell: Custom shell script goes here
Input variables
Optional
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value. Accepted data types include: STRING | BOOL | NUMBER | DATE
Description: Relevant message to describe the variable.
Trigger/Skip condition
Optional
A conditional statement to execute or skip the task
Script
Required
Custom script for the Pre/Post-build tasks
Output directory path
Optional
Output variables
Optional
Environment variables that are passed as input variables for the next task.
Pass/Failure Condition (Optional): Conditional statements to determine the success/failure of the task. A failed condition stops the execution of the next task and/or build process
Task name
Required
A relevant name for the task
Description
Optional
A descriptive message for the task
Task type
Optional
Container image
Input variables
Optional
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value Accepted data types include: STRING | BOOL | NUMBER | DATE
Description: Relevant message to describe the variable
Trigger/Skip condition
Optional
A conditional statement to execute or skip the task
Container image
Required
Select an image from the drop-down list or enter a custom value in the format <image>:<tag>
Mount custom code
Optional
Enable to mount the custom code in the container. Enter the script in the box below.
Mount above code at (required): Path where the code should be mounted
Command
Optional
The command to be executed inside the container
Args
Optional
The arguments to be passed to the command mentioned in the previous field
Port mapping
Optional
The port number on which the container listens. The port number exposes the container to outside services.
Mount code to container
Optional
Mounts the source code inside the container. Default is "No". If set to "Yes", enter the path.
Mount directory from host
Optional
Mount any directory from the host into the container. This can be used to mount code or even output directories.
Output directory path
Optional
Directory path for the script output files such as logs, errors, etc.
envoyPort
envoy port for the container.
idleTimeout
the duration of time that a connection is idle before the connection is terminated.
name
name of the port.
port
port for the container.
servicePort
port of the corresponding kubernetes service.
nodePort
nodeport of the corresponding kubernetes service.
supportStreaming
Used for high performance protocols like grpc where timeout needs to be disabled.
useHTTP2
Envoy container can accept HTTP2 requests.
labels
set of key-value pairs used to identify the StatefulSet .
annotations
A map of key-value pairs that are attached to the stateful set as metadata.
serviceName
The name of the Kubernetes Service that the StatefulSet should create.
podManagementPolicy
A policy that determines how Pods are created and deleted by the StatefulSet. In this case, the policy is set to "Parallel", which means that all Pods are created at once.
revisionHistoryLimit
The number of revisions that should be stored for each replica of the StatefulSet.
updateStrategy
The update strategy used by the StatefulSet when rolling out changes.
mountPath
The path where the volume should be mounted in the container.
apiVersion
The API version of the PVC .
kind
The type of object that the PVC is.
metadata
Metadata that is attached to the resource being created.
labels
A set of key-value pairs used to label the object for identification and selection.
spec
The specification of the object, which defines its desired state and behavior.
accessModes
A list of access modes for the PersistentVolumeClaim, such as "ReadWriteOnce" or "ReadWriteMany".
dataSource
A data source used to populate the PersistentVolumeClaim, such as a Snapshot or a StorageClass.
kind
specifies the kind of the snapshot, in this case Snapshot.
apiGroup
specifies the API group of the snapshot API, in this case snapshot.storage.k8s.io.
name
specifies the name of the snapshot, in this case my-snapshot.
dataSourceRef
A reference to a data source used to create the persistent volume. In this case, it's a secret.
updateStrategy
The update strategy used by the StatefulSet when rolling out changes.
resources
The resource requests and limits for the PersistentVolumeClaim, which define the minimum and maximum amount of storage it can use.
requests
The amount of storage requested by the PersistentVolumeClaim.
limits
The maximum amount of storage that the PersistentVolumeClaim can use.
storageClassName
The name of the storage class to use for the persistent volume.
selector
The selector used to match a persistent volume to a persistent volume claim.
matchLabels
a map of key-value pairs to match the labels of the corresponding PersistentVolume.
matchExpressions
A set of requirements that the selected object must meet to be considered a match.
key
The key of the label or annotation to match.
operator
The operator used to compare the key-value pairs (in this case, "In" specifies a set membership test).
values
A list of values that the selected object's label or annotation must match.
volumeMode
The mode of the volume, either "Filesystem" or "Block".
volumeName
The name of the PersistentVolume that is created for the PersistentVolumeClaim.
Path
It define the path where the liveness needs to be checked.
initialDelaySeconds
It defines the time to wait before a given container is checked for liveliness.
periodSeconds
It defines the time to check a given container for liveness.
successThreshold
It defines the number of successes required before a given container is said to fulfil the liveness probe.
timeoutSeconds
It defines the time for checking timeout.
failureThreshold
It defines the maximum number of failures that are acceptable before a given container is not considered as live.
httpHeaders
Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe.
scheme
Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
tcp
The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy.
Path
It define the path where the readiness needs to be checked.
initialDelaySeconds
It defines the time to wait before a given container is checked for readiness.
periodSeconds
It defines the time to check a given container for readiness.
successThreshold
It defines the number of successes required before a given container is said to fulfill the readiness probe.
timeoutSeconds
It defines the time for checking timeout.
failureThreshold
It defines the maximum number of failures that are acceptable before a given container is not considered as ready.
httpHeaders
Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe.
scheme
Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
tcp
The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy.
enabled
Set true to enable ambassador mapping else set false.
ambassadorId
used to specify id for specific ambassador mappings controller.
cors
used to specify cors policy to access host for this mapping.
weight
used to specify weight for canary ambassador mappings.
hostname
used to specify hostname for ambassador mapping.
prefix
used to specify path for ambassador mapping.
labels
used to provide custom labels for ambassador mapping.
retryPolicy
used to specify retry policy for ambassador mapping.
corsPolicy
Provide cors headers on flagger resource.
rewrite
used to specify whether to redirect the path of this mapping and where.
tls
used to create or define ambassador TLSContext resource.
extraSpec
used to provide extra spec values which not present in deployment template for ambassador resource.
enabled
Set true to enable autoscaling else set false.
MinReplicas
Minimum number of replicas allowed for scaling.
MaxReplicas
Maximum number of replicas allowed for scaling.
TargetCPUUtilizationPercentage
The target CPU utilization that is expected for a container.
TargetMemoryUtilizationPercentage
The target memory utilization that is expected for a container.
extraMetrics
Used to give external metrics for autoscaling.
enabled
Enable or disable ingress
annotations
To configure some options depending on the Ingress controller
path
Path name
host
Host name
tls
It contains security details
enabled
Enable or disable ingress
annotations
To configure some options depending on the Ingress controller
path
Path name
host
Host name
tls
It contains security details
istio
Istio enablement. When istio.enable set to true, Istio would be enabled for the specified configurations
gateway
Allowing external traffic to enter the service mesh through the specified configurations.
host
The external domain through which traffic will be routed into the service mesh.
tls
Traffic to and from the gateway should be encrypted using TLS.
secretName
Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway.
virtualService
Enables the definition of rules for how traffic should be routed to different services within the service mesh.
gateways
Specifies the gateways to which the rules defined in the VirtualService apply.
hosts
List of hosts (domains) to which this VirtualService is applied.
http
Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies.
corsPolicy
Cross-Origin Resource Sharing (CORS) policy configuration.
headers
Additional headers to be added to the HTTP request.
match
Conditions that need to be satisfied for this route to be used.
uri
This specifies a match condition based on the URI of the incoming request.
prefix
It specifies that the URI should have the specified prefix.
retries
Retry configuration for failed requests.
attempts
It specifies the number of retry attempts for failed requests.
perTryTimeout
sets the timeout for each individual retry attempt.
rewriteUri
Rewrites the URI of the incoming request.
route
List of destination rules for routing traffic.
enabled
To enable or disable the command.
value
It contains the commands.
image_tag
It is the image tag
image
It is the URL of the image
enable
false,true
decide the enabling factor
apiVersion
pincher.devtron.ai/v1beta1, pincher.devtron.ai/v1alpha1
specific api version
action
sleep,delete, scale
This specify the action need to perform.
timeRangesWithZone:timeZone
eg:- "Asia/Kolkata","US/Pacific"
It use to specify the timeZone used. (It uses standard format. please refer this)
timeRangesWithZone:timeRanges
array of [ timeFrom, timeTo, weekdayFrom, weekdayTo]
It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges.
These settings will take action on Sat and Sun from 00:00 to 23:59:59,
targetReplicas
[n] : n - number of replicas to scale.
These is mandatory field when the action is scale
Default value is [].
fieldSelector
- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now())
These value will take a list of methods to select the resources on which we perform specified action .
Deployment Frequency
It shows how often this app is deployed to production
Change Failure Rate
It shows how often the respective pipeline fails.
Mean Lead Time
It shows the average time taken to deliver a change to production.
Mean Time to Recovery
It shows the average time taken to fix a failed pipeline.
region
AWS region in which secret is created
accessKeyIDSecretRef.name
Name of secret created that would be used for authentication
accessKeyIDSecretRef.key
In generic secret created for AWS authentication, variable name in which base64 encoded AWS access-key is stored
secretAccessKeySecretRef.name
Name of secret created that would be used for authentication
secretAccessKeySecretRef.key
In generic secret created for AWS authentication, variable name in which base64 encoded secret-access-key is stored
secretKey
Key name to store secret
key
AWS Secrets Manager secret name
property
AWS Secrets Manager secret key
Source type
Required
Source type to trigger the CI. Available options: Branch Fixed | Branch Regex |Pull Request | Tag Creation
Branch Name
Required
Branch that triggers the CI build
Advanced Options
Optional
Create Pre-Build, Build, and Post-Build tasks
TRIGGER BUILD PIPELINE
Required
The build execution may be set to:
Automatically (default): Build is triggered automatically as the Git source code changes.
Manually: Build is triggered manually.
Pipeline Name
Required
A name for the pipeline
Source type
Required
Select the source type to build the CI pipeline: Branch Fixed | Branch Regex | Pull Request | Tag Creation
Branch Name
Required
Branch that triggers the CI build
Docker build arguments
Optional
Override docker build configurations for this pipeline.
Key: Field name
Value: Field value
Author
Author of the PR
Source branch name
Branch from which the Pull Request is generated
Target branch name
Branch to which the Pull request will be merged
Title
Title of the Pull Request
State
State of the PR. Default is "open" and cannot be changed
Author
The one who created the tag
Tag name
Name of the tag for which the webhook will be triggered
Deploy to environment
Environment: Provide the name of the environment.
Namespace: Provide the namespace.
When do you want to deploy
You can deploy either in one of the following ways:
Automatic: If you select automatic, your application will be deployed automatically everytime a new image is received.
Manual: In case of manual, you have to select the image and deploy manually.
Deployment Strategy
Configure the deployment preferences for this pipeline.
200
app detail page url
400
Bad request
401
Unauthorized
| Secret key in backend |
| Name for this key in the generated secret |
| Property to extract if secret in backend is a JSON object |
| Set this to true if configuring an item for a binary file stored else set false |
| Name of secret created that would be used for authentication. |
| In generic secret created for GCP authentication, variable name in which base64 encoded service account key is stored. |
| GCP Project ID where secret is created. |
| Key name to store secret. |
| GCP Secrets Manager secret name. |
| Name of the pipeline |
| Select from automatic or manual execution depending upon your use-case |
| Select the source through which the CI Pipeline will be triggered |
| 1.Pre-build Stages- Scripts to be executed before building an image. 2.Docker build Stages- Provide a new argument and override an old argument in key-value pair. 3. Post-build Stages- Scripts to be executed after building image |
| It will scan your image and find if any vulnerabilities present |
| Branch from which the Pull Request is generated. |
| Branch to which the Pull request will be merged. |
| The one who created the Pull Request. |
| Title provided to the Pull Request. |
| It shows the state of PR and as of now it is fixed to Open which cannot be changed. |
| The one who created the tag. |
| Name of the tag for which the webhook will be triggered. |
| specify the version of yaml |
| applies the changes to a specified branch |
| branch type on which changes are to be applied, it can be BRANCH_FIXED or TAG_PATTERN |
| branch name on which changes are to be applied, it can take a value as the name of branch (“master”) or as a regular expression ("%d.%d.%d-rc") |
| A script which you want to execute, you can also execute the docker commands here |
| script to run before the docker build step |
| script to run after the docker build step |
| The location where you want to see the output of the report of Test cases |
| Name of the pipeline |
| ‘Branch Fixed’ or ‘Tag Regex’ |
| Name of the branch |
| It will make the rollout automatically promote the new ReplicaSet to active Service after this time has passed |
| It is used to delay scaling down the old ReplicaSet after the active Service is switched to the new ReplicaSet |
| It will indicate the number of replicas that the new version of an application should run |
| It will make the rollout automatically promote the new ReplicaSet to the active service |
| No. of replicas allowed above the scheduled quantity |
| Maximum number of pods allowed to be unavailable |
| It defines the maximum number of replicas the rollout can create to move to the correct ratio set by the last setWeight |
| The maximum number of pods that can be unavailable during the update |
| It is the required percent of pods to move to the next step |
| It is used to set the duration to wait to move to the next step |
| Select your preferred data type for Kubernetes ConfigMap or Kubernetes External ConfigMap |
| Provide a name to this ConfigMap. |
| Select this option if you want to inject Environment Variables in pods using ConfigMap. |
| Select this option, if you want to configure a Data Volume that is accessible to Containers running in a pod and provide a Volume mount path. |
| Provide the actual key-value configuration data here. Key and corresponding value to the provided key. |
| Server is the connection address for the Vaultserver, e.g: "https://vault.example.com:8200" |
| Specify the path where the secret is stored in Vault |
| Enter the name of the secret that will be used for authentication |
| Specify the key name within the secret that contains the token |
| Provide a name for the secret in Kubernetes |
| Enter the name of the secret in Vault |
| Specify the key within the Vault secret |
| Provide a name to your Secret |
|
| Specify if there is a need to add a volume that is accessible to the Containers running in a pod. |
| Select this option if you want to inject Environment Variables in your pods using Secrets. |
| Select this option if you want to configure a Data Volume that is accessible to Containers running in a pod. Ensure that you provide a Volume mount path for the same. |
| Provide a key and the corresponding value of the provided key. |
Environment | Select the environment where you want to deploy your application | (List of available environments) |
Namespace | Automatically populated based on the selected environment | Not Applicable |
Trigger | When to execute the deployment pipeline | Automatic: Deployment triggers automatically when a new image completes the previous stage (build pipeline or another deployment pipeline) Manual: Deployment is not initiated automatically. You can trigger deployment with a desired image. |
Deployment Approach | How to deploy the application |
During the CI process, the application source code is pulled from your git repository.
Devtron also supports multiple Git repositories (be it from one Git account or multiple Git accounts) in a single deployment.
Therefore, this doc is divided into 2 sections, read the one that caters to your application:
Follow the below steps if the source code of your application is hosted on a single Git repository.
In your application, go to App Configuration → Git Repository. You will get the following fields and options:
This is a dropdown that shows the list of Git accounts added to your organization on Devtron. If you haven't done already, we recommend you to first add your Git account (especially when the repository is private).
If the authentication type of your Git account is anonymous, only public Git repositories in that account will be accessible. Whereas, adding a user auth or SSH key will make both public and private repositories accessible.
In this field, you have to provide your code repository’s URL, for e.g., https://github.com/devtron-labs/django-repo.
You can find this URL by clicking on the Code button available on your repository page as shown below:
Copy the HTTPS/SSH portion of the URL too
Make sure you've added your Dockerfile in the repo
Not all repository changes are worth triggering a new CI build. If you enable this checkbox, you can define the file(s) or folder(s) whose commits you wish to use in the CI build.
In other words, if a given commit contains changes only in file(s) present in your exclusion rule, the commit won't show up while selecting the Git material, which means it will not be eligible for build. However, if a given commit contains changes in other files too (along with the excluded file), the commit won't be excluded and it will definitely show up in the list of commits.
Devtron allows you to create either an exclusion rule, an inclusion rule, or a combination of both. In case of multiple files or folders, you can list them in new lines.
To exclude a path, use ! as the prefix, e.g. !path/to/file
To include a path, don't use any prefix, e.g. path/to/file
You may use the Learn how link (as shown below) to understand the syntax of defining an exclusion or inclusion rule.
Since file paths can be long, Devtron supports regex too for writing the paths. To understand it better, you may click the How to use link as shown below.
As we saw earlier in fig. 4 and 5, commits containing the changes of only README.md file were not displayed, since the file was in the exclusion list.
However, Devtron gives you the option to view the excluded commits too. There's a döner menu at the top-right (beside the Search by commit hash search bar).
The EXCLUDED label (in red) indicates that the commits contain changes made only to the excluded file, and hence they are unavailable for build.
After clicking the checkbox, a field titled clone directory path appears. It is the directory where your code will be cloned for the repository you specified in the previous step.
This field is optional for a single Git repository application and you can leave the path as default. Devtron assigns a directory by itself when the field is left blank. The default value of this field is ./
This checkbox is optional and is used for pulling git submodules present in a repo. The submodules will be pulled recursively, and the auth method used for the parent repo will be used for submodules too.
As discussed earlier, Devtron also supports multiple git repositories in a single application. To add multiple repositories, click Add Git Repository and repeat all the steps as mentioned in Single Repo Application. However, ensure that the clone directory paths are unique for each repo.
Repeat the process for every new git repository you add. The clone directory path is used by Devtron to assign a directory to each of your Git repositories. Devtron will clone your code at those locations and those paths can be referenced in the Docker file to create a Docker image of the application.
Whenever a change is pushed to any of the configured repositories, CI will be triggered and a new Docker image file will be built (based on the latest commits of the configured repositories). Next, the image will be pushed to the container registry you configured in Devtron.
Even if you add multiple repositories, only one image will be created based on the Dockerfile as shown in the docker build config
Let’s look at this with an example:
Due to security reasons, you want to keep sensitive configurations like third-party API keys in separate access-restricted git repositories, and the source code in a Git repository that every developer has access to. To deploy this application, code from both the repositories are required. A Multi-Git support helps you achieve it.
Other examples where you might need Multi-Git support:
To make code modularized, where front-end and back-end code are in different repos
Common library extracted out in a different repo so that other projects can use it
Provide the Data Type of your secret. To know about different Data Types available click on
Helm or GitOps Refer
| Sample Values | Description |
|---|---|
!README.md
Exclusion of a single file in root folder: Commits containing changes made only in README.md file will not be shown
!README.md
!index.js
Exclusion of multiple files in root folder: Commits containing changes made only in README.md or/and index.js files will not be shown
README.md
Inclusion of a single file in root folder: Commits containing changes made only in README.md file will be shown. Rest all will be excluded.
!src/extensions/printer/code2.py
Exclusion of a single file in a folder tree: Commits containing changes made specifically to code2.py file will not be shown
!src/*
Exclusion of a single folder and all its files: Commits containing changes made specifically to files within src folder will not be shown
!README.md
index.js
Exclusion and inclusion of files: Commits containing changes made only in README.md will not be shown, but commits made in index.js file will be shown. All other commits apart from the aforementioned files will be excluded.
!README.md
README.md
Exclusion and inclusion of conflicting files: If conflicting paths are defined in the rule, the one defined later will be considered. In this case, commits containing changes made only in README.md will be shown.
