Leaner Docker image through the use of multi-stage builds #51
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In #50 I was able to successfully push an image to Docker Hub, but quite
a large one -- weighing in at 91 MB, which is pretty heavy for this
small program. It's big because it includes the entire Go build system.
Here we lean out the final image by switching
Dockerfile
to use amulti-phase build strategy. This creates one image initially based off
of a Go image which is used to build the final release program, then
creates a second image based on the lightweight Alpine Linux and copies
over the release binary.
This has the effect of reducing the final image's size from 91 MB to a
lean 13.7 MB (that's Alpine Linux +
stripe-mock
), which is faster/cheaperfor users to pull.
A smaller optimization is to add a
.dockerignore
file which preventsus from having to copy a number of extraneous files into the Docker
daemon for the initial build. This will help nominally to speed things
up.
One slight loss is that I've removed testing within the Go image from
.travis.yml
because we no longer have a Go runtime with which to rungo test ./...
. I think this is okay because we're already runningtests elsewhere in the Travis build, and it's unlikely that running them
in a Docker container is going to surface anything extra.
Here's me running the image locally:
And a successful cURL:
r? @ob-stripe
cc @stripe/api-libraries