Docker Sandbox COMPLETELY changed in a minor update

Docker Desktop Docker Sandbox
1

I had Docker Desktop download an automatic update (4.64 → 4.67) on my Mac.

Docker Sandboxes stopped working, it’s looking for a non-existing file:

failed to start VM: create SDK client: create SDK client: health check: docker daemon not ready: failed to connect to the docker API at unix:///Users/omergilad/.docker/sandboxes/vm/agent-sandbox/docker.sock; check if the path is correct and if the daemon is running: dial unix /Users/omergilad/.docker/sandboxes/vm/agent-sandbox/docker.sock: connect: no such file or directory

Also, I opened the Docker Sandbox docs and was surprised to see that everything in the CLI was changed, migrated to an “sbx” CLI tool, without any notice, any migration steps - a total surprise that breaks my current workflow.

I have to force downgrade to a previous version to just do what I did until now.
I can confirm that in 4.64 my current sandbox setup works normally - after deleting the 4.67 Docker Desktop and downloading the 4.64 release.

2

The sandbox is still experimental, but there is a misunderstanding here which I try to clarify below.

sbx is a new tool, but as far as I know, docker sandbox still exists. The two solution doesn’t even use the same folder for storing the sandboxes. Here are the two commands on my Mac

 »  sbx version
Client Version:  v0.23.0 195ef9ec2cdaba8c88c1c9e3935d225a53ead8cb
Server Version:  v0.23.0 195ef9ec2cdaba8c88c1c9e3935d225a53ead8cb
 ta@ta-mb-2  /opt/homebrew/Caskroom/sbx/0.23.0   stable 
 »  docker sandbox version
Client Version: v0.12.0 f13b3c1a96a8be40b06473bb3db0c26dbfe1878c
Server Version: v0.12.0 f13b3c1a96a8be40b06473bb3db0c26dbfe1878c
 ta@ta-mb-2  /opt/homebrew/Caskroom/sbx/0.23.0   stable 

The one in Docker Desktop works as a plugin and and you can even connect to the daemon inside the sandbox by switching to the context of your sandbox like

docker context use agent-sandbox
docker info

The new tool on the other hand uses containerd directly with the nerdbox runtime to create the micro vm. You can list processes on your mac if you started any sandbox with “sbx” and search for “nerdbox”.

The error message you shared is something I saw often when I used the Docker Desktop plugin and the sandbox crashed without properly exiting. After that, I had to manually restart the sandbox daemon. It is not documented unfortunately, but it worked for me after I found the command in one of the sandbox logs

docker sandbox daemon stop
docker sandbox daemon start -d

Unfortunately one time I completely lost the whole sandbox VM and the “vm” folder was empty. When I reported it I learned it was possible in that version and hopefully you still have the VM and you just need a daemon restart.

sbx is still exprimental with its v0.24.1, so you can still expect issues which you can report on GitHub

If you just want to discuss some features or get help, you can continue to share your questions here or join the “sbx” slack channel.

I still use sbx v0.23 and on Windows, I think I managed to break the sandbox completely by unmounting its bind mounted worspace directory which forced me to delete the containerd folder in order to use the same sandbox name, but new versions come out frequently. I just noticed the v0.24.1, so I really recommend switching to this version. And you can update the sbx whenever you want, not depending on the version of Docker Desktop.

3

Docker Desktop new release still broke the existing workflow - confirmed.
In 4.64 I had no issues whatsoever. Force downgrading to 4.64 solved my current issues.

Also, the new docs (both for “sbx” and the old “docker sandbox” CLI - under https://docs.docker.com/ai/sandboxes/) completely removed template saving from a sandbox (“docker sandbox save”).
This is a DEAL BREAKER, and if the new release cycle will stop supporting arbitrary template saving to an image, I will not use this product anymore, my workflow depended on this ability.

4

I don’t know what sandbox version was installed in 4.64. Can you share the output of docker sandbox version now after downgrading back? I only remember 0.12, but I also don’t remember when I started to check versions.

If it was “0.12”, the upgrade could not change anything in the sandbox. It could still broke something, I’m not saying it couldn’t, but docker sandbox save still works as well as sbx save. I can confirm it is not documented for the docker sandbox command, which could only be a mistake, not intentional since even the new sbx has the same subcommand.

You can report the bug in the documentation by clicking on “Request changes” in the top right corner on GitHub.

By the way, I realized I was not precise before. My issue ith the sandbox was that when I stopped Docker Desktop, but the sandbox daemon was still running, after I stopped that two, I could not restart it. If downgrading solved your issue, it is possible the daemon was just restarted with it.

I have been using the sandbox since the beginning of march. I found that the current version was introduced in Docker Desktop 4.61, released in February, so it looks like I used that from the beginning until switching to sbx. After I had problems on Windows I switched to Mac and I did not exprerience issues since then.

Maybe I was just lucky, so if restarting the daemon doesn’t help, only the downgrade, I would recommend sharing your feedback in another repository

5

I did attempt to restart the daemon in the latest version and it didn’t solve it.
Only downgrading to 4.64 did.

I am glad to know that the template saving feature is intended to be maintained, and was just omitted from the docs by mistake.

Overall - since all this recent move to ‘sbx’ is a big experimental change, I will just stick with what currently works in Docker desktop 4.64 without doing any automatic update and without trying the new ‘sbx’, until everything looks more mature.

6

That sounds like a good approach.

7

Have you considered to create your custom template using a Dockerfile? After all the agent template is “just” a container image. Since we don’t know anything about your workflow, it might be a shot in the dark. Manual commands are only repeatable with precise and complete documentation… while a Dockerfile already is a precise documentation itself.

8

In my workflow I do a lot of installation and configuration on my sandbox and I need to constantly back it up for reusing with other mounted workspaces.
Creating an exact Dockerfile for this moving target is not feasible - that’s why template saving is exactly what I need - saving a snapshot of the sandbox without the mounted part.