Dockerfile best practices

[dwt]

Hi there,

I was evaluating this to ease building docker files for internal use in our company.

However, several questions came up:

• There seems to be no way to customize image building with my own dockerfile
• There seems to be no way to integrate this with a docker-compose.yml which handles file-system mappings into the container, as well as .env handling, exposed ports and dependent containers (e.g. databases, …)
• The generated Dockerfile doesn't seem to adhere to docker best practices like NOT running as root inside and ensuring that operating system packages are updated (no upstream docker image ensures that os level updates are installed and up to date, even on a clean build)

There is more, but this would be a good start. Am I missing something? Are these the constraints of this plugin right now?

[ofek]

Hello there! Currently only a plugin for Docker environments is offered, there is not yet a builder plugin where running hatch build would produce an image.

I don't have much time for implementation but am totally willing to review and release any PRs!

[dwt]

Maybe the best starter pull request would be to document the current goals of the project and where it should / could eventually go. What I understand from the code and your comments:

• Currently it is just meant to package the code into a docker container to prevent running it directly on the host. This allows choosing the / a base image of your choice to get nearer to your production environment
• It is not meant to build the docker image that is then deployed to production
• It does it map the code into the container to allow watching / auto restart on code changes behavior if the run command is configured correctly
• No support for docker-compose for support of sidecar / helper containers

Do you envision this to become a builder plugin that helps the developer build docker containers built with best practice for production that are used as unchanged as possible in development to minimize the differences in runtime environment?

Do you envision this to eventually encourage a docker composed based workflow that runs helper services (Apps consisting of multiple services, DBs, Reverse Proxy, …) out of different containers to ease setting up an environment that closely matches production with the ease of just typing docker compose up even for a new developer who has no setup previously?

Do you envision that this project eventually contains documentation on how to correctly setup various IDEs to run / debug code inside of these containers?

No pressure to any of this, I'm just trying to understand where you want / envision this project to be going.

[ofek]

everything you said is correct including the vision I have for the project with the exception of the compose part as I haven't thought much about that

[dwt]

Well, I like the docker-compose.yml workflow for new projects, especially if they are composed of multiple services (Database, Reverse Proxy, …) as that allows to get very near to the production environment with a very simple setup procedure, especially for new developers, as it regularly just requires docker compose up for them to get started.

I am not quite sure how hatch would fit into this, as managing all the other services and the docker-compose.yml file seems kind of out of scope for a python project manager. Managing / creating / updating / starting the Dockerfile however seems like it could be in scope and would provide an easy integration point with a docker compose based workflow for the larger project.