​

Managed PostgreSQL 12 → 16 migration guide

1. Upgrade database instance to Postgres16 from your respective cloud provider console
   1. AWS:
      1. https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html
   2. GCP:
      1. https://cloud.google.com/sql/docs/postgres/upgrade-major-db-version-inplace
   3. Azure:
      1. https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-major-version-upgrade
2. Scale down db dependent workload
   1. Run chmod +x scale-down-db-workloads.sh from the node/machine that you use to access kubernetes
   2. Run ./scale-down-db-workloads.sh

scale-down-db-workloads.sh

1. 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 (v3.31.0) with new password and select auth_type as sha-scram-256 and save the config.
   1. Select “Configure” for the latest version with status “pending 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

​

Embedded cluster upgrade

1. Create two new instances with the following system requirements in the same subnet as the existing nodes
   1. 16 CPU cores
   2. 32 GiB memory
   3. 150 GiB disk
   4. Operating System: Ubuntu 22.04 recommended. We do support all the OS’es listed System requirements in https://kurl.sh/deepsource-fowl-stable-v4
2. Follow this guide to install latest Kubernetes on both the nodes: https://docs.deepsource.com/docs/installation-standalone-cluster
3. Proceed with installing v4, make sure you have the license file on local.

​

DeepSource enterprise server upgrade (v3 → v4)

1. Check for updates
2. Select v4.x.x
3. Click on configure
4. Get secret of existing deepsource
   1. Dump all secret to a file for backup

kubectl get secret asgard -n default -o go-template='{{range $k, $v := .data}}{{$k}}: {{$v | base64decode}}{{"\n"}}{{end}}' > secrets

1. VCS Settings
   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_'

1. 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. Networking Settings

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'

1. Configure the new settings using the output from the above commands
2. Save and Deploy
3. Update DNS entry (for embedded clusters)
4. Make sure DeepSource is up and running
5. Follow minio migration guide

​

Minio Migration

​

Embedded Cluster (Cluster Upgrade with new cluster)

1. Run the following command in old cluster by SSH’ing into 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 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 from your local make sure you can access both the instances
2. Open port 9002 for communication between your local and both the new and old nodes.
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

1. For the access_key and secret_key refer to the output of the commands you ran earlier on both the nodes