Fermer

décembre 21, 2023

Préparation à la mise à niveau de la base de données Sitecore / Blogs / Perficient

Préparation à la mise à niveau de la base de données Sitecore / Blogs / Perficient


Récemment, mes collègues et moi avons été chargés de mettre à niveau une solution conteneurisée de Sitecore 9.3.0 vers 10.3.1, ce qui m’a enthousiasmé car cela faisait une minute que je n’avais pas effectué de mise à niveau de Sitecore. Les étapes de mise à niveau ont considérablement évolué au fil de ces années et j’avais très envie de les explorer et de les exécuter.

Nous avons divisé la mise à niveau en 3 étapes principales répertoriées ci-dessous et j’ai effectué les étapes de mise à niveau de la base de données pendant que mes coéquipiers travaillaient sur les 2 autres étapes.

  1. Mettre à niveau la base de données
  2. Mettre à niveau la solution VS
  3. Mettez à niveau les fichiers Docker.

Dans cette série de blogs en 3 parties, nous couvrirons en détail l’étape 1 qui implique la mise à niveau des bases de données sitecore de 9.3.0 à 10.3.1. Dans cette première partie, nous examinerons en profondeur les conditions préalables requises pour la mise à niveau et les étapes nécessaires pour s’y préparer.

Conditions préalables à la mise à niveau

  1. Vous devez connaître la version de votre hôte local Windows ltsc et la topologie de votre sitecore. Pour moi, la version ltsc était 2019 et la topologie sitecore était xp0.
  2. Aller à https://dev.sitecore.net/Downloads/Sitecore_Experience_Platform/103/Sitecore_Experience_Platform_103_Update1.aspx et consultez le « Guide de déploiement de conteneurs de mise à niveau ».
  3. Téléchargez et extrayez le package Sitecore Container Deployment via le lien « Container Deployment Package » présent sur https://dev.sitecore.net/Downloads/Sitecore_Experience_Platform/103/Sitecore_Experience_Platform_103_Update1.aspx dans un dossier sur votre local, par exemple C:/sitecoreupgrade.
  4. En fonction de votre version et de votre topologie ltsc, accédez au dossier correspondant et examinez son contenu.
    • Dans mon cas, c’était C:\sitecoreupgrade\SitecoreContainerDeployment.10.3.1.009452.1448\compose\ltsc2019\upgrade\xp1
      • Comme il n’y avait pas de dossier pour xp0, nous avons décidé d’utiliser le dossier de topologie xp1
      • Nous avons opté pour le dossier de composition car nous utilisions Docker et non Kubernetes
    • Dans le dossier xp1, examinez le contenu de docker-compose.upgrade.yml pour identifier toutes les sauvegardes de bases de données (voir les lignes 7 à 16 dans la capture d’écran ci-dessous) dont vous avez besoin de prod.
    services:
  mssql-upgrade:
    image: ${SITECORE_DOCKER_REGISTRY}sitecore-xp1-mssql-upgrade:${SITECORE_VERSION}
    environment:
      IS_ALWAYS_ENCRYPTED: ${IS_ALWAYS_ENCRYPTED}
      PROCESSING_ENGINE_TASKS_DATABASE_USERNAME: ${PROCESSING_ENGINE_TASKS_DATABASE_USERNAME}
      Sitecore_ConnectionStrings_Core: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Core;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Sitecore_ConnectionStrings_Master: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Master;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Sitecore_ConnectionStrings_Web: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Web;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Sitecore_ConnectionStrings_Experienceforms: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Experienceforms;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Sitecore_ConnectionStrings_Processing_Engine_Tasks: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Processing.Engine.Tasks;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Sitecore_ConnectionStrings_Messaging: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Messaging;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Sitecore_ConnectionStrings_Reporting: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Reporting;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Sitecore_ConnectionStrings_Xdb_Collection_Shard0: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Xdb.Collection.Shard0;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Sitecore_ConnectionStrings_Xdb_Collection_Shard1: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Xdb.Collection.Shard1;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Sitecore_ConnectionStrings_Marketingautomation: Data Source=${SQL_SERVER};Initial Catalog=${SQL_DATABASE_PREFIX}.Marketingautomation;User ID=${SQL_USERNAME};Password=${SQL_PASSWORD}
      Database_Upgrade_From_Version: ${DATABASE_UPGRADE_FROM_VERSION}
      Database_Upgrade_To_Version: ${DATABASE_UPGRADE_TO_VERSION}
      Sitecore_License: ${SITECORE_LICENSE}
    isolation: ${ISOLATION}

  5. Avant d’effectuer la sauvegarde de la base de données prod, vous pouvez créer/vérifier une connexion sur prod sitecore que vous pouvez utiliser pour vous connecter à sitecore sur l’hôte local afin de nettoyer les bases de données et d’effectuer les étapes de post-mise à niveau.

Étapes de préparation à la mise à niveau

  1. Effectuez des sauvegardes des bases de données de production 9.3.0 existantes sur Azure.
    • Ceux-ci ont généralement des extensions bacpac
    • Nous avions sauvegardé les fichiers bacpac dans un conteneur Blob
  2. Téléchargez et installez « Microsoft Azure Storage Explorer ».
  3. Ouvrez l’explorateur de stockage Azure et connectez-vous au conteneur Blob via ces étapes
        • Accédez au nœud « Comptes de stockage » dans Azure Explorer et cliquez avec le bouton droit.
        • Sélectionnez « Se connecter au stockage Azure »
        • Sélectionnez « Conteneur ou répertoire Blob » comme ressource Azure
        • Sélectionnez votre méthode de connexion préférée. Comme notre équipe DevOps avait partagé avec moi l’URL SAS du conteneur Blob, je l’ai utilisée comme méthode de connexion. Après vous être connecté à Blob Container, téléchargez les fichiers bacpac
      Méthode de connexion Azure

      Sélectionnez SAS comme méthode de connexion

  4. Sur votre local, démarrez tous les conteneurs de votre solution 9.3.0.
  5. Connectez-vous à l’instance de serveur SQL présente dans le conteneur SQL à l’aide de SSMS sur votre hôte local. Le nom du serveur SQL a généralement cette syntaxe : « 127.0.0.1, numéro de port ». Par exemple 127.0.0.1,1433
  6. Effectuez des sauvegardes des bases de données 9.3.0 existantes depuis le local via SSMS.
  7. Activez l’authentification de la base de données confinée en exécutant cette commande suivante dans SSMS.
    sp_configure 'contained database authentication', 1;  
GO  
RECONFIGURE;  
GO
  8. Importez tous les fichiers bacpac de la production sur l’hôte local via la fonctionnalité « Importer une application de niveau données » dans SSMS. Vous pouvez ajouter le texte « .Prod » au nouveau nom de la base de données afin de pouvoir différencier la version prod de la version locale des bases de données. Par exemple « Sitecore.Master.Prod ». Voir les captures d’écran ci-dessous pour référence.
    Importer le fichier bacpac dans SSMS

    Importer le fichier bacpac dans SSMS

    Ajouter le texte ".Prod" au nouveau nom de la base de données

    Ajoutez le texte « .Prod » au nouveau nom de la base de données

    Note:- Nous avons observé que notre volume de conteneur SQL se plaignait de l’espace disque à cet emplacement « C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA ». Nous avons donc fini par changer cela en « C:\Data » pour le chemin du fichier de données et le chemin du fichier journal. La raison étant que le chemin « C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA » se trouvait à l’intérieur du conteneur et disposait d’un espace limité. Par conséquent, le changer en « C:\Data » (qui revient à mon hôte local via le montage de volume comme mentionné dans les étapes ci-dessous) lui a fait utiliser l’espace disque de mon hôte local.

  9. Arrêtez le conteneur SQL via cette commande « docker stop » Par exemple docker stop my_container
  10. Consultez la section de service « sql » du fichier docker-compose de votre solution et observez le chemin de l’hôte local défini sous le volume. Dans mon cas, il s’agissait du dossier data\sql (voir la ligne n°7 dans la capture d’écran ci-dessous) dans le dossier docker de la solution.
    sql:
    image: ${REGISTRY}sitecore-xp-sxa-sqldev:${SITECORE_VERSION}-windowsservercore-${WINDOWSSERVERCORE_VERSION}
    isolation: ${ISOLATION}
    restart: ${RESTART_POLICY:-unless-stopped}
    hostname: ${SQL_HOST}
    volumes:
      - .\data\sql:C:\Data
    networks:
      default:
        aliases:
          - ${SQL_HOST}
    mem_limit: 2GB
    ports:
      - "1433:1433"
    environment:
      SA_PASSWORD: ${SQL_SA_PASSWORD}
      ACCEPT_EULA: "Y"
      SQL_HOSTNAME: ${SQL_HOST}
    # Allows for access to the database through traefik to support using database locally.
    # This should not be used in production.
    #
    # Since this is not http, but tcp traffic it does does not understand the concept of a "host".
    # so we must dedicate a port to it in traefik, and direct all traffic to this router: HostSNI(`*`).
    labels:
      - "traefik.enable=true"
      - "traefik.tcp.routers.${COMPOSE_PROJECT_NAME}-sql.entrypoints=sql"
      - "traefik.tcp.routers.${COMPOSE_PROJECT_NAME}-sql.rule=HostSNI(`*`)"
      - "traefik.tcp.routers.${COMPOSE_PROJECT_NAME}-sql.service=${COMPOSE_PROJECT_NAME}-sql"
      ## Service for SQL requests
      - "traefik.tcp.services.${COMPOSE_PROJECT_NAME}-sql.loadbalancer.server.port=1433"

  11. Accédez au dossier docker\sql\data dans votre solution et
    • Observez les noms des données locales 9.3.0 et des fichiers journaux. Par exemple, Sitecore.Master, Sitecore.Core, etc.
    • Déplacez tous les fichiers mdf et ldf liés aux bases de données de production que vous avez importées dans les étapes ci-dessus vers un autre dossier, par exemple C:\sitecoreupgrade\proddbs
    • Renommez les fichiers dans le dossier « C:\sitecoreupgrade\proddbs » pour qu’ils correspondent aux noms de fichiers des fichiers locaux 9.3.0. Par exemple, renommer « Sitecore.Master.Prod » en « Sitecore.Master »
    • Copiez les fichiers de « C:\sitecoreupgrade\proddbs » vers le dossier « docker\sql\data » de votre solution et remplacez les fichiers existants
  12. Redémarrez le conteneur SQL via cette commande « docker start ». Note:- L’instance sitecore peut prendre quelques minutes pour s’afficher lorsque vous redémarrez le conteneur SQL. D’ici là, une erreur de délai d’attente SQL peut s’afficher.
  13. Créez votre solution VS.
  14. Supprimez les bases de données ayant « .Prod » dans leur nom pour libérer de l’espace disque.(Facultatif)
  15. À ce stade, votre site local utilise la base de code 9.3.0 à partir de la version locale et de production des bases de données 9.3.0. Si vous disposez d’une connexion sitecore de production, vous pouvez essayer de vous connecter à votre instance sitecore locale en l’utilisant pour vérifier que vous voyez le contenu de production.
  16. Connectez-vous à nouveau au conteneur SQL via SSMS et créez une nouvelle connexion, par exemple « sitecoreupgrade », et attribuez-lui le rôle d’adhésion « propriétaire de base de données » pour toutes les bases de données sitecore.

Cela couvre les conditions préalables et les étapes de préparation nécessaires pour effectuer la mise à niveau de la base de données.
Dans la partie 2, nous passerons en revue les étapes à suivre pour effectuer la mise à niveau réelle des bases de données. Enfin, nous examinerons les étapes qui doivent être exécutées après la mise à niveau de nos bases de données sitecore et de notre base de code vers 10.3.1.



Le meilleur outil 2023 pour ta croissance Instagram !



Source link

décembre 21, 2023