#Руководство по обновлению 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 необходимо мигрировать на новый оператор.

#Предварительные требования

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

#Шаги обновления

#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. Приведите сетевую конфигурацию в соответствие с исходной

#Справочные документы

• Документация по резервному копированию SonarQube
• Документация по развертыванию SonarQube