точнее удобнее вагранта

ты знаешь все начальные условия? я нет. сейчас есть виртуалка для разработки. но нет действий для воспроизведения среды.

ты знаешь все начальные условия? я нет. сейчас есть виртуалка для разработки. но нет действий для воспроизведения среды.

если нет действий для воспроизведения среды - то как бы уже ты проигрываешь.

а если бы были - запихнуть в docker не проблема

с тем же vagrant

он бы просто запровиженил контейнер

В данном случае у меня нативная FS будет. Плюс контейнер с тем же апачем.

апачем?

1. вагрант с nfs медленнее чем docker + volumes на linux-based системе

сохранять файлы размером по 4кб разницы нет

Так?

сохранять файлы размером по 4кб разницы нет

огромная разница

особенно когда у тебя тысячи мелких php файлов в проекте

(вендоры, кэш)

любая операция записи через nfs будет в 8-10 раз медленнее

Заливается через svn кстати...

для примера - symfony приложение на linux в докере отдает респонсы за 40ms а у меня в виртуалке с nfs + docker 400ms

Заливается через svn кстати...

тогда забей на докер)

будет неконсистентно)

Контейнеры будут по одной простой причине - два проекта с разными версиями php

5.6 и 7

Сейчас один проект прямо на хосте держу, второй - виртуалка.

И мне это не очень....

если нет действий для воспроизведения среды - то как бы уже ты проигрываешь.

я не пишу в этот чат чтобы доказать что у меня 8=====> большой, если ты воспринимаешь каждое сообщение как "вызов" - то ок, будем общаться в ключе кто кого затроллит. по существу: сейчас нет ничего кроме виртуалки, значит нужно сделать что похоже и может решить проблему воспроизведения dev среды (ака provision), когда появятся шаги - будет ясно что использовать vagrant, vagrant + ansible, docker, docker + ansible (где ansible можно заменить на puppet, chef и тд)

> по существу: сейчас нет ничего кроме виртуалки, значит нужно сделать что похоже и может решить проблему воспроизведения dev среды (ака provision), когда появятся шаги - будет ясно что использовать vagrant, vagrant + ansible, docker, docker + ansible (где ansible можно заменить на puppet, chef и тд) vagrant имеет смысл только в ситуациях, когда тебе критична что бы в dev/prod окружении была одинаковая версия ядра linux. В противном случае docker. И да, docker + ansible так себе идея

ну то есть докер по дефолту - все остальное уже по ситуации.

p.s. я полтора года просидел на vagrant + ansible, сейчас всю эту кучу yaml файликов заменил простой docker-compose

vagrant имеет смысл в случае если у тебя: legacy, обычный hard сервер, ты умеешь только с виртуалкой работать

есть порог вхождения, про него почему то все забывают

а что думаешь по поводу того, что ансибл делает установку мониторов и докера на чистые ноды? мне нравится.

> есть порог вхождения, про него почему то все забывают в ансибл тип порога вхождения нет? Или в паппет?

а что думаешь по поводу того, что ансибл делает установку мониторов и докера на чистые ноды? мне нравится.

у меня этим занимается docker-machine

погоди, мы начали с чистого vagrant

погоди, мы начали с чистого vagrant

чистый вагрант проблему не решает. Воспроизводить окружение нужно. Если ты про "захерачить руками окружение и сохранить box" то тебе никто не мешает сделать docker commit

и уже не надо разбираться с dockerfile и прочим

а docker-machine кто ставит на ноды?

а все остальное - то же самое

(я не в теме про dm)

а docker-machine кто ставит на ноды?

docker-machine и ставит. У него есть generic драйвер который провиженит машину автоматом через ssh

круто, спс за наводку

?

но если тебе надо более тонко настраивать окружение хоста - то лучше все же ansible какой-нибудь.

если же деплоиться на какой-нибудь aws ecs то в целом хватает тупо докера и aws ecs cli

я что-то застрял с мыслью, что dm - это костыль для маководов.. а тут вон какой боярышник)

чистый вариант заставит решить проблему отсуствия provision, это имхо самая сложная часть в этом всём процессе

я что-то застрял с мыслью, что dm - это костыль для маководов.. а тут вон какой боярышник)

ну в целом эта штука для управления машинами с докер демонами, где именно он будет настраивать докер демон - зависит от выбранного драйвера. ТАм и под aws есть и под digital ocean

но 100% задач он не решает конечно

ок, все равно аригато

хотя для 90% проектов его хватает. Всякие там заббиксы ж можно поставить как docker контейнер и не париться.

ну так и делаю

- один элемент (ансибл) принесет только счастье

чистый вариант заставит решить проблему отсуствия provision, это имхо самая сложная часть в этом всём процессе

и мы приходим к тому что с docker это сделать банально проще

и мы приходим к тому что с docker это сделать банально проще

субьективщина не очень хороша для доказательств

как минимум потому что вместо подбора ролей и составления плейбуков можно тупо сделать docker pull php:7.0-apache

или что тебе надо

официальные образы существенно упрощают поддержку

а искать удобную роль в ansible-galaxy или рецепт для чифа такое себе развлечение

еще надо не проиграть когда плэйбуки составляешь

по сути единственный кейс когда вагрант лучше - это когда у тебя есть потребность в конкретной версии linux kernel

погоди погоди... мы про разное говорим. я не пытаюсь решать проблему деплоя на первом этапе. только переход от установки софта руками по инструкции к установке их через автоматику. виртуалка + инструкция => vagrant + provision потом в зависимости от текщего деплоя или желания его изменить либо vagrant + что то для деплоя либо docker

как минимум потому что вместо подбора ролей и составления плейбуков можно тупо сделать docker pull php:7.0-apache

выбор нужного базового контейнера может тоже поставить в тупик, сколько их там со словом php - 10, 100, 1000?

выбор нужного базового контейнера может тоже поставить в тупик, сколько их там со словом php - 10, 100, 1000?

поэтому там есть фильтрик "official"

У меня как раз linux

ты работаешь 1 над проектом?

https://hub.docker.com/_/php/

поэтому там есть фильтрик "official"

box'ы имеют то же свойство, ты же знаешь

box'ы имеют то же свойство, ты же знаешь

официальный бокс "debian", пустой но зато официальный?

ты работаешь 1 над проектом?

Два сейчас. Текущий (который используется). И новый - на laravel

под laravel еще есть laradock всякие

официальный бокс "debian", пустой но зато официальный?

https://atlas.hashicorp.com/debian/boxes/jessie64/

ERROR: S client not available

https://atlas.hashicorp.com/debian/boxes/jessie64/

docker pull debian

профита вообще нет

это как пустой контейнер

docker pull debian

разговор получается не очень я знаю как это сделать и через docker и через vagrant

профита вообще нет

профит есть в обучении, ты уже всё это знаешь - а человек нет

то есть обучение зло?)

под laravel еще есть laradock всякие

Проще самому создать, я думаю. Кроме того там ещё всякие oracle нужны....

разговор получается не очень я знаю как это сделать и через docker и через vagrant

Для докера есть официальный образ с пыхой

Клиенты я имею ввиду.

Или например php-fpm

Для докера есть официальный образ с пыхой

почему всех в интернете нужно держать за идиотов?!

Яснопонятно

вот мне rkt больше понравился чем docker, но пляски с systemd в версии 0.5 меня мало порадовали

воу rkt stop появился!

то есть обучение зло?)

обучение не является злом, главное делать это последовательно... docker меняет концепцию чуть более радикально чем виртуальная машина.

вот мне rkt больше понравился чем docker, но пляски с systemd в версии 0.5 меня мало порадовали

рокет был хорошим катализатором что бы докер развивался

некоторые реально важные плюшки (вроде подписи образов) по сути в докере были сделаны только после того как анонсировали рокет

обучение не является злом, главное делать это последовательно... docker меняет концепцию чуть более радикально чем виртуальная машина.

это да

хотя опять же тот же oracle

я не знаю приходилось ли тебе настраивать oracle в виртуалке самому

https://github.com/oracle/docker-images/tree/master/OracleDatabase

а так взял и готово

год назад когда без докера пытались это добро поднимать сами было больно

хотя опять же тот же oracle

я написал выше что я не знаю всей ситуации, но я могу почти на 99% сказать что с составлением provision возникнут проблемы потому что проблемы с документацией

Проще самому создать, я думаю. Кроме того там ещё всякие oracle нужны....

вот тут про оракл)

а так взял и готово

у него есть продакшен - нужно оглядываться на него.

у него есть продакшен - нужно оглядываться на него.

ну тут соглашусь

какие wiki для проекта юзаете?

confluence

ну блин(

?)

а другие есть?)