Развертывание приложений в облаке
После проектирования и разработки облачного приложения его можно переместить на этап развертывания для выпуска клиентам. Развертывание может включать несколько этапов, в каждом из которых проводится ряд проверок, гарантирующих выполнение целей приложения.
Перед развертыванием облачного приложения в рабочей среде полезно иметь контрольный список, который поможет оценить ваше приложение по списку основных и необходимых рекомендаций. Примеры включают контрольный список развертывания от AWS и Azure. Многие поставщики облачных услуг предоставляют полный список средств и служб, которые помогают в развертывании, например в этом документе от Azure.
Процесс развертывания
Развертывание облачного приложения — это итеративный процесс, который начинается с окончания разработки и продолжается вплоть до выпуска приложения на рабочих ресурсах.
Рис. 1. Процесс развертывания кода
Для облачных разработчиков характерно поддерживать несколько одновременно работающих версий своих приложений, чтобы разделить развертывание своего приложения на различные этапы.
- Тестирование
- Промежуточная
- Производственный экземпляр
Каждый из трех этапов в идеале должен иметь идентичные ресурсы и конфигурацию, что позволяет разработчикам тестировать и развертывать приложения и сводить к минимуму вероятность несоответствий из-за изменений, возникающих в результате изменений среды и конфигурации.
Конвейерное изменение приложения
В типичном сценарии разработки гибких приложений (как показано на предыдущем рисунке) приложения обслуживаются коллективом инженеров и разработчиков, которые работают над проблемами и ошибками с помощью какого-либо механизма отслеживания проблем. Изменения в коде поддерживаются в системе репозитория кода (скажем, svn, mercurial или git), где размещаются отдельные ветви для выпуска кода. После передачи изменений кода, проверок и утверждений код можно передать по конвейеру на этапы тестирования, промежуточного процесса и рабочей среды. Это можно сделать несколькими способами.
Пользовательские скрипты: разработчики могут использовать пользовательские скрипты для извлечения последней версии кода и выполнения определенных команд для сборки приложения и его внедрения в рабочее состояние.
Предварительно подготовленные образы виртуальных машин: разработчики также могут подготавливать и настраивать виртуальную машину со всеми необходимыми средами и программным обеспечением для развертывания приложения. После настройки можно создать моментальный снимок виртуальной машины и экспортировать ее в образ. Этот образ можно передать в различные облачные системы оркестрации для автоматического развертывания и настройки для рабочего развертывания.
Системы непрерывной интеграции. Для упрощения различных задач, участвующих в развертывании, средства непрерывной интеграции (CI) можно использовать для автоматизации задач (например, получения последней версии из репозитория, создания двоичных файлов приложений и выполнения тестовых случаев), которые необходимо выполнить на различных компьютерах, составляющих рабочую инфраструктуру. Примерами популярных средств CI являются Jenkins, Bamboo и Travis. Azure Pipelines — это средство непрерывной интеграции Azure, предназначенное для работы с развертываниями в Azure.
Управление временем простоя
Некоторые изменения в приложении могут потребовать частичной или полной остановки служб приложений для внесения изменений в серверную часть приложения. Как правило, разработчики должны запланировать определенное время суток, чтобы свести к минимуму перерывы в работе клиентов приложения. Приложения, разработанные для непрерывной интеграции, могут выполнять эти изменения в рабочих системах с минимальным или полным отсутствием перерывов в работе клиентов приложения.
Избыточность и отказоустойчивость
Рекомендации по развертыванию приложений обычно предполагают, что облачная инфраструктура является эфемерной и может стать недоступной или быть изменена в любой момент. Например, виртуальные машины, развернутые в службе IaaS, могут быть запланированы для завершения по усмотрению поставщика облачных служб в зависимости от типа соглашения об уровне обслуживания.
В приложениях нужно воздержаться от жесткого программирования или предположения о наличии статических конечных точек для различных компонентов, таких как базы данных и конечные точки хранилища. Хорошо спроектированные приложения в идеале используют API службы для запроса и обнаружения ресурсов и подключения к ним динамически.
Катастрофические сбои в ресурсах или подключении могут произойти в любой момент. Критические приложения должны быть спроектированы с учетом таких сбоев и обеспечения избыточности при отказе.
Многие поставщики облачных служб разбивают центры обработки данных на регионы и зоны. Регион — это конкретное географическое расположение, в котором полностью размещается центр обработки данных, а зоны — это отдельные секции центра обработки данных, которые изолированы для отказоустойчивости. Например, две или более зоны в центре обработки данных могут иметь отдельные инфраструктуры питания, охлаждения и подключения, чтобы сбой в одной зоне не повлиял на работу инфраструктуры в другой. Сведения о регионах и зонах обычно предоставляются поставщиками облачных служб клиентам и разработчикам для проектирования и разработки приложений, которые могут использовать это свойство изоляции.
Таким образом, разработчики могут настроить приложение для использования ресурсов в нескольких регионах или зонах, чтобы повысить доступность своего приложения и быть устойчивым к сбоям в зоне или регионе. Им потребуется настроить системы, которые могут маршрутизировать и балансировать трафик между регионами и зонами. DNS-серверы также можно настроить, чтобы на запросы поиска домена они возвращали определенные IP-адреса в конкретной зоне в зависимости от того, откуда был создан запрос. Это предоставляет метод балансировки нагрузки на основе географической близости клиентов.
Безопасность и усиление защиты в рабочей среде
Выполнение интернет-приложений в общедоступном облаке нужно выполнять с осторожностью. Так как диапазоны IP-адресов облачных служб — это хорошо известные лакомые кусочки, важно убедиться, что все приложения, развернутые в облаке, следуют рекомендациям по обеспечению безопасности и усилению защиты конечных точек и интерфейсов. Ниже приведены некоторые основные принципы, которые следует соблюдать.
- Все программное обеспечение следует переключать в рабочий режим. Большинство программного обеспечения поддерживает режим отладки для локального тестирования и "рабочий режим" для реальных развертываний. Обычно приложения в режиме отладки могут отправлять большое количество информации злоумышленникам, которые отправляют неправильно сформированные входные данные и, следовательно, представляют собой простую цель для разведывательных атак хакеров. Независимо от того, используете ли вы веб-платформу, такую как Django и Rails, или базу данных, такую как Oracle, важно следовать соответствующим рекомендациям по развертыванию рабочих приложений.
- Административный доступ к общедоступным службам должен быть ограничен конкретными внутренними IP-адресами. Убедитесь, что администраторы не могут напрямую войти в критически важный ресурс из Интернета, не посещая внутреннюю панель запуска. Настройте брандмауэры с помощью правил на основе IP-адресов и портов, чтобы разрешить минимальный набор необходимых прав доступа, особенно через SSH и другие средства удаленного подключения.
- Следуйте принципу минимальных привилегий. Запускайте все службы от имени наименее привилегированного пользователя, который может выполнять требуемую роль. Ограничьте использование учетных данных пользователя root отдельными ручными входами системных администраторов, которым необходимо выполнить отладку или настройку некоторых критических проблем в системе. Это также касается доступа к базам данных и административным панелям. В общем случае доступ должен быть защищен с помощью длинной пары открытого и закрытого ключей, а эта пара ключей должна быть безопасно сохранена в зашифрованном расположении с ограниченным доступом. Ко всем паролям должны предъявляться строгие требования к стойкости.
- Используйте хорошо известные техники и инструменты защиты для систем обнаружения и предотвращения вторжений (IDS/IPS), управления информационной безопасностью и событиями (SIEM), брандмауэров уровня приложения и систем защиты от вредоносных программ.
- Настройте расписание установки исправлений, совпадающее с выпусками исправлений поставщика систем, которые вы используете. Часто поставщики, такие как Майкрософт, имеют жесткий цикл выпуска исправлений.