Отлично. Нет, это будет идеально. Ещё раз спасибо! Очень признателен.
1 лайк
Команда теперь ./discourse-setup --two-container
только что сработала как ожидалось 
2 лайка
Отличное замечание! Появилось ли сообщение, которое помогло это понять?
Я давно собирался привести эту тему в порядок, так как они изменились.
1 лайк
Да, очень полезно, спасибо.
2 лайка
Есть ли планы на миграцию с устаревшего механизма «ссылок контейнеров» на корректную настройку с использованием пользовательской сети, к которой подключены два контейнера?
«Ссылки» являются устаревшими и могут быть удалены в будущем, согласно документации Docker
1 лайк
Звучит как хорошая идея.
Если кто-то не сделает это раньше меня, я попробую создать PR в подмодуле для перехода на сети и/или сокеты (что некоторые и так предпочитают), а также напишу инструкцию по конвертации существующей настройки в новую конфигурацию.
5 лайков
@pfaffman Не знаю, успел ли ты это сделать, но если успел, не хочешь дать на это ссылку здесь? 
3 лайка
Стоит ли добавить && ./launcher cleanup в конец этих команд?
После перехода на установку с двумя контейнерами я заметил, что старыми образами дисковое пространство быстро заполняется.
1 лайк
Я определённо рекомендую это в своём руководстве… Многие развёртывают на небольших системах, таких как DO Droplets, и я знаю, что помогал другим, кто не до конца понимал, куда уходит их дисковое пространство.
2 лайка
@pfaffman, Здравствуйте,
Несколько дней назад я установил AWS EC2 с одним контейнером, и всё работало отлично. Но мне нужна именно конфигурация с двумя контейнерами: web_only на EC2 и data на AWS RDS (PostgreSQL 15.3 на порту 5432 — я не могу выбрать другую версию, и в базе данных нет параметра DB_NAME). В качестве кластера Redis я попробовал использовать AWS ElastiCache, но затем оставил ссылку в data.yml на существующий шаблон:
#- "templates/postgres.template.yml"
- "templates/redis.template.yml"
После успешной первоначальной настройки data и web_only я не могу открыть веб-страницу. «Этот сайт недоступен»
Я не вносил изменений в записи DNS и не менял настройки доступа в группах безопасности AWS (фаервол для веб-сервера и базы данных).
Successfully bootstrapped, to startup use ./launcher start data
root@ip-172-31-3-68:/var/discourse# ./launcher start data
x86_64 arch detected.
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -h ip-172-31-3-68-data -e DOCKER_HOST_IP=172.17.0.1 --name data -t -v /var/discourse/shared/data:/shared -v /var/discourse/shared/data/log/var-log:/var/log --mac-address <...> local_discourse/data /sbin/boot
27b66e577d250e4178f5e145c9962be7b5f2d905cfacd233d3d2278e7b83aa93
Successfully bootstrapped, to startup use ./launcher start web_only
root@ip-172-31-3-68:/var/discourse# ./launcher start web_only
x86_64 arch detected.
+ /usr/bin/docker run --shm-size=512m --link data:data -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET= -e DISCOURSE_DB_HOST=database-discourse.<..>.rds.amazonaws.com -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e DISCOURSE_HOSTNAME=talk.furtherium.com -e DISCOURSE_DEVELOPER_EMAILS=hello@furtherium.com -e DISCOURSE_SMTP_ADDRESS=email-smtp.us-east-2.amazonaws.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=A<...>S -e DISCOURSE_SMTP_PASSWORD=B<...>M -e DISCOURSE_NOTIFICATION_EMAIL=noreply@talk.furtherium.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -e DISCOURSE_DB_NAME= -e DISCOURSE_DB_USERNAME=postgres -e DISCOURSE_DB_PASSWORD=7<...>1 -e DISCOURSE_REDIS_HOST=data -h ip-172-31-3-68-web-only -e DOCKER_HOST_IP=172.17.0.1 --name web_only -t -p 80:80 -p 443:443 -v /var/discourse/shared/web-only:/shared -v /var/discourse/shared/web-only/log/var-log:/var/log --mac-address <...> local_discourse/web_only /sbin/boot
1233f1c660eb7cecc48d2a840aae037b46ecfd7afe029ef89b2e686b136b9886
- Я проверил подключение к базе данных через SSH с помощью telnet — ОК
- Я вижу подключения к базе данных в панели управления AWS RDS
- Я перезагружал экземпляры 3 раза
- Я запускал rebuild 3–4 раза без ошибок
- Я проверил список активных контейнеров и образов, удалил лишние
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1233f1c660eb local_discourse/web_only "/sbin/boot" 18 minutes ago Up 18 minutes 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp web_only
27b66e577d25 local_discourse/data "/sbin/boot" 47 minutes ago Up 47 minutes data
Что ещё я могу сделать? Спасибо за ваши усилия и время!
Вам это не нужно. Вам требуется только веб-контейнер, а шаблоны Postgres и Redis нужно удалить. Elasticache, на мой взгляд, неоправданно дорог, поэтому, если вы используете один хост, вы можете запустить его на EC2.
Просто добавьте переменные окружения в ваш существующий app.yml и удалите ненужные шаблоны. Недавно я слышал, что этот сайт работает на PG15, так что всё должно быть в порядке.
Спасибо за ответ, Джей (@pfaffman). Хочу уточнить:
- Стоит ли мне использовать установку
app.ymlс одним контейнером и раскомментировать строки, касающиеся базы данных и Redis? А также в поле ENV файлаapp.ymlдобавить строки для удалённой базы данных в AWS (DB_USER и т. д. — из конфигурации web_only, как сейчас)? - Или оставить всё как есть, но остановить контейнер данных и оставить только веб-контейнер?
- Если я не буду использовать ElastiCache, нужно ли оставить строку “templates/redis.template.yml”?
Переход со стандартной конфигурации на двухконтейнерную прошел почти гладко. Я потратил довольно много времени из-за отсутствующих пробелов в YAML-файле, которые заставили меня подумать, что проблема в локализации (что было далеко от истины), но это была ошибка с моей стороны.
Однако, когда форум запустился, он оказался абсолютно пустым. Исправить это было довольно легко, так как у меня была актуальная резервная копия в S3, но теперь я задаюсь вопросом, почему это произошло изначально — есть какие-то предположения?
То есть, если бы я пошел по пути полной установки новой двухконтейнерной конфигурации, а затем восстановил её из резервных копий, это могло бы сэкономить время. Или нет, потому что мне всё равно пришлось бы редактировать YAML-файл, по крайней мере, добавлять плагины, настраивать email, MaxMind и т. д.
1 лайк
[Не относится к посту выше]
Интересует, в чём преимущество использования двухконтейнерной конфигурации? Почему не обычный одиночный контейнер?
Я думаю, это нужно для того, чтобы ваш форум не был недоступен во время перестроения при обновлении или установке плагина.
2 лайка
Для меня уже упомянуто короткое время простоя. Кроме того, я часто обновляюсь — как минимум раз в неделю, поэтому моя настройка склонна сталкиваться с ошибками. Нужно признать, что не слишком часто, но время от времени всё же.
В те моменты, когда причина в плагине — что бывает нечасто, обычно это какой-то компонент — мне требуется три-четыре попытки, чтобы найти проблемный элемент. А когда каждая попытка занимает около 30 минут, мой форум оказывается недоступным слишком долго, даже если он небольшой и создан для хобби.
И третья причина в том, что я могу это сделать.
2 лайка
Для меня крайне стрессово, когда сборка завершается неудачей и мой сайт перестаёт работать. По сути, это требует моего немедленного (а иногда и продолжительного) внимания, чтобы разобраться и найти обходной путь. Совсем не весело!!!
Двухконтейнерная установка превращает это в обычное неудобство, и основную проблему обычно можно решить в удобное для меня время. Кроме того, к тому моменту проблема, вызвавшая сбой, часто уже устранена.
Если использовать ветку stable, я, вероятно, не стал бы заморачиваться. Но при работе ближе к «краю» с веткой tests-passed это неоценимо для повышения устойчивости во время сборок и обновлений.
2 лайка
А, понятно. Спасибо за объяснение!
Я совершенно забыл, что даже писал это!
1 лайк
Отличный туториал. У меня ушло всего 5 минут: на новом сервере я создал и восстановил резервную копию, затем выполнил ./discourse-setup --two-container.
Спасибо
2 лайка
Может ли кто-нибудь объяснить, почему этот шаг необходим, если вы переносите существующий сервер с рабочей базой данных?
Я понимаю, что создание безопасной резервной копии на удалённом сервере непосредственно перед миграцией — это хорошая практика, но зачем её скачивать?
2 лайка