Cassiope · Getting started

Chargement…

Bravo, votre application tourne sur Cassiope

Cette page est l'application que vous venez de déployer : un petit programme Node.js lancé dans un conteneur. Elle sert de banc d'essai pour découvrir, un par un, ce que Cassiope vous apporte. Rien n'est obligatoire : faites les étapes dans l'ordre que vous voulez.

Ce qui se passe quand vous ouvrez l'adresse de cette page

Pourquoi parle-t-on du port 3000 ?

Vous n'avez jamais à le saisir : l'adresse publique est simplement https://…, sans :3000. Le port est la « porte » par laquelle Cassiope entre dans votre conteneur. Une application écoute sur un seul numéro choisi par son code, et Cassiope doit le connaître pour lui transmettre les visites.

Il ne sert donc que dans deux cas : (1) votre application n'écoute pas sur 3000 (tout autre framework) — il faut alors le dire à Cassiope, sinon l'adresse affiche une erreur 502/504 ; (2) un autre service de Cassiope veut l'appeler en interne (section 5).

Votre progression

Les étapes se cochent toutes seules quand la page détecte que vous les avez faites (rechargez la page après un redéploiement).

Petit lexique
Variable d'environnement
Un réglage NOM=valeur que Cassiope donne à votre application au démarrage, sans le mettre dans le code (adresse d'une base, clé d'API, mode « production »…).
Secret
Une variable dont la valeur ne doit jamais s'afficher en clair (mot de passe, clé d'API). Cette page masque tout nom contenant KEY, TOKEN, SECRET, PASSWORD…
Add-on
Un service tout prêt géré par Cassiope (base PostgreSQL, MySQL, Redis) que vous branchez à votre application.
Binding
Le branchement d'un add-on à un service : Cassiope ajoute à votre service les variables contenant l'adresse et le mot de passe de l'add-on.
Volume
Un disque qui survit aux redéploiements. Sans volume, tout fichier écrit par l'application est perdu à chaque déploiement.
Healthcheck
Une adresse (/healthz) que Cassiope interroge régulièrement pour savoir si l'application va bien.
Redéployer
Redémarrer le service pour qu'il prenne en compte les changements (variables, add-ons, volumes). Presque toutes les étapes l'exigent.

1 · Variables d'environnement

Ajoutez des variables au service dans Cassiope, redéployez, puis vérifiez ici qu'elles sont bien injectées. Les secrets sont masqués.

À quoi ça sert ?

Une application a besoin de réglages qui changent selon l'endroit où elle tourne : adresse de la base, clé d'un service tiers, mode test ou production. On ne les écrit pas dans le code (ils fuiraient dans Git) : Cassiope les donne à l'application au démarrage. Ici, vous vérifiez que ce mécanisme fonctionne.

Pourquoi HELLO=world ? Aucune importance : c'est une valeur de test sans conséquence, pour constater que ce que vous saisissez dans Cassiope arrive bien dans l'application. Remplacez-la par ce que vous voulez.

Pourquoi une variable secrète ? Pour voir la différence : une variable normale s'affiche telle quelle, une variable dont le nom contient KEY, TOKEN, SECRET ou PASSWORD s'affiche masquée (2 premiers caractères + longueur). Dans un vrai projet, c'est le traitement que vous voulez pour une clé d'API ou un mot de passe.

À faire
  1. Dans Cassiope, onglet Variables du service : ajoutez HELLO = world.
  2. Ajoutez aussi API_KEY = n'importe quel texte, par exemple abc123-ma-cle-de-test (une vraie clé ressemble à ça : une suite de caractères illisible ; ici, ce que vous tapez n'a pas d'importance).
  3. Redéployez, rechargez cette page, saisissez HELLO, API_KEY ci-dessous et cliquez sur Vérifier : HELLO apparaît en clair, API_KEY masquée.

Variables du service

Afficher les variables système

2 · Add-ons PostgreSQL, MySQL et Redis

Attachez un add-on au service (binding) : la variable injectée contenant une URL postgres://, mysql:// ou redis:// est détectée automatiquement. Le test se connecte, écrit et relit une donnée.

À quoi ça sert ?

Une base de données est un programme à part, pas un fichier de votre application. Cassiope en héberge pour vous (add-on) et, quand vous la « branchez » à votre service, lui injecte l'adresse et le mot de passe sous forme de variables. Vous n'installez, ni ne configurez rien. Cette page prouve que le branchement marche en écrivant puis relisant une ligne.

À faire
  1. Dans Cassiope, créez un add-on (PostgreSQL par exemple).
  2. Attachez-le à ce service, puis redéployez.
  3. Revenez ici : l'add-on apparaît ci-dessous, cliquez sur Tester.

3 · Explorateur PostgreSQL

Bases, tables puis données de l'add-on connecté (lecture seule, 25 lignes par page, cellules tronquées).

À quoi ça sert ?

À voir ce que votre application a réellement écrit dans la base, sans installer d'outil. Rien n'est modifié ici. Cette section se remplit dès qu'un add-on PostgreSQL est branché (section 2).

4 · Explorateur Redis

Clés, contenu d'une clé et file de démonstration cassiope-probe:queue (seule clé que cette page écrit).

À quoi ça sert ?

Redis est une mémoire très rapide, utilisée pour le cache ou les files de tâches. La file de démonstration vous laisse empiler et dépiler des messages pour voir un add-on Redis vivre. Cette section se remplit dès qu'un add-on Redis est branché.

5 · Connexion interne entre applications

Les variables {PRÉFIXE}_URL, _HOST et _PORT injectées par un lien interne sont détectées ici.

À quoi ça sert, et pourquoi un port ici ?

Dans une vraie application, plusieurs services se parlent : un site appelle une API, l'API appelle un service d'images. Plutôt que de rendre l'API publique sur Internet, Cassiope crée un lien interne : une adresse réservée à vos services, invisible de l'extérieur.

Contrairement à l'adresse publique, cette adresse ne passe pas par le HTTPS de Cassiope : c'est un appel direct d'un conteneur à l'autre, donc il faut préciser la porte (le port). C'est la seule situation où connaître le port est utile.

Les « 3 variables injectées » sont le mode d'emploi de ce lien. Avec le préfixe API : API_URL (adresse complète, prête à appeler), API_HOST (le nom de la machine cible) et API_PORT (son port). Ce sont de vraies variables d'environnement, comme celles de la section 1 : elles n'apparaissent qu'après le redéploiement du consommateur.

Comment tester une adresse interne, et prérequis
  1. Déployez une seconde copie de ce service (le producteur) dans la même machine que celle-ci : deux ressources ne se connectent que si elles tournent sur le même nœud.
  2. Dans le producteur, onglet Connexions : Exposer avec le port 3000 (ou celui de PORT), portée internal (même projet) ou tenant. Le service est redéployé.
  3. Dans ce service (le consommateur), onglet Connexions : Connecter le producteur avec un préfixe, par exemple API. Trois variables sont injectées au prochain déploiement : API_URL, API_HOST, API_PORT.
  4. Redéployez le consommateur : les variables ne sont lues qu'au démarrage. Le lien apparaît alors ci-dessous : cliquez sur Tester.

Un test réussi affiche la réponse du producteur, dont calledBy = le nom de ce service. Un délai dépassé signale le plus souvent deux services sur des nœuds différents ou un producteur non redéployé après l'exposition ; un refus de connexion, un mauvais port exposé.

6 · Stockage

Comparez le disque applicatif (éphémère) et un volume persistant monté sur /data. Le compteur de démarrages de chaque dossier ne survit à un redéploiement que s'il est sur un volume.

À quoi ça sert ?

Un conteneur est jetable : à chaque déploiement, il est recréé à neuf et tout fichier écrit dedans disparaît (photos téléversées, base SQLite, exports…). Pour garder des fichiers, on monte un volume : un disque séparé, rebranché sur le nouveau conteneur à chaque fois.

Essai : (1) cliquez sur Écrire 10 Mo dans les deux cadres ci-dessous, (2) ajoutez un volume sur /data dans Cassiope, (3) redéployez. Le compteur et les fichiers du cadre « Volume persistant » restent, ceux du « Disque applicatif » repartent à zéro.

Tous les montages

7 · Configuration avancée : ports et healthcheck

Testez le comportement de Cassiope face à un service qui change de port ou devient malsain. Les pannes simulées se désarment seules.

À quoi ça sert ?

Pour voir comment Cassiope réagit quand ça va mal, sans casser un vrai service : le bouton « 503 » fait croire à Cassiope que l'application est en panne ; le bouton « lent » simule une application qui ne répond plus à temps. Section pour les curieux : vous pouvez l'ignorer au début.

Healthcheck /healthz

Attendu : un service configuré avec un healthcheck est marqué malsain après quelques échecs ; sans healthcheck, rien ne change. Voir la page du service pour l'état affiché.

Ports

Le service écoute sur PORT (3000 par défaut) ; l'adresse publique, elle, ne contient jamais le port. Pour tester un autre port : changez PORT puis le port exposé dans Cassiope, ou ajoutez EXTRA_PORTS=8081,8082 pour écouter sur plusieurs ports, puis exposez l'un d'eux. Le bloc ci-dessus indique le port et l'hôte vus par l'application.

8 · Génération de logs

Écrit des lignes JSON sur la sortie standard (info) ou d'erreur (warn, error), à consulter dans l'onglet Logs du service.

À quoi ça sert ?

Les logs sont le journal de bord de votre application : c'est là qu'on cherche pourquoi quelque chose a planté. Générez quelques lignes ici, puis ouvrez l'onglet Logs du service dans Cassiope pour voir comment elles s'y affichent.