угу, и половина вьюх слетит

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

не все миграции совместимы с обновлением кода. например, в схеме, когда у вас head/tail базы (в проде используется одна из и с каждым релизом они меняются местами) самый сложный вариант миграции это изменение формата поля ... так вот он делался в 5 шагов. то есть в 5 релизов чтобы было forward & backward compatibility

не все миграции совместимы с обновлением кода. например, в схеме, когда у вас head/tail базы (в проде используется одна из и с каждым релизом они меняются местами) самый сложный вариант миграции это изменение формата поля ... так вот он делался в 5 шагов. то есть в 5 релизов чтобы было forward & backward compatibility

Почему пять, трёх не хватит?

я лучше потом в личку воспроизведу, если не горит. сейчас чутка занят

я лучше потом в личку воспроизведу, если не горит. сейчас чутка занят

ok)

возможно, я не встречался пока с какими-то случаями, но если миграции транзакционны, и имеют полноценны down (да, это не всегда возможно, или очень трудозатратно), то достаточно одной бд, если же дауна нет, то две бд, и переключение в зависимости от версии релиза

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

Миграции нужны чтобы мигрировать схему базы. Точка.

ну нет, это слишком строгое ограничение.

это не ограничение, а определение

если бы они не помогали обеспечивать косистентность версии бд с версией кода - я бы их не испольовал)

Делайте в два шага, что я еще могу сказать.

зачем в два?)

На больших базах выполнение миграций это жесть по времени.

зачем в два?)

Потому что если делать в один шаг то придется полный цикл миграций накатить

ну миграции тоже разные бывают

Например, добавить поле и удалить еще какое то.

это не ограничение, а определение

класс, вы предлагаете все делать по букве?

Все это долго. Если раскатить это на несколько шагов то это позволит достичь меньшего даунтайма.

И научить код работать с двумя полями одновременно

Сложные миграции должны накатываться без простоя имхо. Либо простой должен быть гарантированно небольшим.

Иначе прод будет простаивать пару часов

собственно, дженкинс заливает код в папку нового релиза, делает копию бд, накатывает миграции и мы переключаемся на новый релиз, зачем мне дайнтайм?

Стоп стоп стоп

что происходит со старой версией базы?

туда в реалтайме могут новые данные приходить

вы просто теряете часть данных

класс, вы предлагаете все делать по букве?

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

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

Так как с переключением базы вы не допускаете потерь данных?

ок, вместо копии используем репликацию

постгрес вроде позволяет в транзакции накатывать обновление схемы данных

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

возможно и путаю, но фишка в том, что на практике надо отталкиваться от того, что сейчас есть, а не от "определения слова миграция"

То что сейчас есть? а что есть? то что у вас есть то на вас и накладывает ограничения.

Вроде в постгрессе можно накатывать обновление схемы в транзакции. Следовательно достаточно сделать так чтобы старый код мог работать с новой схемой пока новый код не будет запущен во всех инстансах

А следовательно лучше делать миграции базы в два шага.

Возможно кто то более опытный что подскажет? хотя мне кажется это больше для канала по базам данных.

ну да, моя база не содержит такого кол-ва данных, чтоб миграции выполнялись дольше пары секунд

Тогда у вас и проблемы нет

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

Впрочем даже 10 минут имхо перебор, если сайт не заточен на конкретную временную зону.

докер из репозитория, композ с сайта докера

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

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

спасибо, займусь.

так-что каждый третий билд в нашей компании включает в себя и миграции тоже

ну это веский аргумент, чтобы использовать докер

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

там выше обсуждали докеризацию бд и смысл этого

я просто возразил на то, что бд может изменяться чаще, и все

> Anton я просто возразил на то, что бд может изменяться чаще, и все Просто тут надо понимать, что докер про ЧАСТО ИЗМЕНЯЕМЫЙ КОД сервисов, а не про часто изменяемые данные. Поэтому сколько там раз миграции применяются - не столь важно.

применение миграций - это часть деплоя, все же)

Небольшой обзор докладов на предстоящей конференции "Linux Piter #2": https://habrahabr.ru/company/emc/blog/311614/

Ребят, можете помочь с докером? Уже совсем с ног сбился :( Все время после перезагрузки поднимается интерфейс docker0. Причем контейнеров докеровских никаких нет, все удалены. Но интерфейс поднимается, на пинги отвечает, апач на нем работает. Где можно найти этот неуловимый конейнер?

docker ps что показывает?

пусто

В том то и суть. И от пользователя, и от рута

netsta -ntlp

И docker ps -a пустой?

Да

в хост системе есть апачь?

есть

опусти его и не дудет отвечать

или listen сделай на конкретный ip

netstat -ntlp | grep 80

убил апач, отвечать перестал

Думаю будет что типа tcp6 0 0 :::80 :::* LISTEN 3810/apache2

Интерфейс только не пойму откуда берется

демон докера его подинмает

а откуда? Я уже ведь всей контейнеры удалил

https://docs.docker.com/engine/userguide/networking/default_network/custom-docker0/#customize-the-docker0-bridge

глубже не копал

Удалил мост. После перезагрузки та же лавочка

а чем мост мешает?

господа. у меня тут интерсная ситуация. я поднял набор контейнеров docker-compose-ом, они друг друга видят , подсетка стандартная 172.18.255.255 поднял рядом еще два но уже просто докером, подсетка 172.17.255.255 ( не 172.18 ! ) эти два друг друга видят и по именами и по ip (приложения отвечают по http) но из первой группы вторая группа не видна и наоборот причем даже ping не ходит обе группы видны с хоста

вопрос

чозах

Вопрос то в чем?

network_mode Надо указать, если нужно чтобы они все друг друга видели, то есть либо при запуске композером прописать network_mode=bridge, либо тем что руками поднимал указать тот нетворк который создал композер

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

потому что нет маршрутизации?

это ответ?

это ответ?

Нужен маршрутизатор или arp proxy - но его нельзя советовать