Docker "machine" is a new command created by Docker team to manage docker servers you can deploy containers to. Think about boot2docker you use to run on your development workstation, but applied to all possible Cloud and on-premises hosting services.
"machine" is actually an OSX / BSD command, so conflict with your installation (#2). To prevent this I've moved it to my go/bin and declared this first in PATH.
The user experience here is very comparable to boot2docker, so I don't worry you'll get quickly used with it.
Let's no switch to a Cloud provider. Google Compute Engine is not (yet) supported, so was an opportunity to give Microsoft Azure a try, as this is terra incognita for me ...
First need to subscribe - then get your subscriber ID. Authentication on Azure is based on client certificate, so need to create a cert file, that you then have to register on https://manage.windowsazure.com. As it took me some time to discover where to upload it, here is a screenshot :
test
wtf ? This is actually a know issue. I have the same issue running docker client 1.3.2. I'm still stuck here.
Also, provisionning Azure host took a looooong time, "Waiting for SSH". I have no idea this is just me due to some misconfiguration, or something expected on Azure. I'm used with GCE to give me SSH prompt within 10 seconds... :P #troll
Anyway, the question here is not if provider A is better than B, but the option Docker Machine offer to change provider without changing the toolchain. Assuming I have a production delivery pipeline based on Docker containers, I'd be happy I can run the same both locally and provisioning Cloud instances by whatever IaaS provider.
Isn't that cool ?
"machine" is actually an OSX / BSD command, so conflict with your installation (#2). To prevent this I've moved it to my go/bin and declared this first in PATH.
Docker machine is based on ssh authentication to setup docker host nodes. You won't be able to use it with a standard Docker client, so need to download a custom 1.3.1-dev-identity-auth build - the related changes haven't been merged in 1.3.2 yet. I've moved this binary to go/bin to get it as default docker command during my test session. Run docker command once to get your authentication setup well done (~/.docker/public-key.json file).
Right, you're well done now. Let's first experiment locally, to compare with boot2docker
➜ machine create -d virtualbox local INFO[0000] Downloading boot2docker... INFO[0039] Creating SSH key... INFO[0039] Creating VirtualBox VM... INFO[0044] Starting VirtualBox VM... INFO[0044] Waiting for VM to start... INFO[0075] "local" has been created and is now the active machine. Docker commands will now run against that machine. ➜ echo $DOCKER_HOST tcp://boot2docker:2376 ➜ export DOCKER_HOST=`machine url` DOCKER_AUTH=identity ➜ echo $DOCKER_HOST tcp://192.168.99.100:2376
I expected (according to "Docker commands will now run against that machine") that DOCKER_HOST would be well set, but I had to set it by myself - maybe because it's already defined in my environment.
➜ machine ip local
192.168.99.100
➜ machine ssh local
## .
## ## ## ==
## ## ## ## ===
/""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
\______ o __/
\ \ __/
\____\______/
_ _ ____ _ _
| |__ ___ ___ | |_|___ \ __| | ___ ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__| < __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
boot2docker: 1.2.0
master : 8a06c1f - Fri Nov 28 17:03:52 UTC 2014
docker@boot2docker:~$ ls /Users/nicolas/
Applications/ Library/ bin/
Boulot/ Movies/
Desktop/ Music/
Documents/ Pictures/ dotfiles/
Downloads/ Public/ go/
Dropbox/ VirtualBox VMs/ google-cloud-sdk/
docker@boot2docker:~$ exit
➜ docker ps
The authenticity of host "192.168.99.100:2376" can't be established.
Remote key ID EJF7:BPI4:GKOC:GR7H:RKZL:KH5J:LOBB:YZRU:HCWR:JYXZ:AOGH:OOEO
Are you sure you want to continue connecting (yes/no)? yes
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
➜ docker run --rm -ti ubuntu bash
Unable to find image 'ubuntu:latest' locally
ubuntu:latest: The image you are pulling has been verified
511136ea3c5a: Pull complete
01bf15a18638: Downloading 9.731 MB/201.6 MB 20m43s
30541f8f3062: Download complete
e1cdf371fbde: Download complete
9bd07e480c5b: Download complete
...
So I get a classic Boot2Docker installation on machine, with /Users shared volume and all expected setup. Also get equivalent commands I use to run with boot2docker client command.
The user experience here is very comparable to boot2docker, so I don't worry you'll get quickly used with it.
Let's no switch to a Cloud provider. Google Compute Engine is not (yet) supported, so was an opportunity to give Microsoft Azure a try, as this is terra incognita for me ...
First need to subscribe - then get your subscriber ID. Authentication on Azure is based on client certificate, so need to create a cert file, that you then have to register on https://manage.windowsazure.com. As it took me some time to discover where to upload it, here is a screenshot :
test
➜ machine create -d azure --azure-subscription-id="c33.....ec5" --azure-subscription-cert="mycert.pem" azure INFO[0000] Creating Azure host... INFO[0072] Waiting for SSH... INFO[0161] Waiting for docker daemon on host to be available... INFO[0202] "azure" has been created and is now the active machine. Docker commands will now run against that machine. ➜ export DOCKER_HOST=`machine url` DOCKER_AUTH=identity ➜ docker run --rm -it debian bash FATA[0000] TLS Handshake error: tls: oversized record received with length 20527
wtf ? This is actually a know issue. I have the same issue running docker client 1.3.2. I'm still stuck here.
Also, provisionning Azure host took a looooong time, "Waiting for SSH". I have no idea this is just me due to some misconfiguration, or something expected on Azure. I'm used with GCE to give me SSH prompt within 10 seconds... :P #troll
Anyway, the question here is not if provider A is better than B, but the option Docker Machine offer to change provider without changing the toolchain. Assuming I have a production delivery pipeline based on Docker containers, I'd be happy I can run the same both locally and provisioning Cloud instances by whatever IaaS provider.
Isn't that cool ?
3 commentaires:
It is ;-)
At your link to known issue it says that this issue has been fixed and closed 4 days ago.
Yes, they are pretty reactive to fix issues.
Enregistrer un commentaire