2

As the amount of docker images and corresponding docker_entrypoint.sh files increases, I end up with repeated bash code across all entry point scripts. Since I hate repeated code my first thought was to create a shared lib folder with bash routines that are used by multiple entry point scripts.

However I'm not sure if this is a good practice mainly because we are leaving Docker's build context and we may get errors such as Forbidden path outside the build context (e.g. see here). I realize that we may work around this type of problems by doing something like creating symbolic links to connect the build context to the lib folder, but I'm not sure if I like this type of approach.

Therefore my question is whether it is a good idea to have shared libs for Docker entry points at all and: i) if not, is there a better approach to avoid repeated code; ii) if so, what is the best way to avoid problems such as the above-mentioned ones.

Thank you all for your attention

João Matos
  • 6,102
  • 5
  • 41
  • 76

1 Answers1

2

I would put your common code in a company base image, and call that common code from each of your child image's entrypoint.sh scripts. You will need a company base image for each of your extended upstream images, which isn't a problem if everyone uses the same upstream base image, but becomes a challenge if you have lots of different languages to support.

Another option, if you have lots of upstream images to support, you could get away with extending multi-stage builds to copy files from one "entrypoint" image you manage to each of your other images:

Dockerfile for entrypoint code could look like:

FROM scratch
COPY entrypoint_bin /usr/local/bin

Then you can add something like this to each of your other images:

FROM entrypoint:latest as entrypoint
FROM node_or_jdk_or_something_else:1.0
COPY --from=entrypoint /usr/local/bin /usr/local/bin
...
BMitch
  • 231,797
  • 42
  • 475
  • 450