Docker for Mac and Windows Beta

Before purchasing any equipment, I always spend time researching how well in works with Linux. Doing this, other than the occasional bad update, I have never had a hardware compatibility issue with Linux. And I do mean never and I don't throw that word around lightly. It does limit my decisions, but there's still plenty of good hardware that just works with Linux.

That's it, thanks for following up in my absence.

There are a couple of frameworks where all of the production files end up in, for instance /dist and one other directory. Rather than having to constantly blacklist everything you just say "ignore everything except X and Y"

I linked to that because it cross references to the PR where the build-args feature was added. If they're out of sync that's 1) news to me and 2) confusing and should be fixed.

I think one of the things we're seeing is that Docker is opinionated, a number of powerful dev tools and frameworks are also opinionated, and us poor developers are stuck between a rock and a hard place when those opinions differ.

For instance I'm still not clear how you'd use the docker-compose 'scale' argument with nginx. Nginx needs to know what its upstreams are, and there's IIRC still an open issue about docker-compose renumbering links for no good reason, and some Docker employee offering up how that's a feature not a bug. I could punch him.

Single use auth tokens and temporary keys sure would fix quite a few things, to be certain, but those opinions keep coming in and messing up good plans :/

> Docker uses LXC containers.

Nope, we've been using our own implementation of a container runtime for 2 years (libcontainer). LXC is not supported anymore and it was always a hacky execdriver.

> In Linux, these aren't VMs and are light weight user-land separations that use things like cgroups and lots of really special kernel modules for security.

They're kernel-space separations since the kernel understands namespaces (though it doesn't understand the concept of a container and some things aren't namespacrd).

> Unfortunately, this means Docker only runs on Linux .. not even Linux...special Docker Kernel Linux (all the features they need are in the stock Kernel tree, but it's still a lot of modules).

Almost all modern distros have support for all of the modules required to run Docker.

> In Linux, you can just go to localhost. I _think_ FreeBSD has native Docker support with some custom kernel modules. I'm not sure...I've only looked at the Readme. I haven't tried it.

FreeBSD is not supported as a daemon.

> So even in Windows/Mac, all your containers do run in one VM (where as with traditional stuff you mentioned, you'd need a VM for each thing).

Actually, recent versions of Docker can run as a daemon on Windows using some proprietary features I don't care about.

> Docker containers are meant to handle one application (that it runs as root within its container as the init process ... cause wtf?).

All machines have a single process running as root as the init. You can run a proper init inside your container (in fact it's recommended), and run many processes inside the same container. It's discouraged for scalability reasons to stuff your database and front-end in the same container because then it's hard to spin up more than one front-end connected to the same backend.

> In my work with Docker, I'm not sure how I feel. LXC containers have had a lot of security issues. Right now, Docker doesn't have any blaring security holes and LXC has increased security quite a bit.

Again: Docker doesn't and hasn't used LXC for quite a while. In addition, Docker has default selinux, seccomp and apparmour profiles that increase the security (seccomp allows us to disable syscalls that arent namespaced). There is a concern on the kernel side that they don't appear to care about going the Zones or Jails route: actually making the kernel aware about containers so that it can properly namespace things.

> After a while you get a shit ton of images that just waste space you're not using. CoreOS prunes these at regular intervals. A docker command to do this is still a Github issue. Writing one yourself with docker-py is horribly difficult because of image dependencies).

ahem % docker images | awk '/^/ { print $3 }' | xargs docker rmi

Sure, it's not a single command but it isn't impossible to do and doesn't require docker-py. Besides, you should be using engine-api.

> Oh and images. Docker uses images to build things up like building blocks. That's a whole thing I don't want to go into, but look it up. It's actually kind of interesting and allows for base image updates to fix security issues (although you still need to rebuild your containers against the new images ... I think...I haven't looked into that yet).

There's also tools like zypper-docker to allow for hot-patching of images.

> Until you, say, want to print something,

CUPS and Amahi work great for me. I've had more pain setting up printers on Windows and OS X (the latter started sending print jobs on each probe).

> run one of the bajillion pieces of useful software that aren't available for Linux.

Examples? I can't think of any software that I need that isn't available for GNU/Linux.