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

141–150 of 228 posts

Re: Rails on Docker

#141

Post by viraptor »

berkes wrote: post #127
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 ar…

> Finally tamed the timing of releasing that db migration without downtime? Here's sidekiq, requiring you to synchronize restarts of several servers

To be fair, this was already an issue whenever you have more than one instance of anything. Whether it's an extra sidekiq or two web servers or anything else, you have a choice of: stop everything and migrate, or split the migration into prepare, update code, finalise migration.

Re: Rails on Docker

#142

Post by viraptor »

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…

This experience is mostly about how you see docker used, not any specific property of it. Both Capistrano and Docker can be used for deploys with or without interruptions. Both can be immediate or take minutes. The tool itself won't save you from bad usage.

Re: Rails on Docker

#143

Post by cutler »

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…

Honestly, to an outsider Docker sure sounds like a world of pain.

Re: Rails on Docker

#144

Post by markhesketh »

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…

I do the same thing and it works well.

For your issue could you handle bringing up your docker-compose 'manually' in bin/dev? Maybe conditionally by checking if the image exists locally with `docker images`. Then tear it down and run foreman after it completes?

Re: Rails on Docker

#145

Post by vxNsr »

cutler wrote: post #143
jchw wrote: post #41

Earlier quoted context omitted.

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

Honestly, to an outsider Docker sure sounds like a world of pain.

To a developer it probably is, as a user, it’s much easier to install self hosted server apps with minimal effort. Especially because the Docker file usually already has the sane defaults set while the binary requires more manual config.

Re: Rails on Docker

#146

Post by laneystroup »

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.

This rules out almost all docker based-PaaS (including Fly.io, Render.com, AWS App Runner, and Digital Ocean), as these run your containers on general Docker hosts. In fact, the only PaaS provider that I can find advertising PCI compliance is Heroku, which now charges +$1800/month plus for Heroku Private to achieve it.

I would love to share my configuration with anyone that needs it.

Re: Rails on Docker

#147

Post by [deleted] »

laneystroup wrote: post #146

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…

[deleted]

Re: Rails on Docker

#148

Post by amarshall »

laneystroup wrote: post #146

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…

Did you read the OP?

> Fly.io doesn't actually run Docker in production—rather it uses a Dockerfile to create a Docker image, also known as an OCI image, that it runs as a Firecracker VM

Re: Rails on Docker

#149

Post by atmosx »

laneystroup wrote: post #146

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…

Fly.io will convert your docker image to a firecracker[^1], a microVM engine based on KVM.

[^1]: https://firecracker-microvm.github.io/

Re: Rails on Docker

#150

Post by throwanem »

vxNsr wrote: post #145
cutler wrote: post #143

Earlier quoted context omitted.

Honestly, to an outsider Docker sure sounds like a world of pain.

To a developer it probably is, as a user, it’s much easier to install self hosted server apps with minimal effort. Especially because the Docker file usually already has the sane defaults set while the binary requires more manual config.

It's not too bad as a developer, either, especially when building something that needs to integrate with dependencies that aren't just libraries.

It may be less than ideally efficient in processor time to have everything I work on that uses Postgres talk to its own Postgres instance running in its own container, but it'd be a lot more inefficient in my time to install and administer a pet Postgres instance on each of my development machines - especially since whatever I'm building will ultimately run in Docker or k8s anyway, so it's not as if handcrafting all my devenvs 2003-style is going to save me any effort in the end, anyway.

I'll close by saying here what I always say in these kinds of discussions: I've known lots of devs, myself included, who have felt and expressed some trepidation over learning how to work comfortably with containers. The next I meet who expresses regret over having done so will be the first.

Post reply on HN