web-dev-qa-db-fra.com

Mécanisme de relance des boucles

J'ai un script que je lance pour déployer 2 services Web et une application frontale. Le script appelle une méthode qui vérifie si les 2 services principaux sont opérationnels. Si tel est le cas, considérez le déploiement comme réussi, sinon annulez.

Les 2 services prennent parfois plus de temps que le front-end pour démarrer. Actuellement, je mets en veille pour retarder la vérification du service Web. Cela leur laisse le temps de démarrer.

Je souhaite supprimer ce sommeil et ajouter un mécanisme de nouvelle tentative de sorte que si un service est en panne, réessayez simplement la vérification à plusieurs reprises jusqu'à ce que j'obtienne une réponse.

Pour vérifier si l'appareil est en place, j'utilise curl. J'ai lu que curl a un mécanisme de nouvelle tentative mais je ne l'ai jamais utilisé.

Avez-vous déjà résolu ce problème auparavant? Je veux comprendre les choses que je dois considérer lors de la résolution, par ex. puis-je réessayer jusqu'à ce que j'obtienne un HTTP 200 de mon service?

Quelqu'un a-t-il des suggestions pour tester cela? J'aurais besoin de trouver un service qui était en panne.

EDIT: Je vois que -retry ne réagit qu'aux erreurs transitoires "Erreur transitoire signifie soit: un délai d'attente, un code de réponse FTP 4xx ou un code de réponse HTTP 5xx". Mon service peut retourner un 404, donc la relance de curl n'est pas ma solution.

restcurlweb-deployment
21
TheCoder

L'instruction suivante va réessayer 5 fois ou un maximum de 40 secondes avec un délai d'expiration de connexion de 5 secondes, et aucune politique d'interruption exponentielle

curl --connect-timeout 5 \
    --max-time 10 \
    --retry 5 \
    --retry-delay 0 \
    --retry-max-time 40 \
    'http://your_url'


--max-time 10     (how long each retry will wait)
--retry 5         (it will retry 5 times)
--retry-delay 0   (an exponential backoff algorithm)
--retry-max-time  (total time before it's considered failed)

Notez qu'il existe également un --retry-connrefuse qui réessaye même lorsque la connexion est refusée.

32
Dan Ionescu

Juste pour dissiper toute confusion possible pour toute personne nouvelle ...

Veuillez voir: https://curl.haxx.se/docs/manpage.html

--recommencez

Si une erreur transitoire est renvoyée lorsque curl essaie d'effectuer un transfert, il réessayera ce nombre de fois avant d'abandonner. Si vous définissez le nombre sur 0, curl ne fera aucune nouvelle tentative (ce qui est la valeur par défaut). Une erreur transitoire signifie: un délai d'attente, un code de réponse FTP 4xx ou un code de réponse HTTP 5xx.

Lorsque curl est sur le point de réessayer un transfert, il attendra d'abord une seconde, puis pour toutes les tentatives à venir, il doublera le temps d'attente jusqu'à ce qu'il atteigne 10 minutes, ce qui sera alors le délai entre le reste des tentatives. En utilisant --retry-delay, vous désactivez cet algorithme de décroissance exponentielle. Voir aussi --retry-max-time pour limiter le temps total autorisé pour les tentatives.

Si cette option est utilisée plusieurs fois, la dernière sera utilisée.

Ajouté dans 7.12.3.

2
Twilio Technical Support

Si tu utilises --max-time 10 cela tuera votre connexion avant 10 secondes, donc ce n'est pas utile lors du téléchargement.

Le suivi réessayera 300 fois avec un délai de 5 secondes et un délai de connexion de 30 secondes

curl \
    --connect-timeout 30 \
    --retry 300 \
    --retry-delay 5 \
    URL
1
Max Barrass