Developing Discourse using a Dev Container

Dev Containers is an open standard for configuring a development environment inside a container. This almost entirely eliminates the need to install/configure Discourse-specific tools/dependencies on your local machine, and makes it very easy to keep up-to-date as Discourse evolves over time.

Dev Containers can be used in a number of different IDEs, or directly using their reference CLI. This guide will describe the setup process for VSCode.

Getting started

  1. Download and install VSCode

  2. Install the Dev Containers extension in VSCode

  3. Clone the Discourse repository onto your machine

    git clone https://github.com/discourse/discourse
    
  4. In VSCode, use FileOpen Folder, then choose the Discourse directory

  5. Open the folder in its Dev Container. This can be done via the popup prompt, or by opening the command palette (Cmd/Ctrl + Shift + P) and searching for “Open folder in container…”

  6. If this is your first time launching a container, you will be prompted to install and start Docker Desktop. Once complete, go back to VSCode re-run “Open folder in container…”

  7. Wait for the container to download and start. When it’s done, the README will appear, and you’ll see the Discourse filesystem in the sidebar.

  8. Run the default build task using Ctrl + Shift + B (Cmd + Shift + B on mac).

    This will install dependencies, migrate the database, and start the server. It’ll take a few minutes, especially on the lower-end machines. You’ll see “Build successful” in the terminal when it’s done.

  9. Visit http://localhost:4200 in your browser to see your new Discourse instance

  10. All done! You can now make changes to Discourse’s source code and see them reflected in the preview.

Applying config/container updates

Every so often, the devcontainer config and the associated container image will be updated. VSCode should prompt you to “rebuild” to apply the changes. Alternatively, you can run “Dev Containers: Rebuild Container” from the VSCode command palette. The working directory, and your Redis/Postgres data will be preserved across rebuilds.

If you’d like to start from scratch with fresh database, you’ll need to delete the discourse-pg and discourse-redis docker volumes. This can be done from the “Remote Explorer” tab of the VSCode sidebar.

Discourse’s sample vscode .vscode/settings.json and .vscode/tasks.json will be copied when you first boot the codespace. From that point forward, if you want to use the latest sample config, you’ll need to manually copy .vscode/settings.json.sample to .vscode/settings.json.

References


This document is version controlled - suggest changes on github.

13 Me gusta

Hola,

No se creó ninguna cuenta de administrador

Cuando se utiliza el contenedor de Docker desde el exterior a través de los scripts en d/ (por ejemplo, d/boot_dev --init, como se especifica en Install Discourse for development using Docker), me pide que configure una cuenta de administrador como parte del proceso.

Sin embargo, cuando se utiliza como Contenedor de Desarrollo y se ejecutan los pasos de compilación (Ctrl/Cmd + Shift + B), NO crea un administrador.

Al echar un vistazo a las instrucciones, primero tuve la impresión de que crear un administrador es bastante arduo; pero luego me di cuenta de que todo lo que se necesita es este comando, lo dejo aquí para aquellos que se encuentren con el mismo problema:

rake admin:create

(o, si se queja de que se requiere una versión diferente de rake: bundle exec rake admin:create)

6 Me gusta

En Windows 11, si no quieres encontrar problemas con los finales de línea, como:

[23963 ms] Inicio: Ejecutar en contenedor: /bin/sh -c ./.devcontainer/scripts/start.rb
/usr/bin/env: ‘ruby\r’: No existe el archivo o directorio
/usr/bin/env: usa -[v]S para pasar opciones en las líneas shebang

.. asegúrate de Clonar en Volumen

5 Me gusta

Quizás haya una mejor manera, pero para trabajar en plugins tengo una carpeta hermana discourse-plugins junto a mi carpeta principal del repositorio de discourse. Esto se monta en /workspace/plugins para que luego pueda crear enlaces simbólicos dentro del contenedor.

Esto es lo que agregué a mounts en devcontainer.json:
"source=${localWorkspaceFolder}/../${localWorkspaceFolderBasename}-plugins,target=/workspace/plugins,type=bind"

2 Me gusta

Esto es realmente útil, gracias.

1 me gusta

… O simplemente git reset --hard
Me funcionó
Luego Dev Container: Rebuild Container y Ctrl-Shift-B

Si estás usando OrbStack (no afiliado) en tu entorno macOS local y quieres ejecutar Discourse en HTTPS con un dominio personalizado, actualiza tu devcontainer.json con las siguientes adiciones:

  1. Dale un nombre al contenedor.
  2. Añade el dominio comodín .orb.local a la variable de entorno RAILS_DEVELOPMENT_HOSTS (los nombres de host deben estar separados por una coma).
--- a/.devcontainer/devcontainer.json
+++ b/.devcontainer/devcontainer.json
@@ -13,10 +13,11 @@
   ],
   "remoteUser": "discourse",
   "remoteEnv": {
-    "RAILS_DEVELOPMENT_HOSTS": ".app.github.dev",
+    "RAILS_DEVELOPMENT_HOSTS": ".app.github.dev,.orb.local", // Paso 2
     "PGUSER": "discourse",
     "SELENIUM_FORWARD_DEVTOOLS_TO_PORT": "9229",
   },
+  "runArgs": ["--name","discourse"], // Paso 1
   "mounts": [
     "source=${localWorkspaceFolderBasename}-node_modules,target=${containerWorkspaceFolder}/node_modules,type=volume",
     "source=${localWorkspaceFolderBasename}-pg,target=/shared/postgres_data,type=volume",

p.d. por favor, házmelo saber si sabes cómo configurar el nombre de host *.orb.local y el nombre del contenedor dinámicamente, como se define para GitHub Codespaces. Establecer el valor como .app.github.dev,.orb.local no me funcionó.

Actualización: De alguna manera, me faltaba un registro en mi archivo /etc/hosts. Después de añadir esta línea, pude usar el dominio comodín .orb.local en el paso 2.

Con estos cambios en el archivo devcontainer.json, ahora puedo ejecutar mi instancia local de Discourse en https://discourse.orb.local/

/etc/hosts

Añade esta línea a tu archivo /etc/hosts si aún no la tienes.

##
# Docker y OrbStack
##
127.0.0.1 host.docker.internal

Consejo extra 1
Si por alguna razón la configuración de tu red, o la red VPN de tu empresa, etc., entra en conflicto con los rangos de IP de los contenedores de OrbStack, actualiza tu OrbStack con un rango diferente.

Consejo extra 2
Si omites el paso 1, OrbStack creará un contenedor con un nombre aleatorio, pero aún así podrás usar HTTPS sin añadir ningún número de puerto. La desventaja es el nombre del contenedor, por lo que el nombre de dominio se actualizará cada vez que reconstruyas el contenedor.