Комментарии 12
С базами данных при таком подходе часто бывают проблемы
Кто бы сомневался)
Печаль в том, что со временем все привыкают бояться задорого менять имеющиеся и закостеневшие сущности в БД, без страха только приносят новые.
0
А ссылку на оригинал статьи можно приложить?
0
Трюк с использованием одной базы данных для двух серверов с разными версиями приложения заключается в том, что в новых версиях можно только добавлять новые сущности (колонки, таблицы и т.д.). А удалять старые можно только после того, как все серверы мигрируют на новую версию. При этом ничего не мешает делать это из самого приложения (обновление БД при запуске приложения — Liquibase и т.д.). Недостаток: миграция БД занимает несколько версий приложения.
А вот использование разных баз данных обязательно приведет к вопросу их синхронизации между собой, что опять-таки должно выполняться автоматически. Первый вариант (одна БД — много серверов) выглядит проще и надежнее.
А вот использование разных баз данных обязательно приведет к вопросу их синхронизации между собой, что опять-таки должно выполняться автоматически. Первый вариант (одна БД — много серверов) выглядит проще и надежнее.
0
Основная идея в том, чтобы иметь две легко переключаемых среды
А что если если серверов много? Достаточно дорогое решение. Ко всему этому 50% мощности всегда простаивает.
0
Да и необходимость переводить приложение в read-only режим во время деплоя тоже не очень красивое решение.
0
Большие дядьки, когда серверов много, заменяют по одному контролируя кто из пользователей переключен на новый сервис. canary release называется, опять же у Фаулера почитать можно: http://martinfowler.com/bliki/CanaryRelease.html
что в общем то частный случай blue-green deployemnt-а
Переключать в read-only не нужно и даже вредно, но нужно соблюдать правила backward/forward compatibity.
и снова Фаулер к чтению: http://martinfowler.com/articles/consumerDrivenContracts.html
что в общем то частный случай blue-green deployemnt-а
Переключать в read-only не нужно и даже вредно, но нужно соблюдать правила backward/forward compatibity.
и снова Фаулер к чтению: http://martinfowler.com/articles/consumerDrivenContracts.html
0
По-вашему, 50% дисков в RAID1 тоже простаивают?
0
Здесь вам на помощь придёт уменьшение уровня изоляции — виртуальные машины, контейнеры или даже просто изолированные среды исполнения (отдельные application pool в IIS, pool в php-fpm и т.д.).
Например у нас более-менее стандартная схема nginx->haproxy->backend, где в качестве бэкендов выступают IIS, где на каждом сервере есть b/g apppool. Основная нагрузка обрабатывается только одним экземпляром, второй через минуту (в нашем случае) просто выгружается, потому что haproxy не передаёт на него новых запросов. А запас по памяти на бэкенде организовать обычно не проблема.
Например у нас более-менее стандартная схема nginx->haproxy->backend, где в качестве бэкендов выступают IIS, где на каждом сервере есть b/g apppool. Основная нагрузка обрабатывается только одним экземпляром, второй через минуту (в нашем случае) просто выгружается, потому что haproxy не передаёт на него новых запросов. А запас по памяти на бэкенде организовать обычно не проблема.
0
Прежде всего хочу сказать спасибо моей жене Клэр, которая сподвигла меня написать это комментарий. Моим друзям Дэну и Стивену что поддерживали меня когда я читал текст перевода. Хочу поблагодарить Натали Басс за оказаный перевод, и особую благодарность Дэйву Фарли (Dave Farley) и Джезу Хамбл (Jez Humble) за незаконченную книгу «Непрерывная доставка», автору неизвестного рисунка с амебами, так же благодарен за то что открыл для меня новый вид технической схемы.
После того как мы пересели на Сине-Зеленый деплой мы увеличили продажи. Вначале мы были настроены скептически, но когда мы собравшись на совещании, Кен (наш ведущий аналитик) неожиданно сказал: «Почему бы нам не попробувать сине-зеленый деплой»? И тут же с жестикуляцией начал объяснять нам, что это то, что нам нужно. Никогда наши совещания не были столь увлекательные. Мы избежали сразу же проблемы с базами данных с маржинколами и перчерсордерами, фьючерсы начали общатся на одном языке с контентменеджерами, а фолоапы почти исчезли.
Спасибо автор за проделаный вами труд. Побольше бы таких статей на хабре!
PS: Спасибо фаулеру за новый паттерн!
После того как мы пересели на Сине-Зеленый деплой мы увеличили продажи. Вначале мы были настроены скептически, но когда мы собравшись на совещании, Кен (наш ведущий аналитик) неожиданно сказал: «Почему бы нам не попробувать сине-зеленый деплой»? И тут же с жестикуляцией начал объяснять нам, что это то, что нам нужно. Никогда наши совещания не были столь увлекательные. Мы избежали сразу же проблемы с базами данных с маржинколами и перчерсордерами, фьючерсы начали общатся на одном языке с контентменеджерами, а фолоапы почти исчезли.
Спасибо автор за проделаный вами труд. Побольше бы таких статей на хабре!
PS: Спасибо фаулеру за новый паттерн!
+3
Прям не иллюстрации, а реклама детских разноцветных прокладок.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Сине-зеленый деплой