Очень просто ports: ip:80:80. Но я сейчас использую nginx-proxy как описано здесь, только на Win пришлось поставить локально nginx, для проксирования на Docker Api. На linux машине прописал в DNS домен, для локальной разработки
Как-нибудь удалось решить проблему с тормозами? на работе приходится работать под Windows при монтировании папки в контейнер заметно падает скорость загрузки страниц, немного помогает вынос логов внутрь докер контейнера(аткуально для symfony app)
Мне кажется это не совсем верный подход, хорошо если делаешь два мержа один за другим, и можешь посмотреть и соотнести последовательность миграций, а когда делаешь мержи через несколько дней и/или несколько мержей в течении дня. У меня не так много опыта, но уже даволно часто приходилось встречаться, когда фича могла висеть долгое время, до вливания ее в мастер. а тут получается нужно будет переименовать файлы миграций, перед тем как что-то влить, и при том делать это постоянно, чтобы быть уверенным что миграция будет выполнена
Два разработчика ответвились от ветки где последняя миграция Version20150527081937. Первый генерирует миграцию, номер у нее будет Version20160627081937, второй Version20160528081937. Вначале вливаются изменения первого, и теперь номер миграции выше чем у второго. Получается она не применится? В обоих миграциях создания не связанных друг с другом таблиц
Я о том чтобы миграция 1 была выполнена, даже если перед ней было выполнена миграция 2. То есть просто сравнивать какие миграции выполнены в базе и какие еще есть, а вот порядок 1 и 2 это просто последовательность выполнения. Так же, насколько я знаю делает доктрина
А почему не использовать COMPOSE_PROJECT_NAME=CI_JOB_ID, в этом случае у всех контейнеров и сетей будет уникальное имя?
Очень просто ports: ip:80:80. Но я сейчас использую nginx-proxy как описано здесь, только на Win пришлось поставить локально nginx, для проксирования на Docker Api. На linux машине прописал в DNS домен, для локальной разработки
Для всех логов, type: rotating_file плюс для каждого уровня и канала свой файл, еще забыл про вынос файла с кешем так же внутрь контейнера, подозреваю что тоже самое нужно будет проделать и со статикой, на варганте помогает http://www.whitewashing.de/2013/08/19/speedup_symfony2_on_vagrant_boxes.html
Как-нибудь удалось решить проблему с тормозами? на работе приходится работать под Windows при монтировании папки в контейнер заметно падает скорость загрузки страниц, немного помогает вынос логов внутрь докер контейнера(аткуально для symfony app)
Мне кажется это не совсем верный подход, хорошо если делаешь два мержа один за другим, и можешь посмотреть и соотнести последовательность миграций, а когда делаешь мержи через несколько дней и/или несколько мержей в течении дня. У меня не так много опыта, но уже даволно часто приходилось встречаться, когда фича могла висеть долгое время, до вливания ее в мастер. а тут получается нужно будет переименовать файлы миграций, перед тем как что-то влить, и при том делать это постоянно, чтобы быть уверенным что миграция будет выполнена
Два разработчика ответвились от ветки где последняя миграция Version20150527081937. Первый генерирует миграцию, номер у нее будет Version20160627081937, второй Version20160528081937. Вначале вливаются изменения первого, и теперь номер миграции выше чем у второго. Получается она не применится? В обоих миграциях создания не связанных друг с другом таблиц