Aqueles instruções que não envolvem o VS Code não funcionaram para mim agora mesmo no macOS. Recomendo que usuários do macOS que desejam interagir com a imagem Docker do Discourse fora do VS Code usem o script Docker legado boot_dev em vez disso.
Com docker ps, encontrei o nome do meu container (um nome aleatório e engraçado, como peaceful_lumiere). Executei docker inspect peaceful_lumiere | jq '.[0].NetworkSettings.Networks.bridge.IPAddress' e ele retornou um endereço IP. Acessei http://<ip>:4200 no meu navegador, mas a página ficou girando para sempre.
Acho que isso acontece porque o servidor de desenvolvimento do ember-cli não está ouvindo em todas as interfaces; ele só está ouvindo em http://127.0.0.1:4200 dentro do container.
Finalmente consegui fazer funcionar adicionando uma seção runArgs ao arquivo .devcontainer/devcontainer.json, assim:
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",
… mas, se você fizer isso, não funcionará no VS Code (porque tanto o VS Code quanto o devcontainer tentarão encaminhar portas). Criei um arquivo devcontainer-cli.json separado e usei devcontainer --override-config .devcontainer/devcontainer-cli.json, e isso funcionou.
Mas então percebi: passei por todas essas dificuldades, mas não estou em melhor situação do que usando o script legado boot_dev existente. Seguir as etapas documentadas é mais rápido e fácil do que tentar forçar o devcontainer a fazer a coisa certa via CLI.
Os Dev Containers são destinados principalmente ao uso no VS Code, ou em algo que gerenciará automaticamente o encaminhamento de portas para você; a CLI do devcontainer não faz isso. Então, se você não quer usar o VS Code, talvez não valha a pena usar os Dev Containers.