Déployer une application et sa base

Un runtime, des dépendances, une base qui garde ses tables. Le réflexe est d’aller chercher un service managé par besoin. Dans un lab, on prend une VM et on pose la base dessus. Je vous dis pourquoi, puis on la monte.

Ce scénario est le bon si

La question	La réponse qui vous met ici
Que faites-vous tourner ?	Un processus qui vous appartient : une API, un back end, un job, un binaire, un conteneur.
Vous faut-il installer des choses ?	Oui : un runtime, des paquets système, des outils que vous choisissez.
Vos données doivent-elles survivre au redémarrage ?	Oui, d’où la base de données.
Le lab porte-t-il sur un service Azure précis ?	Non. Si votre sujet est un service managé, ce tutoriel ne s’applique pas.

Si vous ne servez que des fichiers déjà buildés, prenez le scénario plus court : déployer un site statique.

Pourquoi la base sur la VM

Tout tient à une ligne du tableau : l’arrêt automatique ne couvre que les VM.

	Base installée sur la VM	Service de base de données managé
Facturation	Suit la VM, donc suit l’arrêt automatique.	24 h sur 24 tant que la ressource existe.
Arrêt automatique	Oui, la base s’arrête avec la machine à 19 h.	Non concerné. Rien ne l’éteint à votre place.
Mise en place	Quelques minutes, un gestionnaire de paquets.	Une ressource à créer, un réseau et des règles d’accès à configurer.
Ce que vous apprenez	Vous administrez la base vous-même.	Sauvegardes et disponibilité gérées pour vous, hors de votre vue.
Dans un lab	Le cas par défaut.	Seulement si le sujet du lab est ce service.

Le piège classique : la base managée créée « pour deux jours de test » et oubliée jusqu’à l’échéance du lab. Elle a facturé quatre-vingt-dix nuits et deux mois de week-ends pendant que la VM dormait. Voir Coûts.

Prérequis

Un Resource Group créé avec ses tags et un lab déclaré. Sinon : créer mon lab Azure. La VM se crée dans ce Resource Group.

Créer la VM

1. Dans le Portail Azure, créez une ressource Virtual machine dans votre Resource Group et dans la région du lab.

2. Choisissez une image Ubuntu Server LTS et une taille modeste, par exemple Standard_B2s (2 vCPU, 4 Gio). Les tailles disponibles varient d’une région à l’autre. Pour le disque, Standard SSD suffit.

3. Gardez l’authentification par clé SSH et téléchargez la clé privée. Pas de mot de passe, c’est la porte que les balayages automatiques trouvent en premier.

4. À l’étape réseau, mettez Public inbound ports sur None. Le réglage par défaut ouvre le port SSH au monde entier, ce qui n’est jamais acceptable, même une heure.

5. Dans l’onglet Tags, renseignez owner, projectName et creationDate, les trois sans lesquels la création est refusée, puis expirationDate. Le portail applique ces tags à toutes les ressources créées par l’assistant : carte réseau, IP publique, NSG et disque en ont besoin autant que la VM.

6. Prenez une IP publique de type Standard, donc statique. Une IP dynamique change à chaque libération de la machine, et l’arrêt automatique de 19 h en provoque une chaque soir.

7. La VM créée, ouvrez son NSG — le pare-feu d’Azure, voir le glossaire — et ajoutez une règle entrante autorisant le port 22 depuis la seule IP autorisée, 194.148.102.82 (la sortie de Chancy). Ce n’est pas l’adresse de votre poste : votre connexion doit sortir par Chancy. Connectez-vous ensuite en SSH avec la clé téléchargée.

Un seul VNet pour tout le lab

L’assistant du portail crée un VNet avec la première VM. Pour une deuxième machine dans le même lab, réutilisez ce VNet. La règle est un VNet par lab. Voir organisation et réseau.

Installer la base et l’application

L’exemple installe PostgreSQL et prépare une base pour l’application. Adaptez le moteur, la démarche ne change pas.

sudo apt update
sudo apt install -y postgresql

# La base n'écoute que sur la machine elle-même : configuration par défaut sur
# Ubuntu, et exactement ce qu'il faut ici.
sudo -u postgres psql -c "SELECT inet_server_addr();"

# Un utilisateur et une base dédiés à l'application.
sudo -u postgres psql -c "CREATE USER app WITH PASSWORD 'un-mot-de-passe-genere';"
sudo -u postgres createdb --owner=app appdb

# Vérification depuis la machine.
psql "postgresql://app:un-mot-de-passe-genere@localhost/appdb" -c "\l"

L’application tourne sur la même machine et se connecte à localhost. Aucun port de base de données n’est ouvert sur le réseau, donc aucune règle NSG à écrire pour la base.

Pour joindre l’application depuis votre poste : un tunnel SSH, ssh -L 8080:localhost:8080 azureuser@votre-ip, et rien n’est exposé — c’est le chemin le plus court, puisque le port 22 est déjà ouvert. Sinon une règle NSG sur le port de l’application, avec 194.148.102.82 en source comme pour SSH, jamais 0.0.0.0/0.

Ce qui surprend après la première nuit

Le symptôme	Ce qui se passe
L’application ne répond plus le matin	La VM a été arrêtée à 19 h. C’est une règle imposée, pas un incident. Redémarrez, et vérifiez que vos services redémarrent seuls (systemctl enable).
La base a « perdu » ses connexions	Elle s’est arrêtée avec la machine. Les données sont là, les connexions ouvertes non. À votre application de se reconnecter.
L’adresse a changé	L’IP publique était dynamique. Passez-la en statique.
SSH ne répond pas, ou expire	La règle n’autorise que 194.148.102.82 : votre connexion ne sort pas par Chancy. Vérifiez votre adresse vue de l’extérieur (curl ifconfig.me) avant de soupçonner la VM. N’élargissez pas la règle pour compenser.
Un déploiement refusé pour cause de policy	Une ressource annexe a été créée sans les tags obligatoires : carte réseau, disque, IP publique ou NSG.
Le disque se remplit	Journaux, images de conteneurs et dumps s’accumulent vite. Faites de la place plutôt que d’agrandir le disque.

Une base de test se remplit de données inventées

Une base vide donne envie d’un extrait de production pour « tester avec du vrai ». Aucune donnée client réelle, personnelle ou sensible dans un lab, y compris dans une base posée sur une VM, y compris pour une seule requête. Générez un jeu de données, ou anonymisez avant de charger.

Le disque de la VM n’est pas sauvegardé. Un pg_dump régulier vers votre poste ou un dépôt Git, et le schéma versionné plutôt que reconstruit à la main. À l’échéance du lab, le Resource Group disparaît, la base avec.

À la fin du lab

Le Resource Group est supprimé à l’échéance par les administrateurs, ce qui emporte la VM, son disque et la base. Si le besoin s’arrête avant, supprimez sans attendre : voir cycle de vie, prolongation et clôture. Entre-temps, l’écran Cost analysis filtré sur votre Resource Group donne le coût réel du lab.

S’il me faut un service managé

Un lab dont le sujet est AKS, une base managée ou une passerelle demande un arbitrage de coût et de dimensionnement avant toute création. Lisez Coûts, puis écrivez à lab@qiminfo.ch en précisant ce que vous voulez tester et combien de temps.