Open ktbartholomew opened 9 years ago
:+1: :100:
Think we should nuke boot2docker completely, or make some effort to retain backwards compatibility? I'm leaning toward "nuke boot2docker" myself.
(Also, I need to do this for my dotfiles at some point.)
~/deconst-repos $ find . -type f | xargs grep boot2docker
./preparer-jekyll/README.md: * [Docker](https://docs.docker.com/installation/#installation) for your platform. Choose the boot2docker option for Mac OS X or Windows.
./preparer-jekyll/deconst-preparer-jekyll.sh:which boot2docker >/dev/null 2>&1 && {
./preparer-jekyll/deconst-preparer-jekyll.sh: CONTENT_STORE_URL=${CONTENT_STORE_URL:-http://$(boot2docker ip):9000/}
./client/.gitignore:resources/boot2docker*
Binary file ./client/.git/objects/pack/pack-799e442ec2782d5b55b195f1b6951ad5223ff85b.pack matches
./client/src/utils/DockerMachineUtil.js: var data = fs.readFileSync(path.join(util.home(), '.docker', 'machine', 'machines', machineName, 'boot2docker.iso'), 'utf8');
With Docker 1.8, boot2docker is being deprecated in favor of docker-machine with the virtualbox driver. As many of our new internal users have been installing Docker via Docker Toolbox, which bundles docker-machine and not boot2docker, we should make sure that our various utility scripts will work with docker-machine.
Specifically,
DECONST=$(boot2docker ip)
is used in a few places to determine the Docker host's IP.