Здравствуйте, Ops, Вы писали:
vsb>>По умолчанию нет, запустил — висит, стопнул — не висит. Ops>Это ж каждый раз запускать. Мне удобнее, когда все время работает, даже если в данный момент база не нужна.
Ну так запусти и не останавливай.
vsb>>Порт занимает только если пробросишь, а так у контейнера свой IP. Ops>И сразу о простоте настройки, на которую тут все кивают: как предлагается узнавать этот IP в разрабатываемом софте? Как быть, когда по-умолчанию доступ открыт только с 127.1, что довольно часто используется в продакшне?
В контейнере нет смысла этого делать, так как контейнер сам по себе изолирован. Для взаимного обнаружения сервисов — использовать распределённые registry типа etcd.
Здравствуйте, Cyberax, Вы писали:
C>Для взаимного обнаружения сервисов — использовать распределённые registry типа etcd.
Тут точно разговор об упрощении, а не об усложнении?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, serjjj, Вы писали:
S>Если маппить директорию наружу и запускать в докере все под рутом, то выхлопом в маппированной директории будет владеть рут, что не очень удобно. Приходится протаскивать через переменные окружения uid:gid текущего пользователя, и создавать скриптом нового пользователя в контейнере сразу после запуска. Есть еще варианты?
Для нас не проблема, т.к. если эти файлы нужны какому-то другому приложению, то оно тоже докеризуется и тот же каталог маппится в несколько контейнеров.
Вместо того чтобы искать программы, ставить, настраивать, запускается единообразная среда для SAS контроллера. Со всеми нужными скриптами.
Точно так же, можно сделать контейнер для, например, деплоймента.
Внутри все пути настроены. Все настройки, все нужные пакеты, библиотеки. Праильный command prompt, с показом git-branch или текущей docker машины.
Чтобы обновить не нужно всем рассылать "запустите XYZ" или добавьте путь в path. Обновляется image и все. Одна кнопка и мы в полностью настроенном окружении. Можно и на shared deployment PC. Пути все одинаковые, но в разных персональных контейнерах.
Никакого пользовательского мусора не залеживается и не ведет к ошибкам вида "А у меня все работает"
Здравствуйте, 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>может, хайп быстро пройдёт и снова начнётся поиск новой серебрянной пули?
