Connecting to a Remote Docker - (Docker CLI in Hostmachine WIndows10); Daemon in VirtualBox Ubuntu VM

Docker Desktop
1

I have installed VirtualBox and installed Ubuntu server version in VirtualBox VM. My host machine is Windows 10.

I have also installed Docker in my host Windows box. My intention is to use the docker CLI in Windows to connect to docker daemon (server) inside the VM.

I have made the changes in the Ubuntu VM and it is listening at port 2375.

tcp        0      0 127.0.0.1:2375          0.0.0.0:*                LISTEN 2305/dockerd

Also I have set the environment variable DOCKER_HOST in my host(Windows) to the VM machine IP and port.

 set DOCKER_HOST=tcp://192.168.56.107:2375

My Windows machine IP is 192.168.56.1 and the ping is working fine.

Pinging 192.168.56.107 with 32 bytes of data:
Reply from 192.168.56.107: bytes=32 time<1ms TTL=64
Reply from 192.168.56.107: bytes=32 time<1ms TTL=64

But when I try to connect from my Windows machine, it gives the following error:

error during connect: Get http://192.168.56.107:2375/v1.27/info: dial tcp 192.168.56.107:2375: connectex: No connection could be made because the target machine actively refused it.

Please find docker info output:

controller@ubuntuserver:~$ docker info
Containers: 4
 Running: 0
 Paused: 0
 Stopped: 4
Images: 2
Server Version: 18.09.6
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: bb71b10fd8f58240ca47fbb579b9d1028eea7c84
runc version: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
init version: fec3683
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.15.0-50-generic
Operating System: Ubuntu 18.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.79GiB
Name: ubuntuserver
ID: AWDW:34ET:4J2J:2NWB:UPK7:EQHB:W64E:22AT:W6J4:BMRD:NDO6:CNR2
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
Product License: Community Engine

WARNING: API is accessible on http://127.0.0.1:2375 without encryption.
         Access to the remote API is equivalent to root access on the host. Refer
         to the 'Docker daemon attack surface' section in the documentation for
         more information: https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface
WARNING: No swap limit support

 cat /lib/systemd/system/docker.service
[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
BindsTo=containerd.service
After=network-online.target firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3

# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s

# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity

# Comment TasksMax if your systemd version does not supports it.
# Only systemd 226 and above support this option.
TasksMax=infinity

# set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes

# kill only the docker process, not all processes in the cgroup
KillMode=process

[Install]
WantedBy=multi-user.target

Can you please help me to resolve this?

2

What is the reason that you don’t use Docker Desktop? It runs its own VM in Hyper-V and they have probably solved 99 % of the problems that could arise around Windows.

3

I already tried that - but had issues in mounting volumes using Docker desktop in WIndows. Moreover, I require Linux VM for running other applications in my desktop to test. So I thought I would run docker inside the available Linux VM. Then faced this network issue (it says the connection was able to get through, but the server refused it).

Please see the following link for the details I tried:

4

Then the easiest is to solve this issues. Volume mounts work fine with Desktop when it is configured properly and Desktop is in any case the best choice if it runs on your OS.
What you try is to develop from scratch something similar to Docker Toolbox that was used on older Windows versions. It will not work. As a reference, take a look at their Github repo.

What about WSL?

5

Look at this
https://docs.microsoft.com/es-es/virtualization/windowscontainers/management/manage_remotehost