Hola,
Creé una bifurcación para probar un concepto. Estamos usando Foreman principalmente en desarrollo para ejecutar Redis, un trabajador de Resque y un programador de Resque. Estos trabajadores y programadores dependen de que se inicie Redis y, en algunos casos, fallan debido a eso.
La versión en https://github.com/rvanlieshout/foreman admite la defensa de la dependencia en el Procfile. Por ahora, solo usa un retraso de 5 segundos para permitir que un padre comience. Un procfile podría verse así:
mongodb: mongod --quiet --dbpath=db/mongo/
| redis: redis-server /opt/local/etc/redis.conf
| | worker: bundle exec rake environment resque:work QUEUE=* VERBOSE=1 RAILS_ENV=development
| | scheduler: bundle exec rake resque:scheduler QUEUE=* VERBOSE=1 RAILS_ENV=development
post_office: post_office --smtp 10025 --pop3 10110
(Nota: Redis no depende de Mongo aquí ... solo para demostrar)
Cuando se ejecuta un "inicio de capataz", se inicia Mongo y PostOffice primero, seguido de Redis después de 5 segundos y el trabajador y el programador después de 10.
Esta versión de Foreman es compatible con versiones anteriores, pero plantea algunos otros problemas / preguntas:
Entonces ... ¿Ha tenido preguntas relacionadas con la dependencia antes? ¿Cree que esta solución podría ser algo que se incluirá en una versión futura de Foreman?
Y ... ¡gracias por este proyecto! Realmente nos ayuda a mejorar nuestro flujo de trabajo de desarrollo.
Realmente no hay ninguna forma de saber cuándo algo está "listo" más que detectar si se ha enlazado a su puerto asignado. No todos los procesos se vinculan a un puerto, y prefiero no introducir esta compleja relación al capataz.
Si se sintiera tan inclinado, podría envolver sus procesos con un script que buscara algo más disponible antes de comenzar el proceso previsto.
Salud,
David
Me encantaría esto :( - Tengo un montón de procesos RTSPProxy y RTSPClient y quiero retrasar el inicio de los clientes.
¿Está implementado todavía?