[deleted]
Rails on Docker
181–190 of 228 posts
Re: Rails on Docker
#182Earlier quoted context omitted.
Yeah the fly.io stuff is great, beautiful artwork too, top class job. Re: security updates. It's not handled. There are companies that will scan your infrastructure to figure out what's in your containers and find out of date OS base images. One thing I'm currently experimenting with is a product for people who would like an experience slightly closer to traditional Linux. The gist is, e.g. include "#!gradle -q print…
> It's not handled. So... what do actual real people do in practice? I am very confused what people are actually doing here. LOTS of people seem to have moved to this kind of docker-based deploy for PaaS. They can't all just be... ignoring security patches? I am very confused that nobody else seems to think the "handle patches story" is a big barrier to moving from heroku-style to docker-style... that everyone else j…
Most places are building software regularly. Once a week update the base layer of the container to the latest OS. Then update your libs and app. Run tests, deploy.
Re: Rails on Docker
#183This is awesome and I'm glad Rails is adding something official here. Unfortunately if you want to use the Dockerfile in development with docker-compose you will need to make some changes/additions.
Most notably: only precompile assets if deploying, not during development
Re: Rails on Docker
#184Earlier quoted context omitted.
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.
'apt-get clean' doesn't clear out /var/lib/apt/lists. It removes cached downloaded debs from /var/cacpt/apt but you'll still have hundreds of MiB of package lists on your system after running it.
As I mentioned above, I recommend avoiding Ubuntu because it violates the principle of dev - prod parity. For any significant scale, Ubuntu will be left in the dust. Don't rely on system packages, build your own stream of minimal vendored (/opt/company) dependencies and keep them current because defaults are always old and don't consistently apply necessary patches for bugfixes and functionality.
Re: Rails on Docker
#185Earlier quoted context omitted.
> 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/ch…
Your comment makes clear you didn't read the guy you replied to, and I'm not sure it would've been in good faith even if you had, so I'm not going to spend time writing a full response.
Re: Rails on Docker
#186Earlier quoted context omitted.
'apt-get clean' doesn't clear out /var/lib/apt/lists. It removes cached downloaded debs from /var/cacpt/apt but you'll still have hundreds of MiB of package lists on your system after running it.
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.
Re: Rails on Docker
#187[flagged]
Re: Rails on Docker
#188Earlier quoted context omitted.
I never got around to implementing it but I wonder how this plays with cross-runner caches in e.g. Gitlab, where the cache goes to S3; there's a cost to pulling the cache, so it'll never be as fast as same-machine, but should be way faster for most builds, right?
the cache is small but if you have a `docker buildx build --cache-from --push` type command it will always pull the image at the end and try to push it again (although it'll get layer already exists responses), for ~250mb images on gitlab I find this do-nothing job takes about 2.5 mins in total (vs a 10 min build if the entire cache were to be invalidated by a new base image version). I'd very much like it if I could…
I mostly love Docker and container-based CI but wow what a great reminder that even common-seeming workflows still have plenty of sharp edges!
Re: Rails on Docker
#189What kills rails for me at the moment is the time it takes to start up. I'd love to be able to use on top of things like cloud run where resources ramp down to zero when there are no requests, but the startup time makes this very difficult.
You might try caching bootsnap in the Docker image. I didn’t realize this was possible until I saw it in the Dockerfile that Sam and DHH cranked out recently.
Re: Rails on Docker
#190It's been a while since I've done any Ruby/Rails development, but just curious why they chose to use a Debian/Ubuntu based image in the default Dockerfile instead of an Alpine based image?
The dockerfile is optimized for “works for the most number of people out of the box”. There was debate over using the ruby v ruby-slim image. Ultimately it was decided to go with the larger image to maximize compatibility.
That said, keep using Alpine! There’s no reason for folks to stop doing what they’re already doing if it’s working for them.
The new dockerfile is meant more for people who are just getting started that aren’t familiar with Docker or Linux.