Я уже какое-то время запускаю Discourse в кластере Kubernetes, используя неподдерживаемый образ от Bitnami. Поскольку Bitnami прекращает поддержку этого образа и переводит его за платный доступ, я планирую миграцию нашего сервера на собственное решение, размещенное в AWS.
У меня есть несколько вопросов, по которым я был бы очень признателен за помощь сообщества:
Мы уже используем внешнюю базу данных PostgreSQL для установки, и она останется без изменений. Однако мы обновляли некоторые настройки через интерфейс пользователя, а также с помощью переменных окружения, которые скрипты установки Bitnami сопоставляют с настройками Discourse. Например, DISCOURSE_S3_BACKUP_BUCKET сопоставляется с S3_BACKUP_BUCKET.
Достаточно ли будет задать настройки Discourse в необходимых YAML-файлах, или всё ещё следует использовать переменные окружения?
Если мы создадим резервную копию через интерфейс, что именно будет восстановлено — обновится ли база данных?
Лучше ли создать новую базу данных с чистой установкой, а затем выполнить восстановление из резервной копии?
Если новая установка будет использовать более новую версию Discourse, возникнут ли проблемы при попытке восстановления?
Стандартное руководство по установке использует Docker. Как вы мониторите контейнеры в производственной среде, учитывая, что стандартная установка представляет собой одну виртуальную машину с Docker?
Существуют ли какие-либо документы, подробно описывающие процесс миграции и возможные подводные камни?
Я уверен, что в процессе миграции у меня возникнет ещё много вопросов, но любая консультация или помощь будут очень кстати.
Если это ещё не было в ваших планах, я бы рекомендовал создать новую базу данных (на том же сервере) для миграции, чтобы не нарушить работу существующего сайта.
Я не совсем понимаю, что вы считаете, что делает Bitnami, но переменная, которую вам нужно задать в ENV, — это DISCOURSE_S3_BACKUP_BUCKET. См. Настройка совместимого с S3 провайдера объектного хранилища для загрузок, чтобы узнать, как правильно задать эти переменные S3 в вашем файле app.yml.
Если под «лучше» вы имеете в виду «не приведёт ли это к тому, что я сломаю существующий сайт и оставлю его в состоянии, из которого он никогда не восстановится?», то ответ — да.
Это именно то, что нужно. Версия системы, из которой вы восстанавливаете, должна быть такой же или новее версии резервной копии. После восстановления база данных будет автоматически мигрирована.
Возможно, этой информации вам достаточно, и мы с радостью поможем вам здесь бесплатно. Если вы хотите получить персональную помощь, адаптированную под вашу конкретную настройку, вы можете связаться со мной или запросить помощь в канале Marketplace.
Также ещё один вариант — создать образы и запустить их в Kubernetes. Я делал это несколько раз и использовал GitHub для сборки образов.
Мой опыт подтверждает это. За годы я столкнулся с таким количеством странных мелких сбоев, что всегда делаю полные резервные копии, чтобы иметь возможность начать с нуля и восстановить сайт. Попытки исправлять проблемы на месте рано или поздно приведут к неудаче.
Как и вы, я оказался в тупике, когда Bitnami прекратила предоставлять бесплатные образы и графики. Мне пришлось адаптироваться и мигрировать множество развертываний. Одним из них было развертывание Discourse. Если это будет вам полезно, вот ссылка на заменяющий Helm-чарт, который я создал за очень короткое время (что означает, что он работает, но далеко от идеального дизайна). Это попытка использовать «официальный метод установки», поскольку за все эти годы так и не появился «стандарт сообщества» в виде Helm-чарта. (Полагаю, чарт Bitnami фактически был таким стандартом, так как немногие из нас предвидели такие резкие изменения.) В любом случае, этот новый чарт, который я использую для одного из моих исследовательских сообществ, по сути представляет собой под с двумя контейнерами: официальный контейнер Docker-in-Docker и пользовательский контейнер на основе python:3, который устанавливает Docker, а затем использует официальную установку Discourse. Поскольку все компоненты (сервер Discourse, Redis, PostgreSQL) работают внутри «черного ящика» локального образа, созданного скриптом запуска, масштабируемость или поддержка высокой доступности отсутствуют. Мне удалось сократить время простоя при перезапуске пода на другом узле (например, при выводе узла из эксплуатации для обновления ОС или при сбое узла), используя docker save для сохранения собранного образа на постоянный том, а затем загружая его, если local_discourse/app:latest не найден.
Но чтобы ответить на ваш вопрос: я не знаю, как мониторить что-либо в этом новом развертывании. Я работаю «в продакшене», но мое сообщество достаточно мало, а использование умеренное, поэтому, если форум временно недоступен, это не проблема. Тем не менее, я очень близок к тому, чтобы отказаться от самостоятельного хостинга и перейти на такой сервис, как Communiteq или Discourse.org.
