Посоветуйте ультралегкий дистрибутив/докер-хост плз

Любой, серверный вариант без графики.

Debian 12 No Desktop (Server) Disk Space 4 GB (minimum) Ubuntu Server Minimum RAM: 1.5 GB (ISO installs) Minimum storage: 5 GB (ISO installs)

Часто alpine используют.

Вообще, раз технологические средства не бесконечные, то имеет смысл docker не использовать.

Озвучьте тогда что там на ваших железках, сколько озу, сколько диск.

А они без докера уже не умеют сервисы развертывать, ха-ха-ха. Причем он пишет что там не один контейнер будет, а несколько. Как все это будет тормозить и вобще взлетит ли…

так указал же в исходном сообщении: Остаются свободными около 1гб оперативной и 1гб накопителя

из опробованного лучше всего поместились rancher os и burmilla os, хосто отъедает меньше 45% от ресурсов, но через неделю-две начинается жер памяти, дистрибутивы не поддерживаются, куда копать не нашел. На дебиан при этом контейнеры работают без проблем. Alpine в очереди на тест, немного смутили варианты установки, но после красноглазия с ранчерос думаю разберусь:)

Необходимое приложение поставляется именно в докере, так что без вариантов.

Необходимое приложение поставляется именно в докере, так что без вариантов.

Что значит «без вариантов»? Если там какой-то репозиторий с конфигом для докера, то его можно просто проигнорировать, забрать саму софтину и запускать её напрямую. Если там файл контейнера, то его можно распаковать без проблем, а далее см. выше.

ну тогда ищите спец дистрибутив для запуска контейнеров. Мне рассказывали что использовали Роса rootfs в качестве запускалки контейнеров, но оно идет как архив т.е. вам надо будет прикрутить загрузчик к нему.

https://abf.io/platforms/rosa13/products/408/product_build_lists/58897

Часто alpine используют

Для гостей. А топикстартер про хост спрашивает.

А чем он как хост не подходит?

файл контейнера, то его можно распаковать без проблем

Я сюда и пришел в надежде не получать советов как на реддите:) Давайте проще спрошу: вы лично за сколько возьметесь деконтейнизировать приложение, убедиться в его полной работоспособности и гарантировать повторяемость установки и через 10-15 лет? А то так можно и до советов свой линукс написать. Условия же заданы вполне точно.

Давайте проще спрошу: вы лично за сколько возьметесь деконтейнизировать приложение, убедиться в его полной работоспособности и гарантировать повторяемость установки и через 10-15 лет?

Этим должен заниматься тот, кто в этом заинтересован. Т.е. если ситуация повернется так, что из контейнеров не получится никак, будете деконтейнизировать.

вы лично за сколько возьметесь деконтейнизировать приложение, убедиться в его полной работоспособности и гарантировать повторяемость установки

15kуе

и через 10-15 лет?

в год

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

при таких ресурсах - можно использовать контейнеры, но имхо не через docker, а через более лёгкий runtime; собираются/готовятся они при этом через docker.

я пробовал 2 варианта:

https://github.com/RuriOSS/rurima/blob/main/doc/USAGE.md запускалка контейнеров rurima, работает даже в termux на андроиде, на полноценном линуксе тоже работает.

Срезает много углов, насколько я понимаю в частности исходит из того что о образ=контейнер, то есть или базовый слой readonly, или он будет засираться приложением. Варианта прозрачно добавить unionfs со временным слоем поверх, как это делает docker - нет

Вариант 2 гонял контейнеры с помощью вот этого - https://github.com/containers/crun

там в примере на сайте использование с podman, но я запускал без него.

По сути 3 файла: статический бинарник этого crun, squashfs c приложением, и shell-скрипт, который его с кучей параметров вызывает предварительно монтруя squashfs

Приложение собиралось докером, потом формат результата сборки тюнился чтоб его было удобно запускать подобной штукой. Конкретно в моём случае я пережимал в squashfs, потому что стандартные способы хранение контейнеров докером очень избыточны, в его последних трендах вообще дублирование - хранит одновременно в формате чтоб быстро запускалось и одновременно в формате чтоб быстро отдать на другой хост.

Этот вариант со sqaushfs делал давно, возможно с тех пор стало можно менее криво

Соответственно с точки зрения дистрибутива - этим 2м утилитам ничего не требуется, это статически собранные бинарники, можно запускать из дистрибутива состоящего из одного busybox, а можно наверное вообще как init запустить (но тогда наверное будут проблемы с resolv.conf если он нужен контейнеру)

Что и как можно поставить в качестве хоста под docker, чтобы максимум от этих ресурсов отдать контейнерам?

Тот, который используют контейнеры.

Alpine.

Давай уточним задачу. Ты хочешь избавиться от виртуалки (esxi) и заменить её на контейнеры? Или ты хочешь внутри виртуалки пускать ещё и контейнер?

Если первое, то выглядит здраво. Если второе, то сочетание пассивного охлаждения, небольшой памяти и монстра по имени esxi уже само по себе выглядит кринжово, а если сверху ещё и контейнеров навалить для верности (ну чтоб уж точно не всплыло)…

Ну и насколько небольшая, ты не уточнил. У тебя когда спрашивали про ресурсы, имели в виду не только «сколько памяти остаётся», но и сколько её вообще физически, чтобы оценить проблему в комплексе. То же и по диску.

P.S. Если у тебя совсем выбора нет, то выше Alpine уже посоветовали, можно ещё на минимальный дебиан (не серверная установка, а именно минимальный ISO с ручным допилом) посмотреть. Alpine, скорее всего, будет жрать заметно меньше, его под это специально затачивали, дебиан более массовое, хорошо описанное и многократно испытанное решение. Но если что, в том, что кто-то не выиграл чемпионат по бегу с гирями на ногах, ЛОР не виноват.

Остаются свободными около 1гб оперативной и 1гб накопителя.

Какое железо изначально? Остаются после чего? Не может же быть оно таким. Какие приложения предполагается запускать в докере?

Спасибо, попробую.

Какое железо изначально? Остаются после чего?

Странный вопрос. esxi работает так, что гостевая ос увидит ровно 1024мб памяти и 1024мб накопитель. Это фактически не отличается от железного компьютера именно с такими ресурсами.

Всем спасибо за рекомендацию alpine, пойду пробовать.

Вообще, раз технологические средства не бесконечные, то имеет смысл docker не использовать.

Мегаочевидный вывод. Даже если взять специальный дистр аля MicroK8s - ему всё равно по самому минимуму нужен 1 Gb RAM и 1 Gb SSD.

В своё время на OpenWrt я в роутер с 16 флеша и 64 Мб оперативы запихивал веб сервер, торрент-клиент, и ещё сверху места нормально так оставалось. Когда места очень мало, то сборка из исходников с интенсивным использованием одного набора разделяемых библиотек внезапно оказывается очень эффективной.

OpenWrt поддерживает Docker.

https://openwrt.org/docs/guide-user/virtualization/docker_host

Если вы делаете из этой машины appliance, а не пытаетесь пользоваться как «компьютером» со всеми его атрибутами, то Debian Standard (полноценный, не контейнерный образ) с установленным Docker можно уместить в 200 МБ squashfs (только что попробовал, вышло 193 МБ).

Обновлять саму ОС при необходимости будете с помощью систем обслуживания embedded: swupdate, rauc.

Меньше будет только с OpenWrt, Alpine (<100МБ), но их набор софта отличается от типичного сервера.

Необходимое приложение поставляется именно в докере, так что без вариантов.

Какое «приложение»? К чему? Кем поставляется?

Если перестать выражаться загадками, ответы могут стать точнее.

вангую что подрядчики заделиверили работу в виде докер контейнера и теперь его срочно надо запустить

TinyCore Linux. Вот это действительно, куда уж меньше-то :)

Debian Standard (полноценный, не контейнерный образ) с установленным Docker можно уместить в 200 МБ squashfs (только что попробовал, вышло 193 МБ).

То, что нужно! Подскажите плз где найти информацию как собрать такую систему.

Докер из openwrt уже опробован со всех сторон, прямо скажем это не работает.

рекомендацию alpine, пойду пробовать

Может еще на TCL посмотреть? Известный минималист. Но и оригинал, да.
Еще, КМК, вероятность найти подходящего минималиста выше в среде системд-фри. А последний алпайн уже не из этих, если не ошибаюсь.

TinyCore Linux

Да, смотрел на него (точнее на boot2docker), смутило полное отсутствие упоминаний подобного комбайна в интернете за последние годы:) Надо попробовать.

TinyCore Linux

Видимо смотрели «поверхностно», обратите внимание как устроен дистрибутив, и да, alpine будет «полегче»

Проблема в том, что докер обычно подразумевает, что образ будет тягать с собой все системные бибилотеки. А если он не тягает, то зачем докер?

Образ ВМ с нужными пакетами и разметкой можно собрать с помощью mkosi, например (output = gpt_squashfs, Raw GPT disk image, with squashfs as read-only root).

Для уменьшения размера нужно удалить:

/var/cache/apt/*
/var/lib/apt/lists/*debian*
/usr/share/locale/*
/usr/share/doc/*
/usr/share/man/*
/usr/share/groff/*
/usr/share/info/*
/usr/share/lintian/*
/usr/share/linda/*

В самом Debian потребуются различные костыли и настройки для того, чтобы он работал с read-only rootfs, либо настраивать overlayfs (пакет overlayroot).

В целом подойдёт любая инструкция а-ля debian for embedded. Но только качественная, профессиональная, а не с форумов. У меня под рукой ничего нет.

Ты там под кайфом что ли сидишь?

Если у тебя ESXi и надо запускать линуксовые сервисы - то берешь и запускаешь их… В линуксовых же виртуалках - так же, как ты это уже делаешь. Не хватает места - докупаешь диск. Не хватает оперативки - докупаешь оперативку. Все очевидно.

зачем докер

Для простоты развёртывания и использования.

У меня системы сильно проще, чем у автора (128 МБ флешка и 512 МБ RAM), и мне приходится ужиматься с OpenWrt, выделять оставшиеся после rootfs крохи для сохранения какого-никакого persistent, а обновления перезаписывают всю ФС, включая persistent (потому что иначе пришлось бы выделять фиксированный размер под rootfs, места было бы ещё меньше), правда настройки сохраняются.

образ будет тягать с собой все системные бибилотеки

Образы могут быть минимальные, очень легковесные, с абсолютным минимумом библиотек и утилит (см. apline, или даже просто статический busybox).

Для простоты развёртывания и использования.

Прежде всего неплохо было бы уточнять «развёртывания и использования чего?». Имея исходную задачу можно и докеры подсказать, если уж на то пошло.

гости для сбора телеметрии

У меня примерно то же самое, а возможно мы вообще одни и те же данные собираем. Network probe с возможностью запуска экспериментов, и эксперименты готовят разные люди с использованием разного ПО.

В моём случае нужен я как надзиратель, чтобы эксперимент в принципе запустился (т.к. требуется особая компиляция под OpenWrt) и ничего не сломал. С Docker такой проблемы бы не стояло.

Для простоты развёртывания и использования

Да все проще, когда контейнеру исполняется лет 10, то половину библиотек крайне сложно опознать, авторая половина уже много лет отсутствует в репах. У меня в работе есть виртуалки которые лет 20 живут в неизменном виде, есть два хоста которые не перезагружались уже больше 15 лет.

Вашему контейнеру? Так это решается хранением всех необходимых файлов.

Берите подходящий для долговременного использования дистрибутив за основу, в репозиториях Debian ничего не исчезает, и они сами не исчезают (правда со временем переезжают в архив, по другому пути). Или CentOS 6, где тоже всё онлайн и доступно, хотя он вышел в 2011 году.

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

Вашему контейнеру? Так это решается хранением всех необходимых файлов

Если бы. В моем случае необходима как минимум машина времени.

2all. Если интересно что это, то можно было так и спросить:) Это система проактивного мониторинга параметров, живет рядом с rtos системой управления (она кстати, при своих 16мб rom, 64mb ram очень много делать умеет). Из-за проблем со связью в последнее время она переносится непосредственно к самим железкам. А перед эникей-комментариями можете ознакомиться сколько стоит сегодня подобное оборудование с лицензиями, думаю у каждого предлагающего квартира куда дешевле стоит.

Или CentOS 6, где тоже всё онлайн и доступно, хотя он вышел в 2011 году.

Вот кстати centos5 это был первый на моей памяти случай, лет 6-7 назад упала машина, все бекапы оказались уже с косяком, восстановить у нас ее так и не вышло именно из-за отсутствия нужных версий либ.

У меня своей квартиры вообще нет, если на то пошло :-D

В целом, поместить Debian 12 на 1 Гб у тебя получится, базовую систему с ядром.

Прекрасно запустится на 512 Мб и даже меньше.

А так - alpine linux, он оптимизирован именно для контейнеров (для их сборки), но и для запуска подойдёт.

Там Musl вместо glibc, в итоге дистрибутив получается компактным.

Ну и есть специализированные core дистрибутивы, в которых минимальная система, сам docker и всё.

Смотри alpine.

Могу только плечами пожать. Репозитории CentOS 5 живые, исходники и собранные компоненты все на месте. Внутри .src.rpm-файлов есть оригинал архива исходной программы.

Репозитории CentOS 5 живые

Значит что-то рядом живущее не нашли, уже не вспомню, полгода громадину с нуля переделывали в итоге. Но это я про зачем виртуализация.

Ну и есть специализированные core дистрибутивы, в которых минимальная система, сам docker и всё.

Мой вопрос как раз про то, что именно есть. Вон, сам esx/esxi, просто шикарная штука - использую со времен 3.5, уж не сосчитать сколько сотен хостов было, ни разу не было никаких глюков, удобно - не то слово. А теперь проксмокс в ходу. Промолчу про проксмокс, копрософт как он есть. Или вот openwrt, у меня этих виртуалок наверно под тысячу установлено, в системе из этого топика тоже есть - машина живет с 32ром/96рам и есть не просит. А вот для докера ничего простого и удобного готового не нашел.

https://github.com/RuriOSS/rurima/blob/main/doc/USAGE.md

там написано:

Undocumented part:
The load, run, sfx and netns subcommand is WIP, it should not be used by users.

А как же без run то?

https://github.com/containers/crun

Можно как-то приложение в контейнере через внешний strace запустить? Применительно к crun, либо docker вообще.

Как я понял в среде писателей стабильного софта докер не особо котируется, на что мне здесь уже намекали:) Alpine замечательная штука - на сотню перезагрузок уже три варианта глюков при старте, одна и та же виртуалка из холодной копии с одинаково пустыми логами просто иногда стартует не одинаково, но только при установленном докере. И работает эдак втрое медленнее photon.

В итоге остановился на photon os 5. Хоть и самая тяжелая из просмотренного, но всё поместилось, лучшая из всех скорость работы контейнера, феноменально быстрый запуск в работу и отличная стабильность. Alpine надо курить что-то за пределами официальных мануалов, непредсказуемое поведение, низкая скорость работы контейнера (на глаз раз в 3-5 ниже). Tinycore, воистину если захочется пару лет курить tfm для души - лучший выбор:)