Issue has been resolved. What we ultimately concluded was that for unknown reasons the order of files being required was slightly different for different users of the docker container. So the solution we have found was to explicitly re-order requires and to require everything needed for a given module, even if it was typically already loaded elsewhere. Luckily ruby deals with redundant dependency loading for me. We never found a reason why some users, repeatably and without fail, experienced different behavior when loading the application. ------------------------------------------------------------------ Hi Everyone, I've just spent two days dealing with some weirdness, and I turn to you all to see if anyone else has had an experience like this. Background on me: I'm not a docker newbie. I've been working with docker professionally for 3+ years now, and I was playing with it with amateur interest from before DockerFiles existed. I built a docker container that we are using for development, pushed it to our repo, and had a colleague pull it and try to use it. The container works fine for me, and for my colleague it gets a dependency missing error. We then tried it across other colleagues. For some it works fine, for some more it does not. We confirmed the container is the same, we have the same SHA for the image digest when we run `docker images --digest`. Docker for Mac removes the dependency on VirtualBox and instead uses virtualization technology that is already part of Mac OS X, HyperVisor. Docker for Windows uses Microsoft’s virtualization technology, Hyper-V. What we have confirmed is that for those that it does not work, they are using OSX High Sierra, where as for myself and another colleague for whom it does work, we are on (regular) Sierra. So, thats where I am now. We think the difference is caused by OSX version, but I don't know how to mitigate it, or how to further diagnose the issue. Do you have any thoughts? Any ideas of where to look to see a root cause? More than likely you and your colleague's docker is using different Linux kernel (with possible differences in the base OS, not to mention different version of docker). Docker for Mac uses XHYVE hypervisor and runs (at least in my version) Linuxkit base OS. You *CAN* 'enter' that Linux VM on a mac and verify a few possible differences this way: screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty This will put you into a VM shell, you may be able to run a few checks there and compare. This will tell the story. There were a few devs on my team that were tracking down similar weirdness with Docker for Mac. I don't recall the details and wasn't directly involved, but they did have problems that were, in part, traced to some edge/experimental stuff that some had turned on and others didn't. In the end, they spent a few hours huddled together with lsof, strace and friends and the answer was found. I believe it turned out to be PEBKAC as opposed to anything specifically blameable to Docker. Since you mentioned that some developers are on Sierra and others on High Sierra, I'm guessing that the behaviour you're seeing might relate to an issue with raw images on APFS in High Sierra. For Sierra users, qcow2 images are used. If you look in Docker → Preferences → Disk, you can figure out disk format by the file extension on the Disk image location. See for a bit of information about the two image formats. To rule this out as an issue, I suggest you manually switch everyone to the qcow2 image format, and try again. Future versions of Docker for Mac will switch to the raw format as a default. Sorry, I should have been more clear. I'm referring to the VM image that backs the xhyve VM that Docker for Mac uses, not the Docker images. A problem cropped up many months ago when Docker for Mac started switching High Sierra users from qcow2 to raw VM images. This transition has been temporarily halted. But, depending on when your High Sierra users installed Docker for Mac, they may be on raw VM images. I suggest you check your High Sierra users for what type of VM image they're on, and switch them all to qcow2, if they're on raw.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
March 2019
Categories |