julien-duponchelle / docker-osx Goto Github PK

Hello guys,

I'm trying to understrand the way to expose a port of the Vagrant that run Docker.
I can't write directly in the Vagrantfile because you overwrite it.

I'm sure we can do it so if you expose it here, it could be nice to write it in the README.

is there a way to cleanly uninstall?

In additional docker halt, I'd like to have the ability to destroy a created virtualbox VM with something like vagrant destroy. Can't run vagrant destroy itself since there's no Vagrantfile or other way for vagrant to know what Virtualbox is doing.

This error occurs on command:

go get -v github.com/dotcloud/docker/...

It's because go is installed without --with-cgo flag.

We're shutting down our AWS account so I need to shut down this domain. Does anyone want to take this over? I could host it on my personal AWS account if not.

Hi @bfirsh with docker 1.3 out should we replace the whole project by a link to boo2tdocker?

I used homebrew to install gnu-tar in the past because of a problem with OS X's built-in tar. This causes docker-osx installation to fail. The output of docker-osx shell is:

Installing Docker 0.11.1 client...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 2885k  100 2885k    0     0  1181k      0  0:00:02  0:00:02 --:--:-- 1181k
tar: /docker/docker: Not found in archive
tar: usr/local/bin/docker: Not found in archive
tar: Exiting with failure status due to previous errors

Boot2docker is lighter than ubuntu:
https://github.com/steeve/boot2docker

It should probably read "Easily install and use Docker on Mac OS X".

Though I sort of prefer more direct descriptions, e.g. "Docker on OS X", "Fast and easy installation of Docker on OS X". shrug What do you think?

Are they really necessary? boot2docker isn't a replacement for docker-osx yet, so there is no need to make it look as if docker-osx is broken.

Would be great if I could just do:

brew tap phinze/cask
brew install brew-cask
brew cask install vagrant virtualbox
brew install docker

I have a situation where calling docker run -v $(pwd):/app <image> pserve development.ini is really slow, due to the fact that vagrant has to sync a rather large directory at pwd. I've found that changing this line:

config.vm.synced_folder "$(echo ~)", "$(echo ~)", :create => true, mount_options: ["dmode=777,fmode=776"]

To:

config.vm.synced_folder "/Users/jayd3e", "/Users/jayd3e", :nfs => true

Eliminates the problem. Just wanted to get some insight into the options that I removed, and why they are there in the first place.

Getting the following error when running it with the .docker dir freshly deleted on Mac OS X 10.9:

[default] Booting VM...
[default] Waiting for machine to boot. This may take a few minutes...
[default] Machine booted and ready!
[default] Mounting shared folders...
[default] -- /vagrant
Failed to mount folders in Linux guest. This is usually beacuse
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=id -u vagrant,gid=getent group vagrant | cut -d: -f3 /vagrant /vagrant
mount -t vboxsf -o uid=id -u vagrant,gid=id -g vagrant /vagrant /vagrant
/usr/local/bin/docker: line 145: /Users/powellc/.docker/go/bin/docker: No such file or directory

In my attempt to make automatic upgrading work, vagrant up is run, then vagrant provision is run. It shouldn't do both of these on first boot, but we also need to make sure that the machine is reliably provisioned in case of failure.

It should probably read "Easily install and use Docker on Mac OS X".

Though I sort of prefer more direct descriptions, e.g. "Docker on OS X", "Fast and easy installation of Docker on OS X". shrug What do you think?

I sometimes run docker halt to check everything's stopped, but this boots the machine if it isn't already running, only to shut it down again. We should shortcut docker halt before the VM is booted.

Vagrant is great to manage VMs which 1) are custom, 2) have lots of moving parts and 3) change often.

In contrast, to run docker on OSX you only ever need the same exact image for everyone. So 1) it's not custom (everyone gets the same image), 2) there are no moving parts, and 3) it changes only once per release of docker.

My recommendation is to use simply use boot2docker, and make headless virtualbox calls yourself. It's really not that hard and the result will be much simpler and smaller.

I seem to be getting a port conflict when I tried this out. I would change the Vagrantfile, but I am not sure where they are :)

jdyer@retina:~ » docker version
Bringing machine 'default' up with 'virtualbox' provider...
[default] Importing base box 'ubuntu'...
[default] Matching MAC address for NAT networking...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Fixed port collision for 22 => 2222. Now on port 2200.
Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 4243 is already in use
on the host machine.

To fix this, modify your current projects Vagrantfile to use another
port. Example, where '1234' would be replaced by a unique host port:

  config.vm.network :forwarded_port, guest: 4243, host: 1234

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn't allow modifying port forwarding.
Install docker configuration
VM must be running to open SSH connection. Run `vagrant up`
to start the virtual machine.
command-line line 0: Missing argument.
lost connection
VM must be running to open SSH connection. Run `vagrant up`
to start the virtual machine.
Restart docker
Bringing machine 'default' up with 'virtualbox' provider...
[default] Setting the name of the VM...
[default] Clearing any previously set forwarded ports...
[default] Fixed port collision for 22 => 2222. Now on port 2200.
Vagrant cannot forward the specified ports on this VM, since they
would collide with some other application that is already listening
on these ports. The forwarded port to 4243 is already in use
on the host machine.

To fix this, modify your current projects Vagrantfile to use another
port. Example, where '1234' would be replaced by a unique host port:

  config.vm.network :forwarded_port, guest: 4243, host: 1234

Sometimes, Vagrant will attempt to auto-correct this for you. In this
case, Vagrant was unable to. This is usually because the guest machine
is in a state which doesn't allow modifying port forwarding.
2013/08/28 19:36:57 unexpected EOF
jdyer@retina:~ »

Hi there,

This is with a fresh install of vagrant and virtual box and using the default docker-osx settings and environment variables. Any assistance as to where I'm going wrong would be greatly appreciated.

~ docker-osx shell
Starting local Docker environment...
/Applications/Vagrant/bin/../embedded/gems/gems/vagrant-1.6.3/lib/vagrant/pre-rubygems.rb:31: warning: Insecure world writable dir /usr/local in PATH, mode 040777
/Applications/Vagrant/embedded/gems/gems/bundler-1.6.2/lib/bundler/runtime.rb:222: warning: Insecure world writable dir /usr/local in PATH, mode 040777
Start Docker Virtual machine
/Applications/Vagrant/bin/../embedded/gems/gems/vagrant-1.6.3/lib/vagrant/pre-rubygems.rb:31: warning: Insecure world writable dir /usr/local in PATH, mode 040777
/Applications/Vagrant/embedded/gems/gems/bundler-1.6.2/lib/bundler/runtime.rb:222: warning: Insecure world writable dir /usr/local in PATH, mode 040777
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports...
default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2222
default: SSH username: vagrant
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

For #19, it would be really great if we could install the Vagrant plugin once and assume it has been installed. In other words, run an installation.

I think we have a couple of options:

1. Have an install function which is run on first run, then a docker install command or similar to reinstall if stuff gets broken.
2. Have an explicit install script, sort of like the usual curl ..../install.sh | sh (not that this is necessarily a good way to do it, but it is an understood, easy to use pattern – see homebrew for example). This is not as neat as the magical combined install and execution, but might be easier to comprehend.

I get unexpected EOF when running any docker command, like docker search rails.

One exception is docker version which returns:

Go version (client): go1.1.2
2013/09/30 15:55:09 unexpected EOF

When I mount a directory from my local fs

ex:

docker run -i -v /Users/tyler/docker/data:/var/lib/mysql 3af0265e97e1 /bin/bash

I get weird permissions issues:

drwxr-xr-x 1 1000 1000 68 May 2 16:17 mysql

Am I doing it wrong? Is my installation of the VM corrupted? Is this a bug?

Tried this on three different machines. Doesn't work. Don't know if its cause brew cant install mercurial (site seems to be down). Manual installation of hg will get the VM to boot but docker version fails with:

Go version (client): go1.1.1
2013/09/03 15:23:16 unexpected EOF

OSX 10.8.4 Build 12E3067 (mid 2013 MacBook Air)
OSX 10.8.4 Build 12E55 ( Aluminium 2010 MacMini )
OSX 10.6.8 Build 10K549 (MacBook Core 2 Duo)

I don't like that this wraps docker. I especially don't like that it adds non-standard commands that will confuse people as to what is supported by docker itself and what is not. If you're going to call it docker, make sure it's really docker (ie no modifications). Otherwise call it something else.

My recommendation:

• Ship the unmodified docker binary (which we officially distribute for Darwin as of 0.7.3 by the way)
• Ship a separate script, called docker-osx or something, with your additional commands.
• Have your script configure docker in such a way that it connects to the vm. You can do this by proxying connections from the local unix socket to the vm, or by setting the DOCKER_HOST environment variable (as of 0.7.3).

If you do this I can merge it upstream and make it the official mac installer for docker.

Any chance we could get an update to the Vagrant base box to 0.10.0?

At least for me on OS X I am unable to get 0.10.0 to work perfectly. The client is installed as 0.10.0, but the server remains at 0.8.0.

This causes the docker ps command to return nothing, even when logging into the VM and running the same command shows the correct data.

Looks like @steeve is working on an almost identical thing for boot2docker. Perhaps we should decide on one and combine our efforts? Perhaps one should be blessed as "official" if it's going to be included in an installer? /cc @shykes

I had a fun time trying to set a friend up with docker-osx yesterday: their /usr/local/bin directory was owned by root, so we ran sudo curl ... and sudo docker-osx shell. This resulted in docker-osx hanging during VM provisioning. Not 100% sure why, but docker-osx ssh complained about key file ownership, which may well be to do with it.

To make matters worse, attempting to stop and remove the VM failed silently, so even after a chown ... /usr/local/bin, and a do-over, things continued to behave oddly. We had to open up VirtualBox and remove it with the GUI.

Three takeaways from this:

1. docker-osx should probably never be run as superuser.
2. There should perhaps be a note in the README, since docker-osx is manually installed with curl. Perhaps "step 0" should be "make sure /usr/local/bin is writable by you".
3. To prevent VM sadness, docker-osx should detect if it's running as superuser and refuse to do anything.

I get weird file corruption when mounting /var/www into this container. It seems to be specific to nginx in combination with docker-osx (not sure if the same happens with other virtualisation countainers that mount stuff from the host machine into the VM). I could not reproduce this on a pure linux/docker host. I had this on MacOSX 10.9.4 and a fresh docker-osx install.

$ docker-osx shell
$ mkdir ~/Sites/nginxtest
$ docker run --rm -i -t -v /Users/stefanfoulis/Sites/nginxtest:/usr/local/nginx/html -p 0.0.0.0:42002:80 nginx:latest
$ curl http://172.16.42.43:42002/index.html
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.7.1</center>
</body>
</html>

All fine so far.

$ echo "Hi there" > ~/Sites/nginxtest/index.html
$ curl http://172.16.42.43:42002/index.html
Hi there

So far so good. Let's add something to the file

$ echo "More stuff" >> ~/Sites/nginxtest/index.html
$ curl http://172.16.42.43:42002/
Hi there

The new line is missing. Even stopping the container and starting a new one will not have the change show up.

^C%
$ docker run --rm -i -t -v /Users/stefanfoulis/Sites/nginxtest:/usr/local/nginx/html -p 0.0.0.0:42002:80 nginx:latest
$ curl http://172.16.42.43:42002/
Hi there

And what is super weird, I can connect to the container with bash, run nginx in the backround and observe the files changing in the filesystem. But nginx does not pick them up.

$ docker run --rm -i -t -v /Users/stefanfoulis/Sites/nginxtest:/usr/local/nginx/html -p 0.0.0.0:42002:80 nginx:latest /bin/bash
root@e9e8fae26a58:/usr/local/nginx/html# nginx &
[1] 8
root@e9e8fae26a58:/usr/local/nginx/html# cat index.html
Hi there
More stuff

but at the same time from the host:

$ curl http://172.16.42.43:42002/index.html
Hi there

Deleting the file gets picked up though

$ rm ~/Sites/nginxtest/index.html
$ curl http://172.16.42.43:42002/index.html
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.7.1</center>
</body>
</html>

And now it gets interesting. Overwriting a file with a shorter content will show the content of the old file, but truncated at the length of the new file.

$ echo "And now for something completely different." > ~/Sites/nginxtest/index.html
$ curl http://172.16.42.43:42002/index.html
And now for something completely different.
$ echo "Now a shorter text" > ~/Sites/nginxtest/index.html
$ curl http://172.16.42.43:42002/index.html
And now for somethi%
$ echo "A way longer text that contains completely different content. Did I mention it is longer?" > ~/Sites/nginxtest/index.html
$ curl http://172.16.42.43:42002/index.html                                                                                        
And now for something completely different.

It looks like it's tied to the first request done with a new file. If you delete the file and make at least one request for that file and get a 404 and then re-add it, the new file contents will be picked up.

It seems to be a combination of docker-osx and nginx (I experienced this with the orchardup/nginx docker image as well. We did a quick test with an apache image, which did not show this behaviour.

My wild speculation: I suspect nginx is doing some deep magic in the way it detects file changes and caches it somehow (but apparently not just in memory, otherwise it would not survive container destruction and restart). Something with the docker abstraction of the volumes (and maybe just in combination of using a volume that was shared to the vm from the host os) and how nginx reads the files.

I'm linking this issue from docker and the official nginx docker image as well, as I'm not sure where the issue originates.

Some additional environment information:

docker version
Client version: 1.1.1
Client API version: 1.13
Go version (client): go1.2.1
Git commit (client): bd609d2
Server version: 1.1.1
Server API version: 1.13
Go version (server): go1.2.1
Git commit (server): bd609d2