Стратегии сине-зеленого развертывания в Azure Spring Apps

Эта статья относится к:✅ Basic/Standard ✅ Enterprise

В этой статье описывается поддержка сине-зеленых развертываний в Azure Spring Apps.

Azure Spring Apps (стандартный план и более поздние версии) разрешает два развертывания для каждого приложения, только одно из которых получает рабочий трафик. Этот шаблон часто называется сине-зеленым развертыванием. Поддержка сине-зеленого развертывания в Azure Spring Apps в сочетании с конвейером непрерывной поставки (CD) и тщательное автоматизированное тестирование позволяют гибко развертывать приложения с высоким уровнем уверенности.

Чередование развертываний

Для самой простой реализации сине-зеленого развертывания в Azure Spring Apps следует создать два фиксированных развертывания и всегда использовать для развертывания обновлений то из них, которое не получает рабочий трафик. Задача Azure Spring Apps для Azure Pipelines позволяет легко настроить такой режим развертывания, установив для флага UseStagingDeployment значение true.

Ниже описан практический подход к чередованию развертываний.

Предположим, что приложение имеет два развертывания: deployment1 и deployment2. В настоящее время deployment1 установлено как производственное развертывание и выполняет версию приложения v3.

Это означает, что развертывание deployment2 является промежуточным. Таким образом, когда конвейер непрерывной доставки (CD) готов к запуску, он развертывает следующую версию приложения (v4) на промежуточном развертывании deployment2.

После запуска v4 на deployment2 вы можете провести автоматические и ручные тесты через частную тестовую конечную точку, чтобы убедиться, что v4 соответствует всем ожиданиям.

Когда вы будете уверены в версии v4, развертывание deployment2 можно перевести в статус рабочего, и теперь оно будет получать весь рабочий трафик. При этом v3 продолжит работу в deployment1 на случай, если выявите критическую ошибку и потребуется вернуть назад.

Развертывание deployment1 является промежуточным. Поэтому следующий запуск конвейера развертывания развертывает на deployment1.

Теперь вы можете протестировать V5 на закрытой тестовой конечной точке deployment1.

И теперь, когда версия v5 соответствует всем вашим ожиданиям, вы снова устанавливаете deployment1 в качестве рабочей версии, чтобы v5 получало весь трафик в рабочей среде.

Компромиссы, связанные со стратегией чередования развертываний

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

Постоянное стейджинг-развертывание

Промежуточное развертывание всегда работает, а значит потребляет ресурсы экземпляра Azure Spring Apps. Это по сути удваивает требования к ресурсам для каждого приложения в Azure Spring Apps.

Состояние гонки в процессе утверждения

Предположим, что в вышеописанном приложении производственный конвейер требует ручного утверждения перед тем, как новая версия приложения сможет получать рабочий трафик. Это создает риск того, что, пока одна версия (v6) ожидает ручного утверждения на промежуточном развертывании, конвейер развертывания снова запустится и перезапишет её более новой версией (v7). Затем, когда будет предоставлено утверждение для v6, конвейер развертывания v6 переведет промежуточное развертывание в производство. Но теперь будет развернута непроверенная версия v7, а не утвержденная v6, и именно она будет получать трафик.

Возможно, вы сможете предотвратить состояние гонки, гарантируя, что поток развертывания для одной версии не сможет начаться, пока не будет завершён или прерван поток развертывания для всех предыдущих версий. Другой способ предотвратить состояние гонки при утверждении — использовать метод именованных развертываний, который описан ниже.

Именованные развертывания

При использовании метода именованных развертываний для каждой новой версии развертываемого приложения создается новое развертывание. Когда приложение протестировано на своем индивидуальном развертывании, это развертывание устанавливается в качестве рабочего. Развертывание с предыдущей версией можно сохранять достаточно долго, чтобы быть уверенным, что откат не понадобится.

На рисунке ниже версия v5 выполняется на развертывании deployment-v5. Имя развертывания теперь содержит номер версии, поскольку оно было создано специально для этой версии. Других развертываний пока нет. Теперь, чтобы развернуть версию v6, конвейер развертывания создает новое развертывание deployment-v6 и развертывает в нем версию приложения v6.

Так мы избавляемся от риска параллельного развертывания другой версии. Во-первых, Azure Spring Apps не допускает создания третьего развертывания, пока существуют два предыдущих. Во-вторых, даже если возможно более двух развертываний, каждое развертывание идентифицируется по версии приложения, которую оно содержит. Таким образом, конвейер, управляющий оркестрацией развертывания v6, будет пытаться установить в качестве продуктового развертывания только deployment-v6.

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

Компромиссы, связанные с методом именованных развертываний

Метод именованных развертываний имеет следующие преимущества:

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

Но существуют и недостатки, которые описаны в следующем разделе.

Сбои конвейера развертывания

Между началом развертывания и удалением промежуточного развертывания любые попытки снова запустить конвейер развертывания завершатся ошибкой. Конвейер попытается создать новое развертывание, что завершится ошибкой, так как для каждого приложения в Azure Spring Apps разрешено только два развертывания.

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

Следующие шаги

• Автоматизация развертываний приложений в Azure Spring Apps