Настройка тестового сервера

Существует несколько приемов, которые могут помочь при настройке тестового сервера.

Что такое тестовый сервер?

Тестовый сервер — это, по сути, копия продакшн-сайта. Он также размещается на сервере и функционирует идентично. Он работает внутри контейнера Docker, как и обычный сайт Discourse.

Он предназначен для того, чтобы у вас было место для проверки рискованных действий или тестирования функций, которые нелегко скрыть от пользователей. Он очень полезен для тестирования рекламы с помощью плагина Discourse Advertising Plugin (Ads) или если вы хотите сделать что-то необычное, например, импорт или слияние форумов.

Это отличается от сервера разработки, который обычно работает в легкодоступном (и изолированном) месте, чтобы разработчик мог безопасно экспериментировать с кодом.

Что мне нужно?

  1. Всё, что требуется для стандартной самостоятельной установки

  2. Если у вас настроены резервные копии S3, ваша жизнь станет намного проще

    • в противном случае вам понадобится способ перемещать большие файлы на сервер и с него через SSH

Шаги

Настройте свой сервер так, как вам удобно

Обычно это виртуальный сервер Ubuntu, размещенный на Digital Ocean, но вы можете использовать любой другой вариант, с которым вам комфортно.

Установите Discourse

С помощью этого руководства (или, возможно, через dashboard.literatecomputing.com). Я рекомендую использовать «мусорные» учетные данные для электронной почты (вам не нужно, чтобы почта работала).

Подтвердите, что установка работает:

Создайте учетную запись администратора (если необходимо)

Создайте учетную запись администратора из командной строки. Это позволит избежать необходимости аутентификации по электронной почте.

./launcher enter app
rake admin:create

Это не строго необходимо, кроме как для тестирования установки, так как вы можете восстановить систему из резервной копии через командную строку.

Отредактируйте app.yml и внесите некоторые изменения

  1. Возможно, стоит сделать копию исходного файла app.yml (я называю свою app.vanilla.yml), к которой вы сможете вернуться, если что-то пойдет не так.

  2. В конце раздела env добавьте следующие строки:

      ## Настройки, специфичные для тестового сервера
      DISCOURSE_BACKUP_FREQUENCY: 0
      DISCOURSE_LOGIN_REQUIRED: true
      DISCOURSE_DISABLE_EMAILS: 'yes'
      DISCOURSE_S3_DISABLE_CLEANUP: true
      DISCOURSE_ALLOW_RESTORE: true
    
  3. Если у вас настроены резервные копии S3 (или аналогичные), добавьте также эти строки (используя настройки с основного сайта):

      ## Настройка S3
      DISCOURSE_S3_ACCESS_KEY_ID: 'your_key'
      DISCOURSE_S3_SECRET_ACCESS_KEY: 'your_secret'
      DISCOURSE_BACKUP_LOCATION: 's3'
      DISCOURSE_S3_BACKUP_BUCKET: 'your_backups_location'
      DISCOURSE_S3_REGION: 'your_s3_region'
      DISCOURSE_S3_DISABLE_CLEANUP: true
    

    а если вы также используете загрузки S3:

      DISCOURSE_ENABLE_S3_UPLOADS: true
      DISCOURSE_S3_UPLOAD_BUCKET: 'your_uploads_location' 
    
  4. Возможно, стоит добавить те же плагины, что и на вашем продакшн-сайте.

  5. Выполните пересборку:

    • ./launcher rebuild app

Управление тестовым сервером

Теперь у вас есть тестовый сервер, подключенный к вашим резервным копиям S3 (но не перезаписывающий их), который легко восстановить, и который ни при каких обстоятельствах не может отправлять электронные письма. Идеально!

Вы можете восстановить свежую резервную копию на тестовый сервер и приступать к работе. Если вам не понравится результат, вы просто восстановите его снова.

Отключение или включение

Если вы оставляете тестовый сервер включенным в течение длительного времени, существует риск его индексации Google и случайного входа пользователей в него вместо основного сайта. Поскольку их учетные данные являются копией вашего продакшн-сайта, это вполне возможно.

Простой способ избежать этих проблем — просто выключить Discourse:

 ./launcher stop app

А чтобы включить его снова для использования:

./launcher restart app

Обновления

Если вы хотите, чтобы всё оставалось синхронизированным с точки зрения плагинов и кода, вам нужно будет обновлять и пересобирать как тестовый сервер, так и ваш продакшн-сайт одновременно. То же самое касается изменений в app.yml.

Если вы не используете S3, вам придется вручную перемещать резервные копии между серверами. И они большие!

Заполнение тестового сервера

Если вам нужен тестовый сервер, его следует заполнить вашими реальными данными с вашего реального форума через Restore. Иногда проблема заключается именно в ваших данных, и тестирование форума с другим набором данных может дать вам ложную надежду.

Однако, если вам нужен тестовый сервер, чтобы посмотреть, как работает Discourse, вы можете проверить его с помощью тестовых данных. В этом случае сделайте следующее:

./launcher enter app
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate

Это заполнит ваш форум тестовыми данными, чтобы вы могли увидеть, как всё выглядит с выбранными вами темами и плагинами. Если вы еще не запустили свой форум, это даст вам представление о том, как всё может выглядеть.

Управление двухфакторной аутентификацией

Хотя имя пользователя и пароль вашей учетной записи с основного сайта должны работать и на тестовом сайте, с двухфакторной аутентификацией (2FA) могут возникнуть сложности. Если у вас возникнут проблемы, отключите 2FA:

./launcher enter app
rake users:disable_2fa[<USERNAME>]
32 лайка

Натан, отличная идея собрать это руководство.

Возможно, я что-то упустил, но какой шаг здесь отключает электронную почту?

5 лайков

Хороший вопрос. Указание некорректных учетных данных SMTP однозначно предотвращает отправку, но также имеет смысл отключить рассылку электронной почты с помощью:

DISCOURSE_DISABLE_EMAILS = yes

Кроме того, эта настройка включается автоматически при восстановлении, поэтому в ней нет особой необходимости.

8 лайков

Добавил в исходный пост инструкции по отключению приложения.

2 лайка

Верно, и часто бывает удобно получить ссылку для входа, поэтому я рекомендую

 DISCOURSE_DISABLE_EMAILS = 'non-staff'
6 лайков

Как насчёт раздела о создании фейковых пользователей? Некоторые администраторы не хотят, чтобы на тестовых серверах хранилась персонально идентифицируемая информация (PII). Чем люди пользуются для создания фейковых пользователей в больших масштабах или для удаления PII?

Я думал о том, чтобы импортировать данные из продакшена, а затем запустить задачу анонимизации для каждой записи, но в результате тестовый сайт выглядел бы очень скучно!

Могу ли я предложить превратить вопрос автора темы в статью вики?

Некоторые ссылки:

Я сделал это вики.

В целом, я хочу, чтобы на тестовом сайте использовались те же данные, что и на продакшн-сайте, чтобы можно было проверить, что всё будет работать с реальными данными. Но, возможно, людям нужны фейковые данные, чтобы посмотреть, что может Discourse, прежде чем они начнут его использовать? (О, кажется, по этим ссылкам есть более продвинутые решения.)

Кажется, можно было бы использовать цикл с вызовом User.create и списком имён откуда-нибудь.

2 лайка

Очевидно, это не моя сильная сторона :slightly_smiling_face:, но не будет ли это хорошим поводом использовать rake dev:populate?

cd /var/www/discourse
ALLOW_DEV_POPULATE=1 bundle install
ALLOW_DEV_POPULATE=1 rake dev:populate

Думаю, это также сработает на продакшн-сервере, который по сути является средой для тестирования или стейджингом.

4 лайка

Похоже, это не помеха!

Отличное предложение:

Код задачи: discourse/populate.rake at 1472e47aae5bfdfb6fd9abfe89beb186c751f514 · discourse/discourse (github.com)

Действия, специфичные для пользователя:

1 лайк

Отлично! Действительно, кто-то уже подумал об этой проблеме!

РЕДАКТИРОВАНИЕ: и для интереса я попробовал это на недавно установленной тестовой площадке; я вставил ваши задачи bundle и rake, и вот что получилось:

root@test2-app:/var/www/discourse# ALLOW_DEV_POPULATE=1 rake dev:populate
OK
Я не обнаружил пользовательский файл `config/dev.yml`, создаю его для вас, чтобы вы могли изменить значения по умолчанию.
Существует 9 записей групп. Создаю ещё 6.
......
Существует 3 записи пользователей. Создаю ещё 27.
...........................
Существует 4 записи категорий. Создаю ещё 26.
..........................
Включение discourse-solved для категории 'Рецепты' (12).
Создание 30 образцов записей тегов
..............................
Существует 6 записей тем. Создаю ещё 24.
........................
root@test2-app:/var/www/discourse# 


3 лайка

Главная проблема в том, что ваш набор данных перестанет отражать данные рабочей среды.

Тестовый сервер должен быть репрезентативным по отношению к рабочей среде, иначе вы не сможете протестировать всё необходимое перед внедрением запланированных изменений в продакшн.

Я наблюдал за довольно впечатляющими сбоями, когда нерепрезентативные тесты не выявляли проблемы, которые позже проявлялись в рабочей среде. Чаще всего они возникали из-за проблем с качеством данных.

Например, двойные фамилии (с дефисом и без) и символы с диакритическими знаками вызывали огромные проблемы.

Если это настоящий тестовый сервер, он должен точно имитировать рабочую среду. Копия не должна быть видна обычным пользователям, и отключение электронной почты для нештатных сотрудников настоятельно рекомендуется, но в остальном это просто приглашает к проблемам.

5 лайков

Да, я согласен. Мой вопрос возник из-за клиента, который беспокоился о том, что в тестовой среде будут использоваться реальные данные клиентов.

В идеале у нас должен быть скрипт, который подменяет имена и адреса электронной почты, оставляя всё остальное без изменений.

1 лайк

Звучит как довольно простой разговор. Если у них нет репрезентативной копии, значит, у них нет тестового сайта.

Если он развернут и защищен так же, как и рабочая версия, каковы их воспринимаемые риски?

2 лайка

Я согласен со Стивеном. Что беспокоит клиента больше: наличие реальных данных на тестовом сайте или отсутствие тестового сайта, который фактически проверяет ваши реальные данные?

Если вы не тестируете с реальными рабочими данными из продакшена, то вы не знаете, что произойдет, когда вы начнете использовать живые данные.

И этот разговор уже сильно уводит нас от темы оригинального поста. :slight_smile:

2 лайка

Я думаю, что здесь стоит настроить автоматическое удаление постов через 30 дней или около того. Я добавил это в первое сообщение. Иногда поддельные данные очень полезны. Более параноидальные из нас (включая меня) имеют реальные причины не доверять тестовому серверу, если он не был протестирован с вашими реальными данными.

4 лайка

После внедрения двухфакторной аутентификации (2FA) на нашем сайте возникло несколько проблем, поэтому я добавил следующее:

1 лайк

Вау — это было так круто! Бам-бум-бум!

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

Огромное спасибо @nathank, @pfaffman, @merefield, @JammyDodger и @Stephen… о боже!

Happy So Excited GIF

5 лайков

Я с удовольствием прочитал бы рекомендации о том, как отключить pop-опрос через командную строку.

Лучший способ — установить переменную окружения DISCOURSE_pop3_polling_enabled=false

Вам нужно написать название переменной заглавными буквами, но я не могу сделать это со своего телефона.

2 лайка

Недавно я перенес производственный форум на S3 и CloudFront. У меня уже был запущен тестовый сервер, но теперь он отстает от производственной среды и S3, так как я не уверен, нужен ли мне отдельный бакет и подключение CDN. Мне не хочется нести дополнительные расходы AWS только из-за тестового сервера. Предполагается, что указание обоих серверов на один и тот же бакет S3 не рекомендуется? Как правильно это сделать?

1 лайк