L'environnement proxy tel que le voit un worker Sidekiq

La tâche utilise l'environnement de son worker Sidekiq, et non un nouveau terminal ou un processus web Rails. Pour un worker au premier plan dont le client HTTP lit ces variables :

http_proxy=http://proxy.example.net:8080 \
https_proxy=http://proxy.example.net:8080 \
bundle exec sidekiq

Pour l'agencement Linux géré par systemd documenté par Sidekiq, placez les valeurs dans le drop-in de l'unité worker réelle :

[Service]
Environment="http_proxy=http://proxy.example.net:8080"
Environment="https_proxy=http://proxy.example.net:8080"

Rechargez les définitions d'unité et remplacez le worker via la procédure de redémarrage habituelle du déploiement. Recharger le code Rails dans un worker existant ne remplace pas son environnement hérité.

Un contrôle de service public peut utiliser un point de terminaison de la liste de proxys HTTP dans ces valeurs lorsque des intermédiaires publics sont autorisés et que le client du worker n'a pas d'identifiants proxy configurés ni conservés. Avec plusieurs unités propres à des files, identifiez laquelle a exécuté la tâche en échec. Un succès d'un autre worker n'établit pas la configuration de celui-ci.

Consignez cette unité et le client HTTP ensemble. Un client explicitement configuré peut utiliser une autre route quelles que soient les variables transmises au worker ; dans ce cas, configurez son interface prise en charge.