161–170 of 228 posts
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.
Yes, usually you still serve your asset (images,...) directory through nginx or something similar, though.
Earlier quoted context omitted.
Open a PR! This will fix the problem if its a bug/oversight or if its intended to be that way, force somebody to comment on it for a future person who is puzzled by this choice.
It's intended. Yes serving static files from Ruby is slower than from nginx or whatever, but you'd need to embed nginx in the image and run both processes etc. The assumption here is that there is a caching proxy in front of the container, so Rails will only serve each assets once, so performance isn't critical.
> RAILS_SERVE_STATIC_FILES="true"
> RAILS_SERVE_STATIC_FILES - This instructs Rails to not serve static files
That is not what it does when you put `="true"`, nope.
In fact both, settings are common. On heroku you typically use `RAILS_SERVE_STATIC_FILES="true"` but put a CDN in front. But other people do false and have eg nginx serving them. If this is what fly.io means you to do... where is the nginx, not mentioned in the tutorial?
Whichever they intend to do, their code does not match their narrative of what it does.
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. Thi…
If you could share your configurations that would be great! (see email in my profile). I used Capistrano for many, many, years but haven't kept up with it in quite a while. I've had to tackle HIPAA deployments in k8s and it's quite the ordeal for a small team. I miss the days of "cap deploy".
Earlier quoted context omitted.
Yeah the fly.io stuff is great, beautiful artwork too, top class job. Re: security updates. It's not handled. There are companies that will scan your infrastructure to figure out what's in your containers and find out of date OS base images. One thing I'm currently experimenting with is a product for people who would like an experience slightly closer to traditional Linux. The gist is, e.g. include "#!gradle -q print…
> It's not handled. So... what do actual real people do in practice? I am very confused what people are actually doing here. LOTS of people seem to have moved to this kind of docker-based deploy for PaaS. They can't all just be... ignoring security patches? I am very confused that nobody else seems to think the "handle patches story" is a big barrier to moving from heroku-style to docker-style... that everyone else j…
But how does this work when talking to dev databases on my machine?
Dockerized applications can still reach services on the localhost, but you may want to take a look at docker compose so you get your application and backing systems in one place. It makes your local development environment incredibly resilient.
Earlier quoted context omitted.
Same boat here. I'm doubtful that we could take on the additional maintenance work for less than the Heroku premium we pay. I wouldn't be surprised if I'm wrong and newer tools bridge the gap for a lower price and/or time investment, but I also wouldn't be surprised if I'm right and many places using Docker could save time/money offloading the maintenance to something more like a managed PaaS.
Agreed. I actually have not too much problem with heroku pricing (I could complain about some areas, but it's working for us) -- I'm just worried that heroku seems to be slowly disintegrating through lack of investment, so am worried that there seem to be no other realistic options for that level of service! There don't seem to be other reliable options for managed PaaS that takes care of maintenance in the same way.
There's also netlify, vercel and similar sites but I think they're mainly geared toward all-javascript apps.
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 technic…
One problem you're likely to run into is that systems using the same packaging lineage cut the same dependency up in different ways. The "right name" for a dependency can change between Ubuntu and Debian, between different releases of Ubuntu, and different architectures. It very quickly gets out of hand for any interesting set of dependencies. Now it might be that there's enough stability in the repositories these da…
Earlier quoted context omitted.
It's intended. Yes serving static files from Ruby is slower than from nginx or whatever, but you'd need to embed nginx in the image and run both processes etc. The assumption here is that there is a caching proxy in front of the container, so Rails will only serve each assets once, so performance isn't critical.
I am not sure which they intended, but the problem is that the comment doesn't match the code: > RAILS_SERVE_STATIC_FILES="true" > RAILS_SERVE_STATIC_FILES - This instructs Rails to not serve static files That is not what it does when you put `="true"`, nope. In fact both, settings are common. On heroku you typically use `RAILS_SERVE_STATIC_FILES="true"` but put a CDN in front. But other people do false and have eg n…
That comment isn't in the Rails dockerfile, it was added by the OP.
https://github.com/rails/rails/blob/4f3af4a67f227ed7998fed57...
Earlier quoted context omitted.
You did this on the same machine, right? In a CI setting with no shared cache you need to rely on an OCI cache. The last build image is cached with the inline cache, but prior images are not
I never got around to implementing it but I wonder how this plays with cross-runner caches in e.g. Gitlab, where the cache goes to S3; there's a cost to pulling the cache, so it'll never be as fast as same-machine, but should be way faster for most builds, right?