31–40 of 228 posts
> RAILS_SERVE_STATIC_FILES - This instructs Rails to not serve static files. ...but... it's set to True....
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.
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.
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 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`.
> RAILS_SERVE_STATIC_FILES - This instructs Rails to not serve static files. ...but... it's set to True....
Standard heroku Rails deploy instructions are to turn on `RAILS_SERVE_STATIC_FILES` but also to put a CDN in front of it.
My guess is this is what fly.io is meaning to recommend too. But... yeah, they oughta fix this! A flaw in an otherwise very well-written and well-edited article, how'd it slip through copy editing?
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.
Checkout Cloud 66!
Earlier quoted context omitted.
in case anyone doesn't know what that means, its basically this kind of dockerfile FROM the_source_image as builder RUN build.sh FROM the_source_image COPY --from=builder /app/artifacts /app/ CMD .... i'm not sure if you can really call it the new best practice though, its been the default for ... a very long time at this point.
Typically I wind up using a different source image for the builder that ideally has (most of) the toolchain bits needed, but the same runtime base as the final image. (For Go, go:alpine and alpine work well. I'm aware alpine/musl is not technically supported by Go, but I have yet to hit issues in prod with it, so I guess I'll keep taking that gamble.)
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.
- 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.