Унаследованные приложения (legacy code) могут быть причиной проблем, связанных с контейнеризацией. Но только потому, что они не были созданы для облачных вычислений изначально, не означает, что эти приложения не могут найти «свой дом» в контейнерах.
Контейнеры и виртуализация стали невероятно популярными технологиями в последние годы. Переносимость и простота развертывания, которые они внедрили, в сочетании с их естественной подгонкой под приложения-микросервисы, сделали контейнеры логичной основой для новых приложений. Но знаете ли вы, что контейнеры могут обеспечить также больше преимуществ для ваших устаревших приложений?
Контейнеры обеспечивают значительную более высокую эффективность использования ресурсов по сравнению с запуском приложений непосредственно на серверах. Переход на контейнерное развертывание позволяет консолидировать больше приложений на физическом или виртуальном сервере, избавив от необходимости использовать «гостевую» ОС для каждой ВМ в виртуальном ЦОДе арендатора облака и сократив расходы на стоимость лицензий ОС. Использование виртуальных машин, а тем более bare metal серверов, вместо контейнеров для одного приложения - это переплата за большой дом для одинокого человека, включая все дополнительные расходы на ипотеку, обслуживание и налоги на недвижимость, который мог бы так же комфортно жить в квартире за небольшую часть стоимости дома.
Если вы хотите получить большую эффективность и снизить затраты на работу с существующей собственной или арендованной IT-инфраструктурой, оцените, какие приложения можно перенести для работы на основе контейнеров. Чтобы помочь вам, ниже приведены пять шагов, которые можно использовать, чтобы убедиться, что конкретные приложения являются хорошими кандидатами на контейнеризацию.
1. Является ли приложение, предварительно упакованным как отдельный двоичный файл или файл JAR?
Проверьте не является ли приложение одним двоичным файлом или JAR-файлом. Если это так, его легко поместить в контейнер. Приложения Java и JAR-файлы особенно гибкие и могут быть легко преобразованы. Кроме того, контейнеризованная Java имеет еще одно преимущество - переносится конкретная среда JRE внутри контейнера. Это упрощает развертывание. Также это означает, что множество версий Java может запускаться бок о бок на одних и тех же серверах из-за наличия изоляции контейнеров.
2. Платформа, на которой ваше приложение построено, доступна в контейнеризованной версии или пакете?
Платформы, такие как Tomcat, Node.js, Drupal, Joomla и многие другие, уже доступны в виде контейнеров Docker. Многие вендоры или сообщества с открытым исходным кодом уже сделали работу для преобразования вашего приложения в контейнерную среду. Сделайте инвентаризацию разработанных приложений и проверьте, используют ли они программное обеспечение, которое доступно в контейнеризированной версии. Если это так, извлеките конфигурацию приложения, загрузите контейнерную версию платформы и настройте ту же конфигурацию для запуска в этой версии. Как только оно будет работать, вы можете повторно развернуть его гораздо быстрее в общем кластере.
3. Доступны ли какие-либо из ваших сторонних приложений в виде версии для контейнера?
Поставщики видят преимущества разработки своего программного обеспечения на основе контейнеров, и многие из них начинают предлагать контейнеризированные версии своего коммерческого программного обеспечения. Например, поставщики Hitachi, предоставляют программное обеспечение в контейнерной версии для управления SAN в дополнение к полносерверным версиям. Просто попросите у менеджеров по продажам узнать, предлагают ли они подобные версии, и как использовать их, если они это делают.
4. Является ли приложение Stateless?
Stateless app - это прикладная программа , которая не сохраняет данные клиента, сгенерированные за один сеанс, для использования в следующем сеансе с этим клиентом. Каждый сеанс выполняется, как если бы он был первым, а ответы не зависели от данных предыдущего сеанса. Напротив, stateful-приложение сохраняет данные о каждом сеансе клиента и использует эти данные в следующий раз, когда клиент делает запрос.
Когда приложение stateless, сервер не сохраняет состояние сеанса клиента. Вместо этого данные сеанса хранятся на клиенте и передаются на сервер по мере необходимости. Это важное соображение в первую очередь при разработке приложений в автономном режиме.
Распределенная архитектура, которая делает возможной горизонтальную масштабируемость в облачных вычислениях, вызвала большой интерес к stateless приложениям и их компонентам, которые могут быть легко перераспределены в случае сбоя и масштабированы при изменении нагрузки. Другая причина заключается в том, что, когда приложения stateless, они могут быть легко подключены к другим приложениям через API.
Функциональное программирование, которое часто используется для микросервисов и контейнеризации, также вызвало интерес к stateless-приложениям. Функциональное программирование - это подход к разработке программного обеспечения, который использует очень маленькие сегменты неизменяемого кода. Каждая функция выполняет свою задачу «как в первый раз», и «знает», но не зависит от других функций в программе. Поскольку все части программы stateless, программисты могут собирать функции несколькими способами, не беспокоясь о сбоях в программе.
Многие подобные веб-приложения, которые имеют уровни, которые просто выполняют обработку, являются хорошими целями, особенно те, которые основаны на Tomcat или других веб-интерфейсах. Если stateless уровни приложения могут быть отделены, они являются хорошими кандидатами на контейнеризацию, так как они получат большую гибкость.
Среди преимуществ также - более простые резервные копии и более простые изменения конфигурации приложения. Обратите внимание, что контейнеризация stateful-приложения с сохранением работоспособности все еще находится в пределах разумной досягаемости, поскольку распределенные системы хранения, такие как ceph, Portworx, и Rex-Ray, также доступны в контейнерном виде. Просто вам потребуется сделать еще несколько шагов для контейнеризации и это является целями более поздней фазы.
5. Является ли ваше приложение уже частью конвейера непрерывной интеграции и непрерывного развертывания (Continuous Integration/Continuous Deployment Pipeline)?
Если у вас уже есть приложения, которые являются частью процесса DevOps и CI / CD, вам будет проще перейти на контейнеры. Вы можете начать упаковку своих приложений в контейнеры и развернуть их на существующих серверах. Как только вы будете уверены, что ваше приложение работает правильно, вы сможете начать вводить платформы для оркестровки контейнеров и начнете понимать другие преимущества подхода, такие как устойчивость и эффективность.
Возможно, часть вашей команды программистов уже разрабатывает приложения в контейнерах, но после этого развертывает их на «голых» серверах. Если вы «сработаетесь» со своими разработчиками, чтобы внести изменения в свой существующий конвейер CI / CD, вы можете достичь гораздо большей эффективности инфраструктуры. Кроме того, контейнеры упрощают автоматизацию тестирования и оптимизацию кода, который не работает должным образом. Это особенно полезно при использовании методологии Agile.
Источник: https://dzone.com/articles/five-steps-to-determine-whether-an-app-can-be-containerized
Если Ваша компания занимается разработкой и хочет получить услугу виртуальный облачный сервер (IaaS) со скидкой 40%, тогда заполните небольшую форму и укажите промо-код: "developer40"
Предложением могут воспользоваться любые компании, зарегистрированные в РФ, основной вид деятельности которой относится к категории "Разработка программного обеспечения и консультирование в этой области".
