Heroku - 4 Les fonctionnalités et Architecture v4
Bienvenue dans ce cours d'introduction à Heroku. Cette vidéo se consacre aux fonctionnalités de la plateforme et à la façon dont elles aident à gérer une application. Nous abordons ici son architecture ; les permissions et les prix seront traités plus tard. Heroku accepte du code dans plusieurs langages (Java, Node.js, Python, etc.). Mais le code source ne suffit pas, car la majorité des applications modernes possède des dépendances externes. Heroku a donc besoin du code source et d'une description des dépendances requises pour lancer l'application. Ce fichier de description varie selon le langage : Gemfile pour Ruby, requirements.txt pour Python, package.json pour Node.js et pom.xml pour Java.
Buildpacks, slugs et releases
Avec le code source et la description des dépendances, Heroku sait comment lancer votre application. Il dispose d'un composant appelé buildpack, dont le rôle est de comprendre les dépendances du code, de les récupérer pour que l'application puisse les utiliser, et de générer les éléments nécessaires (images, vidéos, etc.). À l'issue de ce processus, le buildpack regroupe tout cela en un slug. Une fois le slug prêt, viennent les variables de configuration : ce sont des identifiants ou variables d'environnement accessibles au code en cours d'exécution. Pourquoi ne pas les mettre directement dans le code ? Pour deux raisons principales : la sécurité (toute personne ayant accès au code aurait accès aux informations sensibles) et la flexibilité (changer une variable et redémarrer l'application sans modifier le code).
La dernière étape consiste à attacher les add-ons : bases de données (Postgres, MongoDB), systèmes de cache (Redis, Memcached) ou moteurs de recherche (Elasticsearch). Heroku crée des instances prêtes à l'emploi ; le fournisseur du service configure tout pour vous. La liste complète est disponible sur https://elements.heroku.com/addons. Quand code, dépendances, variables de configuration et add-ons sont prêts, on obtient une release. Toutes les releases sont stockées par Heroku : en cas de déploiement défectueux, il suffit de revenir à une release précédente pour rétablir le service. Une fois la release prête, elle est confiée à un dyno qui l'exécute. Vous pouvez imaginer les dynos comme des machines Linux dans le cloud, dont les capacités sont ajustables. La mise à l'échelle dans Heroku se fait via ces dynos : augmenter leur nombre ou utiliser des dynos plus puissants, ou réduire à l'inverse selon vos besoins. Toutes ces étapes (recherche de dépendances, variables de configuration, add-ons) sont automatiques : l'utilisateur n'envoie que des changements de code.
Heroku offre trois options pour déployer du code : l'intégration GitHub (à chaque changement, Heroku récupère le nouveau code et rebuild l'application), Heroku Git (une alternative similaire native), et Docker (vous déployez des images de conteneurs). GitHub est recommandé si votre projet comporte plus de deux ou trois personnes, grâce à ses fonctionnalités de revue et de versioning. En résumé : tout commence par un push de code, puis Heroku exécute automatiquement et dans l'ordre la recherche des dépendances, la création des fichiers requis, l'ajout des variables de configuration et l'installation des add-ons. Une fois toutes ces étapes réalisées, une release est créée et confiée à un dyno qui l'exécute. À bientôt pour la prochaine vidéo !
En résumé
Heroku fonctionne en automatisant l'ensemble du processus de déploiement : la plateforme détecte les dépendances (via Gemfile, requirements.txt, pom.xml ou package.json), les installe via des buildpacks, configure les variables d'environnement pour sécuriser les données sensibles, et provisionne les add-ons demandés. Chaque déploiement crée une « release » stockée et versionnée, permettant les rollbacks instantanés en cas de problème. L'exécution se fait sur des dynos (machines Linux dans le cloud) dont on peut ajuster la puissance et le nombre pour mettre à l'échelle l'application selon les besoins.
Points clés
- Heroku gère automatiquement les dépendances en lisant les fichiers descriptifs (Gemfile, requirements.txt, pom.xml, package.json) et les installe via des buildpacks avant de lancer l'application
- Les variables de configuration permettent de stocker les informations sensibles (identifiants, clés API) en dehors du code source, améliorant la sécurité et facilitant l'utilisation de configurations différentes selon l'environnement (test vs production)
- Les add-ons (PostgreSQL, MongoDB, Redis, Elasticsearch) sont provisionnés automatiquement et configurés par le fournisseur du service, prêts à être utilisés dès que le code s'exécute
- Chaque déploiement crée une « release » versionnée et stockée, permettant de revenir instantanément à une version antérieure en cas d'erreur critique
- Les dynos sont des machines Linux exécutant dans le cloud dont la puissance et le nombre peuvent être ajustés pour augmenter ou réduire la capacité de calcul
- L'ensemble du processus (recherche des dépendances, configuration, provisionnement des add-ons, mise à l'échelle) est automatique ; l'utilisateur envoie simplement les changements de code
Questions fréquentes
Comment Heroku gère-t-il automatiquement les dépendances?
Heroku utilise des buildpacks qui lisent les fichiers de description des dépendances (Gemfile pour Ruby, requirements.txt pour Python, pom.xml pour Java, package.json pour Node.js) et les installe automatiquement avant de lancer l'application.
Pourquoi les variables de configuration sont-elles importantes?
Elles permettent de stocker les informations sensibles (identifiants de base de données, clés API) en dehors du code source, améliorant la sécurité et permettant d'utiliser différentes configurations pour les environnements de test et de production.
Qu'est-ce qu'une release dans Heroku et pourquoi est-ce utile?
Une release est une version complète de l'application (code + dépendances + configuration + add-ons) qui est créée et stockée lors du déploiement, permettant de revenir rapidement à une version précédente en cas de problème critique.