Комментарии 36
Хм а апофеозом хайпа можно назвать всякие туториалы по запуску штук типа nextcloud на rpi при помощи докера. Вот уж точно гвозди микроскопом заколачивать предлагается.
Гвозди микроскопом? Помоему докер как раз отлично позволяет запускать кучу всякой мелочи на домашнем железе, простым способом, без особого насилия корневой системы.
У меня на WD MyBook Live - MIPS, 256MB ОЗУ, 2TB винт, Debian 6 - в «клетках»: трансмишн, DLNA, iSCSI - как Вам такое?
Это микросервер получается? Хотя, стоп! Микросервер у hp и там четыре диска, плюс-минус... Это наносервер выходит!
Всё работает три года уже как, плюс-минус, но с доп.вентилятором сверху. Скоро буду переезжать на подставку для ноута с 4-я вентиляторами - WD'шек у меня много, весь ассортимент почти, до Home серий.
PS: «Клетки» - не докер, конечно, но суть та-же.
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 и правильно пробрасывают волумы
Это всё контейнеры с состоянием. (кроме мб podman, про него ничего не знаю)
freebsd jail
а что разве jail можно будет запустить на не freebsd системе ? Если нет, то это совсем не альтернатива
systemd-nspawn
а зависимости откуда оно возьмет ?
Основной плюс docker, что в большинстве случаев, достаточно взять Dockerfile/docker-compose.yml и выполнить одну/две команды команду - docker build/run и/или docker-dompose up. Причем, не важно под какую систему собрано приложение, будь это даже alpine, то оно одинакого будет работать и на CentOS/RHEL/Debian/Ubuntu
Так и представляю как qa настраивает jail/lxc и поднимает окружение из 5-7 сервисов, взаимосвязанных между собой. Сколько часов/дней он на это потратит ...
А потом еще оказывается, что разработчик на Windows, qa на macos
А потом еще оказывается, что разработчик на Windows, qa на macos
с Docker не сильно меньше геммороя
А сколько он на докер потратит? День? Два?
На порядок меньше, в общем случае, если упростить то apt install docker && docker-compose up. Все ! И это большое преимущество докера
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 не слышали ? Хоть хостовую директорию подключай.
Короче дальше не читал.
Контейнеры ничего не сохраняют, это неизменяемые read-only модули.
По мне так это больше плюс.
Они считали, что система Kubernetes слишком сложная, в ней никто не
разберётся и людям больше по вкусу придётся нативный оркестратор Docker
Swarm, очень простой в использовании, с маленькой и ясной документацией.
Где-то я уже это видел ... А вспомнил Git vs Bazaar
О чем статья?
Возможно, причина ещё и в плохом маркетинге: некоторые пользователи Kubernetes не знали существовании Docker Swarm.
Кроме того, была проблема личных комплексов и фундаментального эго. Элитные разработчики Google с некоторой долей презрения смотрели на программистов из стартапа Docker, поскольку у тех было хуже образование, меньше опыт и общий уровень IQ.
Kubernetes был значительно функциональней и более зрел даже когда стал доступен публичной аудитории нежели сворм, архитектурно выбран правильный подход с декларативностью описания конфигурации и модульностью, обеспечив возможность готовить его на гетерогенных инфраструктурах, практически полностью абстрагируясь от особенностей этих платформ. Он стал стандартном описания среды запуска приложений в основном из-за этого. Про элитный разработчиков, эго и комплексы - какая-то бредовая жесть)
Лучшие альтернативы для Docker