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

51–60 of 228 posts

Re: Rails on Docker

#51

Post by jayd16 »

jrochkind1 wrote: post #30
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…

As someone who has not yet adopted to Docker, even though that seems to be what is done on contemporary best-in-class PaaS.... I don't totally understand the maintenance story. On heroku with buildpacks, I don't need to worry about OS-level security patches, patches to anything that was included in the base stack provided by the PaaS, they are responsible for. Which I consider part of the value proposition. When I sw…

I think the idea is you have a CI/CD pipeline that will periodically rebuild and redeploy with the latest base images along with your code updates and such.

Re: Rails on Docker

#53

Post by d3nj4l »

vidarh wrote: post #42
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"…

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.

Re: Rails on Docker

#54

Post by wefarrell »

I do miss the pre-docker days of using capistrano to deploy rails projects. Most deploys would take less than two minutes in the CI server and most of that was tests. The deploys were hot and requests that happened during the deploy weren't interrupted. Now with Docker I'm seeing most deploys take around ten minutes.

The downside of capistrano was that you'd be responsible for patching dependencies outside of the Gemfile and there would be occasional inconsistencies between environments.

Re: Rails on Docker

#55

Post by mfkp »

ksajadi wrote: post #37
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 feel your pain and risking a shameless plug, we built a company to solve this problem as it was the only thing we really didn't like about Rails. Checkout Cloud 66!

I've been using Cloud66 since 2015 for my rails deployments, makes my life much easier!

Re: Rails on Docker

#56

Post by kitsunesoba »

jchw wrote: post #41
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…

> the extra memory usage on macOS It's worth noting that the Docker experience is very different across platforms. If you just run Docker on Linux, it's basically no different than just running any other binary on the machine. On macOS and Windows, you have the overhead of a VM and its RAM to contend with at minimum , but in many cases you also have to deal with sending files over the wire or worse, mounting filesyst…

I don't do backend work professionally so my opinion probably isn't worth much, but the way Docker is so tightly tied to Linux makes me hesitant to use it for personal projects. Linux is great and all but I really don't like the idea of so explicitly marrying my backend to any particular platform unless I really have to. I think in the long run we'd be better served figuring out ways to make platform irrelevant than shipping around Linux VMs that only really work well on Linux hosts.

Re: Rails on Docker

#57

Post by JimDabell »

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

If all you want to do is run a series of commands while only creating a single layer, heredocs are probably the simplest / most readable approach:

https://www.docker.com/blog/introduction-to-heredocs-in-dock...

Re: Rails on Docker

#58

Post by regularfry »

gls2ro wrote: post #48
iamflimflam1 wrote: post #47

What kills rails for me at the moment is the time it takes to start up. I'd love to be able to use on top of things like cloud run where resources ramp down to zero when there are no requests, but the startup time makes this very difficult.

I dont think Rails is fit for this. It is a full app so I think by design it does not fit into Cloud Run architecture of cloud functions. May I suggest you take a look at Roda or Hanami?

While I've not tried it personally, Django can be run like this. It being a "full app" doesn't preclude it from having a fast enough startup to allow for cloud function deployment.

Re: Rails on Docker

#59

Post by 5e92cb50239222b »

wefarrell wrote: post #54

I do miss the pre-docker days of using capistrano to deploy rails projects. Most deploys would take less than two minutes in the CI server and most of that was tests. The deploys were hot and requests that happened during the deploy weren't interrupted. Now with Docker I'm seeing most deploys take around ten minutes. The downside of capistrano was that you'd be responsible for patching dependencies outside of the Gem…

Why are using Docker then? I have little experience with Ruby, but for PHP projects we're still using ye olde way. Deploys are hot and do not interrupt requests, just as you described (it pretty much comes down to running `composer install && rsync` in CI — there are more complicated solutions like capistrano, which I've also used, but they don't seem to provide enough features to warrant increased complexity).

Re: Rails on Docker

#60

Post by freedomben »

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

Yeah this is a very widely misunderstood or unknown thing about docker files. After the nth time explaining it to somebody, I finally threw it into a short video with demo to explain how it worked: https://youtu.be/RP-z4dqRTZA
Post reply on HN