Update Go language version 1.6.3 -> 1.9.0, as well as Alpine 3.4 -> 3.6

[ohaiwalt]

Fixes #80.

Definitely open to discussion about how this was done. The previous image base was Alpine itself, and then went on to install Go using the Alpine installer. Alpine 3.4 doesn't have recent versions of Go available, and as it turns out, even Alpine 3.6 doesn't have the package available yet.

The golang image used is Alpine 3.6 and builds Go from source. My largest argument against using the official golang image would ordinarily be size but this Alpine image is only ~80MB instead of ~270MB for something like Debian.

I built the Docker image and ran it with Cog, everything seemed to be working.

[ohaiwalt]

Also worth mentioning that I don't know enough about what's going on with the CI system to mess with those Dockerfiles just yet. Any insight there would be appreciated.

Specifically, what's different about the operable/go:1.6.3 image, why is it used instead of the same Alpine and install process?

[coveralls]

Coverage remained the same at 20.893% when pulling f44e34d on ohaiwalt/go-1.9 into 858b8ff on master.

[coveralls]

Coverage remained the same at 20.893% when pulling f44e34d on ohaiwalt/go-1.9 into 858b8ff on master.

[christophermaier]

@ohaiwalt OK, I think I've refreshed my memory on how CI is set up for this repo.

The Dockerfile.ci file is basically set up to provide an environment in which the unit tests can run. It's not trying to create any kind of deployable artifact or anything like that.

The Dockerfile file, on the other hand, is intended to be the "real" container image from which people can actually run Relay.

In reviewing all this, I think that Dockerfile.builder can likely be removed entirely. That was a holdover from when "building a deployable Relay container" meant creating the Relay binary out-of-band and then dropping that into an extremely bare-bones container (it may even have been FROM scratch, I think). All that is in the past, though, with the merging of this.

There's probably some additional historical layers at work here, too, from when I moved our CI from Buildkite to Travis CI. If you see ways to further consolidate our Docker usage as well as our testing approaches, then by all means, feel free to do so!

[christophermaier]

This looks like a good change to me!