Search code examples
gitdockerrepositorydocker-registryorganization

Difference between sharing a Dockerfile and a Docker image?

I am trying to get a good understanding of Docker best practices and to clarify what is the difference between:

  1. sharing the Dockerfile (specs/build configuration) including language specific config file (such as requirements.txt for Python or package.json for Node ).

and

  1. creating and sharing a Docker image via a registry (e.g Docker Hub) ?

In the first case the user needs to clone the repo to get the specs and run the docker build to create an image.

_

What would be the general best practice for storing and sharing "Docker code" (for the lack of better term) when getting started with Docker or working on personal projects?

In which situation would it be preferred to share a built image via the registry?

Solution

  • TL;DR

    Pushing the image to a public repository would enable others to pull the built image and run it. Providing access to the source code and Dockerfile would enable others to build the image locally. They're not mutually exclusive.

    For example, I release public images to Docker Hub for running self-hosted GitHub Actions Runners in Kubernetes. The releases are done using GitHub Actions from the public GitHub repository. I plan on supporting released versions (tagged builds from a git tag) (i.e. if someone installs a released version and reports an issue) but at the same time everything is available for people to hack at it if they want too (+1 for opensource) without limits on what you're allowed to do (MIT License) - say you wanted to add some apt packages to the runner image, just do eeet then build and use your own image (... and if it makes sense for other users then maybe consider creating a pull request with the changes).

    You might be able to host a public repository with a proprietary license but would need to confirm the legality.

    You can definitely host a private repository and release public images but beware that if you're trying to hide your codez then you should expect people like me to inspect your image if I get my hands on it so I'd suggest building compiled binaries (i.e. go program built FROM scratch).

    You can also definitely host private repos and release your images to a private docker registry then control access to your images (i.e. distribute a docker-compose.yml configured with your private images and require that customer docker login to pull the images).