#Руководство по обновлению SonarQube с версии 9.9.5.1 до 2025.1.0 (Alauda Build of SonarQube Operator версии 2025.1.z)

#Overview

В этом документе описывается процесс обновления SonarQube с версии 9.9.5.1(9.9.6) до 2025.1.0. Поскольку данное обновление связано с изменениями в операторе версии 4.0, существующие экземпляры SonarQube необходимо мигрировать на новый оператор.

#Prerequisites

• В кластере установлен оператор новой версии (sonarqube-ce-operator)
• Убедитесь, что для обновления достаточно системных ресурсов
• Используйте функционал продукта для обновления SonarQube до версии 9.9.5.1
• Выполните полное резервное копирование данных согласно документации по резервному копированию

#Upgrade Steps

#1. Остановите развертывание экземпляра старой версии

# Предотвратить автоматическую синхронизацию оператора
kubectl patch deployment <old-sonarqube-name>-sonarqube -n <old-instance-namespace> \
  --type=json \
  -p '[{"op": "add", "path": "/metadata/annotations/skip-sync", "value": "true"}]'

# Масштабировать развертывание до 0
kubectl scale deployment <old-sonarqube-name>-sonarqube -n <old-instance-namespace> --replicas=0

#2. Настройте экземпляр новой версии

#2.1 Конфигурация базы данных

Примечание: SonarQube 9.9.5 поддерживает версии PG 11-15, а SonarQube 2025.1.0 — версии PG 13-17. Для миграции данных на новую версию PG обратитесь к официальной документации PG

Информация о PG, используемая старой версией SonarQube, хранится в spec.database.secretName экземпляра SonarQube.

kubectl get sonarqube.operator.devops.alauda.io <old-sonarqube-name> -n <old-instance-namespace> -o jsonpath='{.spec.database.secretName}'

Используйте эту команду для получения secretName, затем выполните

kubectl get secret <secretName> -n <old-instance-namespace> -o yaml для получения информации о секрете

Содержимое секрета:

apiVersion: v1
data:
  database: <database base64>
  host: <host base64>
  password: <password base64>
  port: <port base64>
  sslmode: <sslmode base64>
  username: <username base64>
kind: Secret
metadata:
  name: old-sonarqube-pg-secret
type: Opaque

1. Выполните полное резервное копирование данных согласно документации по резервному копированию

2. Создайте новую базу данных PG для нового экземпляра SonarQube.

   Рекомендуется создавать новую базу данных для развертывания новой версии SonarQube, чтобы избежать загрязнения старой базы и обеспечить нормальную работу старой версии SonarQube

3. Выполните миграцию данных согласно документации по резервному копированию

4. Создайте новый секрет базы данных. В секрете новой версии необходимо хранить только пароль:

   # Примечание: пароль здесь — это пароль для вновь развернутой базы данных PG
   kubectl create secret -n <namespace> generic sonarqube-db-secret \
     --from-literal=jdbc-password=<password>

5. Создайте конфигурацию нового экземпляра SonarQube с информацией о подключении к базе данных, подключающуюся к предыдущему экземпляру PG

   spec:
     helmValues:
       postgresql:
         enabled: false  # Отключить стандартный PostgreSQL
       jdbcOverwrite:
         enable: true
         # jdbcSecretName — имя созданного секрета
         jdbcSecretName: sonarqube-db-secret
         # username, host, port, database — имя пользователя, хост, порт, база данных новой PG
         jdbcUrl: jdbc:postgresql://<host>:<port>/<database>?socketTimeout=1500
         jdbcUsername: <username>

#2.2 Конфигурация хранилища

Выберите соответствующую конфигурацию в зависимости от типа хранилища, используемого в старом экземпляре SonarQube:

kubectl get sonarqube.operator.devops.alauda.io <old-sonarqube-name> -n <old-instance-namespace> -o jsonpath='{.spec.persistence.type}'

Использование StorageClass:

Разверните новый экземпляр, используя существующий PVC

spec:
  helmValues:
    persistence:
      enabled: true
      ## Имя PVC старой версии — <old-sonarqube-name>-sonarqube
      existingClaim: <old-sonarqube-name>-sonarqube

Использование существующего PVC:

Используйте команду ниже для получения имени PVC, используемого старой версией SonarQube

kubectl get sonarqube.operator.devops.alauda.io <old-sonarqube-name> -n <old-instance-namespace> -o jsonpath='{.spec.persistence.pvc.webServiceExistingClaim}'

spec:
  helmValues:
    persistence:
      enabled: true
      existingClaim: <spec.persistence.pvc.webServiceExistingClaim из YAML старого экземпляра>

Использование HostPath:

Примечание: Узел для HostPath новой и старой версии должен совпадать. В path необходимо добавить каталог portal на основе пути старой версии. Например, если путь старой версии /sonarqube/, то путь новой версии должен быть /sonarqube/portal/

spec:
  helmValues:
    nodeSelector:
      kubernetes.io/hostname: <node-name>
    persistence:
      enabled: false
      host:
        nodeName: <spec.persistence.location.nodeName из YAML старого экземпляра>
        path: <spec.persistence.location.path из YAML старого экземпляра>/portal # В старой версии в контроллере добавлен каталог portal, в новой версии нужно сохранить соответствие

#2.3 Конфигурация сети

Поскольку экземпляр старой версии не был удалён, конфигурация сети новой версии не может совпадать со старой (то есть ingress не может использовать тот же домен, nodePort — тот же порт), иначе возникнут конфликты. Временно используйте другие адреса, после завершения обновления удалите старый экземпляр и измените адрес доступа.

Используйте команду ниже для получения типа сети, используемого старой версией SonarQube

kubectl get sonarqube.operator.devops.alauda.io <old-sonarqube-name> -n <old-instance-namespace> -o jsonpath='{.spec.service.type}'

Конфигурация Ingress:

spec:
  helmValues:
    ingress:
      enabled: true
      hosts:
        - name: <spec.service.ingress.domainName из YAML старого экземпляра> ## Примечание: при наличии старого экземпляра использование того же домена в новом вызовет конфликт, поэтому задайте другой домен
      tls: ## Если старая версия использует https, необходимо настроить tls, иначе не настраивайте следующий блок
        - secretName: <spec.service.ingress.secretName из YAML старого экземпляра> ## Сертификат старой версии может находиться в cpaas-system, его нужно скопировать в namespace развертывания экземпляра
          hosts:
            - <spec.service.ingress.domainName из YAML старого экземпляра>

Конфигурация NodePort:

spec:
  helmValues:
    service:
      name: sonarqube
      type: NodePort
      nodePort: <spec.service.nodePort.port из YAML старого экземпляра> ## Примечание: при наличии старого экземпляра использование того же nodePort в новом вызовет конфликт, задайте другой nodePort

Настройка spec.externalURL:

spec:
  ## Если конфигурация сети — Ingress, значение <new-sonar-url> — <spec.service.ingress.domainName из YAML старого экземпляра>
  ## Если конфигурация сети — NodePort, получите IP командой kubectl get nodes -o jsonpath='{.items[0].status.addresses[?(@.type=="InternalIP")].address}'. Значение <new-sonar-url> — IP:<nodePort>
  externalURL: <new-sonar-url>

#2.4 Другие настройки

• Сохранение плагинов: в новой версии необходимо сохранить плагины старой версии. Добавьте конфигурацию spec.helmValues.plugins.deleteDefaultPlugins со значением false
• Миграция конфигурации SSO: перенастройте согласно Документации по развертыванию: Конфигурация SSO
• Миграция конфигурации ресурсов: настройте spec.helmValues.resources нового экземпляра на основе spec.resourceAssign старого экземпляра
• Миграция конфигурации helmValues: большинство данных из helmValues старого экземпляра можно напрямую перенести в helmValues нового экземпляра. Например, spec.helmValues.jvmOpts можно напрямую перенести в spec.helmValues.jvmOpts нового экземпляра.

Пример полного YAML для новой версии:

apiVersion: operator.alaudadevops.io/v1alpha1
kind: Sonarqube
metadata:
  name: new-sonarqube
spec:
  helmValues:
    plugins:
      deleteDefaultPlugins: false # Сохранить плагины старой версии
    prometheusExporter: # Отключить стандартный мониторинг prometheus, jar-пакеты нужно добавить заранее при запуске
      enabled: false
    resources: # Установить лимиты ресурсов, из spec.resourceAssign в YAML старого экземпляра
      limits:
       cpu: 800m
       memory: 4Gi
      requests:
       cpu: 400m
       memory: 2Gi
    postgresql: # Отключить стандартный экземпляр PostgreSQL
      enabled: false
    jdbcOverwrite: # Настроить с использованием информации PG из старого экземпляра
      enable: true
      jdbcSecretName: sonarqube-db-secret # Использовать имя созданного секрета
      jdbcUrl: jdbc:postgresql://<pg.host>:<pg.port>/<pg.database>?socketTimeout=1500
      jdbcUsername: <pg.username>
    service: # Настроить на основе старого экземпляра
      name: sonarqube
      type: NodePort
      nodePort: <spec.service.nodePort.port из YAML старого экземпляра>
    persistence: # Настроить на основе старого экземпляра
      enabled: true
      existingClaim: <spec.persistence.pvc.webServiceExistingClaim из YAML старого экземпляра>

#3. Выполните миграцию схемы данных вручную

Перейдите по адресу new-sonar-url/setup и следуйте подсказкам

#4. Проверьте результаты обновления

Проверьте следующее, чтобы убедиться в успешности обновления:

• Все данные проектов сохранены полностью
• Пользовательские аккаунты и права корректны
• Состояние плагинов в норме (некоторые плагины могут потребовать переустановки)
• Доступны исторические данные анализа

#5. Очистка

1. После подтверждения стабильной работы нового экземпляра старый экземпляр можно удалить
2. Приведите конфигурацию сети в соответствие с исходной

#Reference Documents

• SonarQube Backup Documentation
• SonarQube Deployment Documentation