Prevent container from 'executing' outside schedule

[kimbamps]

Description

Problem situation

We have containers that run like a jobs for which we use this awesome scheduling solution. During deploy of a new container version or when they get a scheduled cron trigger, the container starts running and does its thing, which is great.

But when a container gets restarted manually, a host machine is rebooted, Docker Swarm labels are changed, ... this container service also start executing. Which normal behavior for a container, but we don't want that in our case, since it is generating to much unwanted load.

Before using this scheduling solution we made use of a container command to start the internal execution of the container. By default the container would start but would do nothing and end up in the completed state. Only when we provided a start command to the container he would execute the job in the container.

Request

Would it be possible to add extra label swarm.cronjob.container-command to provide a command to the scheduled container.

Possible implementation

I'm assuming you probably trigger a docker service update at schedule time? (I did have a look at the code, but GO really isn't my language ;))
But if my assumption is correct, you could possibly use the docker service update --args "<container-command>" <serviceName> command to facilitate this.

What are your thoughts on this? Or does anybody have other possible solutions for this problem?

[lzkill]

This enhancement is very welcome!

[cjsfj]

Presuming you're using Swarm, you can prevent automatically running the job on deployment (which includes reboots) by specifying the deploy.replicas key in your swarm yaml:

svcname:
    deploy:
        replicas: 0
        labels:
            - "swarm.cronjob.enable=true"
            - "swarm.cronjob.schedule=0 0 23 * * *"
            - "swarm.cronjob.skip-running=false"

[kimbamps]

That is indeed a good suggestion, but the application team also want the container to run on demand when when they redeploy it. Otherwise they need to wait for a scheduled moment or changes the schedules every time. With the risk that somebody forgets to set the schedule it correct again.
We could mitigate this by using multiple compose files, one with and one without schedule, but then they need to undeploy the 'manual' container again so that the container does not start when something is changed on the Swarm that triggers a container restart.

[lorello]

@kimbamps I understand the need, and our developers also need to run the container once each time a deployment occurs. We currently use replicas: 0 as the deployment configuration, and our workaround is to manually do the following for each deployment:

docker service update --replicas 1 <service-name> ; docker service update --replicas 0 <service-name>

This way, the problem you're experiencing doesn't occur.

However, I'm not entirely convinced by your proposed solution. Changing the container's entry point to manage deployment and scheduler behavior has a significant impact. Wouldn't an additional label like this be preferable:

swarm.cronjob.run-on-deploy: true

?

My 2c

[kimbamps]

@lorello Thank u for your suggestion, but we have a standardized deployment framework for all our teams and we try to keep all 'special' cases/implementation isolated to the smallest possible use case.

For your other suggestion, I don't see how the Swarm-cronjob container could controle how our job container is deployed and will respond on deploy time. From what I know about this project is a standalone container with a pretty clean separation from the job container based on the label from the job containers. So the swarm-cronjob container will only see the job container labels after deployment.

There are lots of official container on docker.hub where commands are use to controle certain behaviors, provide configuration, ... Like in our case, we don't need to change our container since it is already provided.

For me its more about giving the 'left over ;)' Swarm community some more options on how to reliably trigger job container. We will never be able to 'push' one solution to everybody, there are always multiple situation and criteria in play which define how people make use of job containers.