Currently, we use a tool called godockerize to read //docker:foo directives and build our Docker images. From my point of view, we chose this because of the following alleged benefits:
Dockerfile.However, I would argue most of these benefits do not apply to us:
Dockerfile.Additionally, it has the following drawbacks for us:
godockerize tool, which is increasingly non-trivial and always needs more features and toggles as our services become more complex.godockerize tool is not trivial and can lead to show-stopping bugs for us when it improperly generates Dockerfiles due to bugs (like pulling in directives from a non-singular file sources (i.e. any package being bundled with godockerize, rather than just main.go or Dockerfile)).Proposal:
godockerizegodockerize (THIS IS IMPORTANT because godockerize has some things in it like DNS fixes for our services) and create a new base sourcegraph/go image designed for writing Go services.Dockerfile, using sourcegraph/go as the base image.I would love to stop using Godockerize. I think explicit Dockerfiles are more maintainable and understandable.
Wholeheartedly agree. I once wanted to check/update the version of some environmental thing in an image and it took me forever because there was no simple Dockerfile.
:+1: I wasted a few hours trying to figure out how an image was being built, and didn't realize until someone told me we use godockerize.
@tsenart mentioned that this would greatly simplify the postgresql task he is tackling. As such I'll take a look at this in this milestone.
Most helpful comment
I would love to stop using Godockerize. I think explicit Dockerfiles are more maintainable and understandable.