Aller au contenu principal

Mettre à jour l'instance

Ce que fait une mise à jour​

BaaStide vous donne un nouveau bundle pour chaque version. La mise à jour remplace la définition des services et le dossier de configuration par ceux du nouveau bundle, garde vos réglages et vos secrets, puis télécharge et redémarre les images qui ont changé.

Les migrations de la base de données s'appliquent au démarrage, avant les autres services.

Le nouveau bundle apporte aussi le média de restauration bare metal de la nouvelle version et une nouvelle version de l'agent. Vous choisissez quand vos agents passent à cette version.

La mise à jour ne change ni vos clients, ni vos politiques, ni vos points de restauration.

Prérequis​

  • Un accès root sur l'hôte, ou un compte membre du groupe docker, dans le dossier de déploiement de l'instance.
  • Le bundle baastide-onprem-<version>.tar.gz de la nouvelle version, et l'accès au registre d'images de BaaStide.
  • Une sauvegarde à la main de la base de données, faite juste avant. Voir Sauvegarder et restaurer l'instance.
  • Un accès HTTPS sortant vers le registre d'images de BaaStide.

Lancez toutes les commandes dans bash, dans le dossier de déploiement de l'instance.

1. Appliquer la nouvelle version​

  1. Sauvegardez la base de données à la main. Voir « Sauvegarder à la main » dans Sauvegarder et restaurer l'instance.

  2. Ouvrez l'archive du nouveau bundle, hors du dossier de déploiement.

  3. Remplacez docker-compose.yml et le dossier config/ par ceux du nouveau bundle. Gardez .env et le dossier secrets/.

  4. Ouvrez .env et réglez BAASTIDE_VERSION sur la nouvelle version.

  5. Créez les fichiers de secrets que l'ancien bundle n'avait pas, puis démarrez la nouvelle version :

    [ -e secrets/m365-relay-key ] || install -m 0444 /dev/null secrets/m365-relay-key
    [ -e secrets/backup-s3-secret-key ] || install -m 0444 /dev/null secrets/backup-s3-secret-key
    [ -e secrets/pool-root-s3 ] || install -m 0444 /dev/null secrets/pool-root-s3
    [ -e secrets/m365-s3-secret-key ] || install -m 0444 /dev/null secrets/m365-s3-secret-key
    [ -e secrets/backup-passphrase ] || (umask 0377 && openssl rand -base64 33 | tr -d '\n' > secrets/backup-passphrase && chmod 0444 secrets/backup-passphrase)
    [ -e secrets/share-key ] || (umask 0377 && openssl rand -base64 32 | tr -d '\n' > secrets/share-key && chmod 0444 secrets/share-key)
    [ -e secrets/vapid-key ] || install -m 0444 /dev/null secrets/vapid-key
    docker compose pull
    docker compose up -d --wait

  6. Appliquez les nouvelles règles d'accès du service redis. Ce service lit ses règles à son démarrage seulement. La commande up écrit le fichier du nouveau bundle, mais elle ne redémarre pas redis quand son image est la même. La commande ci-dessous compare le fichier avec celui que redis a chargé, et elle redémarre redis seulement quand les deux diffèrent.

    docker compose exec -T redis sh -c 'sha256sum < /run/secrets/redis/users.acl | cmp -s - /tmp/users.acl.sha256' ||
      docker compose up -d --wait --force-recreate --no-deps redis

    Le redémarrage prend quelques secondes. Les autres services se reconnectent et les files d'attente restent en place.

  7. Recréez le service d'entrée. L'étape 3 a remplacé le dossier config/. Voir « 2. Recharger le service d'entrée » plus bas.

  8. Vérifiez l'état des services.

    docker compose ps

Les commandes de l'étape 5 créent les fichiers absents : la clé du relais Microsoft 365, vide, la clé secrète du bucket Microsoft 365, vide, la clé secrète du bucket de sauvegarde, vide, la clé de la racine des buckets, vide, la phrase secrète de la sauvegarde de la plateforme, la clé des mots de passe des partages réseau et la clé des notifications push, vide. Les services ne démarrent pas sans ces fichiers.

Une licence d'essai a besoin de la clé de la racine des buckets. Avec un fichier vide, l'instance ne démarre pas de licence d'essai. Voir Importer une licence.

Quand la commande crée une nouvelle phrase secrète de sauvegarde, copiez-la aussitôt dans votre gestionnaire de mots de passe, hors de l'hôte. La sauvegarde de la plateforme prend la nouvelle clé des partages réseau à sa prochaine exécution.

La clé des mots de passe SQL Server et la clé de l'identité de l'instance ne demandent aucune commande. Le premier démarrage du nouveau bundle les crée dans leurs volumes, et la sauvegarde de la plateforme les prend à sa prochaine exécution.

Vous n'attendez pas la fin des sauvegardes en cours. La commande up ne recrée que les services qui ont changé, pas le transport des données des agents quand son image est la même. Les services de tâches rendent leur travail en cours à l'arrêt, en 30 secondes au plus : une tâche de maintenance repart, et une sauvegarde Microsoft 365 reprend à son point de reprise.

2. Recharger le service d'entrée​

Le service d'entrée lit quatre fichiers de config/ à son démarrage : sa configuration, son script de démarrage, son script des révocations et sa table des buckets. Quand vous remplacez le dossier config/ par un autre, avec tar -x, mv ou la plupart des éditeurs, le service garde les anciens fichiers. Il faut alors le recréer.

  1. Après un remplacement du dossier config/, recréez toujours le service :

    docker compose up -d --force-recreate --no-deps haproxy

    Les sauvegardes des agents en cours reprennent leurs envois ouverts et continuent.

  2. Après un changement sur place d'un fichier de config/, une recharge suffit :

    docker compose kill -s USR2 haproxy

    Les connexions ouvertes des agents restent en place. Les nouvelles connexions des agents peuvent recevoir une erreur pendant un court moment, le temps que l'instance rende de nouveau la liste des agents révoqués. Les agents réessaient seuls.

Ne choisissez pas entre la recréation et la recharge d'après l'empreinte d'un seul fichier. Un nouveau bundle peut changer le script des révocations sans changer la configuration. Une recharge garderait alors l'ancien script. Le script de démarrage, lui, n'est lu qu'à la création du conteneur : une recharge ne l'applique jamais.

3. Enregistrer la nouvelle version de l'agent​

Le nouveau bundle contient une version de l'agent. Enregistrez cette version, puis choisissez quand vos agents y passent.

  1. Copiez les manifestes signés de la version hors du service qui les sert, puis enregistrez la version :

    v=$(cat config/agent-version)
    rm -rf agent-release && mkdir -p agent-release/windows-amd64
    for f in manifest.json manifest.sig windows-amd64/manifest.json windows-amd64/manifest.sig; do
      if docker compose exec -T releases test -e "/srv/releases/$v/$f"; then docker compose cp "releases:/srv/releases/$v/$f" "agent-release/$f"; fi
    done
    chmod -R a+rX agent-release
    docker compose run --rm -T -v "$PWD/agent-release:/run/agent-release:ro" admin \
      register-agent-release --dir /run/agent-release --version "$v" --set-production

  2. Vérifiez la version dans le portail. Dans le menu Plateforme, cliquez Versions de l'agent.

La commande contrôle la signature de chaque manifeste. Elle refuse une signature fausse. Vous relancez la commande sans risque : une version déjà enregistrée n'est pas changée.

L'option --set-production lance le déploiement tout de suite. L'instance envoie la mise à jour aux agents en ligne, quelques agents par minute, et jamais pendant une tâche. Elle n'envoie rien quand le déploiement est arrêté : contrôlez la page Déploiement du menu Plateforme. Voir Mise à jour automatique de l'agent.

Pour déployer plus tard, lancez la commande sans --set-production. Choisissez ensuite la version de production dans le portail, sur la page Versions de l'agent.

4. Après la mise à jour​

  1. Ouvrez le portail avec un compte Administrateur plateforme.
  2. Dans le menu Plateforme, cliquez Santé. Vérifiez que les gateways et les workers donnent un signal récent, et que les files n'ont aucune tâche en échec. Voir Exploiter l'instance.
  3. Dans le menu Plateforme, cliquez Vue d'ensemble. Vérifiez la carte Sauvegarde de la plateforme.
  4. Donnez le nouveau média de restauration aux techniciens qui préparent des clés USB de restauration. Voir Préparer le média de restauration.

Limites et précautions​

  • Ne modifiez pas docker-compose.yml. Une mise à jour remplace ce fichier. Mettez vos changements locaux dans docker-compose.override.yml.
  • Copiez le dossier config/ du nouveau bundle et réglez BAASTIDE_VERSION dans la même mise à jour. Le fichier config/recovery-iso.env donne la version et l'empreinte du média de restauration à l'API. Sans ce fichier, l'API ne démarre pas.
  • Gardez .env. Ce fichier porte aussi la liste des services optionnels de votre instance. Avec Microsoft 365 actif, la mise à jour télécharge aussi les images Microsoft 365, et elle applique leurs migrations au démarrage.
  • Remplacez le dossier config/ et recréez le service d'entrée. Sans cette recréation, le service garde les anciens fichiers, dont son script des révocations.
  • Ne sautez pas la sauvegarde de la base de données. Voir Sauvegarder et restaurer l'instance.
  • Une remise en service à partir d'une archive demande le bundle de la même version que l'archive. Mettez à jour après la remise en service, pas pendant.
  • Un agent qui reste trop ancien ne sauvegarde plus. Voir Agent trop ancien.