Развертывание программного обеспечения или приложений — это процесс, необходимый для того, чтобы сделать новое или обновленное программное обеспечение доступным для пользователей. Сегодня большинство организаций автоматизируют по крайней мере некоторые этапы развертывания новых приложений. Многие организации применяют модель развертывания, известную как непрерывная поставка, при которой выпуски программного обеспечения постоянно находятся в состоянии готовности к развертыванию и могут быть полностью автоматически развернуты в рабочей среде одним нажатием кнопки.
Развертывание программного обеспечения обычно включает в себя такие действия, как подготовка сред, установка и тестирование программного обеспечения. Развертывание также должно включать постоянный мониторинг работоспособности и производительности недавно развернутых сред и возможность отката развертывания, если что-то пойдет не так.
Развертывание программного обеспечения и выпуск программного обеспечения могут показаться синонимами, но они выполняют две разные функции. Выпуск программного обеспечения — это итеративный процесс разработки приложения, а развертывание программного обеспечения — процесс развертывания приложения. Новый выпуск может включать дополнительные функции, исправления ошибок или исправления безопасности. Развертывание программного обеспечения включает размещение программного обеспечения в ИТ-среде или доставку его конечным пользователям.
Software Deployment Checklist (Контрольный список)
Хотя каждая модель развертывания программного обеспечения работает по-разному, каждый процесс развертывания должен состоять из нескольких этапов. Это краткий контрольный список для эффективного развертывания:
1. Preparation
Вот важные шаги, которые необходимо реализовать на этапе планирования:
- Сообщите всем заинтересованным сторонам — очень важно информировать всех пользователей о предстоящем развертывании и учить пользователей, как использовать новые развернутые функции.
- Определите соавторов — жизненный цикл разработки программного обеспечения (SDLC) — это совместный процесс, в котором могут участвовать разрозненные команды. Вы должны определить и проинформировать всех соавторов, чтобы свести к минимуму трения между командами разработки, эксплуатации и безопасности.
- Перечислите сторонние инструменты — идентификация всех инструментов и требований, связанных с процессом развертывания, может помочь вам убедиться, что все сотрудники знают, как их эффективно использовать, и свести к минимуму любые проблемы, связанные с этими инструментами.
- Настройте среду тестирования — всегда тестируйте свое программное обеспечение, прежде чем внедрять новый продукт для конечных пользователей.
- Разработайте четкий процесс развертывания — общайтесь с командой, чтобы убедиться, что процесс развертывания понятен всем участникам и все находятся на одной волне.
- Создайте план отката — используйте этот план, если во время развертывания возникнут критические проблемы. Стратегии прогрессивной доставки позволяют беспрепятственно и автоматически откатывать развертывания (подробнее см. ниже).
- Определите показатели производительности — общие показатели включают использование памяти и ЦП, а также время ответа на запрос. Вы можете использовать эти базовые метрики и настраиваемые KPI для измерения эффективности развертывания. В прогрессивной доставке вы даже можете использовать эти метрики для автоматического определения успешности или неудачи развертывания.
2. Testing
Этап тестирования проверяет ваше программное обеспечение перед развертыванием. Вот важные аспекты, которые необходимо охватить на этом этапе:
- Напишите модульные тесты — цель состоит в том, чтобы протестировать небольшую часть программного обеспечения, чтобы проверить его поведение независимо от других частей. Модульный тест проходит успешно, если результат соответствует требованиям, и не проходит, если дает противоречивый результат.
- Интегрируйте тесты с процессом CI — интегрируйте свои модульные тесты в общий репозиторий, чтобы автоматически создавать и проверять каждую часть. Выполнение этого перед развертыванием позволяет вам легче исправлять и удалять ошибки, чем исправление в рабочей среде.
- Разверните тесты в промежуточной среде — создайте точную копию целевой рабочей среды и используйте ее для тестирования обновлений, кода и других аспектов, чтобы убедиться, что программное обеспечение работает должным образом перед развертыванием.
- Запустите сквозные тесты для поиска регрессии — цель состоит в том, чтобы протестировать рабочий процесс приложения от начала до конца, пройдя все операции, которые оно может выполнять, чтобы проверить, как оно работает с другими компонентами, такими как сетевое подключение и оборудование.
- Приемочное тестирование — на этом последнем этапе процесса тестирования программное обеспечение проверяется заинтересованными сторонами или реальными пользователями. Их отзывы помогают определить, готово ли программное обеспечение к производству или нет. В процессе непрерывной доставки это может быть решено с помощью концепции приемных шлюзов, в которых автоматизированное развертывание ожидает ручного утверждения, а затем продолжается.
- Используйте дымовые тесты — создайте специальный набор тестов для запуска его в рабочей среде ПОСЛЕ развертывания, чтобы убедиться, что только что выпущенное программное обеспечение не имеет регрессий.
3. Deployment and Release Process
Этот заключительный этап охватывает важные аспекты реализации развертывания и включает в себя:
- Развертывание в рабочей среде — отправка обновления в производственную среду, в которой пользователи взаимодействуют с программным обеспечением.
- Мониторинг производительности продукта — используйте заранее определенные ключевые показатели эффективности для мониторинга производительности продукта, проверяя такие аспекты, как ошибки HTTP и производительность базы данных.
- Мониторинг работоспособности среды — используйте инструменты мониторинга для выявления потенциальных проблем, связанных с программной средой, такой как операционная система, система баз данных и компилятор.
- Выполняйте автоматические откаты — используйте дымовые тесты и метрики, чтобы решить, был ли выпуск успешным или нет, и автоматически переходите к предыдущему выпуску, если есть проблемы.
- Отслеживайте журналы — вы можете использовать журналы, чтобы получить представление о том, как программное обеспечение работает на компонентах инфраструктуры, расследовать ошибки и выявлять угрозы безопасности.
- Документирование версии выпуска и примечания — сохранение копий новых версий, создаваемых при внесении изменений в продукт, помогает поддерживать согласованность.
Software Deployment Strategies
Вот некоторые из основных стратегий развертывания программного обеспечения:
1. Базовое развертывание (Basic Deployment)
Базовое развертывание включает в себя одновременное обновление всех узлов в целевой среде для внедрения новой версии. Эта стратегия уязвима для сбоев и затрудняет откат обновления. Хотя базовое развертывание является быстрым, простым и экономичным, оно сопряжено с наибольшим риском и поэтому не подходит для критически важных бизнес-приложений.
2. Последовательное развертывание (Rolling Deployment)
Скользящее развертывание включает в себя обновление подмножества экземпляров приложения (вместо полного обновления базового развертывания). Размер окна относится к количеству экземпляров, обновляемых за раз. Чем больше кластер, тем больше должен быть размер окна.
Последовательные обновления обеспечивают гибкость при масштабировании новой версии перед уменьшением масштаба старой версии (т. е. резкое обновление) и ограничивают количество экземпляров приложения, остающихся недоступными во время масштабирования.
Такой подход исключает простои, поскольку трафик перенаправляется на новую версию только тогда, когда она готова. Это также снижает риск развертывания, поскольку ошибочные обновления затрагивают ограниченное число пользователей. Однако откат может быть медленным, поскольку он также требует постепенного подхода. Новые развертывания должны быть обратно совместимыми, поскольку они сосуществуют со старыми версиями. Также важно убедиться, что балансировщик нагрузки поддерживает фиксированные сеансы, если приложению требуется сохранение сеансов.
3. Мультисервисное развертывание (Multi-Service Deployment)
Мультисервисное развертывание одновременно обновляет каждый узел в целевой среде несколькими сервисами. Этот подход похож на базовое развертывание, но сопряжен с меньшим риском и полезен для приложений с зависимостями версий или служб. Хотя мультисервисные развертывания являются быстрыми и экономичными, они уязвимы для сбоев и медленно откатываются. Эта стратегия также может усложнить тестирование, проверку и управление зависимостями служб.
4. Сине-зеленое развертывание (Blue/Green Deployment)
Сине-зеленое развертывание предполагает одновременное развертывание двух версий приложения. Текущая версия (синяя) и новая версия (зеленая) работают в разных средах, и в любой момент времени может быть только одна действующая версия. Синяя версия продолжает работать, пока зеленая версия проходит тестирование. Когда новое развертывание будет готово, можно безопасно переключить трафик, либо выведя из эксплуатации старую версию, либо сохранив ее для будущего отката. В некоторых случаях синяя среда становится зеленой для следующего обновления.
Синие/зеленые развертывания исключают простои и позволяют мгновенно откатываться. Изоляция синей и зеленой сред защищает динамическое развертывание от ошибок на этапе тестирования. Однако, несмотря на то, что эта стратегия развертывания менее рискованна, ее реализация обходится дороже, поскольку эксплуатационные расходы должны охватывать две среды.
Обеспечение обратной совместимости необходимо для беспрепятственного отката. Во время переключения желательно разрешить сброс соединения в текущих сеансах, чтобы обеспечить выполнение существующих запросов.
5. Канареечное развертывание (Canary Deployment)
Канареечное развертывание включает в себя поэтапный выпуск службы или приложения. На первом этапе обновление развертывается для небольшого подмножества пользователей (например, 2%). Внедрение постепенно продолжается, увеличивая область охвата до более крупных подмножеств пользователей, пока не достигнет 100 %.
Этот подход сопряжен с наименьшим риском по сравнению с любой стратегией развертывания, позволяя командам контролировать и тестировать оперативные обновления. Это позволяет оценивать производительность в реальной производственной среде, а не в смоделированной промежуточной среде. Это также исключает время простоя и обеспечивает быстрый откат.
Возможным недостатком канареечных развертываний является их медленное развертывание. Каждый инкремент релиза требует времени, требующего мониторинга в течение как минимум нескольких часов. Еще одна проблема заключается в обеспечении возможности наблюдения за стеком приложений и инфраструктурой — мониторинг часто требует усилий. Как и в случае с другими стратегиями развертывания, крайне важно обеспечить привязку сеанса и обратную совместимость, чтобы обеспечить плавный переход.
6. A/B-тестирование
A/B-тестирование включает в себя маршрутизацию небольшого подмножества пользователей к новой функциональности для сбора статистики и помощи в принятии бизнес-решений. Хотя это и не является строго стратегией развертывания, это подход к тестированию, основанный на канареечной стратегии развертывания. Компании используют A/B-тестирование, чтобы определить, какая версия функции имеет лучший коэффициент конверсии.
Этот метод — лучший способ измерить эффективность функциональности приложения. Это помогает обеспечить безопасные выпуски программного обеспечения и предсказуемый откат. Выборка целевой аудитории проста в управлении и помогает предоставить статистику вовлеченности и поведения пользователей. Однако настройка A/B-теста сложна, требует репрезентативных выборок аудитории, и может быть сложно гарантировать достоверность результатов теста. Еще одна проблема заключается в обеспечении наблюдаемости в ходе нескольких A/B-тестов.
7. Теневое развертывание (Shadow Deployment)
Теневое развертывание включает в себя выпуск двух параллельных версий программного обеспечения, разветвление входящих запросов на текущую версию и отправку их на новую версию. Этот подход помогает проверить, как новые функции справляются с производственной нагрузкой, не влияя на трафик. Когда новая версия соответствует требованиям производительности и стабильности, можно безопасно развернуть приложение.
Хотя эта стратегия узкоспециализирована и сложна в настройке, она устраняет влияние на производство, используя дублирование трафика для проверки ошибок с использованием теневых данных. Тесты очень точны, потому что они используют производственную нагрузку для создания реалистичных условий. Теневое развертывание считается подходом с низким уровнем риска и часто сочетается с другими безопасными стратегиями, такими как канареечное развертывание.
Однако теневое копирование трафика может привести к нежелательным побочным эффектам, таким как дублирование платежных транзакций. Инструменты виртуализации и заглушки могут помочь снизить этот риск для служб, изменяющих состояние или взаимодействующих со сторонними системами. Еще одним недостатком является стоимость внедрения из-за требуемого опыта и необходимости одновременного запуска двух сред.
Что такое Progressive Delivery?
Прогрессивная доставка — это парадигма разработки программного обеспечения, обеспечивающая лучший контроль над доставкой обновлений программного обеспечения. Он включает в себя создание конвейера непрерывной интеграции и непрерывной доставки (CI/CD) с несколькими гибкими методами развертывания новых версий программного продукта. Вот основные концепции прогрессивной доставки:
- Конвейеры CI/CD — автоматизируйте задачи сборки, тестирования и развертывания.
- Управление флагами функций — позволяет включать и выключать функции во время производства. Это помогает командам вносить изменения в функции в рабочей среде и быстро выпускать обновления.
- Прогрессивное развертывание — вводит такие методы, как канареечное, сине-зеленое, A/B-тестирование и развернутое развертывание. Мы рассмотрим их более подробно ниже.
5 советов для успешного развертывания программного обеспечения
Следующие рекомендации помогут вам более эффективно развертывать программное обеспечение.
Держите отдельные кластеры для производства и не-производства.
Наличие одного большого кластера для всего создает проблемы с потреблением ресурсов и безопасностью. Важно иметь как минимум два кластера, один для производственных и один для непроизводственных ресурсов. Разделение кластеров помогает предотвратить обмен данными между модулями в каждом кластере.
Эта передовая практика помогает предотвратить сценарии, в которых разработчик развертывает тестовую функцию в пространстве имен в рабочей среде кластера. Если разработчик запускает интеграционные тесты для функции, они могут повлиять на внутренние рабочие нагрузки. Использование разных пространств имен недостаточно для разделения сред.
Хотя в одном кластере возможна многопользовательская среда, для ее достижения требуются значительный опыт и усилия. Создание отдельных кластеров обычно проще. Некоторые организации создают несколько выделенных кластеров, в том числе производственные, теневые, кластеры разработчиков, инструментальные и другие специализированные кластеры. По крайней мере, производственный кластер должен быть отделен от всего остального.
Применить ограничения ресурсов.
По умолчанию при развертывании приложения в Kubernetes ограничений на ресурсы нет. Без указанных ограничений приложения могут использовать весь кластер, нарушая производительность рабочего кластера. У каждого приложения должны быть ограничения на ресурсы — разработчики могут не справиться с этим сами, но они должны знать, какие ограничения ЦП и памяти устанавливать.
При установке лимитов важно учитывать потенциальный трафик и всплески нагрузки, а не только среднее потребление. Kubernetes обеспечивает эластичность ресурсов, но важно соблюдать правильный баланс. Если предел слишком низкий, кластер может привести к сбою приложения. Если он слишком высок, кластер становится неэффективным.
Ограничения ресурсов также должны учитывать используемые языки программирования. Например, у приложений Java часто возникают проблемы с ограничением памяти. Можно автоматизировать выделение ресурсов с помощью автоматического масштабирования.
Собирайте метрики развертывания
Кластеры Kubernetes имеют распределенные службы, поддерживающие динамические приложения, поэтому важно иметь соответствующие метрики, чтобы приложения могли адаптироваться к трафику. Метрики важны для быстрого получения важной информации без kubectl, понимания шаблонов трафика и информирования об ограничениях ресурсов.
Метрики также помогают измерить успешность развертывания, обеспечивая непрерывный мониторинг производительности приложения. Отслеживание метрик в идеале должно быть частью автоматизированного рабочего процесса:
При автоматическом откате система проверяет метрики после развертывания, помечая его как выполненное или откатывая его. Установление показателей, влияющих на развертывание, может быть сложной, но важной задачей.
Реализуйте стратегию секретов.
При использовании динамических служб для обработки изменений конфигурации они (или аналогичные службы) также должны обрабатывать соответствующие секреты. Они передают секреты контейнерам во время выполнения. Важно использовать единую стратегию для обработки секретов, гарантируя, что различные типы секретов (например, секреты времени выполнения и секреты сборки) не будут перепутаны, а тестирование и разработка будут проходить гладко.
Приложениям требуются только секреты сборки во время упаковки (т. Е. Репозиторий артефактов или учетные данные хранилища файлов). Секреты времени выполнения необходимы только после развертывания (т. е. закрытые ключи, пароли базы данных и сертификаты SSL). Разработчики должны передавать приложению только необходимые секреты.
Конкретная стратегия менее важна, чем придерживаться одной стратегии. Каждая команда должна использовать одну и ту же стратегию обработки секретов во всех средах, что упрощает отслеживание секретов. Он должен быть гибким, чтобы обеспечить простоту тестирования и развертывания. В центре внимания должно быть использование секретов, а не их источник.
Автоматизируйте обновления базы данных.
Управление базой данных так же важно, как и работа с приложением. Лучше всего автоматизировать базы данных для кода приложения — это включает в себя создание конвейеров автоматического обновления для новых наборов изменений. Динамическая временная среда позволяет командам безопасно просматривать наборы изменений и код.
Стратегия автоматизации базы данных должна включать механизм отката в случае неудачного обновления. Автоматическое преобразование производственных данных в тестовые данные полезно, поскольку хранение копий производственных данных в тестовой среде менее безопасно и неэффективно. Наличие небольшого анонимного подмножества данных обеспечивает более эффективную обработку.
Прогрессивная доставка стала проще благодаря Codefresh
Codefresh — это платформа доставки программного обеспечения GitOps, основанная на проекте Argo с открытым исходным кодом. Те, кто знаком с Argo CD, могут сразу же воспользоваться надежными функциями Codefresh, а те, кто плохо знаком с непрерывной доставкой, оценят простоту и удобство настройки. Новый унифицированный пользовательский интерфейс объединяет все возможности Argo CD и Argo Rollouts в одном представлении.
Codefresh использует самоуверенный, но гибкий подход к доставке программного обеспечения. Чтобы развернуть приложение, просто определите источник манифестов git и установите цель развертывания. Выполнение этого из пользовательского интерфейса зафиксирует конфигурацию в git. Попав в git, Codefresh автоматически обнаружит приложение и развернет его.
Прогрессивная поставка долгое время была недоступна командам разработчиков из-за сложных требований. На платформе Codefresh стратегии прогрессивной доставки, такие как канареечное или сине-зеленое развертывание, можно просто определить декларативным образом. Эти прогрессивные стратегии доставки могут значительно снизить риск развертывания новых изменений за счет простого автоматического обнаружения проблем и возврата к предыдущим стабильным версиям.
Ниже вы можете увидеть, как в Codefresh автоматически управляется канареечное развертывание.