How to run docker on read-only filesystem?

Question

[asmyasnikov]

Коллеги, подскажите как организовать нормальную работу docker'а на readonly файловой системе.
У меня хосты - одноплатники с операционкой на sd-карте. SD-карты как известно имеют ограниченный ресурс по перезаписи. Хотелось бы отдать в продакшин устройства, исключив фактор выхода из строя sd-карты

Answer 1

[chupasaurus]

SD-карты как известно имеют ограниченный ресурс по перезаписи.

Решается путём закупки SLC/MLC SD-карт.
Если есть возможность, все логи (как системные, так и контейнеров) надо отправлять на агрегатор вместо локального хранения.

Answer 2

[Vitaly Karasik]

Насколько понимаю, достаточно отключить logging, и все будет работать.

Answer 3

[Георг Гаал]

Не получится на ro.
Докер хранит свое состояние в /var/lib/docker
Туда же идут образы, данные и конфигурации контейнеров и пр. пр. пр.

Какие варианты я вижу:

1. Монтировать указанный каталог на tmpfs
2. Отказаться от использования docker, поставлять сервисы "запеченными" в основной образ с ОС на RO ФС
3. Перейти на альтернативные технологии контейнеризация типа systemd-nspawn

Comments

[asmyasnikov]

Я предполагал, что на момент деплоя монтирую файловую систему в read-write, затем перемонтирую ее в read-only. Это позволит докеру установить все необходимое для запуска.

[Георг Гаал]

Можете попробовать, но сомневаюсь, что получится и что это правильный путь.
Мне все-таки очень сильно кажется, что нужно подход поменять.
Если расскажете подробнее о проекте - могу посоветовать более предметно что делать и куда дальше бежать.

[asmyasnikov]

С systemd-шными сервисами (включая deb-пакеты) уже пройденый этап - много времени занимает деплой. С docker'ом все гораздо быстрее стало.
Подробнее о проекте. Часть хостов на amd64 (которые имеют честный HDD), часть хостов на RaspberryPi (arm32v7 с industrial SD-картами), сборка под 2 архитектуры. Приватный docker-репозиторий. Для деплоя используется saltstack. В docker-compose прописаны теги образов, соответствующие архитектуре. Хосты преимущественно работают без интернета. Настроен всего 1 systemd-шный сервис - собственно запуск docker-compose. Есть четкая процедура деплоя (в конфиге saltstack), в рамках которой можно делать всякие вещи (типа перемонтирования разделов файловой системы, docker pull и пр.)
Насчет SD-карт. У меня уже было 2 отказа обычных SD-карт на устройствах, работающих в режиме 24/7 - мороз + логи съели ресурс блоков. После этого карты заменил на industrial, но гарантии их безотказности нет - ресурс по перезаписи все равно исчерпается когда-либо. В связи с этим я решил перенять опыт прошивок для всяких роутеров (типа OpenWRT), где root-файловая система монтируется в read-only.

[Георг Гаал]

voidSoul
логи - положим, не проблема. Можно их либо писать в /dev/null (докер так умеет), либо в journald (кстати, системные логи тоже ведь нужно отключить для RO FS?), либо в еще какой-нибудь драйвер (например, rsyslog и доставлять их по сети на удаленный сервер).
контейнеры - само их состояние и overlay fs - однозначно поверх RO FS работать не будет. Поэтому я и предложил запускать поверх tmpfs, но выглядит как костыль.
Мне кажется, что все-таки стоит вернуться на дистрибуцию через deb. С salt'ом - нормально комбо. Касательно с докером - я даже не знаю. Что быстрее? Выкат? Разработка?

> Настроен всего 1 systemd-шный сервис - собственно запуск docker-compose

Не надо так делать. Никогда. Во-первых, docker-compose тут лишний. Во-вторых, у вас уже есть salt, который прекрасно умеет оркестировать контейнеры. В третьих, если засосывать docker-compose в systemd unit, то последний не сможет надежно проверять работоспособность сервиса в докере. Лучше уж тогда напрямую запуск каждого отдельного контейнера в отдельный systemd unit оборачивать. Там свои нюансы, но это выглядит более надежным решением, чем тащить туда компоуз.

[asmyasnikov]

> Касательно с докером - я даже не знаю. Что быстрее? Выкат? Разработка?
Все вместе - разработка + выкат + тестирование. Раньше неделями могло приезжать обновление. Но самое главное - это мое время, его уходило в разы больше. Сейчас от коммита до накатывания обновления - 6 минут.

[asmyasnikov]

> Во-вторых, у вас уже есть salt, который прекрасно умеет оркестировать контейнеры.
а не могли бы Вы поделиться ссылкой на такую оркестровку docker-контейнеров с помощью saltstack?

[asmyasnikov]

> Во-первых, docker-compose тут лишний
docker-compose решает важную задачу - разруливает зависимости запуска (сначала БД, затем сервисы использующие БД и используемые для перенаправления веб-запросов, затем nginx, зависящий (proxy_pass) от вторичных сервисов)
Настройка взаимных зависимостей отдельных systemd-сервисов - еще та задачка...

[Георг Гаал]

voidSoul, для управления контейнерами salt'ом напрямую мы небезуспешно используем https://docs.saltstack.com/en/latest/ref/states/al...

Настройка взаимных зависимостей отдельных systemd-сервисов - еще та задачка...
Это существенно более гибкий механизм чем то, что предлагает docker compose для обеспечения порядка запуска сервисов.

Сейчас от коммита до накатывания обновления - 6 минут.
Я и с deb сделал бы не хуже... Ну, ок.

[asmyasnikov]

Георг Гаал, а разве инструкции salt'а для управления docker-контейнерами перманентные (т.е. восстанавливаются после рестарта хоста)?

[Георг Гаал]

voidSoul, ну, после перезагрузки - контейнеры никуда не исчезают. Но это не salt'овая особенность, а "фишка" самого докера. Можно ещё задать политику рестарта контейнера, т.е. после перезагрузки контейнеры могут автоматически запуститься. Это может быть как желательно, так и не очень (поэтому я и предлагал управление запуском переложить с докера на systemd)