HNS failed with error : The parameter is incorrect - docker

I am making a docker containerized application using visual studio 2017.
When running docker through visual studio first, I got an error that "ERROR: client version 1.22 is too old".
This error was resolved by updating docker compose to version 2.1
Below link contains further instruction about this specific error
ERROR: client version 1.22 is too old
After this error was resolved ,On Building docker now I get "HNS failed with error : The parameter is incorrect."
From multiple github discussion I have found that it is a windows network error.
Is there a solution to this problem ?
Should I down grade docker version or install something else.
I am using windows container.
On running docker version
Client:
Version: 17.06.0-ce
API version: 1.30
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 21:30:30 2017
OS/Arch: windows/amd64
Server:
Version: 17.06.0-ce
API version: 1.30 (minimum version 1.24)
Go version: go1.8.3
Git commit: 02c1d87
Built: Fri Jun 23 22:19:00 2017
OS/Arch: windows/amd64
Experimental: true
Edit:
If I switch to linux container this problem is solved.
But another issue occurs drive is not shared.
After sharing d: drive drive sharing issue still occurs.
How can I resolve linux container drive sharing issue.
I want to use windows container locally so that I can deploy this app on azure.

This is a known limitation. At present windows only supports one NAT network. Removing Netnat by invoke Remove-Netnat is not supported.
Run this in powerhell.
Get-NetNat | Remove-NetNat

To prevent docker-compose from creating a new default network you can use the existing one by specifying it in docker-compose.yml:
networks:
default:
external:
name: nat
To check for existing networks execute
docker network ls

Open the powershell(X64) in admin mode
Execute below command
Get-NetNat
If it returns something like this
Then run below command in powershell
Remove-NetNat

Related

Docker cannot access any Internet URL during build

I have the following Dockerfile:
FROM mcr.microsoft.com/windows/servercore:ltsc2019
SHELL ["powershell", "-Command"]
RUN Invoke-WebRequest -UseBasicParsing http://www.google.com
On my Windows 10 machine, I run docker build . and get the following:
Basically, Docker is unable to access any Internet URL I try. I can run the same Dockerfile on my Windows Server 2019 Core machine and everything works fine. I'm running Docker version 18.09.2 and haven't updated it recently. This was working a few days ago, so it's a new issue. I've tried restarting the Docker engine and also rebooting. I've also tried a docker system prune. Any ideas what broke this? I'd rather not reinstall Docker if possible.
Docker Info:
Client: Docker Engine - Community
Version: 18.09.2
API version: 1.39
Go version: go1.10.8
Git commit: 6247962
Built: Sun Feb 10 04:12:31 2019
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.2
API version: 1.39 (minimum version 1.24)
Go version: go1.10.6
Git commit: 6247962
Built: Sun Feb 10 04:28:48 2019
OS/Arch: windows/amd64
Experimental: false
Update: Seems to be DNS related. I can ping things.
This is a known issue with ltsc2019 images (https://github.com/Azure/AKS/issues/1029). Put following at the start of your dockerfile or before entrypoint
Set-DnsClientServerAddress -InterfaceIndex (Get-NetAdapter).IfIndex -ServerAddresses ('8.8.8.8')

Building Docker Images on Windows Server 2016

We are looking forward to build docker images on a Windows Server 2016 Jenkins slave (though not ideal) for our microservices using a base openjdk image.
We did get Docker EE installed on Windows Server 2016 and as expected getting the below error:
PS C:\> docker pull openjdk:8
8: Pulling from library/openjdk
no matching manifest for windows/amd64 in the manifest list entries
Unlike Windows 10, i have not been able to set the daemon to switch to linux containers.
Is it possible?
How can this be done?
What issues will we be running into if we went this route?
Docker Version:
PS C:\> docker version
Client:
Version: 18.03.1-ee-3
API version: 1.37
Go version: go1.10.2
Git commit: b9a5c95
Built: Thu Aug 30 18:42:35 2018
OS/Arch: windows/amd64
Experimental: false
Server:
Engine:
Version: 18.03.1-ee-3
API version: 1.37 (minimum version 1.24)
Go version: go1.10.2
Git commit: b9a5c95
Built: Thu Aug 30 18:56:49 2018
OS/Arch: windows/amd64
Experimental: true
Windows Build:
OS Name: Microsoft Windows Server 2016 Standard
OS Version: 10.0.14393 N/A Build 14393
The error is because openjdk:8 is not a windows container.
To check this ,you can try pulling "microsoft/nanoserver" and this will work fine because it's a windows container
you can check these links for running linux containers in windows 2016 server:
https://blog.docker.com/2017/09/preview-linux-containers-on-windows/
https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/linux-containers
This is an experimental feature so not recommended for production
Another option is to use docker for windows:
https://store.docker.com/editions/community/docker-ce-desktop-windows and in the installation configuration window leave the use windows container unchecked

Docker push incredibly slow to google registry

I have Google Instance and a Google Docker Registry configured.
Things where working quite smoothly and suddenly when I try to push to the
registry, it became practically unusable because of the speed.
$ docker push gcr.io/<ID>/my-registry/image:44]
The push refers to a repository [gcr.io/<ID>/my-registry/image:44]
3bc2db43a686: Pushing [=======> ] 3.409MB/23.32MB
1302d8ee9a47: Layer already exists
29d71372a492: Layer already exists
And if I measure the bandwidth of the docker push I get
NetHogs version 0.8.1
PID USER PROGRAM DEV SENT RECEIVED
1521 root /usr/bin/dockerd ens4 24.183 0.458 KB/sec
But my actual connection to the internet is good enough.
$ speedtest-cli
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Google Cloud (x.x.x.x)...
Selecting best server based on latency...
Hosted by KamaTera INC (Santa Clara, CA) [10.61 km]: 20.436 ms
Testing download speed........................................
Download: 2046.49 Mbit/s
Testing upload speed..................................................
Upload: 114.68 Mbit/s
I tried restarting the docker daemon and nothing.
This are the tools I am using
$ docker version
Client:
Version: 17.09.0-ce
API version: 1.32
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:42:18 2017
OS/Arch: linux/amd64
Server:
Version: 17.09.0-ce
API version: 1.32 (minimum version 1.12)
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:40:56 2017
OS/Arch: linux/amd64
Experimental: false
$ gcloud version
Google Cloud SDK 176.0.0
alpha 2017.10.13
beta 2017.10.13
bq 2.0.27
core 2017.10.13
gsutil 4.27
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
Any idea what could be the problem?
Use gcloud builds submit instead of docker push
Docs: https://cloud.google.com/sdk/gcloud/reference/builds/submit
I tried using docker push to get images to GCR, but it was incredibly slow and would eventually grind to a halt. I then started using GCE instances to docker push from, which was very fast. Later, I stumbled upon gcloud builds submit. It runs fast locally for me.

Docker Compose (docker-compose) couldn't connect to docker daemon on Windows Server 2016 TP5

I am trying to get docker-compose to work on Windows Server 2016 TP5. I have installed Docker Desktop for Windows (not Docker Toolbox) as a service, which works perfectly. I have downloaded the latest docker-compose for windows from https://dl.bintray.com/docker-compose/master/ and put it in the same path as Docker (after unblocking the downloaded file, and renaming it to docker-compose.exe.
When I run the docker-compose up (in Powershell as an Administrator), I get the following error:
ERROR: Couldn't connect to Docker daemon. You might need to install
Docker:
https://docs.docker.com/engine/installation/
Here are the docker and docker-compose information on my machine:
Docker:
Client:
Version: 1.12.1
API version: 1.24
Go version: go1.6.3
Git commit: 23cf638
Built: Thu Aug 18 17:52:38 2016
OS/Arch: windows/amd64
Server:
Version: 1.12.1
API version: 1.24
Go version: go1.6.3
Git commit: 23cf638
Built: Thu Aug 18 17:52:38 2016
OS/Arch: windows/amd64
Docker Compose:
docker-compose version 1.9.0dev, build f65f89a
You might want to try to set your DOCKER_HOST:
$ENV:DOCKER_HOST="npipe://\\.\pipe\docker_engine"
Alternatively, when registering the engine, you can make it listen on TCP too:
dockerd.exe -H npipe:////./pipe/docker_engine -H localhost:2375 --register-service
There are more details on this Compose issue

How to override the default value of COMPOSE_HTTP_TIMEOUT with docker-compose command

I have docker-compose which fetches some of the images and builds one.
When I run docker-compose up , I am getting the following error
ERROR: An HTTP request took too long to complete. Retry with --verbose
to obtain debug information. If you encounter this issue regularly
because of slow network conditions, consider setting
COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).
Question: How to pass the COMPOSE_HTTP_TIMEOUT with docker-compose command?
COMPOSE_HTTP_TIMEOUT is an environment variable, so
COMPOSE_HTTP_TIMEOUT=200 docker-compose up
You need your COMPOSE_HTTP_TIMEOUT at your docker instance level (docker-compose up) and not inside your docker image. So the solution is to create a .env file and put this inside:
#.env
COMPOSE_HTTP_TIMEOUT=200
you can check the doc here
For Mac users, restarting docker from the status bar icon fixed this issue:
restart the docker
command: sudo service docker restart
then try docker-compose up
I faced this issue recently. Even after overriding the default COMPOSE_HTTP_TIMEOUT value it did not work for me.
Possible cause As mentioned in documentation Compose CLI environment variables
COMPOSE_HTTP_TIMEOUT: Configures the time (in seconds) a request to the Docker daemon is allowed to hang before Compose considers it failed. Defaults to 60 seconds.
Removing the tty:true from my docker-compose worked for me.
More details on the issueCompose error "HTTP request took too long to complete" #3633
Docker Environment details:
$ docker-compose version
docker-compose version 1.18.0, build 8dd22a9
docker-py version: 2.6.1
CPython version: 2.7.13
OpenSSL version: OpenSSL 1.0.1t 3 May 2016
$ docker version
Client:
Version: 18.09.1
API version: 1.39
Go version: go1.10.6
Git commit: 4c52b90
Built: Wed Jan 9 19:35:01 2019
OS/Arch: linux/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 18.09.1
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 4c52b90
Built: Wed Jan 9 19:06:30 2019
OS/Arch: linux/amd64
Experimental: false
Add this one in .env file: COMPOSE_HTTP_TIMEOUT=1000
I had faced similar issue as below:
Quick Solution is, to restart your VM
sudo su - root
reboot -f
Then login again after 5-10 mins and check. It should work now!
Open terminal and type following command
COMPOSE_HTTP_TIMEOUT=200
To verify type
echo $COMPOSE_HTTP_TIMEOUT
Output: 200

Categories

Resources