+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Смонтированная папка очищается при удалении контейнера

Смонтированная папка очищается при удалении контейнера, RouterOS

Stuebi

Guest

11.12.2023 13:03:00

Привет! Я пытаюсь использовать контейнер с примонтированной папкой, указывающей на /usb1 на hAP ax³, и у меня проблемы с сохранением данных. Когда я сохраняю файлы в примонтированной папке, они удаляются при удалении контейнера. Даже если я скачиваю их напрямую через /fetch.

Настройка: я скачиваю кастомный образ через команду fetch в /usb1/image.tar и добавляю/распаковываю его. Затем загружаю файлы в мою папку монтирования. Эти файлы должны быть редактируемыми из контейнера и сохраняться, даже если я переписываю или удаляю контейнер. USB-накопитель отформатирован в EXT4. Контейнер запускается под root, поэтому вижу, что файлы в примонтированных папках тоже принадлежат root.

Добавляю монтирование и контейнер, а также скачиваю кастомную конфигурацию:
/container/mounts/add name=data src=usb1/data dst=/data
/container/add file=usb1/image.tar interface=veth1 root-dir=usb1/container mounts=data workdir=/usr/src/node-red start-on-boot=yes logging=yes
/tool fetch url="https://www.mydomain.com/download/f/flows.json" mode=http dst-path=usb1/data/flows.json

Контейнер нужно запустить хотя бы один раз, после его остановки и удаления файлы, которые я положил в путь /usb1/data (например, скачанный flows.json из примера выше), тоже удаляются. Это нормальное поведение? Есть ли способ сохранять файлы, созданные внутри или снаружи контейнера, и повторно использовать примонтированную папку?

Пробовал удалить точки монтирования из контейнера, а потом удалить сам контейнер — это тоже очищает папку монтирования!? Большое спасибо за помощь!

vic3apex Guest	#2 0 05.03.2024 15:10:00 У меня та же проблема с моим hap ax^3 и внешним USB-накопителем.

optio

Guest

10.08.2024 11:09:00

Мне удалось воспроизвести эту проблему (ROS 7.15.3) в сценарии, когда внутри одной смонтированной директории есть другая смонтированная директория. Мне нужна именно такая конфигурация, потому что требуется tmpfs-директория внутри смонтированной, так как процесс выполняется в chroot в ней.

Диски:
/disk> print
Flags: B - BLOCK-DEVICE; M - MOUNTED
Columns: SLOT, MODEL, SERIAL, INTERFACE, SIZE
# SLOT MODEL SERIAL INTERFACE SIZE
0 M tmpfs1 ram 1 003 520
1 BM usb1 Kingston DataTraveler 3.0 838AAB340F1CE661493015AE USB 2.10 480Mbps 62 058 921 984

Монтирования:
/container/mounts> print
...
5 name="unbound_etc_unbound" src="/usb1/containers/mounts/unbound/etc/unbound" dst="/etc/unbound"
7 name="unbound_etc_unbound_zonefiles" src="/tmpfs1/containers/mounts/unbound/etc/unbound/zonefiles"

Контейнер:
/container> print detail
...
3 ;;; [U] Unbound
name="f003e017-8e79-466d-8137-4b1e5938c141" tag="alpinelinux/unbound:latest" os="linux" arch="arm"
interface=veth3 envlist="unbound_envs" root-dir=usb1/containers/unbound
mounts=unbound_etc_unbound,unbound_etc_unbound_zonefiles dns=127.0.0.1 hostname="unbound"
domain-name="lan" workdir="/etc/unbound" start-on-boot=yes status=running

Монтирования из shell контейнера:
/ # mount
...
/dev/sda on /etc/unbound type ext4 (rw,nosuid,nodev,noexec,relatime)
tmpfs on /etc/unbound/zonefiles type tmpfs (rw,nosuid,nodev,noexec,relatime,size=980k)

То есть внутри смонтированной директории /etc/unbound есть ещё одна смонтированная директория - zonefiles (tmpfs):
/ # ls -al /etc/unbound/
total 40
drwxr-xr-x 4 unbound unbound 4096 Aug 10 10:43 .
drwxr-xr-x 18 root root 4096 Aug 10 10:42 ..
-rw-r--r-- 1 unbound unbound 3313 Aug 10 10:42 root.hints
-rw-r--r-- 1 unbound unbound 758 Aug 10 10:43 root.key
-rw-r----- 1 unbound unbound 315 Aug 10 10:43 server.cnf
-rw-r--r-- 1 unbound unbound 13769 Aug 10 10:42 unbound.conf
drwxr-xr-x 2 unbound unbound 4096 Aug 10 10:42 unbound.conf.d
-rw------- 1 unbound unbound 0 Aug 10 10:42 unbound_server.key
drwxr-xr-x 2 unbound unbound 100 Aug 10 11:08 zonefiles

/ # ls -al /etc/unbound/zonefiles
total 144
drwxr-xr-x 2 unbound unbound 100 Aug 10 11:21 .
drwxr-xr-x 5 unbound unbound 4096 Aug 10 11:16 ..
-rw-r--r-- 1 unbound unbound 10 Aug 7 19:17 .type
-rw-r--r-- 1 unbound unbound 97149 Aug 10 03:30 doh.zone
-rw-r--r-- 1 unbound unbound 39390 Aug 10 11:21 urlhaus.zone

Когда контейнер удаляется, все файлы из смонтированной директории /etc/unbound тоже удаляются. Раньше такого не было, пока не добавили монтирование zonefiles. При удалении других контейнеров с монтированными директориями (но не так, что внутри уже смонтированной) такой проблемы нет. Похоже, в ROS containers есть баг, связанный с этим.

P.S. root-директория контейнера (usb1/containers/unbound) при удалении контейнера тоже не удаляется, и её нельзя было удалить из WInbox до перезапуска ROS:

tangent

Guest

10.08.2024 13:28:00

Похоже, это баг в RouterOS только в том смысле, что оно вообще не должно позволять сделать так, но, думаю, оно именно то и делает, что вы ему сказали. У вас не хватает «dst» в mount ID 7. Каталог будет создан внутри контейнера и исчезнет, когда контейнер удалится. Для справки, я проверил ваш случай (bind-монтированная директория на tmpfs) на полноценном контейнерном движке, и всё работает как надо:

$ mkdir $XDG_RUNTIME_DIR/test
$ podman run -it --rm -v $XDG_RUNTIME_DIR/test:/test:z alpine
/ # echo hi > /test/file
/ # exit
$ cat $XDG_RUNTIME_DIR/test/file
hi

Отмонтаж родительской tmpfs-директории (/run в данном случае) удалит всё внутри, включая мой «…/test/file», но это не касается поддиректорий, если родительская директория по-прежнему смонтирована в хостовой ОС.

optio

Guest

10.08.2024 13:46:00

Я просто неправильно скопировал и вставил, потому что строка в терминале была разбита. Цель для этого монтирования существует: /container/mounts> print
...
5 name="unbound_etc_unbound" src="/usb1/containers/mounts/unbound/etc/unbound" dst="/etc/unbound"
7 name="unbound_etc_unbound_zonefiles" src="/tmpfs1/containers/mounts/unbound/etc/unbound/zonefiles" dst="/etc/unbound/zonefiles"
Контейнер ROS так не ведёт себя, и родительские элементы тоже удаляются, так что, похоже, это баг в ROS.

tangent

Guest

10.08.2024 14:33:00

Сведи это к простому примеру, как я сделал выше с Podman и Alpine, и у тебя будут все основания для подачи отчёта об ошибке. Чем проще ты сделаешь воспроизведение проблемы, тем быстрее её исправят. Вовлечение Unbound только усложняет ситуацию без какой-либо пользы. Проясни всё.

optio Guest	#7 0 10.08.2024 14:41:00 При настройке Unbound я это заметил, поэтому примеры даны именно для Unbound, но думаю, что для любого контейнера с таким способом монтирования будет то же самое…

tangent Guest	#8 0 10.08.2024 14:50:00 А если нет, то вы узнали что-то интересное, возможно даже важное.

optio

Guest

10.08.2024 14:51:00

Давай поспорим? Редактирую: Как и ожидалось, проблема не связана с образом контейнера, воспроизвел то же самое на CHR ROS, используя обычный образ Alpine:
# 2024-08-10 17:57:22 от RouterOS 7.15.3
# software id =
#

/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
/interface veth
add address=192.168.100.101/24 gateway=192.168.100.1 gateway6="" name=veth1
/container mounts
add dst=/parent name=alpine_parent_dir src=/containers/mounts/alpine/parent
add dst=/parent/child name=alpine_child_dir src=/tmpfs1/containers/mounts/alpine/parent/child
/disk
add media-interface=none media-sharing=no slot=tmpfs1 tmpfs-max-size=1000000 type=tmpfs
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=virtual0
/container
add cmd="tail -f /dev/null" interface=veth1 mounts=alpine_parent_dir,alpine_child_dir root-dir=/containers/alpine
/container config
set registry-url=https://registry-1.docker.io tmpdir=/containers/tmp
/ip smb
set enabled=no
/dude
set enabled=yes
/ip dhcp-client
add interface=ether1
/ip ssh
set host-key-size=4096 host-key-type=ed25519 strong-crypto=yes
/system clock
set time-zone-autodetect=no time-zone-name=Europe/Berlin
/system identity
set name=CHR
/system note
set show-at-login=no

Пока контейнер добавлен и запущен:

Когда контейнер удалён:

Кроме того, корневая директория контейнера остаётся после его удаления, и её нельзя удалить, пока не перезагрузишь систему:

tangent

Guest

#10

10.08.2024 16:24:00

Я бы ещё сильнее сократил это перед тем, как отправлять багрепорт в MikroTik. Твой “/export” содержит гораздо больше информации, чем нужно (например, настройка ether1, чувак, часовой пояс…), и при этом недостаточно данных, чтобы воспроизвести проблему. Особенно строка “/container add” не показывает имя удалённого образа. Я бы отправил им последовательность интерактивных команд, которые они могут выполнить на своём CHR, чтобы проверить твои слова — одним автономным скриптом. Включая команды “/file” для настройки и проверки смонтированных директорий, так ты сможешь обойтись без кучи скриншотов. Говорю по опыту: последние два бага с контейнерами, которые я сообщил в MT, исправили в следующем крупном релизе, и я уверен, что заслуга частично в том, что я прислал им чёткий и воспроизводимый тест-кейс.

optio

Guest

#11

10.08.2024 16:48:00

Да, это полный вывод команды /export, и экспорт из ROS для контейнеров неполный (это тоже баг), но на скриншоте видно тег — alpine:latest, который загружается с Docker Hub — registry-url=https://registry-1.docker.io. Всё делается через Winbox: перед запуском контейнера родительская директория с файлами копируется с ПК (перетаскиванием в /containers/mounts/alpine — эта структура каталогов создаётся на рабочем столе и потом перетаскивается в Files в Winbox), чтобы создать директорию до запуска контейнера, иначе к ней будет применён тип хранилища контейнера (чтобы содержимое было видно из ROS shell или Winbox). Для отчёта о баге постараюсь отправить как можно больше деталей, но на самом деле это просто воспроизвести: достаточно смонтировать другую директорию в уже существующий путь монтирования, ведёт себя одинаково вне зависимости от того, tmpfs это или нет. Для немонтируемого tmpfs смысла в этом нет, но для tmpfs замонтившего путь это может быть оправдано, как в моём случае с Unbound.

tangent

Guest

#12

10.08.2024 16:53:00

Я лишь хочу сказать, что если упростить процесс до «копируешь из Jira, вставляешь в CHR, а потом смотри сюда», у саппорта не будет повода отправлять отчет обратно с фальшивым объяснением «не будем чинить» или гадать, что именно ты имел в виду. Им просто придется сразу же передать его разработчикам. Отправь им мой пример с Podman. Лучше ещё и переведи его в команды Docker и тоже отправь. (Достаточно убрать флаг монтирования :z и заменить «podman» на «docker».) Тогда они сами увидят, что у них реализация — самая странная.

optio Guest	#13 0 10.08.2024 16:59:00 У меня установлен Docker, могу создавать примеры прямо с помощью команд Docker.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры