from Hacker News

Rails on Docker

by mikecarlton on 1/26/23, 4:32 PM with 220 comments

• by jchw on 1/26/23, 4:47 PM

  > Everything after that removes the manifest files and any temporary files downloaded during this command. It's necessary to remove all these files in this command to keep the size of the Docker image to a minimum. Smaller Dockerfiles mean faster deployments.

  It isn't explicitly explained, but the reason why it must be in this command and not separated out is because each command in a dockerfile creates a new "layer". Removing the files in another command will work, but it does nothing to decrease the overall image size: as far as whatever filesystem driver you're using is concerned, deleting files from earlier layers is just masking them, whereas deleting them before creating the layer prevents them from ever actually being stored.

• by brundolf on 1/26/23, 4:56 PM

  I used to think I hated Docker, but I think what I actually hate is using Docker locally (building/rebuilding/cache-busting images, spinning containers up and down, the extra memory usage on macOS, etc etc). I don't need all that for development, I just want to run my dang code

  But I've been really enjoying it as a way of just telling a PaaS "hey here's the compiler/runtime my code needs to run", and then mostly not having to worry about it from there. It means these services don't have to have a single list of blessed languages, while pretty much keeping the same PaaS user experience, which is great

• by nickjj on 1/27/23, 1:00 AM

  If anyone is looking for a complete guide I put together this last month: https://nickjanetakis.com/blog/a-guide-for-running-rails-in-...

  It includes running Rails and also Sidekiq, Postgres, Redis, Action Cable and ties in esbuild and Tailwind too. It's all set up to use Hotwire as well. It's managed by Docker Compose. The post also includes a ~1h hour ad-free YouTube video. The example app is open source at https://github.com/nickjj/docker-rails-example and it's optimized for both development and production. No strings attached. The example app has been maintained and deployed a bunch over the years.

• by alberth on 1/26/23, 5:19 PM

  Am I the only person who struggles to deploy Rails apps.

  It's a super productive framework to develop in, but deploying an actuals Rails apps - after nearly 20 years of existance, still seems way more difficult than it should be.

  Maybe it's just me.

• by sdwolfz on 1/26/23, 5:37 PM

  I have my own local development Rails setup and template files that could be dropped in any project with minimal changes (mostly around configuring the db connection)

  - https://gitlab.com/sdwolfz/docker-projects/-/tree/master/rai...

  Haven't spent the time to document it. But the general idea is to have a `make` target that orchestrates everything so `docker-compose` can just spin things up.

  I've used this sort of thing for multiple types of projects, not just Rails, it can work with any framework granted you have the right docker images.

  For deployment I have something similar, builds upon the same concepts (with ansible instead of make, and focused on multi-server deploys, terraform for setting up the cloud resources), but not open sourced yet.

  Maybe I'll get to document it and post my own "Show HN" with this soon.

• by wefarrell on 1/26/23, 6:01 PM

  I do miss the pre-docker days of using capistrano to deploy rails projects. Most deploys would take less than two minutes in the CI server and most of that was tests. The deploys were hot and requests that happened during the deploy weren't interrupted. Now with Docker I'm seeing most deploys take around ten minutes.

  The downside of capistrano was that you'd be responsible for patching dependencies outside of the Gemfile and there would be occasional inconsistencies between environments.

• by cvccvroomvroom on 1/27/23, 4:01 AM

  Thanks but I already have my own containers and infrastructure for dev and prod Rails.

  It's fine for people who are just starting out or want a repeatable environment.

  Also, if you want stability and fewer headaches long-term:

  - use a RHEL-derived kernel and customize the userland (container or host) quay.io has a good cent 9 stream. Ubuntu isn't used at significant scale for multiple reasons, and migrating over later is a pain.

  - consider podman over docker

  - use packaging (nix, habitat, or rpms) rather than make install (and use site-wide sccache)

  - container management (k8s or nomad)

  - configuration management (chef) because you don't always have the luxury of 12factor ephemeral instances based on dockerfiles and need to make changes immediately without throwing away a database cluster or zookeeper ensemble

  - Shard configuration and app changes, with a rollback capability

  - Have CI/CD for infrastructure that runs before landing

  - Monitoring and alerting

  - Don't commit directly to production except for emergencies. Require a code review signoff by another engineer. And be able to back out changes.

  - Have good, tested backups that aren't replication

  - Don't sweat the small stuff, but get the big stuff right that doesn't compound tech debt

• by agtorre on 1/26/23, 4:56 PM

  This is really cool. Is the Rails server production ready? I was always under the impression you had to run it with Uvicorn or similar, although I haven't been following Rails development recently.

• by jupp0r on 1/27/23, 7:57 AM

  Will it be called "Ruby on Whales"? Joke aside, it's trivial to write your own Dockerfile and this still is what nontrivial apps will do, due to customization.

• by rcarmo on 1/26/23, 5:21 PM

  > RAILS_SERVE_STATIC_FILES - This instructs Rails to not serve static files.

  ...but... it's set to True....

• by dieselgate on 1/26/23, 8:24 PM

  I've found the "Docker for Rails Developers" book by Rob Isenberg [1] to be a great resource for getting started using Rails and Docker. It's only a couple years out of date at this point but should still be highly relevant for anyone trying to get started. The only issue I've had with Rails and Docker is serving the container on a 1gb d.o. droplet - the node-sass gem is usually a sticking point for a lot of people and believe the 1gb droplet to be just too small to host a dockerized rails app. But the benefits of using docker for Development is still overwhelmingly worth the effort of containerizing things.

  It's super cool rails 7.1 is including the Dockerfile by default - not that rails apps need more boilerplate though..

  [1]: https://pragprog.com/titles/ridocker/docker-for-rails-develo...

• by dewey on 1/26/23, 5:48 PM

  This is long overdue. Rails got very nice updates in the past years to make it easier to handle JS and other assets.

  Deploying it was still always a hassle and involved searching for existing Dockerfiles and blog posts to cobble together a working one. At the beginning I always thought I'm doing something wrong as it's supposed to be easy and do everything nicely out of the box.

  And dhh apparently agrees (Now at least: https://dhh.dk/posts/30-myth-1-rails-is-hard-to-deploy) as there's now a default Dockerfile and also this project he's working on, this will make things a lot nicer and more polished: https://github.com/rails/mrsk

• by bradgessler on 1/26/23, 5:36 PM

  I have a proposal out for making the deployment story even easier by providing RubyGems a way to describe the packages they depend on to operate properly at https://community.fly.io/t/proposal-declare-docker-images-de...

  The idea is I could run a command like `bundle packages --manager=apt` and get a list of all the packages `apt` should install for the gems in my bundle.

  Since I know almost nothing about the technicalities and community norms of package management in Linux, macOS, and Windows, I'm hoping to find people who do and care about making the Ruby deployment story even better to give feedback on the proposal.

• by ginzunza on 1/26/23, 4:59 PM

  This is a manual using that image with Redis and Postgres: https://medium.com/@gustavoinzunza/rails-redis-pg-with-docke...

• by revskill on 1/26/23, 7:35 PM

  This is a really good news. And to be fun, the easiest way to become mainstream, is to have a guide on how to deploy a Rails application in 1 click, for any cloud hosting service.

• by laneystroup on 1/26/23, 10:13 PM

  I still use Capistrano. In fact, I like Capistrano so much that I have full Load Balancing, Auto-Scaling, and End-to-End encryption enabled for my projects on AWS via the elbas gem.

  My primary use case for this is PCI Compliance. While PCI DSS and/or HIPAA do not specifically rule out Docker, the principle of isolation leans heavily twoard the principle that web hosts must be running on a private virtual machine.

  This rules out almost all docker based-PaaS (including Fly.io, Render.com, AWS App Runner, and Digital Ocean), as these run your containers on general Docker hosts. In fact, the only PaaS provider that I can find advertising PCI compliance is Heroku, which now charges +$1800/month plus for Heroku Private to achieve it.

  I would love to share my configuration with anyone that needs it.

• by e12e on 1/27/23, 1:40 PM

  For some more (too many?) in-depth tricks for rails and docker, see also:

  "Ruby on Whales: Dockerizing Ruby and Rails development"

  https://evilmartians.com/chronicles/ruby-on-whales-docker-fo...

  Previously posted to hn - but without any comments.

• by throwaway23942 on 1/26/23, 8:31 PM

  I use FROM scratch. The app itself is built with a binary packer that is copied in.

  Still, I'd much rather use Nix/Guix over Dockerfile.

• by 023984398 on 1/27/23, 4:09 AM

  This is awesome and I'm glad Rails is adding something official here. Unfortunately if you want to use the Dockerfile in development with docker-compose you will need to make some changes/additions. Most notably: only precompile assets if deploying, not during development

• by thrownaway561 on 1/26/23, 5:33 PM

  Though this is a great step... you still have to edit the Dockerfile if you are using Postgres and Redis.

• by marcopicentini on 1/26/23, 7:34 PM

  Deploying with Cloud66 is a lot easier. Just git push.

  I can chose my hosting provider and switch each other.

• by iamflimflam1 on 1/26/23, 5:51 PM

  What kills rails for me at the moment is the time it takes to start up. I'd love to be able to use on top of things like cloud run where resources ramp down to zero when there are no requests, but the startup time makes this very difficult.

• by bploetz on 1/26/23, 5:30 PM

  It's been a while since I've done any Ruby/Rails development, but just curious why they chose to use a Debian/Ubuntu based image in the default Dockerfile instead of an Alpine based image?

• by benced on 1/27/23, 9:30 AM

  As someone who doesn’t know rails at all, what’s the innovation here? Surely Rails has had Dockerfiles written for it before?

• by garfieldnate on 1/27/23, 12:43 PM

  How on earth did Rails not have an official Dockerfile until now? Have people been deploying like it's 2010?

• by hit8run on 1/26/23, 7:54 PM

  I use dokku. Works really well.

• by quest88 on 1/26/23, 6:00 PM

  But how does this work when talking to dev databases on my machine?