OpenQuality.ru

Windows Azure: еще раз про автоматизацию развертывания

Добрый день.

В примере развертывания сервисов в Azure есть серьезный недостаток: в период останова/удаления старого и заливки/cтарта нового билда будет наблюдаться простой в работе сервиса. Это период может исчисляться единицами и даже десятками минут (определяется количеством ролей сервиса, количеством виртуальных машин для каждой роли и даже просто загрузкой Azure в текущий момент). Такие простои недопустимы. Как их избежать?

Как уже говорилось в предыдущей статье, у каждого сервиса есть два слота: Production и Staging. Слот Production – это “официальное” представительство сервиса; он имеет постоянный URL и обслуживает запросы пользователя. Слот Staging находится “в тени” – cнаружи он доступен только при известном Deployment ID, который меняется с каждой заливкой нового билда. Назначение слота Staging: предварительная заливка и проверка нового билда. После того как новый билд залит в Staging, можно делать switch – переключение сервисов, при котором сервисы в Staging и Production меняются местами: новый билд уходит в Production, а старый переходит в Staging. В случае использования слота Staging для заливки нового билда последовательность действий будет такой:

1. Заливка нового билда в Staging

$slot = "Staging"
New-Deployment -serviceName $servicename -storageserviceName $storagename -subscriptionId $sub -certificate $cert -slot $slot -package $package -configuration $config -label $label | 
Get-OperationStatus -WaitToComplete

2. Старт нового билда в Staging

Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub | 
	Get-Deployment -Slot $slot | 
	Set-DeploymentStatus 'Running' | 
	Get-OperationStatus -WaitToComplete

3. Ожидание полного старта сервиса в Staging

$wait = 120
write-host "Pause for $wait sec before we start checking service status"
Start-Sleep -s $wait
 
do
{
 
	$dep = Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub | Get-Deployment -Slot $slot
 
	"{0}: {1}" -f $dep.Slot, $dep.Status;
 
	$serviceReady = 1;      
 
	foreach($roleInstance in $dep.RoleInstanceList)
 
	{
		"{0}: {1}" -f $roleInstance.InstanceName, $roleInstance.InstanceStatus;
 
		if ($roleInstance.InstanceStatus -ne "Ready") 
		{ 
			$serviceReady = 0;
			write-host "Service $ServiceName is not ready. Next cycle after $wait sec...";
			Start-Sleep -s $wait
			break;
		}
	}
 
} while ($serviceReady -eq 0)

4. Проверка состояние сервиса в Production

Если сервис находится в состоянии Running Transitioning (например, при масштабировании), то переключить сервисы в слотах Production и Staging не удастся.

$wait = 120
do
{
	 $serviceReady = 1;      
 
	 $dep = Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub | Get-Deployment -Slot "Production"
 
	 "{0} {1} {2}: {3}" -f "Service", $servicename, "in Production", $dep.Status;
 
	 if ($dep.Status -eq "RunningTransitioning")
	 {
		   $serviceReady = 0;
		   write-host "We can't switch slots until $servicename in Production becomes just Running."
		   write-host "Next check after $wait sec...";
		   write-host "  "
		   Start-Sleep -s $wait
 
	 }
 
} while ($serviceReady -eq 0)

5. Дождались готовности сервисов в обоих слотах и выполняем их переключение

Get-Deployment staging -subscriptionId $sub -certificate $cert -serviceName $servicename | 
	   Move-Deployment | Get-OperationStatus -WaitToComplete

Теперь в Production у нас находится новый билд, а в Staging – старый.

6. Останавливаем сервис в Staging

 
Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub |
	Get-Deployment -Slot $slot |
	Set-DeploymentStatus 'Suspended' |
	Get-OperationStatus -WaitToComplete

7. Удаляем сервис из Staging

Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub | 
	Get-Deployment -Slot $slot | 
	Remove-Deployment | 
	Get-OperationStatus -WaitToComplete

Зачем останавливать и удалять сервис в Staging? Почему не оставить его на случай неполадок с новым билдом? Дело в том, что Microsoft взимает деньги за хостинг сервиса в Azure даже в том случае, если сервис находится в остановленном состоянии. Даже в Staging. Чем больше виртуальных машин, которые образуют сервис, тем больше приходится платить. Поэтому нужно находить компромисс: оставлять сервис в Staging только на период дымового тестирования билда в Production.

Всего доброго, оставайтесь с нами.

Отправить в Twitter, Facebook, ВКонтакте | Опубликовано 23.09.2010 в рубрике "Облака"

Комментарии (2)

1. Pingback : Качество программного обеспечения: невозможное возможно : Windows Azure: еще раз про автоматизацию развертывания | September 23, 2010

   […] Развертывание сервиса в среде Windows Azure с использованием слота Staging для обеспечения бесперебойной работы web-приложений. Читать далее. […]

   
   

2. Pingback : OpenQuality.ru | Качество программного обеспечения | February 21, 2011

   […] быть продуманы и отлажены. В случае облачного сервиса, заливка - это такая же важная часть техпроцесса как разработка […]

   
   

Добавить комментарий