In this case you could still pick homebrew as your package manager of choice. It works pretty well, is available cross platform ( https://github.com/Linuxbrew/linuxbrew ) and is far more simple than docker. You just have write a short shell script which installs all the dependencies via brew when not installed already (much like you'd do in a Dockerfile).
Brew doesn't offer you isolation - you cannot run multiple isolated applications with different dependencies at the same time.
But you can install brew in a subdir. For some projects i do exactly that. Project/.brew. I have a project/bin/activate which puts ./.brew/bin in your path. And there you go: postgres9.5 for this project and postgres 9.2 for that project. Still no isolation though. And having pg installed in a docker image is not a good example... But you getthe point :)
Who downvoted this? This is a real experience report, expressing valid concerns, citing an issue tracker for more information. Is this type of comment discouraged on HN? If so, why?
I didn't downvote, but I'd imagine people don't agree with his criticism of stability because it conflicts with VirtualBox. VirtualBox has to invasively modify your system configuration in order to accomplish virtualization. On the other hand, xhyve is using an OS X sanctioned virtualization technique (hypervisor.framework) that works within sandboxed apps. This is the route going forward that Apple advocates for vir…
This is exactly correct. We're really enjoying working with the Hypervisor.framework, VMnet.framework, and all the various hooks Apple has exposed for apps like Docker for Mac. There are some bugs in the short-term, but Apple has been steadily addressing our Radar bugs and we have workarounds in place in the Application for the most annoying ones.
We'd love to get your feedback on the new filesystem engine in the Docker for Mac app. It's been a ton of work to get right, and there a few corner cases in the current beta that we're squashing, but overall things "just work" for my day-to-day Linux development on my Mac using the current beta. At this stage, pointing it to the weirdest and most wonderful filesystem stressers you can find is welcome. We'll leap on a…
One thing I'm immediately concerned about is having some way of "pausing" xhyve. Purely because of Android development :( Intel's HAXM doesn't (seem to?) play nice, and asks for an exclusive lock. See https://github.com/mist64/xhyve/issues/88 and https://code.google.com/p/android/issues/detail?id=197915
I haven't tried the Android emulator recently, but I am interested in deploying Facebook's Infer tool on our codebase (and they've got a Docker container too for it of course). So I've filed an internal bug for us to look into HAXM and figure out if it plays well with Docker for Mac/Windows. Thanks for the pointer!
If you're using docker on mac, you're probably not using it there for easy scaling (which was the reason docker was created back then), but for the "it just works" feeling when using your development environment. But docker introduces far too much incidental complexity compared to simply using a good package manager. A good package manager can deliver the same "it just works" feeling of docker while being far more li…
No, package managers don't really have anything to do with this.
No, package managers don't really have anything to do with this.
Nix can provision containers, VMs, bare metal. It is much more capable than Docker because it composes , and doesn't use opaque disk images as the basis for everything. Nix provides much better reproducibility.
Docker uses LXC containers. 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. 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). In Windows/Mac, you still need to run in a vi…
The glaring security hole in Docker is that it has not designed a solution for keeping secret data necessary to build an image from being in the image at run time. They also haven't solved the general case of keeping transient build data out of the final image either, but that's a broader problem that doesn't necessarily involve security concerns. For now not a lot of people are concerned about either problem so it's…
They have build args for this in now. Thus, you'd do something like:
docker build --build-arg OAUTH_TOKEN=blah -t example .
Can someone explain in simple terms how Docker for Windows is different from Application Virtualization products like VMware ThinApp, Microsoft App-V, Spoon, Cameyo, etc? Also, why does it require Hyper-V activated in Windows 10? I found this: https://docs.docker.com/machine/overview/ but I don't understand if you need separate VMs for separate configurations or they have a containerization technology where you are a…
Docker uses LXC containers. 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. 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). In Windows/Mac, you still need to run in a vi…
The two most recent technical previews for Windows Server support containers natively. You don't need a VM to run containers on Windows.
The glaring security hole in Docker is that it has not designed a solution for keeping secret data necessary to build an image from being in the image at run time. They also haven't solved the general case of keeping transient build data out of the final image either, but that's a broader problem that doesn't necessarily involve security concerns. For now not a lot of people are concerned about either problem so it's…
They have build args for this in now. Thus, you'd do something like: docker build --build-arg OAUTH_TOKEN=blah -t example .
From the horse:
The build-time environment variables were not designed to handle secrets.
By lack of other options, people are planning to use them for this.
To prevent giving the impression that they are suitable for secrets,
it's been decided to deliberately not encrypt those variables in the process.