Add default Dockerfiles#46762
Conversation
Let's make it easier for someone to go from Hello World locally to production.
|
The CI lint failure is unrelated to this patch, and has already been fixed on main via #46763. |
* main: Remind of credentials diff enrollment on edit [docs] Code samples for postgres configs Silence credentials generator in app generator Let `initialize` not create an Array as its return value Reduce Array allocations in MimeNegotiation Trim trailing whitespace from *.md files Avoid unnecessary replacements when the node doesn't change Allow assets:precompile to be run in a production build step without passing in RAILS_MASTER_KEY (#46760)
Docker quirks!
Follow-up to rails#46762. Docker-related files are intended for production deployment, not development. Therefore, this commit prevents those files from being generated for plugin dummy apps.
| @@ -0,0 +1,50 @@ | |||
| # Make sure it matches the Ruby version in .ruby-version and Gemfile | |||
There was a problem hiding this comment.
It could be useful to mention --build-arg to help with debugging out-of-sync Ruby versions.
|
|
||
| # Entrypoint prepares database and starts app on 0.0.0.0:3000 by default, | ||
| # but can also take a rails command, like "console" or "runner" to start instead. | ||
| ENTRYPOINT ["/rails/bin/docker-entrypoint"] |
There was a problem hiding this comment.
Yes. Mapping cleanly for non-root use-cases is an exercise in frustration especially for Linux where it needs to map to a host UID / GID in /etc/hosts.
If not running as root is important, run it via Podman.
If this is intended for deployment, most hosting providers aren't giving you root level to the full server. Just within the container you're given so I don't think it's a huge deal.
There was a problem hiding this comment.
There are plenty of risks with rails running as root within a container, even is a syscap constrained environment (like the cloud). If a container is compromised, the attacker now has the ability to install packages, read and write arbitrary files within the container.
There was a problem hiding this comment.
@ianks thanks. This makes sense. I generally run all my docker containers as non-root users just because it's generally good practice, didn't realize there was real security concerns with it on hosting providers considering I never see dockerfiles from them as non-root users. Apologies for brushing this off and thank you for taking the time.
| ARG NODE_MAJOR_VERSION=19 | ||
| RUN curl -sL https://deb.nodesource.com/setup_$NODE_MAJOR_VERSION.x | bash - | ||
| RUN apt-get update -qq && \ | ||
| apt-get install -y build-essential libvips nodejs && \ |
There was a problem hiding this comment.
These should be removed after bundle installs and asset pre-compilation to reduce container bloat
|
@dhh what about using alpine based image for production? |
|
@dixpac while Alpine is great for size, the glaring issue is that it uses musl-libc instead of glibc which could be a big stumbling block for new users. |
|
Compatibility is more important than size for the default image. You can always tailor the generated file as you see fit. |
|
Is there any command to add the default Dockerfile to an existing Rails app? |
|
@collimarco run |
11 participants
Add Docker files by default to new apps: Dockerfile, .dockerignore, bin/docker-entrypoint. These files can be skipped with
--skip-docker. They're intended as a starting point for a production deploy of the application. Not intended for development (see Docked Rails for that).Example:
You can also start a console or a runner from this image:
To create a multi-platform image on Apple Silicon to deploy on AMD or Intel and push to Docker Hub for user/app: