Enterprise Upgrade Guide 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.

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

2. Follow this guide to install latest Kubernetes on both the nodes.
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
   

   2. 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_'
      

      2. Github Enterprise

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

      3. Gitlab

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

      4. Bitbucket Cloud

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

      5. Bitbucket Data Center

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

      6. Azure DevOps

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

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

   4. Database Settings

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

   5. Integration Settings

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

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

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

3. Run the following commands from your local machine from which you can access both the application instances, old and new.
4. Open port 9002 on your firewall so that your local machine can access the new and old nodes on the port. Also ensure the both the nodes can access the 9002 port on each other.
5. Install minio-client on your local by following the guide: https://min.io/docs/minio/linux/reference/minio-mc.html#install-mc
6. Run the migration script:

curl -LJO https://enterprise-assets.deepsource.com/migrate-minio 
chmod +x migrate-minio
./migrate-minio

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