Install Discourse for development using Docker

Документация Руководства для разработчиков
, ,
168

Спасибо за руководство.

Однако у меня возникли проблемы с созданием резервной копии из раздела администратора.

Получаю следующую ошибку:
pg_dump: error: connection to database "discourse development" failed: FATAL: Peer authentication failed for user "postgres".

Я проверил файл pg_hba.conf и установил все опции в режим trust.

Буду очень признателен за помощь в том, как заставить это работать.

Я пробовал как на Ubuntu, так и на MacOSX. Всё работает отлично на обеих системах (создание постов, API и т.д.), за исключением функции резервного копирования.

169

Спасибо за это фантастическое решение с Docker.

Для запуска спецификаций плагинов это работает отлично:

d/rake plugin:spec["discourse-follow"]

Есть ли способ запускать тесты конкретных плагинов, как в обычной среде разработки без Docker? Например:

LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/requests/follow_controller_spec.rb:32

Я пробовал, например:

d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10 LOAD_PLUGINS=1 RAILS_ENV=test

Но получаю ошибку.

170

LOAD_PLUGINS и RAILS_ENV должны предшествовать команде для назначения переменных окружения. После команды они воспринимаются как аргументы для rspec, который их не понимает.

LOAD_PLUGINS=1 RAILS_ENV=test d/rspec plugins/discourse-follow/spec/lib/updater_spec.rb:10

171

Нет, я не убеждён, что это работает — вы действительно пробовали?

У меня получается:

NameError:
  uninitialized constant Follow

Подозреваю, что это связано с тем, что переменные окружения не передаются в процесс Docker?

Именно поэтому я делал их аргументами.

172

Извините, я неправильно истолковал ваши две команды как «первая работает для этой спецификации, вторая не работает для этой спецификации». У меня не настроена среда разработки для тестирования.

Посмотрев на файл rspec на GitHub, я думаю, что вы правы: переменные окружения не передаются. Однако, похоже, вы можете выполнить d/shell, чтобы получить доступ к оболочке внутри контейнера, а затем запустить там свою команду rspec.

1 лайк
173

Саймон, это больше, чем просто отличное рабочее решение, спасибо!

Только что попробовал, и всё работает, то есть:

my-blah-machine:~/discourse$ d/shell
discourse@discourse:/src$ LOAD_PLUGINS=1 RAILS_ENV=test rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

Добавил это и полную версию плагина в Wiki.

1 лайк
174

Если внимательнее присмотреться к d/exec, который используют как d/shell, так и d/rspec, я думаю, его тоже можно сократить вот так:

RAILS_ENV=test d/exec LOAD_PLUGINS=1 rspec plugins/discourse-follow/spec/lib/updater_spec.rb:37

d/exec передаёт RAILS_ENV, но не передаёт LOAD_PLUGINS, поэтому они размещаются по обе стороны от d/exec.

1 лайк
175

Это вызывает ошибку:

OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "LOAD_PLUGINS=1": executable file not found in $PATH: unknown
176

Ах, похоже, переменные окружения нельзя использовать с docker exec таким образом. Ничего страшного, по крайней мере, сначала открыть оболочку работает.

1 лайк
177

У меня точно такая же проблема, как у Макса. Всякий раз, когда я пытаюсь создать резервную копию или восстановить данные в локальной среде разработки Docker, возникает одна и та же ошибка: Peer authentication failed for user "postgres".

После некоторого исследования я обнаружил, что в среде разработки конфигурация базы данных отображается следующим образом:

BackupRestore.database_configuration
=> #<struct BackupRestore::DatabaseConfiguration host=nil, port=nil, username="postgres", password=nil, database="discourse_development">

Каким-то образом в среде разработки переменная окружения для имени пользователя не устанавливается, и модуль BackupRestore по умолчанию использует значение postgres.

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "postgres",
      config["password"] || password,
      config["database"]
    )

Где мы можем указать правильное имя пользователя базы данных?

1 лайк
178

Как мы можем использовать это здесь: Install the Discourse Theme CLI console app to help you build themes?

Мы успешно установили gem: d/exec sudo gem install discourse_theme … теперь задача состоит в том, чтобы создать символическую ссылку на локальную тему …

@Simon_Manning обратите внимание на использование sudo для обхода проблем с разрешениями (спасибо за напоминание @fzngagan)

179

Я пытаюсь протестировать плагин с помощью настройки Docker. Случайно приложение перестает загружаться, и я вижу только пустую страницу, пока не удалю папку с данными и не пересоберу всё заново. Есть какие-то советы по отладке этой проблемы?

180

Были ли какие-либо результаты по этому вопросу? Проблема, похоже, всё ещё актуальна.

181

Мой «грязный» обходной путь заключался в замене имени пользователя с postgres на discourse в следующем блоке кода:

# lib/backup_restore.rb:122

    DatabaseConfiguration.new(
      config["backup_host"] || config["host"],
      config["backup_port"] || config["port"],
      config["username"] || username || ENV["USER"] || "discourse",
      config["password"] || password,
      config["database"]
    )
182

Я перешёл с локального Mac на виртуальную машину с Ubuntu, надеясь, что это упростит запуск, но, к сожалению, пока ничего не вышло.

Уже столкнулся с какими-то странными проблемами с правами доступа на ранних этапах. d/bundle install сообщает, что для установки некоторых компонентов нужны права sudo, d/rails s также выдаёт ошибки прав доступа.

Traceback (most recent call last):
        8: from /src/bin/unicorn:70:in `<main>'
        7: from /src/bin/unicorn:38:in `ensure_cache_clean!'
        6: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `mkdir_p'
        5: from /usr/local/lib/ruby/2.7.0/fileutils.rb:211:in `each'
        4: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `block in mkdir_p'
        3: from /usr/local/lib/ruby/2.7.0/fileutils.rb:226:in `reverse_each'
        2: from /usr/local/lib/ruby/2.7.0/fileutils.rb:228:in `block (2 levels) in mkdir_p'
        1: from /usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `fu_mkdir'
/usr/local/lib/ruby/2.7.0/fileutils.rb:250:in `mkdir': Permission denied @ dir_s_mkdir - /src/tmp (Errno::EACCES)

Есть какие-то идеи, что идёт не так? На этой машине ранее без проблем работал продакшн-инстанс Discourse. Я просто остановил и удалил эти контейнеры, а затем клонировал репозиторий для разработки в другую директорию. Запускаю всё через tmux, чтобы управлять разными сессиями оболочки.

183

У меня пока нет M1, но я планирую перейти очень скоро, и мне действительно удобнее работать с Docker.

Ссылка в том PR ведёт на https://github.com/docker/for-mac/issues/5321, где они пишут:

единственное решение — перейти на мультиархитектурные образы с поддержкой arm64. Они также будут работать значительно быстрее и в целом надёжнее. Рекомендую проверить, какие базовые образы вы используете, и по возможности перейти на мультиархитектурные. На Docker Hub можно посмотреть, какие архитектуры поддерживаются каждым образом: […]

Чтобы собрать мультиархитектурный образ самостоятельно, рекомендую использовать docker buildx. Подробнее в этой статье: https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/

Готовы ли разработчики Discourse поддержать мультиархитектурный образ? Похоже, что базовый образ Discourse основан на debian:buster-slim, который уже поддерживает несколько архитектур, поэтому создание мультиархитектурного базового образа для Discourse не должно быть чрезмерно сложным. Однако это может означать, что команде придётся поддерживать ARM в продакшене. Кому-то (команде Discourse?) придётся запускать тесты Discourse как на x86_64, так и на ARM, исправлять возникающие проблемы и так далее.

Будет ли вообще приветствоваться PR в этом направлении?

(На мой взгляд, ARM — это архитектура будущего, даже в облачных средах.)

2 лайка
Install Discourse on Arm-Based Compute
184

Я пытаюсь настроить это в WSL2.

Я дошёл до запуска ember_cli, но Chrome выдаёт следующую ошибку:

Ни в терминале, ни в логе разработки видимых ошибок нет. Буду признателен за любые предложения.

1 лайк
Trouble setting up dev Discourse on WSL2 with Docker - solved
185

Это действительно полезно

186

Всем привет,

сталкиваюсь с теми же проблемами, поэтому решил сообщить об этом как об ошибке. Пожалуйста, ознакомьтесь с информацией ниже.

Восстановление резервной копии не удаётся в чистой среде разработки Docker: FATAL: Peer authentication failed для пользователя «postgres»

Дайте знать, если смогу предоставить дополнительную информацию или оказать какую-либо помощь.

Кун

187

Не могу заставить это работать на openSUSE Leap 15. Предполагаю, что это не поддерживаемая ОС, хотя, раз мы используем Docker, это не должно иметь значения…

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/app/assets/javascripts/plugins
/src/lib/plugin/instance.rb:441:in `ensure_directory'
/src/lib/plugin/instance.rb:713:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Пытался просто вручную создать «app/assets/javascripts/plugins», и это привело меня к следующему:

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ dir_s_mkdir - /src/tmp
lib/discourse.rb:94:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Так что я создам директорию tmp в исходной папке…

Но затем это привело меня сюда:

Migrating database...
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - /src/tmp/5ad4443faf817dc922116f8df65ae5c3
lib/discourse.rb:97:in `initialize'
lib/discourse.rb:97:in `open'
lib/discourse.rb:97:in `atomic_write_file'
/src/lib/plugin/instance.rb:726:in `activate!'
lib/discourse.rb:283:in `block in activate_plugins!'
lib/discourse.rb:280:in `each'
lib/discourse.rb:280:in `activate_plugins!'
/src/config/application.rb:318:in `block in <class:Application>'
/src/lib/plugin_initialization_guard.rb:5:in `plugin_initialization_guard'
/src/config/application.rb:317:in `<class:Application>'
/src/config/application.rb:73:in `<module:Discourse>'
/src/config/application.rb:72:in `<main>'
/src/Rakefile:7:in `<main>'
(See full trace by running task with --trace)

Похоже, что boot_dev запускает docker exec от имени пользователя discourse… но директории принадлежат пользователю с uid 1016 (uid моего пользователя на хосте).

Предполагаю, что многие разработчики не сталкиваются с этой проблемой на своих личных ноутбуках, где их пользователь имеет uid 1000, и это случайно совпадает…

1 лайк