![Docker For Mac Forum Docker For Mac Forum](https://docs.docker-cn.com/docker-for-mac/images/settings.png)
When posting an issue/feedback, please make sure to remove any sensitive information. Oct 31, 2016 - Just for laughs I tried to run zcashd on my mac, in docker. Turns out it's pretty easy! I ran it in docker for mac, with this Dockerfile: FROM.
I'm also in the beta, and I like it a lot. It's functionally equivalent to `dlite`, which Nathan LaFreniere has done an extremely good job on.
He deserves massive credit for making OSX Docker dev bearable and for providing the inspiration for 'Docker for Mac'. A few issues I've seen: 1. I cannot believe they are using `docker.local`. This hostname will cause nothing but trouble for years to come. DON'T USE `.local`! Apple has decided that `.local` belongs to Bonjour, and due to a longstanding bug with their IPv6 integration, you can expect to see a 5-10s random delay in your applications as Bonjour searches your local network to try to resolve `docker.local`.
Yeah, you put it in your `/etc/hosts`? Doesn't matter. Still screws up. Use `docker.dev` or `local.docker`.beta8 is screwed up. It won't bind to its local ip anymore.
The only option is to port forward from localhost. Unfortunately, Docker isn't offering a download of beta7.
Thankfully, I still had the DMG around. The polish is still lacking. Most menu bar items ask you to open up something else. Why 'Docker for Mac'? Couldn't the team think of a less confusing name? Now I have 'Docker' running 'docker'.
Otherwise - great projects, and again, much credit to @nlf for `dlite`. If you're not part of the beta, check out dlite. It's at least as good as Docker for Mac.
I cannot believe they are using `docker.local`. This hostname will cause nothing but trouble for years to come. We are indeed moving away from `docker.local` in Docker for Mac. There have actually been two networking modes in there since the early betas: the first one uses the OSX vmnet framework to give your container a bridged DHCP lease ('nat' mode), and the second one dynamically translates Linux container traffic into OSX socket calls ('hostnet' or VPN compatibility mode). Try to give hostnet mode a try by selecting 'VPN compatibility' from the UI. This will bind containers to `localhost` on your Mac instead of `docker.local` and also let you publish your ports to the external network. One of our design goals has been to run Docker for Mac as sandboxed as possible, and so we cannot just modify the /etc/resolv.conf to introduce new system domains such as '.dev'.
We've been iterating on the networking modes in the early betas to get this right, so beta9 should hopefully strike a good balance with its defaults. It's also why we've been holding a private beta, so that we can make these kinds of changes without disrupting huge numbers of users' workflows. Your feedback as we figure it out is very much appreciated! Interesting, this is the first time I'm reading about it 1. Well, if anything it looks like a web app would have to be rebuilt from the ground up to fit that model.
I haven't yet read much about it, but here's a few questions that pop up immediately: 1) If you have a container per data object, doesn't that mean you also have to start a process every time a user opens a document? So forget about doing any computations in the setup. Even just things like using regex patterns in python (that need to be compiled once) or using anything with a VM (that needs to be started) you'd have to give up. Usecase seems to be extremely limited, but maybe I'm not getting something right here. 2) How do you handle indexes, views and collections over a large set of data objects?
it looks like a web app would have to be rebuilt from the ground up to fit that model. The app market is full of apps that were not originally written for Sandstorm: Examples: Wekan, Etherpad, Rocket.Chat, EtherCalc, draw.io, Gogs, Dillinger, NodeBB, EtherDraw. It turns out that converting a web app to Sandstorm is mostly deleting code. You delete your user management, your collection management, your access control, etc.
What you have left is the essence of your app - the UX for manipulating your core data model, of which you now only need to worry about one instance. doesn't that mean you also have to start a process every time a user opens a document? Most apps we've encountered only take a couple seconds to start. But we're working on a trick where we snapshot the process after startup and start each grain from the snapshot, thus essentially optimizing away any startup-time slowness.
How do you handle indexes, views and collections over a large set of data objects? Sandstorm is (currently) designed for productivity apps, not for 'big data' processing.
The data within a single grain is usually small. That said, you can run whatever database you want inside the grain. (I'm the tech lead of Sandstorm.). Most apps we've encountered only take a couple seconds to start.
But we're working on a trick where we snapshot the process after startup and start each grain from the snapshot, thus essentially optimizing away any startup-time slowness. This is very interesting. I've been looking for something like this since 2007 for optimizing the startup time of some apps. However I couldn't find any suitable technologies for this purpose; VM memory snapshotting is heavyweight and is slower than starting an app from scratch, OS-level tools like cryopid can't even be called alpha-level.
What kind of snapshot technology do you intend to use, and how confident are you that it will work well? Pretty much anything you'd like to do with CouchDB or MongoDB. Replace 'document based storage' with table based and you have pretty much any.SQL application.
So I guess my question is: How do you expect people to use your fine grained model with databases? If the answer is 'not at all' then I find the scope too limiting. If the answer is '1 grain 1 db' then I find the claim that you are solving difficult permission problems to be false. Note: I don't want to be too critical here, I'm just trying to pick holes in your claims of scope so I can categorise the power of sandstorm and how far it could be useful for things I'd like to build. Pretty much anything you'd like to do with CouchDB or MongoDB Wekan is a Trello clone that uses MongoDB for storage.
On Sandstorm, each board lives in a grain, so there ends up being one MongoDB per board. This works fine. The only thing stand-alone Wekan ever did that queried multiple boards at once is display the user's list of all boards. On Sandstorm, displaying the user's grain list is Sandstorm's job, not Wekan's - and indeed, usually the user is more interested in seeing the list of all their grains rather than just the Wekan boards, so delegating this to Sandstorm is a UX win.
If that is not the kind of example you have in mind, then you really need to give a specific example. I've noticed some pretty extreme performance penalties with Docker for Mac. Wherein VirtualBox would spin.
I work on Docker for Mac The early betas focussed on feature completeness rather than performance for filesystem sharing. In particular, we have implemented a new 'osxfs' that implements bidirectional translation between Linux and OSX filesystems, including inotify/FSEvents and uid/guid mapping between the host and the container. Getting the semantics right took a while, and all the recent betas have been steadily gaining in performance as we implement more optimisations in the data paths. If you do spot any pathological 'spinning cases' where a particular container operation appears to spiking the CPU more than it should be in, we'd like to know about it so we can fix it. Reproducible Dockerfiles on the Hub are particularly appreciated so that we can add them to the regression tests. Our approach is to focus on functionality and correctness first, and then improve performance over time. Sounds promising.
But I'd like to see Docker work with Microsoft to produce something even better for Windows, using the new Windows Subsystem for Linux (WSL). With WSL, Docker and Microsoft should be able to bring Linux-based Docker containers to Windows, without the performance hit and resource fragmentation that inevitably come with virtualization. True, WSL doesn't support namespaces and cgroups, but IIUC, Windows itself has equivalent features. So the Docker daemon would run under Windows, and would use a native Windows API to create containers, each of which would use a separate WSL environment to run Linux binaries. I don't know how layered images would be supported; Microsoft might have to implement a union filesystem. Keep in mind, Linux containers work since there's only one Linux kernel, and the rest of the OS is just files that can be stuck into the container. Anything that can pretend to be the Linux kernel (like a Solaris 'branded zone') can run a Linux container.
But you'd actually need many different kinds of 'Windows container', since Windows actually has an abundance of kernel-exposed runtimes: the DOS VMM, Win16 with cooperative threading, Win32 with COM, WinNT, WinRT, the POSIX subsystem. You could certainly write a particular container runtime to allow a specific type of app (e.g.
WinRT apps) to run, and that might be enough to enable developers going forward to target both Windows and Linux hosts for their Windows apps. But that would hardly be Windows, in the sense of being able to have your app launch arbitrary other 'Windows' processes in the same container the way that Docker apps do with arbitrary Linux processes. Having all the machinery to simulate all the vagueries that have changed in the Windows OS core over time, such that one container could contain any and all Windows processes running together, would be a much harder challenge. I don't know what the combined surface area of all the runtimes the Windows kernel exposes looks like, but I can't imagine it'd be something even MS could re-implement as a Linux-kernel translation layer easily (especially considering all the compatibility shims each layer provides to make specific apps work, that would have to be carried forward into the translation layer.). There is still a tiny VM running. This one happens to be the Native OS X Hypervisor Framework.
From the docs: Hypervisor (Hypervisor.framework). The Hypervisor framework allows virtualization vendors to build virtualization solutions on top of OS X without needing to deploy third-party kernel extensions (KEXTs). Included is a lightweight hypervisor that enables virtualization of the host CPUs. I've had a great run with VirtualBox, between Vagrant and Docker Machine.
But I can't lie, I won't miss its installer, uninstaller, OS X kernel extensions, questionable network file sharing, and more. Removing a big blob of software between me and my virtualization-ready CPU is progress. Then Docker for Mac is the one-two punch. Simpler virtualization, extremely rich containerization. The touted 'native' is not what it is all cracked up to be. Maybe windows is a plus that brings a few souls into the fold, but I've been looking for OSX performance ratings and only found some comments here and there that are like my experience.
At my El Capitano, the exact same setup in Docker Beta takes roughly ten times to do its thing than my more flexible vbox setup did. A java stack (Jenkins) starts in about 1.5 minutes, but with Docker Beta it takes 15 minutes or about!
So, my docker-machine setup lets me see my hosts with vbox, manage them with docker-machine, and get the NFS tweaked with docker-machine-nfs. Boot2docker OS is nice and small and works. So for me this is quite a contrast with the 'native' Alpine images based Beta. Which in my 5-hour stint with it did not show much way to overview or inspect it without getting new/more gear. I have Docker for Windows Beta, but when I've installed it on my Surface Pro 3, it immediately caused the device to get stuck in a BSOD loop. I think it has something to do with Hyper-V and connnected standby but I'm not 100% sure.
Wasn't able to find an answer because it's so early on. I really want to get into Docker, but that bug has killed any possibility of me adopting it as of right now.
I did install it on a desktop (which I lightly use) and it worked fine. With the new Windows 10 Insider build on that desktop though, Docker constantly is asking permission to run. Anyhow, I really hope someone does a good overview of Docker for Windows beta, as well as the Ubuntu environment within Windows 10 now.Seems like OSX gets all of the dev love, so I'm wish and hoping for a really nice Windows overview. As I am currently having a hard time with both. Neither, as of right now, work well. I started playing around with Docker for Mac in an attempt to get my whole dev environment set up in Docker. It was really slick, especially being (re-)introduced to docker-compose which makes connecting containers very easy.
There is a ton of potential there. My biggest challenge is that the documentation hasn't quite caught up to all of the interesting stuff that is going on. I'd certainly welcome some more opinionated answers for how to develop on Docker.
Specifically: how to not run apps as root, as almost all examples use root and permissions are annoying if you don't do so; how to use docker containers for both dev and prod; best practices for getting ssh key access into a container during the build phase. But much of it Just Works at this point, I'm pretty confident that the best practices will catch up in time. I install node, postgres, and redis natively and it all works fine.
What benefits does docker provide to my workflow? Isn't it obvious? With docker (or vagrant, or at least a VM etc) you can have the SAME environment as the deployment one. If you run OS X or Windows your direct local installs with differ in numerous ways to your deployment. And same if you run Linux but not the same distro or the same release.
And that's just the start. Who said you'd be working in only one deployment/app at the time? If you need two different environments - it could be even while working on version 2.0 of the same web app with new technologies-, e.g. One with Node 4 and one with Node 5, or a different postgres version, etc, you suddenly have to juggle all of these in your desktop OS. Now you need to add custom ways to switch between them (e.g.
Can't have 2 postgres running on the same port at the same time), some will be incompatible to install together etc. Without a vm/docker you also don't have snapshots (stored versions of the whole system installed, configured, and 'frozen'). Having dev servers set up the same as production makes sure that none of the little gotchas pop up that can cause problems. You can more readily guarantee that the version of every part of the stack is the same, and that the configurations are the same. One of the things this lets you do is work deeper in the stack without nearly as many concerns.
You can test config tweaks, hand-rolled builds, etc, with knowing that a rollback is just an rm -rf and untar away, or a finalized config change is expressed as a single diff. When you have 15 of those things start to make sense. I used vagrant in school just so that I wouldn't have any lasting tweaks of db's and weird things you end up doing. Also, with a provisioning script, I can get my projects running to this day.
My snobol, smalltalk and scheme projects all can be run by just running vagrant up. I don't have to make sure that my current machine has all of the dependencies. When we developed an angular and java site, I set up vagrant to configure tomcat, node, java, and all of the plugins required to get tomcat and maven to be nice together. Did it once, and then everyone else with a unixy platform were able to not spend time on dealing with that. Now that the class is over, all of that is removed from my machine but I can always just crank it back up in the time it takes to install all of those dependencies. I got an impression that this is not that useful for development due to very weak networking support. For example I use a single docker installation in a VM to test several unrelated projects with all of them providing a web server on a port 80/443.
I do not want to remap ports not to deviate from the production config. Instead I added several IP to the VM and exposed relevant containers on own IP addresses.
Then for testing I use a custom /etc/hosts that overwrites production names with VM's IP addresses. This works very nicely. But I do not see that something like this is possible with 'Docker for Mac'.