Comments 26
Podman как альтернатива Docker. Со временем вы узнаёте, что Docker — не единственный вариант. Podman, например, не висит постоянно в памяти. Можно даже сделать алиас, alias docker=podman, и забыть, что у вас на самом деле не Docker.
Лично у меня с podman как-то не пошло.
Много мелких отличий (и это еще ладно, с этим можно разобраться, было бы время и желание).
Но вот технические проблемы заставили вернуться к docker. Простейший пример - неудачный перезапуск контейнера из-за занятого порта прошлой версией контейнера. В чем дело глубоко не копал (не всегда есть время и желание копать подобные проблемы), так что чинился перезагрузкой.
Наверное это решение проблемы? podman run --replace
--replace If another container with the same name already exists, replace and remove it. The default is false.
И чем это поможет, если я вручную останавливаю контейнер и вручную же его запускаю?
неудачный перезапуск контейнера из-за занятого порта прошлой версией контейнера.
конечно при условии что имя контейнера тоже самое.
Разумеется имя то же самое. Более того - ничего не менялось, даже образ оставался тот же.
Хотя при ручной остановке контейнера - имя не важно все-таки. Порты должны становиться доступными в любом случае.
Причем подобное происходило неоднократно.
К сожалению мало вводных:) Самые первые версии podman работали с предоставлением root, как docker сервис (который обслуживает все сущности для контейнеров), но после чего переориентировались к rootless mode, в котором работает не только Podman враппер, но и целая цепочка background сервисов, из которых за работу с сокетами и портами отвечает containers-rootlessport. Часто, из того что я видел, он продолжает оставатся активным для контейнера, даже когда контейнер остановлен, и тем самым продолжая держать заняными порты данного контейнера. И когда я делал --replace, оно удаляло старый контейнер, и освобождало используемые порты для новой копии контейнера.
Это было в прошлом году, на свежей Fedora, rootless.
И это явно была бага - потому как повторялась нестабильно. Чаще всего перезапуск контейнера не приводил к проблемам, даже если запускать контейнер сразу же.
К слову, это был не единственный прикол с портами. Я использую подход "разработка в контейнере", под каждый стек - свой контейнер. К контейнеру цепляюсь через SSH. И иногда не с 1й попытки удавалось достучаться из VSCode до контейнера. Иногда VSCode не мог достучаться, пока я вручную через консоль не подключусь разок.
Ну и завершающим штрихом было то, что в половине случаев я не мог загрузить систему нормально. После входа, при загрузке gnome - просто серый экран и все. Система ни на что не реагирует. В логах никакого криминала не увидел, поиск по симптомам в интернете ничего не дал. Так что могу только косвенно подозревать, что podman что-то не поделил при старте и произошел deadlock (возможно с docker "подрался"). Но именно что подозревать - перестал использовать podman и проблема ушла (хотя я его не удалял даже). И да, я знаю, что docker и podman не рекомендуют использовать совместно.
Так что лично у меня podman оставил не лучшие впечатления. Слишком много неожиданностей, помимо ожидаемого некоторого изменения поведения команд (относительно docker). Работать, конечно, можно, но стабильной работу не назвать.
P.S. а самый прикол в том, что все описанные проблемы могут быть вызваны одним сбойным модулем, сбои которого вполне могут быть именно локальными особенностями моей системы.
Это нормально, если за рабочий день вы запустите и грохнете пару сотен контейнеров.
Это не нормально, от слова - совсем… К сожалению, в последнее время это становится нормой, но если у тебя контейнер «просто взял и сломался», возможно, дело тут все-таки в пряморукости админа :)
>> но в целом контейнеры универсальны. - универсальны в рамках операционной системы под которую собирались, т.к. используют ее ядро.
>> LLM сейчас отлично умеют генерировать Dockerfile - отлично умеют, но версии и параметры будут устаревшими, нужно все тщательно перепроверять.
Контейнер у нас создаётся в системе с ядром 5, бежит локально на ядре 6, а ещё и в системах с ядром 3.
Веселья хватает на каждый день.
А еще версия docker может быть разной. Причем одной у разработчика, другой у CI/CD и третьей на сервере. И у каждой свои нюансы (и несовместимости). Или вообще не docker, а что-то еще стоять может (тот же podman). И кеши сборки могут быть разные, как и базовые образы при том же теге.
Но стоит сказать, что веселья явно стало сильно меньше относительно до-docker времен с "а у меня работает" от программиста. Да и по работоспособности docker-сборки можно с высокой степени достоверности определить, на какой стороне проблемы - у разработчика или на сервере (а может косячить и CI/CD).
А на такое лично не нарывался. Может уже это порешали до меня.
Есть примеры таких несовместимостей ?
Нарывался, что более старая версия docker на сервере не сумела запустить свежий образ (собранный более свежей версией docker).
Причем ошибка была не "новая версия образа, не могу прочесть", а что-то прям совсем непонятное и дикое - за давностью не помню, но вроде приложение падало с "нет доступа к ФС".
P.S. причем я как минимум две подобных ситуации помню, как решались проблемы обновлением docker. И оба раза внятных причин сбоя не было - приходилось идти в гугл и искать решение.
Конкретика немного есть тут (пара лет с небольшим случаю):
https://github.com/apache/solr-docker/pull/13 - образ JRE превратился в тыкву в определенный момент.
Веселье в том, что мы обновили docker до актуального из реп - получили новое сообщение об ошибке. И по новому сообщение вышли уже на это сообщение (оказалось, что в репах тоже чуть более старая версия, чем нужно).
про LLM добавлю 5 копеек IMHO: чтобы нормальный результат получить - надо потратить время и нормально сформулировать. и всё равно потом перепроверка и отладка. Зачастую очень быстрее получается "сделать с каких-то СВОИХ готовых наработок копию и поменять что надо". В-общем ИИ вообще не впечатлил в том виде как сейчас
Неплохая статья, была бы полезна 5 лет назад ;)
Только маленько по верхам во второй части, лучше бы была серия, но глубже.
А что с Виндой? Когда нужно виндовый домен, терминальник, сиквел-сервер и 1С?
@Контейнер — это изолированный процесс, которому кажется, что он запущен в отдельной системе. Но на самом деле он использует ядро хостовой ОС @
да и жизненный цикл домена не подразумевает частое пересоздание.
так то винда - это ВМ-ки, а вот сиквел смотря какой... вполне себе можно и сиквел и 1С закрутить в контейнерах. ну и 1с-ку в браузере - тогда и терминальный не нужен. остается вопрос: зачем тут домен?
Статью было бы вернее назвать как - то вроде «контейнеры для самых маленьких», а не так. Подумал, что тут про какие - то новшества, а тут просто про контейнеры в целом
Статья очень кстати, особенно когда застрял на поддержке инфраструктуры, работающей на виртуалках в опенстеке
Где мои 450к в месяц?
Представьте: у вас на одном сервере два приложения. Одному нужна Java 8, другому — Java 11. С виртуалками решение одно: две отдельные виртуалки.
Или можно сделать unshare -m, чтобы не тратится на создание отдельной файловой системы под каждое приложение; Или можно сделать chroot, чтобы не плодить неймспейсы линукса под каждое приложение; Или можно подменить PATH, чтобы вообще не зависеть от подсистем ядра Линукса; Или же можно просто не использовать /bin/java, а вместо этого хотя бы запускать приложение через /bin/java<версия>. В линуксе в принципе изначально плохо изолируется только libc по понятным причинам, который обычно никогда не надо изолировать. Я не понимаю, почему девопсы пытаются мне доказать, что поставить две версии интерпретатора на одну систему - это рокет сайнс, который требует неймспейсов, си групп и подмену рута одновременно.
И так со всем девопсом в целом: Большинство поднимает кубер только для того, чтобы либо "разгрузить" приложение с максимальным rps равным двум, либо разгрузить (уже без кавычек) приложение с максимальным rps равным двум. Имхо, два случая должны заставить задуматься о жизни и о направлении проекта.
Похоже мне никогда не увидеть 450к в месяц :p
:-) Комментарий правильный....
1) От разработчиков требуется полноценный программный продукт... С полноценной системой дистрибуции и обновления, мало того еще и масштабируемый (если клиентам это необходимо), и защищенный (если хранит/обрабатывает приватные данные) и безопасный (если не хотите получить проблемы со временем)... И это точно проблемы прикладных разработчиков, а не "дяди" администратора который будет этот продукт эксплуатировать. Администратору нужны указания/документация что он должен обеспечить, чтобы прикладной продукт работал безотказно и безопасно... И на нем же "висит" обязанность кроме прикладного ПО обеспечить "правильную эксплуатацию" системного ПО (ПО третьих производителей связанного с прикладным ПО).
2) Мало кого интересует сколько ресурсов требует "простаивающая система" - если она "простаивает" значит и ресурсы ей не нужны. "Умение" контейнеров "захватывать" ресурсы - требует времени на такой "захват", и если ваше прикладное приложение "по бизнес требованиям" может себе позволить "не отвечать" на время выделения ресурсов (или отвечать "повторите еще раз позже") - контейнеризация вам возможно подходит, а если после "простоя" приложения происходит "непредвиденный всплеск" нагрузки в 100 раз, ответ на которую требуется в течении 1 секунды - проблемы с "временем захвата" ресурсов и отказами в прикладной обработке будут. Разница же в потребляемых ресурсах (на высоконагруженных сервисах/приложениях) в пиках прикладной нагрузки между контейнерами и VM - малозначительна. Более того "вспомогательные" сервисы контейнеризации при абсолютной необходимости обеспечения их устойчивости к сбоям как правило нивелируют снижение требования к контейнеризированным прикладным сервисам (по сравнению с прикладными сервисами в VM).
Общий вывод - если у вас "наколенная система" с 10 прикладными TPS, контейнеры ваш выбор. Если же у вас в пиках от 300TPS, миллионы хранимых в сутки операций (БД с десятками терабайт) и простой в 5 секунд недопустим (поскольку после него придется обрабатывать уже 1500TPS), то что-то вспомогательное (не критичное) вы можете "запихнуть" в контейнеры, но основную нагрузку вы в контейнеры просто "не впихнете"...
Что вам надо знать в 2025 году про контейнеры, чтобы не пропустить важное