Sourcegraph: proposal: stop using godockerize

Created on 26 Nov 2018  路  4Comments  路  Source: sourcegraph/sourcegraph

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:

  1. Easy to turn a Go service into a docker image without writing an entire Dockerfile.
  2. It is easy to share the base logic across all of our Go docker images (primary benefit).
  3. Docker directives live alongside the code (very minor benefit).

However, I would argue most of these benefits do not apply to us:

  1. We could have a base Docker image that all of our Go services are built from with roughly the same ease-of-use for adding new services.
  2. Same as #1 above.
  3. I would argue this is not a benefit because it is non-standard compared to reading/writing a Dockerfile.

Additionally, it has the following drawbacks for us:

  • We must write and maintain the godockerize tool, which is increasingly non-trivial and always needs more features and toggles as our services become more complex.
  • As seen in https://github.com/sourcegraph/godockerize/pull/9 the 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:

  1. Stop using godockerize
  2. Take the Dockerfiles we currently are generating via godockerize (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.
  3. Make all of our services have their own Dockerfile, using sourcegraph/go as the base image.
debt ops & tools & dev

Most helpful comment

I would love to stop using Godockerize. I think explicit Dockerfiles are more maintainable and understandable.

All 4 comments

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.

Was this page helpful?
0 / 5 - 0 ratings