You should look at mounting volumes to persist your workspace directories. See this template for example.

https://github.com/matifali/coder-templates/blob/main/deeplearning/main.tf

I addedlifecycle { ignore_changes = all } (docs) for docker_container resource. Then I stop the workspace, the code server seems to be stopped (I cannot connect to it.), the container still doesn't stop. Then I manually stop the container. Then restart the workspace, the container was started as expected (not recreated).

BUT, if I don't stop the container after stopping the workspace, and start the workspace, wired things happen, unable to connect (the ui keeps loading,ps -aux in container shows two code-server instances).

Probably, coder should stop all container when stopping a workspace? By the way, I see nothing related to stopping a container interraform docs. Probably terraform simply doesn't support stopping a container? Can anyone tell me is that correct?

You cannot persist a container on workspace stop. Even if you somehow prevent terraform from destroying it it will be recreated/replaced on the next workspace restart.
For persistence you should mount volumes to the directories you need.

I hit this same issue as well. Let me provide a little more usecase info to justify the need.

We are using the Docker Container template w/a-few tweeks. We like that, it's fast! As opposed to DevContainer (EnvBuilder).

We have a case where we use a mostly complete image, but we want to add some addtl things (like vscode extensions and a few other things).
We'd prefer not modify the image we are using because other folks use the same image in a fashion that doesn't relate to the coder experience.
So, the semantics around workspace lifecycle are odd for us, as we spend time "peppering" the container on workspace start up and all that "peppering" is lost on a workspace stop.
The end-user goes to start their auto-stopped workspace and their food tastes bland (no pepper!), well not really, but they have to wait for the pepper to be applied to the new container. Not that long but, still we want fastness :) .

Here's the work-around that might-be-awful or might-not-be (we'll see I guess)

add this to the bottom of your Container template

resource "null_resource" "docker_control" {  triggers = {    always_run = timestamp()  }  provisioner "local-exec" {    command = <<-EOT      if [ "${data.coder_workspace.me.transition}" = "start" ]; then        docker start ${docker_container.workspace[0].name}      elif [ "${data.coder_workspace.me.transition}" = "stop" ]; then        docker stop ${docker_container.workspace[0].name}      fi    EOT  }  depends_on = [docker_container.workspace, data.coder_workspace.me]}

now, you must also change the count variable on your "workspace" resource

resource "docker_container" "workspace" {  count = 1

The full life cycle as tested is this...

1. You create the ws, container starts as expected. (confirmed withdocker ps -a)
2. You stop the ws, container w/count=1 remains, null resource kicks in and issues a stop (also confirmed w/docker ps -a) NOTE: coder Ui is confused, cuz it thinks there is a container, but really the null_resource kicks in and is stopping the container (see above )
3. You start the ws, container w/count=1 is still there-but-stopped, now your null_resource kicks in and starts the container. Coder UI is now happy cuz it finds what it expects, the container running.

I fear what happens if a stop doesn't actually stop? Maybe that's not a thing, but does seem like there is some potential for state inversion sync problem.

We'll see I guess.
I would like to see this as a feature though, yes I know this is partly a Terraform thing and partly a provider:docker thing, but I suspect there's something doable here?