Aller au contenu principal

Stockage

Disponible

Fonctionnalité déployée et prise en charge. Les champs et commandes décrits ici sont stables au sein de la version v1alpha1.

Un service peut monter un ou plusieurs volumes persistants : les données survivent aux redémarrages, aux mises à jour et même à la suppression de l'App. En contrepartie, un service avec volume tourne en un seul exemplaire.

Prérequis​

  • Une App en cours d'écriture (Depuis docker compose).
  • Une image qui écrit dans un chemin connu (/var/lib/postgresql/data, /data…) et qui tourne sous un uid non administrateur : le volume appartient à l'uid donné dans user.

Étapes​

1. Déclarer le volume​

db.yml
apiVersion: deploy.stackngo.io/v1alpha1
kind: App
metadata:
  name: db
spec:
  services:
    postgres:
      image: postgres:17
      user: "999"                                   # uid de postgres : le volume lui appartient
      ports: ["5432"]
      env:
        PGDATA: /var/lib/postgresql/data/pgdata
        POSTGRES_PASSWORD: { secret: db, key: password }
      healthcheck: { cmd: ["pg_isready", "-U", "postgres"] }
      volumes:
        - { path: /var/lib/postgresql/data, size: 10Gi }

Pas de replicas, pas d'autoscale, pas de strategy (ou strategy: { type: recreate }) : le schéma refuse le manifeste sinon.

2. Appliquer​

sng apply db.yml
sng app describe db
App      : db
Statut   : prête
SERVICE   KIND        IMAGE        PHASE  URL  DETAIL
postgres  deployment  postgres:17  Ready  -    Reconciled 1/1 prêts

Vérification​

Écrivez dans la base, puis sng app restart db : les données sont toujours là après le redémarrage. sng app patch db --image postgres:17.2 fait de même : le service est arrêté, puis redémarré sur le même volume.

Ce qu'il faut savoir​

PointComportement
Accèsun seul exemplaire du service à la fois
replicas0 ou 1 seulement ; sng app scale db 2 est refusé
autoscaleinterdit
strategytoujours recreate : le service est arrêté avant d'être redémarré (coupure le temps du redémarrage)
Taillesize: 10Gi ; agrandir un volume après coup n'est pas documenté dans cette version
Nombre10 volumes au plus par service, path absolu de 256 caractères au plus
Identitéun volume est identifié par son chemin ; réordonner la liste ne permute pas les données, changer le path crée un nouveau volume vide
Suppression de l'Apples services de l'App disparaissent, les volumes restent avec leurs données
Suppression du serviceidem : les volumes du service sont conservés
Type de disquefixé par la plateforme, non choisissable
Un volume n'est pas un partage

Deux services ne peuvent pas monter le même volume, et un service à volume ne peut pas être répliqué. Pour des fichiers partagés ou servis en masse, utilisez un stockage objet ou le CDN.

Supprimer les données​

sng app delete db conserve le volume. Il n'existe pas, dans cette version, de champ ni de commande pour le supprimer vous-même : demandez-le au support en indiquant le nom de l'App et du service. Si vous recréez une App du même nom avec le même path, elle retrouve le volume et ses données.

Si ça ne marche pas​

Ce que vous voyezCauseCorrection
Manifeste refusé avec replicas, autoscale ou strategy: rollingUn service à volume tourne en un seul exemplaireRetirer ces champs
sng app scale db 2 refuséIdemGarder 1, ou retirer le volume
Le service démarre mais ne peut pas écrire dans le volumeL'image tourne sous un autre uid que userDonner dans user l'uid de l'image (999 pour postgres)
Les données ont disparu après un changement de manifesteLe path du volume a changé : c'est un nouveau volumeRemettre l'ancien path : l'ancien volume est retrouvé

Pour aller plus loin​

  • Les volumes compose nommés deviennent des volumes de 1Gi à la traduction : pensez à ajuster size (Depuis docker compose).
  • La taille d'un volume compte dans le quota de votre offre ; voir Tiers.

Voir aussi​