Способы развертывания программных приложений

Окружения развёртывания программного обеспечения

Только что опубликовал в русской википедии перевод статьи Deployment environment.

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

В развёртывании программного обеспечения, окружение или ярус является компьютерной системой в которой компьютерная программа или компонент программного обеспечения развёртывается и выполняется. В простом случае, такое развёртывание и немедленное выполнение программы на той же машине, может выполнятся в единственном окружении, однако при промышленной разработке используется разделение на development окружение (‘окружение разрабочика’) (где делаются исходные изменения) и production окружение (которое используют конечные пользователи); часто с промежуточными этапами (‘stages’) посередине. Этот структурированный процесс управления релизами может иметь фазы deployment (rollout, ‘развёртывание’, ‘выкатка’), testing (‘тестирование’), и rollback (‘откат’) в случае проблем.

Окружения могут существенно отличаться в размерах: deployment окружение это обычно рабочая станция отдельного разработчика, в то время как production окружение может быть сетью множества географически разнесённых машин в случае с дата-центров, или виртуальными машинами в случае с облачными решениями. Код, данные и конфигурация могут быть развёрнуты паралельно, и нет необходимости связи с соответствующим ярусом — например, pre-production код может подсоединяться к production БД.

Архитектуры

Архитектуры развёртывания существенно разнятся, но в целом, ярусы начинаются с develpment (DEV) и заканчиваются production (PROD). Распространённой 4-х ярусной архитектурой является каскад ярусов deployment, testing, model, production (DEV, TEST, MODL, PROD) c деплоем софта на каждом ярусе по очереди. Другое распространённое окружение это Quality Control (QC), для приёмочного тестирования; песочница или экспериментальное окружение (EXP), для экспериментов не предназначенных для передачи в продакшен; и Disaster Recovery (‘аварийное восстановление’), для предоставления возможности немедленного отката в случае проблемы с продакшеном. Другой распространённой архитектурой является deployment, testing, acceptance and production (DTAP).

Такая разбивка в частности подходит для серверных программ, когда сервера работают в удаленных дата-центрах; для кода который работает на конечных устройствах пользователя, например приложений (apps) или клиентов, последний ярус обозначают как окружение пользователя (USER) или локальное окружение (LOCAL).

Точные определения и границы между окружениями варьируется — test может рассматриваться как часть dev, приёмка может рассматриваться как часть test, часть stage, или быть отдельной и так далее. Основные ярусы обрабатываются в определённом порядке, с новыми релизами при развёртывании (rolled out или pushed) на каждом. Ярусы experimental и recovery, если представлены, являются внешними к этому процессу — experimental релизы являются конечными, в то время как recovery являются обычно старыми или дублирующими версиями production, развёрнутыми после production. В случае проблем, в последнем случае можно сделать roll back к старому релизу, и большинство просто выкатывают старый релиз таким же способом как новый. Последний шаг, деплой в production («pushing to prod») самый чувствительный, т.к. здесь любые проблемы напрямую влияют на пользователя. По этой причине это часто управляется по разному, но как минимум мониторится более тщательно, и в некоторых случаях имеется фаза отката или простого переключения. Лучше всего избегать названия вроде Quality Assurance (QA); QA не означает тестирование софта. Тестирование важно, но это отличается от QA.

Иногда развёртывание выполняется вне обычного процесса, главным образом для предоставления срочных или небольших изменений, без необходимости полного релиза. Это может быть один патч, большой service pack или небольшой hotfix.

Окружения могут быть очень разных размеров: разработка обычно идёт на индивидуальных машинах разработчиков (хотя это могут быть тысячи разработчиков), в то время как продакшеном могут быть тысячи географически распределённых машин; тестирование и QC может быть маленьгим и большим, зависеть от предоставленных ресурсов, а staging может варьироваться от единичной машины (подобно canary) до точных дубликатов продакшена.

Окружения

Local

Development/Thunk

Сервер разработки выступающий как песочница где разработчик может выполнить unit-тестирование

Integration

Основа для построения CI, или для тестирования сайд-эффектов разработчиком

Testing/Test/QC/Internal Acceptance

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

Staging/Stage/Model/Pre-production/External-Client Acceptance/Demo

Production/Live

Серверы конечных пользователей/клиентов

Окружение разработчика

Окружение разработчика (dev) является окружением в котором софт разрабатывается, это часто просто компьютер разработчика. Это отличается от конечной целевой среды некоторыми вещами — цель может не быть стационарным компьютером (это может быть смартфон, встроенная система, самоуправляемый транспорт датацентра и т.д.), и даже если это стационарный компьютер, окружение разработчика будет включать инструменты разработчика например компилятор, IDE, различные или дополнительные версии библиотек и вспомогательного софта, и т.д., что не представлено в пользовательском окружении.

В контексте управления ревизиями, особенно при участии множества разработчиков, проводятся более тонкие различия: разработчик имеет рабочую копию исходного текста на своей машине, и изменения вносятся в репозиторий, будучи закомиченными либо в «стволе», либо в ветке, в зависимости от методологии разработки. Окружение на отдельной рабочей станции, на которой изменения отработаны и опробованы, может называться локальным окружением или песочницей. Сборка копии исходного кода репозитория в чистом окружении является отдельным этапом интеграции (интеграция разрозненных изменений), и это окружение может называться интеграционным окружением или окружением разработчика; при непрерывной интеграции это делается часто, так же часто, как и для каждой ревизии. Понятие уровня исходного кода звучащее как «фиксация (коммит) изменения в репозитории» с последующей сборкой «ствола» или ветки — соответствует переходу от локального (индивидуального окружения разработчика) к интеграции (чистой сборке); плохой релиз на этом этапе означает, что изменение сломало сборку, а откат релиза соответствует либо откату всех сделанных изменений, либо отмене только ломающего изменения, если это возможно.

Тестовое окружение

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

Различные типы тестирования предполагают различные типы тестовых сред, некоторые или все из которых могут быть виртуализированы для обеспечения быстрого параллельного тестирования. Например, автоматизированные тесты пользовательского интерфейса могут выполняться на нескольких виртуальных операционных системах и дисплеях (реальных или виртуальных). Для проведения тестов производительности может потребоваться нормализованная базовая конфигурация аппаратного обеспечения, чтобы результаты тестов производительности можно было сравнивать с течением времени. Тестирование на доступность или устойчивость может основываться на симуляторах отказов в виртуальных аппаратных средствах и виртуальных сетях.

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

Staging

Stage или stage-окружение — это среда для тестирования, которая в точности похожа на продакшен-окружение. Она стремится как можно точнее отразить реальное продакшен-окружение и может подключаться к другим продакшен-сервисам и данным, таким как базы данных. Например, серверы будут работать на удаленных машинах, а не локально (как на рабочей станции разработчика во время разработки, или на одной тестовой машине во время тестирования), чтобы проверить влияние сети на систему.

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

Другим важным использованием stage-окружения является тестирование производительности, в частности нагрузочное тестирование, так как это часто чувствительно для окружения.

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

Продакшен-окружение

Продакшен-окружение также известно как live (в частности в применении к серверам) так как это окружение, с которым непосредственно взаимодействуют пользователи.

Развертывание в производственной среде является наиболее чувствительным шагом; это может осуществляться путем непосредственного развертывания нового кода (перезаписывания старого кода, так что только одна копия представлена в один момент времени), или путем развертывания изменения конфигурации. Это может принимать различные формы: параллельное развертывание новой версии кода и переключение на неё с изменением конфигурации; развертывание новой версии кода рядом со старым с соответствующим «флагом нового функционала», и последующее переключение на новую версию с изменением конфигурации, которая выполнит переключение этого «флага»; или развертывание отдельных серверов (один выполняет старый код, другой — новый) с перенаправлением трафика со старого на новый с изменением конфигурации на уровне маршрутизации трафика. Всё это, в свою очередь, может быть применено одновременно или выборочно, и на разных этапах.

Развертывание новой версии обычно требует перезапуска, если только нет возможности горячего переключения, и поэтому требует либо прерывания обслуживания (обычно это пользовательское ПО, когда приложения должны быть перезагружены), либо дублирования — постепенного перезапуска экземпляров «за спиной» у балансировщика нагрузки, либо заблаговременного запуска новых серверов с последующим простым перенаправлением трафика на новые сервера.

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

Источник

Быстрое развертывание любого приложения вместе с Waypoint

К публикуемым в нашем блоге авторским статьям и переводным материалам про лайфхаки/интересные находки мы решили добавить разбор нового проекта. Waypoint — опенсорсный проект, предоставляющий разработчикам последовательный рабочий процесс сборки, развертывания и релиза приложений на любой платформе. Waypoint позволяет разработчикам провести свои приложения от разработки до производственной среды в одном файле и развертывать приложения с помощью одной команды: waypoint up . Waypoint из коробки поддерживает Kubernetes, HashiCorp Nomad, Amazon ECS, Google Cloud Run, экземпляры контейнеров Azure, Docker, Buildpacks и не только. Читайте дальше, чтобы увидеть небольшой пример, узнать больше о функциях Waypoint и о проблемах, которые решает инструмент.

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

Упрощение развертывания

Waypoint был создан нами по одной простой причине: разработчики хотят просто развертывать приложения. У HashiCorp есть возможность работать со всеми типами организаций и отдельных лиц нашего сообщества, что ставит нас перед проблемами, с которыми сталкиваются разработчики при развертывании приложений и в разрезе доступности для пользователей. Мы общаемся с десятками отдельных пользователей каждый день через GitHub Issues, дискуссионные форумы, электронную почту и т.д. Каждую неделю мы встречаемся более чем с 500 компаниями, чтобы обсудить их текущие разработки и операционные проблемы.

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

Другая проблема, которую мы увидели, зависит от приложения, ведь инструменты часто самые разные: Docker и kubectl для Kubernetes, HashiCorp Packer и Terraform для виртуальных машин, свои инструменты у каждой бессерверной платформы и т.д. Эта фрагментация снова создает проблему обучения отдельного человека. Для команд это уже проблемы последовательности и сложности.

С помощью Waypoint мы стремимся решить эти две проблемы. Waypoint предоставляет одну простую команду для развертывания любого приложения: «waypoint up». Рабочий процесс одинаков для любой платформы: Kubernetes, Nomad, EC2, Google Cloud Run и еще более десятка других будет поддерживаться к моменту запуска. Waypoint расширяется с помощью плагинов для любой логики сборки, развертывания и релиза. Разработчики просто хотят развертывать приложения. Waypoint просто делает это.

Функциональность

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

• waypoint up: единственная команда для сборки, развертывания и релиза приложения. Waypoint использует файл конфигурации, хранящийся вместе с кодом приложения, для определения того, как будет работать. Подробнее о жизненном цикле приложения Waypoint рассказывается в документации Waypoint.
• URL-адреса развертывания и приложения: Разворачиваемые с помощью Waypoint приложения получают общедоступный URL waypoint.run с действующим сертификатом TLS, который генерируется Let’s Encrypt. Используйте этот адрес, чтобы быстро просмотреть развернутые приложения и поделиться ими с другими людьми.
• Выполнение команд: выполняйте команды в контексте развертывания через waypoint exec. Вы можете использовать exec для открытия оболочки в вашем приложении, а через нее выполнять отладку, миграцию и другие задачи. Здесь можно узнать больше о команде waypoint exec.
• Логи: Waypoint предоставляет доступ к моментальному снимку журналов вашего приложения в режиме реального времени. Эти журналы полезны, когда вам нужно отладить поведение развивающегося приложения. Однако они не заменяют комплексные решения для логирования, такие как Datadog или Splunk. Логи агрегируются и доступны через CLI и веб-интерфейс. Здесь можно узнать больше о логах.
• Веб-интерфейс: в дополнение к простому и мощному CLI, в Waypoint есть веб-интерфейс, позволяющий просматривать сборки, развертывания и релизы проектов и приложений. Сегодня веб-интерфейс можно только читать. Мы непрерывно разрабатываем его и расширим функциональность в будущем. Более того, в графическом интерфейсе будут подсказки о том, как использовать интерфейс командной строки
• Плагины: логика сборки, развертывания и выпуска полностью расширяема с помощью плагинов. Waypoint поставляется с более чем десятком встроенных плагинов, и любой желающий может расширить функциональность Waypoint, написав свой собственный плагин.

Пример рабочего процесса

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

Сборка, развертывание, релиз

Файл конфигурации Waypoint описывает три основных этапа жизненного цикла приложения: сборку, развертывание и релиз.

• Сборка берет исходный код приложения и конвертирует в артефакт. Процесс сборки может включать опциональную конфигурацию реестра для отправки собранного артефакта в реестр таким образом, чтобы он был доступен платформам развертывания. Например, на этом этапе исходный код конвертируется в образ Docker, EC2 AMI и т.д.

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

Релиз активирует развертывание и открывает его основному трафику. В будущем мы добавим в Waypoint поддержку продвижения приложений между средами, откат развертываний и релизов и постепенное перемещение трафика между серверами после релиза.

Поднимаем Waypoint

Команда waypoint up выполняет сборку, развертывание и релиз приложения. В конце выводится один или несколько адресов, по которым доступно приложение. Неважно, какое это приложение и для какой платформы, вы всегда можете ввести в терминал waypoint up для развертывания.

Можно выполнять этапы жизненного цикла отдельно друг от друга. Это полезно при взаимодействии с Github Actions и инструментами CI/CD, подобными CricleCI и Jenkins. Узнать больше об автоматизации рабочего процесса приложения с помощью Waypoint можно здесь.

Адреса приложения и развертывания

Развернутые с помощью Waypoint приложения получают общедоступный URL вида waypoint.run с действительным сертификатом TLS, автоматически сгенерированным Let’s Encrypt. Используйте этот адрес, чтобы быстро посмотреть развернутые приложения и поделиться ими. Мы предоставляем этот URL через бесплатный общедоступный сервис компании HashiCorp. Функция необязательна и может быть отключена. В примере выше наш URL recently-pleasant-duck—v1.waypoint.run. Обратите внимание, что этот адрес уже не работает, приложение выполнялось только для этого поста в блоге. Вы можете посмотреть определенную версию развертывания по ссылке вида recently-pleasant-duck—vN.waypoint.run, где N — номер версии развертывания. Эта функция очень полезна, чтобы поделиться предрелизной версией вашего приложения с вашей командой.

Логирование в Waypoint

Waypoint дает доступ к моментальному снимку логов приложения в режиме реального времени. Эти логи полезны, когда нужно отладить поведение развивающегося приложения. Однако они не заменяют комплексные решения для логирования. Логи агрегируются и доступны для просмотра через интерфейс командной строки и веб-интерфейс. Эта функция логов работает вне зависимости от платформы. Используете ли вы Kubernetes, EC2, Google Cloud Run или другую платформу, вы можете согласовано просматривать логи. С помощью пользовательского интерфейса можно просматривать логи нескольких развернутых на разных платформах приложений.

Waypoint exec

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

Другие возможности

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

Waypoint и существующие приложения

Если у вас уже есть приложение и рабочий процесс развертывания, вы можете почувствовать сомнение в том, сможете ли использовать…. Мы не ждем, что команды разработки немедленно перестроят и с нуля перестроят свой рабочий процесс для Waypoint. Но у нас есть плагин docker pull и возможность локального выполнения, позволяющая адаптировать Waypoint для приложения с уже настроенным рабочим процессом. Кроме того, у нас есть документация, которая описывает интеграцию Waypoint в другие CI: CircleCI или Jenkins. Эта функция позволяет просмотреть историю развертывания в интерфейсе Waypoint, выполнять команду exec, логирование, конфигурацию приложения и не только это. Приложив немного усилий, вы получаете преимущества Waypoint, пока обдумываете, хотите ли перейти на более управляемый плагин. Когда у вас много приложений, этот подход позволяет сочетать рабочие процессы и сравнивать их.

Полная расширяемость плагинами

Логика жизненного цикла полностью расширяемая. Waypoint работает на той же системе плагинов, что и Terraform. мы полагаем, что написать плагин для Waypoint так же просто (если не проще), чем для Terraform. В Waypoint встроено более десятка плагинов с самого начала. Мы надеемся и ожидаем, что со временем, с помощью сообщества открытого ПО, это число резко возрастет. У Terraform при запуске было около 6 провайдеров. Сегодня у Terraform 300 провайдеров. Мы верим, что такое возможно и для развертывания приложений. Если вам интересно написать плагин, пожалуйста, прочитайте наше руководство для авторов плагинов и посмотрите исходный код встроенных плагинов Waypoint 0.1 на Github.

• Попробуйте Waypoint, посетив страницу начала работы, чтобы посмотреть демонстрацию быстрого старта или выполнить инструкции, которые ссылаются на примеры приложений NodeJS, Python, Ruby, Java и многих других языках, фреймворках и облачных платформах.
• Дайте нам обратную связь. Waypoint как проект все еще находится на ранней стадии, и мы хотели бы обратиться к сообществу за обратной связью через дискуссионный форум HashiCorp. Вы также можете посетить страницу сообщества и узнать, как внести свой вклад в проект.
• Напишите плагин. Мы будем рады вашей помощи в продолжении улучшения Waypoint. Если у вас есть идея плагина Waypoint, опубликуйте ее на GitHub или предложите ее на форуме Waypoint в HashiCorp.
• Поделитесь своим приложением. Если вы развернули приложение с помощью Waypoint, сделайте снимок экрана, где оно работает, с URL-адресом Waypoint, и опубликуйте в Twitter с тегом #WaypointUp HashiCorp. Если вы хотите, чтобы другие люди увидели работу приложения, поделитесь URL Waypoint. Мы выделим приложения сообщества в ближайшие недели.

Специально для хабровчан мы сделали промокод HABR, дающий дополнительную скидку 10% к скидке указанной на баннере.

Источник