Dockerizing a Ruby on Rails Application | Hacker News Reader

Dockerizing a Ruby on Rails Application

semaphoreci.com

84 pointsdamir27 comments

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.

Instead of compiling assets externally, you could do it in a multi stage docker build.

You can but I've not found the value in the complexity. The CI container image already requires node and all the needed dev packages for tests to run anyway so I just run the precompile in the CI container after tests pass then copy the resulting `public` directory into the production container.

This also means the same exact environment is used to generate the production assets that was used to generate them for test.

I've found it increases portability and makes it both easier to move between pipeline providers and debugging failed builds locally.

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

As someone who's only touched Ruby for a few years (and not even Ruby on Rails): I wouldn't have even known to look for a Gemfile.lock.

Perhaps the author doesn't know either.

> As someone who's only touched Ruby for a few years

Well... Gemfile.lock has nothing to do with rails and all to do with Bundler, but if you've never used Bundler for dependency management it's possible that it's new to you.

But Bundler (and the Gemfile and Gemfile.lock) are one of the core components of rails, they even get mentioned in the getting started page (https://guides.rubyonrails.org/getting_started.html).

I only have a couple of years of experience with rails and haven't touched it in 6 years, but I'd be very sceptical of any article that tries to teach how to build projects in rails and doesn't even get those basics right.

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

gem 'byebug', '1.1.0'

Yes you could do that for all your gems... Or you could just copy in Gemfile.lock. One of the big reasons to run in containers is repeatability and knowing if it runs in your local Docker fine it will run the same on another Docker like system.

That doesn't help with transitive dependencies.

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

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

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

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.

What are y'all using instead of k8s?

Kubernetes for HEY, ECS for the other legacy apps that I mentioned are using Docker, bare metal for Basecamp 2 & 3 (but K8s is on the roadmap for both of them)

GitLab has a pretty nice image for running their Community Edition in Docker.

I've investigated it a few times for several Rails applications that I maintain, but I've never completed a rollout. Running Rails on Docker isn't a huge hurdle, but Capistrano's default git-based deploys are just so _easy and fast_ once the server is set up. I also have to balance deploying Docker with ops' expertise.

I do recommend getting a copy of _Docker for Rails Developers_ to avoid needing to read a bunch of disparate blogs, though it covers Docker Swarm instead of Kubernetes.

[1] https://www.amazon.com/Docker-Rails-Developers-Applications-...

We have a number of Dockerized Rails apps hosted on AWS Elastic Beanstalk. It isn't quite as smooth as Heroku but once setup it has been quite solid. The parity between develop and prod is decent, we use docker-compose and localstack to simulate backing services.

We've had our Rails like apps (Sinatra, Padrino) Dockerized for 5 years now and running on container orchestration systems. First Mesos, now Kubernetes. And some running as Lambdas as well. We do not have a single production app not in a container and we are mostly Ruby.

We have run on Docker and ECS for a couple of years.

Discourse is a Rails app and all our deployments use Docker. Our image is open source, under our org in both GitHub and DockerHub.

I use docker as a build server. At the end of the project it spits out a debian package that I can install on a machine. It doesn't need bundler, only ruby and the gem command (up to a certain version). Quite a nice setup if you look for bare metal performance

I run my side project in Docker on Kubernetes, works well and wasn’t too annoying to set up. Compared to getting my Go deployments to run it was kind of a pain though.

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?

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.

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.

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

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

Reply on news.ycombinator.com