Что не относится к актуальным вариантам развертывания серверных приложений
Основы подготовки приложений к развертыванию (Application packaging)
«Application packaging» устоявшийся термин для названия IT сервиса в сфере поддержки конечных пользователей (EUS) во всем мире, но, практически не известный в России. Поэтому в нашей статье опишем лучшие практики, которые скрываются за данным сервисом и расскажем о том, как он может помочь снизить общую стоимость владения (TCO) программным обеспечением и, в конечном счете, уменьшить стоимость поддержки рабочих мест пользователей.
Стратегия и подходы. Снижение TCO.
Стоимость владения программным обеспечением (ПО) занимает существенную долю IT-бюджета любой современной компании, что обуславливает актуальность управления (подходами, стратегией и т.д.) как бюджетом, так и программами с целью снижения стоимости поддержки рабочих мест пользователей. Один из таких проверенных временем подходов – это Application packaging (рус. авторский перевод «Подготовка приложений к развертыванию»).
Результат подготовки приложения к развёртыванию – это пакет, содержащий одно или несколько приложений, содержащий все необходимые пользовательские, региональные, лицензионные настройки, при необходимости тюнингованный для разрешения известных проблем, в том числе с совместимостью. Как правило, у всех пакетов – единые интерфейсы (практически всегда командная строка и иногда UI) для установки и удаления, что облегчает дальнейшую эксплуатацию для Service Desk. Важно также отметить, что во время разработки пакета применяются корпоративные политики и лучшие практики (best practices) В пример приведем наиболее популярные, такие как:
ROI (Return of investments)
На сегодняшний день все топовые западные компании используют практики подготовки приложений к развертыванию (Application packaging) в своем IT. Более того, данный сервис является стандартным для любого крупного тендера, что говорит о востребованности данных услуг, его актуальности и экономической целесообразности.
Так, например, в статье JUKKA KOULETSIS: The Basics of Application Packaging приводится опыт компании Dell, где утверждается, что использование практик (сервиса) по подготовке программ к развертыванию позволяет единожды вложившись в разработку и тестирование пакета, сократить стоимость их поддержки:
Мы бы хотели поделиться опытом нашей компании и подтвердить графики, приведенные в статье, следующими примерами.
В производственном секторе мы работаем с двумя компаниями (европейскими подразделениями), изготавливающими шины. Это мировые лидеры (из ТОП-10) с более 10 тыс. рабочих станций. Только за счет использования практик application packaging нам удалось довести состав команды развертывания до 1 человека (без учета бекапов). Другими словами, мы смогли компенсировать 80% затрат на подготовку приложений уже на этапе развертывания, при этом на начальном этапе количество инцидентов, связанных с приложениями, удалось сократить на 45% соответственно:
Аналогичную динамику с данными одного порядка мы наблюдали при внедрении сервиса в банковской сфере (два крупных европейских банка и их филиалы), двух крупных компаний из строительной отрасли и целого ряда других компаний в странах Скандинавии, что еще раз подтверждает универсальность практик.
Конечно же, конкретные графики будут зависеть как от особенностей среды, в которой применяется подход по подготовке пакетов, так и от провайдера сервиса, так как у поставщиков услуг, профессионально занимающихся Application packaging, есть свои секреты и решения, но в целом, целесообразность применения практики подготовки приложений к развертыванию очевидна. За более чем 8 лет работы с иностранными заказчиками по всему миру у нас сформировались свои секреты в области управления приложениями, которые мы готовы применить и для заказчиков из России.
Технологии и решения
На сегодняшний день для корпоративного и частного секторов представлено огромное множество технологий и программ для подготовки программного обеспечения к развертыванию.
Поэтому в определённых ситуациях становиться выгодной конвертация установочных файлов формата Exe (Setup.exe) в формат Windows Installer. Для этих целей мы используем решение AdminStudio Repackager от Flexera Software.
На сегодняшний день все большую популярность получают технологии виртуализации программ, в частности, решение AppV от Microsoft, которой мы посвятили отдельную статью на Хабре. Технологии виртуализации с каждым годом завоевывают все большую популярность. Уже на сегодняшний день половина наших крупных европейских заказчиков используют AppV как основную технологию, а Windows Installer применяют там, где не применим AppV. Последний особенно выгоден, где повсеместно используются терминальные среды. Для них Application packaging за счет управления конфликтами (проактивного поиска и устранения) и проактивного анализа возможности использования на терминальных средах позволяет не только получить все плюсы, описанные выше, но и более рационально использовать физические сервера, сократить количество ребилдов серверов и общее количество инцидентов и проблем, то есть снизить стоимость владения до 25% процентов. Для управления конфликтами (conflict management) мы используем свои разработки, а также решение Application Manager от Flexera Software.
Более того, использование сервисов по подготовке приложений к развертыванию позволяет существенно снизить риски и стоимость миграций в новые среды (например, из десктопных решений на терминальные или на новую ОС). Так, сейчас мы активно работаем над миграцией наших некоторых клиентов на Windows 10. И для тех заказчиков, где уже используется Application packaging – мы делаем эту работу за считанные недели/месяцы в зависимости от размера компании. Там же, где Application packaging еще не используется, время миграции – это самый лучший период для внедрения сервиса, попутно проведя оптимизацию состава программного обеспечения, что по факту может сэкономить в разы только бюджет на миграцию, не говоря уже о дальнейшей стоимости поддержки. О том, какие программы используются для рационализации, чуть ниже в этом материале.
В области предварительной подготовки ПО мы работаем уже много лет с передовыми компаниями по всему миру, и за данный период разработали множество своих решений, которые позволяют нам быть эффективными и оказывать первоклассный сервис. Вот некоторые из наших решений:
Совокупность решений сторонних вендоров и наших решений позволяет нам оказывать сервисы на высоком уровне даже для зрелых IT-инфраструктур за адекватную стоимость.
Обладая значительным опытом в сфере управления приложениями и в подготовке приложений для развертывания, мы используем наработанные практики не только при работе с европейскими заказчиками, но и распространяем опыт на работу компаний в нашей стране. Данная статья, судя по всему, одна из первых, описывающих сервис Application packaging на русском языке и мы надеемся, что она окажет свое влияние на популяризацию знаний в этой области в России.
Быстрое развертывание любого приложения вместе с 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. Пропущены некоторые шаги настройки, поэтому, если вы хотите попробовать полный пример самостоятельно, пожалуйста, ознакомьтесь с нашими руководствами по началу работы. В этом примере мы развернем приложение в Kubernetes. Создадим рядом с приложением файл waypoint.hcl. Этот файл описывает все этапы жизненного цикла приложения.
Сборка, развертывание, релиз
Файл конфигурации 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.
Специально для хабровчан мы сделали промокод HABR, дающий дополнительную скидку 10% к скидке указанной на баннере.
Сервер приложений и веб-сервер
Сервер приложений (Application Sever) – это сервер промежуточного программного обеспечения (ПО, middleware). Это системное ПО, которое располагается между операционной системой (ОС) с одной стороны, внешними ресурсами, например, системой управления базами данных СУБД (DBMS, Database Management System) или Интернет-сервисами, с другой стороны, и приложениями пользователя.
Сервер приложений действует как хост для бизнес-логики пользователя, он также обеспечивает доступ к бизнес-приложениям и задаёт их параметры для пользователя. Сервер приложений должен устойчиво работать независимо от изменений трафика клиентских запросов, отказов оборудования и ПО, распределённого характера масштабных приложений, а также возможной разнородности форматов данных и ресурсов их обработки.
Внешние ресурсы, например, СУБД и Интернет-сервисы, предоставляют веб-серверы (Web Server). Они отвечает на запросы пользователя по доставке контента.
Серверы приложений иногда путают с веб-серверами. У них есть общие функции, но есть и много различий. Понимание этих различий поможет правильно сконфигурировать программное обеспечение и инфраструктуру оборудования для нужд предприятия.
Различия между серверами приложений и веб-серверами
Параметр сравнения
Веб-сервер
Сервер приложений
Основная цель
Хостинг сайтов и ответы на простые веб-запросы
Хостинг приложений и обеспечение сложных взаимосвязей бизнес-логики
Тип контента
Доставка только статического контента HTML
Доставка как статического, так и динамического контента
Протоколы
HTTP/HTTPS и другие протоколы
Соединение с приложениями
Подключения к базами данных
К статическим базам данных
К базам данных приложений
Типичные клиенты
Веб- и мобильные приложения, а также веб-браузеры
Многопотоковая обработка
Поддерживается параллельная обработка многих запросов
Потребление ресурсов
Трафик не потребляет много ресурсов
Процессы с интенсивным потреблением ресурсов
Контейнеры
Веб-контейнеры (сервлеты, JSP, JSF, веб-сервисы), контейнеры клиентских приложений (DI, безопасность)
Ёмкость
Результат запроса
Гипертекстовый документ, отображающий информацию в браузере
Файлы, содержащие данные, по требованию клиента
Что такое веб-сервер?
Веб-сервер – это компьютерная система, которая хранит, обрабатывает и доставляет веб-страницы для клиента. Клиентом в этом случае является веб-браузер на компьютере пользователя или мобильное приложение на его смартфоне или планшете. В зависимости от настроек, веб-сервер может хранить один или множество веб-сайтов. Веб-серверы доставляют клиенту только статический HTML-контент, такой как документы, изображения, видео, шрифты и пр.
Обычно веб-серверы не обрабатывают динамический контент и не позволяют программировать свои программы. Веб-серверы работают по протоколу передачи гипертекста HTTP (Hypertext Transfer Protocol) или HTTPS (Hypertext Transfer Protocol Secure). Однако, опционально, некоторые веб-серверы позволяют добавлять компоненты, позволяющие работать с динамическим контентом.
Что такое сервер приложений?
Сервер приложений (Application Server, App-Server) – это программный комплекс, предназначенный для доставки контента и средств его представления для клиентских приложений. Клиентами могут быть веб-приложения, браузеры или мобильные приложения.
Серверы приложений предоставляют для клиентов бизнес-логику, то есть, преобразуют данные в динамический контент и обеспечивают функционал приложений. Примеры такого контента:
Сервер приложений – это связующее звено между клиентом и программным кодом физического сервера. Типичные задачи сервера приложений:
Серверы приложений также обрабатывают такие процессы, как кластеризация, исправление отказов и балансировка нагрузки.
Рис. 2. Сервер приложений.
Что общего у веб-сервера и сервера приложений
Если в качестве основного приложения клиента выступает веб-браузер, то различия между двумя типами серверов размываются. Большинство веб-серверов имеют плагины на основе скриптов (ASP, JSP, JSF, PHP, Perl, и пр.), которые позволяют генерировать динамический контент.
Поскольку в сценариях применения у веб-серверов и серверов приложений много общего, то наиболее популярные серверы являются гибридами этих двух типов. Гибридное решение, совмещающее свойства обеих серверов, обеспечивает максимальную скорость и функциональность системы.
Для хостинга веб-сайта со статическим контентом лучше всего подходят объектные СХД.
Наиболее популярные веб-серверы
Nginx – веб-сервер с открытым кодом, который может работать как обратный прокси-сервер (reverse proxy). Обратный прокси-сервер работает не в сторону клиента, фильтруя контент и обеспечивая безопасность, а в сторону веб-сервера. Nginx имеет архитектуру, управляемую событиями EDA (event-driven architecture), позволяющую создавать и определять события, реагировать на события, измерять потребление ресурсов реакции на событие. Кроме того, он может выполнять функции прокси-сервера электронной почты и балансировщика нагрузки и может выполнять одновременно множество запросов.
HTTP-сервер Apache – популярный веб-сервер на ОС Linux, который входит с стек LAMP (Linux, Apache, MySQL, PHP). На этом веб-сервере работает около 40% Интернет-сайтов. Apache имеет богатый выбор функций, включая htaccess, FTP, HTTP/2, ограничение полосы пропускания для определённых клиентов (throttling), балансировку нагрузки и пр.
Microsoft IIS (Internet Information Services) – свободно распространяемый пакет серверного ПО, представляющий собой проприетарный набор служб от компании Microsoft. IIS распространяется с пакетом Windows NT. IIS поддерживает протоколы HTTP, HTTPS, FTP, POP3, SMTP, NNTP.
Jetty – проект свободного ПО, который может обеспечивать функции НТТР-сервера, НТТР-клиента и контейнера javax.servlet. Хотя Jetty разрабатывался как веб-сервер, он также может служить платформой для межмашинных коммуникаций (М2М).
LiteSpeed имеет хорошую производительность и масштабируемость, широкий диапазон функций и простую в использовании консоль администратора. Это четвёртый по популярности веб-сервер, который, по состоянию на декабрь 2020 года, использовался для 8.1% веб-сайтов.
Наиболее популярные серверы приложений
Apache Tomcat – контейнер сервлетов с открытым исходным кодом на языке Java. Tomcat позволяет запускать веб-приложения и содержит ряд программ для автоматического конфигурирования и часто используется вместе с конфигурационным файлом Apache HTTPD (Apache Hypertext Transfer Protocol Server daemon). Tomcat может исполнять Java-сервлеты, доставлять клиентам страницы в кодах Java Server Page, и может обслуживать приложения Java EE (Java Enterprise Edition).
Сервер Oracle WebLogic – сервер для распределённых приложений с использованием стандартов Java EE. Он полностью интегрирован с продуктами и облачными сервисами Oracle.
Glassfish – сервер приложений с открытым кодом на Java EE, который поддерживает Java-сервлеты, а также спецификацию написания и поддержки серверных компонентов с бизнес-логикой EJB (Enterprise JavaBeans).
JBoss – сервер приложений с открытым кодом для создания, развёртывания и хостинга приложений на языке Java. JBoss может работать на разных платформах и в любой операционной системе с поддержкой Java.
Какой сервер приложений будет наиболее подходящим?
Знание различий между сервером приложений и веб-сервером помогает выбрать сервер для того или иного использования.
Другим подходом может быть добавление функционала в веб-сервер при помощи плагинов. В этом случает, веб-сервер может использовать технологию программирования на стороне сервера (server-side), такую как скрипты CGI, JSP, сервлеты, ASP (Active Server Pages) или JavaScript на стороне сервера.
Использование обоих типов сервера в одной системе
Часто и веб-сервер, и сервер приложений, развёртывают в одной системе. Это даёт возможность предоставлять клиентам как статический, так и динамический контент. В этом случае, веб-сервер становится подсистемой сервера приложений и все их сервисы работают на одной и той же программно-аппаратной платформе.
Преимуществом такого подхода является более высокая производительность системы. В каждом типе сервера максимально используются их преимущества. Простые веб-запросы будут сразу же обрабатываться веб-сервером и при этом не будет снижаться производительность сервера приложений.
Например, на сайте Интернет-магазина должна предоставляться информация о ценах в реальном времени. Обычно на сайте также есть форма для приобретения товара. Когда пользователь посылает запрос, веб-страница магазина ищет актуальную цену и выдаёт результат в виде HTML-страницы. Эту функциональность можно обеспечить как при помощи сервера приложений, так и при помощи веб-сервера с соответствующими плагинами. Возможно несколько сценариев.
Сценарий 1. Использование только веб-сервера с плагинами
Веб-сервер предоставляет функционал Интернет-магазина:
Сценарий 2. Использование как веб-сервера, так и сервера приложений
Сервер приложений хранит бизнес-логику для поиска цены. Веб-сервер делегирует ему генерацию ответа, скрипт вызывает сервис поиска в сервере приложений, и затем формулирует ответ HTML.
Размещение логики поиска цены в сервере приложений позволяет использовать её различными частями приложения. В первом сценарии сервис поиска цены не может повторно использоваться, поскольку данные встроены в HTML-страницу.
Рис. 3. Использование как веб-сервера, так и сервера приложений.
Заключение
Пересечение функций веб-сервера и сервера приложений означает, что каждый сценарий применения может иметь несколько решений. Можно применять веб-серверы и серверы приложений отдельно, а можно использовать их комбинацию.
Однако, не каждая конфигурация будет равноценной по параметрам работы и потреблению ресурсов, хотя и будет выполнять возложенные на неё функции. Знание различий между двумя типами серверов поможет сэкономить средства, облегчить масштабирование системы и повысить производительность.