@jamesgibson14 Thanks for confirming that it worked. Maybe post your findings in the PR. I think it would be best to build the tests that were requested in this pull request and get the PR merged in officially.
@aedm Great news on your image. You would need that PR to work with Meteor Up and some other changes too (as it works mainly on mounts, but it should be doable). I'm absolutely open to changing some aspects of SpaceGlue though. I realize folks are looking for a "small image", but I think there are some considerations to make.
For example, I think it's worth weighing out the build-speed benefits are achieved of having the cached Docker layers produced by the additional
RUN commands and the use of the
-builddeps image for the
-onbuild image which needs most of those tools to be installed to reliably build all projects that are thrown at it.
In SpaceGlue, I chose
buildpack-deps:jessie-curl since it is used by the
node Docker image right now. It is a large base image though. I do think Alpine is the direction to go, but I haven't been able to say (in other words, I don't have time to test) that every project thrown at SpaceGlue would build properly on Alpine. I'm fairly confident in Debian right now and SpaceGlue is meant to "just work".
I think there is a benefit to the faster image build times achieved by having the dependencies already downloaded and installed. The bulk of the size in my images is the Debian OS, and various compiler toolchain components. In practice, these layers are cached by CI servers (and container registries) and are loaded (and are
docker pushed-to) fairly quickly. For example, if I do a new commit to my repo, my image is very quickly already building the app itself and not
apt-get-ing various build dependencies.
In an enormous deployment I understand the benefits of the slim images. Even if I was to remove the build dependencies in the Dockerfile, unless they are all done in the same step, the higher layers hold most of weight still and aren't freed up. Given the current setup, if a smaller image is desired, something like
docker-squash can be helpful and would do a nice job of "flattening" the image created by SpaceGlue (if I actually push the commits which
apt-get remove things at the end of the build, which I haven't, yet).
I'm not sure there is a way to do everything perfectly with a single image which you reference in your app. I could imagine the most benefit in a setup which runs from outside Docker and passes work to various Docker images which do a particular portion of the workload. A three-part system, for example: 1) Which builds the bundle
meteor build and outputs the tarball, 2) An Alpine distro with build dependencies which takes that tarball recompiles it and outputs another tarball, 3) An Alpine distro that just runs the final tarball.
Sheesh, the more I think about all the ways this could be done, the more I intend to use Galaxy for any future project. Running your own infrastructure can be a real time-sink.