I'm having a docker application that writes to the local filesystem on a windows machine.
When I run/debug the application from Visual Studio it works, but when I then run the image in docker I get "Could not find part of the path". And that is usually an indication of insufficient rights to write in that folder.
But now I'm confused, is it not in both circumstances using my credentials?
Anyway in an attempt I have tried to give everyone full control, but still the same error.
Aha, it turns out to be that when I do the docker run command I have to use the -v parameter
Like this:
docker run --rm -it -v c:\hostcontainershare:c:\containertmp myconsoleapplication ".NET Framework App Writing to Host Folder" 1
I found the explanation here: https://msdn.microsoft.com/en-us/magazine/mt814415.aspx
And when you run it from Visual Studio, it apparently does that automatically for you.
Related
I had been trying to create a context to deploy a few containers from my main Mac to another another but I have been getting a weird error.
So, I have two Macs, one iMac (Late 2013) (here will be called Enterprise) and one Macbook Pro (Mid 2015) (here will be called Defiant). Defiant is my main computer and I want to deploy my container to Enterprise in order to not overload Defiant memory. I have been working with docker context to achieve that. Currently, I have Enterprise running Docker v20.10.16 and Defiant running v20.10.16.
I have created the context on Defiant and after I run the docker context use enterprise and when I run docker container ls I get the following error:
error during connect: Get "http://docker.example.com/v1.24/containers/json": command [ssh -l rafaelguerra -- Enterprise.local docker system dial-stdio] has exited with exit status 127, please make sure the URL is valid, and Docker 18.09 or later is installed on the remote host: stderr=zsh:1: command not found: docker
Does anyone know how to make it work?
Thanks
UPDATE:
Weird thing I just found out, when logged into Enterprise and run echo $PATH returns /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin however when I run ssh rafaelguerra#enterprise.local 'echo $PATH' I got the following /usr/bin:/bin:/usr/sbin:/sbin
I don't have a clue for a reason for this.
I found the reason for the problem, all commands docker run are run within ssh not with a permanent ssh session. So, zsh does not load the correct PATH when the command is run within the ssh. Therefore, the only thing I need to do was setting the correct PATH inside of the ~/.zshenv file and everything is working now.
Setup:
Ubuntu 20.04 distro running inside WSL2 (5.4.72-microsoft-standard-WSL2)
VS Code version 1.55.2 installed in Windows
Docker version 19.03.8, build afacb8b7f0 installed in WSL2
docker-compose version 1.29.0, build 07737305 installed in WSL2
Remote-Containers Extension for VS Code v0.166.1 installed locally (I could not find an option to explicitly install this inside WSL2, but I am not sure if this even matters, see below)
Original error:
When I open the command palette and enter Remote-Containers: Rebuild and Reopen in Container, I get the error `The 'docker' command was not found. Make sure Docker is installed' in a pop up window.
What I tried:
Attempt 1
First, I thought that the Remote-Containers extension wants to execute the docker commands inside windows and not WSL2. Since I don't have Docker Desktop installed on Windows, it is impossible to execute docker commands in Windows. So I tried downloading a specific version of the the Remote-Containers extension file from the marketplace v0.165.0 I believe, copying it into the VS extension folder inside WSL2 /home/kevinsuedmersen/.vscode-server/extensions and installing it manually from the VS Code Extension panel. However, this also installed the Remote-Containers extension locally, so probably on Windows. I am not sure if locally means that this extension is available globally, but nevertheless, I am still getting the error that the docker command is not found as explained above.
Attempt 2
I notice that when I open a PowerShell on Windows, I can use the docker daemon inside WSL2 by prepending wsl to all docker commands, e.g. wsl docker run hello-world. So, I went to the VS Code and in settings (Settings > Remote > Containers > Docker Path), I changed the docker path from docker to wsl docker, but then, I got this error Docker Desktop WSL 2 backend required. This is even the case on another laptop, where I actually have Docker Desktop installed and the WSL2 backend enabled.
Attempt 3
I tried changing the docker path in VS code to the full path of the docker socket in WSL2 /var/run/docker.sock, but then I got the error Current user does not have permission to run 'docker'. Try adding the user to the 'docker' group. My current user kevinsuedmersen is already member of the docker group.
Any advice or directions are greatly appreciated.
Answer was given on the GitHub Repo of the VS-Remote-Container Extension here: https://github.com/microsoft/vscode-remote-release/issues/4914
I've created a .net core web api project and am successfully running it under Docker Desktop for Window. It works fine as long as I'm running the project in Visual Studio. I run the "Docker" profile and hit it with localhost:8000/. I've configured it to use port 8000...
But when I stop the visual studio debugger, I can no longer access it even though when it still shows up as "RUNNING" in Docker Desktop. How can I access the service in the container, without running the project in Visual Studio?
I'm a newbie in this area, but if an image has been built and that image is running in a container, I'd think I'd be able to access it without needing to run the visual studio project. Isn't the container a "compiled, built, stood-up instance of my image, running in a docker host"???
Thanks, Brent
"Isn't the container a "compiled, built, stood-up instance of my image, running in a docker host"???" Yes, it is, you're 100% right, but in the Visual Studio, they made some performance adjustments so everything can run so smoothly, without any overhead of stopping and removing the container, updating the image and running it etc. In fact, under the hood, your binaries and source code are mapped via volume, so there's no need to juggle building new images etc. every time you run the app. If you run docker inspect on the container created by the Visual Studio, you'll be able to see that that mapping in the "Mounts" section of the JSON output.
I created a brand new ASP.NET Core web API app from the template with Docker enabled. I noticed that the container lifetime is linked with the Visual Studio process. If I close the Visual Studio the container is stopped and removed and as soon as I open the solution with the previously mentioned project in the Visual Studio the container is immediately up and running even though I haven't even started debugging yet.
If you want to run a container outside of the Visual Studio, you can always build the image from the Dockerfile in your project and run it.
It could look like this:
cd "path/with/your/Dockerfile"
docker build -t "your-image-name" .
docker run -it -p 8000:80 -n "your-container-name" "your-image-name"
I am trying to develop in a remote container.
I run VS Code on my local windows machine.
I have a linux machine which runs docker and a bunch of containers.
I have the "Remote - Containers" and "Remote - SSH" extensions installed in VS Code.
I can connect to my linux machine in VS Code and I can see the running containers.
I can right click on a container and choose "Attach Shell". This works fine:
When I right click on a container and choose "Attach Visual Studio Code" I get an error:
UPDATE
The above error was raised because (for some reason?) docker must be running locally on windows also even though we are fully on a remote machine. I've installed and run docker locally.
Now when I right click on a running container, I get a different error:
Of course the containers are running -- I see them.
How can I Attach Visual Studio Code to a running remote container successfully?
This may not be a real answer but it's too much for a comment.
I believe you have a local machine and docker on a remote server.
The first thing you have to do is to install docker on your local machine and configure it so that's its looking for the docker host on your remote server.
Then you can create a .devcontainer.json on your machine. If you have the extension installed, VSCode will offer you do open this as container environment. Since your docker host sits on remote, this will now happen on your server instead of your local machine.
When I did the setup, I followed amongst other things this guide. Especially the SSH-Agent was required to get a remote docker host working. https://code.visualstudio.com/docs/remote/containers-advanced#_a-basic-remote-example
Here is a example .devcontainer file of mine.
Now back to your initial question, I don't think you will be able to use the remote container extension on a container that wasn't started as dev container. This is because vscode will install a bunch of stuff in there when its first set up. Similar to the SSH Extension. I may be wrong on this so take it with a grain of salt.
It may also be worth noting that once you connect to your server via SSH and have then the regular docker extension (which is not the remote container extension) installed, on remote, you will see your docker images listed there. But that does not mean you will be able to connect like that from local to remote container. For that you need to configure a docker remote host.
I have also faced similar issue after doing some research I found the issue was with my installation.
But I faced this issue when I installed vs-code through snap in Ubuntu.
May be try uninstalling VS Code and reinstalling it.
It should work if Docker is installed properly.
I took a clean machine (Windows 10 Enterprise w/out the Anniversary Update) and installed (in this order) Full IIS, Hyper-V, VS2015 Enterprise, .NET Core 1.0.1 Tooling Preview 2, Docker for Windows, Visual Studio Docker Tools, and a few other random programs.
I then opened VS2015 and created a default .NET core website. When I run (F5) all works as expected. I then right clicked on the project and went to Add->Docker Support. Now when trying to run (F5) using Docker I see this error message:
MSB4018 The "PrepareForCompile" task failed unexpectedly.
Microsoft.DotNet.Docker.CommandlineClientException: Error response
from daemon: Container ... is not running at ...
I have searched online and the only thing I can find that might explain it is that I don't think Shared Drives are working. I did set it up in Docker->Shared Drives, but when I run:
docker run --rm -v c:/Users:/data alpine ls /data
the response is empty.
Likewise when I try using busy box the directory is empty.
docker run -it -v /C/Users:/wormhole busybox
cd wormhole
ls
I have tried using Windows Desktop for Docker 1.12.1-stable and beta 26. Both have the same issue.
Some have indicated that Antivirus could cause a problem. I do have Mcafee installed, but I cannot uninstall or disable the antivirus software.
Some have suggested that passwords with unusual characters can cause this issue but that does not apply here.
I don't know that shared drives are causing the VS2015 error, but it seems like a good place to start since shared drives are broken.
I have restarted bot hdock and the computer many times, to no avail.
Any Ideas?
I had the same issue.
In order to fix it I found the container referenced by the id in the stack trace. Then I removed it:
docker rm <containerid>
When I tried running from VS 2015 again it worked. I don't know what initially caused the issue.
I just wanted to add since I also stumbled upon this issue. I had a clean Win 10 machine, and I just had to enable the "Shared Drive" setting in docker:
This may not be the actual problem that you're facing (Thankfully you fixed it!); this is just for people that may not have this enabled!