Votre premier déploiement
D'un dépôt à une adresse qui fonctionne, avec les erreurs signalées avant que vous ne les commettiez.
Trente minutes, passées surtout à attendre. À la fin, vous aurez une application sur Internet, une base de données derrière elle, et votre propre domaine devant.
Faites-le avec quelque chose que vous ne craignez pas de casser.
Avant de commencer
- Une organisation disposant d'un peu de crédit.
- Un dépôt contenant une application web qui écoute sur un port et répond en HTTP.
- Un nom de domaine, si vous voulez faire la dernière étape. Facultatif.
1. Connecter le dépôt
Autorisez ISOGrid auprès de votre hébergeur de code, et sélectionnez uniquement le dépôt que vous allez déployer. La connexion pourra être élargie plus tard ; commencer de façon restreinte signifie qu'une erreur ici ne coûte rien.
2. Créer l'application
Choisissez le dépôt, la branche, une région et une taille.
La plateforme détermine alors comment la construire. Si elle vous pose une question, répondez-y — elle ne le fait que lorsqu'un dépôt est réellement ambigu, et deviner produirait une application qui échoue à trois heures du matin plutôt que maintenant.
Choisissez la plus petite taille qui suffit. Monter en taille plus tard demande un redémarrage, pas une reconstruction, et commencer petit évite que votre première facture soit une surprise.
3. Suivre le premier déploiement
Le premier est le plus lent : rien n'est encore en cache.
S'il échoue, lisez les journaux de la copie défaillante plutôt que ceux de
l'application en général. Par ordre de probabilité, il s'agit d'une valeur
d'environnement manquante, d'un mauvais port, ou d'une application liée à
localhost — ce qui, à l'intérieur de sa propre copie, signifie uniquement
cette copie : elle tourne parfaitement, et rien ne peut l'atteindre.
4. Visiter l'adresse
Vous obtenez immédiatement une adresse chiffrée, avec un certificat que la plateforme obtient et renouvelle. Rien à configurer.
Gardez cette adresse. Elle continue de fonctionner même quand votre propre domaine ne fonctionne pas, ce qui en fait la première chose à essayer quand quelque chose casse plus tard.
5. Ajouter une base de données
Commandez-la séparément de l'application. Elle survivra à une centaine de déploiements.
Pour un premier essai, une disposition simple convient : c'est la moins chère, et une interruption pendant que vous apprenez n'est qu'un désagrément. Pour tout ce qu'un client utilisera, lisez Bases de données avant de choisir — ce qui distingue les dispositions, c'est ce à quoi chacune survit.
Les identifiants ne sont affichés qu'une fois. Copiez-les maintenant. Ils ne peuvent plus être récupérés ensuite, et si vous les perdez, vous en créez de nouveaux.
6. Relier les deux
Définissez les informations de connexion comme valeurs d'environnement de l'application. Enregistrez le mot de passe comme secret, et non comme valeur ordinaire : un secret est en écriture seule, il ne peut donc pas être relu plus tard depuis une page web ni s'échapper dans une capture d'écran.
L'enregistrement redémarre l'application, car un programme lit son environnement une seule fois, au démarrage.
7. Ajouter une seconde copie
Vous avez une seule copie, ce qui signifie une coupure de service à chaque déploiement et à chaque remplacement de la machine qui l'héberge.
Passez à deux. Elles sont placées sur des machines différentes, les requêtes sont réparties, et les déploiements deviennent invisibles pour les utilisateurs du site. C'est la plus grande amélioration de fiabilité disponible, et elle tient en un seul paramètre.
8. Faire pointer votre propre domaine
Rattachez le nom et créez l'enregistrement que la console vous indique.
Le certificat est émis dès que le nom se résout vers la plateforme — cet ordre compte, car une autorité de certification vérifie que vous contrôlez un nom en l'atteignant. S'il reste en attente, l'enregistrement n'est pas encore en place, ou pas encore partout. Voir Adresses et domaines.
9. Activer les sauvegardes
Faites-le avant d'en avoir besoin.
Vos données sont déjà copiées sur plusieurs machines si vous avez choisi une
disposition qui le fait. Ce n'est pas une sauvegarde. La réplication recopie
un DELETE malencontreux sur chaque copie aussi fidèlement qu'une écriture
correcte. Les sauvegardes vous protègent des erreurs des personnes et des
logiciels ; la réplication vous protège de la panne du matériel. Il vous faut les
deux, et une seule est activée par défaut.
Pour continuer
- Quand ça ne va pas — à lire une fois maintenant, pendant que rien n'est cassé.
- Référence des commandes — tout ce qui précède peut être automatisé.
- Déployer depuis la CI/CD — déployer à chaque push plutôt qu'à la main.