Those non-VS Code instructions didn’t work for me just now on macOS. I recommend that macOS users who want to interact with the Discourse Docker image outside of VS Code use the legacy boot_dev Docker script instead.
With docker ps I found my container name (a randomized silly name, like peaceful_lumiere). I ran docker inspect peaceful_lumiere | jq '.[0].NetworkSettings.Networks.bridge.IPAddress' and it spit out an IP address. I went to http://<ip>:4200 in my browser, and it just sat there spinning forever.
I think that’s because the ember-cli dev server isn’t listening on all interfaces; it’s only listening on http://127.0.0.1:4200 inside the container.
I eventually got it to work by adding a runArgs section to .devcontainer/devcontainer.json, like this.
8025, // mailhog
9229 // chrome remote debug
],
+ "runArgs": [
+ "-p",
+ "127.0.0.1:4200:4200",
+ "-p",
+ "127.0.0.1:3000:3000",
+ "-p",
+ "127.0.0.1:9292:9292",
+ "-p",
+ "127.0.0.1:8025:8025",
+ "-p",
+ "127.0.0.1:9229:9229"
+ ],
"remoteUser": "discourse",
"remoteEnv": {
"RAILS_DEVELOPMENT_HOSTS": ".app.github.dev",
… but if you do that, it won’t work in VS Code (because VS Code and the devcontainer will both try to forward ports). I made a separate devcontainer-cli.json and used devcontainer --override-config .devcontainer/devcontainer-cli.json, and that worked.
But then it dawned on me: I’ve jumped through all these hoops, but I’m no better off than using the existing legacy boot_dev script. Following those documented steps is quicker and easier than trying to coerce devcontainer to do the right thing from the CLI.
Dev Containers are primarily intended for use in VS Code, or something that will automatically manage port forwarding for you; devcontainer CLI doesn’t do that. So, if you don’t want VS Code, maybe don’t bother with Dev Containers.