Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого? M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы? M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Докер — это явление, по масштабам не уступающее гиту, только в сисадминстве.
Основной его бонус — инкапсуляция и сетевое хранилище образов.
К любому крупному приложению обычно прилагается документ с n (n >= 10) пунктов, которые надо выполнить перед тем, как попытаться это приложение запустить. Докер заменяет всё это безобразие однострочником.
Раньше приложения зиповали и заливали в Nexus — сейчас их собирают и заливают в докер. Разница в том, что зип надо как-то распаковать, настроить, дотащить зависимости (ту же java в простейшем случае) — в образе докера всё это уже есть, причем с дедупликацией.
Раньше запуск приложения 1-2-3 летней давности был очень нетривиальной задачей — с докером шанс успеха очень высок, т.к. все зависимости и системные библиотеки упакованы внутри образа.
Раньше для приложений делали всякие-разные лаунчеры, прописывали их в init.d, извращались как могли, чтобы они автоматически перезапускались при краше или рестарте сервера. Докер делает это лучше, сам и без внесения изменений в настройки хоста.
Немного советов от опытного пользователя докера)
— только Linux. Желающие заниматься разработкой серверного ПО под другими осями — страдают или не используют докер
— --net=host — единственный правильный вариант, маппинг портов и всё это докеровское безобразие с сетевыми драйверами — не нужно
— приложение должно настраиваться через переменные окружения (env variables) и, в тяжелых случаях, файлами
— приложение должно внятно писать, какие переменные окружения ему нужны, какие забыли указать, и какие вообще оно понимает
— в приличном приложении все слушающие порты должны настраиваться (см. пункт про --net=host)
— volumes ненужная фигня — лучше просто маппить каталоги наружу. Мы делаем -v /data:/data/$image_name
— приложение должно само редиректить stdout в файл — доверять стандартному docker logging driver нельзя — он кривой
— docker compose и т.п. фигня — на одной машине проще на баше примитивный скрипт родить, а в кластере все равно kubernetes/consul/велосипед
— не нужно извращаться с юзерами под докером — в контейнере можно запускать всё из-под рута. Все равно из контейнера ему не деться, про дыры в безопасности "изнутри" я не слышал, а при желании kernel capabilities можно еще сильнее урезать.
Здравствуйте, Ops, Вы писали:
Ops>А что за вопросы и ошибки? Она ж элементарная в установке, попробуй как нибудь, все искаропки работает и каши не просит.
Ошибки:
— "А я взял ту версию что у меня была на диске". Ага, и 2 месяца с не той версией
— "А у меня уже давно стоит" — старая версия со старыми данными
— "Не ставится, чего-то. Про порт пишет, что-то"
— "Ой, не могу, моя БД привязана к другому проекту XYZ"
— "Что-то ставится, но не работает. Наверное какие-то старые конфиги остались. Я давно собирался почистить, но..."
— "Что-то у меня с конкретной openssl эта версия не идет, а обновить я не могу"
Все вроде элементарно и каши не просит. Только вот, один скрипт или N элементарных действий: нашел, скачал, поставил настроил. поставил-настроил, поставил-настроил.
И ты можешь гарантировать что все файлы до последнего будут деинсталлированы? А если это не простгрес? А что если какой-то дополнительно файл поменялся, а? А если 50 раз поменялся? Ах да, он теперь отличается от package maintainer version... Плюс в кратковременную или долговременную память. А стоит ли это того, если git для таких вещей подходит больше.
В общем, "каши не проосит", это веьма далеко от истины.
А про ssl я не просто так написал. Тот же nginx для http2 требует новую версию openssl. Которую на 14.04 просто так не поставишь без мук. А обновить, когда там столько уже вручную поставили всего того что каши не просит.... нее, невозможно, сейчас это никак нельзя.
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего?
изолированная среда, которую при желании можно соединить с чем-то ещё
меньше проблем с правами
M>и что плохого?
хреновый дизайн команд управления
нестабильность
проблемы с безопасностью
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы? M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
изучить стоит. контейнеры будут развиваться.
надеюсь только, что иным образом.
Здравствуйте, MTD, Вы писали:
TK>>Кошмар какой. Это как кухня совмещённая с сортиром MTD>А можно конструктивней? Мне действительно интересно, что не понравилось и что ты предложил бы в качестве альтернативы.
В одном контейнере и сборка и использование. Можно сборку делать в промежуточном контейнере — зачем все в один складывать?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, 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-ам новой школы
Здравствуйте, MTD, Вы писали:
MTD>А что хорошего и плохого в виртуальных машинах? Может википедию сначала почитать? Лично мне докер очень нравится — позволяет очень просто и быстро развернуть нужное окружение.
зачем докер, если уже есть виртуальные машины?.. чем он лучше?
Вместо того чтобы искать программы, ставить, настраивать, запускается единообразная среда для SAS контроллера. Со всеми нужными скриптами.
Точно так же, можно сделать контейнер для, например, деплоймента.
Внутри все пути настроены. Все настройки, все нужные пакеты, библиотеки. Праильный command prompt, с показом git-branch или текущей docker машины.
Чтобы обновить не нужно всем рассылать "запустите XYZ" или добавьте путь в path. Обновляется image и все. Одна кнопка и мы в полностью настроенном окружении. Можно и на shared deployment PC. Пути все одинаковые, но в разных персональных контейнерах.
Никакого пользовательского мусора не залеживается и не ведет к ошибкам вида "А у меня все работает"
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего?
Одной командой можно развернуть нетривиальное окружение на любой ОС. Можно очень быстро запускать много экземпляров чего-нибудь, восстанавливать окружение и тд. Например я думаю заюзать докер для БД-тестов: заранее готовится образ с БД и нужными таблицами, перед каждым тестом запускается отдельный инстанс БД, после теста выбрасывается.
M>и что плохого?
1. Это контейнер, а не виртуальная машина, если окружение завязано на ОС, ничего не получится. Например я работаю с Oracle 9i, который требует RHEL 4 и специальных настроек ядра, докер тут не поможет.
2. Не раз слышал про проблемы с производительностью. Для разработки, конечно, пофиг, для продакшна надо тестить.
3. Под венду официальная сборка требует hyper-v, а это Pro, на Home пролетаешь. Вроде есть какие-то старые сборки с виртуалбоксом, наверное придумать можно что-нибудь, но всё равно неприятно.
4. Все эти образы жрут сотни мегабайтов, а то и гигабайты. Ставить убунту на 300 мегабайтов ради постгреса в 3 мегабайта иногда кажется странным.
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы? M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Хз, чего там изучать, там всё тривиально, за 10 минут можно разобраться. Какие там митапы.
Здравствуйте, 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, все ок. Начинаешь городить, то что нужно — получаются сюрпризы.
Ознакомится думаю стоит, чтобы понимать что это такое и как может пригодится.
Здравствуйте, turbocode, Вы писали:
НС>>Это как виртуалка, только намного дешевле в плане ужирания ресурсов. T>За счет чего? Винда в докере будет работать быстрее?
Винда в докере (native containers) жрет меньше ресурсов, используется "облечгенное" ядро ОС, которое вызовы направляет софтовой прослойке.
В *nix контейнеры не жрут вообще (почти), ибо вся "виртуализация" заключается в ограничении user-space ресурсов доступных программе.
Здравствуйте, Kolesiki, Вы писали:
K>Да он и так проходит как бы боком. K>Если ты — ответственный программист, все взаимосвязи твоего ПО должны быть прозрачны, легко настраиваемы и устанавливаться без запинок по списку из 3 пунктов, один из которых — "разархивировать ПО в папку", а другой — "Profit!".
Разархивировать и все? И сразу сеть сконфигрурирована, ОС настроена, пакеты установлены, права розданы. Чудесный архиватор однако.
Здравствуйте, Anton Batenev, Вы писали:
AB>Посмотреть, чтобы иметь мнение, стоит. Завязывать на нее production процессы — это целиться себе в ногу со 100% вероятностью ее очень больно прострелить.
У многих, и у нас в том числе docker в продакнеш ( aws ecs ), До него работали "классически". разница небо и земля в пользу докера.
Стабильность, надежность и скорость деплоя и скейла повысилась в разы
Здравствуйте, Vetal_ca, Вы писали:
V_>А там, "Ты у нас с докером, к сожалению, один. Подгонишь коллег, будет больше... все ищем".
как отличить нормальную технологию от маркетингового шлака
V_>Разные сценарии, разные компании, докер очень хорошо работает. Тоже, много и всерьез. Но не для тех, кто "Да что там разбираться, 30 минут ...."
я чего не понимаю: если везде новички, с чего вдруг везде "очень хорошо работает"? может, это всё-таки детский хайп?
Здравствуйте, neFormal, Вы писали:
V_>>А там, "Ты у нас с докером, к сожалению, один. Подгонишь коллег, будет больше... все ищем".
F>как отличить нормальную технологию от маркетингового шлака
Она работает. Чем идеальная правильная но не созданная.
F>я чего не понимаю: если везде новички, с чего вдруг везде "очень хорошо работает"? может, это всё-таки детский хайп?
Есть и не новички но все плотно работают наверняка и на свободном рынке неваляются.
что в нём хорошего? и что плохого?
стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого?
А что хорошего и плохого в виртуальных машинах? Может википедию сначала почитать? Лично мне докер очень нравится — позволяет очень просто и быстро развернуть нужное окружение.
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
Тебе видней. Изучается он на базовом уровне за пол дня.
M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Является ли лопата серебрянной пулей? А молоток? Детские какие-то вопросы.
Здравствуйте, 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
Здравствуйте, 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>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Докер уже вышел на плато продуктивностию
НО довольно слабое применение докера в энтерпрайзах, так как корпоративный софт очень любит использовать ресурсы ОС, недоступные в среде docker.
Здравствуйте, Ночной Смотрящий, Вы писали:
vsb>>3. Под венду официальная сборка требует hyper-v, а это Pro, на Home пролетаешь.
НС>Зачем докер на персоналках?
Для разработки, наверное.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ночной Смотрящий, Вы писали:
vsb>>1. Это контейнер, а не виртуальная машина, если окружение завязано на ОС, ничего не получится. Например я работаю с Oracle 9i, который требует RHEL 4 и специальных настроек ядра, докер тут не поможет.
НС>Оракль то зачем в докер пихать? Такие вещи обычно как PaaS делаются, а не как IaaS.
Чтобы разработчик мог легко развернуть локальную базу и начать работать. С постгресом, например, проблем нет и это мегаудобно.
vsb>>3. Под венду официальная сборка требует hyper-v, а это Pro, на Home пролетаешь.
НС>Зачем докер на персоналках?
Чтобы разрабатывать софт. Мне, например, не нужна ни одна фича от Pro, кроме вот этого вот hyper-v, да и он не нужен сам по себе, но раз докер требует — пришлось купить. А он между прочим стоит в полтора раза дороже.
Здравствуйте, Vetal_ca, Вы писали:
V_>- Возможность делать изолированные command center console. Не нужно больше — "А сегодня потрать день на настройку своего компьютера". Все из коробки (image). Если пользователь что-то доставил или "разлил", вышел — вошел и вся разлившаяся гадость убралась вместе со старым контейнером. Вместо того чтобы ждать своего веселого часа, "кто поменял эти файлы и не сказал". При этом N человек могут работать в своем контейнере где файлы у каждого свои, но находятся в одном и том же сконфигурированном месте. Типа унифицированного офиса из грузового контейнера.
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого?
Хорошего — то, что легко можно установить сложный комплекс ПО — когда есть куча зависимостей, древних либ, невнятные взаимосвязи, ручные конфиги и т.п. Грубо говоря, "большая помойка".
Плохо — то, что если проектом должен заняться второй программист , он попросту не сможет восстановить правильно рабочую среду — ведь для этого надо разобраться в "куча зависимостей, древних либ" и т.д.
M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы?
Только в плане эрудиции.
M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
Да он и так проходит как бы боком.
Если ты — ответственный программист, все взаимосвязи твоего ПО должны быть прозрачны, легко настраиваемы и устанавливаться без запинок по списку из 3 пунктов, один из которых — "разархивировать ПО в папку", а другой — "Profit!".
Здравствуйте, Hobbes, Вы писали:
H>Например, docker-compose позволяет одной командой запустить десяток сервисов, прогнать интеграционные тесты и всё за собой убрать. Это ли не чудо?
Нет, это просто автоматизация того, что уже было до докера.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Классическую виртуалку, если это винда, поднять быстрее 8 минут со стандартного образа не получается, много времени уходит на конфигурирование.
Классически это занимает пару секунд на клонирование готовой VM и задание ей новой instance конфигурации.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vsb, Вы писали:
vsb>Чтобы разработчик мог легко развернуть локальную базу и начать работать. С постгресом, например, проблем нет и это мегаудобно.
С ним и при обычной установке проблем нет, непонятно, зачем его в контейнер совать.
vsb>Чтобы разрабатывать софт. Мне, например, не нужна ни одна фича от Pro, кроме вот этого вот hyper-v, да и он не нужен сам по себе, но раз докер требует — пришлось купить. А он между прочим стоит в полтора раза дороже.
Да отлично он без hyper-v запускается, просто используй "старую" версию. hyper-v вообще не самая удобная технология, с ней у тебя хостовая система сама работает под гипервизором, и не отключая (с обязательным ребутом) нельзя запустить другую виртуалку, кроме как в режиме программной эмуляции.
Зато среди фич Pro — нормальная настройка обновлений, что куда важнее. Или сейчас домашняя уже сама не ребутается?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>С ним и при обычной установке проблем нет, непонятно, зачем его в контейнер совать.
N разработчиков ставят его вне контейнера и задают вопросы и делают ошибки, сказывающиеся теперь и в процессе всей разраотки. Отвлекаясь от своей основной работы.
Или они работают с одним image, запуская один проверенный скрипт, сделанный ответственным за это дело человеком. Которому не надо разбираться с тем, что творится на машине разработчика N
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>Классическую виртуалку, если это винда, поднять быстрее 8 минут со стандартного образа не получается, много времени уходит на конфигурирование. CC>Классически это занимает пару секунд на клонирование готовой VM и задание ей новой instance конфигурации.
где то есть общедоступное registry таких виртуалок?
нет? — тогда минимум один раз надо один фиг настроить. потом поддерживать весь этот сброд образов
видел я у тестеров этот зоопарк образов. этож блин е"№&%й п"#№%ц.
к тому же историю менеджить сложно, удалил все случайно — и привет.
Dockerfile's отлично храняться в git со всеми вытекающими
Здравствуйте, CreatorCray, Вы писали:
CC>Классически это занимает пару секунд на клонирование готовой VM и задание ей новой instance конфигурации.
Я видел документацию по созданию VM. Кроме всей этой геморности с кликни здесь, запусти там, нужно это все дело кофигурировать.
А Docker image это файлец, прямо из git. Легко поддающийся git diff, видный и понятный насквозь.
Можно легко развернуть программу из git до облака. Легко, по-настоящему а не в стиле "я могу написать на RSDN что могу".
Разница колоссальна. Например для меня интересно автоматизировать это дело с докером. Четкие унифицированные блоки. Явная конфигурация, разделение.
Без этого я просто не стал бы это делать, оставив более нудное занятие менее занятому товарищу. Мог бы, но просто не хочу.
Здравствуйте, Vetal_ca, Вы писали:
V_>N разработчиков ставят его вне контейнера и задают вопросы и делают ошибки, сказывающиеся теперь и в процессе всей разраотки. Отвлекаясь от своей основной работы.
А что за вопросы и ошибки? Она ж элементарная в установке, попробуй как нибудь, все искаропки работает и каши не просит.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, mogadanez, Вы писали:
M>где то есть общедоступное registry таких виртуалок?
Тебе для того чтоб докерить винду на линухе один фиг надо где то с ней виртуалку взять.
Или докерить на одной винде другую.
Проблемы те же.
M>видел я у тестеров этот зоопарк образов. этож блин е"№&%й п"#№%ц.
С кривыми руками и не такое бывает.
M>к тому же историю менеджить сложно, удалил все случайно — и привет.
Офигенный аргумент. Подходит к чему угодно.
Я не против докера, просто это не серебряная пуля и подходит не для всех сценариев.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Vetal_ca, Вы писали:
CC>>Классически это занимает пару секунд на клонирование готовой VM и задание ей новой instance конфигурации. V_>Я видел документацию по созданию VM. Кроме всей этой геморности с кликни здесь, запусти там, нужно это все дело кофигурировать.
Создание ВМ мало чем отличается от обычной установки.
V_>А Docker image это файлец, прямо из git. Легко поддающийся git diff, видный и понятный насквозь. V_>Можно легко развернуть программу из git до облака. Легко, по-настоящему а не в стиле "я могу написать на RSDN что могу".
Сколько софта ты разворачивал в ВМ и сколько в докере?
Потому что я с ВМ работал много и всерьёз. И команда по поддержке докера у нас тоже был тим, который регуларно на докерские ограничения жаловался.
Докер хорошо работает для простых сценариев, если надо что нить посложнее то файлецом из гита не обойдёшься.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
M>>где то есть общедоступное registry таких виртуалок? CC>Тебе для того чтоб докерить винду на линухе один фиг надо где то с ней виртуалку взять. CC>Или докерить на одной винде другую. CC>Проблемы те же.
про винду разговор отдельный имо
я бы даже сказал в топку винду =)
докером пользовался много но желания/необходимости поднять там винду ни разу не было
в принципе докер даже на маке говно.
Он для того чтобы в линухе поднять линух
Здравствуйте, mogadanez, Вы писали:
M>про винду разговор отдельный имо M>я бы даже сказал в топку винду =) M>в принципе докер даже на маке говно. M>Он для того чтобы в линухе поднять линух
Т.е. очень сильно нишевый.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Сколько софта ты разворачивал в ВМ и сколько в докере?
в линухе — практически любой
CC>Потому что я с ВМ работал много и всерьёз. И команда по поддержке докера у нас тоже был тим, который регуларно на докерские ограничения жаловался. CC>Докер хорошо работает для простых сценариев, если надо что нить посложнее то файлецом из гита не обойдёшься.
не очень пониманию о каких сложных случаях идет речь, все что можно сконфигурировать с команд лайна — можно в докере
если получается большой файл — выделяем базовые имеджи.
может архитектура не очень просто? разбить на куски, сделать микросервисы ....
CC>Создание ВМ мало чем отличается от обычной установки.
Гораздо геморнее
CC>Сколько софта ты разворачивал в ВМ и сколько в докере? CC>Потому что я с ВМ работал много и всерьёз. И команда по поддержке докера у нас тоже был тим, который регуларно на докерские ограничения жаловался. CC>Докер хорошо работает для простых сценариев, если надо что нить посложнее то файлецом из гита не обойдёшься.
Файлецы это cкриптцы разного объема и сложности. И да, обойдешься, чем сложнее тем геморнее VM-ный подход ибо растет его история и накопившаяся энтропия. И сопровождаемая документация "Как построить эту VM" все больше отходит от рабочего состояния. Да, и docker images тоже надо периодически менять. Скажем так, VM-ный подход мне не нравится т.к. работать нужно играючи и в удовольствие. Перелопачивать VM — ищите согласного специалиста, bye-bye.
С тимами проблема, да, жалуются. Нет людей, которые знают: Я в надежде за новым опытом и для корректировки курса пошел в компанию где должны быть, чтобы поделиться и набраться чужого опыта. Изменив привычный курс на мелкие стартапы. А там, "Ты у нас с докером, к сожалению, один. Подгонишь коллег, будет больше... все ищем". В общем сильных коллег с докером не встречал, на митапы одни новички ходят и их для рекрутмента больше делают.
Разные сценарии, разные компании, докер очень хорошо работает. Тоже, много и всерьез. Но не для тех, кто "Да что там разбираться, 30 минут ...."
Здравствуйте, Ops, Вы писали:
vsb>>Чтобы разработчик мог легко развернуть локальную базу и начать работать. С постгресом, например, проблем нет и это мегаудобно.
Ops>С ним и при обычной установке проблем нет
Проблем куча. Надо найти дистрибутив, возможно нужной версии, скачать его, установить, правильно настроить авторизацию, накатить скрипты. Как думаешь, за сколько времени справится человек, который это никогда не делал? Я думаю, несколько часов, как минимум. Кроме того установленный постгрес это уже установленный софт у тебя на компе, который прописывается в сервисы, висит в памяти, занимает порт, про это всё надо помнить. Я очень не люблю устанавливать любую программу, которая делает что-то большее, нежели читает/пишет со своего каталога. Докер-образ гораздо более эфемерен.
> непонятно, зачем его в контейнер совать.
А с правильно настроенным образом это пара команд. Ну сам докер, конечно, надо установить до этого. Но он один, а зависимостей много.
vsb>>Чтобы разрабатывать софт. Мне, например, не нужна ни одна фича от Pro, кроме вот этого вот hyper-v, да и он не нужен сам по себе, но раз докер требует — пришлось купить. А он между прочим стоит в полтора раза дороже.
Ops>Да отлично он без hyper-v запускается, просто используй "старую" версию.
Ну это так себе вариант. А если мне нужна фича новой версии?
Ops>hyper-v вообще не самая удобная технология, с ней у тебя хостовая система сама работает под гипервизором, и не отключая (с обязательным ребутом) нельзя запустить другую виртуалку, кроме как в режиме программной эмуляции.
Ну это если тебе нужны другие виртуалки. А зачем они нужны, если есть hyper-v?
Ops>Зато среди фич Pro — нормальная настройка обновлений, что куда важнее. Или сейчас домашняя уже сама не ребутается?
Не знаю, это как раз мне не важно, никогда не испытывал проблем с обновлениями. Если и ребутнется раз в год, ничего страшного не вижу. Я предполагаю, что она ребутается у тех, кто месяцами откладывает обновления, может быть ошибаюсь.
Здравствуйте, TK, Вы писали:
TK>>>Кошмар какой. Это как кухня совмещённая с сортиром
Понятно, еще один фундаменталист — поставить разработчика раком ради каноничности.
TK>В одном контейнере и сборка и использование. Можно сборку делать в промежуточном контейнере — зачем все в один складывать?
Это просто и удобно, а ты можешь сказать ради каких преимуществ делать сборку в промежуточном контейнере?
Здравствуйте, vsb, Вы писали:
vsb>Проблем куча. Надо найти дистрибутив, возможно нужной версии, скачать его, установить, правильно настроить авторизацию, накатить скрипты. Как думаешь, за сколько времени справится человек, который это никогда не делал? Я думаю, несколько часов, как минимум. Кроме того установленный постгрес это уже установленный софт у тебя на компе, который прописывается в сервисы, висит в памяти, занимает порт, про это всё надо помнить. Я очень не люблю устанавливать любую программу, которая делает что-то большее, нежели читает/пишет со своего каталога. Докер-образ гораздо более эфемерен.
Че-то я не понял, а в докере это не висит в памяти (плюс виртуалка, все это обеспечивающая) и не занимает порт?
vsb>Ну это так себе вариант. А если мне нужна фича новой версии?
Так она ж обновляется, я не зря "старую" в кавычках написал.
vsb>Ну это если тебе нужны другие виртуалки. А зачем они нужны, если есть hyper-v?
Например, у HV довольно посредственная поддержка гуя для не-винды.
vsb>Не знаю, это как раз мне не важно, никогда не испытывал проблем с обновлениями. Если и ребутнется раз в год, ничего страшного не вижу. Я предполагаю, что она ребутается у тех, кто месяцами откладывает обновления, может быть ошибаюсь.
Вроде домашняя может просто без спроса ребутнуться, утром подходишь к компу, а он обновленный. Во всяком случае, именно на это многие после выхода 10-ки ругались.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Че-то я не понял, а в докере это не висит в памяти (плюс виртуалка, все это обеспечивающая) и не занимает порт?
По умолчанию нет, запустил — висит, стопнул — не висит. Порт занимает только если пробросишь, а так у контейнера свой IP.
vsb>>Ну это так себе вариант. А если мне нужна фича новой версии?
Ops>Так она ж обновляется, я не зря "старую" в кавычках написал.
Ну тогда ладно, если разницы особой нет.
vsb>>Не знаю, это как раз мне не важно, никогда не испытывал проблем с обновлениями. Если и ребутнется раз в год, ничего страшного не вижу. Я предполагаю, что она ребутается у тех, кто месяцами откладывает обновления, может быть ошибаюсь.
Ops>Вроде домашняя может просто без спроса ребутнуться, утром подходишь к компу, а он обновленный. Во всяком случае, именно на это многие после выхода 10-ки ругались.
Я не оставляю компьютер включённым, ребут ещё ладно, а если свет моргнёт. Не существенная проблема на мой взгляд. Вот если посреди презентации ребутнется, да ещё и с 15-минутной установкой обновлений, это будет действительно неприятно.
Здравствуйте, vsb, Вы писали:
vsb>По умолчанию нет, запустил — висит, стопнул — не висит.
Это ж каждый раз запускать. Мне удобнее, когда все время работает, даже если в данный момент база не нужна.
vsb>Порт занимает только если пробросишь, а так у контейнера свой IP.
И сразу о простоте настройки, на которую тут все кивают: как предлагается узнавать этот IP в разрабатываемом софте? Как быть, когда по-умолчанию доступ открыт только с 127.1, что довольно часто используется в продакшне?
vsb>Я не оставляю компьютер включённым, ребут ещё ладно, а если свет моргнёт. Не существенная проблема на мой взгляд. Вот если посреди презентации ребутнется, да ещё и с 15-минутной установкой обновлений, это будет действительно неприятно.
Посреди презентации как раз не проблема, просто надо обновить заранее, до ее начала. А вообще, использование домашней винды на устройстве, критически важном для бизнеса — странно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, scf, Вы писали:
scf>- Мы делаем -v /data:/data/$image_name scf>- не нужно извращаться с юзерами под докером — в контейнере можно запускать всё из-под рута. Все равно из контейнера ему не деться, про дыры в безопасности "изнутри" я не слышал, а при желании kernel capabilities можно еще сильнее урезать.
Если маппить директорию наружу и запускать в докере все под рутом, то выхлопом в маппированной директории будет владеть рут, что не очень удобно. Приходится протаскивать через переменные окружения uid:gid текущего пользователя, и создавать скриптом нового пользователя в контейнере сразу после запуска. Есть еще варианты?
Здравствуйте, neFormal, Вы писали:
F>и ловить падения контейнеров на большом траффике...
Ой-ой-ой, попугаем *большим* траффиком.
Легко крошится на траффик поменьше. Load balancer и/или round robin DNS на вход. А дальше share nothing кластер и большой траффик крошится на на маленький.
Если это, конечно, не монолитный копролит, который из тьмы веков от косервативных программеров, который принципиально не разделим.
Это если контейнеры принципиально падают, хотя у меня таких проблем не наблюдалось если сам процесс, pid 1, внутри не падает.
Здравствуйте, serjjj, Вы писали:
S>Если маппить директорию наружу и запускать в докере все под рутом, то выхлопом в маппированной директории будет владеть рут, что не очень удобно. Приходится протаскивать через переменные окружения uid:gid текущего пользователя, и создавать скриптом нового пользователя в контейнере сразу после запуска. Есть еще варианты?
Держать Volumes внутри. Как раз таки глобальные порты и mappings очень неприятная штука...
Данные копировать в контайнер и из контайнера операции копирования. Это работает и работает очень хорошо, особенно в более сложных случаях — remote docker machine, docker in docker и т.п.
Пользователя можно задать в image. В новой docker engine добавили возможность задать UID:GID для ADD/COPY в Dockerfile
Здравствуйте, Ops, Вы писали:
vsb>>По умолчанию нет, запустил — висит, стопнул — не висит. Ops>Это ж каждый раз запускать. Мне удобнее, когда все время работает, даже если в данный момент база не нужна.
Ну так запусти и не останавливай.
vsb>>Порт занимает только если пробросишь, а так у контейнера свой IP. Ops>И сразу о простоте настройки, на которую тут все кивают: как предлагается узнавать этот IP в разрабатываемом софте? Как быть, когда по-умолчанию доступ открыт только с 127.1, что довольно часто используется в продакшне?
В контейнере нет смысла этого делать, так как контейнер сам по себе изолирован. Для взаимного обнаружения сервисов — использовать распределённые registry типа etcd.
Здравствуйте, Cyberax, Вы писали:
C>Для взаимного обнаружения сервисов — использовать распределённые registry типа etcd.
Тут точно разговор об упрощении, а не об усложнении?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, serjjj, Вы писали:
S>Если маппить директорию наружу и запускать в докере все под рутом, то выхлопом в маппированной директории будет владеть рут, что не очень удобно. Приходится протаскивать через переменные окружения uid:gid текущего пользователя, и создавать скриптом нового пользователя в контейнере сразу после запуска. Есть еще варианты?
Для нас не проблема, т.к. если эти файлы нужны какому-то другому приложению, то оно тоже докеризуется и тот же каталог маппится в несколько контейнеров.
Здравствуйте, Vetal_ca, Вы писали:
V_>Я видел документацию по созданию VM. Кроме всей этой геморности с кликни здесь, запусти там, нужно это все дело кофигурировать.
Ой, пойду ансиблы переписывать, а то оказывается надо мышкой куда то кликать...
Здравствуйте, vsb, Вы писали:
vsb>У виртуальных машин больше расходов. Ядро грузится секунды, жрёт мегабайтов 10 оперативной памяти как минимум. У контейнеров этих расходов нет. Ну и самое главное, докер это экосистема. Я одной командой могу wordpress установить, другой postgres с redis поднять, а с виртуалками надо тратить время.
Полагаю, настоящая причина только первая. А на счёт "экосистемы" — при желании это можно было б сделать и "по-старому", дело только в том, что при таких накладных расходах (именно на полный environment для отдельной ОСи) это нафиг никому не нужно. Даже бесплатный VirtualBox умеет делать snapshot'ы (чем не образ?), а платные вещи (не знаток, ибо мне не доводилось работать там, где лицензия на полноценное VM-окружение хоть от того ж VMWare бала б рентабельной) быть может умеют и больше. Точнее не быть может, а наверняка, иначе как эти "облачные серверы" предоставляют всё то, что они предоставляют. Даже то, что сообщением ниже — вроде б причина, но многие ОСи могут устанавливаться по текстовой конфигурации, так что небольшая надстройка о том, куда их в VM ставить — и можно было сделать аналог для VM. Причина, полагаю, лишь в том, что почти никто не будет этим пользоваться, ибо в случае отдельного VM для каждого VC site'а 99% вычислительных ресурсов уйдут на guest OS, то есть непроизводительно.
Здравствуйте, mizuchi, Вы писали:
M>что в нём хорошего? и что плохого? M>стоит ли эта абстракция того, чтобы её узучать и даже иногда ходить на всякие meetup'ы? M>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
