Une application avec une base de données

Une API et un PostgreSQL managé, reliés par un secret, en deux copies, avec une sauvegarde que vous avez restaurée une fois.

Quarante minutes, dont une partie à attendre. À la fin, vous aurez une API qui tourne en deux copies, une instance PostgreSQL à vous derrière elle sur un réseau privé, la chaîne de connexion rangée là où personne ne peut la relire, et une sauvegarde que vous aurez réellement restaurée.

Faites-le avec quelque chose que vous ne craignez pas de casser.

Avant de commencer

  • Une organisation disposant d'un peu de crédit.
  • La CLI, installée et connectée. Voir Installer la CLI.
  • Un dépôt connecté à votre organisation, contenant une API qui écoute sur un port et lit l'adresse de sa base de données dans une seule variable d'environnement. Ce tutoriel appelle la variable DATABASE_URL, l'application shop-api et la base shop-db. Remplacez acme/shop-api par votre dépôt.

1. Commander la base de données

Dans la console, ouvrez Instances de bases de données et cliquez sur Nouvelle instance. Nommez-la shop-db, choisissez la Région, laissez Réseau sur celui qui est proposé (c'est celui de votre organisation), choisissez Nœud unique sous Topologie, prenez la plus petite taille, puis cliquez sur Déployer.

Vous devez voir shop-db dans la liste avec l'état provisionnement, puis en service. Un premier démarrage peut prendre plusieurs minutes. La page se met à jour toute seule.

N'utilisez pas les Mini-bases de données pour cela. Une mini-base n'est joignable que par une adresse publique. Une instance rejoint votre réseau privé, et c'est par là que l'application va l'atteindre.

Notez le nom du réseau. L'application doit être sur le même.

2. Lire la chaîne de connexion

Ouvrez l'instance avec Gérer. Dans l'onglet Vue d'ensemble, sous Connexion, cliquez sur Afficher les informations de connexion.

Vous devez voir une ligne commençant par postgresql://, et en dessous l'hôte, le port, la base de données et l'utilisateur. Cette ligne est l'identifiant complet : votre rôle d'administration, son mot de passe et l'adresse privée.

Avant de quitter la page, cliquez sur Tester les connexions sous Connectivité. Le point de terminaison privé doit indiquer accepte. Sinon, attendez une demi-minute et testez de nouveau : une instance est marquée en service un peu avant d'accepter les connexions.

Cette ligne contient un mot de passe. Ne la collez ni dans une discussion, ni dans un ticket, ni dans un commit.

3. Créer l'application, avec la chaîne comme secret

Placez d'abord la chaîne dans une variable du shell, sans qu'elle apparaisse à l'écran ni dans l'historique. Avec bash ou zsh :

read -rs DATABASE_URL

Collez la ligne, appuyez sur Entrée. Créez ensuite l'application :

isogrid apps create --name shop-api \
  --url https://github.com/acme/shop-api \
  --replicas 2 --public \
  --secret-env DATABASE_URL="$DATABASE_URL" \
  --wait

--secret-env enregistre la valeur comme secret et la remet à l'application sous forme de variable d'environnement. N'utilisez pas --env pour cela : une variable ordinaire est lisible par quiconque peut voir l'application. Si votre code lit ses secrets dans des fichiers, utilisez --secret, qui remet la même valeur dans le fichier /run/secrets/DATABASE_URL.

--replicas 2 lance deux copies : un déploiement ne laisse plus de coupure.

Vous devez voir Created shop-api in …, on network …, puis Build #1 succeeded., puis shop-api is running. et son adresse.

Vérifiez le réseau sur cette première ligne. Si ce n'est pas celui de l'étape 1, l'application démarre et ne trouve jamais la base. Indiquez le bon avec --network ; isogrid networks list affiche les vôtres.

4. Vérifier

isogrid apps status shop-api
isogrid apps secrets shop-api

La première doit afficher shop-api running 2/2 running. La seconde affiche DATABASE_URL et rien d'autre : le nom, jamais la valeur. Aucune commande ni aucune page ne redonne la valeur.

Ouvrez maintenant l'adresse et appelez quelque chose qui lit dans la base.

Si des copies s'arrêtent sans cesse, status les liste avec l'erreur, et ceci montre ce que l'application a écrit :

isogrid apps logs shop-api --search 'level:error' --since 15m

Par ordre de probabilité : l'application est sur un autre réseau que la base ; le code lit une variable d'un autre nom ; ou chaque copie ouvre plus de connexions que la base n'en accepte. Deux copies, ce sont deux pools. Voir Bases de données.

5. Faire une sauvegarde

Les sauvegardes sont déjà activées pour une instance : chaque jour, à 03:00 UTC, conservées tant que vous ne dites pas le contraire. N'attendez pas la nuit pour savoir si elles fonctionnent. Ouvrez l'onglet Sauvegardes et cliquez sur Sauvegarder maintenant.

Vous devez voir « Sauvegarde en cours… elle apparaîtra ici une fois terminée. », puis une ligne par base de données de l'instance, avec sa taille et l'état réussie, et à côté Télécharger et Restaurer.

Sous Planification des sauvegardes, vous pouvez changer l'heure et Conserver (jours). Laissé vide, toutes les sauvegardes sont conservées.

Ce n'est pas ce que vous apportent les copies d'une base. La réplication répète fidèlement un DELETE malencontreux. Seule une sauvegarde lui est antérieure.

6. La restaurer

Une sauvegarde jamais restaurée est un espoir, pas une sauvegarde. Cliquez sur Restaurer sur la ligne. On vous demande de nommer une nouvelle base, et on vous propose le nom d'origine suivi de _restored. Acceptez.

Vous devez voir « Restauration dans « … » en cours. La base apparaîtra une fois la restauration terminée. »

Une restauration n'écrase jamais rien. Elle se fait à côté de vos données, dans une base qui ne doit pas encore exister : rien de ce qu'utilise l'application ne change.

Pour vérifier, ouvrez l'onglet Requêtes, saisissez le nouveau nom dans le champ Base de données, et comptez les lignes d'une table que vous connaissez :

SELECT count(*) FROM orders;

Vous devez obtenir le nombre que la table avait au moment de la sauvegarde.

7. Faire pointer l'application vers les données restaurées

Seulement le jour où vous devez vraiment revenir en arrière. La chaîne de connexion est celle de l'étape 2, où le nom de la base, à la fin, est remplacé par le nouveau :

read -rs RESTORED_URL
isogrid apps update shop-api --secret-env DATABASE_URL="$RESTORED_URL"
isogrid apps deploy shop-api --wait

Vous devez voir Updated shop-api: secrets., puis shop-api is running.

Enregistrer un secret ne redémarre rien. C'est la seconde commande qui le fait prendre en compte par les copies : elle redéploie la version déjà construite de l'application, sans reconstruire.

Pour continuer