discourse_docker

repository·main·Indexed 23 days ago

https://github.com/discourse/discourse_docker

Docker images and management tooling for deploying and managing Discourse forums. Includes the Launcher CLI for container lifecycle management, templates for standalone and distributed architectures, and a Setup Wizard CLI for installation configuration. Provides specialized image variants for runtime, building, development (discourse_dev), and testing (discourse_test), with build support via docker buildx bake.

Tokens
3K
Snippets
5
Records
17
Agent score
84%

What's inside discourse_docker

  1. Understand Discourse Docker image variants

    main

    The Discourse Docker images are categorized into different functional roles. The base image contains all core dependencies (runit, postgres, nginx, ruby, imagemagick, etc.) and the discourse user. It has several tag variants:

    • runtime-deps: Runtime dependencies only.
    • build-deps: Includes runtime-deps plus build tools for compiling gems, node, and pnpm.
    • slim: Includes build-deps plus a Discourse clone (main and stable/esr varieties).
    • web-only: Includes slim plus gems and node modules.
    • release: Includes web-only plus redis and postgres.
  2. Build new Docker images using docker buildx bake

    main

    To build new images, use the docker buildx bake command. This process builds local images with predefined tags as defined in the docker-bake.hcl file in this repository.

    To see a list of all valid build targets, run: docker buildx bake --list targets

    docker buildx bake {target}
  3. Use the discourse_dev image for development

    main

    The discourse_dev image is an all-in-one container for development that includes redis and postgres.

    Usage Requirements:

    • You must mount your local Discourse source directory to /src inside the container.
    • The discourse user is granted passwordless sudo permissions to facilitate command-line Docker tools that run as the discourse user.

    For utilities to assist with this setup, refer to the README in the main discourse/bin/docker directory of the discourse/discourse repository.

  4. Upgrade Discourse

    main

    There are two primary ways to upgrade your Discourse instance:

    1. Web UI: Use the admin interface at http://yoursite.com/admin/upgrade to upgrade an already running image.
    2. CLI Rebuild: Create a new base image manually by running the launcher rebuild command.
    ./launcher rebuild my_image
  5. Understand Discourse configuration file structure

    main

    Discourse container configurations (typically located at containers/app.yml) are structured using two primary top-level keys for settings:

    1. env: Used for environment variables. Keys starting with DISCOURSE_, LETSENCRYPT_, or UNICORN_ are automatically categorized here.
    2. params: Used for other configuration parameters.

    Additionally, the templates key is an array used to include specific configuration templates, such as SSL or Let's Encrypt configurations.

  6. Configure container definitions

    main

    Container definitions (typically YAML files in the /containers directory) use special sections to configure the Docker environment.

    Templates

    Use templates to compose your configuration from existing pups-managed templates found in /templates.

    Port Exposure

    Use expose to publish ports. You can bind to specific host interfaces or just specify the container port to expose it without publishing.

    Volumes

    Use volumes to map host directories to guest directories. This is recommended for persistent data like logs and uploads to ensure data survives container rebuilds.

    Use links to connect the current container to another container (e.g., a database container).

    Environment Variables

    Use env to set environment variables inside the container.

    Labels

    Use labels to add metadata to the container.

    Hooks

    Hooks allow you to run code before or after template logic. You can find available hooks by searching templates for hook: or running grep -r "hook:" . in the repository.

    ### templates:
    ```yaml
    templates:
      - 'templates/cron.template.yml'
      - 'templates/postgres.template.yml'

    expose:

    expose:
      - '2222:22'
      - '127.0.0.1:20080:80'

    volumes:

    volumes:
      - volume:
        host: /var/discourse/shared
        guest: /shared
    links:
      - link:
        name: postgres
        alias: postgres

    environment variables:

    env:
      DISCOURSE_DB_HOST: some-host
      DISCOURSE_DB_NAME: '{{config}}_discourse'

    labels:

    labels:
      monitor: 'true'
      app_name: '{{config}}_discourse'

    hooks:

    hooks:
      after_code:
        - exec:
            cd: $home/plugins
            cmd:
              - git clone https://github.com/discourse/docker_manager
  7. Configure Docker bake environment variables

    main

    You can customize the image building process by setting the following environment variables used by docker-bake.hcl:

    VariableDescriptionDefault
    ARCHImage architectureamd64,arm64
    BASE_IMAGEBase image repositorylocal_discourse/base
    TEST_IMAGETest image repositorylocal_discourse/discourse_test
    SETUP_WIZARD_IMAGESetup wizard image repositorylocal_discourse/setup-wizard
    DEV_IMAGEDev image repositorylocal_discourse/discourse_dev
  8. How the Discourse Setup Wizard signals a rebuild

    main

    The Discourse Setup Wizard (running inside a container) cannot perform a full rebuild of the Discourse image itself because the rebuild process must run on the host machine. To bridge this, the wizard writes a signal file to a specific path inside the container: /discourse_docker/.wizard_rebuild_needed.

    The host-side wrapper script monitors this file. When the file is detected, the wrapper script initiates the actual rebuild process on the host. If the rebuild(skip: true) option is used during the wizard process, this signal file is not created, and the rebuild is bypassed.

    REBUILD_SIGNAL_FILE = "/discourse_docker/.wizard_rebuild_needed"