Running cron on the host of an Elastic Beanstalk Docker environment

0

Is it sensible to run cron jobs on the host of an Elastic Beanstalk docker environment?

For example, the cron tab would be something like the following, which would run the command "schedule:run" in an image from ECR:

* * * * * root docker run --rm -v /var/app/current:/var/www/html [ecr id].dkr.ecr.eu-west-1.amazonaws.com/my-image:latest schedule:run >> /dev/null 2>&1 && while pgrep php > /dev/null; do sleep 1; done

(the pgrep / sleep part keeps the container alive until background tasks started by the main thread finish)

The reason I want to run cron on the host instead of inside one of the containers defined by docker-compose.yml, is that I don't want long-running (30 minute+) jobs to delay or fail deployments. And I don't want those jobs to be killed halfway through. Elastic Beanstalk is keen to delete those containers every time there's a deployment.

(We do have a web-server and a queue handler defined in docker-compose.yml, so we will still be using docker-compose to start those services.)

  • Just an update on this, it did seem to be working fairly well but then for some reason EB stopped and started the docker service, whiwch obviously killed my long running job. I'm not sure if it's maybe just because I'd recently set the environment to 0 instances and then put it back to 1.

    2024/02/09 14:08:32.009175 [INFO] Running command /bin/sh -c systemctl show -p PartOf docker.service
    2024/02/09 14:08:32.020203 [INFO] Running command /bin/sh -c systemctl stop docker.service
    2024/02/09 14:08:42.729687 [INFO] Warning: The unit file, source configuration file or drop-ins of docker.service changed on disk. Run 'systemctl daemon-reload' to reload units.
    Warning: Stopping docker.service, but it can still be activated by:
      docker.socket
    
    2024/02/09 14:08:42.729770 [INFO] Running command /bin/sh -c systemctl disable docker.service
    
1 Risposta
0

Hello,

Thank you for reaching to us.

Elastic Beanstalk does control the environment instances and it runs docker service on the instance itself. Hence when there will be a reboot/ new instance launch, beanstalk will stop/start the docker service. This is because it is part of the environment, so bringing down the instance count to 0 will actually bring down the docker service as well, since there are no instances in the environment to run the service.

Also, please note that Elastic Beanstalk scales up and down the Ec2 instances within the autoscaling group according to the metric that it will be monitoring. So in order for the docker to be UP and running within the Elastic Beanstalk environment, you should need to make sure that the instance count is never going to 0.

AWS
TECNICO DI SUPPORTO
Nakul_D
con risposta 4 mesi fa

Accesso non effettuato. Accedi per postare una risposta.

Una buona risposta soddisfa chiaramente la domanda, fornisce un feedback costruttivo e incoraggia la crescita professionale del richiedente.

Linee guida per rispondere alle domande