Comments 5
Или я чего-то не понимаю всё таки: Смена IP адресов в таблице балансировщика нагрузки занимает секунды != Zero Downtime Upgrade
Ну и это не считая того, что адекватно «прогреть» тяжелое приложение в таком случае врядли получится.
Не лучше ли держать балансировщик in front, который собственно и будет отвечать на запросы к contoso.cloudapp.net и проксировать на «backend»?
Ну и это не считая того, что адекватно «прогреть» тяжелое приложение в таком случае врядли получится.
Не лучше ли держать балансировщик in front, который собственно и будет отвечать на запросы к contoso.cloudapp.net и проксировать на «backend»?
Подразумеваю, что «прогрев» приложение в staging окружении уже прошло. То есть оно работает и отвечается на запросы про URL: http://{guid}.cloudapp.net/. В случае свопа балансировщик (внутренний) просто перенаправляет запросы на новый адрес.
Однако, вы абсолютно верно заметили! Есть вариант организации балансировщика «in front». Об этом будет вторая часть — Traffic Manager.
Однако, вы абсолютно верно заметили! Есть вариант организации балансировщика «in front». Об этом будет вторая часть — Traffic Manager.
Внимание вопрос.
Есть у меня допустим, contoso.com, веб роль приложения asp.net mvc. есть к нему база данных production.
как мне обновить staging для выкатки обновления тестерам в случае обновления моделей. Если я обновляю структуру бд, то production тут же ломается с ошибкой что текущая модель в коде не соответствует модели БД.
Условие таково что тестовые пользователи должны продолжать работать с боевыми данными и на staging и на production, то ест для них обе среды должны ссылаться на одни и те же данные.в БД.
Реальный кейс: я пишу маленькую домашнюю веб бухгалтерию для частного использования.
Хочу выкатить новый функционал для определенной группы пользователей.
Эта группа пользователей хочет заходить и по production ссылке и одновременно сравнивать работу компонентов приложения выложенных в staging.
Можно, конечно, сказать что «извините, но вы пользуетесь тестовой средой и изменения в production ваших данных будут выкатываться в полночь» и написать велосипед, забирающий данные тестовых пользователей из одной бд (тестовое окружение) и меняющие их под реалии production database а пользователей с галочкой «тестовая группа» в профиле перенаправлять в staging…
Ваши варианты взглядов на эту проблему?
Есть у меня допустим, contoso.com, веб роль приложения asp.net mvc. есть к нему база данных production.
как мне обновить staging для выкатки обновления тестерам в случае обновления моделей. Если я обновляю структуру бд, то production тут же ломается с ошибкой что текущая модель в коде не соответствует модели БД.
Условие таково что тестовые пользователи должны продолжать работать с боевыми данными и на staging и на production, то ест для них обе среды должны ссылаться на одни и те же данные.в БД.
Реальный кейс: я пишу маленькую домашнюю веб бухгалтерию для частного использования.
Хочу выкатить новый функционал для определенной группы пользователей.
Эта группа пользователей хочет заходить и по production ссылке и одновременно сравнивать работу компонентов приложения выложенных в staging.
Можно, конечно, сказать что «извините, но вы пользуетесь тестовой средой и изменения в production ваших данных будут выкатываться в полночь» и написать велосипед, забирающий данные тестовых пользователей из одной бд (тестовое окружение) и меняющие их под реалии production database а пользователей с галочкой «тестовая группа» в профиле перенаправлять в staging…
Ваши варианты взглядов на эту проблему?
В статье описан процесс миграции приложения. Миграция компонента уровня базы данных — это тема отдельной статьи. Конечно если Staging и Production окружение работают с одной базой данных, то априори Staging версия не должна содержать никаких breaking changes в базе данных. Ну или поддерживать хотя бы backward compatibility.
В вашем примере, я бы для staging использовал отдельную БД, и при необходимости синхронизировал данные из production, допустим с помощью того же SQL Server Agent или SQL Azure Data Sync. Да это накладно, однако на мой взгляд production нельзя ломать ни в коем случае.
К тому же, если уж пошел разговор для разделения окружений, то centur ниже совершенно правильно заметил, что если вы хотите разграничить окружения, то лучше будет сделать отдельный облачный сервис, либо вообще отдельную подписку. Такие решения как раз встречаются чаще в продакшене.
Статья лишь описывает средства, которые Microsoft предоставляет из коробки. Конечно в любой технологии есть свои подводные камни и скрытые фичи. Но возможность реализовать одну задачу разными способами — это преимущество.
Кстати, в следующей статье, я как раз опишу механизм, как сделать Zero Downtime для нескольких облачных сервисов, без использования Staging и Production слотов.
В вашем примере, я бы для staging использовал отдельную БД, и при необходимости синхронизировал данные из production, допустим с помощью того же SQL Server Agent или SQL Azure Data Sync. Да это накладно, однако на мой взгляд production нельзя ломать ни в коем случае.
К тому же, если уж пошел разговор для разделения окружений, то centur ниже совершенно правильно заметил, что если вы хотите разграничить окружения, то лучше будет сделать отдельный облачный сервис, либо вообще отдельную подписку. Такие решения как раз встречаются чаще в продакшене.
Статья лишь описывает средства, которые Microsoft предоставляет из коробки. Конечно в любой технологии есть свои подводные камни и скрытые фичи. Но возможность реализовать одну задачу разными способами — это преимущество.
Кстати, в следующей статье, я как раз опишу механизм, как сделать Zero Downtime для нескольких облачных сервисов, без использования Staging и Production слотов.
Пожалуйста, не используйте стейджинг окружение для тестов!
Никогда не делайте этого — единственное предназначение стейджинг окружения — более гладкое обновление продакшена (с чем он справляется но средненько).
В остальных случаях вы не просто наступаете на грабли, вы просто бегаете по полю с граблями. Даже сотрудники МС, когда с ними беседуешь на эту тему говорят что изначально они не очень правильно спозиционировали эту фичу. Сейчас они уже не говорят что стейджинг окружение — для тестеров.
Итак краткий перечень самых толстых граблей:
1. Обновление базы в результате миграций (привет от EF) — ваш стейджинг слот может содержать миграции которые несовместимы с тем что в продакшене. Засунули новый пакет, прогрели — получили сломаную базу в продакшене.
2. Vip Swap обратно — возможно. но тоже есть риски. Если вы поломали базу продакшена предыдущим действием — откатиться просто так не получится — вам нужно сделать даунгрейд миграции. А ее то на продакшене еще нету ( потому как она новая и есть только в пакете стейджинга)
3. Несколько сайтов — если у вас несколько сайтов в одной роли (например админка или сайты с разной авторизацией) — работать с ними в стейджинге — невозможно, Hostheader не прописываеся никому кроме основного, т.е. достучаться до админки в стейджинг слоте — нельзя ( это если вы вдруг захотите починить что-то откатом миграции через админку ;) )
4. Очереди. Сделали вы воркер роль, которая при старте начинает таскать сообщения из очереди. Вроде все как МС рекомендовал. Заливаете в стейджинг для тестирования — обнаруживаете что есть бага (ну вы же «тестируете» — это нормально). Ан нет — воркер в стейджинге таскает те же сообщения что и продакше. Ну т.е. из продакшен очереди. Т.е. часть сообщений в очереди было стырено стейджингом, успешно слито по причине бага и кто-то что-то недополучил в продакшене.
Ну и еще много мелких других вещей, за которыми надо следить, если вы действительно хотите иметь контроллируемое продакшен окружение.
Всегда используйте отдельно сконфигурированное тестовое (а можно и девелоперское) окружение. Да это будет дороже, и даже если вы считаете что вырванные нажо..голове волосы отрастут — клиенты попавшие в такие ситуации будут очень обижены на вашу «технологическую платформу».
Никогда не делайте этого — единственное предназначение стейджинг окружения — более гладкое обновление продакшена (с чем он справляется но средненько).
В остальных случаях вы не просто наступаете на грабли, вы просто бегаете по полю с граблями. Даже сотрудники МС, когда с ними беседуешь на эту тему говорят что изначально они не очень правильно спозиционировали эту фичу. Сейчас они уже не говорят что стейджинг окружение — для тестеров.
Итак краткий перечень самых толстых граблей:
1. Обновление базы в результате миграций (привет от EF) — ваш стейджинг слот может содержать миграции которые несовместимы с тем что в продакшене. Засунули новый пакет, прогрели — получили сломаную базу в продакшене.
2. Vip Swap обратно — возможно. но тоже есть риски. Если вы поломали базу продакшена предыдущим действием — откатиться просто так не получится — вам нужно сделать даунгрейд миграции. А ее то на продакшене еще нету ( потому как она новая и есть только в пакете стейджинга)
3. Несколько сайтов — если у вас несколько сайтов в одной роли (например админка или сайты с разной авторизацией) — работать с ними в стейджинге — невозможно, Hostheader не прописываеся никому кроме основного, т.е. достучаться до админки в стейджинг слоте — нельзя ( это если вы вдруг захотите починить что-то откатом миграции через админку ;) )
4. Очереди. Сделали вы воркер роль, которая при старте начинает таскать сообщения из очереди. Вроде все как МС рекомендовал. Заливаете в стейджинг для тестирования — обнаруживаете что есть бага (ну вы же «тестируете» — это нормально). Ан нет — воркер в стейджинге таскает те же сообщения что и продакше. Ну т.е. из продакшен очереди. Т.е. часть сообщений в очереди было стырено стейджингом, успешно слито по причине бага и кто-то что-то недополучил в продакшене.
Ну и еще много мелких других вещей, за которыми надо следить, если вы действительно хотите иметь контроллируемое продакшен окружение.
Всегда используйте отдельно сконфигурированное тестовое (а можно и девелоперское) окружение. Да это будет дороже, и даже если вы считаете что вырванные на
Sign up to leave a comment.
Zero Downtime Upgrade для приложения в Microsoft Azure. Часть 1: PaaS