Isn't the point of multistage build to have your build-time dependencies isolated from run-time dependencies, so that you can jettison the build-time deps before deploy and have a smaller image?
Does that really make sense with Ruby? I mean sure, maybe you don't need that C compiler at runtime, ... unless you wanted to avoid building a new image every single time you needed to try adding a new Gem to your Gemfile that might try to compile some native extensions ... and maybe that shouldn't be happening as often as I'm imagining, and the right thing to do is to build a new image... but:
CMD ["bin/run-dev.sh"]
I don't know what to make of this but it does look like something that's intended for use in development. If I was going to ad-hoc "bundle update" to give my app's Gemfile.lock a refresh anywhere at all, it'd be here. So I'll need those...
Can you elaborate on why this should scare you? I've actually been given some orthogonal advice (nothing to do with multi-stage)... that a buildpack is something you don't want anywhere near your production servers, and that I should be using Dockerfiles or pre-built images instead (so, closer to what's suggested by the OP.)
I don't know why I'd follow either piece of advice. I love buildpacks! But what exactly do you find scary about these particular Dockerfiles?
Well that's fine, I don't know who uses Dokku in production... I think it's granted that it is a solution for development.
My point is that for Windows users, for example, they might be using containers to do their development because the host environment is unsuitable for running Ruby in.
This is not a hypothetical situation. I work in a setting with mixed developers (some using Windows, some using Mac) and the Windows developers need a Virtual Machine or Container in order to run Ruby in. I use a Mac. If I gave them multi-stage containers which had jettisoned a stage and now had no C compilers, they would be stumped the first time they tried running 'bundle update'.
And running 'bundle update' is the (only) prescribed way to get new gem versions into your Gemfile.lock, so... back to where we started. Are you sure this is a strategy for Ruby devs using Dokku?
> If you need Node to compile your web assets but don't need it in production, your final container doesn't need to have Node
OK, I'm coming around. You could drop node and C compilers from your image, shedding a lot of weight. This still seems like something I'd really only want to do in production.
(In a development setting, I'd like my team to be able to break into the containers and execute arbitrary commands. We should be able to, for example, "bundle update" or "assets precompile" without having a need for another separate environment to do those things. But in production, I don't want anyone running arbitrary commands or making "configuration drifts" inside of my running containers. They should be homogenous.)
