People,
I know Discourse has standardised on Docker for distribution and support but it seems to me there are some reasonable arguments for also making Discourse available as a Podman container? I would be happy to have a go at producing something if at least one clued-up dev was prepared to help me . .
Regards,
Phil.
It is unlikely we can spend any time on it, but if you want to give it a go, go for it.
Thanks for the fast reply Jeff!
I will see if I can get some enthusiam going from the appropriate Fedora group . .
@codinghorror , Can you point me to a HOWTO for a completely manual install somewhere? - I have some familiarity with Rails etc . .
Here are the instructions: Beginners Guide to Install Discourse on Ubuntu for Development.
If you look at the install script in the Install Discourse Dependencies section of the guide, you’ll find the manual instructions there.
Thanks!
I will check it out . .
Docker для RHEL 8 заменён на Podman.
Логично начать поддержку установки Podman, чтобы не потерять клиентов RHEL (и CentOS).
Согласно официальному сайту Podman,
Если говорить просто: «alias docker=podman»
что демонстрирует высокую совместимость с Docker.
Показатель ROI выглядит достойно?
Поскольку рекомендуемая установка не использует пакет Docker, поставляемый репозиторием, я не уверен, что это имеет значение в любом случае.
Пока сами разработчики Docker не прекратят поддержку дистрибутива, у нас всё в порядке.
Я точно не знаю, сколько усилий потребуется для поддержки Podman, но мне кажется, что корпоративные клиенты не любят уровень поддержки «вероятно, в порядке».
Если вы используете RHEL (CentOS) 8 или новее, вам придётся устанавливать Docker из внешнего репозитория, возможно, параллельно с Podman, и этот сценарий не поддерживается Red Hat. Либо можно использовать Podman для установки образа Docker, но это не поддерживается Discourse.
Надеюсь, что в будущем это будет официально поддерживаться.
Полагаю, что после выхода CentOS 8 этому вопросу уделят больше внимания.
Docker уже поддерживается в CentOS 8 и, соответственно, в RHEL 8. Мне неизвестны какие-либо сценарии, в которых вы бы запускали их одновременно. Не упустил ли я что-то?
Скорее всего, неверно утверждать, что Docker был вытеснен Podman; верно лишь то, что теперь Podman поставляется по умолчанию. В конце концов, кто использует версию Docker, входящую в дистрибутив?
Обязанность по поддержке всегда лежала на Docker, а не на Red Hat. Как упоминалось выше, рекомендация всегда заключалась в использовании пакета Docker, а не той версии, которая входит в дистрибутив.
На самом деле всё наоборот, но на связанной странице Red Hat сказано:
Пакет
dockerне поставляется и не поддерживается Red Hat для Red Hat Enterprise Linux (RHEL) 8.
Контейнерный движок
podmanзаменилdockerв качестве предпочтительного, поддерживаемого и рекомендуемого контейнерного рантайма для систем Red Hat Enterprise Linux 8.
Я не трактую это как поддержку Docker со стороны Red Hat.
Если это означает отказ от поддержки клиентов RHEL, то это решение Discourse.
Проверьте репозиторий Docker: там нет пакетов для RHEL, только для CentOS.
Podman должен быть на 100% совместим с Docker, поэтому, честно говоря, я не уверен, что нам нужно что-то делать.
Возможно, стоит немного отредактировать документ по установке, добавив ссылку на установку Podman (например, просто указать, что он поддерживается, и в самом начале упомянуть, что команду docker нужно заменить на podman), чтобы у пользователей не возникало сомнений, поддерживается ли он или нет?
Мы не будем занимать никакой конкретной позиции, пока не протестируем это.
Насколько мне известно, никто в истории человечества никогда не пытался установить Discourse с помощью Podman.
Похоже, здесь возникло некоторое недопонимание. Мы знаем о Podman, и несколько человек в нашей команде поддерживают его успех, поскольку это будет полезно для всей экосистемы FOSS. Однако:
Он не поддерживается.
Наш хостинг использует Ubuntu/Debian. Поэтому у нас в данный момент нет клиентов, работающих на RHEL.
Даже если решение работает «как есть», я бы очень скептически относился к любой идее поддержки.
Если только Docker не откажется от CentOS/RHEL, это излишне, и даже в этом случае Discourse/Docker не станут первым приложением, имеющим требования на уровне дистрибутива.
Что меня больше всего расстраивает здесь, так это соотношение спекуляций и реально проделанной работы.
Если бы вы начали с этого, моя реакция была бы иной:
Я использовал официальную установку Discourse в Docker на podman в течение последних 30 дней. Вот мелкие замечания, которые у меня возникли, и вот что мне понравилось в этой настройке!
Вся суть здесь в том, что вы требуете от нас работы, не желая экспериментировать или прилагать какие-либо усилия. Это станет большой проблемой для вас и сообщества.
Мне это очень не нравится.
Это довольно точно отражает мой ответ: мы работаем с предсказуемыми технологиями, поэтому нет ни необходимости, ни места для апокалиптических заявлений.
Я тоже не особо люблю перебранки и, наверное, должен был промолчать, а не вступать в спор.
Исходя из этого заявления, я полагал, что вам нужно проделать некоторую работу, чтобы заставить это работать, но если это должно быть на 100% совместимо и дело лишь в замене команды, это было бы замечательно.
Я предлагал, чтобы вы могли направлять тех, кто запутался, используя Podman вместо Docker.
Я точно не знаю вашу модель разработки, но полагаю, что она управляется сообществом, и пользователи должны сначала внести свой вклад.
Я попробовал заняться этим около получаса. Podman совместим с командами, но не с выводом, поэтому launcher путается, пытаясь разобрать вывод. (Различить их несложно: docker --version отвечает podman version 1.0.5, так что это не серьёзное препятствие.)
Устройства сети docker0 нет. Драйвер хранения overlay по умолчанию в Podman по сути является реализацией overlay2 и имеет псевдоним на него, но вывод не содержит слова overlay2, а вывод команды docker info немного отличается. Я использовал флаг --skip-prereqs, чтобы обойти проверки. Общие каталоги не были созданы автоматически; я не стал разбираться, почему. Я выполнил mkdir -p /var/discourse/shared/standalone/log/var-log, чтобы продолжить. Далее я столкнулся с проблемами прав доступа из-за того, что SELinux был включён в режиме принуждения, но не настроен для /var/discourse.
Если вы монтируете каталог в контейнер как том и добавляете :z или :Z, движки контейнеров переименовывают содержимое под томами в
container_file_t.
В документации по сборке Podman сказано:
Опция
zуказывает Podman, что два контейнера разделяют содержимое тома. В результате Podman помечает содержимое общим меткой. Общие метки тома позволяют всем контейнерам читать и записывать содержимое. ОпцияZуказывает Podman пометить содержимое приватной немаркированной меткой. Только текущий контейнер может использовать приватный том.
Я решил временно выполнить Я изменил setenforce 0 для этой тестовой установки и вернуться к этому позже, возможно.volumes, чтобы использовать строчную :z следующим образом:
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared:z
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log:z
С этими небольшими изменениями мне удалось запустить загрузку Discourse. Redis недоволен тем, что в ядре поддерживаются прозрачные большие страницы, и предлагает отключить это, а также изменить настройки перераспределения памяти. Вероятно, мимо меня пролетело множество других полезных сообщений отладки в мегабайтах вывода журнала!
./launcher start app
...
--restart option is not supported.
Use systemd unit files for restarting containers
Я модифицировал скрипт, чтобы не использовать --restart, и обнаружил необходимость в --skip-prereqs также в режиме start, что в итоге привело меня к попытке выполнить docker run, после чего:
./launcher start app --skip-prereqs
...
+ /usr/bin/docker run ... -e DOCKER_HOST_IP= --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared:z -v /var/discourse/shared/standalone/log/var-log:/var/log:z --mac-address 02:9c:01:9b:0e:17 local_discourse/app /sbin/boot
--mac-address option not currently supported
Так что определённо это не работает из коробки, и я не знаю, сколько усилий потребуется, чтобы доработать launcher для работы с Docker или Podman. Обработка предварительных требований была бы «работой из коробки» и, вероятно, не слишком сложной при предварительной проверке на наличие Podman, но я не знаю, насколько глубоко предположения о настройке сети проникают в конфигурацию нижних уровней, и похоже, что этот режим сети просто не поддерживается Podman.
Исходя из этого опасения, я планирую не тратить усилия на то, чтобы заставить launcher работать под Podman. Я просто сообщаю результаты первоначального быстрого эксперимента.
Тем не менее, для кого-то, кто лучше знает стек, это, вероятно, не составит большого труда. Весной этого года я проводил всю свою разработку в рамках ручной установки разработки на Fedora 29 с тривиальными корректировками, такими как использование dnf вместо apt-get и некоторыми незначительными переводами названий пакетов, вообще не используя Docker или Podman. Я предполагаю, что кто-то, кто хорошо знает Podman, а также обычное администрирование всего технологического стека Discourse, вероятно, посчитает это умеренным объёмом относительно лёгкой работы. Если бы я знал, что именно нужно сделать, то лучше понимал бы, будет ли это работа, которая, скорее всего, «устареет» и потребует постоянного обслуживания, или нет. Но… я не знаю. 