My first message here, and before anything just to thank all the people that makes Rails possible. I’m in love with it. Still learning it.
My main “point of improvement” would be the deployment process. Having done a few things in PHP in which you basically copy files, and set a config in place for the database, the deployment process in rails got me really frustrated to the point to almost abandoning the project the first time.
I do know there things easier that other when it comes to changes. It is just my feedback as a beginner.
Yes please. After many years of using Rails and having deployed them I’m still not sure what’s the best approach (now I just use Capistrano to push code to a single VPS, plus taking advantage of Heroku for other apps)
I think another “problem” comparing it to php is that it also depends on where it’s hosted. I think that php is such used that any shared hosting supports it. While rails requires more a “manual” approach (through bare, vps, paas). I haven’t deployed to any shared hosting for year, but last time I remember some were using passenger to make it easy and fast like dropping files in a folder (but I think it was still requiring some extra work for migrations and configs)
Just throwing it out there, if a section with how to deploy on bare/docker/paas is added, what do you think about having a section for shared hosting as well (screened out to only suggest the best options), as they’d be useful for beginners. And there could even be some kind of partnership (affiliation?) where those hosting companies would generate something from the lead, which is then donated to ruby central (/something else)
Yeah this totally depends on where it’s hosted. If you’re going to a bare box you’d need something like Capistrano (which is a very heavy solution), but if you’re going to Heroku it’s much simpler, and if you’re using ECS/Kubernetes it’s all in the Dockerfile. I think different companies will have different pain points here.
I’m going to give a shoutout here to Hatchbox.io. After years of setting up DigitalOcean VPSes by hand to run Rails apps, I gave Hatchbox a try (which is largely a friendly UI to automate installing Rails apps on VPSes from cloud providers like DigitalOcean), and it’s like the sky parted and the angels sang. I’m planning to (slowly) migrate all of my various Rails infrastructure over to Hatchbox in the coming months. Also a nice bonus that it’s run by Chris Oliver of GoRails fame.
My understanding of hatchbox is that it’s a one-person operation and is a subscription service. What happens if this one person goes out of business/becomes unavailable to maintain the service? Will deployments stop working?
If you go the mile with self-hosted docker anyway, I want to point your attention to http://dokku.viewdocs.io/dokku/ . They use the heroku buildpacks by default and for small/medium-sized production use its totally fine with the defaults. Besides, if you need nginx and stuff optimization you can do that. You can also go the all Dockerfile-route with it if you want.
Then, deployment becomes (like (it used to be?) in heroku) a git push mydokkuname, automatically fetching ssl certs, doing the migrations, assets compilation, custom health checks, even creating subdomains if you want etc.pp. Sure enough, initial setup takes a bit of time, but afterwards you will not want to miss it. It kind of made deployment fun for me as ruby/rails made programming fun for me.
While my book is making me good money, I have always felt that Rails life would be better if we did not need it.
Personally, I host my applications on a VPS because I like to have everything under control (being Linux engineer for almost 15 years certainly helps with that) but I admit that even though the process outlined in my book works like a charm once set up, it took a tremendous amount of research, trial & error and time to get all that knowledge together (and lots of developers simply have no interest in doing operations). It’s getting worse with every major Rails release (I just finished to update my process to serve Rails 6 with Ruby 2.7 yesterday).
Operations — deployment is particular — has always been a little neglected in the Rails world which is a shame because serving Ruby applications reliably in production obviously takes more than just FTPing a bunch of files.
With recent additions (like ActiveJob) establishing a common default for basic tasks, I think it would be great if developers would be a little less on their own when trying to deploy their apps. This would neither hurt Heroku, Hatchbox.io and friends nor those who want to build their infrastructure from the ground up.
I have been trying out a few things in the last months but there is nothing to show yet. There are just too many moving parts for a one-size-fits-all approach (different databases, different application servers, VPS, containers, …).
I think most newcomers would be happy to find at least some hints in the Rails Guides.
I know that Noel Rappin has been using the knowledge he’s gotten from writing a book about modern Rails front-end to contribute a bit more to the Rails front-end documentation. Would you feel comfortable doing the same with some of your hard-earned knowledge about Rails deployment and operation?
I switched over to it a couple of years ago and I think it does a fantastic job.
I wrote a bit about why I like it if anyone is interested:
As @andreimoment mentions, it is a one-man band. If it goes out of business, then automatic deployments will stop working. You’ll still have your server up and running, and you’ll still have root access. You could switch over to capistrano or similar to manage updates yourself. The servers are still yours - so at least they won’t be at risk.
I’ve been using Heroku for all these years primarily because I could just do git push heroku master and forget about devops. But lately, I’ve been trying to figure out how it all works under the hood.
I have consolidated all my learning in the form of an Ansible playbook that takes care of all the grunt work involved in deploying Rails apps. However, getting everything to work took way too much time and effort than I had imagined.
The other suggestions mentioned in this thread (e.g: Hatchbox and Dokku) are good, but I feel that we need something like ActiveJob but for deployment.
This is a great point, thanks for bringing it up, Bharani. I know of big consultancies that choose to not manage the devops side of things, and just use Heroku, even for big commercial projects. They’ve no doubt done the math and figured that the cost of hiring someone knowledgeable just would not pay off. For smaller shops, one person shops, this isn’t really an option anyway.
It would be really nice if Rails had some best practices for deployment baked in, or at least documented in a contributable manner. One of the big selling points of Rails is “just add your idea”. And that goes a long way throughout the development cycle, with sensible defaults and a good mix of tools to do almost anything you want in a Web app. But then (eventually) you want to deploy, and that’s where the learning cliff is encountered to be sure.
One problem with this “just let Rails do/document it” is the literal Babel of different hosting options out there. One of the things that made/makes PHP so easy for beginners is the sheer ubiquity of hosting providers, since the barrier to entry is a2enmod php (from their point of view). Most Linux distros come with versions of Apache compiled for PHP/MySQL out of the box. Even Digital Ocean, which has a nice “Rails Hosting” button on their configuration panel, doesn’t have a way to ensure that everything is quite that newbie-proof for the first-time hoster.
I don’t have a solution to this, I agree that it’s worth doing, and I hope that others on this list have some idea of how we could tackle this.
I’m planning to (slowly) migrate all of my various Rails infrastructure over to Hatchbox in the coming months. Also a nice bonus that it’s run by Chris Oliver of GoRails fame.