111–120 of 132 posts
Anyone know why Erlang doesn't run well on containerized Docker?
Earlier quoted context omitted.
I find using nix as a package manager to be a better solution. Write a nixfile that have all the tools you need for a script, and you're fixed. Docker is a slow, blunt tool for just containerizing dependencies IMO.
A slow, blunt, cross-platform tool. So while I agree, I don't think nix makes a good replacement for docker.
Earlier quoted context omitted.
> For instance, don't try to dockerize databases Host volume mappings. Problem solved. I've been using them for over a year, with all kinds of different databases, postgres, mysql, mongodb, in dev, ci, and production, never had a problem. It gives you a nice separation of what is and what isn't part of the application state, and makes backups a breeze.
Is this what you're referring to? https://docs.docker.com/engine/tutorials/dockervolumes/
Docker seems very limited when it's unsuitable to run databases. I've never seen this limitation with other container solutions. What is it about Docker that makes it problematic?
The thing I've learnt with Docker is that all the other Prod issues still exist. Docker at its core only solves the executable part or distribution of the process to run. Still need to figure out, network, storage, monitoring, backups, discovery, etc...
What starts out as a single host can quickly quadruple once all the other considerations are taken into account and wanting a scalable, reliable and available system.
I've never used Docker, or containers, but I read about things like "Breaking changes and regressions ... a well documented problem with Docker" and "Can’t clean old images ... a well known issue" and it just seems to me like a crazy thing to try to use and depend on this thing/company. Bluntly put they seem like children. So nevermind a retort, what I would like to see is a sane, sensible "business value" cost/benef…
Anyone know why Erlang doesn't run well on containerized Docker?
Earlier quoted context omitted.
A slow, blunt, cross-platform tool. So while I agree, I don't think nix makes a good replacement for docker.
Cross-distribution, to be precise. You can't run amd64 image on RPi for instance.
No it does not change processor architectures for you.
Earlier quoted context omitted.
(Having read the Reddit thread for a while) Macs don't appear to have support for containers which is what Docker is . Well that is probably bollocks because they are *BSD based and I know that FreeBSD at least has a form of containerization and I seem to recall that the whole container thing was invented on a BSD - "jails". So Docker can't run native on iStuff. You have to run it within a Linux VM. I gave up on Goog…
XNU (the macOS kernel) may have BSD origins, but it doesn't have features like cgroups and process namespacing that the Linux kernel provides and the Docker runtime relies on.
if I am using mount Volumens to export my data, can I bypass the aufs/overlay implementation/logic ? do I need to pay attention only if I don't mount the volumes? thx
Docker founder here. I keep reading articles stating that "the Docker API changes with every release", but the assertion is never backed by any specific examples. Has anyone here encountered an actual breaking change? If so, I would appreciate you sharing the specifics so we can fix it. Docker is by no means perfect: - I remember that in 1.10 the switch to content-addressed registries meant that older clients could n…
The fact that if your local client is newer than the daemon, the client will fail to do anything is pretty annoying. You can hack around it, but that's not a solution to the problem.
Also, while you shake off the 1.10 change as though it wasn't a huge deal, the migration tool that was written was not fit for purpose. First of all, it sometimes caused corruption after the migration (fixed after release but still an issue, and you couldn't practically un-bork the corruption). There were other issues with the tool, but the biggest issue was the there wasn't any sane transition period -- which made packaging very difficult. Because Docker couldn't handle restarting the daemon and keeping the containers around (and after restarting a post-1.10 daemon you'd have to wait for the full migration to finish before you could even interact with the daemon -- another issue with the transition), you'd have to publish a fake version bump of the Docker package to even alert users to the issue!
A more sane way to handle it would've been how databases handle the issue. You lazily do the conversion (or you have your software be able to handle both formats so you can run your migration while still having your containers work). And yes, I'm aware that it'd be difficult to implement but the transition path implemented was really bad.
I spent several weeks of my life (that I'll never get back) trying to make the migration path work. It didn't end up working because it wasn't designed to work nicely from the outset. So I ended up just telling users of our Docker packages about the issue and packaging the migration tool separately.
Another issue that I've had recently is that Docker is making it increasingly difficult to use `runc` by another name. In openSUSE we package a system runC separately to Docker (and it lives in /usr/sbin/runc), but because of the fact that in 1.12 --runtime was intentionally broken (and containerd's defaults are no longer obeyed by Docker) now you can't effectively use --exec-opt native.cgroupdriver=systemd. Great. So now we're going to have to package docker-runc and docker-containerd separately.
Don't get me started on the containerd split. I was not very happy the day that PR was merged, because it caused a bunch of headaches for us. It's also a bit amusing to note that containerd was tagged as "pre-alpha" until Docker bundled it (then it was considered stable).
That all being said, Docker is a great project -- it's just that you have to admit that issues with Docker are not "incredibly disconnected from reality".