This could either be seen as a bug, documentation improvement or both.

OS Information

• OS: Ubuntu 20.04.4 LTS running on Coder v1
• coder --version: v0.5.4-devel+ad8d9dd

Steps to Reproduce

Note that here we are running coder in production mode.

1. Set up postgres database
2. Run coder server: CODER_PG_CONNECTION_URL="postgres://..." coder server
3. Run coder login http://127.0.0.1:3000
4. Create template from docker-local example: coder templates create docker-local -d ~/src/coder/examples/docker-local
5. Create workspace: coder create -t docker-local my-test

Expected

The coder create and coder ssh my-test commands should just work™️.

Actual

(Note: I originally created this issue due to silent failure of coder create making it seem like it's just taking a long time for the workspace to start up, but that seems to be related to #1036 and possibly fixed?)

Running coder create --template=docker-local my-test gives an error:

  This template has customizable parameters. Values can be
  changed after create, but may have unintended side effects
  (like data loss).

var.docker_image
  What docker image would you like to use for your workspace?

  >  codercom/enterprise-base:ubuntu

┌─────────────────────────────────────────────────────────────┐
│ Workspace Preview                                           │
├─────────────────────────────────────────────────────────────┤
│ RESOURCE                    STATUS      ACCESS              │
├─────────────────────────────────────────────────────────────┤
│ docker_container.workspace  ephemeral                       │
│ └─ dev (linux, amd64)                    coder ssh my-test  │
├─────────────────────────────────────────────────────────────┤
│ docker_volume.coder_volume  persistent                      │
└─────────────────────────────────────────────────────────────┘
> Confirm create? (yes/no)
✔ Queued [45ms]
✔ Setting up [6ms]
⧗  Starting workspace
  Terraform 1.1.9
  coder_agent.dev: Plan to create
  docker_volume.coder_volume: Plan to create
  docker_container.workspace[0]: Plan to create
  Plan: 3 to add, 0 to change, 0 to destroy.
  coder_agent.dev: Creating...
  coder_agent.dev: Creation complete after 0s [id=990e17cb-62a9-4227-9d7b-247b669321ac]
  docker_volume.coder_volume: Creating...
  docker_volume.coder_volume: Creation complete after 0s [id=coder-coder-my-test-root]
  docker_container.workspace[0]: Creating...
  docker_container.workspace[0]: Creation errored after 1s
  Error: container exited immediately

✘ Starting workspace [2014ms]
exit status 1

But there is no indication as to what's wrong. With an older version of coder server (with the silent failure mentioned above), the docker container is not cleaned up and we can inspect it's log:

❯ docker logs coder-coder-my-test-root
curl: (7) Failed to connect to 127.0.0.1 port 3000: Connection refused

We see that the container didn't successfully complete its bootstap due to inability to download the agent (from a bad access URL).

There are four three things to observe here:

1. The access URL is unspecified and defaulting to 127.0.0.1 which is likely not what we want to propagate inside the workspace being created inside the Docker container
2. The coder server is not listening on the Docker interface (--address 0.0.0.0:3000 would help)
3. If this was a --dev instance we might not run into this issue when a tunnel is created
4. The curl error (and subsequent container exit) did not propagate and result in coder server being able to inform the user that the bootstrap failed (terraform issue? fixed as per observations in Final output on workspace creation shows "connecting" forever - confusing UX #1036?)

Notes

There are a few ways we could improve upon this, some ideas:

1. Improve documentation for examples/docker-local to mention all knobs that need to be tuned
2. Detect server/template configuration mismatches that can never work (e.g. the 127.0.0.1 access URL is not likely to work inside any sort of container system, nor is coder server listening on 127.0.0.1)
3. Better error reporting in the cli (could we show the container error log?)