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

101–110 of 228 posts

Re: Rails on Docker

#101

Post by rendaw »

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://community.fly.io/t/deploying-to-fly-via-github-actio... ... the timing of this post seems weird.

FWIW the article says

> create a Docker image, also known as an OCI image

I don't think this is quite right. From my investigation, Docker and OCI images are basically content addressed trees, starting with a root manifest that points to other files and their hashes (root -> images -> layers -> layer configs + files). The OCI manifests and configs are separate to Docker manifests and configs and basically Docker will support both side by side.

Re: Rails on Docker

#102

Post by orf »

vidarh wrote: post #99
orf wrote: post #86

Earlier quoted context omitted.

Unfortunately this messes with caching and causes the builder step to always rebuild if you’re using the default inline cache, until registries start supporting cache manifests.

How so? I just tested a build, and it used the cache for every layer including the builder layers.

You did this on the same machine, right? In a CI setting with no shared cache you need to rely on an OCI cache. The last build image is cached with the inline cache, but prior images are not

Re: Rails on Docker

#104

Post by revskill »

This is a really good news. And to be fun, the easiest way to become mainstream, is to have a guide on how to deploy a Rails application in 1 click, for any cloud hosting service.

Re: Rails on Docker

#105

Post by gitgud »

JimDabell wrote: post #57
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...

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/

Re: Rails on Docker

#106

Post by sequoia »

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

Is there some reason not to use multi-stage builds for this? Blogspam: https://sequoia.makes.software/reducing-docker-image-size-pa...

Re: Rails on Docker

#107

Post by cobrabyte »

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!

+1 for Cloud66

Re: Rails on Docker

#108

Post by zbentley »

Too wrote: post #83
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"…

The new best practice is to use the RUN --mount cache options. Making the removal of intermediate files unnecessary and speeds up the builds too. Surprised to see so few mentions of it.

As someone whose week was ruined by an overwhelming proliferation of `--mount type=cache` options throughout a complex build system, I'm not so sure.

Externally managed caches don't have a lifecycle controlled or invalidated by changes in Dockerfiles, or by docker cache-purging commands like "system prune".

That means you have to keep track of those caches yourself, which can be a pain in complex, multi-contributor environments with many layers and many builds using the same caches (intentionally or by mistake).

Re: Rails on Docker

#109

Post by hakunin »

jrochkind1 wrote: post #96
brundolf wrote: post #93

Earlier quoted context omitted.

It seems not that hard to just manually bump your version periodically, right? I get that it's not as nice as having it taken care of for you, but it's not like you're having to manage a whole system by hand

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. Nothing to bump in this case, just occasionally rebuild your own image from scratch, instead of from cache, to make sure it downloads the latest base image.

Re: Rails on Docker

#110

Post by ehhthing »

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…

For what it's worth, the vast majority of vulns in a web app are in its code or dependencies rather than in the base OS. I haven't actually seen any real-world cases of getting hacked because your docker base OS image was out of date. The only exception I would give would be for like language runtime version, which can occasionally be an attack vector. Switching runtime version usually requires manual testing regardless, so I wouldn't really consider it a docker-only problem.

If you're really concerned, just have a CI job that rebuilds and tests with newer base image versions.

Post reply on HN