Синие/зеленые развертывания с Azure ServiceFabric

Ответ 1

Сервисная Fabric - это все, что нужно для прокатки обновлений, а не для свопов развертывания, например, для обмена VIP. Оба апатрида и службы с сохранением состояния обновляются таким же образом, но есть несколько дополнительных нюансов для состояния, о которых я расскажу позже.

При прокатке обновлений я имею в виду, что обновления до приложения выполняются на месте, по одному домену обновления за раз, поэтому нет простоев и внезапного переключения. Скользящее обновление в Service Fabric может быть выполнено в безопасном "управляемом" режиме, когда платформа будет выполнять проверки работоспособности, прежде чем перейти к следующему домену обновления, и автоматически откатится, если проверки работоспособности не пройдут.

Хорошо, все звучит хорошо. Но как вы выполняете синие/зеленые развертывания, когда обновления всегда обновляются?

Здесь, где появляются типы приложений и версия. Вместо двух "сред", которые могут содержать два запущенных приложения, Service Fabric имеет эту концепцию версий приложений, из которых могут быть созданы экземпляры приложений. Вот пример того, как это работает:

Скажем, я хочу сделать приложение под названием Foo. Мое приложение Foo определяется как тип приложения, называет его FooType. Это похоже на определение класса в С#. И, как класс в С#, я могу создавать экземпляры моего типа. Каждый экземпляр имеет уникальное имя, похожее на то, как каждый экземпляр объекта класса имеет уникальное имя переменной. Но в отличие от классов в С#, у моего FooType есть номер версии. Затем я могу "зарегистрировать" тип и версию приложения в своем кластере:

FooType 1.0

С зарегистрированным я могу создать экземпляр этого приложения:

"fabric:/FooApp" of FooType 1.0

Теперь скажем, что я разрабатываю версию 2.0 своего приложения. Поэтому я регистрирую версию 2.0 моего FooType в кластере:

FooType 1.0
FooType 2.0

Теперь у меня есть обе версии зарегистрированного FooType, и у меня все еще есть экземпляр 1.0:

"fabric:/FooApp" of FooType 1.0

Здесь, где он получает удовольствие. Я могу сделать несколько интересных вещей:

Я могу взять "fabric:/FooApp" - экземпляр FooType 1.0 и обновить его до FooType 2.0. Это будет скользящее обновление этого запущенного приложения.

Или.. Я могу оставить только "fabric:/FooApp" и создать новый экземпляр моего приложения версии 2.0:

"fabric:/FooApp" of FooType 1.0
"fabric:/FooAppv2Test" of FooType 2.0

Теперь у меня есть два приложения, работающих бок о бок, в одном кластере. Один экземпляр 1.0, а другой - экземпляр 2.0. При некоторой настройке портов и конечных точек приложения я могу гарантировать, что пользователи все еще будут обращаться к экземпляру 1.0, пока я тестирую экземпляр 2.0.

Отлично, поэтому все мои тесты проходят против экземпляра 2.0, поэтому теперь я могу смело взять экземпляр 1.0 и обновить его до 2.0 FooType. Опять же, это скользящее обновление этого экземпляра (fabric:/FooApp), это не перенос пользователей в новый экземпляр (fabric:/FooAppv2Test). Позже я пойду и удалю ткань:/FooAppv2Test, потому что это было просто для тестирования.

Одно из преимуществ синего/зеленого цвета, однако, может быть заменено на другое развертывание, если новый не работает. Ну, у вас все еще есть 1.0 и 2.0 зарегистрированного FooType. Поэтому, если ваше приложение начало ошибочно работать после обновления с 1.0 до 2.0, вы можете просто "обновить" его до 1.0! Фактически, вы можете "обновить" экземпляр приложения как можно больше различных типов своего типа приложения! И вам не нужно иметь экземпляры всех ваших версий приложений, которые работают, как в среде обмена, у вас есть только зарегистрированные версии и один экземпляр приложения, который может "обновляться" между версиями.

Я упомянул о предостережениях с поддержкой состояния. Главное, что нужно помнить с помощью служб с поддержкой состояния, - это состояние приложения - данные ваших пользователей - содержится в экземпляре приложения (fabric:/FooApp), поэтому для ваших пользователей, чтобы увидеть их данные, вам нужно сохранить их в этом экземпляре. Вот почему мы делаем перепродажу обновлений вместо свопов развертывания.

Это просто основная идея. Существуют и другие способы игры с типами приложений, версиями и экземплярами в зависимости от ваших целей и того, как работает ваше приложение, но в другое время.