Я понимаю, что это непростая задача. Однако цель контейнеров — обеспечить согласованное и переносимое состояние. Поэтому, если контейнеры используются по назначению и у вас всё работает, то с высокой долей вероятности они будут работать и у всех остальных, кто использует этот контейнер.
Если сам процесс инициализации (bootstrap) перенести внутрь контейнера, а не выполнять его на хост-системе, это уже значительно повысит его переносимость. Я могу заняться этим после завершения других проектов. Я тоже не эксперт в области контейнеров, но создавал несколько из них. Однако есть один недостаток: отсутствует документация по установке, верно? Всё сводится к тому, что вам просто дают скрипт и говорят: «Запустите его». Я могу попытаться воспроизвести то, что делает этот скрипт, но тогда у вас останется мало возможностей для внесения предложений по улучшению.
Таким образом, если сообщество, особенно люди, непосредственно вовлечённые в процесс и обладающие внутренней информацией о том, как должна работать установка, готовы дать совет или помочь, я готов начать эту инициативу. В противном случае качество не будет соответствовать вашим ожиданиям.
Цели будут примерно следующими:
- Dockerfile, обеспечивающий атомарную сборку конфигурации (без локального bootstrap вне контейнера);
- Отсутствие необходимости запускать контейнер от имени root; предпочтительно использовать fakeroot и добавлять capabilities (это аргументы командной строки, пользователи всё ещё могут при желании запускать контейнер от root…);
- Создание скрипта entrypoint, который можно настраивать с помощью переменных окружения, которые должны быть чётко задокументированы;
- Использование
podman-generate-systemdили аналогичного инструмента для создания systemd-юнита, позволяющего (пере)запускать контейнер или запускать его при загрузке системы (функция Podman; возможно, у Docker есть что-то похожее, но акцент делается на интеграцию этого процесса).
Это касается базовой установки. Для масштабируемого решения потребуется docker-compose и решение на базе Kubernetes. Честно говоря, я не считаю, что сообщество Discourse должно отвечать за создание универсального решения «под ключ». Поскольку такие вещи можно очень тонко настраивать, особенно в Kubernetes. Поэтому, полагаю, базовое решение на основе compose будет достаточно для того, чтобы пользователи могли быстро разобраться.
Это обеспечит переносимое и более безопасное решение, что в целом повысит уровень внедрения и качество. Тем временем я посмотрю, действительно ли Discourse нужен для моего сообщества. Если да, то пока я буду использовать Ubuntu LTS. Как только у меня появится больше времени, я займусь внедрением такой конфигурации.