GitHub
IX. Jetable
Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux
Les processus des applications 12 facteurs sont jetables, c’est-à-dire qu’ils peuvent être démarrés ou stoppés en un instant. Cela simplifie un rapide grossissement vertical, le déploiement rapide du code ou de changements dans la configuration, ainsi que la robustesse des déploiements de production.
Les processus doivent viser à minimiser le temps de démarrage. Idéalement, un processus prend quelques secondes entre le moment où une commande le lance et celui où il est en marche et prêt à recevoir des requêtes ou du travail. Un court temps de démarrage rend les processus de release et de scalabilité verticale plus agiles; il aide également à la robustesse, car les gestionnaires de processus peuvent plus facilement déplacer des processus vers de nouvelles machines physiques lorsque c’est nécessaire.
Les processus s’éteignent gracieusement lorsqu’ils reçoivent un signal SIGTERM (fr) du gestionnaire de processus. Pour un processus web, s’éteindre en douceur se fait en arrêtant d’écouter sur le port de service (refusant, par la même occasion, toute nouvelle requête), en permettant à la requête courante de se terminer, et en quittant ensuite. Ce qui est implicite dans ce modèle, c’est que les requêtes sont courtes (pas plus de quelques secondes), ou dans le cas de longues requêtes, les clients doivent pouvoir tenter de se reconnecter sans problème lorsque la connection est perdue.
Pour un processus de worker, s’éteindre gracieusement est réalisé en renvoyant le travail en cours dans la file de travaux. Par exemple, avec RabbitMQ le worker peut envoyer un message NACK; avec Beanstalkd, le travail est renvoyé dans la file automatiquement dès qu’un worker se déconnecte. Les systèmes basés sur des verrous, comme Delayed Job doivent s’assurer de supprimer le verrou de leur travail en cours. Il est implicite dans ce modèle que toutes les tâches sont réentrantes (fr), ce qui est réalisé en englobant les résultats dans une transaction, ou en rendant l’opération idempotente (fr).
Les processus doivent également être robustes face aux morts subites, dans le cas d’une panne du hardware sous-jacent. Bien que ce soit bien moins courant qu’un arrêt gracieux avec SIGTERM, cela peut arriver malgré tout. L’approche recommandée est l’utilisation d’un backend robuste de files de messages, tel que Beanstalkd, capable de renvoyer les tâches dans la file lorsqu’un client se déconnecte ou ne répond plus. Dans les deux cas, une application 12 facteurs est structurée pour gérer des fins inattendues et non-gracieuses. Le design crash-only (en) amène ce concept à sa conclusion logique (en).