I just installed docker on windows 10
I can run the following command docker version so docker must be working
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 0520e24302
Built: Fri Mar 23 08:31:36 2018
OS/Arch: windows/amd64
Experimental: false
Orchestrator: swarm
If a create a new dotnet core project from within Visual studio the project builds fine and runs the code inside the container. (I think that is the correct terminology)
So, I tried to add an existing project to docker. Basically, all I did was right click on the .sln and added docker support.
But if I try to run the project I get the following error
error during connect: Get https://192.168.99.100:2376/v1.37/version:
dial tcp 192.168.99.100:2376: connectex: A connection attempt failed
because the connected party did not properly respond after a period of
time, or established connection failed because connected host has
failed to respond.
How can I fix it?
I tried running simple commands in PowerShell but that seems to give the same error. (docker version)
how can the new project connect to 192.168.99.100:2376 and not the existing one that I added the dockerfile to?
Open powershell
cd to the directory with the dockerfile
run:
docker build -t myapp .
when that's done run:
docker run --rm -d --name myapp -p 8080:8080 myapp
open browser to localhost:8080
Related
New to Docker / containers. Everything I've read and watched online shows that Docker for Windows "just works" with Visual Studio by adding the DockerFile to the project, and away it goes. I have a default/generated MVC .Net 6 (core) application (I added no logic of my own), and it runs just fine under the "IIS Express" mode. When I select the "Docker" mode, it appears to build ok, but then it times out when it tries to open the app in the browser. First it pops up a message in Visual Studio saying, "A remote operation is taking longer than expected", then another message pops up in Visual Studio saying, "The network connection to XXX.XX.XXX.XXX:XXXX has been lost. Debugging will be aborted". When I click OK, it opens a browser window (Chrome) to url http://localhost:0/. Turning off the firewall didn't help.
I've placed the "Container Tools" output from VS at the end of this description.
I left the DockerFile code itself as-is from what is generated by VS:
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["testingDocker.csproj", "."]
RUN dotnet restore "./testingDocker.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "testingDocker.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "testingDocker.csproj" -c Release -o /app/publish
#/p:UseAppHost=false
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "testingDocker.dll"]
I have pulled a couple other sample images from Docker (e.g., "markheath/samplewebapp:windows" and "kgpkgp/samplewebapp:latest"), ran each of them, mapping the desired ports, e.g.,
docker run -d -p 8081:80 --name ContainerName ImageName:TagName ping -t localhost
...and then opened them in the browser successfully, e.g.,
http://localhost:8081/
I have used various host ports with success for these pulled images, so I think I can rule out network and firewall issues.
When I look at the Docker Desktop display, the "testingdocker" image is there, and the "testingDocker" container is there, but stopped with a status of "EXITED (4294967295)". The "Open with browser" option does not appear under the ellipsis button. When I try to create a new container from the existing image using the command line (docker run -d -p 8083:80....), the container successfully is created and runs, and the "Open with browser" option is available; when I select it, the browser opens to http://localhost:8083/ but fails to load, displaying message "localhost took too long to respond" (ERR_CONNECTION_TIMED_OUT). I've second-guessed (and third-guessed, etc) everything. Any advice on what might be wrong here?
EDIT: I randomly discovered that if I ran it in Release mode (as opposed to Debug mode), it behaves as expected (i.e., runs in the browser, runs in Docker), which is a great step forward. Of course, being in Release mode, I can't actually debug the code, whereas all of the demos out there show that you can be in Debug and step through the code. I'm still in need of getting it to run in Debug. I tried changing the keyword "Release" to "Debug" in the Dockerfile hoping that would be the issue, but it made no difference.
"Container Tools" output from VS:
========== Checking for Container Prerequisites ==========
Verifying that Docker Desktop is installed...
Docker Desktop is installed.
========== Verifying that Docker Desktop is running... ==========
Verifying that Docker Desktop is running...
Docker Desktop is running.
========== Verifying Docker OS ==========
Verifying that Docker Desktop's operating system mode matches the project's target operating system...
Docker Desktop's operating system mode matches the project's target operating system.
========== Pulling Required Images ==========
Checking for missing Docker images...
Pulling Docker images. To cancel this download, close the command prompt window.
docker pull mcr.microsoft.com/dotnet/aspnet:6.0
Docker images are ready.
========== Warming up container(s) for testingDocker ==========
Starting up container(s)...
docker build -f "C:\J\testingDocker\testingDocker\Dockerfile" --force-rm -t testingdocker:dev --target base --label "com.microsoft.created-by=visual-studio" --label "com.microsoft.visual-studio.project-name=testingDocker" "C:\J\testingDocker\testingDocker"
Sending build context to Docker daemon 8.199MB
Step 1/5 : FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
---> 1eaec0f2abb1
Step 2/5 : WORKDIR /app
---> Running in d3b72aeec68e
Removing intermediate container d3b72aeec68e
---> 3f573ca3d231
Step 3/5 : EXPOSE 8080
---> Running in a880a99ebd54
Removing intermediate container a880a99ebd54
---> 22255aa22f3f
Step 4/5 : LABEL com.microsoft.created-by=visual-studio
---> Running in 58b503e11d66
Removing intermediate container 58b503e11d66
---> 41c0305f94a5
Step 5/5 : LABEL com.microsoft.visual-studio.project-name=testingDocker
---> Running in 3dea4d690e3c
Removing intermediate container 3dea4d690e3c
---> d05c6888e64f
Successfully built d05c6888e64f
Successfully tagged testingdocker:dev
Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
docker rm -f 2319c1e877821720d122cd45ee01c27cabf410acee68d41528e691a19e1bc8c5
2319c1e877821720d122cd45ee01c27cabf410acee68d41528e691a19e1bc8c5
docker run -dt -v "C:\Users\James\onecoremsvsmon\17.3.10630.1389:C:\remote_debugger:ro" -v "C:\J\testingDocker\testingDocker:C:\app" -v "C:\J\testingDocker\testingDocker:c:\src" -v "C:\Users\James\.nuget\packages\:c:\.nuget\fallbackpackages2" -v "C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages:c:\.nuget\fallbackpackages" -e "ASPNETCORE_LOGGING__CONSOLE__DISABLECOLORS=true" -e "ASPNETCORE_ENVIRONMENT=Development" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -e "NUGET_PACKAGES=c:\.nuget\fallbackpackages2" -e "NUGET_FALLBACK_PACKAGES=c:\.nuget\fallbackpackages;c:\.nuget\fallbackpackages2" -P --name testingDocker_1 --entrypoint C:\remote_debugger\x64\msvsmon.exe testingdocker:dev /noauth /anyuser /silent /nostatus /noclrwarn /nosecuritywarn /nofirewallwarn /nowowwarn /fallbackloadremotemanagedpdbs /timeout:2147483646 /LogDebuggeeOutputToStdOut
51a6d9e31decdc7adf618d8cadbe09ef26e3aa19c13a7d63f13353761a333f89
Container started successfully.
========== Finished ==========
You can try below methods:
Check whether you have used networking security software. You can disable or close those application.
You can use DebugDiag Tools to monitor devenv.exe and msvsmon.exe, and collect the dump files.
Switched to m1 mac a week ago and I cannot get my application up and running with docker because of the jboss/keycloak image not working as expected. Getting the following message from the container when trying to access localhost:8080
12:08:12,456 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.network.interface.private: org.jboss.msc.service.StartException in service org.wildfly.network.interface.private: WFLYSRV0082: failed to resolve interface private
12:08:12,526 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("interface" => "private")]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.network.interface.private" => "WFLYSRV0082: failed to resolve interface private"}}
12:08:13,463 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: Keycloak 12.0.4 (WildFly Core 13.0.3.Final) started (with errors) in 20826ms - Started 483 of 925 services (54 services failed or missing dependencies, 684 services are lazy, passive or on-demand)
Tried with all image versions and all behave the same. Has anyone managed to run this image without issues? Thanks
Also you can build the keycloak docker image locally, I was able to start keycloak after doing that. Here are the steps I follow;
Clone Keycloak containers repository: git clone git#github.com:keycloak/keycloak-containers.git
Open server directory (cd keycloak-containers/server)
Checkout at desired version, eg. git checkout 12.0.4
Build docker image docker build -t jboss/keycloak:12.0.4 .
Run Keycloak docker run --rm -p 9080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin jboss/keycloak:12.0.4
Using this image, I am now able to startup keycloak. https://hub.docker.com/r/wizzn/keycloak
For Keycloak 16, docker 20.10 and docker-compose 1.29, this image works flawlessly: https://hub.docker.com/r/sleighzy/keycloak - as suggested by #zakjan.
A service like:
keycloak:
image: sleighzy/keycloak
environment:
... your Keycloak config
Should be enough to get up and running.
I'm on an m1 and I ran this and it worked.
docker run --platform=linux/amd64 -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:17.0.0 start-dev
I merely add --platform=linux/amd64 to their docker command I found in https://www.keycloak.org/getting-started/getting-started-docker
The location for building a quarkus version of keycloak has changed, so this method will not work anymore for any major releases greater than 16. But the following script will. Just save it as an sh. file and execute it in your terminal. By enabling the last line, this will also directly start an instance of Keycloak.
The version number can be changed, but this is only tested for M1 chips and version 17.0.0.
VERSION=17.0.0 # set version here
cd /tmp
git clone git#github.com:keycloak/keycloak.git
cd keycloak/quarkus/container
git checkout $VERSION
docker build -t "quarkus-keycloak:$VERSION" .
#docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin "quarkus-keycloak:$VERSION" start-dev --http-relative-path /auth
There is an update to this issue - images for AMD64 and ARM64 architectures are now available and can be found here: https://quay.io/repository/keycloak/keycloak?tab=tags.
Ref the discussions in Github (https://github.com/keycloak/keycloak-containers/issues/341 and https://github.com/keycloak/keycloak/issues/8825).
jboss/keycloak not supported arm64 for now.
But you can use that image on docker hub: mihaibob/keycloak
https://hub.docker.com/r/mihaibob/keycloak
I'm using this and haven't difference.
I don't have a mac but I just started working with jboss/keycloak lately and have been able to get it to start.
Essentially what I did (assuming docker is installed):
docker pull jboss/keycloak:16.1.0
docker run --env-file targetDB.txt -p 8080:8080 jboss/keycloak:16.1.0
Might have to do those commands with sudo
This pulls the jboss/keycloak image from docker hub and then it runs it exposing the port 8080 within the container to the host machine. It also uses the environment variables in the .txt file (which contains info on the database endpoint you wish to connect keycloak to to persist data).
If you don't specify --env-file <text file> I believe keycloak uses its default h2 Database which isn't the best.
I have my local jboss/keycloak pointing to an postgres db I have in an AWS RDS environment, so the contents of the targetDB.txt for me is:
DB_VENDOR=postgres
DB_ADDR=<my postgres aws rds endpoint>:5432
DB_DATABASE=<name of the database>
DB_USER=<db username to connect to postgres instance>
DB_PASSWORD=<password associated with db username to connect>
If I'm not mistaken the name of the Database in DB_DATABASE field must already exist. So you'll need to create that before running the docker run command.
After you do the docker run command above and the logs show it starting up you should be able to access the keycloak admin console on your local browser:
http://localhost:8080/auth
If this is the first time you're running keycloak you have to create a master/admin user before you can log in.
To add a master user, run these commands (while your keycloak is already running):
docker exec <container id or container name> /opt/jboss/keycloak/bin/add-user-keycloak.sh -u <USERNAME> -p <PASSWORD>
then you need to restart your keycloak container:
docker restart <container id or container name>
Again you might have to do those commands with sudo.
After thats done, go back to your local web browser http://localhost:8080/auth and you can now access the login page and actually login with the username and password you created above.
i got this error on windows server 2019 standard running docker and no idea how to solve it. Running windows container with process isolation. Memory is always max 40% (32Gb), CPU always below 20% and disks lot of space (250Gb free).
Running an official container like : docker run -d --rm -p 8080:80 --name test mcr.microsoft.com/dotnet/core/samples:aspnetapp
Got this error after extracting phase and start of container :
C:\Program Files\Docker\docker.exe: Error response from daemon: CreateComputeSystem ba698710f7bff4d46dce2ee65453b9da143195770b93cf82f8bb3818fca70174: Insufficient system resources exist to complete the requested service. (extra info: {"SystemType":"Container","Name":"ba698710f7bff4d46dce2ee65453b9da143195770b93cf82f8bb3818fca70174","Owner":"docker","VolumePath":"\\\\?\\Volume{61d19b2c-50e1-4dd5-9257-9c67998f1123}","IgnoreFlushesDuringBoot":true,"LayerFolderPath":"C:\\ProgramData\\docker\\windowsfilter\\ba698710f7bff4d46dce2ee65453b9da143195770b93cf82f8bb3818fca70174","Layers":[{"ID":"05435bc5-50b1-5044-9210-12d7ab180470","Path":"C:\\ProgramData\\docker\\windowsfilter\\84fc4324bf3d2de92b5f9c0a80e238bc3b3f1fdbe0fea13b7a35146069c21663"},{"ID":"3f1c6cd1-b66d-5d8d-aa2e-d11e489b74fe","Path":"C:\\ProgramData\\docker\\windowsfilter\\11d9c87c3490cf087488aaf21a3c88b45c68273ea270c6f850261583715cf241"},{"ID":"655918d6-84bb-5633-8bb2-981f3a29e3c6","Path":"C:\\ProgramData\\docker\\windowsfilter\\1f11a5340a1c13ef658355b9e30f7794ee398fb863105d6e18b48bd8a4687f79"},{"ID":"41893d4a-0704-50df-8f4e-41cad4480d3e","Path":"C:\\ProgramData\\docker\\windowsfilter\\36296cba828c68663184ddd5e75f5084ce59b755fcc9025845fe516782b2e243"},{"ID":"dc4a1317-f05d-5470-847d-d1e4bd029e6d","Path":"C:\\ProgramData\\docker\\windowsfilter\\8293bbc58e2c9c7da089187afd6cbf0e22b1bcb27cadc3e569542e324733ef82"},{"ID":"6f247d11-4160-56dc-9dbe-b40a4b67d151","Path":"C:\\ProgramData\\docker\\windowsfilter\\d9ba1e3f6cffcc5f69e2d2265a7539a0e4aff9b4f8f86e3edc3ff5b4026a584b"},{"ID":"5f54a86d-b6e0-5f1c-977d-dc7bba046d7e","Path":"C:\\ProgramData\\docker\\windowsfilter\\9beb006814b54bda1f7afa7a0f2870a4a970ef624ab6d2bffec4e27f2b749d6e"},{"ID":"03a39db9-584f-5d5b-8bbc-95883aa2af8b","Path":"C:\\ProgramData\\docker\\windowsfilter\\38ad1eb3b36d16eb77e6264daca47fad96080cb9596aa6aeb8c6d269ffbead89"},{"ID":"bffe53fb-2619-5d30-ae46-da6f759a87ed","Path":"C:\\ProgramData\\docker\\windowsfilter\\d4b5eaee9002c7b73dd7a72880c9caa3a39b7ef5c304b19e7c0a732c01b2a4bb"},{"ID":"aaec8c93-d215-59d6-99e2-001f38fa3ee3","Path":"C:\\ProgramData\\docker\\windowsfilter\\34ccac695ab1683cc21309e94c64110476d45b07b69b6956da9e795c31f6b815"}],"HostName":"ba698710f7bf","HvPartition":false,"EndpointList":["9070F572-5CDD-4CCE-8C7E-218F0BA2F221"],"AllowUnqualifiedDNSQuery":true}).
Server: Docker Engine - Enterprise
Engine:
Version: 18.09.11
API version: 1.39 (minimum version 1.24)
Go version: go1.12.12
Git commit: 6112046bc9
Built: 11/13/2019 07:49:53
OS/Arch: windows/amd64
Experimental: false
Go to registry,
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\NDIS\IfTypes\24
and set ifUsedNetLuidIndices to 01
and then restart the computer.
I have docker installed on Windows Server 2019 Datacenter.
This is the Docker info:
Client: Docker Engine - Community
Version: 19.03.5
API version: 1.40
Go version: go1.12.12
Git commit: 633a0ea
Built: Wed Nov 13 07:22:37 2019
OS/Arch: windows/amd64
Experimental: false
I would like to have docker start automatically whenever the server starts, but i consistently get this message at startup:
Service is not running
Docker Desktop service is not running, would you like to start it? Windows will ask you for elevated access.
in order to start docker, i will have to press start manually through the GUI, but i would like to automate this process.
I have already tried:
-Logging in with my account on this machine
-Put docker shortcut at shell:startup folder
Thanks.
I found that using
"net start com.docker.service" before starting the docker.exe process works.
Here's the Original Command after initial solution search on web. I tried various combinations of using the slash (/) in vain:
winpty docker run --privileged --rm -it -v '//c//temp//git//distributions//cache://root//.gradle' --mount type=bind,source=//c//temp//git//distributions,target=//distdestiny_server.in.systems.com/x86/p83-buildenv './gradlew'
C:/Program Files/Docker Toolbox/docker.exe: Error response from daemon: OCI runtime create failed: container_linux.go:344: starting container process caused "exec: \"./gradlew\": stat ./gradlew: no such file or directory": unknown.
After further search on web, I used bind-mounts and propogation options with various combinations, but ended up with this error:
winpty docker run --privileged --rm -it --mount type=bind,source=//c//temp//git//distributions//cache,target=//root//.gradle --mount type=bind,source=//c//temp//git//distributions,target=/dist,bind-propagation=shared destiny_server.in.systems.com/x86/p83-buildenv './gradlew'
C:/Program Files/Docker Toolbox/docker.exe: Error response from daemon: linux mounts: path /c/temp/git/distributions is mounted on / but it is not a shared mount.
Another option I came across is MountFlags. However, the docker documentation only mentions it but doesn't say where to specify it. I couldn't find a way to specify it on the cmd. lines. I find references on the web to some files such as Dockerfile, docer.service, etc. However, I am unable to find any of these files on my system. Is it necessary that I should create swarm to get these files? The only last option I have is to use MountFlags but don't know how and where to specify it.
Docker details: I have just now upgraded docker Client from 17.07.0-ce to 18.03.0-ce on my desktop as I type this content. Still I have the same issue reported.
From Docker Quickstart Terminal:
$ docker version
Client:
Version: 18.03.0-ce
API version: 1.37
Go version: go1.9.4
Git commit: 0520e24302
Built: Fri Mar 23 08:31:36 2018
OS/Arch: windows/amd64
Experimental: false
Orchestrator: swarm
Server: Docker Engine - Community
Engine:
Version: 18.09.3
API version: 1.39 (minimum version 1.12)
Go version: go1.10.8
Git commit: 774a1f4
Built: Thu Feb 28 06:40:51 2019
OS/Arch: linux/amd64
Experimental: false
Any help in this regard is much helpful. Thanks.
Using docker on windows is fraught with problems relating to paths. It looks like you're falling down one of these rabbit holes. Assuming .gradle is a directory (it is on my machine):
The way I have solved this is using docker volumes: volumes are different from the drive mapping you're currently using as the files will not appear on the host filesystem, but they are persistent across container executions, which is often sufficient. For example, I have a /git directory mounted from a volume in all my dev tools use that to get hold of source code that has been cloned from git. If you need to access these files outside docker, then a volume can be awkward, but if you only used gradle inside a container and never on the host, then you could map your .gradle directory to a volume and simply reuse it across different containers.
Before you do this though, it is a good idea to explicitly create a volume with:
docker volume create gradle
There are various techniques that will implicitly create volumes, but personally, I like to be explicit because of the principle of least surprise.
The syntax to mount the volume is similar to the one you used above, but we simply name the volume on the left-hand side of the volume switch:
docker container run -it --rm -v gradle:/root/.gradle/ ...
There may be another problem in your docker run command though. At the end, you pass the string './gradlew'. You're assuming that this is in the working directory, which could be a problem if the working directory isn't what you think it is. To ensure this doesn't happen, you should state the working directory using the -w <dir> switch. Something like:
docker container run -it --rm -w /root /v gradle:/root/.gradle/