You can configure Devtron by using configuration files. Configuration files are YAML files which are user-friendly. The configuration allows you to quickly roll back a configuration change if necessary. It also aids cluster re-creation and restoration.
There are two ways you can perform configurations while setting up Devtron dashboard:
You can also setup ingress
while setting up Devtron dashboard. Refer here for ingress setup.
In certain cases, you may want to override default configurations provided by Devtron. For example, for deployments or statefulsets you may want to change the memory or CPU requests or limit or add node affinity or taint tolerance. Say, for ingress, you may want to add annotations or host. Samples are available inside the manifests/updates directory.
To modify a particular object, it looks in namespace devtroncd
for the corresponding configmap as mentioned in the mapping below:
component | configmap name | purpose |
---|---|---|
Let's take an example to understand how to override specific values. Say, you want to override annotations and host in the ingress, i.e., you want to change devtronIngress, copy the file devtron-ingress-override.yaml. This file contains a configmap to modify devtronIngress as mentioned above. Please note the structure of this configmap, data should have the key override
with a multiline string as a value.
apiVersion
, kind
, metadata.name
in the multiline string is used to match the object which needs to be modified. In this particular case it will look for apiVersion: extensions/v1beta1
, kind: Ingress
and metadata.name: devtron-ingress
and will apply changes mentioned inside update:
as per the example inside the metadata:
it will add annotations owner: app1
and inside spec.rules.http.host
it will add http://change-me
.
In case you want to change multiple objects, for eg in argocd
you want to change the config of argocd-dex-server
as well as argocd-redis
then follow the example in devtron-argocd-override.yaml.
Once we have made these changes in our local system we need to apply them to a Kubernetes cluster on which Devtron is installed currently using the below command:
Run the following command to make these changes take effect:
Our changes would have been propagated to Devtron after 20-30 minutes.
To use Devtron for production deployments, use our recommended production overrides located in manifests/updates/production. This configuration should be enough for handling up to 200 microservices.
The overall resources required for the recommended production overrides are:
The production overrides can be applied as pre-devtron installation
as well as post-devtron installation
in the respective namespace.
If you want to install a new Devtron instance for production-ready deployments, this is the best option for you.
Create the namespace and apply the overrides files as stated above:
After files are applied, you are ready to install your Devtron instance with production-ready resources.
If you have an existing Devtron instance and want to migrate it for production-ready deployments, this is the right option for you.
In the existing namespace, apply the production overrides as we do it above.
Name | Value |
---|---|
argocd
argocd-override-cm
GitOps
clair
clair-override-cm
container vulnerability db
clair
clair-config-override-cm
Clair configuration
dashboard
dashboard-override-cm
UI for Devtron
gitSensor
git-sensor-override-cm
microservice for Git interaction
guard
guard-override-cm
validating webhook to block images with security violations
postgresql
postgresql-override-cm
db store of Devtron
imageScanner
image-scanner-override-cm
image scanner for vulnerability
kubewatch
kubewatch-override-cm
watches changes in ci and cd running in different clusters
lens
lens-override-cm
deployment metrics analysis
natsOperator
nats-operator-override-cm
operator for nats
natsServer
nats-server-override-cm
nats server
natsStreaming
nats-streaming-override-cm
nats streaming server
notifier
notifier-override-cm
sends notification related to CI and CD
devtron
devtron-override-cm
core engine of Devtron
devtronIngress
devtron-ingress-override-cm
ingress configuration to expose Devtron
workflow
workflow-override-cm
component to run CI workload
externalSecret
external-secret-override-cm
manage secret through external stores like vault/AWS secret store
grafana
grafana-override-cm
Grafana config for dashboard
rollout
rollout-override-cm
manages blue-green and canary deployments
minio
minio-override-cm
default store for CI logs and image cache
minioStorage
minio-storage-override-cm
db config for minio
cpu
6
memory
13GB
If you wish to use Ingress as a means to access the Devtron services available in your cluster, you can configure it either during the installation or after the installation of Devtron.
Refer the section relevant to you:
If you have successfully configured Ingress, refer Post Ingress Setup.
If you are installing Devtron, you can enable Ingress either via set flag or by using ingress-values.yaml to specify the desired Ingress settings.
You can use the --set
flag to specify the desired Ingress settings.
Here, we have added 5 configurations you can perform depending on your requirements:
To enable Ingress and set basic parameters, use the following command:
To add labels to the Ingress resource, use the following command:
To add annotations to the Ingress resource, use the following command:
To configure TLS settings, including secretName
and hosts
, use the following command:
To include all the above settings in a single command, use:
As an alternative to the set flag method, you can enable Ingress using ingress-values.yaml
instead.
Create an ingress-values.yaml
file. You may refer the below format for an advanced ingress configuration which includes labels, annotations, secrets, and many more.
Once you have the ingress-values.yaml
file ready, run the following command:
After Devtron is installed, Devtron is accessible through devtron-service
. If you wish to access Devtron through ingress, you'll need to modify this service to use a ClusterIP instead of a LoadBalancer.
You can do this using the kubectl patch
command:
Next, create ingress to access Devtron by applying the devtron-ingress.yaml
file. The file is also available on this link. You can access Devtron from any host after applying this yaml.
For k8s versions < 1.19, apply this yaml:
Optionally, you also can access Devtron through a specific host by running the following YAML file:
Once Ingress setup for Devtron is done and you want to run Devtron over https
, you need to add different annotations for different ingress controllers and load balancers.
In case of nginx ingress controller
, add the following annotations under service.annotations
under nginx ingress controller to run devtron over https
.
(i) Amazon Web Services (AWS)
If you are using AWS cloud, add the following annotations under service.annotations
under nginx ingress controller.
(ii) Digital Ocean
If you are using Digital Ocean cloud, add the following annotations under service.annotations
under nginx ingress controller.
In case of AWS application load balancer, add following annotations under ingress.annotations
to run devtron over https
.
In case of AWS application load balancer, the following annotations need to be added under ingress.annotations
to run devtron over https
.
For an Ingress resource to be observed by AGIC (Application Gateway Ingress Controller) must be annotated with kubernetes.io/ingress.class: azure/application-gateway. Only then AGIC will work with the Ingress resource in question.
Note: Make sure NOT to use port 80 with HTTPS and port 443 with HTTP on the Pods.
For Helm
installation this section refers to secrets section of values.yaml
.
Configure the following properties:
Parameter | Description | Default |
---|---|---|
For Helm
installation this section refers to configs section of values.yaml
.
Configure the following properties:
Parameter | Description | Default |
---|---|---|
Devtron provides ways to control how much memory
or CPU
can be allocated to each Devtron microservice. You can adjust the resources that are allocated to these microservices based on your requirements. The resource configurations are available in following sizes:
Small
: To configure the small resources (e.g. to manage less than 10 apps on Devtron ) based on the requirements, append the Devtron installation command with -f https://raw.githubusercontent.com/devtron-labs/devtron/main/charts/devtron/resources-small.yaml
.
For Helm
installation this section refers to customOverrides section of values.yaml
. In this section you can override values of devtron-cm which you want to keep persistent. For example:
You can configure the following properties:
AWS SPECIFIC
While installing Devtron and using the AWS-S3 bucket for storing the logs and caches, the below parameters are to be used in the ConfigMap.
NOTE: For using the S3 bucket it is important to add the S3 permission policy to the IAM role attached to the nodes of the cluster.
The below parameters are to be used in the Secrets :
AZURE SPECIFIC
While installing Devtron using Azure Blob Storage for storing logs and caches, the below parameters will be used in the ConfigMap.
GOOGLE CLOUD STORAGE SPECIFIC
While installing Devtron using Google Cloud Storage for storing logs and caches, the below parameters will be used in the ConfigMap.
To convert string to base64 use the following command:
Note:
Ensure that the cluster has read and write access to the S3 buckets/Azure Blob storage container mentioned in DEFAULT_CACHE_BUCKET, DEFAULT_BUILD_LOGS_BUCKET or AZURE_BLOB_CONTAINER_CI_LOG, or AZURE_BLOB_CONTAINER_CI_CACHE.
Ensure that the cluster has read access to AWS secrets backends (SSM & secrets manager).
The following tables contain parameters and their details for Secrets and ConfigMaps that are configured during the installation of Devtron. If the installation is done using Helm
, the values can be tweaked in values.yaml file.
We can use the --set
flag to override the default values when installing with Helm. For example, to update POSTGRESQL_PASSWORD and BLOB_STORAGE_PROVIDER, use the install command as:
Blob Storage allows users to store large amounts of unstructured data. Unstructured data is a data that does not adhere to a particular data model or definition, such as text or binary data. Configuring blob storage in your Devtron environment allows you to store build logs and cache.
In case, if you do not configure the Blob Storage, then:
You will not be able to access the build and deployment logs after an hour.
Build time for commit hash takes longer as cache is not available.
Artifact reports cannot be generated in pre/post build and deployment stages.
You can configure Blob Storage with one of the following Blob Storage providers given below:
Note: You can also use the respective following command to switch to another Blob Storage provider. As an example, If you are using MinIO Storage and want to switch to Azure Blob Storage, use the command provided on the Azure Blob Storage tab to switch.
Use the following command to configure MinIO for storing logs and cache.
Note: Unlike global cloud providers such as AWS S3 Bucket, Azure Blob Storage and Google Cloud Storage, MinIO can be hosted locally also.
Use the following command to configure AWS S3 bucket for storing build logs and cache. Refer to the AWS specific
parameters on the Storage for Logs and Cache page.
Configure using S3 IAM policy:
NOTE: Pleasee ensure that S3 permission policy to the IAM role attached to the nodes of the cluster if you are using the below command.
Configure using access-key and secret-key for aws S3 authentication:
Configure using S3 compatible storages:
Use the following command to configure Azure Blob Storage for storing build logs and cache. Refer to the Azure specific
parameters on the Storage for Logs and Cache page.
Use the following command to configure Google Cloud Storage for storing build logs and cache. Refer to the Google Cloud specific
parameters on the Storage for Logs and Cache page.
Parameter | Description | Default |
---|---|---|
Parameter | Description | Default |
---|---|---|
Parameter | Description |
---|---|
Parameter | Description |
---|---|
Parameter | Description | Default |
---|---|---|
Parameter | Description | Default | Necessity |
---|---|---|---|
Parameter | Description | Default | Necessity |
---|---|---|---|
Parameter | Description |
---|---|
POSTGRESQL_PASSWORD
Using this parameter the auto-generated password for Postgres can be edited as per requirement(Used by Devtron to store the app information)
NA
WEBHOOK_TOKEN
If you want to continue using Jenkins for CI then provide this for authentication of requests should be base64 encoded
NA
BASE_URL_SCHEME
Either of HTTP or HTTPS (required)
HTTP
BASE_URL
URL without scheme and trailing slash, this is the domain pointing to the cluster on which the Devtron platform is being installed. For example, if you have directed domain devtron.example.com
to the cluster and the ingress controller is listening on port 32080
then URL will be devtron.example.com:32080
(required)
change-me
DEX_CONFIG
dex config if you want to integrate login with SSO (optional) for more information check Argocd documentation
NA
EXTERNAL_SECRET_AMAZON_REGION
AWS region for the secret manager to pick (required)
NA
PROMETHEUS_URL
URL of Prometheus where all cluster data is stored; if this is wrong, you will not be able to see application metrics like CPU, RAM, HTTP status code, latency, and throughput (required)
NA
CI_NODE_LABEL_SELECTOR
Labels for a particular nodegroup which you want to use for running CIs
NA
CI_NODE_TAINTS_KEY
Key for toleration if nodegroup chosen for CIs have some taints
NA
CI_NODE_TAINTS_VALUE
Value for toleration if nodegroup chosen for CIs have some taints
NA
DEFAULT_CACHE_BUCKET
AWS bucket to store docker cache, it should be created beforehand (required)
DEFAULT_BUILD_LOGS_BUCKET
AWS bucket to store build logs, it should be created beforehand (required)
DEFAULT_CACHE_BUCKET_REGION
AWS region of S3 bucket to store cache (required)
DEFAULT_CD_LOGS_BUCKET_REGION
AWS region of S3 bucket to store CD logs (required)
BLOB_STORAGE_S3_ENDPOINT
S3 compatible bucket endpoint.
BLOB_STORAGE_S3_ACCESS_KEY
AWS access key to access S3 bucket. Required if installing using AWS credentials.
BLOB_STORAGE_S3_SECRET_KEY
AWS secret key to access S3 bucket. Required if installing using AWS credentials.
AZURE_ACCOUNT_NAME
Account name for AZURE Blob Storage
AZURE_BLOB_CONTAINER_CI_LOG
AZURE Blob storage container for storing ci-logs after running the CI pipeline
AZURE_BLOB_CONTAINER_CI_CACHE
AZURE Blob storage container for storing ci-cache after running the CI pipeline
BLOB_STORAGE_GCP_CREDENTIALS_JSON
Base-64 encoded GCP credentials json for accessing Google Cloud Storage
DEFAULT_CACHE_BUCKET
Google Cloud Storage bucket for storing ci-logs after running the CI pipeline
DEFAULT_LOGS_BUCKET
Google Cloud Storage bucket for storing ci-cache after running the CI pipeline
ACD_PASSWORD
ArgoCD Password for CD Workflow
Auto-Generated
Optional
AZURE_ACCOUNT_KEY
Account key to access Azure objects such as BLOB_CONTAINER_CI_LOG or CI_CACHE
""
Mandatory (If using Azure)
GRAFANA_PASSWORD
Password for Grafana to display graphs
Auto-Generated
Optional
POSTGRESQL_PASSWORD
Password for your Postgresql database that will be used to access the database
Auto-Generated
Optional
AZURE_ACCOUNT_NAME
Azure account name which you will use
""
Mandatory (If using Azure)
AZURE_BLOB_CONTAINER_CI_LOG
Name of container created for storing CI_LOG
ci-log-container
Optional
AZURE_BLOB_CONTAINER_CI_CACHE
Name of container created for storing CI_CACHE
ci-cache-container
Optional
BLOB_STORAGE_PROVIDER
Cloud provider name which you will use
MINIO
Mandatory (If using any cloud other than MINIO), MINIO/AZURE/S3
DEFAULT_BUILD_LOGS_BUCKET
S3 Bucket name used for storing Build Logs
devtron-ci-log
Mandatory (If using AWS)
DEFAULT_CD_LOGS_BUCKET_REGION
Region of S3 Bucket where CD Logs are being stored
us-east-1
Mandatory (If using AWS)
DEFAULT_CACHE_BUCKET
S3 Bucket name used for storing CACHE (Do not include s3://)
devtron-ci-cache
Mandatory (If using AWS)
DEFAULT_CACHE_BUCKET_REGION
S3 Bucket region where Cache is being stored
us-east-1
Mandatory (If using AWS)
EXTERNAL_SECRET_AMAZON_REGION
Region where the cluster is setup for Devtron installation
""
Mandatory (If using AWS)
ENABLE_INGRESS
To enable Ingress (True/False)
False
Optional
INGRESS_ANNOTATIONS
Annotations for ingress
""
Optional
PROMETHEUS_URL
Existing Prometheus URL if it is installed
""
Optional
CI_NODE_LABEL_SELECTOR
Label of CI worker node
""
Optional
CI_NODE_TAINTS_KEY
Taint key name of CI worker node
""
Optional
CI_NODE_TAINTS_VALUE
Value of taint key of CI node
""
Optional
CI_DEFAULT_ADDRESS_POOL_BASE_CIDR
CIDR ranges used to allocate subnets in each IP address pool for CI
""
Optional
CI_DEFAULT_ADDRESS_POOL_SIZE
The subnet size to allocate from the base pool for CI
""
Optional
CD_NODE_LABEL_SELECTOR
Label of CD node
kubernetes.io/os=linux
Optional
CD_NODE_TAINTS_KEY
Taint key name of CD node
dedicated
Optional
CD_NODE_TAINTS_VALUE
Value of taint key of CD node
ci
Optional
CD_LIMIT_CI_CPU
CPU limit for pre and post CD Pod
0.5
Optional
CD_LIMIT_CI_MEM
Memory limit for pre and post CD Pod
3G
Optional
CD_REQ_CI_CPU
CPU request for CI Pod
0.5
Optional
CD_REQ_CI_MEM
Memory request for CI Pod
1G
Optional
CD_DEFAULT_ADDRESS_POOL_BASE_CIDR
CIDR ranges used to allocate subnets in each IP address pool for CD
""
Optional
CD_DEFAULT_ADDRESS_POOL_SIZE
The subnet size to allocate from the base pool for CD
""
Optional
GITOPS_REPO_PREFIX
Prefix for Gitops repository
devtron
Optional
RECOMMEND_SECURITY_SCANNING
If True, security scanning
is enabled
by default for a new build pipeline. Users can however turn it off in the new or existing pipelines.
FORCE_SECURITY_SCANNING
If set to True, security scanning
is forcefully enabled
by default for a new build pipeline. Users can not turn it off for new as well as for existing build pipelines. Old pipelines that have security scanning disabled will remain unchanged and image scanning should be enabled manually for them.
HIDE_DISCORD
Hides discord chatbot from the dashboard.