You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm trying to run docker inside "vs code container" initiating from the Azure AI Foundry project.
But upon installing Container tools extension or Docker and then clicking the Containers icon in vs code, it prompted "Failed to connect. Is Docker installed?". The terminal prompted: "bash: docker: command not found".
Is there anything that could be done to make it work? Thanks!
With Azure technical support, they helped to install docker CLI inside the containerized viscode. And now, upon running docker version, I got:
Client: Docker Engine - Community
Version: 28.2.2
API version: 1.50
Go version: go1.24.3
Git commit: e6534b4
Built: Fri May 30 12:07:26 2025
OS/Arch: linux/amd64
Context: default
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.50/version": dial unix /var/run/docker.sock: connect: permission denied.
With this permission issue, google suggested adding user to docker group.
Is this the correct to address the issue? In case it is, could you suggest the right command of doing so with a Mac local machine?
In the meanwhile, the "remote explorer" viscose extension could communicate with the local docker desktop without the need of additionally installing the docker CLI. Does it work on a different mechanism? Is there a way that we can take advantage of this intuitive communication with docker desktop while still keeping the ready made folder structure and GitHub setup from the containerized vscode? Thanks in advance for the answers and knowledge sharing.
So if I understand your setup correctly, you have Docker Desktop running on Mac, with a dev container, with the Docker CLI installed inside the dev container--is that correct? And the goal is to manage Docker containers/images/etc. on the host, but from the dev container?
Brandon Waterloo [MSFT] (@bwateratmsft) I got Docker Desktop running on Mac, with a containerized vscode (with Docker CLI installed).
And I'll use the containerized vscode to do everything. There's no code on the host Mac. And I prefer not using Docker Desktop if there's a possibility to run docker inside the containerized vscode itself, which will be a clean and simplified scenario.
Maybe you are aware of the AWS Cloud9, which would be the ideal counterpart of the ideal all-in-one cloud based secure development environment (experience).
It is possible to run Docker inside a Docker container, but it's also possible to control the Docker host (in this case, Docker Desktop on your Mac) from within the container. However, to do the latter you'll need to install the Docker CLI in the container as well as volume-map the Docker socket (/var/run/docker.sock).
Sure! What you're describing is referred to as "Docker-in-Docker" (or "dind"), where containers run inside a dev container. There's a bit of information available here on Docker-in-Docker. There is more than one way to set it up, perhaps the easiest is the Dev Containers way: https://github.com/devcontainers/templates/tree/main/src/docker-in-docker
Importantly, once you've gotten Docker installed in your dev container, you also need to install the Container Tools extension on the "server" side of VSCode. If you go to the Extensions view in VSCode, you'll see two lists of extensions--one installed on the host machine (your Mac), and one installed in the container's VSCode server. The Container Tools extension needs to be installed on the server side to work. This screenshot is for WSL, not a dev container, but it will look very similar:
The alternative is called "Docker-from-Docker" or "Docker outside of Docker", where containers run beside a dev container, on the host. This requires volume-mounting the Docker socket.
I'm going to convert this to a discussion as it seems like there's not a bug here.
Activity
bwateratmsft commentedon Jun 23, 2025
Can you share more about what you mean when you say:
Is it using https://insiders.vscode.dev/azure or a simple dev container?
mirojs commentedon Jun 24, 2025
Brandon Waterloo [MSFT] (@bwateratmsft) Sure. It's quite similar to the https://insiders.vscode.dev/azure. But I created the compute instance under the "management center" of the Azure AI Foundry.
With Azure technical support, they helped to install docker CLI inside the containerized viscode. And now, upon running docker version, I got:
Client: Docker Engine - Community
Version: 28.2.2
API version: 1.50
Go version: go1.24.3
Git commit: e6534b4
Built: Fri May 30 12:07:26 2025
OS/Arch: linux/amd64
Context: default
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.50/version": dial unix /var/run/docker.sock: connect: permission denied.
With this permission issue, google suggested adding user to docker group.
Is this the correct to address the issue? In case it is, could you suggest the right command of doing so with a Mac local machine?
In the meanwhile, the "remote explorer" viscose extension could communicate with the local docker desktop without the need of additionally installing the docker CLI. Does it work on a different mechanism? Is there a way that we can take advantage of this intuitive communication with docker desktop while still keeping the ready made folder structure and GitHub setup from the containerized vscode? Thanks in advance for the answers and knowledge sharing.
bwateratmsft commentedon Jun 24, 2025
So if I understand your setup correctly, you have Docker Desktop running on Mac, with a dev container, with the Docker CLI installed inside the dev container--is that correct? And the goal is to manage Docker containers/images/etc. on the host, but from the dev container?
mirojs commentedon Jun 25, 2025
Brandon Waterloo [MSFT] (@bwateratmsft) I got Docker Desktop running on Mac, with a containerized vscode (with Docker CLI installed).
And I'll use the containerized vscode to do everything. There's no code on the host Mac. And I prefer not using Docker Desktop if there's a possibility to run docker inside the containerized vscode itself, which will be a clean and simplified scenario.
Maybe you are aware of the AWS Cloud9, which would be the ideal counterpart of the ideal all-in-one cloud based secure development environment (experience).
bwateratmsft commentedon Jun 25, 2025
It is possible to run Docker inside a Docker container, but it's also possible to control the Docker host (in this case, Docker Desktop on your Mac) from within the container. However, to do the latter you'll need to install the Docker CLI in the container as well as volume-map the Docker socket (
/var/run/docker.sock).mirojs commentedon Jun 25, 2025
Brandon Waterloo [MSFT] (@bwateratmsft) Could you help to elaborate how to run Docker inside the containerized vscode? It's the ideal case.
bwateratmsft commentedon Jun 25, 2025
Sure! What you're describing is referred to as "Docker-in-Docker" (or "dind"), where containers run inside a dev container. There's a bit of information available here on Docker-in-Docker. There is more than one way to set it up, perhaps the easiest is the Dev Containers way: https://github.com/devcontainers/templates/tree/main/src/docker-in-docker
Importantly, once you've gotten Docker installed in your dev container, you also need to install the Container Tools extension on the "server" side of VSCode. If you go to the Extensions view in VSCode, you'll see two lists of extensions--one installed on the host machine (your Mac), and one installed in the container's VSCode server. The Container Tools extension needs to be installed on the server side to work. This screenshot is for WSL, not a dev container, but it will look very similar:
The alternative is called "Docker-from-Docker" or "Docker outside of Docker", where containers run beside a dev container, on the host. This requires volume-mounting the Docker socket.
I'm going to convert this to a discussion as it seems like there's not a bug here.