• DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    а что за инструмент? Если это не коммерческая тайна конечно
    Так там же написано выше: lithos
  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    О еще забыл сказать что vagga-box умеет по nfs расшаривать файловую систему контейнеров. Так что ты можешь посмотреть содержимое контейнера, и добавить его в свой IDE. (Ну и даже поредактировать в экстренных случаях).

    В linux’е это тоже работает если что (и без nfs).

  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Тогда она [называлась Fig](github.com/...er/compose/commit/2af7693) не была «под крылом» у Docker’а, и в целом не понятно было взлетит оно или нет (если лень открывать ссылку, Fig стал compose’ом 12 января 2015, а анонсирован compose был на пару месяцев раньше, если мне не изменяет память)

    Я нашёл Fig уже после того как начал писать vagga (хотя и сильно раньше чем она стала называться docker-compose). И впринципе он сильно отличался (и до сих пор отличается) от того что мне удобно, по-этому делать что-то поверх не представлялось чем-то полезным.

    Поддержал: Sviatoslav Sydorenko
  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Да есть vagga-docker, но docker for mac пока очень глючный. Главный глюк обещали починить прям сегодня и выкатить в beta27. Может будет лучше. + там медленная файловая система которая смотрит в хост.

    Сейчас более юзабельная обёртка вокруг virtualbox.

    Обе существуют в виде прототипа, но у нас в компании многие маководы пользуют (сейчас в основном vagga-box). Скорее всего одна из этих обёрток интегрируется непосредственно в код vagga.

  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Ну в данном случае, я удивлён, тому что этих инструментов так мало, а не тому что есть чуть-чуть конкуренции :)

    Но Ваш комментарий был бы интереснее, если бы Вы привели аргументы почему Вам кажется что rocker будет популярный. Какие-то примеры как задачи решаются и там и там, и объясили бы почему какой-то из способов лучше.

    Поддержали: Vitaly Romas, Sviatoslav Sydorenko
  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Зачем вообще билдить контейнеры на машине у девелопера? Обычно этим занимается CI, который уже и пушит в registry/hub.

    Так и есть, я имею ввиду с vagga’ой то же. Но дьявол как всегда в деталях:

    1. Когда вы что-то поправляете в зависимостях сами, или делаете merge локально, вам нужно чтобы контейнер был правильный
    2. Опять же, как узнать когда делать docker pull после git pull ?
    3. Каким тегом помечать имидж? (понятно же почему latest плохо?)

    Ну и еще я комментировал немножно тут

  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Ну, в нас таких проблем немає.
    А можно подробнее? Просто интересно. У вас у всех разработчиков один дистрибутив линукса? Нет Mac OS? Нет старых версий дистрибутива? Или всё в виртуалках?
    Мені ідея підсвічує що пакетів немає :)

    Вот это важное заблуждение. Вот взял Bob обновил пакет pysay==1.2.1 в пакет pysay=1.2.3. Обновление пакета чинит баг. А потом вот Alice делает себе git pull запускает проект, и видит что баг есть. Её действия? Чаще всего она либо создает/возвращает баг в багтрекере, или отвлекает Bob’а чтобы он посмотрел почему на её машине баг не воспроизводится.

    Але сама по собі python-розробка коли є оверхед на конфліктуючі версії натівних ліб це оверхед :)

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

    Опять же проблема не в конфликтах версий в проекте, проблема в том, что у каждого разработчика своё понимание ОС на которой ему комфортно работать. У кого-то это до сих пор Ubuntu 14.04, у кого-то Ubuntu 16.10. В компании есть еще ArchLinux, NixOS, и отдельным особняком стоит OS X которой мы тоже стараемся сделать практически seamless поддержку. И вот собственно версии libpg или libxml у всех этих дистрибутивов разные.

  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Ну честный ответ такой: когда мы сделали vagga docker-compose еще и в планах не было. С тех пор я не пробовал docker-compose.

    Было бы хорошо если бы кто-то, кто часто использует docker-compose попробовал vagga и отписался какая в этом разница. Ну или я бы позадавал вопросы человеку кто пользуется docker-compose регулярно, здесь в комментариях, потому в каких-то штуках про него я могу ошибиться.

    Из того что навскидку: вот есть у вас проект с тестами и документацией. Что должен запускать docker-compose up, проект же, верно? Как запустить тесты? Как собрать документацию? Это отдельные docker-compose файлы? Но как минимум контейнеры для тестов зависят от основных контейнеров, верно? Как это записать в docker-compose?

    Еще вопрос, нужно ли запускать docker-compose build после каждого git pull?

    И еще в vagga есть много фичей из rocker’а.

  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Да, конечно. У нас есть некоторые удобства для python, node.js, ruby, php, пакетов ubuntu и alpine. Но в целом всё что вы можете установить командами shell’а также работает. Если нужно версионировать дополнительные файлы есть тег !Depends filename. (Суть поддержки языков программирования сводится к тому что мы умеем версионировать package.json и requirements.txt не как текст, а немножно более умно, и автоматически конфигурим папки для кеша).

    Поддержал: Oleksandr Olgashko
  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    По умолчанию оно как docker --net=host. Т.е. вся сеть что работает в хостовой системе работает в vagga нормально. Только управлять сетевыми интерфейсами нельзя из-за прав.

    С другой стороны не понятно зачем вам ucarp на рабочей станции или CI. Запускать vagga в production’е крайне не рекомендуется.

  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Ну с java’ой и правда может быть чуть легче, хотя вот еще саму java’у нужно установить, и она тоже в разных дистрибутивах разная.

    Проблема pip install requirements в том, что там еще есть нативные библиотеки очень часто, и это пакеты, и они для ubuntu и archlinux (например) разные. А еще там обычно nodejs/npm (ну чтобы javascript/css/картинки собрать), и у неё тоже бывают бинарные зависимости.

    А еще как узнать нужно ли запускать pip install requirements.txt после git pull ?

  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Ну, я не сомневаюсь, что многие так живут, и привыкли не замечать проблем. Но если Вы хотите это обсудить, покажите как выглядит инструкция для запуска проекта для нового пользователя? (ну или если нельзя показать, скажите сколько там строк и в чём она состоит в общем)

  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Ну конечно можно сделать. Но при добавлении команды, нужно не забыть её вписать еще и в help и в .PHONY. В vagga это в одном месте. И команда есть в списке даже если описание забыли. Но описание есть в большинстве соседних команд, по-этому, вроде, обычно пишут. Конечто же только ради этого я бы не менял make на самописный инструмент, но это тоже важно.

  • DOU Labs: как в EVO разработали Vagga и контейнеризировали всё

    Lithos для контейнеров, verwalter для оркестрации.

    vagga для продакшина собирает контейнер и «придумывает» версию. vagga только локально и в CI (gitlab). На проде сборка контейнеров, версионирование, и т.д. не нужны, по-этому там другой инструмент, более простой и более надёжный.