docker или podman etc.

Бери любой. Не прогадаешь.

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

Кубер, конечно же.

Под etc подразумевается wsl2?

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

Какими?

Хотелось бы понять, что лучше внедрять в компании.

В контексте кубера — podman субъективно лучше, но сложнее (нужно подключать CRI-O и вот это вот всё).

В последних выпусках Радио-Т разбирались проблемы перехода с docker на podman. А проблемы есть.

В перспективе, Podman.

Docker — это вечнотекущий дерьмодемон, старающийся стать вторым systemd. Podman же стремится к управлению через systemd.

Внедряй Nix, будь в авангарде!

1. Берите что лучше знаете.

2. Если оба не знаете, берите докер как более популярный.

Ну так кубер и внедряйте жеж :)

https://m.habr.com/ru/company/flant/blog/531120/

Я в курсе. :)

Мне хотелось услышать, как ТС понимает происходящее. Потому что на самом деле между этими событиями и выбором между Docker и Podman нет абсолютно никакой связи.

Положняк такой: в качестве докера надо юзать podman, а в качестве кубернетеса - k3s.

Также надо не задавать тупых вопросов, а пойти и разобраться, зачем docker юзает containerd, который юзает runc и т. д.

почему же? Поясните что имеете в виду

В перспективе событие бьет по docker точно

почему же?

Потому что и docker, и dodman на выходе производят OCI-образы. При этом не суть важно, какой контейнерный рантайм у тебя будет в k8s.

В перспективе событие бьет по docker точно

Не бьёт. По docker бьёт только распространение kubernetes.

dodman

podman

По docker бьёт только распространение kubernetes.

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

Это в какой части он перешёл на podman? Podman вообще не совсем для встраивания в куб, насколько я знаю.

вы статью с хабра по ссылке выше прочитали?

Ну да. K8s по умолчанию использует containerd, являющийся частью Docker, отпиленной от него именно ради кубера. containerd сейчас полностью нативный CRI, не требующий костылей.

почему же? Поясните что имеете в виду

Потому что Kubernetes не «отказывается от Docker». Docker распилили на куски — сам dockerd (демон, управляющий высокоуровневыми задачами и жизненным циклом контейнеров) и containerd (собственно контейнерный движок).

Суть изменения в том, что kubelet теперь разговаривает напрямую с containerd через более-менее стандартизированный интерфейс (CRI), а dockerd в качестве прослойки более не требуется. Но это всё равно части одного и того же проекта.

В перспективе событие бьет по docker точно

Узбагойся. Ни по кому «событие» не бьёт.

который во внутренней структуре перешел на podman, я про это

Podman вообще не совсем для встраивания в куб

Оба несёте чушь не правы.

Podman можно «встроить» в куб. Точнее, не сам podman, а libpod (опять же, нижележащий контейнерный движок). Их можно подружить через ещё одну прослойку (CRI-O), но о том, чтобы сделать это умолчанием, никто не говорит.

спасибо за пояснения:)

короче говоря. особой разницы нет что использовать? хотя бы понять на будущее. что лучше выбрать

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

Если ты линуксоид, то лучше podman, потому что rootless-контейнеры, buildah, cgroupsv2 и т.п.

Если ты линуксоид но среди маководов - бери пока докер. Потому что маководам бестолку объяснять про rootless-контейнеры, у них их нет, а работать придётся вместе.

Если ты линуксоид, то лучше podman, потому что <…> buildah <…>

Ну вот в подмане buildah (только я не понимаю идеи, зачем он конечному пользователю? я верю, что это классный фреймворк, но с точки зрения прикладного опса он почти бесполезен), а в докере BuildKit. И кстати BuildKit очень вкусный.

Ну вот в подмане buildah (только я не понимаю идеи, зачем он конечному пользователю?

Если я правильно понимаю то BuildKit - это вещь в себе.

А buildah - это набор cli-команд. То есть это не декларативная, а интерактивная сборка образов, так что шаги сборки можно запихивать в скрипты и интегрировать с другими инструментами.

#!/usr/bin/bash   
buildah run $container -- dnf -y install java
buildah run $container -- dnf clean cache
buildah commit $container $myImage

Можно сделать отдельные шаги сборки образа частью Makefile например.

С таким подходом есть конечно свои проблемы. Вместо декларативного Dockerfile мы получаем возможность программировать образ на баше. И мы знаем что написание bash-простыней в свободной форме - это не всегда хорошо :)

Но иногда это бывает полезно.

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

То есть твой же аргумент из соседней темы про Nomad. Ну можно поверх buildah переизобрести докерфайлы. Но зачем.

С таким подходом есть конечно свои проблемы. Вместо декларативного Dockerfile мы получаем возможность программировать образ на баше.

Эээ… а в каком месте докерфайлы-то декларативные? RUN то, RUN сё, ADD третье.

Ну правильнее сказать не декларативные а ограниченные.

for-loop у тебя не получится в них вписать.

То есть твой же аргумент из соседней темы про Nomad.

Ну и там же есть все те же аргументы, которые можно привести в его пользу. Так и живём :)

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

Там правда до сих пор каша с пониманием того как лучше сделать сборку контейнера в контейнере, но работа идёт.

Там правда до сих пор каша с пониманием того как лучше сделать сборку контейнера в контейнере, но работа идёт.

А кстати как?

Честно говорю — даже не пытался гуглить, но вопрос интересный. В докере есть dind, ещё есть всякие тулзы типа skaffold (про которые я тоже только краем глаза слышал, но вроде бы они собирают напрямую, вообще без контейнерного движка). А в экосистеме podman как?

Там надо взять подходящий тип файловой системы, отключить какие-то параметры изоляции, нахимичить с userns и потом оно не сработает :)

Ну то есть вот тут человек описал как он собирает с помощью buildah в GitLab CI

А сам проект buildah вообще-то собирает контейнеры, которые можно использовать для такой сборки.

https://github.com/containers/buildah/blob/master/contrib/buildahimage/stable/Dockerfile

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

Ещё вот тут есть статья https://developers.redhat.com/blog/2019/08/14/best-practices-for-running-buildah-in-a-container/