You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have python / Flask running in a Docker container deployed to a cloud service (AWS).
It responds to HTTP API requests (GET, POST)
Everything is working fine there with this.
Now I want to implement some recurring tasks that run inside the container using any Python scheduler or cron like package.
The recurring tasks may take 30 mins or an hour and will be running inside the container in parallel with responding to API requests without interruption.
I stumbled upon a Python library called 'schedule' (import schedule) and some sample code here
import schedule
from datetime import datetime
def job():
print('\n---\njob()')
now = datetime.now()
current_time = now.strftime("%H:%M:%S")
print("Current Time =", current_time)
print("I'm working...")
schedule.every(10).seconds.do(job)
while True:
schedule.run_pending()
time.sleep(10)
You can see the problem here where the package requires a while True: loop If that is running when the container is instantiated, (in the loop always), the container will not respond to API requests.
Is there another scheduling package that does not require a dedicated loop running all the time?
It seems like I need something external that sleeps for so many seconds and then makes an API call to the container that would invoke:
schedule.run_pending()
but even then, this will not work because the job() running within an API call ( a long running task ), may take 30 mins to 1 hour to run and hit an HTTP time out.
How can I have an API server that responds to API requests, but also runs internally long running tasks initiated by an internal scheduler in the container?
I am not running under an EC2 or GCE instance where traditional cron can be used. I am using a service that simply hosts and runs a single container.
Requirements:
Docker container API server that responds to HTTP requests (GET, POST)
has the ability to run any number of tasks on a schedule that may be long running where the container will stay active and not be shut down or moved out of the cloud hosting service that is running it.
If you have actually done this and have done this with a working solution, please respond.
The text was updated successfully, but these errors were encountered:
I have python / Flask running in a Docker container deployed to a cloud service (AWS).
It responds to HTTP API requests (GET, POST)
Everything is working fine there with this.
Now I want to implement some recurring tasks that run inside the container using any Python scheduler or cron like package.
The recurring tasks may take 30 mins or an hour and will be running inside the container in parallel with responding to API requests without interruption.
I stumbled upon a Python library called 'schedule' (import schedule) and some sample code here
https://github.com/dbader/schedule
You can see the problem here where the package requires a while True: loop If that is running when the container is instantiated, (in the loop always), the container will not respond to API requests.
Is there another scheduling package that does not require a dedicated loop running all the time?
It seems like I need something external that sleeps for so many seconds and then makes an API call to the container that would invoke:
schedule.run_pending()
but even then, this will not work because the job() running within an API call ( a long running task ), may take 30 mins to 1 hour to run and hit an HTTP time out.
How can I have an API server that responds to API requests, but also runs internally long running tasks initiated by an internal scheduler in the container?
I am not running under an EC2 or GCE instance where traditional cron can be used. I am using a service that simply hosts and runs a single container.
Requirements:
If you have actually done this and have done this with a working solution, please respond.
The text was updated successfully, but these errors were encountered: