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

171–180 of 228 posts

Re: Rails on Docker

#171

Post by nickjj »

If anyone is looking for a complete guide I put together this last month: https://nickjanetakis.com/blog/a-guide-for-running-rails-in-...

It includes running Rails and also Sidekiq, Postgres, Redis, Action Cable and ties in esbuild and Tailwind too. It's all set up to use Hotwire as well. It's managed by Docker Compose. The post also includes a ~1h hour ad-free YouTube video. The example app is open source at https://github.com/nickjj/docker-rails-example and it's optimized for both development and production. No strings attached. The example app has been maintained and deployed a bunch over the years.

Re: Rails on Docker

#172

Post by maaarghk »

brundolf wrote: post #138
kugelblitz wrote: post #131

Earlier quoted context omitted.

How do you mean? If the new project without any tests with a PHP 7.2 and MySQL installation and I need to upgrade it to PHP 8.2, I first need to write tests and I can't use PHP 8.2 features until I've upgraded. Composer is the dependency manager, but I still need PHP to run the app later on. And a PHP 7.2 project might behave differently when running on PHP 7.2 or PHP 8.2. And sometimes PHP is just one part of the eq…

> and I can't use PHP 8.2 features until I've upgraded Yeah- so in Rust, the compiler/tooling never introduces breaking changes, as (I think) a rule. For any collection of Rust projects written at different times, you can always upgrade to the very latest version of the compiler and it will compile all of them. The way they handle (the very rare) breaking changes to the language itself is really clever: instead of a…

I'm not gonna lie, I didn't read all that, but the node example alone proves you either didn't read the guy you replied to or haven't been coding long enough to grok the problem.

What if you want to start a new project using the latest postgres version because postgres has a new feature that will be handy, but you already maintain another project that uses a postgres feature or relies on behaviour that was removed/changed in the latest version? You're going to set up a whole new VM on the internet to be a staging environment and instead of setting up a testing and deployment pipeline you're going to just FTP / remote-ssh into it and change live code?

you define an apps entire chain of dependencies including external services in a compose file / set of kube manifests / terraform config for ecs. Then in the container definition itself you lock down things like C library and distro versions: maybe you use specially patched imagemagick on one project or a pdf generator on another, and fontconfig defaults were updated and it changed how aliasing works between distro releases and now your fonts are all fugly in generated exports... stick all those definitions in a Dockerfile and deploy onto any Linux distro / kernel and it'll look identical to it does on local

nevermind this, check out this thread to destroy your illusion that simply having node installed locally will make your next project super future proof https://github.com/webpack/webpack/issues/14532 and note that some of the packages referencing this old issue in open new bug reports are very popular!

if you respond please do not open with "yeah but rust", I can still compile Fortran code too

Re: Rails on Docker

#173

Post by michaelsalim »

hakunin wrote: post #109
jrochkind1 wrote: post #96

Earlier quoted context omitted.

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

If you're basing on a lang-specific container like ruby, then it's the version of that container in the FROM line. Notice how ruby images come in various versions of OS ( https://hub.docker.com/_/ruby ). You can specify that as part of the FROM string. However, they also let you drop the OS part, and only specify ruby version. This will usually default to an image with the latest OS provided by that docker repo. Noth…

This right here. Most of the time you just need to rebuild your image. If the project is being actively developed and built, nothing to worry about. (Unless you pin to a very specific OS version of course).

If it's not, you just need to trigger a build every so often. Maybe this could be a feature PaaS offers in the future.

Re: Rails on Docker

#174

Post by Groxx »

cpuguy83 wrote: post #134
Groxx wrote: post #100

Earlier quoted context omitted.

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.

You can! It's experimental but https://github.com/docker/buildx/pull/1168 Tracking for this: https://github.com/docker/buildx/issues/1104

excellent, thanks!

this has been a serious pain in my side for a while, both for my own debugging and for telling people I try to help "you're gonna have to start over and do X or this will take hours longer".

Re: Rails on Docker

#175

Post by valzam »

treis wrote: post #81
kitsunesoba wrote: post #56

Earlier quoted context omitted.

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…

It's, more or less, practically impossible to be OS agnostic for a backend with any sort of complexity. You can choose layers that try to abstract the OS layer away but sooner or later you're going to run into part of the abstraction that leaks. That plus the specialty nature of Windows/Mac hosting means your backend is gonna run on Linux. It made sense at one point to use Macs but these days pretty much everything i…

The problem of course being that x86 linux on laptops is still and might always be terrible. Using an ARM Mac to develop your backend services is not ideal but probably still a better user experience than the 0.01% where a modern language does something vastly different on your local machine than in production (which is btw also very often ARM these days, at least on AWS).

I've used Ubuntu, WSL2 and currently a M1 mac and if I need to be mobile AT ALL with the machine I chose a Mac any day. For a desktop computer Ubuntu works great though

Re: Rails on Docker

#176

Post by DanHulton »

gitgud wrote: post #105
JimDabell wrote: post #57

Earlier quoted context omitted.

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

Nice syntax, but I like the caching that comes with creating each layer. If you want to reduce layer/image size, then I think [1] "multi-stage builds" is a good option [1] https://docs.docker.com/build/building/multi-stage/

I mean, you can do both. Or, technically with that link you mentioned, all three.

You can use HEREDOCS to combo together commands that make sense in a layer, ensure your layers are ordered such that the more-frequently changing ones are further on in your Dockerfile when possible (this will also speed up your builds, ensuring as many caches as possible are more likely to be valid), and use mutli-stage builds on top of that to really pare it down to the bare necessities.

Re: Rails on Docker

#177

Post by cvccvroomvroom »

Thanks but I already have my own containers and infrastructure for dev and prod Rails.

It's fine for people who are just starting out or want a repeatable environment.

Also, if you want stability and fewer headaches long-term:

- use a RHEL-derived kernel and customize the userland (container or host) quay.io has a good cent 9 stream. Ubuntu isn't used at significant scale for multiple reasons, and migrating over later is a pain.

- consider podman over docker

- use packaging (nix, habitat, or rpms) rather than make install (and use site-wide sccache)

- container management (k8s or nomad)

- configuration management (chef) because you don't always have the luxury of 12factor ephemeral instances based on dockerfiles and need to make changes immediately without throwing away a database cluster or zookeeper ensemble

- Shard configuration and app changes, with a rollback capability

- Have CI/CD for infrastructure that runs before landing

- Monitoring and alerting

- Don't commit directly to production except for emergencies. Require a code review signoff by another engineer. And be able to back out changes.

- Have good, tested backups that aren't replication

- Don't sweat the small stuff, but get the big stuff right that doesn't compound tech debt

Re: Rails on Docker

#178

Post by cvccvroomvroom »

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

Every command in a dockerfile creates a layer, and most Dockerfile builders cache each if that line hasn't changed. Dynamic callouts to run updates or check things on the web won't rerun.

Re: Rails on Docker

#179

Post by cvccvroomvroom »

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

Self-hosting and self-hoisting here. Whenever docker gives me grief, I use podman.

Re: Rails on Docker

#180

Post by cvccvroomvroom »

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.

Yeap. Various docker images are built with pkg mgmt file install exclusions and rm -rf.

It's good to have a slim script but also to have an unslim when you need manpages or locales.

Post reply on HN