Привет! Я использую M1 для разработки автоматизации и инструментов запуска Discourse. Скрипт discourse-setup имеет проблему с определением процессоров на архитектуре ARM и завершается с ошибкой:
Из-за этого контейнер не запускается. В моём случае используется подход с двумя контейнерами (веб + данные), поэтому не запускается именно web_container.
./discourse-setup --two-container
Файл конфигурации containers/web_only.yml уже существует!
. . . переконфигурация . . .
Сохранение старого файла как web_only.yml.2022-06-12-062509.bak
Остановка существующего контейнера через 5 секунд или нажмите Control-C для отмены.
ПРЕДУПРЕЖДЕНИЕ: Поддержка aarch64 в настоящее время экспериментальная. Пожалуйста, сообщайте о любых проблемах по адресу https://meta.discourse.org/tag/arm
Нажмите любую клавишу, чтобы продолжить
ПРЕДУПРЕЖДЕНИЕ: Мы собираемся начать загрузку базового образа Discourse
Этот процесс может занять от нескольких минут до часа в зависимости от скорости вашей сети
Пожалуйста, будьте терпеливы
aarch64: получение из discourse/base
Сводка: sha256:a2ce381fdc4fed59fe160fb01b79bce0d5266f59ad907a22f3399772c8711791
Статус: Образ discourse/base:aarch64 уже актуален
docker.io/discourse/base:aarch64
ПРЕДУПРЕЖДЕНИЕ: Файл containers/web_only.yml доступен для чтения всеми. Вы можете защитить его, выполнив команду: chmod o-rwx containers/web_only.yml
web_only не был запущен!
./discourse-doctor может помочь диагностировать проблему.
./discourse-setup: строка 261: *0: синтаксическая ошибка: ожидаемый операнд (ошибочный токен "*0")
Введите доменное имя для вашего Discourse? [discourse.example.com]:
Привет, да, я тоже работаю на Linux, а не на macOS. Я использую полный образ RHEL 9, а не UBI, через UTM на M1. Таким образом, проблема действительно связана с Linux. После публикации этого PR и обсуждения я наткнулся на несколько тем, где упоминалось, что команда разработчиков использует M1, но, не углубляясь в детали, я подозреваю, что это связано с тем, что команда разработчиков использует другой способ инициализации?
Стоит ли тратить время на работу над производственной средой для M1, когда ещё нет готового к производству оборудования M1? Звучит как нецелесообразная трата времени.
Вы рассматривали вариант установки для разработки?
Кажется, здесь возникло недопонимание. Я не пытаюсь разрабатывать сам Discourse и также не планирую запускать Discourse в продакшене на M1. Мои задачи следующие:
Написание кода автоматизации для управления моей инфраструктурой
Это включает установку и периодическое обновление Discourse.
Работа будет выполняться на моем ноутбуке M1 с использованием образа RHEL9, запущенного через UTM.
Это подразумевает наличие кода автоматизации для установки и начальной настройки Discourse внутри виртуальной машины RHEL9.
Запуск Discourse на серверах с архитектурой Intel
Код автоматизации будет развернут на сервере под управлением RHEL для сред UAT и продакшена.
Таким образом, если я не ошибаюсь, никаких дополнительных изменений не требуется, поскольку я не пытаюсь запускать это на macOS. Если же необходимы какие-то дополнительные изменения помимо тех, что уже есть в PR, то, полагаю, мне придется найти подходящий сервер для выполнения этой работы. Но так ли это на самом деле? С другой стороны, есть ли какие-либо проблемы с представленным PR, которые могут помешать его слиянию, учитывая, что работа уже выполнена?
Ваш исходный пост запрашивает поддержку Apple M1 для установочного пакета производственного выпуска. Проблема в том, что не существует производственного оборудования, использующего новые процессоры Apple.
Отсюда мой вопрос: имеет ли смысл добавлять эту поддержку, когда сценарий установки в производственной среде на M1 невозможен?
Разве не логичнее разрабатывать это в среде, где ваше оборудование более точно отражает финальный сценарий установки?
Должно быть, здесь какое-то недопонимание. В исходном посте я написал: «Я использую M1 для разработки автоматизации и инструментов, чтобы запустить Discourse». Это для разработки автоматизации, а не для запуска самого Discourse. Да, было бы здорово запускать его на репрезентативном оборудовании, но речь идёт именно о разработке инструментов для установки и запуска Discourse и ничего более. Иногда я в пути и хочу иметь возможность делать это только с помощью моего ноутбука на M1, без привязки к машинам, находящимся в каком-то дата-центре, где мне пришлось бы настраивать VPN-подключение.
Я понимаю, что вы пытаетесь сделать. Всё, что я хочу сказать, это то, что установка в производственной среде не работает на M1, потому что M1 не может использоваться в продакшене.
Это не совсем верно. Например, Raspberry Pi использует SoC на базе ARM, и установка Discourse проходит без проблем, согласно:
Хорошо, похоже, я ошибся, сказав, что это процессор на базе ARM, поскольку проблема возникает только на M1?
В любом случае, вот что я сделал…
Создал новую ветку discourse-setup успешно выполнился с изменениями из PR, но затем запустился launcher, который проверил, есть ли у меня актуальный код в master. Поэтому я создал новую ветку и поместил изменения туда. Также я добавил запись в /etc/hosts, чтобы при проверке домена система считала, что я работаю на указанном домене, и тест прошел успешно.
Запустил discourse-setup снова
На этот раз всё прошло успешно, включая запуск launcher для сборки и создание контейнера.
Ниже показано, что я увидел в конце вывода. Я попытался перейти по адресу http://127.0.0.1, но увидел только страницу по умолчанию от nginx. Вероятно, на M1 это всё-таки не работает из-за каких-то других проблем. Протестирую на настоящей системе на базе Intel. Хотя для проверки того, что процесс работает и что-то слушает порты 80/443, это достаточно, но было бы здорово иметь возможность реально обслуживать страницу.
I, [2022-06-14T15:29:42.810750 #1] INFO -- : Замена (?-mix:#?ACCOUNT_EMAIL=.+) на ACCOUNT_EMAIL=$$ENV_LETSENCRYPT_ACCOUNT_EMAIL
в /shared/letsencrypt/account.conf
I, [2022-06-14T15:29:42.811886 #1] INFO -- : Замена (?-mix:ssl_certificate_key.+) на ssl_certificate_key /shared/ssl/$$ENV_DISCOURSE_HOSTNAME.key;
ssl_certificate_key /shared/ssl/$$ENV_DISCOURSE_HOSTNAME_ecc.key;
в /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.812148 #1] INFO -- : Замена (?-mix:add_header.+) на add_header Strict-Transport-Security 'max-age=63072000'; в /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.812430 #1] INFO -- : Замена location @discourse { на location @discourse {
add_header Strict-Transport-Security 'max-age=31536000'; # запомнить сертификат на год и автоматически подключаться к HTTPS для этого домена в /etc/nginx/conf.d/discourse.conf
I, [2022-06-14T15:29:42.813521 #1] INFO -- : > echo "Начало пользовательских команд"
I, [2022-06-14T15:29:42.814803 #1] INFO -- : Начало пользовательских команд
I, [2022-06-14T15:29:42.814856 #1] INFO -- : > echo "Конец пользовательских команд"
I, [2022-06-14T15:29:42.816137 #1] INFO -- : Конец пользовательских команд
I, [2022-06-14T15:29:42.818177 #1] INFO -- : Завершение асинхронных процессов
I, [2022-06-14T15:29:42.819361 #1] INFO -- : Отправка INT для HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main pid: 57
2022-06-14 15:29:42.819 UTC [57] LOG: получен запрос быстрого завершения работы
I, [2022-06-14T15:29:42.820068 #1] INFO -- : Отправка TERM для exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 118
118:signal-handler (1655220582) Получен SIGTERM, планирование завершения работы...
2022-06-14 15:29:42.829 UTC [57] LOG: прерывание всех активных транзакций
2022-06-14 15:29:42.832 UTC [57] LOG: фоновый рабочий "logical replication launcher" (PID 66) завершился с кодом выхода 1
2022-06-14 15:29:42.835 UTC [61] LOG: завершение работы
118:M 14 Jun 2022 15:29:42.866 # Пользователь запросил завершение работы...
118:M 14 Jun 2022 15:29:42.867 * Сохранение финального снимка RDB перед выходом.
118:M 14 Jun 2022 15:29:42.876 * База данных сохранена на диск
118:M 14 Jun 2022 15:29:42.876 # Redis готов к выходу, пока...
2022-06-14 15:29:42.958 UTC [57] LOG: система баз данных завершена
sha256:5f552461c03594fde4b917c0e995c5f63a777b44ee1638e0367c22a29fe1ec16
ef60feb320f8684423dcb5c3ca6062226d937cd72a642485052fa641f15cbc01
+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=4 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e DISCOURSE_FORCE_HTTPS=true -e LC_ALL=en_US.UTF-8 -e LANGUAGE=en_US.UTF-8 -e EMBER_CLI_PROD_ASSETS=1 -e DISCOURSE_HOSTNAME=dev.bogus.com -e DISCOURSE_DEVELOPER_EMAILS=support@bogus.com -e DISCOURSE_SMTP_ADDRESS=smtp-relay.gmail.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=support@bogus.com -e DISCOURSE_SMTP_PASSWORD=stupidpassword -e DISCOURSE_SMTP_DOMAIN=dev.bogus.com -e DISCOURSE_NOTIFICATION_EMAIL=noreply@dev.bogus.com -e LETSENCRYPT_ACCOUNT_EMAIL=me@example.com -h bogusdev-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:f1:a1:42:8a:5f local_discourse/app /sbin/boot
0be6584a62912bae1d517882fde2a5bf61d1c39466448803be811fbd777c87a5
[root@bogusdev discourse]#
[root@bogusdev discourse]# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0be6584a6291 local_discourse/app "/sbin/boot" 35 секунд назад Up 34 секунды 0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp app
[root@bogusdev discourse]#
