Note: This guide is only for users who already have a DeepSource Enterprise Server v3 installation.

​
Managed PostgreSQL 12 → 16 migration guide

  1. Upgrade database instance to Postgres16 from your respective cloud provider console
  2. Scale down db dependent workload
    This will cause a minor downtime for the application. Make sure to run this during off-peak hours.
    1. Download the script to scale down db dependent workloads from scale-down-db-workloads.sh
    2. Run chmod +x scale-down-db-workloads.sh from the node/machine that you use to access kubernetes
    3. Run ./scale-down-db-workloads.sh
  3. Change password for the existing db user used by DeepSource.
Changing the password is required to make sure the latest auth_type is being used.
  1. Check for updates from Admin console and edit the config for DeepSource Enterprise Server (for v3 make sure you edit the config for v3.31.0 and above) with new password and select auth_type as sha-scram-256 and save the config.
    1. Select “scram-sha-256” as Database Authentication Type under Database Configuration
    1. Update the password field with the newly generated password
    1. Save config
    1. Deploy the latest edited version

​
DeepSource enterprise server upgrade (v3 → v4)

​
Pre-requisites

Make sure the required hosts are reachable by running the following command: Run the following command on the machine that has access to the Kubernetes cluster: 
# <NAMESPACE> is the application namespace where DeepSource application workloads are deployed
curl -sSL https://enterprise-assets.deepsource.com/check-host-reachability | bash -s -- -n <NAMESPACE>
Script Usage: 
Usage: ./check-host-reachability [-n NAMESPACE]
-n,  Kubernetes namespace where DeepSource application workloads are deployed (default: "default")

​
Existing cluster installation

  1. Upgrade KOTS: To update KOTS in an online existing cluster, run
curl https://kots.io/install | bash
For more KOTS CLI installation options, including information about how to install or update without root access, see Installing the KOTS CLI.
  1. Run the following command to update the KOTS Admin Console to the same version as the KOTS CLI:
kubectl kots admin-console upgrade -n <NAMESPACE>
Replace <NAMESPACE> with the namespace in your cluster where KOTS is installed.

​
Embedded cluster

  1. Create two new instances with the following system requirements in the same subnet as the existing nodes:
  • 16 CPU cores
  • 32 GiB memory
  • 150 GiB disk
  • Operating System: Ubuntu 22.04 recommended. We do support all the OS’es listed System requirements here.
  1. Follow this guide to install latest Kubernetes on both the nodes.
  2. Make sure the following ports are open between the nodes: https://docs.deepsource.com/docs/enterprise-server-requirements#ports
  3. Before proceeding with installing v4, make sure you have the license file available locally.

​
Steps to migrate

  1. Navigate to the “Version History” tab in the Admin Console and click on “Check for updates”.
  2. Select the latest version that starts with v4.x.x.
  3. You’ll be asked to configure the installation before you can move ahead. Click on the “Configure” button next to the latest version.
  4. Get secrets from the existing DeepSource installation.
    1. Dump all secret to a file for backup, just in case things go south.
    kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' > secrets
    1. VCS Settings
    Get the previously configured secrets for your VCS provider using the commands below:
    1. Github Cloud 
      kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep 'GITHUB_'
      1. Github Enterprise
      kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep 'GITHUB_'
      1. Gitlab
      kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep 'GITLAB_'
      1. Bitbucket Cloud
      kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep 'BITBUCKET_'
      1. Bitbucket Data Center
      kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep 'BITBUCKET_'
      1. Azure DevOps
      kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep 'ADS_'
      1. Google Source Repositories
      kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep 'GSR_'
    2. Access Control Settings 
    kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep -E 'SUPERUSER|SAML|SCIM|IDP'
    1. Database Settings
    kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep -E 'ASGARD_DB'
    1. Integration Settings
    kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep -E 'SLACK|JIRA'
    1. Advanced Configurations
    kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep -E 'SALT'
  5. Configure the new settings using the output from the above commands.
  6. For existing cluster installations with your own ingress controller, make sure to update the ingress annotations. The example ingress annotation is as follows: 
    kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
kubernetes.io/tls-acme: "true"
cert-manager.io/cluster-issuer: "<cluster-issuer>"
nginx.ingress.kubernetes.io/service-upstream: "true"
nginx.ingress.kubernetes.io/client-body-buffer-size: "1M"
nginx.ingress.kubernetes.io/proxy-connect-timeout: "75"
nginx.ingress.kubernetes.io/proxy-send-timeout: "180"
nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
nginx.ingress.kubernetes.io/use-regex: "true"
nginx.ingress.kubernetes.io/server-snippet: |
    add_header X-Frame-Options "SAMEORIGIN";
    add_header Content-Security-Policy "frame-ancestors 'self' https://bitbucket.org;";
    proxy_set_header Host "<primary-host>";
    proxy_set_header X-Forwarded-Proto https;
    server_tokens off;
    proxy_intercept_errors on;
    Replace <cluster-issuer> with the name of the cluster issuer you have in your cluster. Replace <primary-host> with the primary host of your DeepSource installation.
  7. Once you are done, save the config. You will be redirected to the “Version history” page. Deploy the latest configured release.
  8. Once the deployment is complete, make sure DeepSource is up and running by navigating to the DeepSource dashboard.
  9. Follow the minio migration guide below for migrating assets from the old installation to the new one.

​
Minio data migration

​
Existing cluster

Run the following command on the machine that has access to the Kubernetes cluster: 
# <NAMESPACE> is the application namespace where DeepSource application workloads are deployed
curl -sSL https://enterprise-assets.deepsource.com/migrate-minio-in-cluster | bash -s -- -n <NAMESPACE>
Script Usage: 
Usage: ./migrate-minio-in-cluster -n NAMESPACE [-a OLD_MINIO_ACCESS_KEY] [-s OLD_MINIO_SECRET_KEY]
-n, --namespace   Kubernetes namespace to deploy the migration pod (REQUIRED)
-a, --access-key  Old MinIO access key (optional, will use default if not provided)
-s, --secret-key  Old MinIO secret key (optional, will use default if not provided)

​
Embedded cluster

  1. Run the following command in old cluster by SSH’ing into the old application node:
curl -sSL https://enterprise-assets.deepsource.com/old-minio-svc.yaml | kubectl apply -f -
kubectl get secret deepsource-secret -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep -E 'aws'
  1. Run the following command in new cluster by SSH’ing into the new application node:
curl -sSL https://enterprise-assets.deepsource.com/new-minio-svc.yaml | kubectl apply -f -
kubectl get secret deepsource-secret -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' | grep -E 'aws
  1. Run the following commands from your local machine from which you can access both the application instances, old and new.
  2. Open port 9002 on your firewall so that your local machine can access the new and old nodes on the port. Also ensure that both the nodes can access the 9002 port on each other.
  3. Install minio-client on your local by following the guide: https://min.io/docs/minio/linux/reference/minio-mc.html#install-mc
  4. Run the migration script:
curl -LJO https://enterprise-assets.deepsource.com/migrate-minio
chmod +x migrate-minio
./migrate-minio
For the access_key and secret_key refer to the output of the commands you ran earlier on both the nodes.