How on earth did Rails not have an official Dockerfile until now? Have people been deploying like it's 2010?
Rails on Docker
211–220 of 228 posts
Re: Rails on Docker
#212Earlier quoted context omitted.
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/
> Nice syntax Is it though? From the post: RUN apt-get update apt-get upgrade -y apt-get install -y ... EOF It may be due to my ninja level abilities to dodge learning more advanced shell mastery for decades, but to me it looks haphazard and error prone. Are the line breaks semantic, or is it all a multiline string? Is EOF a special end-of-file token, or a variable, if so what’s it’s type? Where is it documented? Is…
I know those questions are rhetorical, but to answer them anyway:
> > Nice syntax
> Is it though?
Before the heredoc syntax was added, the usual approach was to use a backslash at the end of each line, creating a line continuation. This has several issues: The backslash swallows the newline, so one must also insert a semicolon* to mark the end of each command. Forgetting the semicolon leads to weird errors. Also, while Docker supports line continuations interspersed with comments, sh doesn't, so if such a command contains comments it can't be copied into sh.
The new heredoc syntax doesn't have any of these issues. I think it is infinitely better :)
(There is also JSON-style syntax, but it requires all backslashes to be doubled, and is less popular.)
*In practice "&&" is normally used rather than ";" in order to stop the build if any command fails (otherwise sh only propagates the exit status of the last command). This actually leads to a small footgun with the heredoc syntax: it allows the programmer to use just a newline, which is equivalent to a semicolon and means the exit status will be ignored for all but the last command. The programmer must remember to insert "&&" after each command, or use `set -e` at the start of the RUN command, or use `SHELL ["/bin/sh", "-e", "-c"]` at the top of the Dockerfile. But this footgun is due to sh's error handling quirks, not the heredoc syntax itself.
> Are the line breaks semantic, or is it all a multiline string?
The line breaks are preserved ("what you see is what you get").
> Is EOF a special end-of-file token
You can choose which token to use (EOF is a common convention, but any token can be used). The text right after the "This allows you to easily create a heredoc containing other heredocs. Can you think of any other quoting syntax that allows that? (Lisp's quote form comes to mind.)
> Where is it documented?
The introduction blog post has already been linked. The reference documentation (https://docs.docker.com/engine/reference/builder/, https://github.com/moby/buildkit/blob/master/frontend/docker...) explains the syntax using examples. It doesn't have a formal specification; unfortunately this is a wider problem with the Dockerfile syntax (see https://supercontainers.github.io/containers-wg/ideas/docker...). Instead, the reference links to the sh syntax specification (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V...), on which the Dockerfile heredoc syntax is based.
Re: Rails on Docker
#213Earlier quoted context omitted.
Yes, but apt-get clean is still redundant [ed: because the upstream Debian/Ubuntu images automatically runs apt-clean via how dpkg/apt is configured - and your image should inherit this behavior]. Personally I'm not a fan of deleting random files like man pages and documentation - so instead of: RUN apt-get update -qq && \ apt-get install -y build-essential libvips && \ apt-get clean && \ rm -rf /var/lib/apt/lists/*…
Not a fan of violently modifying the system outside of the package manager either. rm -rf isn't configuration management, it's system entropy increasing leaving users scrambling to reinstall the world. If people don't want docs, then distro vendors should package them separately and make them recommended packages.
Indeed. If you want a small image, there's "slim" and "alpine" variants.
Re: Rails on Docker
#214For some more (too many?) in-depth tricks for rails and docker, see also:
"Ruby on Whales: Dockerizing Ruby and Rails development"
https://evilmartians.com/chronicles/ruby-on-whales-docker-fo...
Previously posted to hn - but without any comments.
Re: Rails on Docker
#215This is really cool. Is the Rails server production ready? I was always under the impression you had to run it with Uvicorn or similar, although I haven't been following Rails development recently.
The default Gemfile now bundles Puma in, so yeah it's production ready
Puma is certainly fine as the app server - but normally you'd still have a proxy/load balancer/tls terminator/"ingress server" in front. Something like traefik, nginx, haproxy or caddy.
If (one of the) front-facing servers do regular http caching (a good idea anyway to play nice with rails caching[1])", you can probably "serve" the static assets straight from rails and let your proxy serve them from cache (if you don't have/need a full cdn).
[1] https://guides.rubyonrails.org/caching_with_rails.html#condi...
Re: Rails on Docker
#216> 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...
I like here-docs, but frequently I think just making small shell scripts to be invoked by RUN is better, eg putting apt invocations in something like: buildscripts/install_deps and simply RUN that from the Dockerfile.
Re: Rails on Docker
#217Earlier quoted context omitted.
IIRC, Dokku can only manage 1 server, so it's essentially useless for anything except small side projects that don't need to scale horizontally.
How do you define small side projects? One potent server is enough to serve multiple thousand of requests per second…
Small side project, meaning anything that's fine with occasional downtime.
You should run at least 2 servers for redundancy, regardless of size. You just can't lean on a single server, even if you can squeeze thousands of RPS out of it (big doubt).
It will inevitably fail, and you will have downtime.
Re: Rails on Docker
#218I 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…
The result of a Heroku build pack is also a Docker image. The switching of base layers is a feature of the docker image design, though not normally used by normal docker users.
Re: Rails on Docker
#219Am 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.
We've deployed with Capistrano to Ubuntu hosts for wow... 13 years now? It works super well, but our DevOps folks want to move to a push button approach within GitLab (rather than me typing one easy command, but hey).
I'm super stoked about the included Docker config and all the blog posts it will shortly inspire. Finding best-practices for Docker based deployments has been anything but fun. I'm still not sure how we'll implement the equivalent of `cap production deploy:rollback` and the like with Docker. Not that we use that basically ever, but knowing it's available is great.
Re: Rails on Docker
#220I 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…
On macOS, I've found that the middle of the road of running my own code natively with all the infrastructure components and their config (db, redis, etc) in docker-compose gives me the best combination of performance and ease of setup.