Как стать автором
Обновить

Комментарии 81

Отлично, освоил какое-то время назад докер, а теперь ещё и со внутренностями и дополнительными сущностями придётся разбираться! :(


В статье также не хватает информации о podman, чтобы жизнь была ещё ярче.

И хорошо что освоили, сам докер то никуда не исчезает. Он исчезает только из кубов.
«Освоил докер» это же хорошо.
Просто тут речь про «освоил мейнтенс и траблшутинг куб кластера».
Если это не ваша работа или не ваш интерес в плане развития, то на эти изменения вам можно глубоко наплевать :)

Первое и возможно главное что надо знать о podman это то что эго консольный интерфейс на 99% совместим с docker.
podman на моей рабочей федоре стоит месяца, я периодически строю и запускаю контейнеры, разницы в команндах не обнаружил пока.


Конечно есть ньюансы и они делаю podmanинтереснее. К примеру нет никакого демон процесса как у dockerи не нужен root.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

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

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Тот момент когда радуешься, что забил на k8s много лет назад и тебе теперь не надо переучиваться :)

И что выбрали?
Nomad очень хорош, особенно начиная с версии 1.0 с HCL2
Terraform + ansible + docker.
НЛО прилетело и опубликовало эту надпись здесь

AWS, Google и голое железо

НЛО прилетело и опубликовало эту надпись здесь
Однажды из html отпочковались css/js. Программистам пришлось делиться на фронт\бэк-эндеров.

Однажды «по мотивам» С создали С++ (потом еще и Delphi/Java/.NET выросли). В мире программирования снова добавилось специализаций.

Сейчас «разрастается» технопарк контейнеров. Вновь предлагаются\принимаются стандарты, вынужденно меняются привычные инструменты, используются временные решения и протекают абстракции.

Впереди волшебные «обратная совместимость», «критичные зависимости», «Docker легаси», «переписывание конфигов на новую модную универсальную облачную технологию», и, наконец, «простой в освоении и легковесный инструмент для быстрого создания\развертывания образов типичных бизнес-приложений».
Непонятно, при чем тут это все. Docker вовремя отдал все свои наработки в OCI и провел рефакторинг, благодаря чему мы сейчас имеем экосистему здорового человека — множество решений, совместимые между собой с четким делением функционала и абстракциями. На машине разраба докер, в CI докер или buildah, в кубере любой CRI совместимый рантайм вроде cri-o. И все это прекрасно сосуществует.
Как и с любыми другими абстракциями — «сосуществование» ограничено мэйнстрим-сценариями. Архитектура, в которой код пишется в одной среде, строится в другой и работает в третьей — это не CI/CD, а среднее между лотереей и «русской рулеткой».
Архитектура, в которой код пишется в одной среде, строится в другой и работает в третьей — это не CI/CD, а среднее между лотереей и «русской рулеткой».
Окружение, в котором код пишется, и в котором он работает в продакшене и так всегда разное, и рантайм для контейнеров тут не причём(и уж тем более CI/CD тут не причём).
Вообще-то он должен быть максимально похожим, собственно за это докер и любят
Вообще не должен.
Докер это про изолированность и решение проблемы с совместимостью в пару кликов.
Но никак не за максимальную похожесть, особенно если речь идет о производительности.
Оо
Докер — это прежде всего доставка кода! А потом уже изолированность. С совместимостью есть проблемы (когда ядра на хост машине сильно отличаются)
Окружение, в котором код пишется, и в котором он работает в продакшене и так всегда разное

Не то, что бы я сильно понимал в докере, но разве это не рецепт по созданию на проде совершенно глупых багов?

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

Вы на сервер IDE ставите? А доступ на запись в репозиторий git серверу даёте? Не получится у вас полностью идентичного окружения, ну вот никак.

А причем тут IDE и запись в git? Ну, если мы говорим не о разработке плагина для IDE. Приложение на рабочей станции разработчика билдится в докер-образ для теста, потом билдится в такой же докер-образ на CI и запускается в тесте и проде, получаем одинаковое окружение приложения(одинаковые библиотеки, как минимум) на всех этапах. Отличаются только настройки, данные в БД\хранилище и нагрузка, да и то не всегда.
Приложение на рабочей станции разработчика билдится в докер-образ для теста

вот делать мне еще нечего как на своей машине докеры билдить. Код пишется в IDE, там же билдится, запускается, отлаживается. Близкое окружение только у CI и прода, потому что СI, собственно, контейнеры и билдит.

А проблемы разного окружения просто решаются нормальными инструментами и языками, которые от любого чиха не разваливаются. Читай, дают reproducible builds из коробки.
Да, согласен, тут зависит от языка и инструментов. Не всегда и не все могут гарантировать что приложение, работающее из-под IDE с одними версиями библиотек заведется на версиях библиотек, лежащих в репозиториях из которых собирается образ. Поэтому нередко у нас разработчики интегрируют IDE с Docker и отлаживают сборку сразу в докере.
Вы наверное никогда не сталкивались с багами серии: не знаю что там на проде, у меня всё работает.

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

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

Ну вот на рабочей станции разработчика контейнер работает параллельно с IDE, а на проде — без IDE, и никакой проблемы тут нет. А если на рабочей станции запустить образ докером, а на проде — кубами, то кто-то считает это проблемой. Но в чём разница-то, почему IDE это одно, а программа, отдающая команду containerd запустить контейнер — это другое?

Это называется спецификации и переносимость.
Проведя в общей сложности 10 лет в разработке телеком и медицинских систем — где стандарты на спецификации и переносимость не только есть, но и соблюдаются — имею вам сказать что и то и другое покрывает только самые очевидные и простые взаимодействия. В телекоме даже специальные конференции проводят — «Test Fest» называются — куда разные компании привозят свое оборудование/ПО и в течении 5 дней пытаются заставить то, что в теории должно быть «плаг энд плей», хоть как-то заработать вместе.
Железо и ПО — таки несколько разные вещи.
Я имел в виду именно ПО в IP-сетях операторов/на телефонах. На уровне «железа» не приходилось работать, но думаю что там процессы принципиально не отличаются.
Кстати, в медицине то же самое — если у CT разных производителей формат DICOM более-менее похож, то у MR могут совпадать только данные пациента и дата сканирования.
Если спецификации протоколов соблюдены, то всё должно работать. Собственно, на то протоколы и придуманы :)
У нас под рукой есть отличный пример — интернет. Живет полностью на RFC с тучей реализаций на самых разных языках. И ничего, все работает какой бы сложности не было применение. Таких примеров много, в том числе в железе — USB, PCI, UEFI. Тут тоже самое. Спеки есть, их видимо соблюдают, раз у нас столько разных реализаций между собой не конфликтуют. То, что в каких-то индустриях так не получается, ну это их проблемы. Лучше надо было работать, если хотелось все таки стандарты иметь.
Это вы прикалываетесь так? «Все работает» более-менее только с хостами от Intel и девайсами от 5-6 ведущих производителей. Тот же Raspberry Pi (сделанный на чипе от Broadcom, далеко не последней фирмы) — нещадно глючит, например, если к нему подключить хаб или low- и high-speed устройства одновременно. А спецификации USB 2.0 уже 20 лет.
Эту спецификацию поддерживают Docker, containerd и cri-o, так что образ, собранный с помощью docker build на машине разработчика, должен без проблем запустится с помощью containerd или cri-o. И так и происходит в подавляющем большинстве случаев, но время от времени попадаются «нюансы реализации». Эти нюансы, конечно, исправляются, но иногда не так быстро, как хотелось бы.
Видимо, сосуществование не вполне прекрасное.

Не поймите меня неправильно: я рад Docker-у и OCI. Своевременная передача наработок из Докера в OCI — это здорово, это лучше 99% других подобных случаев. Google, Docker, RedHat и прочие внесшие лепту заслуживают только уважения.

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

Будет замечательно, если пессимист ошибётся, если участники OCI смогут сообща развивать технопарк контейнеров. Но, боюсь, пессимист не ошибется.
Docker вовремя отдал все свои наработки в OCI

Если бы отдал вовремя, не появился бы containerd

А разве containerd — не та самая отданная "наработка" докера?

|Неясно следующее. Я в Dockerfile формирую среду выполнения, например устанавливаю дополнительные библиотеки и т.п. В каком файле теперь это будет происходить если мы говорим о к8s?

Там же, локально и создавать докер контейнеры никто не отменяет.

А если вы делаете сборку в среде k8s то наверное надо смотреть в сторону Builda
habr.com/ru/company/redhatrussia/blog/467105
НЛО прилетело и опубликовало эту надпись здесь
Если я правильно понял — да. Единственное что сломается точно — Docker in Docker. Но он, к счастью, нечасто нужен в кластере, а на машине девелопера он продолжит работать.

Если воркеры CI/CD развёрнуты в кластере… Ждём Docker in K8s)

У нас сборка образов как раз в CI K8s делается. Так что даже любопытно стало, как это будет решаться.

Очень просто. Переходите на buildah или makisu какой-нить и забываете про докер в CI. Мы помню перешли банально, чтобы ускорить билды. Тащить за собой докер только для того, чтобы образ собрать, формат которого стандартизирован, это все таки изврат.

У нас buildah проиграл DOCKER_BUILDKIT=1 docker build по скорости

Пробовали werf для сборки? Много фич, чтобы сильно ускорить её.

Пробовал, даже баг-репорт есть по результатам проб

НЛО прилетело и опубликовало эту надпись здесь

Прямо как с JS-фреймворками :)


Так докер совсем не всё, стоит его все-таки освоить.
Старая армейская мудрость
Не спеши выполнять приказ — подожди, пока его отменят
Не проще ли добавить CRI в Docker?
Но выход есть! Для манипуляции с образами контейнеров можно воспользоваться дополнительной утилитой skopeo
Хех, спасительница
Ох уж эти кликбейтные заголовки, по факту только унифицируются cli
Вы не совсем правы. Тут скорее о том, что попытка сделать похожий cli совершенно другому инструменту привела к сложностям в понимании назначения и освоении
Заголовок кликбейтный. Более того — вводит в заблуждение. Упоминание kubernetes не хватает как минимум. За место того чтобы разводить эту чуму — могли бы наоборот с ней бороться, как делают нормальные авторы. Хотя б назвали бы «Docker — не deprecated, хватит хайпить!». Вроде и вызывающе, но уже не вводит в заблуждение. Содержание более-менее, но заголовок меня в бешенство вводит

"Я хотел воспользоваться докером — но оказалось, что он уже deprecated"

Мы добавили в свой PaaS поддержку BlobFuse Flex volume. Едва анонсировали для пользователей — появилось слово deprecated” в git репозитории к этому драйверу, как альтернатива — объявлен CSI драйвер (и только он будет поддерживаться с k8s 1.21), который “preview, not for production” сейчас, и “мы не уверены, что депрекейтед BlobFuse Flex volume поддерживается Майкрософтом” (смысл ответа на запрос к MS «что теперь делать?»).
И такое не редко. Наверное в современном мире успешнее не те, кто «старше, значит опытнее», а скорее те, кто «опытнее, значит более динамичные и гибкие» (это я о нас — тех, кто все эти компоненты и фреймворки использует).

Аналогично, я уже несколько статей прочитал, для успокоения, начиная с этой:

https://habr.com/ru/company/ruvds/blog/524942/

habr.com/ru/search/?target_type=posts&q=docker&order_by=date
habr.com/ru/search/?target_type=posts&q=kubernetes&order_by=date
1K статей посвящено каждой. Прошло ВСЕГО 4 года, с 2016 по 2020. И в завершение что-то сломали?
Сорян, но на этом месте можно ставить R.I.P. Дальше читать FAQ не вижу смысла.

То есть один containerd для dockerd и kubelet будет работать нормально, просто docker и kubectl не будут видеть контейнеры друг друга и могут быть сложности с пониманием почему не запускается что-то, хотя ресурсов вроде хватает — не хватает, просто не видно всех одновременно. Правильно?

Правильно, так уже давно работает. В k8s кластере у вас только containerd, kubelet работает напрямую с ним, docker там ставить нет смысла. На локальной тачке у вас docker + containerd, но о существовании второго вы и не догадыватесь, для пользователя работа с containerd происходит прозрачно через docker. Так что у вас не должно быть ситуации «не видно всех», т.к. одновременно вы не будете kubelet и docker ставить на тачку
Ну почему, разные требования бывают. На винде вон кроме докера нативного ничего нет. Собственно, без решения этого кубер вряд ли сможет отказаться от его поддержки вообще и в соответствующей баги народ там уже жалуется на разрабов. Если очень прямо надо докер сокет, чтобы торчал в куберовский под (тот же CI), то можно прокинуть. И тут тот факт, что docker ps не видит куберовский контейнеры, уже не имеет значения.
одновременно вы не будете kubelet и docker ставить на тачку

Почему? Пускай без извращений гетерогенных контейнеров в одном проекте, а просто один проект на k8s в minikube nativ, а другой в docker-compose или тупо bash алиас к docker run для каких-то команд

Уууу, повбывав бы падлюк…
Мне вот что не понятно теперь (без Docker) должно значительно уменьшится количество iptables правил и теоретически стабильнее будет работать при овер 100 подов на ноде?

Или изменения на этого никак не коснуться?
Нет. в k8s докеру вообще запрещено что-то с iptables делать. Так что в этом плане ничего не изменится.
iptables создают kube-proxy и CNI plugin
Уменшить их количество можно переключив kube-proxy на режим ipvs
или выбрать CNI plugin типа cilum, который использует eBPF — но тут надо понимать что вы делаете, а не бездумно следовать советам из интернета
Эти crio(1.20) и cri-tools — прям боль. Документации нет, информации нет. Что-то не работает, приходится сидеть голову ломать по нескольку дней.
Думаю, дай для эксперимента исключу кубер и создам контейнер «alpine» напрямую, через crictl. И тут выясняется, что тот огрызок информации, что хранится в репе на гите, не соответствует действительности. Выясняется, что информации по возможным параметрам конфига нет нигде, а запуск pod'a с конфигом из 5 строк из examples выдаст ошибку. Pod запустится, но в Ready не перейдет. Ошибку, которую не понять, потому что «не найден контейнер с ID <id pod'a>», и, внезапно, даже не нагуглить.
Путем экспериментов выяснилось, что это кубер не дает создать контейнер. На чистой машине без кубера все заработало. Но опять же, это надо еще догадаться.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий