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

Привет, спасибо за информацию! Работает ли это на CHR? Могу ли я использовать это для установки node.js и Node-RED? Спасибо!

Отличная работа. Но есть причина, почему ты не используешь 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, учитывая все последние атаки на цепочки поставок.

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

Возможно, достаточно хранить пакеты в каталоге для DUDE. DUDE сохраняет .npk в "dude-data/files/.npk", которые используются для обновления по правому клику в клиенте DUDE на устройстве в Network Map. Маршрутизатор DUDE MT и другие маршрутизаторы MT в той же сети, но очень далеко отсюда.

Ну, прежде всего спасибо за твои комплименты. Очень ценю их 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 будет изучена в ближайшем будущем — ты меня тоже заинтриговал. Спасибо и с уважением, Детлеф

Да, #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.