Если вы выполняете обновления через интерфейс, в конечном итоге вы получите сообщение о том, что необходимо выполнить обновление через командную строку. Это зависит не от Debian, а от базового образа Discourse.
2 лайка
И при методе с двумя контейнерами кнопки обновления GUI вообще не будет, верно?
Обновление графического интерфейса поступает из плагина discourse_docker. Если у вас установлен этот плагин, у вас есть обновление графического интерфейса.
Когда обнаруживаются уязвимости в инструментах обработки изображений, в прошлом точно случались исключения при удаленном выполнении кода, что означает: вам достаточно загрузить одно изображение, чтобы система была скомпрометирована.
Clear Linux задала стандарт скорости загрузки на Linux. Это потрясающая работа, полностью поддерживаю.
1 лайк
О, тогда это немного меняет дело. По какой-то причине я думал, что обновлятор GUI не будет работать с нестандартной установкой на 2 контейнера. В таком случае, если администратор обладает достаточными техническими навыками, у установки на 2 контейнера, похоже, нет особых недостатков. Мне определённо нужны обновления GUI; например, если я в поездке только с телефоном и выходит крупное обновление безопасности Discourse, я смогу хотя бы применить его без доступа по SSH.
1 лайк
Это моя позиция. Вам в основном нужно просто достаточно внимательно следить за обновлениями Postgres или Redis, которые требуют пересборки контейнера с данными. Также нужно знать, как выполнить ./launcher bootstrap web_only && ./launcher destroy web_only; ./launcher start web_only, но это не так уж сложно. Можно просто сделать ./launcher rebuild web_only, но в этом случае сайт будет недоступен во время пересборки.
2 лайка
Для полноты картины: сборка веб-интерфейса обычно не вызывает простоя; процесс bootstrap/destroy/start всё же подразумевает минимальный простой, и выполнять его следует как обычно — с внешней страницей обслуживания, как описано в документации для внешнего nginx. В любом случае это хорошая практика, даже если только для получения IPv6-адресов внутри контейнера.
Отлично, спасибо. А при установке с двумя контейнерами вы всё ещё получаете уведомления из панели управления Discourse о необходимости пересборки контейнера? И в таком случае я мог бы решить, пересобирать только контейнер приложения или также и контейнер данных?
1 лайк
Да. Я вижу это прямо сейчас, потому что не применил обновление 3.1.0.beta1 с пометкой «изменилась только версия». 
1 лайк
Это классический случай «всё хорошо, пока не становится плохо» — люди паникуют, когда обновление в интерфейсе не удаётся, и не знают, что нужно выполнить git pull; ./launcher rebuild app, чтобы обойти проблему. Мне кажется, это происходит каждый раз, когда вносится изменение, делающее обновление GUI неактуальным. Так случилось и на этот раз:
Мне кажется, эта паника подчёркивает ценность наличия последовательного, стандартного механизма обновлений, который позволяет избежать подобного опыта.
В то же время я столкнулся с ещё одним, тоже редким случаем: запуск (bootstrap) ломает работающую систему. Обновления с почти нулевым временем простоя иногда дают сбои подобным образом, возможно, один-два раза в год в среднем? Поэтому не делайте задержку между этапами bootstrap и destroy/start.
Мне стоит обновить текст, чтобы это стало понятнее, поэтому я займусь этим следующим.
Я ещё не развернул LibreTranslate, но рассматриваю эту возможность, чтобы сделать свой сайт доступнее для международной аудитории.
Если мне это удастся, я добавлю эту информацию в исходный пост. 
3 лайка
Многое из этого мне не совсем понятно, но я хочу сказать спасибо, потому что несколько настроек, которые вы упомянули вместе с рекомендациями по их изменению и объяснением последствий для работы сообщества, уже были для меня чрезвычайно ценны!
4 лайка
Рад, что это оказалось полезным даже для тех, кто не входит в мою целевую аудиторию. 
Я использовал это пару дней назад, чтобы развернуть новый экземпляр Discourse, и это помогло и мне, так как я сам не помню всех этих деталей. 
6 лайков
Похоже, в вики есть ошибка в настройке THP.
У меня возникли проблемы с Redis на Ubuntu:
Ваше сетевое соединение Redis работает крайне медленно. Последние показания RTT: [96585, 101554, 97189, 99769, 94618], в идеале они должны быть < 1000. Убедитесь, что Redis запущен в той же AZ или дата
Я считал, что THP уже отключен (следуя вики), но оказалось, что он всё ещё включён 
. Отключение THP, насколько я помню, решило проблему в конце прошлого года.
Ubuntu 24.04 LTS (следуя текущей вики):
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never
echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
cat /etc/sysctl.d/10-huge-pages.conf
# вывод:
# sys.kernel.mm.transparent_hugepage.enabled=never
sudo sysctl --system
# вывод:
* Applying /usr/lib/sysctl.d/10-apparmor.conf ...
* Applying /etc/sysctl.d/10-bufferbloat.conf ...
* Applying /etc/sysctl.d/10-console-messages.conf ...
* Applying /etc/sysctl.d/10-huge-pages.conf ...
* Applying /etc/sysctl.d/10-ipv6-privacy.conf ...
* Applying /etc/sysctl.d/10-kernel-hardening.conf ...
* Applying /etc/sysctl.d/10-magic-sysrq.conf ...
* Applying /etc/sysctl.d/10-map-count.conf ...
* Applying /etc/sysctl.d/10-network-security.conf ...
* Applying /etc/sysctl.d/10-ptrace.conf ...
* Applying /etc/sysctl.d/10-zeropage.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /etc/sysctl.d/99-cloudimg-ipv6.conf ...
* Applying /usr/lib/sysctl.d/99-protect-links.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.apparmor_restrict_unprivileged_userns = 1
net.core.default_qdisc = fq_codel
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
kernel.kptr_restrict = 1
kernel.sysrq = 176
vm.max_map_count = 1048576
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
kernel.pid_max = 4194304
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_regular = 2
fs.protected_symlinks = 1
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never
AlmaLinux 10 (следуя текущей вики):
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never
echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
cat /etc/sysctl.d/10-huge-pages.conf
# вывод:
# sys.kernel.mm.transparent_hugepage.enabled=never
sudo sysctl --system
# вывод:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /etc/sysctl.d/10-huge-pages.conf ...
* Applying /usr/lib/sysctl.d/10-map-count.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
vm.max_map_count = 1048576
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never
Возможно, это подойдёт для вики? На Ubuntu 24.04 и AlmaLinux 10 это сработало при тестировании:
echo 'w /sys/kernel/mm/transparent_hugepage/enabled - - - - never' | sudo tee /etc/tmpfiles.d/10-huge-pages.conf
sudo systemd-tmpfiles --create /etc/tmpfiles.d/10-huge-pages.conf
Для подтверждения:
cat /sys/kernel/mm/transparent_hugepage/enabled
Ожидаемый вывод:
always madvise [never]
Хорошо это слышать — если мы не знаем, помогает ли это, мы можем просто подражать друг другу!
1 лайк
Я не думаю, что /etc/sysctl.d устарел. Посмотрите, пожалуйста, другие файлы в этом каталоге и выясните, какой из них переопределяет /etc/sysctl.d/10-huge-pages.conf. Возможно, это один из файлов с приоритетом 50?
Более правильное решение, вероятно, — изменить приоритет настройки huge-pages так, чтобы она имела преимущество. Однако я в данный момент не использую ни одну из этих версий на своих системах.
Также проверьте, не переопределяет ли эту настройку tuned.
1 лайк
У меня возникла проблема только с применением конфигурации THP, тогда как vm.overcommit.memory применился как ожидалось через /etc/sysctl.d. Это было замечено и устранено на сервере в конце прошлого года. Поэтому вчера я решил проверить это на нескольких микро-VPS.
Только что попробовал это на свежем микро-VPS с AlmaLinux 9, чтобы понять, влияют ли какие-либо файлы конфигурации по умолчанию на конфигурацию THP:
echo always | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# always
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never
sysctl --system
# вывод:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# [always] madvise never
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# never
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# always madvise [never]
sysctl --system
# вывод:
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
* Applying /usr/lib/sysctl.d/50-default.conf ...
* Applying /usr/lib/sysctl.d/50-libkcapi-optmem_max.conf ...
* Applying /usr/lib/sysctl.d/50-pid-max.conf ...
* Applying /usr/lib/sysctl.d/50-redhat.conf ...
* Applying /etc/sysctl.d/99-sysctl.conf ...
* Applying /etc/sysctl.conf ...
kernel.yama.ptrace_scope = 0
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
kernel.core_pipe_limit = 16
fs.suid_dumpable = 2
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.eth0.rp_filter = 2
net.ipv4.conf.eth1.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 2
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.eth0.accept_source_route = 0
net.ipv4.conf.eth1.accept_source_route = 0
net.ipv4.conf.lo.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.eth0.promote_secondaries = 1
net.ipv4.conf.eth1.promote_secondaries = 1
net.ipv4.conf.lo.promote_secondaries = 1
net.ipv4.ping_group_range = 0 2147483647
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_regular = 1
fs.protected_fifos = 1
net.core.optmem_max = 81920
kernel.pid_max = 4194304
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.eth0.rp_filter = 1
net.ipv4.conf.eth1.rp_filter = 1
net.ipv4.conf.lo.rp_filter = 1
cat /sys/kernel/mm/transparent_hugepage/enabled
# вывод:
# always madvise [never]
Вот почему я прошу вас проверить фактические файлы, чтобы найти, что переопределяет эту настройку, чтобы я мог внести обоснованное изменение в приоритет, который я рекомендую для переопределения.
1 лайк
Мое текущее (ограниченное) понимание таково, что команды/выводы из моего предыдущего поста указывают на отсутствие переопределения.
Просматривая файлы на свежем экземпляре AlmaLinux 9:
Эти команды ничего не нашли:
grep -r "transparent_hugepage" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "transparent" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "huge" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
grep -r "page" /usr/lib/sysctl.d/ /etc/sysctl.d/ /etc/sysctl.conf
Значения по умолчанию в файлах конфигурации:
/usr/lib/sysctl.d/50-redhat.conf:kernel.kptr_restrict = 1
/usr/lib/sysctl.d/50-redhat.conf:net.ipv4.conf.default.rp_filter = 1
/usr/lib/sysctl.d/50-redhat.conf:net.ipv4.conf.*.rp_filter = 1
/usr/lib/sysctl.d/50-redhat.conf:-net.ipv4.conf.all.rp_filter
/usr/lib/sysctl.d/10-default-yama-scope.conf:kernel.yama.ptrace_scope = 0
/usr/lib/sysctl.d/50-libkcapi-optmem_max.conf:net.core.optmem_max = 81920
/usr/lib/sysctl.d/50-coredump.conf:kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h
/usr/lib/sysctl.d/50-coredump.conf:kernel.core_pipe_limit=16
/usr/lib/sysctl.d/50-coredump.conf:fs.suid_dumpable=2
/usr/lib/sysctl.d/50-default.conf:kernel.sysrq = 16
/usr/lib/sysctl.d/50-default.conf:kernel.core_uses_pid = 1
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.rp_filter = 2
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.rp_filter = 2
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.rp_filter
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.accept_source_route = 0
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.accept_source_route = 0
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.accept_source_route
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.default.promote_secondaries = 1
/usr/lib/sysctl.d/50-default.conf:net.ipv4.conf.*.promote_secondaries = 1
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.conf.all.promote_secondaries
/usr/lib/sysctl.d/50-default.conf:-net.ipv4.ping_group_range = 0 2147483647
/usr/lib/sysctl.d/50-default.conf:-net.core.default_qdisc = fq_codel
/usr/lib/sysctl.d/50-default.conf:fs.protected_hardlinks = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_symlinks = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_regular = 1
/usr/lib/sysctl.d/50-default.conf:fs.protected_fifos = 1
/usr/lib/sysctl.d/50-pid-max.conf:kernel.pid_max = 4194304
Я использую AlmaLinux 9 для своих экземпляров Discourse, и предоставленная мною конфигурация успешно отключила THP на всех из них. Если отключение THP через sysctl.d не работает при отсутствии переопределений, и tuned не переопределяет его, я бы подумал, что это ошибка.
Мне показалось, что вы говорили, что это больше не работает в AlmaLinux 10, поэтому я и спрашивал, что мешает его применению там.