Aller au contenu principal

Installer l'instance

Ce que fait l'installation​

L'installation pose la plateforme BaaStide sur votre hôte Docker, à partir d'un bundle que BaaStide vous donne. Vous réglez les valeurs de votre site, vous créez les secrets, vous posez le certificat, puis vous démarrez les services.

La dernière commande initialise l'instance. Elle crée l'identifiant de l'installation, la première invitation d'administrateur de la plateforme, le pool de stockage de votre S3 et son premier bucket.

L'installation ne crée aucun client et aucun agent. Voir Première configuration.

Prérequis​

  • L'hôte, le réseau, les noms DNS, le certificat et les secrets préparés. Voir Avant d'installer une instance.
  • Le bundle baastide-onprem-<version>.tar.gz et l'accès au registre d'images de BaaStide.
  • Un accès root sur l'hôte, ou un compte membre du groupe docker.

Lancez toutes les commandes dans bash, dans le dossier du bundle.

1. Récupérer le bundle​

  1. Connectez-vous au registre d'images de BaaStide avec les identifiants que BaaStide vous a donnés.

    docker login <registre>

  2. Ouvrez l'archive du bundle et entrez dans son dossier.

    tar -xzf baastide-onprem-<version>.tar.gz
    cd baastide-onprem-<version>

Le bundle contient :

FichierRôle
docker-compose.ymlLa définition des services de l'instance. Ne le modifiez pas : mettez vos changements locaux dans docker-compose.override.yml.
.env.exampleLes valeurs de votre site, à copier dans .env.
config/La configuration de l'instance, les scripts d'initialisation et les clés publiques des signatures de BaaStide.
INSTALL.mdLe guide d'installation de cette version.
recovery/L'ISO de restauration bare metal de cette version, ses empreintes et sa signature.

L'instance sert elle-même l'ISO de restauration, sans accès à Internet. Le portail donne son lien, son empreinte SHA-256 et l'état de sa signature. Voir Préparer le média de restauration.

2. Régler les valeurs du site​

  1. Copiez le modèle de configuration.

    cp .env.example .env

  2. Ouvrez .env et réglez ces valeurs :

    ValeurCe qu'elle contient
    PUBLIC_URLhttps:// et le nom DNS de l'instance. Ajoutez :<port> quand le port n'est pas 443.
    DATA_PLANE_URLLe second nom DNS des données de sauvegarde, par exemple https://data.backup.example.com. Laissez la valeur vide pour utiliser PUBLIC_URL.
    S3_PROVIDERMinio, Ceph ou Other.
    S3_ENDPOINTL'adresse de votre point d'accès S3.
    S3_REGIONLa région de votre stockage S3.
    S3_ACCESS_KEY_IDL'identifiant de votre clé d'accès S3.
    S3_FORCE_PATH_STYLEtrue pour la plupart des stockages S3 installés chez vous : le nom du bucket est dans le chemin, pas dans le nom d'hôte.
    SMTP_FROML'expéditeur des emails, par exemple BaaStide <backup@example.com>.

  3. Gardez BAASTIDE_REGISTRY et BAASTIDE_VERSION tels que le bundle les donne.

Ne mettez aucun secret dans .env. Les secrets sont des fichiers, à l'étape suivante.

Le fichier .env.example porte d'autres valeurs, toutes optionnelles : le port publié, la sauvegarde de la plateforme, les limites de débit par agent, l'accès MCP et la sauvegarde Microsoft 365. Chaque valeur est expliquée dans le fichier.

3. Créer les secrets​

Les secrets sont des fichiers du dossier secrets/. Ils ne sont jamais des variables d'environnement. Chaque fichier n'est monté que dans les services qui en ont besoin.

  1. Créez le dossier et les secrets tirés au hasard : le mot de passe du compte propriétaire de la base de données, la clé des secrets de la vérification en deux étapes, la clé des liens des emails et la clé des mots de passe des partages réseau.

    install -d -m 0700 secrets
    openssl rand -hex 32 | tr -d '\n' > secrets/postgres-owner-password
    openssl rand -base64 32 | tr -d '\n' > secrets/mfa-key
    openssl rand -base64 32 | tr -d '\n' > secrets/cancel-link-key
    openssl rand -base64 32 | tr -d '\n' > secrets/share-key

  2. Saisissez la clé secrète de votre clé d'accès S3, puis l'URL de votre serveur SMTP avec son mot de passe.

    read -rsp 'Cle secrete S3 : ' S3_SECRET_KEY && printf '%s' "$S3_SECRET_KEY" > secrets/s3-secret-key && unset S3_SECRET_KEY && echo
    read -rsp 'URL SMTP : ' SMTP_URL && printf '%s' "$SMTP_URL" > secrets/smtp-url && unset SMTP_URL && echo

    L'URL SMTP prend la forme smtp://utilisateur:motdepasse@smtp.example.com:587, ou smtps://…:465. Encodez les caractères spéciaux de l'utilisateur et du mot de passe au format URL : @ s'écrit %40.

  3. Créez la passphrase de la sauvegarde de la plateforme, puis les fichiers vides des secrets optionnels. Ces fichiers doivent exister, même vides.

    openssl rand -base64 33 | tr -d '\n' > secrets/backup-passphrase
    for f in backup-s3-secret-key pool-root-s3 m365-s3-secret-key m365-relay-key; do [ -e "secrets/$f" ] || : > "secrets/$f"; done

  4. Copiez le contenu de secrets/backup-passphrase dans un gestionnaire de mots de passe ou dans un coffre, hors de cet hôte.

  5. Créez la clé des notifications push, ou un fichier vide pour laisser les notifications push arrêtées.

    openssl rand -base64 32 | tr -d '\n' > secrets/vapid-key

    Avec un fichier vide (: > secrets/vapid-key), la page Mon compte du portail ne propose pas les notifications push. Les alertes par email fonctionnent comme d'habitude.

Deux clés ne sont pas créées à la main. L'instance les crée à son premier démarrage et ne les change jamais : la clé des mots de passe SQL Server, dans le volume Docker mssql-key, et la clé de l'identité de l'instance pour la licence, dans le volume Docker license-key. La sauvegarde de la plateforme contient ces deux clés.

Clé de la racine des buckets (licence d'essai)​

Une licence d'essai ne démarre que sur des buckets vides. L'instance écrit une marque d'essai signée à la racine de chaque bucket, et elle lève cette marque quand vous importez la licence payante. L'instance fait ces lectures et ces écritures avec une clé d'accès S3 à part, dans secrets/pool-root-s3.

Sans cette clé, l'instance refuse une licence d'essai. Elle vous sert aussi pour importer la licence payante d'une instance qui était en essai. Une instance qui n'a jamais été en essai n'a pas besoin de cette clé : laissez le fichier vide.

  1. Chez votre fournisseur S3, créez une nouvelle clé d'accès. N'utilisez pas la clé de l'étape 2.

  2. Donnez-lui ces droits seulement, sur chaque bucket de l'instance :

    • s3:ListBucket sur le bucket, sans condition de préfixe ;
    • s3:GetObject et s3:PutObject sur <bucket>/.baastide/*.

  3. Ne donnez pas s3:DeleteObject.

  4. Saisissez l'identifiant et la clé secrète.

    chmod u+w secrets/pool-root-s3
    read -rp 'Identifiant de la cle racine : ' POOL_ROOT_KEY_ID && read -rsp 'Cle secrete racine : ' POOL_ROOT_SECRET && echo &&
      printf '{"accessKeyId":"%s","secretAccessKey":"%s","forcePathStyle":%s}' "$POOL_ROOT_KEY_ID" "$POOL_ROOT_SECRET" \
        "$(grep -qx 'S3_FORCE_PATH_STYLE=false' .env && echo false || echo true)" > secrets/pool-root-s3
    unset POOL_ROOT_KEY_ID POOL_ROOT_SECRET
    chmod 0444 secrets/pool-root-s3

Une clé qui contient " ou \ n'est pas acceptée.

Certains fournisseurs ne peuvent pas limiter une clé à un préfixe. Vous devez alors donner à l'instance la clé de l'étape 2. Avec cette clé, un attaquant qui prend le contrôle de l'instance peut supprimer ou changer les données de sauvegarde de tous les clients du pool. Quand votre fournisseur ne peut pas limiter la clé, n'utilisez pas de licence d'essai sur cette instance : importez une licence payante et laissez secrets/pool-root-s3 vide.

4. Poser le certificat​

Posez deux fichiers dans secrets/ :

FichierContenu
secrets/tls.pemLe certificat du nom DNS, puis les certificats intermédiaires, puis la clé privée. Tout au format PEM, dans un seul fichier.
secrets/control-ca.pemLe certificat de l'autorité racine de cette chaîne. Les agents l'épinglent pour leur canal de contrôle.

Avec un certificat de votre autorité de certification :

cat /chemin/vers/backup.example.com.crt /chemin/vers/intermediaire.crt /chemin/vers/backup.example.com.key > secrets/tls.pem
cp /chemin/vers/racine-ca.crt secrets/control-ca.pem

Avec Let's Encrypt et certbot :

certbot certonly --standalone -d backup.example.com
cat /etc/letsencrypt/live/backup.example.com/fullchain.pem /etc/letsencrypt/live/backup.example.com/privkey.pem > secrets/tls.pem
curl -fsS https://letsencrypt.org/certs/isrgrootx1.pem > secrets/control-ca.pem

Après chaque renouvellement, reconstruisez secrets/tls.pem de la même façon, sur place, avec cat >. N'utilisez pas mv : le conteneur voit le fichier qu'il a monté au démarrage. Rechargez ensuite le service d'entrée :

docker compose kill -s USR2 haproxy

Les connexions ouvertes des agents restent en place. L'autorité racine ne change pas à un renouvellement.

Rendez enfin les secrets lisibles dans les conteneurs :

chmod 0444 secrets/*
ls -l secrets

Le changement de l'autorité racine se fait en deux étapes. Voir Canal de contrôle et épinglage de la CA.

5. Démarrer les services​

docker compose up -d --wait
docker compose ps

Le premier démarrage télécharge les images. L'option --wait rend la main quand tous les services sont sains. Les migrations de la base de données s'appliquent à chaque démarrage, avant les autres services.

6. Initialiser l'instance​

  1. Réglez les valeurs de l'initialisation : l'email du premier administrateur de la plateforme, la langue de son invitation (en ou fr), le nom de votre bucket et sa taille cible en octets.

    ADMIN_EMAIL=admin@example.com
    ADMIN_LOCALE=fr
    BUCKET=baastide-backups
    BUCKET_TARGET_BYTES=10995116277760

    BaaStide place les nouveaux dépôts dans les buckets qui sont sous leur taille cible.

  2. Lancez l'initialisation.

    docker compose run --rm -T admin init --mode onprem --admin-email "$ADMIN_EMAIL" --admin-locale "$ADMIN_LOCALE" \
      --pool p1 --pool-endpoint "$(sed -n 's/^S3_ENDPOINT=//p' .env)" --pool-region "$(sed -n 's/^S3_REGION=//p' .env)" \
      --pool-credentials-ref s3 --bucket "$BUCKET" --bucket-target-bytes "$BUCKET_TARGET_BYTES" < /dev/null | tee instance-id

  3. Gardez l'identifiant d'instance que la commande affiche. La commande l'écrit aussi dans le fichier instance-id.

Gardez le nom de pool p1 et la référence d'identifiants s3 : ils correspondent au transport des données de l'instance. La commande ne demande et n'enregistre aucun mot de passe initial.

L'administrateur de la plateforme reçoit son invitation par email. Continuez avec Première configuration.

Limites et précautions​

  • Ne modifiez pas docker-compose.yml. Mettez vos changements locaux dans docker-compose.override.yml. Une mise à jour remplace docker-compose.yml.
  • Sans la passphrase de secrets/backup-passphrase, les sauvegardes de la plateforme ne peuvent pas être ouvertes. Gardez cette passphrase hors de l'hôte.
  • Ne supprimez pas les volumes mssql-key et license-key. Sans la clé des mots de passe SQL Server, il faut saisir à nouveau le mot de passe de chaque instance SQL Server. Sans la clé de l'identité de l'instance, l'instance ne peut plus importer de licence, et elle ne fait plus de sauvegarde.
  • Ne changez pas la clé des notifications push après le démarrage. Avec une nouvelle clé, chaque appareil doit activer les notifications à nouveau.
  • Une seconde exécution de l'initialisation ne change rien. Elle affiche le même identifiant d'instance.
  • Une licence d'essai ne démarre que sur des buckets vides, et elle a besoin de la seconde clé d'accès S3 dans secrets/pool-root-s3. La sauvegarde de la plateforme ne contient pas cette clé : saisissez-la à nouveau après une restauration de la plateforme.