
Optimize Dokku Deployment Speed for Ruby on Rails Apps with Dockerfile - pawurb
https://pawelurbanek.com/optimize-dokku-deployment-speed
======
thejosh
You should really look into multistage builds. This sort of deployment should
scare you.

~~~
yebyen
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?

~~~
pawurb
CMD ["bin/run-dev.sh"]

comes from official Dokku docs,
[https://github.com/dokku/dokku/blob/master/docs/deployment/m...](https://github.com/dokku/dokku/blob/master/docs/deployment/methods/dockerfiles.md)

I don't think it has anything to do with running in dev environment only.

~~~
yebyen
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?

(edit: I am shocked to see the number of users who reported that Dokku was for
use in production in their orgs here...
[https://github.com/dokku/dokku/issues/1878](https://github.com/dokku/dokku/issues/1878))

~~~
yebyen
> 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.)

------
SkyPuncher
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.

~~~
pawurb
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 ?

~~~
undecisive
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!

------
thomasfedb
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.

~~~
pawurb
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.

~~~
thomasfedb
Exactly, as long as the Gemfile isn't changed.

Bumping the patch version on your CSS library resulting in a full redownload
and recompile of every gem sucks.

