
Dockerizing a Ruby on Rails Application - damir
https://semaphoreci.com/community/tutorials/dockerizing-a-ruby-on-rails-application
======
mbell
There are a couple weird things in here:

    
    
        COPY drkiq/Gemfile Gemfile
        WORKDIR /opt/app/drkiq
        RUN bundle install
    

This appears to be leaving out copying Gemfile.lock so you have no real idea
what versions of dependencies are being installed here. This is not safe. Also
it's installing a bunch of dependencies that are not needed in production, a
better bundle command would be something like: `RUN bundle install --no-cache
--jobs 4 --without development test`

    
    
        RUN rails webpacker:install
        RUN rails assets:precompile
    

Why is `rails webpacker:install` being run here? This is very odd. As a
general tip, I would also not compile assets as part of the docker build, but
rather externally then only copy over the `public` directory afterward. This
removes any need for `node` or any related development tools/packages in the
production image.

~~~
thrownaway954
not really... you can specify a specific version of a gem in the Gemfile.

gem 'byebug', '1.1.0'

~~~
mbell
That doesn't help with transitive dependencies.

------
MattyMc
Is anyone currently using this setup (Rails w Docker) in production?

I've been using Rails for years, I haven't yet experienced much pain by way of
language/library versioning (etc). Python is a different story...

~~~
t3rabytes
Yes, we do it at Basecamp for all of our legacy apps (and our newest one,
HEY), and we've ran Basecamp 2 in production via Kubernetes (we no longer do
it, but we did it for a lengthy period of time).

~~~
jakearmitage
I'm curious to know more about why you left Kubernetes. Performance?

~~~
t3rabytes
Nothing Kubernetes-related, it was provider-related. We hurriedly moved
Basecamp 2 back on-prem after a string of outages caused by our cloud provider
at the time. There are a bunch of blog posts on Signal v Noise from early 2019
that talk about it.

------
sandstrom
Any suggestions on how to do zero-downtime deploys with a Rails app running on
Docker?

I guess an obvious one is to use two running images, pull incoming requests
from one of them, take it down, update, bring it up, start traffic flow again.
Repeat for the other.

But is there any other method?

~~~
turtlebits
You don’t need to take your old app down or update during your cutover. Your
new app will be a new docker image, so just run an instance ahead of time.

When it comes to deploy, just repoint your load balancer/proxy.

------
mrinterweb
I've seen a lot of tutorials about getting a rails app to run with docker, but
this one is more complete than most. There is some good stuff here.

------
sealthedeal
Tbh I’m very shocked by how many people have never used docker with Rails. Am
I missing something?

~~~
ArturT
Maybe because of running Rails on Heroku is simpler than with Docker.

