Подходы к развертыванию веб-приложений

Question

В настоящее время наш продукт представляет собой веб-приложение с SQL Сервером в качестве СУБД, ASP. NET бэкэндом и классическим c HTML / JavaScript / CSS интерфейсом. Продукт активно развивается, и каждый месяц мы должны развертывать новую версию его в производственной среде.

Во время этого развертывания мы обновляем все перечисленные выше компоненты (применяем некоторые SQL скрипты, обновляем двоичные файлы и клиент files), но мы развертываем только дельту (набор файлов, которые были изменены с момента последнего выпуска). У него есть некоторые преимущества, например, мы не сбрасываем пользовательские данные / конфигурации / настройки клиента.

Теперь мы собираемся перемещаться внутри облаков, например Azure, AWS, и т.д. c. Отрегулируйте архитектуру продукта, чтобы она соответствовала Docker / Kubernetes, и предоставьте продукт как SaaS.

И теперь сам вопрос: «Какой подход к развертыванию рекомендуется в облаках?» Можем ли мы продолжать применять только дельту? Или нам нужно реорганизовать процесс, чтобы всегда развертывать с нуля?

Если есть какие-то ресурсы Inte rnet, которые я пропустил, поделитесь.

Answer 1

Этот вопрос чрезвычайно широк, но, возможно, некоторые пояснения в любом случае могут направить вас в правильном направлении:

Развертывание исходного кода (например, применение дельты) и развертывание контейнеров - это два очень разных направления в том смысле, что вы вложения в течение всего SLD C МОЖЕТ существенно отличаться. Некоторые конвейеры / продукты тестирования в значительной степени (или исключительно) сосредоточены на работе с одним или другим. Конечно, будут инструменты, которые справятся с обоими.

Они также различаются проблемами, которые они пытаются решить, и имеют некоторые плюсы и минусы:

Развертывания исходного кода / Применять различия:

• Подходит для небольшие команды и быстрое развертывание, поскольку они просты в понимании и настройке.
• Начинает представлять риск, когда вам нужно обновить ОС хоста или зависимости приложений
• Начинает представлять риск, когда хост в производстве начинает дрейфовать (иметь больше разных файлов, чем ожидалось) более значительно time

У Slack есть хорошее описание своего опыта здесь .

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

• Обеспечивает изоляцию от приложения (пространство разработчика) и ОС хоста (пространство sysadmin / ops). Обычно это означает, что они могут работать друг с другом независимо.
• Дает «артефакт», который не меняется между развертываниями, ie контейнер с тегом v1 всегда будет таким же, если вы не сделаете что-то действительно необычное. Вы не можете этого гарантировать.
• Практика изоляции компонентов без состояния делает автомасштабирование этих компонентов очень простым, и в конечном итоге вы можете потратить больше времени на более сложные (обычно с сохранением состояния).
• Представляет новая абстракция с новыми проблемами, в которые ваша команда должна дорасти. Конвейеры тестирования, инструменты разработки, архитектуры мониторинга / входа в систему могут со временем нуждаться в корректировке, а это связано с расходами и рисками.
• Контейнеры с отслеживанием состояния вряд ли можно решить (ie размещение существующей базы данных в контейнере может быть неожиданной проблемой).

Для работы с Kubernetes вам необходимо иметь контейнерное приложение. Это не означает, что вам нужно поместить весь продукт в контейнер на ночь. Разделение внешнего интерфейса для развертывания с помощью cloudfront / s3 и контейнеризация приложения без сохранения состояния заставят вас замочить ноги. * The Devops Handbook

Accelerate

Эффективные Devops

SRE book