Temporal won't run on development containers

[capythulhu]

Expected Behavior

Temporal should work normally on a development container

Actual Behavior

Temporal does not work on a development container

Steps to Reproduce the Problem

Step-by-step better specified here.

1. Clone this repository and open it with Visual Studio Code;
2. On VSCode terminal, run docker-compose up;
3. Wait for Temporal container to be deployed;
4. Watch Temporal work perfectly;
5. Stop and delete the Docker container;
6. On VSCode, press F1 and type Remote-Contianers: Rebuild and Reopen in Container. Press enter;
7. Wait for the development container to be fully deployed;
8. On VSCode terminal (now running inside the dev container) run docker-compose up;
9. Wait for about 1 minute and watch the service temporal to exit with code 1;
10. The logs says: Unable to create dynamic config client. Error: unable to validate dynamic config: dynamic config: config/dynamicconfig/development_sql_es.yaml: stat config/dynamicconfig/development_sql_es.yaml: no such file or directory

Specifications

• Version: 1.16.1
• Platform: Windows 11 with WSL

[yiminc]

Please try temporal's official docker compose: https://github.com/temporalio/docker-compose
Follow the steps there and let us know if it does not work. Thanks.

[capythulhu]

My repository is just a minimal version of that repo, but if you want to reproduce the bug only using original repositories, please, follow these steps:

On Windows

1. Start Docker
2. Open a WSL terminal

On WSL

1. git clone https://github.com/temporalio/docker-compose.git
2. cd docker-compose

At this point, if you run docker-compose up, Temporal will start and work normally. Follow the next steps to set up the development container.

3. mkdir .devcontainer
4. cd .devcontainer
5. wget -q https://raw.githubusercontent.com/qdm12/basedevcontainer/master/.devcontainer/devcontainer.json
6. wget -q https://raw.githubusercontent.com/qdm12/basedevcontainer/master/.devcontainer/docker-compose.yml
7. wget -q https://raw.githubusercontent.com/qdm12/basedevcontainer/master/.devcontainer/Dockerfile
8. code ../

On Visual Studio Code

Make sure you have Remote Containers extension installed.

1. Press F1
2. Type Remote-Containers: Rebuild and Reopen in Container and press Enter

On development container terminal (on Visual Studio Code)

1. rm ~/.docker/config.json (necessary because of some Windows-Docker issue)
2. docker-compose up

At this point, Temporal service will exit after a few seconds with the following log: Unable to create dynamic config client. Error: unable to validate dynamic config: dynamic config: config/dynamicconfig/development_sql_es.yaml: stat config/dynamicconfig/development_sql_es.yaml: no such file or directory

[jbreiding]

I work solely in dev containers and this is because of how bind mounts work with docker.

The best option here to get this to work is to use the docker-compose variant of dev containers and push these services to the main docker-compose file.

An example is here
https://github.com/microsoft/vscode-dev-containers/tree/main/containers/go-postgres

I’m hoping when this feature lands this will be simpler
moby/moby#32582

[capythulhu]

@jbreiding, unfortunately, that's far from the desired solution. I was opting for Docker in Docker because my application has almost 10 services running on containers, and I didn't want them to start along with the dev container itself (in fact, even when testing features, most of time one wouldn't even need to start all services at once) because developers don't need them all running on background while they're coding. Is there a way to prevent that?

[jbreiding]

If you have the docker extension installed you can stop any of the containers if they are running and start then again when needed

You can also not make the dev service dependent on the extra services and only identify the dev service to start.
This is defaulted to app in most cases.

it’s actually pretty close to ideal and works well.

If you insist on this path simply change the bind mounts to reference the fully qualified path accessible to your docker daemon.

this is likely the full path to your workspace folder in wsl. The context path is coming from the container mapping so very likely ‘/workspace’ which is not available to the docker daemon.

there are lots of options available to accomplish this.

https://code.visualstudio.com/docs/remote/devcontainerjson-reference#_docker-compose-specific-properties

[capythulhu]

Thanks for explaining that. Could you clarify some questions I have on that behalf? How exactly one would accomplish not making the dev service dependent on extra services? Below is a docker-compose.yml from Visual Studio Code "Go & PostgreSQL" development container preset (original avaiable here). I'm trying to make the db service not auto-initializable while allowing the developer to start it from inside the dev container using the Docker extension, as you said.

version: '3.8'

volumes:
  postgres-data:
    null

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        VARIANT: 1.18-bullseye
        NODE_VERSION: "lts/*"
    env_file:
      - .env

    volumes:
      - ..:/workspace:cached

    command: sleep infinity

    network_mode: service:db

  db:
    image: postgres:latest
    restart: unless-stopped
    volumes:
      - postgres-data:/var/lib/postgresql/data
    env_file:
      - .env

• Does network_mode: service:db make the app service dependent on db? If so, how to achieve both running on the same network without making them co-dependent?
• Is changing restart: unless-stopped to restart: no the correct way of telling Docker to not automatically initialize the service?

Thanks again for clarifying the situation.

[jbreiding]

I don't have a lot of experience running this way, but this may help you
https://docs.docker.com/compose/profiles/

If you encounter any issues from there its best to get some community help from vscode dev containers team. You will likely find someone running a similar setup.

[capythulhu]

I have tried compose profiles before, but unfortunately, anything that seems to stop services from auto-initializing (including restart: no) result in an error from the command that Remote-Containers extension runs:

Stop (109 ms): Run: docker-compose -f /home/usr/go/src/github.com/foo/go-postgres/.devcontainer/docker-compose.yml --profile * config
Error: Command failed: docker-compose -f /home/usr/go/src/github.com/foo/go-postgres/.devcontainer/docker-compose.yml --profile * config
    at Ru (/home/usr/.vscode-remote-containers/dist/dev-containers-cli-0.231.6/dist/spec-node/devContainersSpecCLI.js:210:813)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async pR (/home/usr/.vscode-remote-containers/dist/dev-containers-cli-0.231.6/dist/spec-node/devContainersSpecCLI.js:182:643)
    at async dR (/home/usr/.vscode-remote-containers/dist/dev-containers-cli-0.231.6/dist/spec-node/devContainersSpecCLI.js:179:2075)
    at async IR (/home/usr/.vscode-remote-containers/dist/dev-containers-cli-0.231.6/dist/spec-node/devContainersSpecCLI.js:224:2195)
    at async Xw (/home/usr/.vscode-remote-containers/dist/dev-containers-cli-0.231.6/dist/spec-node/devContainersSpecCLI.js:224:3221)
    at async kR (/home/usr/.vscode-remote-containers/dist/dev-containers-cli-0.231.6/dist/spec-node/devContainersSpecCLI.js:224:13925)
    at async TR (/home/usr/.vscode-remote-containers/dist/dev-containers-cli-0.231.6/dist/spec-node/devContainersSpecCLI.js:224:13650)
Stop (391 ms): Run in Host: /home/usr/.vscode-server/bin/dfd34e8260c270da74b5c2d86d61aee4b6d56977/node /home/usr/.vscode-remote-containers/dist/dev-containers-cli-0.231.6/dist/spec-node/devContainersSpecCLI.js up --container-data-folder .vscode-server/data/Machine --container-system-data-folder /var/vscode-server --workspace-folder /home/usr/go/src/github.com/foo/go-postgres --workspace-mount-consistency cached --id-label vsch.local.folder=\\wsl.localhost\Ubuntu-20.04\home\usr\go\src\github.com\foo\go-postgres --id-label vsch.quality=stable --log-level debug --config /home/usr/go/src/github.com/foo/go-postgres/.devcontainer/devcontainer.json --remove-existing-container --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root t
Exit code 1
Command failed: /home/usr/.vscode-server/bin/dfd34e8260c270da74b5c2d86d61aee4b6d56977/node /home/usr/.vscode-remote-containers/dist/dev-containers-cli-0.231.6/dist/spec-node/devContainersSpecCLI.js up --container-data-folder .vscode-server/data/Machine --container-system-data-folder /var/vscode-server --workspace-folder /home/usr/go/src/github.com/foo/go-postgres --workspace-mount-consistency cached --id-label vsch.local.folder=\\wsl.localhost\Ubuntu-20.04\home\usr\go\src\github.com\foo\go-postgres --id-label vsch.quality=stable --log-level debug --config /home/usr/go/src/github.com/foo/go-postgres/.devcontainer/devcontainer.json --remove-existing-container --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default on --mount-workspace-git-root true

Dev containers, at least for now, just seem to be too much headache. I'll look for other alternatives. Thank you!

Edit: In case anyone also stumbles on this problem, the discussion continues here.