что в нём хорошего? и что плохого?
стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого?
А что хорошего и плохого в виртуальных машинах? Может википедию сначала почитать? Лично мне докер очень нравится — позволяет очень просто и быстро развернуть нужное окружение.
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
Тебе видней. Изучается он на базовом уровне за пол дня.
M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Является ли лопата серебрянной пулей? А молоток? Детские какие-то вопросы.
Здравствуйте, MTD, Вы писали:
MTD>А что хорошего и плохого в виртуальных машинах? Может википедию сначала почитать? Лично мне докер очень нравится — позволяет очень просто и быстро развернуть нужное окружение.
зачем докер, если уже есть виртуальные машины?.. чем он лучше?
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего?
Одной командой можно развернуть нетривиальное окружение на любой ОС. Можно очень быстро запускать много экземпляров чего-нибудь, восстанавливать окружение и тд. Например я думаю заюзать докер для БД-тестов: заранее готовится образ с БД и нужными таблицами, перед каждым тестом запускается отдельный инстанс БД, после теста выбрасывается.
M>и что плохого?
1. Это контейнер, а не виртуальная машина, если окружение завязано на ОС, ничего не получится. Например я работаю с Oracle 9i, который требует RHEL 4 и специальных настроек ядра, докер тут не поможет.
2. Не раз слышал про проблемы с производительностью. Для разработки, конечно, пофиг, для продакшна надо тестить.
3. Под венду официальная сборка требует hyper-v, а это Pro, на Home пролетаешь. Вроде есть какие-то старые сборки с виртуалбоксом, наверное придумать можно что-нибудь, но всё равно неприятно.
4. Все эти образы жрут сотни мегабайтов, а то и гигабайты. Ставить убунту на 300 мегабайтов ради постгреса в 3 мегабайта иногда кажется странным.
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы? M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Хз, чего там изучать, там всё тривиально, за 10 минут можно разобраться. Какие там митапы.
Здравствуйте, MadHuman, Вы писали:
MTD>>А что хорошего и плохого в виртуальных машинах? Может википедию сначала почитать? Лично мне докер очень нравится — позволяет очень просто и быстро развернуть нужное окружение.
MH>зачем докер, если уже есть виртуальные машины?.. чем он лучше?
У виртуальных машин больше расходов. Ядро грузится секунды, жрёт мегабайтов 10 оперативной памяти как минимум. У контейнеров этих расходов нет. Ну и самое главное, докер это экосистема. Я одной командой могу wordpress установить, другой postgres с redis поднять, а с виртуалками надо тратить время.
Здравствуйте, MadHuman, Вы писали:
MH>зачем докер, если уже есть виртуальные машины?.. чем он лучше?
Тем что ты одной командой поднимаешь из DockerFile нужное тебе окружение:
FROM ubuntu:17.04
WORKDIR /some_dir
RUN apt-get update
RUN apt-get install cmake -y
RUN apt-get install g++ -y
RUN apt-get install libboost-all-dev -y
ADD src src/
ADD CMakeLists.txt .
RUN cd mkdir build && cd build && cmake .. -DCMAKE_BUILD_TYPE=Release && make
EXPOSE 80
CMD cd build && ./server
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего?
изолированная среда, которую при желании можно соединить с чем-то ещё
меньше проблем с правами
M>и что плохого?
хреновый дизайн команд управления
нестабильность
проблемы с безопасностью
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы? M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
изучить стоит. контейнеры будут развиваться.
надеюсь только, что иным образом.
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого? M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
Например, docker-compose позволяет одной командой запустить десяток сервисов, прогнать интеграционные тесты и всё за собой убрать. Это ли не чудо?
Здравствуйте, mizuchi, Вы писали:
m> что в нём хорошего? и что плохого?
Хорошего в нем мало — обычная надстройка для тех, кто не осилил LXC и/или пакетные менеджеры. Много в чем ограничена, многого не умеет. С переменным успехом может использоваться для коротко живущих сред (прогон тестов, которые не требуют особенного runtime например).
m> стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
Посмотреть, чтобы иметь мнение, стоит. Завязывать на нее production процессы — это целиться себе в ногу со 100% вероятностью ее очень больно прострелить.
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого? M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы? M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Удобно что-то чужое быстро развернуть, попробовать. Выкладывать на чужие сервера можно, оно должно все типа подхватить.
Из личного опыта — пробовали на одном сервере запускать через докер тесты, чтобы было изолировано. Redis, Postgres и приложение. Из помудохаться — настроить порты, чтобы при новом запуске из приложения было видно redis и postgres, вновь созданные файлы внутри контейнера под рутом на хост машине и прочии танцы с бубнами.
В итоге отказались, оказалось сильно прожорливо и ненадежно (то упадет раз на 20, то пришлось повесить на крон задачу чистить потерянные контейнеры с образами). Решили задачу плагином к Jenkins-у, который стартовал билды на новом инстансе.
При подготовке решения с докерам, рабочую машину (OpenSUSE) перегружал пару раз в день. Часто запускал, останавливал контейнеры, создавал образы и т.п. Впечатления не из приятных, когда зависает намертво настроенная среда работы.
В общем как обычно, пока делаешь мелочи по Getting Started, все ок. Начинаешь городить, то что нужно — получаются сюрпризы.
Ознакомится думаю стоит, чтобы понимать что это такое и как может пригодится.
Здравствуйте, Hobbes, Вы писали:
H>Например, docker-compose позволяет одной командой запустить десяток сервисов, прогнать интеграционные тесты и всё за собой убрать. Это ли не чудо?
Чудо но очень ограничен.
Дальше только скрипты или что-то типа terraform от hashicorp
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого?
Это как виртуалка, только намного дешевле в плане ужирания ресурсов.
Еще один приятный бонус — штуки вроде ACI. Классическую виртуалку, если это винда, поднять быстрее 8 минут со стандартного образа не получается, много времени уходит на конфигурирование. А контейнер в ACI поднимается за несколько секунд. Сопоставь эффективность скейлинга и отсутствие необходимости всяких нейросетевых предсказателей нагрузки.
Здравствуйте, vsb, Вы писали:
vsb>1. Это контейнер, а не виртуальная машина, если окружение завязано на ОС, ничего не получится. Например я работаю с Oracle 9i, который требует RHEL 4 и специальных настроек ядра, докер тут не поможет.
Оракль то зачем в докер пихать? Такие вещи обычно как PaaS делаются, а не как IaaS.
vsb>3. Под венду официальная сборка требует hyper-v, а это Pro, на Home пролетаешь.
Здравствуйте, mizuchi, Вы писали:
M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Плюсы
— Контейнеризация. "Это работает на моей машине" больше не пройдет. Чистая среда безо всякой истории.
— Все особенности конкретного сервера реализуются кем-то и не нужно с этим разбираться. Или повторно разбираться со своим. Реальный reuse.
— Нет явного взаимного влияния сервера на сервер — каждый в своем мире крутится. Каждый сервер в своем контейнере гадит как хочет.
— Упрощение конфигурирования. Контейнер это простой черный ящих и все его особенности внутри. Разделение внешней кофигурации (эземпляры стека приложений) и простой внутренней (мы одни во вселенной).
— Не надо разбираться "А как добавить в автозапуск продукт XYX". Полное единообразие и нет зоопарка разных подходов (upstart & Co — на помоечку)
— Простота развертывания и возможность убрать все обратно подчистую
— Все развертнывание явно, конфигурация и скрипты. В git с историей. А не "Я настраивал год назад, ща вспомню как"
— Сложные сетевые конфигурации. На одном хосте можно отгрохать интересную конструкцию, целый раутер и т.п.
— К сетям, полная гибкость конфигурирования listen points. Не важно, оставили ли создатели возможность "слушать" на выбранных интерфейсах — делаешь извне как себе надо
— Возможность делать изолированные command center console. Не нужно больше — "А сегодня потрать день на настройку своего компьютера". Все из коробки (image). Если пользователь что-то доставил или "разлил", вышел — вошел и вся разлившаяся гадость убралась вместе со старым контейнером. Вместо того чтобы ждать своего веселого часа, "кто поменял эти файлы и не сказал". При этом N человек могут работать в своем контейнере где файлы у каждого свои, но находятся в одном и том же сконфигурированном месте. Типа унифицированного офиса из грузового контейнера.
— Много другого, отбирающего работу админов старой школы
Минусы
— Постоянно все многое меняется. Подход к deployment сильно другой по сравнению с подходом "старой школы"
— Нет четкого заданного порядка старт-стоп с зависимости между контейнерами. Нада явно добавлять.
— Сложность управления ownership/permissions внутри контейнера — надо изгаляться со starup скриптом или через volumes
— Нет смешанных сетевых режимов (например, host/bridge одновременно)
— Монструозные контейнеры, сильная забагованность и чрезвычайная нестабильность под Windows
— В swarm нет хорошей возможности управления persistent data (БД/NoSQL и прочее)
— В стандартном сетевом режиме работает более медленно чем в native network stack. Проблемы с возможностью отключить userland-proxy: hairpin nat и их знаменитый 3-хлетний баг связанный с багами ядра (https://github.com/moby/moby/issues/5618). Кроме производительности с этим еще проблемы много-портовых контейнеров, например Freeswitch/Asterisk с диапазоном UDP портов
— много другогих проблем, дающих работу DevOp-ам новой школы
