Комментарии 11
А зачем лишняя прослойка в виде Docker и Alpine Linux? Почему бы просто не запускать qemu?
Благодарю за вопрос! На это есть несколько причин:
- Не факт, что версия qemu установленная на CI через пакетный менеджер будет работать точно так же как версия установленная на моей машине, имею ввиду набор и режим работы ключей, от версии к версии он может меняться. Используя докер контейнер я свожу к минимум потенциальную вероятность возникновения проблем с совместимостью.
- Большинство CI систем с которыми мне доводилось работать уже имеют предустановленный Docker сервис, что отменяет необходимость ставить что-либо ещё.
- Пользователей столкнувшихся с Docker и имеющих представление о том как он работает и что нужно для того чтобы запустить приложение (на мой личный взгляд) гораздо больше, чем пользователей умеющих работать с qemu.
- Спортивный интерес и любопытство.
Помимо этого есть ещё ряд других причин, которые касаются конкретных способов использования, мониторинга, запуска в фоновом режиме нескольких виртуальных роутеров, использование в составе композиции контейнеров (пода), нескольких сетевых адаптеров и так далее.
TL;DR. Я-то из заголовка статьи подумал, что докер использовался именно для запуска файлов роутерос, а это оказался враппер для qemu. Сплошной обман. Я уж не говорю о том, что у меня есть подозрение, что т.к. qemu работает через kvm, то есть прямая зависимость от версии ядра и вкомпиленных в него модулей — можете проверить самостоятельно эту гипотезу. А еще посмотреть взлетит ли это все без включенной виртуализации на уровне железа.
Но вот за идею с интеграционным тестированием респект.
А как бы сделал я — взял vagrant какой-нибудь, виртуалочку и гонял бы тесты чем-нибудь поверх него — хотя бы тем же gitlab-ci. К сожалению, не знаю — у вас там облако или локально все ездит.
Благодарю за комментарий! Есть ряд моментов из-за которых был выбран именно этот вариант, как Вам скорее всего известно, у RouterOS помимо ARM есть вариант под x86 (имею ввиду 32х битные процессоры). Иными словами, заставить работать в докере через прямую распаковку файловой системы нетривиальная задача, на данный момент она решена при помощи Qemu без режима KVM который можно включить при желании.
А по поводу KVM было сказано в статье, он отключен по умолчанию, так как первые эксперименты показали наличие проблем у людей, которые запускали контейнер на VPS'ках работающих под KVM, потому как KVM in KVM хостеры обычно не включают.
Vagrant хорошая штука, но на большинстве CI систем её обычно нет из коробки (а вот Docker есть), к тому же лично для меня она кажется избыточной надстройкой над qemu (в контексте CI систем разумеется), хотя у меня в Vagrant работает Docker чтобы не захламлять рабочую операционную систему. Ну и задумка была именно в создании Docker контейнера, если бы был выбран Vagrant то этой статьи и проекта бы не было.
Резюмируя, данная статья как раз и была задумана чтобы показать возможность запуска RouterOS в Docker, согласен, что вариант с прямым доступом к файловой системе был бы оптимальным, но за месяцы изысканий у меня до сих пор не получилось его реализовать. И я очень надеюсь что найдётся человек способный подсказать решение, для этого эта статья и была написана.
Я слегка офигел, когда прочитал заголовок. С нетерпением прочитал первую реализацию и думал: "ну вот сейчас будет смак!" Какое же разочарование было узнать, что заголовок и содержание не имеют ничего общего.
Вы же понимаете, что запускаете RouterOS не в Docker, а в QEMU? С помощью докера, но не в нём.
Помимо всего прочего образ излишне разбухший, потому что содержит в себе кучу ненужного хлама, без которого можно было всё реализовать, не говоря уже о том, что вы не вычищаете за собой репозитории. Опять же выше сказали, что Docker здесь лишний от слова совсем и только ещё больше проблем создаёт.
Короче говоря, весь текст статьи можно уместить в: "смотрите как я умею создавать проблемы на ровном месте."
Отвечая на ваш ответ выше:
Вы могли бы написать роль на ansible и пользователям вообще не пришлось бы заходить на хост. На CI может быть установлен bash и даже его бы хватило на всё.
Благодарю за критику! Позвольте пойду по попрядку, заголовок соответсвует описанию потому как RouterOS на самом деле удалось заставить работать в Docker и проект на самом деле решает поставленную задачу площадки для выполнения интеграционных тестов, а уж через что запускается операционная система и каким образом функционал становится доступен пользователю — уже не так важно. В первой строчке описания на GitHub сказано, что этот проект создан исключительно для тестов и не рекомендуется для продакшен использования, так как есть намного более удачные решения поставленный задачи и даже они используют идею с виртуальной машиной.
Исходные коды RouterOS закрыты и создать полноценный контейнер (наподобии Alpine или Debian) в данный момент не представляется возможным, как Вы могли заметить проекту два года и конечно же я думал об этом много раз, однако, к сожалению на данный момент этого не удалось достигнуть.
По поводу хлама было сказанно в статье и даже перечисленны моменты, на которые стоит обратить внимание, вроде списка пакетов и генератора конфигурации udhcpd, но к сожалению в сутках слишком мало времени, а других проектов помимо этого более чем достаточно (это не считая работу и подработки), поэтому всё привести в порядок — задача не из простых. И это ещё одна из причин написания статьи, возможно найдутся заинтересованные люди готовые помочь.
По поводу ansible, под пользователями я имел ввиду не коллег по работе (для которых да, можно было бы создать конфиг и мы в дамках), а обычных людей, которые хотят использовать RouterOS для скажем тестирования своих маленьких хобби проектов. Времена хитроумных скриптов на bash для меня прошли уже очень давно, примерно в то же время когда я только начал читать Хабрахабр, с интерпретаторами bash точно такая же проблема как и с qemu, у некоторых CI систем bash может работать иначе, у некоторых будет невозможно поставить bash и придётся учитывать логику под dash/csh/zsh/etc. вставить нужное, Docker же всегда и везде работает одинаково. Да и статья не про ещё один bash скрипт для запуска RouterOS, а про идею воплощения контейнера для решения поставленных задач, если бы разговор был только про bash скрипт то этой статьи бы не было и я бы не пытался привлечь к проблематике Docker контейнера внимание уважаемой аудитории, потому как моя мечта заставить RouterOS работать в Docker полноценно без эмуляции.
Надеюсь мне удалось прояснить непонятные моменты и ещё раз спасибо за критику!
Кстати, kvm+libvirt вполне работают в Travis. stackoverflow.com/questions/31828555/using-vagrant-on-cloud-ci-services/60380518#60380518
Добрый день! Благодарю за замечание, заголовок поправил.
В приведённом Вами примере используется Vagrant, что не совсем минималистичное решение как по мне, плюс его тоже необходимо устанавливать в окружение CI, в то время как Docker доступен из коробки.
Travis-CI лишь частный случай, там выполняются тесты библиотеки над которой я работаю в свободное время (в ближайшее время планирую перейти на Scrutinizer-CI), вариант работы через KVM является опциональным и он обычно недоступен на хостинге пользователей проекта, а у некоторых на хостинге есть только Docker сервис и нет возможности установить дополнительный софт.
KVM не задействован не просто потому что я так захотел, а потому что были жалобы людей и отключение его через опции помогло людям настроить виртуальный роутер там где раньше возникали проблемы. (но его всегда можно включить передав соответсвующую команду на этапе запуска контейнера, такая возможность тоже учтена)
просили
Mikrotik RouterOS в qemu через docker
имеем
Mikrotik RouterOS в Docker с помощью Qemu
Называется — найди 10 отличий.
Я бы вообще изменил заголовок на другой.
В роде "Собираем стенд для интеграционного тестирования API Mikrotik RouterOS"
Поясню почему — потому что чисто по заголовку можно подумать, что придумали способ запуска продакшн-роутер-операционки в докере (ну, не знаю для чего), а по факту — чисто платформа для разработки-тестов
А не лучше в Dockerfile передавать аргументы?
Соответственно Dockerfile будет иметь вид:
FROM alpine:3.8
ARG ROUTEROS_VERSON
ENV ROUTEROS_IMAGE="chr-$ROUTEROS_VERSON.vdi"
ENV ROUTEROS_PATH="https://download.mikrotik.com/routeros/$ROUTEROS_VERSON/$ROUTEROS_IMAGE"
…
ENTRYPOINT ["/routeros/entrypoint.sh"]
а собирать образ командой:
docker build. -f ./Dockerfile -t local/routeros:6.42.7 \
--build-arg ROUTEROS_VERSON="6.42.7"
Смысл каждый раз заливать Dockerfile, если в нём ничего кроме версионности не меняется ;-)
Благодарю за вопрос! Вариант с ENV и коммитами в репозиторий (меняя при этом версию имеджа) был выбран в основном из-за особенностей работы Autobuild Docker Hub, чтобы затригерить сборку надо запушить коммит или новый тег, а ещё мне хотелось сделать максимально не зависящую от меня сборку (формата добавил в кронтаб и забыл), специально чтобы сразу после появлении новой версии RouterOS на сайте Mikrotik (с небольшим лагом конечно же) собранный имедж появлялся в списке доступных тегов на Docker Hub автоматически.
В принципе можно было бы настроить сборку имеджей у себя локально и через docker push публиковать новые теги или на каком-нибудь стороннем CI, или даже на домашнем Jenkins, но зачем когда есть Docker Hub?
Однако, мне нравится Ваше предложение о добавлении ARG в конфиг, там где указывается версия, это позволит пользователям собирать инстансы локально через --build-arg не загружая какую-то определённую версию из докерхаба. Спасибо за идею!
Mikrotik RouterOS в Docker с помощью Qemu