Don't make multiple docker images for worker

[rtnpro]

Issue

Currently, we make multiple docker images for each worker script. This adds latency to the build/provisioning process.

Solution

We can create a single image with all the worker scripts and the run the image with worker specific commands.

[dharmit]

Isn't a container meant to have one service? How much magnitude of latency are we adding? I think the servers we're building our images on have a pretty decent bandwidth.

If creating containers is adding latency, why not just run the workers as systemd services like we used to do earlier?

[navidshaikh]

@dharmit :

If creating containers is adding latency, why not just run the workers as systemd services like we used to do earlier?

There will be one container image with all the workers script, and there will be 3 containers spawned from same image with different CMD.
If you look at the Dockerfile, there is neither CMD nor ENTRYPOINT given. 3 different workers will be created with different CMD with same image.

This will save build time of those images while doing deployment as well as this approach is efficient.

[dharmit]

That still doesn't mention a word about why not use systemd services instead? 😄

Systemd services can be configured to restart upon failure. With the approach of one Docker image having multiple services inside it, we might even then make things complex by adding supervisord or systemd inside the container to run these services.