mirror of
https://github.com/hibiken/asynq.git
synced 2026-04-26 07:25:56 +03:00
[GH-ISSUE #168] [FEATURE REQUEST] CLI/server for running exec.Command #54
Labels
No labels
CLI
bug
designing
documentation
duplicate
enhancement
good first issue
good first issue
help wanted
idea
invalid
investigate
needs-more-info
performance
pr-welcome
pull-request
question
wontfix
work in progress
work in progress
work-around-available
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/asynq#54
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @xkortex on GitHub (Jun 11, 2020).
Original GitHub issue: https://github.com/hibiken/asynq/issues/168
Originally assigned to: @xkortex on GitHub.
Is your feature request related to a problem? Please describe.
Running distributed bash scripts / other executables often involves a ton of overhead, job managers, complex pieces of software like Slurm or Kubernetes.
Describe the solution you'd like
A binary for a client and one for a server implementing Asynq protocol basically wrapping
execcalls.There'd be an
asynqexecbinary with the verbsserveandsubmit. Serve would allow setting the concurrency number, as well as configure a whitelist of allowable executable names.E.g. really simple example of the serve logic I just threw together:
asnyqexec submitI think this could double as both a practical example of using the library, and a useful tool in its own right.
If you think this could be a valuable contribution directly to this project, I'd be willing to PR it when I have a bit of time (a lot of this logic is based on a similar project I have), otherwise if you think it better belongs as a separate library, I could do it as such instead. Basically, would you like this added, or should I just do this in my own repo?
Example use case:
I have 4459 videos I want to transcode with ffmpeg and a loosely-organized cluster at my disposal. I'd love to be able to do something like
Easy peasy distributed batch jobs!
@hibiken commented on GitHub (Jun 11, 2020):
@xkortex Thank you for opening this feature request!
This sounds awesome, it'd be a great addition to the project 🎉
I think we can put this binary under
/tools(or you could create a separate directory like/contribor/xif you'd like). It'll make a very cool demo as well.Would you mind describing the above example in more detail? (I'm not familiar with the
rushcommand so I'm not 100% clear on what each command is doing).The first line:
I'm guessing it'll ssh into 10 different machines and on each machine run Asynq server with concurrency set to 1 and only allow
ffmpegcommand to be run, is that right?The second line (I'm a bit more confused about this one):
Will this run
asynqexec submiton each machine that's running Asynq server?Isn't it sufficient to just enqueue tasks in Redis so that those 10 servers pulling tasks from redis will execute the whitelisted commands?
@xkortex commented on GitHub (Jun 12, 2020):
Sorry, I probably picked a bit too complex of an example :p
rush is a neat little app that just parallelizes jobs.
Precisely :)
The last command just submits a job for each filename found. Basically
will load up the queue and any server which is able to run that type of job will pick one from the queue and start running it.
Exactly.
Unless I'm missing something and there is an even easier way to submit the jobs to Redis directly.
@xkortex commented on GitHub (Jun 12, 2020):
Skeleton: https://github.com/xkortex/asynq/tree/dev/exeq
terminal 1
terminal 2
output terminal1:
exeq sub -- ls -lah ~exeq sub -- ffmpeg -i /path/to/vid_h264.mp4 -c:a copy -c:v copy -t 15 /tmp/out_h264.mp4Success!
@hibiken commented on GitHub (Jun 12, 2020):
Thanks for the explanation. The prototype looks good to me. I also like the command name 😉
Feel free to open a PR whenever you have a merge-able change.
I'm excited to see this command added to the project, and thanks for your contributions!
If you have any questions, you can ping me in this thread or in the Gitter channel 👍
@hibiken commented on GitHub (Sep 12, 2020):
@xkortex I'm closing this for now. Let me know if you are still interested. Thanks!
@xkortex commented on GitHub (Sep 21, 2020):
Yeah, that's fine. I got an implementation up and running but just when I was about to get it polished up for merger, I got slammed with a bunch of things at work. I've been using it to great effect on my system but it's still a bit rickety, so I'll just PR once I'm happy with it :)