On-demand background service

I need some advice on the most appropriate service to use on Render. Can somebody provide some guidance?

I have a front-end web service (APIs) that is always available. That service enables end-users to request an on-demand job. No pre-scheduling. The end-user wants the result of the job.

The requirement is to spin up a new docker container for each request by an end-user, run the job, and shut it down after job termination. One way to accomplish that is for the front-end web service to resume a background service, initiate the job, and then suspend the service on completion of the job. A health check is irrelevant for the backend service.

The alternative is to set up a cron job service. Schedule that once a year (a schedule is irrelevant to our needs). If the scheduler happened to invoke the job, the app will fail very quickly and terminate the app with no side-effects to us. Not sure about Render.

In regard to job termination, the app will self-terminate and produce exit codes - 0 for success, and everything else to indicate state at termination. I am not clear how Render monitors job termination. The app is written in c#.

Which service, background worker or cron job is best suited for these requirements?

Thanks,
Dan

Hey Dan,

If it were me building it, I’d have my API and have a background job processing jobs. The API would drop the job into the queue and then a worker would execute the job which spins up the Docker container, executes etc etc. This way, if you need to be running parallel jobs it’s just another job in the queue and it triggers another Docker container to be built. The methods you originally describe don’t sound all that scaleable resuming jobs or a cronjob.

Regards,

John B

Thanks for the reply, John.

Ideally, I prefer to do what you described. I am struggling with Render’s documentation and docker is new to me. I use Render’s static site along with Vitepress and it works great. Thank you.

I expect to run the API front-end and a postgre db on Render. However, the worker is a custom simulator/optimizer. It’s a rather large and complex code base. It receives a large user-specified model for input. The simulator is invoked, runs, and ends. The monitoring I require is to confirm the app finished and the container terminated. The rest is handled by the simulator.

My requirement is NOT to be responsible for administering a queue manager. I can conceptualize how I could use Iron.io’s service, but I am struggling to determine if I can accomplish something similar on Render.

But I am really unclear as to how Render’s job service actually works – or how even how to invoke it using a docker image. (I spent hours searching for the ServiceId source.) The typical process for a real-time app is: Render builds the docker image and then deploys. That seems to be Render’s strength.

The simulator app doesn’t need to be deployed (go live) on a new build - just available in Render’s registry. If it’s in Render’s registry, what is the startCommand to invoke it as a job and drop it onto Render’s queue? I have been assuming that Render is the queue manager on the back-end. Is that not correct?

FWI, on my local machine, my start command looks like this:

"docker run -it image-name -a xxxxx -b xxxx -c [model]

… which is based upon a docker file with the following entry point style: ENTRYPOINT [“dotnet”, “mydotnetapp.dll”]

Feel free to steer in the right direction!

Thanks,
Dan

We don’t manage queue’s or such like - we just run services so if you want a queue then you’d need to deploy a queuing service for us to run.

I’m struggling with what you’re trying to describe here - I’d encourage you to give things a try to see if it’s going to be possible on us to begin with.

Regards,

John B

Hi John,

I need to determine if I can run a docker image on an “on-demand” basis (aka, a batch job) via an api (not a CLI). This batch job has the characteristics of a cron job, without the pre-determined schedule.

The image render pulls from GitHub repo contains an application that is the batch job. The application receives required parameters defined by the dockerfile ENTRYPOINT [“dotnet”, “ZyprSimulator.dll”].

If render attempts to automatically deploy the repo, it will return a failure code because the required parameters to the ENTRYPOINT are not provided by the repo. Render will therefore show a failed deployment. That failure is harmless to my needs, since my intention was NOT to deploy a service that is always in a running state (i.e., not predetermined termination time).

My need is to have an image available from Render’s image registry to invoke on-demand. At that time the necessary parameters are provided. The job executes to completion and returns an exit code that should trigger the termination of the container (i.e., terminate the service). So the definition of a unique job is:

  1. identical image for each job
  2. different parameters for each job

I hope this better describes my needs. btw, I have played around with various services. I have not found the correct “start command” to invoke the docker image.

Thank you,
Dan

On us, whether it’s a cron job or a job itself, they have a backing repo as you rightly say, which can be a Docker build. For a job you can pass in the command to execute and we’d run that (as per https://render.com/docs/jobs).

John B

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.