Skip to main content
Version: 1.7

Installation Configuration

Configure Secrets​

For Helm installation this section refers to secrets section of values.yaml.

Configure the following properties:

ParameterDescriptionDefault
POSTGRESQL_PASSWORDUsing this parameter the auto-generated password for Postgres can be edited as per requirement(Used by Devtron to store the app information)NA
WEBHOOK_TOKENIf you want to continue using Jenkins for CI then provide this for authentication of requests should be base64 encodedNA

Configure ConfigMaps​

For Helm installation this section refers to configs section of values.yaml.

Configure the following properties:

ParameterDescriptionDefault
BASE_URL_SCHEMEEither of HTTP or HTTPS (required)HTTP
BASE_URLURL 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_CONFIGdex config if you want to integrate login with SSO (optional) for more information check Argocd documentationNA
EXTERNAL_SECRET_AMAZON_REGIONAWS region for the secret manager to pick (required)NA
PROMETHEUS_URLURL 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

Configure Resources​

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.

Configure Overrides​

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:

ParameterDescriptionDefault
CI_NODE_LABEL_SELECTORLabels for a particular nodegroup which you want to use for running CIsNA
CI_NODE_TAINTS_KEYKey for toleration if nodegroup chosen for CIs have some taintsNA
CI_NODE_TAINTS_VALUEValue for toleration if nodegroup chosen for CIs have some taintsNA

Storage for Logs and Cache​

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.

ParameterDescriptionDefault
DEFAULT_CACHE_BUCKETAWS bucket to store docker cache, it should be created beforehand (required)
DEFAULT_BUILD_LOGS_BUCKETAWS bucket to store build logs, it should be created beforehand (required)
DEFAULT_CACHE_BUCKET_REGIONAWS region of S3 bucket to store cache (required)
DEFAULT_CD_LOGS_BUCKET_REGIONAWS region of S3 bucket to store CD logs (required)
BLOB_STORAGE_S3_ENDPOINTS3 compatible bucket endpoint.

The below parameters are to be used in the Secrets :

ParameterDescription
BLOB_STORAGE_S3_ACCESS_KEYAWS access key to access S3 bucket. Required if installing using AWS credentials.
BLOB_STORAGE_S3_SECRET_KEYAWS secret key to access S3 bucket. Required if installing using AWS credentials.

AZURE SPECIFIC​

While installing Devtron using Azure Blob Storage for storing logs and caches, the below parameters will be used in the ConfigMap.

ParameterDescription
AZURE_ACCOUNT_NAMEAccount name for AZURE Blob Storage
AZURE_BLOB_CONTAINER_CI_LOGAZURE Blob storage container for storing ci-logs after running the CI pipeline
AZURE_BLOB_CONTAINER_CI_CACHEAZURE Blob storage container for storing ci-cache after running the CI pipeline

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.

ParameterDescriptionDefault
BLOB_STORAGE_GCP_CREDENTIALS_JSONBase-64 encoded GCP credentials json for accessing Google Cloud Storage
DEFAULT_CACHE_BUCKETGoogle Cloud Storage bucket for storing ci-logs after running the CI pipeline
DEFAULT_LOGS_BUCKETGoogle Cloud Storage bucket for storing ci-cache after running the CI pipeline

To convert string to base64 use the following command:

echo -n "string" | base64

Note:

  1. 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.
  2. 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:

helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
--set secrets.POSTGRESQL_PASSWORD=change-me \
--set configs.BLOB_STORAGE_PROVIDER=S3

Configuration of Blob Storage​

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 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.

helm repo update

helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--reuse-values \
--set installer.modules={cicd} \
--set minio.enabled=true

Configuring NodeSelectors and Tolerations​

Adding Custom Configurations​

When installing Devtron, you can specify nodeSelectors and tolerations to fine-tune your deployment. These configurations can be added using either additional --set flags or a separate values.yaml file.

Global vs. Component-level Configurations​

  • Global Configurations: When specified at the global level, these settings apply to all Devtron microservices, except for ArgoCD.
  • Component-Level Configurations: You can also apply these settings to specific components individually.
  • Priority: If a configuration is specified at both the global and component levels, the component-level setting takes precedence for that particular component.

Using --set Flags​

You can use the --set flag to specify individual values directly in the Helm command.

  1. nodeSelector

To set a nodeSelector:

helm install devtron devtron/devtron-operator \
    --create-namespace --namespace devtroncd \
    --set global.nodeSelector."kubernetes\.io/hostname"=node1

This example sets the nodeSelector to schedule pods on a node with the hostname "node1".

  1. Tolerations

To set tolerations:

helm install devtron devtron/devtron-operator \
    --create-namespace --namespace devtroncd \
    --set global.tolerations[0].key=example-key \
    --set global.tolerations[0].operator=Exists \
    --set global.tolerations[0].effect=NoSchedule \
    --set global.tolerations[0].value=value1

This example adds a tolerance for pods to be scheduled on nodes with the taint "example-key".

Using values.yaml​

In the values.yaml file of devtron chart, set the values of the following fields:

global:
  nodeSelector:
    kubernetes.io/hostname: node1  # For nodeSelector
  tolerations:
    - key: example-key  # For tolerations
      operator: Exists
      value: "value1"
      effect: NoSchedule

Set StorageClass for Devtron Microservices​

You can specify a StorageClass to be used by Devtron microservices' Persistent Volume Claims (PVCs) if a default StorageClass is not already configured in your cluster.

Checking for a Default StorageClass​

To check if your cluster has a default StorageClass, run:

kubectl get sc

This command will list all available StorageClasses in your cluster, including the default storage class set (if any). The default StorageClass (if any) can be identified by the (default) label next to its name.

Setting a Default StorageClass​

If no StorageClass class is set as default, you can set one using the following command:

kubectl patch storageclass <storageclassname> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}

Or, if you do not want to change the default StorageClass or prefer to use a different StorageClass for Devtron microservices, specify it during installation using the --set flag:

helm install devtron devtron/devtron-operator \
    --create-namespace --namespace devtroncd \
    --set global.storageClass="<storageclassname>" # set your preferred StorageClass

Alternatively, you can specify the StorageClass in the values.yaml file by modifying the following line in values.yaml.

Configure External PostgreSQL Database​

You can configure Devtron to use an external PostgreSQL database (e.g., Amazon RDS, Google Cloud SQL, Azure PostgreSQL) instead of the default internal database.

Prerequisites​

  • An external PostgreSQL server that is running and accessible
  • PostgreSQL version must be 14
  • The username Devtron uses to connect with PostgreSQL must be postgres
  • Network connectivity between Devtron and PostgreSQL server
  • DNS mapping must be completed for your PostgreSQL server

Database Setup​

Before installing Devtron, create the following databases on your external PostgreSQL server.

  1. orchestrator - Main Devtron orchestration database
  2. lens - Lens service database
  3. git_sensor - Git sensor service database
  4. casbin - Authorization and policy database
  5. clairv4 - (Optional) Required only if you are using Clair for image scanning instead of Trivy
Not sure how to create a PostgreSQL database?

Here’s how you can create databases using popular providers:

Database Creation Commands​

Connect to your PostgreSQL server as the postgres user and run the following commands:

-- Connect as postgres user
CREATE DATABASE orchestrator;
CREATE DATABASE lens;
CREATE DATABASE git_sensor;
CREATE DATABASE casbin;

-- Optional: Only if using Clair for image scanning
CREATE DATABASE clairv4;

Devtron Configuration for External DB​

Note

Ensure the required databases exist before proceeding.

When installing Devtron, you can specify your external PostgreSQL by using either of the following:

  • Updating values.yaml file
  • Passing --set flags during Helm installation

Using values.yaml file​

You can specify the following parameters in your Devtron values.yaml:

externalPostgres:
  enabled: true
  # Password for the postgres user
  PG_PASSWORD: "your_postgres_password"
  # DNS endpoint of your PostgreSQL server
  PG_ADDR: "your.postgres.endpoint"

Using --set flags​

You can use the following --set flags when installing Devtron with Helm:

helm install devtron devtron/devtron-operator \
  --set global.externalPostgres.enabled=true \
  --set global.externalPostgres.PG_PASSWORD="your_postgres_password" \
  --set global.externalPostgres.PG_ADDR="your.postgres.endpoint"

Example​

helm install devtron devtron/devtron-operator \
  --set global.externalPostgres.enabled=true \
  --set global.externalPostgres.PG_PASSWORD="mySecurePassword123" \
  --set global.externalPostgres.PG_ADDR="postgres.example.com"

Secrets​

ParameterDescriptionDefaultNecessity
ACD_PASSWORDArgoCD Password for CD WorkflowAuto-GeneratedOptional
AZURE_ACCOUNT_KEYAccount key to access Azure objects such as BLOB_CONTAINER_CI_LOG or CI_CACHE""Mandatory (If using Azure)
GRAFANA_PASSWORDPassword for Grafana to display graphsAuto-GeneratedOptional
POSTGRESQL_PASSWORDPassword for your Postgresql database that will be used to access the databaseAuto-GeneratedOptional

ConfigMaps​

ParameterDescriptionDefaultNecessity
AZURE_ACCOUNT_NAMEAzure account name which you will use""Mandatory (If using Azure)
AZURE_BLOB_CONTAINER_CI_LOGName of container created for storing CI_LOGci-log-containerOptional
AZURE_BLOB_CONTAINER_CI_CACHEName of container created for storing CI_CACHEci-cache-containerOptional
BLOB_STORAGE_PROVIDERCloud provider name which you will useMINIOMandatory (If using any cloud other than MINIO), MINIO/AZURE/S3
DEFAULT_BUILD_LOGS_BUCKETS3 Bucket name used for storing Build Logsdevtron-ci-logMandatory (If using AWS)
DEFAULT_CD_LOGS_BUCKET_REGIONRegion of S3 Bucket where CD Logs are being storedus-east-1Mandatory (If using AWS)
DEFAULT_CACHE_BUCKETS3 Bucket name used for storing CACHE (Do not include s3://)devtron-ci-cacheMandatory (If using AWS)
DEFAULT_CACHE_BUCKET_REGIONS3 Bucket region where Cache is being storedus-east-1Mandatory (If using AWS)
EXTERNAL_SECRET_AMAZON_REGIONRegion where the cluster is setup for Devtron installation""Mandatory (If using AWS)
ENABLE_INGRESSTo enable Ingress (True/False)FalseOptional
INGRESS_ANNOTATIONSAnnotations for ingress""Optional
PROMETHEUS_URLExisting Prometheus URL if it is installed""Optional
CI_NODE_LABEL_SELECTORLabel of CI worker node""Optional
CI_NODE_TAINTS_KEYTaint key name of CI worker node""Optional
CI_NODE_TAINTS_VALUEValue of taint key of CI node""Optional
CI_DEFAULT_ADDRESS_POOL_BASE_CIDRCIDR ranges used to allocate subnets in each IP address pool for CI""Optional
CI_DEFAULT_ADDRESS_POOL_SIZEThe subnet size to allocate from the base pool for CI""Optional
CD_NODE_LABEL_SELECTORLabel of CD nodekubernetes.io/os=linuxOptional
CD_NODE_TAINTS_KEYTaint key name of CD nodededicatedOptional
CD_NODE_TAINTS_VALUEValue of taint key of CD nodeciOptional
CD_LIMIT_CI_CPUCPU limit for pre and post CD Pod0.5Optional
CD_LIMIT_CI_MEMMemory limit for pre and post CD Pod3GOptional
CD_REQ_CI_CPUCPU request for CI Pod0.5Optional
CD_REQ_CI_MEMMemory request for CI Pod1GOptional
CD_DEFAULT_ADDRESS_POOL_BASE_CIDRCIDR ranges used to allocate subnets in each IP address pool for CD""Optional
CD_DEFAULT_ADDRESS_POOL_SIZEThe subnet size to allocate from the base pool for CD""Optional
GITOPS_REPO_PREFIXPrefix for Gitops repositorydevtronOptional

Dashboard Configurations​

RECOMMEND_SECURITY_SCANNING=false
FORCE_SECURITY_SCANNING=false
HIDE_DISCORD=false
ParameterDescription
RECOMMEND_SECURITY_SCANNINGIf 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_SCANNINGIf 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_DISCORDHides discord chatbot from the dashboard.