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

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

Хм а апофеозом хайпа можно назвать всякие туториалы по запуску штук типа nextcloud на rpi при помощи докера. Вот уж точно гвозди микроскопом заколачивать предлагается.

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

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

Если не хватает ресурсов на корневой системе, то докер тут не виноват ине поможет(его отсутствие)

У меня на WD MyBook Live - MIPS, 256MB ОЗУ, 2TB винт, Debian 6 - в «клетках»: трансмишн, DLNA, iSCSI - как Вам такое?

Это микросервер получается? Хотя, стоп! Микросервер у hp и там четыре диска, плюс-минус... Это наносервер выходит!

Всё работает три года уже как, плюс-минус, но с доп.вентилятором сверху. Скоро буду переезжать на подставку для ноута с 4-я вентиляторами - WD'шек у меня много, весь ассортимент почти, до Home серий.

PS: «Клетки» - не докер, конечно, но суть та-же.

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

49% разработчиков регулярно используют Docker Desktop

Серьёзно? о_О

Консольный docker-compose на порядок удобней.

Ну это относительно. Когда я попробовал попользоваться lens, вместо постоянного kubectl exec ... kubectl get pods и т. д. это куда приятнее и проще. Стразу и статистика по нодам и быстро конфиги с секретами поправить можно и инфа по всем упавшим контейнерам, если такие есть.

Хотя раньше тоже думал, что консолная тулза удобнее.

Это потому что для вас это не центральная вещь в работе. Раз в день логи посмотреть.
А когда вам надо грепать, фильтровать сложные списки и прочее, Lens уже не поможет. Операторов и прочие CRD тоже не видно - только стандартные ресурсы, коих от силы 10% в кластере. Нету валидейшен-хуков и мутаций, если не путаю. Ингресс тоже только ингрессом представлен, а где ИнгрессРаут для Traefik?
Статистика/метрики у Lens тоже примитивные. Даже если всё подкдючить к настоящему Prometheus.

Короче, это игрушка :-)

Здесь автор немножко переврал. В опросе Stack Overflow всё же указан именно Docker (без Desktop).

Далеко не все разработчики любят открытыать консоль и делать что-то помимо запуска их кода

Сколько разработчиков видел,задачи по поднятию контейнеров или не дай бог docker-compose стараются кинуть на системного администратора или же находят дефолтные конфиги,правят и молятся на то,чтобы не потерять их,ещё рядом с конфиг файлом создают текстовый файл с командами или bash/cmd скрипт

Другое дело Docker Desktop,просто и удобно,хотя контейнер через него не поднимешь,всё равно в консоль лезть надо,а вот задачи по принципу,запустить/остановить/провалится/глянуть логи - вообще на ура решает

я вообще удивлюсь если кодеры с понимаем процесса собирают images и правильно пробрасывают волумы

альтернативы docker:
lxc/lxd
podman
freebsd jail
systemd-nspawn

в статье же упоминается только podman.. может стоит сменить название на "лучшая альтернатиВА.."?

мда.. леньтяи..

Это всё контейнеры с состоянием. (кроме мб podman, про него ничего не знаю)

lxc с состоянием по умолчанию, но может быть и как докер

вообще lxc может всё что может docker, но docker может только часть того что может lxc

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

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

freebsd jail

а что разве jail можно будет запустить на не freebsd системе ? Если нет, то это совсем не альтернатива

systemd-nspawn

а зависимости откуда оно возьмет ?

Основной плюс docker, что в большинстве случаев, достаточно взять Dockerfile/docker-compose.yml и выполнить одну/две команды команду - docker build/run и/или docker-dompose up. Причем, не важно под какую систему собрано приложение, будь это даже alpine, то оно одинакого будет работать и на CentOS/RHEL/Debian/Ubuntu

Если нет, то это совсем не альтернатива

альтернатива, хоть и под другую ось.

Основной плюс docker...

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

Так и представляю как qa настраивает jail/lxc и поднимает окружение из 5-7 сервисов, взаимосвязанных между собой. Сколько часов/дней он на это потратит ...

А потом еще оказывается, что разработчик на Windows, qa на macos

А потом еще оказывается, что разработчик на Windows, qa на macos

с Docker не сильно меньше геммороя

Чушь какую-то сморозил

А сколько он на докер потратит? День? Два?

При наличии, готовых образов конфигов что на докер что на lxc что на jail потратит минуту, если будет ваять с нуля то дофига времени

Ну а если разработчик и qa используют ос отличную от той под которую пишется софт то им выдаётся сервер/виртуалка/etc для такой задачи. Хотя я бы сто раз подумал прежде чем человеку сидящему на винде и отказывающемуся мигрировать на что-то удобное и адекватное давать возможность писать в прод.

А сколько он на докер потратит? День? Два?

На порядок меньше, в общем случае, если упростить то apt install docker && docker-compose up. Все ! И это большое преимущество докера

и снова чушь

1) docker-compose не является часть docker а является "инструментом сбоку"

2) если мы всё-таки берём в учёт инструменты сбоку то для lxd всё может выглядеть ровно так же в одну команду стягивание с репы/реджистри и запуск lxc контейнера с конфигом из yml файлика

docker-compose не является часть docker а является "инструментом сбоку"

дальше даже говорить нет смысла

то что в вашем дистрибутиве docker-compose ставится одновременно с docker - это специфика. Есть дистрибутивы, где установка производится только docker и docker-compose приходится ставить отдельно.
Ровно так же, как считать, что vi запускает vim, не сталкиваясь с дистрибутивами, где при запуске vi запускается именно vi, а потом удивляться, почему привычные комбинации клавиш не пашут

Есть дистрибутивы, где установка производится только docker и docker-compose приходится ставить отдельно.

А что имеется ввиду под установкой docker-compose ?

$ wget https://github.com/docker/compose/releases/download/v2.2.3/docker-compose-linux-x86_64

Одна команда и docker-compose установлен. Или сейчас вы расскажите, что wget тоже не везде есть и вообще это не имеет отношение к docker ))

С таким же успехом линукс можно рассматривать отдельно от базового набора утилит, таких как wget/curl/sed/grep/find/awk. Это тоже все инструмент с боку, как сказали выше )))

docker-compose - отдельный инструмент, который не входит в состав Docker, но входит в его экосистему. Тут скорее swarm входит в Docker, так как не требует дополнительной установки.

А про линукс - ну, по сути своей... да. Потому как Линукс, это совокупность ядра и программ и там вовсе не обязательно будет тот же wget, который по сути тот же "инструмент сбоку" для POSIX

В статье постоянно смешиваются понятия "контейнер" и "образ" (образ вообще не используется), хотя это разные вещи.

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

Если разбить на составляющие...

Тут вообще какая то дичь

Чтобы сохранить состояние, как у виртуальной машины, необходимо разработать специальное решение.

Про volume не слышали ? Хоть хостовую директорию подключай.

Короче дальше не читал.

а можно ссылку? я всю дорогу думал что редхат топит за подман а lxd это детище каноникла (который из-за перестановки snap на первое место это детище и убивает)

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

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

ну не совсем, в lxc так тоже можно (см lxd), а основная идея лохера в неизменяемости, контейнеры ro, рестартани и ты снова в исходной точке (что в lxc так же возможно если в качестве образа использовать например squashfs).. докер это просто кострированная версия lxc с переделанным некоторым функционалом..

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

я бы с удовольствием выкинул лохер на помойку и остался верен lxc/lxd, но реалии таковы что 99% работодателей с вменяемой зп предпочитают кубер с докером

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

Контейнеры ничего не сохраняют, это неизменяемые read-only модули.

По мне так это больше плюс.

Они считали, что система Kubernetes слишком сложная, в ней никто не
разберётся и людям больше по вкусу придётся нативный оркестратор Docker
Swarm, очень простой в использовании, с маленькой и ясной документацией.

Где-то я уже это видел ... А вспомнил Git vs Bazaar

О чем статья?

О ключевых словах и ссылках.

Возможно, причина ещё и в плохом маркетинге: некоторые пользователи Kubernetes не знали существовании Docker Swarm.

Кроме того, была проблема личных комплексов и фундаментального эго. Элитные разработчики Google с некоторой долей презрения смотрели на программистов из стартапа Docker, поскольку у тех было хуже образование, меньше опыт и общий уровень IQ.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий