Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails on Docker

fly.io

Post reply on HN
Print view View original

91–100 of 228 posts

Re: Rails on Docker

#91

Post by samruby »

Too wrote: post #83
jchw wrote: post #2

> 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"…

The new best practice is to use the RUN --mount cache options. Making the removal of intermediate files unnecessary and speeds up the builds too. Surprised to see so few mentions of it.

At the moment Rails is focused on simplicity/readability. I've got a gem that I'm proposing (and DHH is evaluating) that adds caching as an option: https://github.com/rubys/dockerfile-rails#overview

Re: Rails on Docker

#92

Post by skrtskrt »

kitsunesoba wrote: post #71
brundolf wrote: post #65

Earlier quoted context omitted.

I don't think Linux is going away as the main server OS anytime soon, if ever. So that just leaves local dev To that end- I prefer to just stick with modern languages whose first-party tooling makes them not really have to care what OS they're building/running on. That way you can work with the code and run it directly pretty much anywhere, and then if you reserve Dockerfiles for deployment (like in the OP), it'll al…

Yeah I'm not too worried about what's on the deployment end, but rather the dev environment. I don't want to spend any time wrestling Docker to get it to function smoothly on non-Linux operating systems. Agree that it's a strong argument for using newer languages with good tooling and dependency management.

the dev workflow usage of docker is less about developing your own app locally and more about being able to mindlessly spin up dependencies - a seeded/sample copy of your prod database for testing, a Consul instance, the latest version of another team's app, etc.

You can just bind the dependencies that are running in Docker to local ports and run your app locally against them without having to docker build the app you're actually working on.

Re: Rails on Docker

#93

Post by brundolf »

jrochkind1 wrote: post #82
mike_hearn wrote: post #68

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…

It seems not that hard to just manually bump your version periodically, right? I get that it's not as nice as having it taken care of for you, but it's not like you're having to manage a whole system by hand

Re: Rails on Docker

#94

Post by Deinumite »

alberth wrote: post #21

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.

I think this is one of the things that Java really solved even though the actual implementation is a bit weird.

Being able to generate a war or jar as a released binary is something that would be cool to see in the ruby world.

Re: Rails on Docker

#95

Post by bdcravens »

d3nj4l wrote: post #53
vidarh wrote: post #42

Earlier quoted context omitted.

An terbative to removing files or go through contortions to stuff things in a single layer is to use a builder image and copy the generated artefacts into a clean image: FROM foo AS builder .. build steps FROM foo COPY --from=builder generated-file target (I hope I got that right; on a phone and been a while since I did this from scratch, but you get the overall point)

This isn’t really useful for frameworks like rails, since there’s nothing to “compile” there. Most rails docker images will just include the runtime and a few C dependencies, which you need to run the app.

Pulling down gems is a bit of a compilation, which could benefit, unless you're already installing gems into a volume you include in the Docker container via docker compose etc. Additionally, what it does compile can be fairly slow (like nokogiri).

Re: Rails on Docker

#96

Post by jrochkind1 »

brundolf wrote: post #93
jrochkind1 wrote: post #82

Earlier quoted context omitted.

> 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…

It seems not that hard to just manually bump your version periodically, right? I get that it's not as nice as having it taken care of for you, but it's not like you're having to manage a whole system by hand

Assume I've never used Docker before, can you tell me what "manually bump your version periodically" means with regard to this question? Can anyone give me concrete instructions for what this looks like in a specific context? Like, say the first Dockerfile suggested in OP?

The Dockerfile has in it:

> ARG RUBY_VERSION=3.2.0

> FROM ruby:$RUBY_VERSION

Which it says gets us "gets us a Linux distribution running Ruby 3.2." (Ubuntu?). The version of that "linux distribution" isn't mentioned in the Dockerfile. How do I "bump" it if there is a security patch effecting it?

Then it has:

> RUN apt-get update -qq && apt-get install -y build-essential libvips && \ ...

Then I just run `fly launch` to launch that Dockerfile on fly.io. How do I "bump" the versions of those apt-get dependencies should they need them?

Re: Rails on Docker

#97

Post by bploetz »

freedomben wrote: post #78
bploetz wrote: post #32

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?

Alpine has some razor edges in it. I would never default to it. Always test your app thoroughly. musl doesn't implement everything that glibc does and some of the differences can cause big problems. This is not purely theoretical. I once spent a week deugging a database corruption issue that happened because of a difference in musl's UTF-8 handling. Use Alpine liberally for local images if you like, but don't use it…

"Use Alpine liberally for local images if you like, but don't use it for production."

We take the exact opposite approach: default to Alpine based images, only use another base OS if Alpine doesn't work for some reason. The majority of our underlying code base isn't C-based, so maybe that's why Alpine has been successful for us, but as always, everyone's situation is different and YMMV.

Re: Rails on Docker

#98

Post by ravedave5 »

0x457 wrote: post #63
alberth wrote: post #21

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.

Rails is a huge framework. I remember using capistrano to deploy it on many servers, and that was much harder than with containers today. 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…

I still have battlescars from capistrano. What a pain. So much easier with docker.

Re: Rails on Docker

#99

Post by vidarh »

orf wrote: post #86
vidarh wrote: post #42

Earlier quoted context omitted.

An terbative to removing files or go through contortions to stuff things in a single layer is to use a builder image and copy the generated artefacts into a clean image: FROM foo AS builder .. build steps FROM foo COPY --from=builder generated-file target (I hope I got that right; on a phone and been a while since I did this from scratch, but you get the overall point)

Unfortunately this messes with caching and causes the builder step to always rebuild if you’re using the default inline cache, until registries start supporting cache manifests.

How so? I just tested a build, and it used the cache for every layer including the builder layers.

Re: Rails on Docker

#100

Post by Groxx »

jbott wrote: post #84
tomca32 wrote: post #61

Earlier quoted context omitted.

Why didn't I ever think of this. This is great and really makes things way simpler. Thanks!

Unfortunately this syntax is not generally supported yet - it's only supported with the buildkit backend and only landed in the 1.3 "labs" release. It was moved to stable in early 2022 (see https://github.com/moby/buildkit/issues/2574 ), so that seems to be better, but I think may still require a syntax directive to enable. Many other dockerfile build tools still don't support it, e.g. buildah (see https://github.com…

And AFAIK buildkit is still a real pain to troubleshoot, as you can't use intermediate stages :/

You can put stuff in a script file and just run that script too.

Post reply on HN