Бесперебойный деплой микрофронтендов с Kubernetes: как настроить

Фронтенд-разработка может жить без независимого деплоя, пока у нее не больше 7 микрофронтендов. Но, чем выше число, тем сильнее страдают процессы. Наша команда в Mindbox прошла через это с Octopus, когда деплоила в Yandex Cloud S3. Причем на все обновления был один свободный бакет. Заливаешь код в мастер, а в это время то же самое делают еще пять разработчиков. Скапливается очередь, код еле ползет, а через час деплой вообще обваливается — Octopus не справился с нагрузкой. Пока чинишь это, оказывается, что твои обновления уже попали в продакшен заодно с чужими. 

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

В этой статье собран опыт платформы автоматизации маркетинга Mindbox по реформированию фронтенда:

• Kubernetes вместо Yandex Cloud S3: деплоим микрофронтенды без сбоев

• Автоматизированный вывод метаданных: экономим ресурсы разработки

• Постепенный переход: меняем деплой без вреда для пользователей

• Хот-тестинг: ускоряем обновление фронтенда

• Советы: как улучшить деплой без микрофронтендов и Kubernetes

Исходные данные

Команды: 68 бэкенд-разработчиков, 12 фронтенд, 10 SRE.

Бэкенд: CDP (customer data platform) как основной монолит и пара десятков микросервисов вокруг него.

Фронтенд:

• старый — смесь C# Razor и React, который выдается из монолитного бэка;

• новые микрофронтенды на React, которые разделены по бизнес-доменам и выдаются из двух бакетов в Yandex Cloud S3 — А и B.

• Репозитории: код разных МКФ хранится в отдельных репозиториях.

• CI/CD для деплоя: GitHub actions и Octopus.

Kubernetes вместо Yandex Cloud S3: деплоим микрофронтенды без сбоев

В Mindbox долгое время микрофронтенды деплоились созависимо. После пуша в мастер Github Action упаковывал обновленный код в бандл. Octopus подхватывал этот бандл и забирал из хранилища другие — с актуальным кодом всех микрофронтендов. Дальше он проверял, какой из бакетов в Yandex Cloud S3 сейчас свободен — А или B. Предположим, А. Тогда Octopus выгружал в него бандлы и направлял туда трафик.

У такой системы два недостатка.

Первый в том, что Octopus сбоит, когда число микрофронтендов переваливает за 7 и все они деплоятся одновременно. Он не умеет работать с микрофронтендами последовательно. Вместо того, чтобы целиком обновить один, а потом браться за следующий, Octopus постоянно переключается между ними. Из-за этого деплой зависает — приходится перезапускать его вручную. Вот как выглядит эта проблема на примере двух приложений — C и D:

1. Запущен деплой обновлений приложения C. 

2. Octopus направляет код приложения C в свободный бакет A.

3. Запущен деплой обновлений приложения D. Обновления C еще не выгрузились в бакет.

4. Octopus бросает C, переключается на D и несет его код в тот же бакет A, который по-прежнему свободен.

5. Код приложения D выгружается в бакет A.

6. Octopus возвращается к деплою C. Но к тому времени бакет A уже занят, код C не может в него попасть и деплой прерывается.

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

1. В продакшене — версия 1 приложения C и 1 — приложения D. 

2. Запускается деплой новых версий — C 2 и D 2. Код обеих направляется в единственный свободный бакет А.

3. Octopus сначала выкладывает С 2 и попутно собирает весь актуальный код, какой находит, в том числе D 2.

4. В продакшене — версии C 2 и D 2.

5. Octopus собирается выложить D 2, но ее деплой уже обвалился, поскольку бакет А был занят. Тем не менее код D 2 ранее попал в продакшен вместе с C 2.

Чем больше обновлений так пересекаются, тем сложнее отследить их статус.

При деплое версии 2 приложения C Octopus выложил актуальный код всех микрофронтендов. В продакшен попала версия 2 приложения D, хотя ее деплой прервался. Из-за этого статус обновлений D 2 отобразился неверно

Чтобы микрофронтенды выкладывались независимо и без сбоев, можно запустить деплой в Kubernetes. Схема следующая. Когда обновляется код микрофронтенда, Github Action все так же собирает его в бандл. А дальше бандл упаковывается не в папку, а в докер-контейнер с Nginx внутри. Octopus переносит контейнер в Kubernetes, где он запускается в нужном окружении.

apiVersion: apps/v1 kind: Deployment metadata:   name: {{ .Values.name }}-deployment-{{ .Values.environment }} spec:   replicas: {{ .Values.services.replicas }}   selector:     matchLabels:       product: {{ .Values.name }}              # Помечаем, что этот под содержит в себе код микрофронтенда.       microfrontend-pod: {{ .Values.isMicrofrontendPod | quote }}   template:     metadata:       labels:         product: {{ .Values.name }}         microfrontend-pod: {{ .Values.isMicrofrontendPod | quote  }}         deploy-environment: {{ .Values.environment }}     spec:       imagePullSecrets:         - name: image-pull-{{ .Values.environment }}       containers:         - name: {{ .Values.name }}-pod           image: "image-repo/{{ .Values.name }}:{{ $.Values.packageVersion }}"           imagePullPolicy: Always           resources:             requests:               cpu: {{ .Values.services.resources.requests.cpu }}               memory: {{ .Values.services.resources.requests.memory }}             limits:               cpu: {{ .Values.services.resources.limits.cpu }}               memory: {{ .Values.services.resources.limits.memory }}           ports:             - containerPort: 8080       tolerations:         - key: dedicated           operator: Equal           value: mindbox-worker           effect: NoSchedule         - key: dedicated           operator: Equal           value: mindbox-worker           effect: PreferNoSchedule --- apiVersion: v1 kind: Service metadata:   name: {{ .Values.name }}-service-{{ .Values.environment }} spec:   selector:     product: {{ .Values.name }}     microfrontend-pod: {{ .Values.isMicrofrontendPod | quote }}     deploy-environment: {{ .Values.environment }}   ports:     - name: main       protocol: TCP       port: 8080       targetPort: 8080 --- apiVersion: traefik.containo.us/v1alpha1 kind: IngressRoute metadata:   name: {{ .Values.name }}-ingressroute-{{ .Values.environment }}-index-html   labels:     mindbox/traefik: common spec:   entryPoints:     - websecure   routes:   # Собираем URL, по которому будет отвечать под.    # Нам нужно, чтобы он отвечал по всем запросам по определенному URL    # и заголовку "environment", который проставляется в HAProxy.     - match: HostRegexp(`{tenant:.*}.{{ .Values.host }}`) && (PathPrefix(`/{{ .Values.namespace }}`)) && Headers(`environment`, `{{ .Values.environment }}`)       kind: Rule       priority: 50       services:         - port: 8080           name: frontend-initial-builder-service-{{ .Values.environment }}   tls:     options:       name: agrade-tls-options       namespace: traefik-common --- apiVersion: traefik.containo.us/v1alpha1 kind: IngressRoute metadata:   name: {{ .Values.name }}-ingressroute-{{ .Values.environment }}   labels:     mindbox/traefik: common spec:   entryPoints:     - websecure   routes:   # Собираем URL, по которому будет отвечать под.    # Нам нужно, чтобы он отвечал по всем запросам по определенному URL    # и заголовку "environment", который проставляется в HAProxy.     - match: HostRegexp(`{tenant:.*}.{{ .Values.host }}`) && PathPrefix(`/v2_static/{{ regexReplaceAll "-" .Values.name  "_"}}/`) && Headers(`environment`, `{{ .Values.environment }}`)       kind: Rule       priority: 50       services:         - name: {{ .Values.name }}-service-{{ .Values.environment }}           port: 8080   tls:     options:       name: agrade-tls-options       namespace: traefik-common 

Helm chart пода микрофронтенда

То есть вместо двух бакетов в Yandex Cloud S3 мы получаем десяток изолированных контейнеров в Kubernetes и таким образом решаем проблему с деплоем большого количества микрофронтендов. Их можно обновлять независимо друг от друга.

Автоматизированный вывод метаданных: экономим ресурсы разработки

Каждый микрофронтенд предоставляет свой файл с метаданными. На основе этих файлов выстраивается роутинг и наполняется основное меню страницы. Если браузер станет загружать их все по отдельности, чтобы вывести меню пользователю, это займет много времени. Чтобы ускорить процесс, все метаданные нужно предварительно объединить в один файл.

С прежним деплоем Octopus собирал метаданные одновременно с релизом кода. Он запускал скрипт, в котором был список микрофронтендов, и этот скрипт находил файлы с метаданными — remoteEntry.js. Затем Octopus склеивал все в один файл initial.js и создавал index.html со ссылкой на него. Все это вместе с бандлами отправлялось в бакет в Yandex Cloud S3. По запросу пользователя браузер выводил index.html с актуальными метаданными.

В Kubernetes сервис Initial builder собирает метаданные только тех микрофронтендов, которые находятся в рантайме. Можно было бы, как раньше, использовать сервис с вложенным списком микрофронтендов и обновлять этот список вручную. Но мы вместо этого автоматизировали процесс с помощью специального класса сервисов под названием headless services. Теперь все докер-контейнеры помечены тегами. Initial builder с помощью headless services считывает их и находит контейнеры с данными, которые запросил пользователь. Дальше Initial builder достает файлы с метаданными и склеивает в один, который затем передает по назначению.

export const getAdressessOfPods = async (req: Request, res: Response, next: NextFunction) => {   // Получаем из переменных среды имена сервисов и сортируем их,    // чтобы опрашивать в нужной последовательности.   const headlessServices = getSortedHeadlessNames(Object.keys(process.env));   const reachedModules = [];    const headlessServicePromises =     headlessServices.length === 0       ? [getAddressesOfMcf()]       : headlessServices.map((service) => getAddressesOfMcf(process.env[service]));    const modules = await Promise.allSettled([...headlessServicePromises]);    for (const module of modules) {     if (module.status === 'rejected') {       logMessage(`can't get mcfAddressArray; reason: ${module.reason}`, {         host: req.hostname,       });       continue;     }      reachedModules.push(...module.value);   }    if (reachedModules.length === 0) {     const errorMessage = `no headless services found. headlessServices: ${headlessServices}`;     logException(new Error(errorMessage));     res.status(500);     res.send('no modules found');     return;   }      // Складываем полученные адреса в locals,    // чтобы получить их в другой middleware.   res.locals[RES_LOCALS.mcfAddresses] = reachedModules;    next(); };

Получение списка подов микрофронтендов

const createRegExForReplace = (MCFName: string) =>   new RegExp(`\\/\\*!\\s@mcf\\sstart\\s${MCFName}\\s\\*\\/.+\\/*!\\s@mcf\\send\\s${MCFName}\\s\\*\\/`);  export const buildNewInitialJs = ({ modulesArray }: BuildNewInitialJsArgs) => {   let newInitial = initEmptyModulesList;    if (modulesArray.length === 0) {     throw new Error('No MCF array are provided');   }    modulesArray.forEach((moduleCode) => {     const safeNoduleCode = deleteNewLines(moduleCode);     const name = REGEX_FOR_FIND_MCF_NAME.exec(safeNoduleCode);     const moduleName = name?.groups?.['MCF_NAME'];      if (!moduleName) {       logException(INVALID_REMOTE_ENTRY_ERROR);       return;     }      const isMcfNameExistInInitialJs = newInitial.search(createRegExForReplace(moduleName));      if (isMcfNameExistInInitialJs === -1) {       newInitial = newInitial.concat(stub, safeNoduleCode, stub, initModule(moduleName));     } else {       newInitial = newInitial.replace(createRegExForReplace(moduleName), safeNoduleCode);     }   });    newInitial = newInitial.concat(stub, loadModules);    return pasteNewLines(newInitial); };  export const handleInitialJs = async (_: Request, res: Response) => {   res.type('.js');   try {     // Получаем файлы с метаданными из каждого пода.     const modulesArray = await getRemoteEntries(res.locals[RES_LOCALS.mcfAddresses]);      // Собираем массив с метаданными в один файл и отдаем его пользователю.     const newInitialJs = buildNewInitialJs({       modulesArray,     });     res.send(newInitialJs);   } catch (error) {     Sentry.captureException(error);     res.status(500).send("Can't build initial.js");   } };

Создание единого файла с метаданными initial.js

Постепенный переход: меняем деплой без вреда для пользователей

Чтобы переход от старого деплоя к новому не сказался на пользователях, мы вводили изменения постепенно.

Какое-то время Initial builder не собирал файл с метаданными целиком, а обновлял тот, что собирался в Yandex Cloud S3 старым способом. То есть Initial builder получал запрос от пользователя и скачивал из Yandex Cloud S3 файл с метаданными. Дальше он с помощью headless services находил и скачивал все доступные файлы с метаданными микрофронтендов. В начале каждого такого файла есть системное имя — точно такое же указано в исходном файле из Yandex Cloud S3. С помощью регулярного выражения фрагменты метаданных в старом файле заменялись на новые. После этого браузер получал и выводил актуальные метаданные.

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

Хот-тестинг: ускоряем обновление фронтенда

Хот-тестинг во фронтенде — это нулевая стадия тестирования, которая позволяет с ходу показать изменения продакт-менеджерам и получить обратную связь.

Изначально код тестировали в четырех окружениях:

• стейджинг — рабочая среда с одним проектом, на котором все проверяют гипотезы и смотрят результат;

• стандард — проект с очищаемой базой, только для е2е-тестов;

• бета — 10% клиентов, которые готовы мириться с возможными багами ради того, чтобы получить обновления первыми;

• стейбл — все остальные клиенты.

Чтобы ускорить процесс, мы ввели для фронтенда что-то вроде престейджинга — хот-тестинг. Когда мы открываем pull request, GitHub Action собирает код в бандл, упаковывает в докер-образ и ставит на него тег, равный хешу ветки. Дальше докер-образ запускается в Kubernetes, где отличается от докер-контейнеров только тем, что отвечает на запросы от одного определенного домена. Чтобы этот домен получил все актуальные данные плюс обновление, в GitHub Action собирается отдельный под Initial builder, для которого указывается два headless service — основной и дополнительный. Основной находит любые докер-контейнеры в стейджинге, а дополнительный — только новый докер-образ.

# Поднимаем для тестирования отдельный Initial builder. --- apiVersion: apps/v1 kind: Deployment metadata:   name: frontend-initial-builder-ht-HASH_PAYLOAD   namespace: microfrontends spec:   selector:     matchLabels:       app: frontend-initial-builder-ht-HASH_PAYLOAD   replicas: 1   template:     metadata:       labels:         app: frontend-initial-builder-ht-HASH_PAYLOAD       annotations:         commit_sha: CI_COMMIT_SHA     spec:       imagePullSecrets:         - name: image-pull-staging       containers:         - name: initial-builder-pod           imagePullPolicy: Always           image: image-repo/frontend-initial-builder:latest           resources:             requests:               cpu: "500m"               memory: "300M"             limits:               cpu: "1000m"               memory: "500M"           ports:           - containerPort: TARGET_PORT           env: # Передаем через переменные окружения названия headless service для поиска МКФ: # первый - базовый, который получит весь код на стейджинг.             - name: headless_service_1               value: headless-mcf-finder-staging  # Второй – дополнительный, который найдет только приложение, которое тестируем.                          - name: headless_service_2               value: headless-mcf-finder-ht-HASH_PAYLOAD             - name: ENVIRONMENT               value: staging       tolerations:         - key: dedicated           operator: Equal           value: mindbox-worker           effect: NoSchedule         - key: dedicated           operator: Equal           value: mindbox-worker           effect: PreferNoSchedule --- apiVersion: v1 kind: Service metadata:   name: frontend-initial-builder-ht-s-HASH_PAYLOAD   namespace: microfrontends spec:   selector:     app: frontend-initial-builder-ht-HASH_PAYLOAD   ports:     - name: main       protocol: TCP       port: TARGET_PORT       targetPort: TARGET_PORT 

Helm chart для поднятия специальной версии Initial builder для в режиме хот-тестинга

# Поднимаем под с кодом МКФ, который хотим протестировать. # В названии пода HASH_PAYLOAD - уникальный хеш, который используется для навигации трафика.  # Этот же хеш в домене, по которому будет открываться тестовый проект. --- apiVersion: apps/v1 kind: Deployment metadata:   name: hot-testing-HASH_PAYLOAD   namespace: microfrontends spec:   selector:     matchLabels:       app: hot-testing-HASH_PAYLOAD   replicas: 1   template:     metadata:       labels:         app: hot-testing-HASH_PAYLOAD       annotations:         commit_sha: CI_COMMIT_SHA     spec:       imagePullSecrets:         - name: image-pull-staging       containers:       - name: hot-testing         imagePullPolicy: Always         image: DOCKER_IMAGE         resources:           requests:             cpu: "30m"             memory: "200M"           limits:             cpu: "45m"             memory: "300M"         ports:         - containerPort: TARGET_PORT       tolerations:         - key: dedicated           operator: Equal           value: mindbox-worker           effect: NoSchedule         - key: dedicated           operator: Equal           value: mindbox-worker           effect: PreferNoSchedule --- apiVersion: v1 kind: Service metadata:   name: hot-testing-service-HASH_PAYLOAD   namespace: microfrontends spec:   selector:     app: hot-testing-HASH_PAYLOAD   ports:     - name: main       protocol: TCP       port: TARGET_PORT       targetPort: TARGET_PORT --- # Headless service, который надет под с тестируемым приложением. apiVersion: v1 kind: Service metadata:   name: headless-mcf-finder-ht-HASH_PAYLOAD   namespace: microfrontends spec:   clusterIP: None   selector:     app: hot-testing-HASH_PAYLOAD   ports:     - name: main       protocol: TCP       port: TARGET_PORT

Helm chart для поднятия пода с тестируемым МКФ

# Чтобы хот-тестинг выглядел как полноценное приложение,  # часть трафика перенаправляем на домен со стейджингом.  apiVersion: v1 kind: Service metadata:   name: hot-testing-base-service-HASH_PAYLOAD   namespace: microfrontends spec:   type: ExternalName   externalName: BASE_PROJECT_URL   ports:     - name: main       port: 443       protocol: TCP       targetPort: 443  ---  # Распределяем трафик по подам. apiVersion: traefik.containo.us/v1alpha1 kind: IngressRoute metadata:   name: hot-testing-ingressroute-HASH_PAYLOAD   namespace: microfrontends spec:   entryPoints:     - websecure   routes:      # Весь трафик, который должен обрабатывать тестируемый МКФ, направляем в под, который подняли.    # Ищем его по имени с хешем.   - match: >-       Host(`hot-testing-HASH_PAYLOAD-staging.mindbox.ru`)       && PathPrefix(`/v2_static/PROJECT_FOLDER/`)      kind: Rule     services:       - name: hot-testing-service-HASH_PAYLOAD         port: TARGET_PORT      # Запросы за метаданными направляем в под с Initial builder, который подняли для теста.   # За счет этого мы получаем метаданные, с замененной частью.   - match: >-       Host(`hot-testing-HASH_PAYLOAD-staging.mindbox.ru`)       && PathPrefix(`/v2_static/initial_builder/`)      kind: Rule     services:       - name: frontend-initial-builder-ht-s-HASH_PAYLOAD         port: TARGET_PORT      # Весь остальной трафик направляем на обычный домен стейджинга.   - match: Host(`hot-testing-HASH_PAYLOAD-staging.mindbox.ru`)     kind: Rule     services:       - name: hot-testing-base-service-HASH_PAYLOAD         port: 443         passHostHeader: false    tls:     options:       name: agrade-tls-options       namespace: traefik-common

Helm chart для маршрутизации трафика в хот-тестинге

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

Запрос метаданных проходит по цепочке:

1. Трафик направляется в под Initial builder, созданный для тестового домена.

2. Initial builder с помощью основного headless service собирает метаданные всех микрофронтендов, а с помощью дополнительного — метаданные тестового микрофронтенда.

3. В общем файле с метаданными Initial builder заменяет один из фрагментов на более новый — от тестового микрофронтенда.

4. Итоговый файл initial.js уходит к пользователю.

В то же время под с тестовым микрофронтендом выдает пользователю код тестируемого приложения, а другие поды — весь остальной код.

В результате продакт-менеджер видит страницу со свежими обновлениями.

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

Советы: как улучшить деплой без микрофронтендов и Kubernetes

Если у вас еще нет микрофронтендов и весь фронтенд — это один большой монолит, можете позаимствовать из статьи хот-тестинг. Собирайте отдельную версию статики и отдавайте ее по запросу с каким-нибудь маркером. У нас это хеш в поддомене, но можно сделать и квер-параметры или заголовки.

Если у вас есть микрофронтенды и они деплоятся созависимо, можно создать много мелких подов в Kubernetes и настроить независимый деплой. В дальнейшем можно реализовать, например, АB-тесты разной статики, если это нужно бизнесу.

Внедрить независимый деплой можно и без Kubernetes — используйте AWS Lambda или отдельные инстансы приложений на виртуальных компьютерах.