My learnings from publishing my first ever Dockerfile for ugit (a shell script based tool to undo git command) and writing the most optimized dockerfile for it.
But you’d use the shell script as part of something else, surely? As in, it’s not a container, it’s something deployed as part of or copied into a container?
That depends, we have quite a few images that are just a single shell script or a collection of shell scripts which run as jobs or cronjobs. Most of them are used for management tasks like cleaning up, moving stuff or debugging.
Has the big advantage of being identical on each node so you don’t have to worry about keeping those shell scripts up to date with volumes. Very easy to just deploy a job with a debug image on every node to quickly check something in a cluster.
Of course, if the shell script “belongs” to an application you might as well add the shell script in the application container and override the start arguments.
But you’d use the shell script as part of something else, surely? As in, it’s not a container, it’s something deployed as part of or copied into a container?
That depends, we have quite a few images that are just a single shell script or a collection of shell scripts which run as jobs or cronjobs. Most of them are used for management tasks like cleaning up, moving stuff or debugging.
Has the big advantage of being identical on each node so you don’t have to worry about keeping those shell scripts up to date with volumes. Very easy to just deploy a job with a debug image on every node to quickly check something in a cluster.
Of course, if the shell script “belongs” to an application you might as well add the shell script in the application container and override the start arguments.