Выпуск Podman 2.0

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

А как бы вы это сделали?

Это ложь. На чем-то сложнее, чем hello world, podman работает иначе, чем docker, и прямое использование прошлой архитектуры становится невозможно.

Пруф или GTFO.

Годно, нужно. Разобраться наконец в синтаксисе podman, что ли.

Вот только в типичном коммерческом продакшене все эти подманы, альтернативные рантаймы для k8s и т. п. так и не вышли за рамки «заморского чуда, на которое можно максимум поглазеть, а потом вернуться в реальный мир и продолжать делать всё как делали». Мне скорее интересно, когда это произойдёт.

Флаг –restart-policy для команд podman run и podman create теперь поддерживает политику unless-stopped.

А как, кстати, это работает без центрального демона? podman под капотом создаёт systemd-юниты?

в типичном коммерческом продакшене все эти подманы, альтернативные рантаймы для k8s и т. п. так и не вышли за рамки «заморского чуда

https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine

With OpenShift 4, the default container engine is moving from Docker to CRI-O, providing a lean, stable, simple and boring container runtime that moves in lock step with Kubernetes.

А как, кстати, это работает без центрального демона? podman под капотом создаёт systemd-юниты?

Я так поняла что --restart – это в рамках одного процесса podman. То есть если процесс внутри контейнера завершится, то podman-обертка его снова запустит. Но если сам podman завершится - то всё, перезапускать будет некому.

А systemd-юниты он умеет генерить, но это не под капотом, а явно, через вызов podman generate systemd.

Докер помойка потому не нужно.

А как бы вы это сделали?

Делегировал бы пользователю и всё – типа ставишь чекпоинты по местам разным в докерфайле. Зачем мне intermediate container на каждый чих и команды составленные в виде x && y && z && a в 50 стопок, просто чтобы он не создавал их. Это назвается поместить себя в рамки, чтобы костылями их решать. Да он ещё для них хэш считает. Это ппц.

Для просветления тебе осталось только прочитать про buildah.

https://github.com/containers/buildah/blob/master/docs/buildah-commit.md

Временные контейнеры в большинстве случаев не нужны вовсе. Из 50-ти команд нужны они раза 4.

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

Вот только в типичном коммерческом продакшене все эти подманы, альтернативные рантаймы для k8s и т. п. так и не вышли за рамки «заморского чуда, на которое можно максимум поглазеть, а потом вернуться в реальный мир и продолжать делать всё как делали». Мне скорее интересно, когда это произойдёт.

Прямо сейчас через gcloud container ты можешь запуститься с cos_containerd или ubuntu_containerd без докера.

Собираю докерфайлом, начальство на ковер не вызывало =D

buildah уже научился использовать кеш?

Если нет, то я лучше продолжу использовать kaniko.

троллинг тупостью, это не троллинг

земля те пухом

Я думал там давно все однострочники пишут, на пять экранов, из-за одебилевшего формата докерфайла.

Доки по сборке Го-приложений это вообще нечто. Пайк пыхтел писал быстрый компилятор, чтобы всё это просто было перечёркнуто в Докерке до нуля. Аутентичный пример

COPY go.mod .
COPY go.sum .
RUN go mod download

# ^^^ трудно представить, но это нужно для ускорения сборки в контейнере

COPY . .

RUN go build -o main .

Собственно давече go.sum ещё обновлялся на каждый чих. А go mod download тащит все зависимости по сети, Карл.

Sic transit gloria mundi.

alpha, ugoday, ну и собственно выгодней было бы кэшировать как раз последствия чертовски долгой go mod downalod, для которой нужны go.mod и go.sum (каждый раз обновлённые с некоторой вероятностью); причём кэшировать на неделю или на какой-то предельный размер, например, чтобы не таскать по сети каждый раз всё это.

P.S.: ну и чё buildah могёт так?

Делегировал бы пользователю и всё

Я не понимаю что это значит. Приведите пример что ли «правильного» Dockerfile.

команды составленные в виде x && y && z && a в 50 стопок,

А как тогда объяснять когда слои создавать, а когда — нет?

Да он ещё для них хэш считает. Это ппц.

Почему ппц и как надо?

Прямо сейчас занимаемся миграцией части кластеров с 6 на 7. Ни у кого из команды не возникло таких бредовых мыслей, как у тебя, относительно systemd. Так как все - профессионалы своего дела, то просто разбираемся, как решать наши задачи с помощью этого инструмента. И да, возраст от 30 до 50.

Меряться пенисами — давняя и славная забава, но чтоб чужими …

Меряться пенисами — давняя и славная забава, но чтоб чужими …

Тебе виднее, чем ты там меряешься. Я бы на твоем месте задумался на тем, что не так с твоей способностью к обучению, если такая очевидная в плане эволюции вещь, как systemd, вызывает у тебя резкое неприятие.

Непонятно что ты вообще хотел этим примером сказать.

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

http://vasya-lozhkin.ru/upload/iblock/794/7947cf687808e4569506c1033806de46.jpg

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

Нет проблемы качать их по сети. Есть проблема невозможности оставить их там, в контейнере, не смотря на будущие изменения go.mod и go.sum. Ну и так далее…

Я не понимаю что это значит. Приведите пример что ли «правильного» Dockerfile.

Явно делать промежуточные контейнеры. Что тут может быть не понятно?

А как тогда объяснять когда слои создавать, а когда — нет?

А что если первые 15 команд мне нужна только изоляция, а не слои? Как тогда Докер должен это понять?

Есть проблема невозможности оставить их там, в контейнере

Нет такой проблемы. В случае с докерфайлом для такого варианта тебе надо базовый слой с кешом исходников отделить в свой образ, типа go-deps. А при сборке приложения делать FROM go-deps.

Тогда как раз кеш у тебя будет доступен сразу и качать его заново не понадобится.

buildah решает этот вопрос по-другому, поскольку отдаёт тебе полный контроль над процессом сборки, и ты можешь какую угодно логику кеширования реализовать самостоятельно.

То есть на хостах где отличная от systemd система инициализации podman вообще не будет работать ? Так как часть функционала docker, podman использует из systemd ?

Ты просто слепил сборку софта со сборкой контейнера и жалуешься. Софт надо отдельно собирать, контейнер - отдельно. Потому что последнее это для рантайма. Потому что это разные задачи и кешируются они по разному.

А какие есть production quality дистры без systemd?

Ты просто слепил сборку софта со сборкой контейнера и жалуешься. Софт надо отдельно собирать, контейнер - отдельно. Потому что последнее это для рантайма. Потому что это разные задачи и кешируются они по разному.

Я не могу вылезти из контейнера потому что сборка софтины идёт на основе другого контейнера с какими-то там специальными либами, используемыми при сборке (софтины).

В отличие от Docker, который хардкодит DockerHub и не принимает патчи чтобы сделать дефолтный реп конфигурируемым, podman позволяет сконфигурировать несколько источников образов и ищет по ним по очереди.

А чем не устраивает ? docker pull example.com/test-image

С другой стороны всё равно нужен какой-то оркестратор. Так что следующим шагом у вас будет: смотрите все, в версии podman3 мы добавили podman-manager, который будет мониторить наши чудесные контейнеры, перезапускать их и т.д.

Только это будет отдельная штука, которую ты можешь ставить, а можешь и не ставить.

Явно делать промежуточные контейнеры.

Образы наверное. Что вам сейчас мешает явно сделать промежуточный образ, а потом FROM my-base-image:0.1.3?

А что если первые 15 команд мне нужна только изоляция, а не слои?

RUN очень && длинная && строка && с командами.

Если тебе нужны какие-то системные библиотеки м утилиты, ты же их через yum/apt/whatever ставишь, а не gentoo style из исходников. Также и с основным аппом должно быть: собирается на билд сервере в артефакт, потом просто скачивается и разворачивается в контейнер при сборке.

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

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

Если сервер свой, можно подумать про кеш через volume mount.

Или, как предложила !alpha, запечь в контейнер (но это должен быть чисто сборочный контейнер, и не надо заменять нормальный ci скрипт докерфайлом).

Путь до registry зависит от инфраструктуры. Из-за того что для докера приходится его прописывать в явном виде, у тебя скрипты деплоя должны знать куда именно деплоят. Носить эту информацию через всю инфру очень дорого.

А podman pull image будет работать одинаково вне зависимости от того запускаю ли я это на своём ноуте, на сервере в штатовском дц или на сервере в гонконге, который должен тащить образ с приватного зеркала registry развернутого там же, потому что с доступом в штаты там проблема.

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

Или поднять какой-нибудь artifactory с виртуальным репом и проксей, чтобы адрес единый был. Но я согласен, что в докере это костыль и сам об него кололся несколько раз.

Это замечательно, но перспективы сэкономить 0.5% системных ресурсов не достаточно, чтобы менять базовые инструменты. По крайней мере в моём случае.

Нам твой случай очень интересен и важен. Продолжай писать о нем побольше.

То есть на хостах где отличная от systemd система инициализации podman вообще не будет работать ? Так как часть функционала docker, podman использует из systemd ?

Не так.

podman - это стандартный процесс. Без скрытых запросов к сторонним сервисам и т.п. Он не использует systemd для запуска контейнера, но, как любой простой процесс легко встраивается в любую стандартную систему управления процессами. То есть благодаря тому что podman не лезет в оркестрацию, повышение привилегий и т.п., а просто запускает контейнер, он совместим с любой готовой оркестрацией, хоть от systemd, хоть от openrc, хоть от openmpi.

Путь до registry зависит от инфраструктуры.

Дал Господь частный реестр образов, даст и VPN до него. Безотносительно деталей реализации на машине, где вы делаете pull image должна быть сетевая связность с реестром. Собственно, вы либо явно задаёте имя как registry/image, либо используете неявный реестр по умолчанию, который всё равно должен быть как-то прописан на хосте. Что, в принципе не так уж и плохо, но на «Путь до registry» никак не влияет.

Да я уже поняла что ты любитель богом данных костылей.

Разумеется это проблему можно решить, разными способами. Я её тоже решила в своё время. Но это никак не меняет того факта что хардкод докер-хаба в коде и отказ от приёма патча, который это чинит - это чисто маркетинговое решение компании Docker, позорное с технической зрения.

А впрочем, если я правильно понял слова альфы, в случае podman мы будем иметь по процессу подмана на каждый контейнер, так что ещё вопрос что легче. Но в любом случае это экономия на спичках.

Давайте не будем про маркетинг. Мне это не интересно, да и вам наверное то же. Я говорю о простой вещи: мы можем задавать частный реестр в имени образа, а можем иметь параметр в конфиге с именем реестра по умолчанию. Второй способ выглядит несколько красивее, но с точки зрения сетевой инфраструктуры они абсолютно одинаковы.

Половина осталась работать. Половина просто зафризилась и потеряла сеть.

с точки зрения сетевой инфраструктуры они абсолютно одинаковы

Нет. Для того чтобы они стали одинаковы с точки зрения инфраструктуры, инфраструктура должна быть соответствующим образом настроена. То есть мы уже ломаем separation of concerns и требуем перенастройки базовой инфры (сетевой) для работы деплой-скриптов приложения (которые от железа и топологии сети должны давно быть абстрагированы).

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

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

До появления podman в Fedora, CentOS и RHEL этот патч накладывали на docker при сборке rpm-ки. Потому что в отличие от тебя, «суровый энтерпрайз» не любит костылить обходные пути в настройках сети без реальной необходимости.

Ага, и оно еле-еле вышло из беты (или ещё не вышло)?

Ну и containerd это всё равно кусок докера.

А что есть почитать про Podman?

Как я понимаю, в RHEL 8 и CentOS 8 для того что получить, например, GCC или Clang/LLVM новой версии, лучше использовать именно Podman, а не сторонние (хоть и официальные) репозитории вроде SCL, EPEL и пр. Так ли это?

Людям там может быть удобно работать. Не любой рабочий процесс можно запихнуть в jenkins.

Для того чтобы они стали одинаковы с точки зрения инфраструктуры, инфраструктура должна быть соответствующим образом настроена

Не понимаю. Есть два варианта:

1. docker pull example.com/image:tag — после чего нам нужно разрешить example.com в ip адрес, найти маршрут до того адреса, установить соединение и т.д.

2. podman pull image:tag — после чего нужно взять из конфига имя реестра example.com, разрешить example.com в ip адрес, найти маршрут до того адреса, установить соединение и т.д.

Я не вижу тут больших различий с точки зрения инфраструктуры.

в Fedora, CentOS и RHEL этот патч накладывали на docker при сборке rpm-ки.

NIH синдром красношляпы меня абсолютно не удивляет.

Билд-сервер, вы же о нём говорили, обычно работает именно так, как я написал. Человеки нужны чтобы код писать, а ходить на сервера, запускать компиляторы, выгружать артефакты сборки и машина может.

Не любой рабочий процесс можно запихнуть в jenkins.

Опишите мне ваш рабочий процесс. Интересно же.

P.S.: ну и чё buildah могёт так?

Kaniko может.

можно подумать про кеш через volume mount.

Хм, наверное это оно.

Есть два варианта:

apt install kernel

apt install www.debian.org/kernel (надеюсь, аналогия понятна).

Требования к production quality дистру опишите