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

121–130 of 228 posts

Re: Rails on Docker

#121

Post by brightball »

ywain wrote: post #66
brightball wrote: post #18

Earlier quoted context omitted.

Docker compose for those services while the language itself runs natively has been the best solution to this problem for me in the past. Docker compose for redis, postgres, elastic, etc. IMO Docker for local dev is most beneficial for python where local installs are so all over the place.

This is exactly what I recently set up for our small team: use Docker Compose to start Postgres and Redis, and run Rails and Sidekiq natively. Everyone is pretty happy with this setup, we no longer have to manage Postgres and Redis via Homebrew and it means we're using the same versions locally and in production. If anyone is curious about the details, I simply reused the existing `bin/dev` script set up by Rails by…

Yea, typically I just do the step manually to start dependencies and then start the rails processes.

Re: Rails on Docker

#123

Post by theptip »

vidarh wrote: post #67
d3nj4l wrote: post #53

Earlier quoted context omitted.

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.

There are however temporary files being downloaded for the apt installation, and while in this case it's simple enough to remove them in one step that's by no means always the case. Depending on which gems you decide to rely on you may e.g. also end up with a full toolchain to build extensions and the like, so knowing the mechanism is worthwhile.

How would you go about copying something you installed from apt in a build container?

Say `apt install build-essential libvips` from the OP, it's not obvious to me what files libvps is adding. I suppose there's probably an incantation for that? What about something that installs a binary? Seems like a pain to chase down everything that's arbitrarily touched by an apt install, am I missing some tooling that would tame that pain?

Re: Rails on Docker

#124

Post by mrkurt »

rendaw wrote: post #101
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"…

Self hoisting here, I put this together to make it easier to generate single (extra) layer docker images without needing a docker daemon, capabilities, chroot, etc: https://github.com/andrewbaxter/dinker Caveat: it doesn't work on Fly.io. They seem to be having some issue with OCI manifests: https://github.com/containers/skopeo/issues/1881 . They're also having issues with new docker versions pushing from CI: https:/…

The newest buildkit shipped a regression. This broke the Docker go client and containerd's pull functionality. It has been a mess: https://community.fly.io/t/deploying-to-fly-via-github-actio...

Re: Rails on Docker

#125

Post by vidarh »

theptip wrote: post #123
vidarh wrote: post #67

Earlier quoted context omitted.

There are however temporary files being downloaded for the apt installation, and while in this case it's simple enough to remove them in one step that's by no means always the case. Depending on which gems you decide to rely on you may e.g. also end up with a full toolchain to build extensions and the like, so knowing the mechanism is worthwhile.

How would you go about copying something you installed from apt in a build container? Say `apt install build-essential libvips` from the OP, it's not obvious to me what files libvps is adding. I suppose there's probably an incantation for that? What about something that installs a binary? Seems like a pain to chase down everything that's arbitrarily touched by an apt install, am I missing some tooling that would tame…

It's a pain, hence for apt as long as it's the same packages, just cleaning is probably fine. But e.g. build-essential is there to handle building extensions pulled in by gems, and that isn't necessary in the actual container if you bring over the files built and/or installed by rubgygems, so the set of packages can be quite different.

Re: Rails on Docker

#126

Post by byroot »

bradgessler wrote: post #31
rcarmo wrote: post #22

> RAILS_SERVE_STATIC_FILES - This instructs Rails to not serve static files. ...but... it's set to True....

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.

Re: Rails on Docker

#127

Post by berkes »

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.

Not just you.

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.

Re: Rails on Docker

#128

Post by kugelblitz »

brundolf wrote: post #4

I used to think I hated Docker, but I think what I actually hate is using Docker locally (building/rebuilding/cache-busting images, spinning containers up and down, the extra memory usage on macOS, etc etc). I don't need all that for development, I just want to run my dang code But I've been really enjoying it as a way of just telling a PaaS "hey here's the compiler/runtime my code needs to run", and then mostly not…

I work a lot on modernizing codebases. Many times it will be codebases without any proper testing, different versions of frameworks and programming languages, etc.

Currently, I'm working in 3 projects at once + my own. Even though it's all PHP, the projects are PHP 8.1 / Symfony 6.2, PHP 8.2 / Symfony 6.2, PHP 8.1 / Laravel 8 and the newest project I joined is PHP 7.4 / Symfony 4. I have to adhere to different standards and different setups; I don't want to switch the language and the yarn or npm versions or the Postgres or MySQL versions and remember each one. Some might use RabbitMQ, another Elasticsearch.

Docker helps me tremendously here.

Additionally, I add a Makefile for each project as well and include at least "make up" (to start the whole app), "make down", "make enter" (to enter the main container I'll be working with), "make test" (usually phpunit) and perhaps "make prepare" (for phpunit, phpstan, php-cs-fixer, database validate) as a final check before adding a new commit.

Locally, I had additional aliases on my shell. "t" for "make test", "up" for "make up".

So now I just have to go to a project folder, write "up" and am usually good to go!

Re: Rails on Docker

#129

Post by yrro »

e12e wrote: post #8
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"…

Note that the explicit "apt-get clean" is probably redundant: https://docs.docker.com/develop/develop-images/dockerfile_be... > Official Debian and Ubuntu images automatically run apt-get clean, so explicit invocation is not required.

'apt-get clean' doesn't clear out /var/lib/apt/lists. It removes cached downloaded debs from /var/cacpt/apt but you'll still have hundreds of MiB of package lists on your system after running it.

Re: Rails on Docker

#130

Post by brundolf »

kugelblitz wrote: post #128
brundolf wrote: post #4

I used to think I hated Docker, but I think what I actually hate is using Docker locally (building/rebuilding/cache-busting images, spinning containers up and down, the extra memory usage on macOS, etc etc). I don't need all that for development, I just want to run my dang code But I've been really enjoying it as a way of just telling a PaaS "hey here's the compiler/runtime my code needs to run", and then mostly not…

I work a lot on modernizing codebases. Many times it will be codebases without any proper testing, different versions of frameworks and programming languages, etc. Currently, I'm working in 3 projects at once + my own. Even though it's all PHP, the projects are PHP 8.1 / Symfony 6.2, PHP 8.2 / Symfony 6.2, PHP 8.1 / Laravel 8 and the newest project I joined is PHP 7.4 / Symfony 4. I have to adhere to different standa…

Sure, but that feels like a band-aid on an existing problem. And sometimes a band-aid is what you need, especially with legacy systems, so I'm not judging that. But I think for a new project, these days, it's a mistake to plan on needing Docker from the outset.

Modern languages with modern tooling can automatically take care of dependency management, running your code cross-platform, etc [0]. And several of them even have an upgrade model where you should never need an older version of the compiler/runtime; you just keep updating to the latest and everything will work. I find that when circumstances allow me to use one of these languages/toolsets, most of the reasons for using Docker just disappear.

[0] Examples include Rust/cargo, Go, Deno, Node (to an extent)

Post reply on HN