41–50 of 229 posts
Absolutely love Podman. You can even define registries to work with docker hub, easily.
Earlier quoted context omitted.
I hate how the Docker team called it native. Docker for Mac/Windows still run in a hypervisor because so much of Docker is specific to Linux/cgroups. There was a FreeBSD port of Docker that attempted to implement a lot of the Docker API using zfs+jails but it went unmaintained and was never ported to the newer modular Docker implementation. You're always going to get that performance hit with the hypervisor layer the…
> Docker for Mac/Windows still run in a hypervisor because so much of Docker is specific to Linux/cgroups. As I understand it, that what you describe is true of Docker for Mac, but not Docker for Windows which uses Windows' built-in container support (analogous to cgroups). https://stefanscherer.github.io/how-to-run-lightweight-windo...
git clone https://github.com/myprofile/my-cool-app
cd my-cool-app
chmod +x deploy.sh
./deploy.sh
Earlier quoted context omitted.
I have no idea how, but Docker for Mac was taking up a whopping 65GB of space in one of the cache folders in ~/Library, although I had uninstalled it months ago. I wish I had taken a screenshot, but I was honestly dumbfounded. I had used it maybe once, ever. EDIT: It turns out I’m not making this up/an edge case, at least 940 people have run into this too: https://github.com/docker/for-mac/issues/371
I have that problem too. Solution seemed to be to set up an alias to clean out old images, volumes, etc and run that every so often
I'm newer to the Docker scene but haven't really found any of the complaints in this article realized in my work. Faster speed would be nice but I don't really mind it now. I see a lot of complaints about the docker daemon and root privileges on HN and I've tried to understand where they are coming from but I can't get anywhere. For instance, I understand the reasoning behind "if there is no need for a daemon there s…
-- When our sw gets deployed on-prem by our users (or in their cloud, or wherever), our customers rather not deploy our SW with root for no good reason. Some of them have to do things like fill out forms ahead of time or on use due to this (!).
-- In turn, when we run third-party code, say as a normal dependency or a user-submitted script, we have no reason to trust it. That means we want to limit what it can do, and especially if something breaks out, have defensive layers. (Browsers & NodeJS are Technology From The Future in this regards.)
Note that almost all "docker exploit X FUD" articles, in fine print, make assumptions around running docker as root / privileged / etc. It's 2019, we know better.
Also, we happen to run an increasing amount of our stack as GPU code, which adds a (not so) funny layer to all this.
These are real problems with docker, but do we wanna talk about docker for Mac? A total performance disaster. https://github.com/docker/for-mac/issues?q=is%3Aissue+is%3Ao...
Seriously. It's absolute trash. I don't even want to think about how much time I've lost waiting for startup and teardown operations. Edit: Before you downvote me too heavily, go give the issues list a thorough read. Some of the problems are quite bad. Perhaps I could have said it in a nicer, but really, it's bad, and it's been bad for a good long while now.
The article is completely on point. Because of all the reasons exposed there (and a few more) I started Wasmer, a new container system based on WebAssembly - https://wasmer.io/ Here are some advantages of Wasmer vs Docker: * Much faster startup time * Smaller containers * OS independent containers (they can run in Linux, macOS and Windows) * Chipset independent containers (so they can run anywhere: x86_64, Aarch64/AR…
Is there a feature by feature comparison of wasmer to docker? I don't think Wasmer, while interesting, is a container system. It looks more like a bytecode vm. Things I use and love from docker that to me feel "container"-y: 1. OSs as a library (FROM alpine:3.9) 2. Network namespaces so all applications think they are running on a machine with port 80 available 3. Service discovery through DNS 4. CPU and memory share…
Because of that some of the things that you posted are a bit hard to compare.
We believe that by having a VM (based on a industry adopted specification such as WebAssembly) we can control much more granularly both execution (CPU, memory) and the runtime interoperability with the system (networking, file system, ...), solving most of the issues that Docker containers have
These are all pretty good points. I can understand why Docker allows any base layer OS, but they could have made their own packages or limited a single distro and it would be easier to check for outdated packages and security issues in containers. The cgroups and Linux specific hooks keep Docker from being implemented natively anywhere else. The fact you have to share the entire Docker socket for containers to be abl…