l'idée de ce genre de sonde doivent simplement répondre à leurs requêtes alors que l'intérêt c'est de vérifier que le logiciel fonctionne
Je pense que c'est un peu plus subtile que ça. Je ne suis pas familier avec Clever Cloud en particulier mais je pense qu'une sonde de « liveness » se doit de vérifier que le service fonctionne indépendamment de toutes dépendances. Si une dépendance dure casse le service mais que le service lui même fait de son mieux, il me semble légitime pour la sonde de répondre "OK". Sinon tu te retrouves à redémarrer le service en boucle, ce qui ne fait qu'intensifier le problème.
On peut (et devrait) avoir des sondes plus poussées qui testent toutes les fonctionnalités. Mais, si un humain est nécessaire pour diagnostiquer une sonde fautive, elle ne devrait pas pouvoir déclencher un redémarrage automatique.
Par exemple : je monte un clone de linuxfr avec le frontend dans un container et la base de données dans un autre. Si la base de données tombe, il est contre-productif de redémarrer le frontend. Donc la sonde de « liveness » du frontend doit dire "OK" même si la base de données est par terre et qu'environ rien ne fonctionne. Le frontend devrait bravement rester debout à servir des erreurs 500 aux utilisateur en attendant que la base de données revienne.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Super avec un mais
Posté par Krunch (courriel, site web personnel) . En réponse au lien Un serveur HTTP de moins de 20 Ko [défi technique parce que]. Évalué à 4. Dernière modification le 01 novembre 2024 à 10:49.
Je pense que c'est un peu plus subtile que ça. Je ne suis pas familier avec Clever Cloud en particulier mais je pense qu'une sonde de « liveness » se doit de vérifier que le service fonctionne indépendamment de toutes dépendances. Si une dépendance dure casse le service mais que le service lui même fait de son mieux, il me semble légitime pour la sonde de répondre "OK". Sinon tu te retrouves à redémarrer le service en boucle, ce qui ne fait qu'intensifier le problème.
On peut (et devrait) avoir des sondes plus poussées qui testent toutes les fonctionnalités. Mais, si un humain est nécessaire pour diagnostiquer une sonde fautive, elle ne devrait pas pouvoir déclencher un redémarrage automatique.
Par exemple : je monte un clone de linuxfr avec le frontend dans un container et la base de données dans un autre. Si la base de données tombe, il est contre-productif de redémarrer le frontend. Donc la sonde de « liveness » du frontend doit dire "OK" même si la base de données est par terre et qu'environ rien ne fonctionne. Le frontend devrait bravement rester debout à servir des erreurs 500 aux utilisateur en attendant que la base de données revienne.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.