Привет, ребята.
Возможно ли — даже если это официально не покрыто/не поддерживается — настроить Discourse/контейнер для более быстрого запуска/загрузки? (за исключением настройки ресурсов самого хоста и контейнера)
Вы можете попробовать использовать несколько файлов контейнеров вместо одного отдельного файла app.yml.
Но будем честны: почти никому не нужно часто пересобирать контейнеры, верно?
Если вам нужно установить плагины, пересобирать контейнер не обязательно. У меня есть неофициальные способы установки плагинов без пересборки.
Вы действительно имеете в виду более быстрый запуск, то есть начало обслуживания страниц раньше после перезапуска контейнера? Нет. Просто требуется время для запуска Rails и всех остальных компонентов.
Если же вы имеете в виду время простоя, связанное с пересборкой контейнера, то решение с двумя контейнерами — это то, что вам нужно.
А если этого недостаточно и вам нужно отсутствие простоев, то можно использовать балансировщик нагрузки: запустить новый контейнер, пока старый продолжает обслуживать страницы, а затем отключить старый, когда новый будет готов.
Я не обязательно имею в виду полную пересборку.
Допустим, вы управляете всем этим с помощью docker — как я и предпочитаю.
Даже перезапуск контейнера docker заставляет Discourse выполнять длинный список действий при загрузке. Да, именно это я и имел в виду. Можно ли это настроить или сократить (в части Ruby/Rails)? Почему при каждом запуске выполняется всё это? Неужели нельзя сохранить состояние?
Решение с двумя контейнерами — что это?
Это два контейнера с непересекающимися компонентами, работающие на одном хосте и обращающиеся к одним и тем же внешним PostgreSQL и Redis?
Или это настройка для обеспечения работы без простоев?
Оно должно прочитать множество строк кода, чтобы быть готовым к обслуживанию запросов. Вы когда-нибудь включали свой телефон, компьютер или современный телевизор? Это занимает некоторое время. Здесь всё точно так же. В контейнере находится целая операционная система.
Да. Rails и nginx вынесены в отдельный контейнер, а PostgreSQL и Redis — в другой (или как вы захотите организовать работу Redis и PostgreSQL).