Context
I hope the following diagram makes it clear, ask if you still need any answer.
Basically, the cronjob itself (a container) will run every hour, that needs to use a long running redis service. (The redis service acts as an interface to some other worker containers, but the cronjob will not connect directly to them). Everything running inside the same Ubuntu instance with docker set up.
Initial Idea
I have the docker compose file that can fire up the workers and the redis service. But can I put an hourly cronjob running on a container (not a long running service) in the same file, to take advantage of the docker-compose networking? In that case, I don't have to expose 6379 to the localhost, am I correct?
Alternatively, if I handle the worker and redis service inside compose, can I make the cronjob container run inside the same network without exposing/publishing post 6379?
Some ideas and options available in docker's networking/compose stack around this scenario will be appreciated.
And I don't have a K8S cluster available, and it's not feasible. So have to keep the solution within standalone docker stack.
Further Clarifications
Based on @ajay's helpful answer, I decided to add some more clarifications on how I am envisioning the docker-compose
and the cron schedule.
services:
redis: # This becomes the hostname
image: "redis:alpine" # port 6379 of this runs the service.
workers:
# The workers must not be directly visible to the cronjob.
# But each worker container must access redis:6379
image: della/worker # From Dockerhub registry
depends_on:
- redis
deploy:
replicas: 5 # Scale out
The Cron schedule looks like this
# The cronjob_container must be able to reach redis:6379
# Takes ~5 minutes to run.
@hourly docker container start cronjob_container
The cronjob_container
cannot be part of the docker-compose
because it's not intended as a long running service. But it needs to be part of the network defined by docker compose.
However, if the compose file allows a cronjob instead of a service, something akin to Kubernetes CronJob
resource, that would be the ideal solution.