Подробное руководство по сине-зеленым развертываниям с помощью Materialize

Минимизация времени простоя во время любого развертывания является ключевой частью любой успешной стратегии развертывания. Есть много способов добиться этого, и сине-зеленое развертывание — один из них.

Использование сине-зеленых развертываний позволяет не только минимизировать время простоя, но и дает возможность вернуться к предыдущей версии приложения, если что-то пойдет не так.

В этой статье мы рассмотрим, как развернуть Materialise в сине-зеленой стратегии развертывания.

Предпосылки

Прежде чем приступить к работе, у вас должно быть следующее:

• Базовые знания [Materialize] (https://materialize.com/docs/get-started)

• [Materialize Cloud Account] (https://cloud.materialize.com/account/sign-up) — *Бесплатная пробная версия включает доступ к двум экземплярам, ​​поэтому вы сможете бесплатно протестировать сине-зеленую архитектуру. *

• На вашем компьютере установлены psql или mzcli

• Поставщик услуг DNS, например Cloudflare, AWS Route 53, Google Cloud DNS или любой другой поставщик услуг DNS.

Что такое сине-зеленое развертывание?

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

В качестве примера взгляните на следующую схему:

Здесь у нас есть два экземпляра Materialize, работающие в Materialise Cloud. Синий экземпляр — это тот, который в настоящее время работает и обрабатывает трафик, поскольку это то, что мы настроили в нашем DNS. Зеленый экземпляр — это тот, который развертывается, и он начнет обрабатывать трафик после завершения развертывания и после того, как мы изменим DNS, чтобы он указывал на зеленый экземпляр.

Весь процесс обычно выглядит так:

• Первоначально у вас будет синий экземпляр, работающий следующим образом:

Этот единственный экземпляр в настоящее время обрабатывает трафик и выполняет всю работу.

• Затем вы должны развернуть новую версию Materialize на зеленом экземпляре:

После завершения развертывания вам потребуется создать все необходимые источники и представления Materialise.

• После завершения развертывания и приема всех ваших данных вы должны переключить DNS, чтобы он указывал на зеленый экземпляр:

После обновления DNS трафик переключается на зеленый экземпляр. Однако имейте в виду, что для распространения DNS может потребоваться некоторое время, прежде чем зеленый экземпляр начнет обрабатывать весь трафик.

Во время распространения DNS синий экземпляр будет продолжать обрабатывать часть трафика.

• После обновления DNS трафик переключается на зеленый экземпляр:

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

• Наконец, мы можем полностью отключить синий экземпляр:

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

Планируйте развертывание

Остальная часть этой статьи представляет собой практическое пошаговое руководство по сине-зеленому развертыванию Materialize Cloud, в котором выполняются следующие шаги:

• Создайте один экземпляр Materialize через Materialize Cloud, это будет синий экземпляр.

• Создайте запись DNS, указывающую на синий экземпляр

• Подключитесь к синему экземпляру и создайте все необходимые источники и представления Materialise.

• Создайте новый экземпляр Materialize через Materialize Cloud, это будет зеленый экземпляр.

• В этот момент только синий экземпляр работает и обрабатывает трафик, поэтому далее мы переключим DNS так, чтобы он указывал на зеленый экземпляр.

• После обновления DNS трафик переключается на зеленый экземпляр, но имейте в виду, что для распространения DNS может потребоваться некоторое время, прежде чем зеленый экземпляр начнет обрабатывать весь трафик.

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

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

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

Создайте «синий» экземпляр с помощью пользовательского интерфейса Materialize Cloud:

• Нажмите кнопку «Создать новое развертывание».

• Выберите имя вашего развертывания. Мы будем использовать имя «синий» для этого развертывания, чтобы убедиться, что мы можем легко идентифицировать его позже.

• Далее выберите размер и регион вашего развертывания

• Наконец, нажмите кнопку «Создать».

Это займет всего несколько минут.

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

Подключение к материализации

В этой демонстрации мы будем использовать команду psql для подключения к экземпляру.

Следуйте инструкциям в пользовательском интерфейсе Cloud, чтобы загрузить сертификаты и подключиться к вашему новому экземпляру через psql в командной строке.

Примечание: вам придется изменить флаг sslmode=verify-full на sslmode=require, если вы не подключаетесь к самому имени хоста развертывания.

Добавление источников материализации

Для этой демонстрации мы будем использовать пример PubNub из документации Materialise Cloud.

Во-первых, нам нужно создать источник PubNub:

```sql

СОЗДАТЬ ИСТОЧНИК market_orders_raw

ОТ PUBNUB

КЛЮЧ ПОДПИСКИ 'sub-c-4377ab04-f100-11e3-bffd-02ee2ddab7fe'

КАНАЛ 'pubnub-market-orders';

Затем мы можем создать [нематериализованное представление] (https://materialize.com/docs/overview/api-components/#non-materialized-views), которое просто предоставляет псевдоним для встроенного оператора SELECT:

```sql

СОЗДАТЬ ПРОСМОТР market_orders AS

ВЫБРАТЬ

((text::jsonb)->>'bid_price'::float AS bid_price,

(text::jsonb)->>'order_quantity' КАК order_quantity,

(text::jsonb)->>'символ' AS символ,

(text::jsonb)->>'trade_type' AS trade_type,

to_timestamp(((text::jsonb)->'timestamp'::bigint) AS ts,

ОТ market_orders_raw;

И, наконец, создайте материализованное представление, которое вычисляет среднюю цену предложения:

```sql

СОЗДАТЬ МАТЕРИАЛИЗОВАННОЕ ПРЕДСТАВЛЕНИЕ avg_bid AS

ВЫБЕРИТЕ символ,

AVG(цена_предложения) AS avg

ОТ market_orders

СГРУППИРОВАТЬ ПО символу;

Наконец, вы можете проверить результаты:

```sql

SELECT * FROM avg_bid;

символ | среднее

яблоко | 199.3392717416626

Гугл | 299.40371152970334

Элериум | 155.04668809209852

Беспин Газ | 202.0260593073953

льняная ткань | 254.34273792647863

Дополнительные сведения об источнике PubNub см. в примере Materialize Cloud PubNub.

Создать маршрут (через DNS или LB) к синему инстансу

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

Для этого вам нужно будет обратиться к своему провайдеру DNS и создать следующую запись:

• Запись CNAME для materialize.your_domain.com, указывающая на имя хоста экземпляра Materialise (например, 12345mz.materialize.cloud)

Например, если имя хоста вашего экземпляра — «my-instance.materialize.cloud», вам потребуется создать запись CNAME, указывающую на «my-instance.materialize.cloud» следующим образом:

materialize.example.com. CNAME 12345mz.materialize.cloud.

Обратите внимание, измените 12345mz.materialize.cloud на имя хоста вашего экземпляра.

Это позволит вам получить доступ к экземпляру через ваше собственное имя хоста: materialize.example.com.

После создания записи CNAME вы можете получить доступ к экземпляру с помощью той же команды psql, что и раньше, но вместо имени хоста Materialize вы можете использовать имя DNS (например, materialize.example.com).

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

Выполнение сине-зеленого развертывания

Со всей этой настройкой мы теперь можем выполнить сине-зеленое развертывание. Сначала мы создадим новый экземпляр Materialize через Materialize Cloud, как мы это делали при первом развертывании.

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

• Создайте источник PubNub:

```sql

СОЗДАТЬ ИСТОЧНИК market_orders_raw

ОТ PUBNUB

КЛЮЧ ПОДПИСКИ 'sub-c-4377ab04-f100-11e3-bffd-02ee2ddab7fe'

КАНАЛ 'pubnub-market-orders';

• Создайте нематериализованное представление:

```sql

СОЗДАТЬ ПРОСМОТР market_orders AS

ВЫБРАТЬ

((text::jsonb)->>'bid_price'::float AS bid_price,

(text::jsonb)->>'order_quantity' КАК order_quantity,

(text::jsonb)->>'символ' AS символ,

(text::jsonb)->>'trade_type' AS trade_type,

to_timestamp(((text::jsonb)->'timestamp'::bigint) AS ts

ОТ market_orders_raw;

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

```sql

СОЗДАТЬ МАТЕРИАЛИЗОВАННОЕ ПРЕДСТАВЛЕНИЕ avg_bid AS

ВЫБЕРИТЕ символ,

трейд_тип,

AVG(цена_предложения) AS avg

ОТ market_orders

GROUP BY символ, trade_type;

Таким образом, если мы запустим оператор SELECT * FROM avg_bid;, мы увидим новый столбец trade_type, который сообщит нам, какой экземпляр в настоящее время обрабатывает трафик.

Чтобы отслеживать состояние вашего экземпляра, вы можете выполнить шаги из документации Materialise здесь:

• Материализировать облачный мониторинг

Как только результаты будут правильными, мы можем приступить к сине-зеленому развертыванию.

Обновите маршрут, чтобы он указывал на зеленый

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

Например, если имя хоста вашего экземпляра — «my-instance.materialize.cloud», вам потребуется обновить запись CNAME, указывающую на «my-instance.materialize.cloud», следующим образом:

materialize.example.com. CNAME 54321mz.materialize.cloud. # Измените это на новое имя хоста

Обратите внимание, измените 54321mz.materialize.cloud на имя хоста вашего нового экземпляра.

В случае, если вы используете общедоступного поставщика DNS, вы также можете уменьшить TTL записи CNAME до 1 часа, чтобы поставщик DNS не кэшировал запись.

Это позволит вам получить доступ к новому экземпляру через ваше собственное имя хоста: materialize.example.com сразу после распространения изменений DNS.

Проверка развертывания

Чтобы убедиться, что мы успешно подключились к новому экземпляру, попробуйте подключиться к новому экземпляру с помощью команды psql, как и раньше, используя DNS-имя (например, materialize.example.com) и выполните следующий запрос:

```sql

SELECT * FROM avg_bid;

Если вы видите столбец trade_type, значит, вы успешно подключились к новому экземпляру.

Альтернативные подходы к смене DNS

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

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

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

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

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

Обратная сторона сине-зеленых развертываний

Вот некоторые из недостатков сине-зеленой стратегии развертывания:

• Изменение DNS может занять некоторое время, чтобы распространиться

• Трафик может направляться на синий экземпляр некоторое время, прежде чем зеленый экземпляр начнет обрабатывать трафик.

• Если у вас есть Materialise Sinks, вам нужно будет спланировать, как обрабатывать данные, которые отправляются на эти приемники, пока работают два экземпляра.

• Во время развертывания вам придется иметь два экземпляра, работающих в одно и то же время, что может добавить некоторые накладные расходы.

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

Заключение

Это всего лишь краткий обзор шагов, которые необходимо предпринять для развертывания Materialise в сине-зеленой стратегии развертывания.

В этой статье мы использовали Materialise Cloud для развертывания Materialize, но этот подход будет работать с любой другой стратегией развертывания Materialise.

Если вы не являетесь участником сообщества Materialise Slack, присоединяйтесь [здесь]](https://materialize.com/s/chat).

Полезные ссылки:

• [Документация по материалам] (https://materialize.com/docs/get-started)

• Materialize Demos

• [Материализировать облако] (https://cloud.materialize.com/)

• [Материализировать Github] (https://github.com/MaterializeInc/materialize)