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.)
This is intriguing, but it kind of goes against the essence of running Dokku.
We run Dokku because it's absolutely dead simple. It's not the fastest nor is it particularly scalable, but it works. There will be a point where we can't scale with just Dokku, but we'll cross that bridge when we come to it.
What you mean by essence ? It's a relatively simple config tweak that significantly increases comfort and stability of Dokku deployments, even in production environments. Going for a more "serious" deployment platform you would have to learn from scratch would be a better solution ?
Thanks for the blog post - it has opened my eyes to something dokku can do - I didn't even consider looking at it from that angle!
For me, the down side is flexibility. If I have a single project that I'm working on that pays all my bills, this approach is perfect.
But buildpacks do a lot more than just bundling and assets - and I like the fact that I can change the ruby version in my Gemfile and suddenly my server is using a different version of ruby.
That doesn't make this suggestion bad - I like that Dokku can be used in these two very different ways, and I have a couple of projects where this approach could be very useful. So thank you again!
Agreed. As someone currently moving my infrastructure to Dokku, where I have legacy apps on a range of ruby and non-rubies, this approach isn't scalable for my needs.
That said, I wonder if there is a middle ground - where we can use this technique to build a docker container that keeps the copy of ruby, holds known gems, sass caches, etc... all the expensive operations get quietly persisted, but the buildpacks still get run. This container could be created on a per-project basis, so maybe the first push would take longer than the others and that's fine, but instead of it taking 10-15 mins to push a project update, it could take less than 5?
I do something similar - mostly because buildpack downloads seen to time out ever second time. Just wish I could find a trivial way to cache installed gems to really get things flying along.
That's actually described in the post. Check out the part where Gemfile* is copied to /tmp, it results in gems getting cached between deploys as long as Gemfile itself was not modified.
