After update to docker-machine, I have no idea how to update DOCKER_OPTS in a local boot2docker docker-machine and save it permanently
$ docker-machine ls
NAME ACTIVE DRIVER STATE URL SWARM
dev * virtualbox Running tcp://192.168.99.100:2376
I tried to ssh into vm with docker-machine ssh dev, and update /etc/docker/default. But the changes I made are dropped after restart VM with docker-machine restart dev.
If you'd simply like to pass arguments to docker, add them to EXTRA_ARGS in /var/lib/boot2docker/profile. For example:
EXTRA_ARGS='
--label provider=virtualbox
--insecure-registry=10.0.0.1:5000
'
The docker process is started via /etc/init.d/docker which sources /var/lib/boot2docker/profile. $EXTRA_ARGS is passed transparently to the docker process towards the end of start().
As of docker-machine 0.5.0, the mirror can be provisioned with --engine-registry-mirror
docker-machine create -d virtualbox --engine-registry-mirror http://mirror.dockerhub.com dev
--engine-registry-mirror [--engine-registry-mirror option --engine-registry-mirror option] Specify registry mirrors to use
Related
When I use docker-machine in a Windows environment (installed with docker-toolbox), every docker run command uses that docker-machine as the docker daemon.
However, when I use docker-machine in a Linux environment, which has native docker daemon installed along with docker-machine, docker run command uses native docker daemon even if there is a running docker-machine instance.
Questions are:
How does docker run command decide which daemon to use?
Are there any method to list running containers on a docker-machine instance?
For the second one, I know I can SSH to the docker-machine instance and query docker ps in it, but I want check it from outside the instance.
Thanks in advance.
The Docker Machine stack works by firing up a VM, and then setting the DOCKER_HOST environment variable to point at it. In particular, it also does the required setup to TLS-encrypt the connection and to set up a TLS client certificate to authenticate the caller. (Without this setup, a remote DOCKER_HOST is extremely dangerous.)
So: docker run and every other Docker command uses the DOCKER_HOST environment variable to decide where to run things. If DOCKER_HOST points at a Docker Machine VM, docker ps will list the containers there; you won’t usually need to docker-machine ssh (though it’s a useful tool when you really need it).
On a native Linux host it’s far easier to just directly use a local Docker daemon. If you do have both a local daemon and a docker-machine VM, you can
# switch to the Docker Machine VM
eval $(docker-machine env default)
# switch back to the host Docker
eval $(docker-machine env -u)
I am running minikube using the instructions at
https://kubernetes.io/docs/tutorials/hello-minikube/
I started minikube:
$ minikube start --vm-driver=hyperkit
and verified that it is successfully running.
I am running 'Docker Community Edition' version 18.06.1-ce-mac73.
$ minikube ssh
is working fine.
However when I do
$ docker ps
on my mac os host, it doesn't show any containers. However, when I do
$ docker ps
after doing minikube ssh, I see about 20 containers.
So, where are the docker containers really running? Why does docker ps not show any containers on my mac?
Thank you.
You can use the following command to configure your Docker Host address:
eval $(minikube docker-env)
Then, when you run docker ps, you should see your containers. Read more here.
Docker containers are not running on your MAC host.
They are running on a VM where you can do minikube ssh to that VM.
The docker ps shows the containers in there inside that VM.
That's expected because you are using hyperkit driver to work as a hypervisor & launch lightweight virtual machines. Think of it as virtualbox launching VMs for you & complete k8s cluster is deployed into those VMs, all of them are well integrated.
Use below to get your virtual machine address or the server where these containers are actually running -
$ minikube ip
Ref -
https://github.com/moby/hyperkit
Since I can't add a comment:
To revert the change in your shell, use
eval $(minikube docker-env -u)
as answered here: How do I undo the command $ eval "$(docker-machine env blog)"
I am new in using docker and I am trying to implement SWARM according to this tutorial -
https://docs.docker.com/get-started/part4/#create-a-cluster
The tutorial starts with -
Launch Hyper-V Manager
Click Virtual Switch Manager in the right-hand menu
Click Create Virtual Switch of type External
I am using Windows 10 PRO and I cannot use Hyper-V Manager and Docker terminal at the same time. Because if I activate Hyper-V and then start docker terminal, my PC shows an error and shut down automatically.
So, I tried to create a virtual machine without Hyper-V by following code
$ docker-machine create -d hyperv --hyperv-virtual-switch "myswitch" myvm1
and as expected I got this error -
Wrapper Docker Machine process exiting due to closed plugin server (connection is shut down)
Error with pre-create check: "read tcp 127.0.0.1:50588->127.0.0.1:50587: wsarecv: `An existing connection was forcibly closed by the remote host."`
So, is there any alternative solution how can I proceed or to use Hyper-V Manager in Windows 10 without such problem.
Thanks a lot for your time :)
Virtualbox and Hyperv don't work together. Since you are using docker quickstart terminal you should be using VirtualBox for the VM
$ docker-machine create -d virtualbox swarmanager1
$ docker-machine create -d virtualbox nodes1
$ docker-machine create -d virtualbox nodes2
Once done you switch to manager node
$ eval $(docker-machine env swarmanager1)
$ docker swarm init --advertise-addr eth0
This will give you a token command and you need to execute them for each node
$ eval $(docker-machine env nodes1)
$ docker <swarm command from manager>
When I create a node with docker-machine
docker-machine create -d virtualbox node1
it is created with tls verification enabled for docker deamon which made things a bit more of a hassle than normal for swarm.
I want to create a node with docker-machine without tls verification for testing purpose.
I tried with:
docker-machine create -d virtualbox --engine-tls false node1
and
docker-machine create -d virtualbox --engine-tls-verify false node1
and
docker-machine create -d virtualbox --engine-opt-tls false node1
I use commands below:
docker-machine create -d virtualbox --engine-env DOCKER_TLS=no node1
And then ssh to the node to execute docker commands:
docker-machine ssh node1
$ docker info
try:
docker-machine create -d virtualbox --engine-opt tlsverify=false node1
and after running:
eval "$(docker-machine env node1)"
run:
unset DOCKER_TLS_VERIFY
This worked best for me:
docker-machine create -d virtualbox --engine-env DOCKER_TLS=no --engine-opt host=tcp://0.0.0.0:2375 node1
This way it binds to 2375 in addition to 2376. 2375 is the tradition for non-tls daemons.
I have Docker installed and it runs fine, but when I have created a container and run it, I want to know the ID of the container, so I do a docker ps. But then I always get this message:
Get http:///var/run/docker.sock/v1.15/containers/json: dial unix /var/run/docker.sock: no such file or directory
What could be wrong here?
Make sure you export the docker environment variables:
where it says
after you run
boot2docker start
and it says:
To connect the Docker client to the Docker daemon, please set:
export DOCKER_CERT_PATH=/Users/jbielick/.boot2docker/certs/boot2docker-vm
export DOCKER_TLS_VERIFY=1
export DOCKER_HOST=tcp://192.168.59.103:2376
You need to export those variables. Check that they are empty with
echo $DOCKER_HOST
and if it's blank, docker can't talk to your VM.
make sure boot2docker is running:
$boot2docker start
make sure docker host variable is exposed:
# Will print boot2docker VM IP
boot2docker ip
The VM's Host only interface IP address is: 192.168.59.103
# Set docker host variable with value from previous command
export DOCKER_HOST tcp://192.168.59.103:2375
Check if the docker daemon is running on the boot2docker host
boot2docker ssh
ps aux | grep docker
/usr/local/bin/docker -d ....
If you are running on Linux make sure you are running as root user