97c70 - 17d
Docker creates more problems than it solves
No, I've been using docker for 10 years off and on, it doesn't solve any real problems (that I personally have)
Just another layer to learn/troubleshoot/have incomplete support for (cf render.com docker volume support)
It seems like these two things should be decoupled, right? Some kind of provisioning code (like Ansible?) combined with a clean environment. But docker combines the two. If you have control over the actual environment (e.g. using the same VPS), you don't need a clean sandboxed environment. Plus, a lot of software platforms already have tools to normalize an environment. Do I really need to run my nodejs server behind nvm, installed in a container, running on a VPS? My original note was inspired by working with render.com's Docker mode, which is redundant because they already have a clean environment to run the package on, and having the extra layer makes it difficult to do simple stuff like use mounted discs.
Yeah, I get that containers allow the use of shared resources on a single host. The problem is that the same pattern has been used (and nested) in many places where it makes no sense. The render problem is that they support deploying dockerfiles, but not configuring the command to run the container on the host, which means you can't map volumes. The workaround is also really weird: https://community.render.com/t/map-disk-to-docker/4707/5
That makes a lot of sense, and yeah, a lot of this comes from me trying to deploy strfry/lmdb on a PaaS 😂
semisol @semisol - 17d
something something use NFDB /j this is not the ideal use case for ephemeral containers, ever. I don’t and wouldn’t run a relay on one
Yeah, I'm switching to just a regular VPS but now it's too underpowered to build strfry 🤷♂️
