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.
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.
That is in fact, I think, why fly.io is investing in trying to make it easier to deploy Rails, on their platform.
But also contributing to the effort to make Rails itself come with a Dockerfile solution, which Rails team is accepting into Rails core because, I'd assume/hope, they realize it can be a challenge to deploy Rails, and are hoping that the Dockerfile generation solution will help.
Heroku remains, IMO, the absolute easiest way to deploy Rails, and doesn't really have a lot of competition -- although some are trying. Unfortunate because heroku is also a) pricey and b) it's owners seem to be into letting it kind of slowly disintegrate.
I'm really encouraged that fly.io seems to be investing in trying to match that ease of deployment for Rails specifically, on fly.io.
The issue is how much RoR does and how tightly it is with its build toolchain - gems often require ways of building C code, whatever you use to build assets has its own set of requirements, there is often ffmpeg or imagemagik dependency. In my opinion, a lot of the issues are from Ruby itself being Ruby.
I agree that it's silly for such productive framework to be such PITA to deploy. To be fair, I pick RoR deployment over node.js deployment any day. I still not sure how to package TS projects correctly.
- productions servers should not have C compiler installed (why???) - compiling assets on every single VM that runs service is twice as silly
I'd still take that over something like AWS Beanstalk.
Checkout Cloud 66!
Whenever you've covered your bases, Rails grows in complexity. Probably necessary complexity to keep up with modern world.
Solved asset pipeline pain? Here's we packer. No, let's swap that out for jsbundle.
Finally tamed the timing of releasing that db migration without downtime? Here's sidekiq, requiring you to synchronize restarts of several servers. Oh, wait, we now ship activejob.
Managed to work around threads eaten by websocket connections in unicorn? Nah, puma is default now. Oh, and here's ActionCable you may need to fix all your server magic.
Rails is opinionated. And that is good at times. But it also means a lot of work on annoying plumbing having to be rebuilt for a new, or shifted opinion. Work on plumbing, that is not work on your actual business core.
To be fair, this was already an issue whenever you have more than one instance of anything. Whether it's an extra sidekiq or two web servers or anything else, you have a choice of: stop everything and migrate, or split the migration into prepare, update code, finalise migration.
But async workers have the tendency to be busy on long running processes, whereas a web server typically has connections that last at most seconds. Their different profile makes restarting just a tad harder.
I'm super stoked about the included Docker config and all the blog posts it will shortly inspire. Finding best-practices for Docker based deployments has been anything but fun. I'm still not sure how we'll implement the equivalent of `cap production deploy:rollback` and the like with Docker. Not that we use that basically ever, but knowing it's available is great.
Being able to generate a war or jar as a released binary is something that would be cool to see in the ruby world.
With Ruby and Python, most instructions for getting something going is just a series of "install this or that", "modify this file over there", "you could do this or that", "call this, than that, and then that", etc. These instructions tend to be developer focused. Virtual environments are usually left as an exercise to the reader and failing to use those leaves you with a big mess on your filesystem. Just pretend your production server is a snowflake developer laptop and you'll be fine seems to be the gist of it. Except of course that doesn't quite work like that anymore in many places and you need to take some steps to prevent that.
I spend some time face palming myself through the Apache Air (python) documentation trying to figure out a sane way to get that on a production environment. As it turned out that involved jumping through quite a few hoops. My conclusion was that whoever wrote that, was not used to dealing with production environments.
So, good that they are tackling this in the rails community. Stuff like this should not be an afterthought. With docker, you don't really need any virtual environments anymore. And you can also use them for development. That actually simplifies getting started instructions for both developers and operations people. Just use this container for development and run this command to push your production ready image to your docker registry of choice. No venvs, no gazillions of dependencies to install, etc.
Deploying Rails to PAAS solutions is also easy but used to be expensive with Heroku. I very recently started using DigitalOcean Apps for a personal project and it's been very easy, while costs look acceptable.
> We auto-magically add, configure, and deploy your services described in the procfile.
…but that’s an outright lie and they caveat that statement by saying they only support single processes which completely defeats the entire purpose of Procfiles.
https://docs.railway.app/deploy/builds
Maybe Fly does this better and I’ll give them a try.
Makes deployment super easy.
It's still going to be some what challenging for some folks as this Dockerfile makes its way through the community, but this is a really small step in the right direction for improving the Rails deployment story. There's now at least a "de facto standard" for people to build tooling around.
Fly.io is going to switch over to the official Rails Dockerfile gem for pre-7.1 apps really soon, so deploying a vanilla rails app will be as simple as `fly launch` and `fly deploy`.