Clang 5 in a Docker container for C++17

For building, you can create an image that is ready to build your application, then run it as needed. After each run, unless you've set up some persistence, it goes back to the pristine state. If you create lots of almost-identical environments, you can use layering to save space (but space is cheap, so...)

If you want to ship an application that way, you just take that a step further. Create an image ready to run the application. Just remember that storage is, by default, ephemeral. It's a config option away, but annoying if you forget it.

I like that I can just ship an image to someone and it'll work on their machine. Great for our OSX developers.

The interesting functionality is the use of namespaces, which are ways to create isolation of {IPC,networking,users,filesystems,processes} between the containers. Docker didn't invent them, they've been in the Linux kernel since forever, but Docker has made great use of them.

Volume mapping is useful too. Most of what it does is achievable via bind mounts, though, volume mapping is just cleaner, IMO.

That said, I've found the most usage out of Docker from the networking side of things, as extraordinarily convoluted as it can be. I have a legacy application that cannot run on any port other than the one that's hardcoded in the application. It tries to connect to itself immediately on startup, too. Obviously it prevents itself from running another instance... by killing the old instance when the new one starts up. Putting it in a Docker container let me run 12 of them, side-by-side, with the ports mapped externally to different ports, invisible to the application.

Just an FYI, I'm not one of the converted. I think the current fad of "Dockerize all the things" is a bit silly, especially when I start seeing people doing things like putting ssh access for the host machine in a container. I have no interest in their tools other than Docker itself. I'm not a fan of their whole "one process per container" suggestion, and basically ignore it whenever I want (you should make sure you have something running as the init system in your container if you do this). But it has pretty much replaced chroots for me, no small task.

Finally, if you want some good examples of what it can do, look at the images from https://hub.docker.com/u/linuxserver/

The fact that one can install a package in some OS means that somewhere, one or more people sat down and wrote a recipe for building and packaging it, and then hopefully performed some minimal QA on the final product to make sure it actually works.

This is not trivial, particularly not if multiple versions of a compiler may need to coexist (because of other packages depending on a particular version), and it needs to be done for each combination of compiler version and OS.

To me, examples like: "just run ", expecting a package to just magically install itself on some OS are the symptoms of a cargo-cult.

Rather, I think that using containers is more like outfitting a cargo container with a fully stocked and staffed workshop, then shipping the container and personnel to where the client needs it to be. The client then only needs to supply the storage space for the container and the goods that need processing (a shared directory in this particular case) and wait for the finished result. Sure, some of the workers may not speak your language, they may use different tools, but until (if?) the workshop gets rebuilt and staffed on "native soil", the inconvenience should be acceptable.

Not to mention if I had a dime for every case of people running full-blown distros under docker I would have been a millionaire by now