Mikrotik.moscow [тема: Новый проект контейнера: "mikrotik.upgrade.server" / "mus"]

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Wed, 23 Oct 2024 07:23:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Ты абсолютно прав — именно поэтому я хотел создать контейнер, который был бы почти самонастраиваемым, как проект MUS. Просто настроил бы Mikrotik для запуска контейнера, загрузил образ — и вуаля, почти всё готово. Думаю, если с такой конфигурацией придется возиться внутри контейнера, будет настоящий кошмар. Что касается логической проблемы, которую ты упомянул, она уже существует, мне это известно. Если запускать MUS или образ alp_rc, то при проверке состояния процесса “auto_init” видишь такую картину: команда rc-status показывает “auto_init [started]”, а rc-service auto_init status — “auto_init [stopped]”. Возможно, это логично для openrc, но мне не совсем ясно, показывает ли “rc-status” процесс в зависимости от уровней запуска, а не реальный статус, как это делает “rc-service auto_init status”. Последний, кажется, точнее. По документации openrc, насколько я понимаю, ситуация именно такая. С уважением, Детлеф
23.10.2024 07:23:00, felted67.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Mon, 21 Oct 2024 16:46:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Извиняюсь, ваши документы хорошие! Мои замечания скорее к Mikrotik — там просто ОЧЕНЬ много шагов, чтобы добавить простой контейнер. Ваши инструкции правильно описывают все этапы. Проблема в RouterOS — он делает этот процесс довольно долгим и ручным, когда нужно просто «добавить функцию» через /container (копирование пакета, режим устройства, диск и так далее) — это само по себе требует много документации. И ещё /container/start (и /stop) не очень удобно скриптовать, потому что они не ждут завершения операции (в отличие от всего остального в RouterOS). Из-за этого очень сложно оптимизировать процесс, что, на мой взгляд, одна из главных причин, почему /container используют не так часто. Ваш проект MUS на базе openrc подтверждает это — ваши более 10 страниц про /container в целом универсальны для всех контейнеров, просто из-за большого количества шагов, которые заставляет делать RouterOS, чтобы получить что-то вроде реальной конфигурации MUS.
21.10.2024 16:46:00, Amm0.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Mon, 21 Oct 2024 14:44:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Да, #2 просто кажется логической ошибкой… и на самом деле ваш фокус был на контейнере MUS, а не на его базовом образе. Что касается Mosquitto и openrc… По пункту #1 с mosquitto… mosquitto действительно стабильно работает внутри контейнера, если запускать его в режиме foreground (который потом через shell можно «зафоновить») вне openrc. Я знаю, что как минимум одна проблема может быть связана с директорией /run, которую openrc использует для хранения PID-файлов. Она доступна для записи root внутри контейнера, но если openrc/service делает chown/chmod и использует какого-то пользователя сервиса/демона (например, mosquitto), чтобы этот ненулевой пользователь мог «видеть» файлы /run/mosquitto с PID сервиса, запущенного openrc… Эти права на папку могут «теряться» после перезапуска системы (или где-то еще)... и когда openrc+mosquitto не может записать PID, это вызывает ошибки — ведь openrc считает, что chmod/chown были уже применены при добавлении сервиса и PID-файл существует (или по крайней мере доступен для чтения). По моим данным, именно PID-файл в /run и не создаётся — точное место и момент я не знаю — но openrc думает, что сервис не работает, потому что PID-файл отсутствует или нет прав на него. Аналогично с другими сервисами openrc, например, postgres. Если честно, я как-то разочаровался в openrc — пробовал несколько раз с тех пор, как появился контейнер, но идея пакетов в том и состоит, чтобы они просто работали. Alpine ведь имеет много пакетов, готовых к openrc, это удобно. В какой-то момент я изучал проекты типа «s6 overlay», например https://github.com/just-containers/s6-overlay и другие, которые пытаются сделать что-то похожее. Но s6 ещё сложнее… чтобы заставить работать init-скрипты. Для таких сервисов, как mosquitto, у которых есть режим foreground и которые можно просто «зафоновить» через shell, bash-скрипт с чем-то вроде «mqtt &; lighttpd» — не такая уж и плохая идея. Я пробовал новую схему с использованием Makefile и параллельных сборок make (-j <кол-во процессов>), чтобы имитировать метод «bash job control» от Docker — по сути, make заменяет bash, и несколько сервисов/демонов в foreground идут как параллельные шаги сборки, которые никогда не заканчиваются (при опции -j). Make также умеет управлять зависимостями, организовывать shell-скрипты в таргеты и логировать всю информацию о процессах с «-d», автоматически фиксируя сбои или запуск новых процессов в цепочке зависимостей. Это концептуально, но я опубликовал экспериментальный контейнер «make.d» для демонстрации такого подхода: https://github.com/tikoci/make.d — он работает в моём IoT-проекте (куда входят mqtt и http для простой внутренней веб-странички), а ещё для развлечения — http://forum.mikrotik.com/t/piano-interactive-player-piano-studio-quality-recorder-using-beep/173756/1 — там одновременно запускаются «mqtt» и «midimonster» в RouterOS контейнере «make.d», чтобы связать MIDI и MQTT (и поскольку это make, midimonster компилируется при старте сервиса, если нужно). Не для продакшена, но для тестирования и экспериментов отлично подходит. Это просто Alpine с make и Makefile, чтобы поднимать Alpine-сервисы через make — CMD/cmd= и ENTRYPOINT/entrypoint= можно менять по необходимости, в зависимости от того, будет ли make «init» или просто процесс (+пакет), установленный через make.
21.10.2024 14:44:00, Amm0.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Sat, 19 Oct 2024 23:23:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Привет снова, я протестировал описанные проблемы:

1.) Ошибка «cgroup-error => read-only filesystem»:
/ # rc-update add mosquitto default
* service mosquitto added to runlevel default
/ # rc-service mosquitto start
mkdir: не удалось создать каталог '/sys/fs/cgroup/openrc.mosquitto': Отказано в разрешении
* Запуск Mosquitto message broker ... [ ok ]
/ # rc-service mosquitto start
* ПРЕДУПРЕЖДЕНИЕ: mosquitto уже запущен

Эта ошибка сообщает лишь о том, что mosquitto не может создать cgroup-запись, так как cgroups в ROS недоступны. Это ожидаемая ошибка (аналогичная возникает и при запуске rsyslog). Её можно игнорировать, потому что mosquitto работает нормально несмотря на неё. Правда, я ещё не проверял, влияет ли отсутствие cgroup на нормальную работу mosquitto. Но даже с этой ошибкой mosquitto остаётся «живым» и работает без дополнительных жалоб.

2.) Ошибка с «auto_init», которая приводит к крашу:
# rc-status
* Кэширование зависимостей сервисов ...
Сервис `machine-id` зависит от несуществующего сервиса `dev` [ ok ]
Runlevel: default
sshd [ запущен ]
Динамический runlevel: hotplugged
Динамический runlevel: needed/wanted
Динамический runlevel: manual
auto_init [ аварийно завершён ]
/ # /sbin/first_start.sh
* rc-update: sshd уже установлен в runlevel `default`; пропуск
* ПРЕДУПРЕЖДЕНИЕ: sshd уже запущен
****
'
Не забудьте установить пароль root для ssh!!!
*
****
*
first_start.sh выполнен!
*
****
* rc-update: сервис `auto_init` не входит в runlevel `default`

Эта ошибка возникает из-за того, что в скрипте «first_start.sh» происходит удаление «auto_init» из /etc/runlevels/default. При запуске rc-status этот скрипт находит «auto_init» в /etc/init.d/, но не в /etc/runlevels/default, что воспринимается как ошибка. Я уберу команду удаления из «first_start.sh». Я даже думал совсем убрать «auto_init» и «first_start.sh», так как они нужны только при первом запуске контейнера. Но оставив их в системе, появляется возможность «сбросить» первоначальную конфигурацию, ведь оба скрипта запускаются при каждом старте и ничего не делают, если в корне файловой системы есть файл «./FIRST_START». Я пересмотрю это и тщательно протестирую перед выпуском новой версии всех публичных образов контейнеров, которые я опубликовал.

Спасибо за сообщение об ошибке! Скорее всего, всё будет сделано в ближайшие дни. Пожалуйста, проверяйте новые образы, чтобы увидеть, решены ли эти ошибки.

С уважением, Детлеф

Редактирование: Похоже, проблема с «auto_init» немного сложнее — дело не только в удалении скрипта. Я подозреваю, что openrc-скрипту «auto_init» требуется дополнительная внутренняя настройка. Rc-status использует дополнительные функции в скрипте — например, start), stop) и status). Я их реализую и снова сообщу. Впрочем, помимо ошибки «аварийно завершён», скрипт выполняется как задумано, но выглядит это скорее как косметическая проблема при запуске rc-status. Ещё раз проверю и постараюсь устранить эту проблему.
19.10.2024 23:23:00, felted67.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Wed, 16 Oct 2024 21:28:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Ну, прежде всего спасибо за твои комплименты. Очень ценю их 8=) А теперь немного “сложного” материала: запускать какие-то процессы, завязанные на cgroups (неважно, v1 или v2), просто не получится. Но дело не в структуре собранных контейнеров — проблема в полном отсутствии поддержки cgroups в реализации Mikrotik. Реализация основана на root-доступе, но нет “связи” с ядром базовой системы. (Не спрашивай, сколько часов я потратил на поиски этой причины за последний год)… так что cgroups — нет. Есть ещё несколько ограничений, с которыми я столкнулся при первом развитии alp-mikrotik_rc. Многие проекты, которые я хотел запускать в среде Mikrotik, просто рушились. Вот почему важно помнить: при использовании моих контейнеров под ними нет реальной поддержки ядра со стороны хост-системы. Это серьёзный подвох, но у Mikrotik свои причины так строго ограничивать базовую систему. (Честно говоря, я их не виню — возможно, сам бы поступил так же 8=) ) Возможно, какая-то “минимальная” поддержка kernel-cgroups могла бы значительно расширить возможности запуска контейнеров на ROS. С другой стороны, стоит помнить, что система на ROS — это в основном роутер, а не виртуальная машина. Эта тема стара как мир — лет 15 назад я работал в команде, создававшей производный продукт от ipcop https://www.ipcop.org/ с дополнительными функциями, которые обычно не встречаются на роутерах. (Кстати, тогда не было докера, а использовался chroot!) Это напоминает мне дискуссии того времени про безопасность и смысл таких решений. Кстати, вот кое-что интересное на тему “1 контейнер — 1 процесс — проблема”, что я недавно нашёл: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem Стоит почитать — забавные мысли про “проблему 1 к 1”, особенно во второй части. Ещё пара слов про документацию, которую я сделал: моя цель была создать контейнеры для Mikrotik не только для продвинутых пользователей, которые смогут собрать их сами. Я хотел дать почти полную документацию, которая коротко, но понятно рассказывает всю суть, чтобы опытный (в какой-то мере) пользователь, знакомый с философией Mikrotik, мог установить контейнеры на свою систему ROS и с большой вероятностью добиться успеха. Помните: нет ничего хуже, чем потратить время и не получить работающий результат 8=). Возможно, документацию стоит пересмотреть, возможно, ты будешь так любезен — указать на конкретные моменты или дать дополнительные советы. Буду благодарен за любой фидбэк — знаешь, никто не совершенен 8=) Ну и проблема с mosquitto будет изучена в ближайшем будущем — ты меня тоже заинтриговал. Спасибо и с уважением, Детлеф
16.10.2024 21:28:00, felted67.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Wed, 09 Oct 2024 20:36:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Я не могу не согласиться с твоим мнением. В контексте контейнера Mikrotik потребности немного другие. Мне нравится схема openrc, которую использует Alpine (напоминает Slackware), и большинство пакетов с демонами идут с openrc-скриптом. Кстати, отличная работа с мануалом по «mus» здесь. Но то, что 50% из 30 страниц посвящено тому, как вообще установить контейнер, тоже как бы подчёркивает, почему стоит сократить количество нужных контейнеров. Игнорируя философию... Именно технические тонкости с «pid 1 requirements», «cgroups», «уборкой зомби-процессов» и прочим раньше меня пугали. Так что ты дал мне надежду.

Я попробовал образ https://github.com/felted67/mikrotik-alp_rc — «базовый образ» (без MUS, только модификации через sed и /sbin/init), чтобы добавить пакет mosquitto. Но при использовании «rc-service» и так далее всё равно получал пугающие сообщения про «cgroups» — примерно такие, будто образ не изменён вовсе. Интересно, так и задумано? Работает/стартует, но ошибка при использовании сервисов редко бывает хорошим знаком.

# rc-update add mosquitto default
* service mosquitto добавлен в уровень запуска default

# rc-service mosquitto start
mkdir: не удалось создать каталог «/sys/fs/cgroup/openrc.mosquitto»: Отказано в доступе
* Запуск Mosquitto message broker … [ ok ]

# rc-service mosquitto start
* ВНИМАНИЕ: mosquitto уже запущен

После первоначального запуска /console/shell после создания он выдал auto_init.

rc-status
* Кэширование зависимостей служб …
Служба machine-id требует несуществующую службу dev [ ok ]
Уровень запуска: default
sshd [ запущен ]
Динамический уровень запуска: hotplugged
Динамический уровень запуска: needed/wanted
Динамический уровень запуска: manual
auto_init [ аварийное завершение ]

# /sbin/first_start.sh
* rc-update: sshd уже установлен в runlevel `default`; пропускается
ВНИМАНИЕ: sshd уже запущен
* first_start.sh выполнен!
* rc-update: служба auto_init не входит в уровень запуска default

В общем, просто небольшой отзыв и для обсуждения — хотелось бы, чтобы openrc работал как надо, потому что иногда удобно объединить несколько маленьких и простых сервисов в один контейнер Mikrotik. Я публикую контейнеры netinstall и «cligames» (текстовые UNIX-игры) на DockerHub. Именно последний я сначала пытался запустить с openrc (хотел больше способов доступа, чем просто telnet, например SSH и HTTP), но получил похожие сообщения от openrc, которые меня тоже отпугнули от его использования.
09.10.2024 20:36:00, Amm0.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Mon, 30 Sep 2024 13:16:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Возможно, достаточно хранить пакеты в каталоге для DUDE. DUDE сохраняет .npk в "dude-data/files/.npk", которые используются для обновления по правому клику в клиенте DUDE на устройстве в Network Map. Маршрутизатор DUDE MT и другие маршрутизаторы MT в той же сети, но очень далеко отсюда.
30.09.2024 13:16:00, bpwl.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Mon, 30 Sep 2024 11:39:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Ну, ты совершенно прав — я нарушаю правило «один процесс — один контейнер». Но в данном случае это сделано специально. Из-за сравнительно небольшого размера образов и, соответственно, минимального использования дискового пространства на устройстве mikrotik, это совсем не проблема. Нарушение «золотого правила» здесь преднамеренно, поскольку это позволяет запускать несколько задач в одном контейнере. Это даёт возможность параллельно заходить в работающий контейнер через ssh. И также — как ты упомянул — позволяет одновременно запускать некоторые процессы и веб-сервер в одном контейнере. Главная причина с моей стороны в том, что у mikrotik не реализована функция docker-compose. Поэтому никакой простой оркестрации невозможна, и я решаю это прямо внутри контейнера (простым способом). Пока это, конечно, не оркестрация в полном смысле, но для моих нужд сработало отлично. Собирая много разных контейнеров для mikrotik раньше, я проверял эту теорию — всё работает, никаких проблем. С уважением, Detlef
30.09.2024 11:39:00, felted67.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Sat, 28 Sep 2024 20:20:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Понятно, он находится в списке зеркал Alpine (https://mirrors.alpinelinux.org). В документации используется «dl-cdn.alpinelinux.org», так что сложное DNS-имя меня немного удивило. Теперь ты нарушаешь основную философию Docker с openrc (то есть один контейнер — одна задача). Но я не такой уж пурист. Особенно на слабых Mikrotik, возможно, лучше запустить один контейнер с openrc, который запускает несколько сервисов — ведь там просто нет одинакового объёма памяти и CPU. К тому же RouterOS не умеет оркестровать «compose»-варианты для работы с набором контейнеров. Наличие рабочих примеров использования openrc для решения проблемы «несколько сервисов в одном контейнере» на Mikrotik — это очень хорошо. Так держать!
28.09.2024 20:20:00, Amm0.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Sat, 28 Sep 2024 17:22:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Ну, вы правы — возможно, кто-то мог бы настроить там другой зеркало. Я использую это зеркало по умолчанию, поэтому и указал его. С другой стороны, этот контейнер можно расширять во время работы. Поэтому я создал alpine-line-openrc_minimal-контейнер, который можно использовать для любых нужд (и ros-контейнер поддерживает [no cgroups]). Вы можете подключиться по ssh к контейнеру и установить дополнительные компоненты, поэтому я добавил репозиторий… Опять же, это не обязательно, но может пригодиться для дальнейших случаев использования. Размер контейнера(ов) составляет от 32 до 37 МБ, так что особо экономить место не нужно.

P.S. Это зеркало — одно из основных здесь, в Германии, для alpine linux. Так что сомневаться в надежности не приходится…

С уважением, Detlef
28.09.2024 17:22:00, felted67.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Sat, 28 Sep 2024 16:50:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Отличная работа. Но есть причина, почему ты не используешь Alpine CDN URL? В Dockerfile:
RUN echo 'https://ftp.halifax.rwth-aachen.de/alpine/v3.20/main/' >> /etc/apk/repositories \
&& echo 'https://ftp.halifax.rwth-aachen.de/alpine/v3.20/community' >> /etc/apk/repositories \
&& apk add --no-cache --update --upgrade su-exec ca-certificates
Возможно, с твоего региона это быстрее, или нужен какой-то форк… но для общего образа, вероятно, лучше использовать что-то вроде *.alpinelinux.org, учитывая все последние атаки на цепочки поставок.
28.09.2024 16:50:00, Amm0.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Sat, 28 Sep 2024 16:28:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Итак, этот проект и соответствующие контейнер-образы работают на большинстве установок Mikrotik. Я использую их в основном на системе CHR, потому что там больше мощность процессора, много оперативной памяти и дискового пространства. Также вы можете установить это на настройке Portainer без каких-либо изменений: https://www.portainer.io/ Возможно, мой контейнер alp_rc будет для вас решением по установке node.js и node red, так как этот образ — просто дистрибутив openrc без дополнительных пакетов. Но все компоненты придется ставить самостоятельно. Ссылка здесь: https://hub.docker.com/repository/docker/felted67/mikrotik-alp_rc/general. Если в вашей системе не нужны kernel-cgroups, то, возможно, все пакеты удастся установить. Под капотом это дистрибутив Alpine Linux. Если нужны дополнительные сведения, задавайте вопросы здесь. С уважением, Детлеф
28.09.2024 16:28:00, felted67.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Wed, 18 Sep 2024 21:14:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Привет, спасибо за информацию! Работает ли это на CHR? Могу ли я использовать это для установки node.js и Node-RED? Спасибо!
18.09.2024 21:14:00, GiovanniG.

Новый проект контейнера: "mikrotik.upgrade.server" / "mus"

Mon, 02 Sep 2024 10:15:00 -0400

Новый проект контейнера: "mikrotik.upgrade.server" / "mus" RouterOS в форуме RouterOS.
Всем привет! Я только что закончил новый контейнерный проект для устройств на базе Mikrotik-routeros. Цель проекта — иметь все пакеты, необходимые для обновлений/апгрейдов, локально, без установки отдельного сервера в сетевой среде. Может, кому-то пригодится. Я использую его регулярно с самой первой (стабильной) рабочей версии. Это небольшой контейнер размером около 40 МБ, поддерживающий все доступные архитектуры с поддержкой Docker. Образы можно найти здесь: https://hub.docker.com/repository/docker/felted67/mikrotik-alp_rc_upgrade-server Исходный код доступен здесь: https://github.com/felted67/mikrotik-alp_rc_upgrade-server А полная документация лежит тут: https://github.com/felted67/mikrotik-alp_rc_upgrade-server/blob/main/doc/mus-documentation.pdf Пока что нет внешней вики или базы знаний, но это появится в ближайшем будущем. Пожалуйста, тестируйте и пробуйте, а если есть предложения, ошибки или вопросы — оставляйте комментарии здесь. Спасибо и удачи! С уважением, Detlef
02.09.2024 10:15:00, felted67.