Hey there! Let me break down exactly what that line from the Packer Docker Builder docs means, especially for your DevOps pipeline scenario with service connections.

First, let's translate that doc sentence into plain terms: The Packer Docker Builder cannot directly connect to a remote Docker host (like a Docker daemon running on another server, or a cloud-hosted Docker service) to perform image builds. It only works when communicating with a Docker daemon that's running locally on the same machine where Packer itself is executing.

Let's tie this to your pipeline setup: If you're trying to run Packer in your DevOps pipeline, and your service connection points to a remote Docker daemon (say, on a separate build server or a cloud container service), that's going to hit a wall. Packer won't be able to reach that remote daemon to do its work—instead, it expects the Docker daemon to be available locally via the default socket (/var/run/docker.sock on Linux) or a local TCP port (like localhost:2375).

If you need to use a remote Docker environment for your builds, here are a few workarounds to consider:

• Run Packer directly on the machine where the remote Docker daemon is hosted. That way, Packer and Docker are on the same system, and the builder can communicate locally.
• In your CI/CD pipeline, use a runner that has Docker installed and running locally. Packer will interact with this local daemon, which can still push built images to remote registries if needed.
• Use Docker-in-Docker (DinD) within your pipeline runner. This spins up a local Docker daemon inside a container, which Packer can connect to as if it's a local service.

备注：内容来源于stack exchange，提问作者Ganju