Будучи инженером облачных технологий, который увлекается разработкой приложений, я недавно задумался над тем, как превращать локальные прототипы/приложения в ценные инструменты, доступные другим членам организации и особенно полезные в корпоративных средах. В этой статье я покажу, как легко можно запустить такие инструменты в облаке!
Зачем это нужно?
Часто бывает так, что талантливый программист или инженер натыкается на полезную библиотеку, фреймворк или инструмент, создает очень эффектную демо-версию, показывает ее своей команде — и на этом все заканчивается. Почему? Это может быть связано с целым рядом факторов, включая:
- неопределенность в отношении затрат;
- отсутствие идей по запуску инструмента в работу;
- неуверенность в учете всех ключевых моментов.
Цель этой статьи — доказать, что выбрать фреймворк, создать с ним приложение и доставить его конечным пользователям можно довольно легко. В данном случае нашим выбором будет Streamlit — популярный фреймворк, помогающий создавать веб-приложения для визуализации данных.
Смысл статьи заключается в том, чтобы предложить отличный способ создания приложений, который недостаточно используется. На самом деле большинство SaaS/PaaS-инструментов, таких как Power BI и Dynamics, подойдут вам в ряде случаев — будь то создание дашбордов, разработка приложения типа CRUD или чего-то еще. Однако если вы хотите использовать действительно крутые приложения (и при этом легко их создавать) и делать их доступными для других людей, читайте дальше!
Что такое Streamlit и почему его стоит использовать?
Лучшее описание этого инструмента дано на сайте Streamlit: это фантастическая библиотека для разработки веб-приложений, предназначенных для взаимодействия с данными.
Лично мне Streamlit нравится по двум причинам.
- Streamlit проще в использовании, чем многие другие инструменты. Это очень простая библиотека по созданию приложений для работы с данными. В нее можно очень легко включать компоненты, созданные в других библиотеках, таких как Seaborn и Altair.
- Streamlit имеет презентабельный вид. Большинство пользователей библиотеки считают, что в ней есть je ne sais quoi (фр. — нечто, невыразимое словами, но моментально покоряющее, убеждающее в качестве). Streamlit легко использовать благодаря высокому качеству доступной документации.
Следует подчеркнуть, что ни один инструмент, библиотека или фреймворк не является панацеей для решения всех проблем. Какую библиотеку выбрать и когда — это отдельный разговор, и мы не будем заострять на нем внимание. То, что будет продемонстрировано здесь, применимо и к другим фреймворкам на других языках.
Как запустить приложение?
На сайте Streamlit есть отличный контент для быстрого запуска и обучения. Предлагаемая там галерея показывает, насколько творческим может быть подход (и демонстрирует некоторые из тех элементов, о которых я говорил ранее). Кроме того, там есть отличная документация и рекомендации по созданию решений с использованием библиотеки.
Сегодня мы развернем многостраничный образец приложения в Azure. Для этого необходимо выполнить три шага:
- Создать приложение.
- Подготовить среду Azure.
- Развернуть приложения
Создаем приложение
В данном случае приложение уже написано, и мы просто заимствуем пример приложения, на который я ссылался ранее. Очень важная рекомендация при разработке на Python — всегда используйте виртуальные среды для управления зависимостями! Тогда у вас будет возможность применить команду pip freeze для создания файла requirements.txt, который позволит Azure установить зависимости приложения. Это текстовый файл, в котором находятся все библиотеки и версии Python, используемые приложением, и который, как правило, широко используется многими облачными провайдерами (что будет важно в дальнейшем).
Чтобы запустить приложение в VS Code, используйте streamlit run Home.py (Home.py является файлом точки входа). Ниже показано, как это работает в моем браузере.
Готовим среду Azure
Чтобы разместить это приложение в Azure самым простым способом, понадобится только развернуть код приложения на экземпляре App Service Azure. Можно создать необходимую инфраструктуру через портал Azure — обычно для этого используются такие инструменты, как Terraform и Bicep (особенно они полезны, если размер облачной среды вашей организации растет). Приятной фишкой здесь является возможность настроить App Service таким образом, чтобы он принимал непосредственно ваш код, а Azure будет заниматься контейнеризацией приложения.
Простая иерархия того, что должно быть подготовлено:
- подписка на использование Azure,
- которая открывает доступ к группе ресурсов,
- которая содержат план App Service,
- который используется экземпляром App Service.
Для большинства экспериментов рекомендую выбирать самый дешевый уровень. Большинство сервисов Azure предлагают бесплатные уровни, которые обеспечивают основной набор функциональных возможностей, необходимых в реальных условиях и позволяющих создать прототип максимально просто. Разумеется, чтобы поэкспериментировать с какими-то конкретными функциями (например, слотами для развертывания App Service), потребуется предоставить SKU, включающий необходимую функциональность.
Я предоставил SKU для плана App Service уровня B1, поскольку бесплатный уровень предполагает только 60 минут вычислений в день. App Service я настроил так, чтобы он выполнял функцию приемщика кода, а не контейнера, и позволил Azure самостоятельно устанавливать контейнеры каждый раз, когда нужно выполнить развертывание.
Важно: в случае Streamlit команда запуска экземпляра App Service должна полностью совпадать с командой, которая будет использоваться для локального запуска приложения.
Выполняем развертывание кода
Развертывание кода в App Service может осуществляться различными способами. Но я склоняюсь к тому, чтобы идти “до конца” (при создании производственных приложений) и ограничиться сверхлегким путем (при создании прототипов).
- Такие инструменты, как GitHub Actions и Azure DevOps, — первое, что приходит на ум, поскольку автоматизированные конвейеры развертывания в них (и других инструментах) являются “лучшим в своем классе” решением. Такое решение отлично подходит для интеграции автоматического тестирования, развертывания, ролбэков, одобрений и многого другого.
- Используя Git со своего устройства, вы отправляете код на новый удаленный репозиторий, который соответствует конечной точке развертывания App Service. Здесь Azure предоставляет имя пользователя и пароль для аутентификации, как и при отправке кода на такие инструменты, как GitHub.
- Есть и другие способы, но эти два являются основными, о которых следует знать. В документации Azure подробно описаны и другие доступные методы.
Для простоты буду использовать метод, при котором добавляется Git remote в репозиторий и выполняется отправка в место назначения. Обратите внимание: на приведенных ниже скриншотах показано, как я добавил Git remote и выполнил отправку на удаленную локацию под названием “Azure”, используя учетные данные, указанные на портале Azure.
Теперь, когда код развернут, достаточно зайти на URL-адрес приложения и убедиться, что оно работает так, как ожидалось. Вначале подобная задача может показаться довольно сложной, но с приобретением опыта она станет очень простой.
Замечания и рекомендации
При развертывании App Service в Azure описанным способом стоит учесть следующее.
- Управление идентификацией и доступом. Вам не нужно создавать собственную службу аутентификации/авторизации. Разрешения можно настроить через Azure Active Directory, а включение Seamless Sign-On — это часть конфигурации App Service. Далее все сводится к стандартным лучшим практикам ролевого управления доступом и т. д.
- Безопасность. В продолжение разговора о безопасности следует отметить наличие множества других возможностей, помимо идентификации. Например, интеграция виртуальных сетей позволяет контролировать трафик App Service, размещая приложение в подсети и поддерживая такими защитными элементами, как группы сетевой безопасности. Другой возможностью является проактивный анализ кода на предмет наличия проблем, например хранения учетных данных в открытом виде (для этого существуют такие инструменты, как SonarCube, которые можно использовать как часть конвейера сборки). Проактивное взаимодействие для понимания требований вашей организации здесь очень важно.
- Развертывание. Эта часть лично мне кажется наиболее интересной, поскольку на более высоких уровнях открывается множество технологий, которые могут существенно облегчить жизнь. Например, после определенного уровня вы получаете несколько “слотов развертывания”, что позволяет развернуть несколько версий одного и того же приложения рядом друг с другом и направлять трафик между ними по своему усмотрению. Одним из ключевых моментов, который позволяет это сделать, является разделение процесса развертывания и релиза. Вы можете развернуть систему в слоте, отличном от того, который видят конечные пользователи, и просто переключать трафик между слотами (т.е. осуществлять релиз) в любое время после завершения развертывания. Приятно, что конфигурация соответствует слотам развертывания, так что это очень просто — щелкнуть переключателем. Кроме того, это существенно упрощает ролбэки. Центр архитектуры Google подробно описывает лучшие практики системной инженерии, которые вас наверняка заинтересуют.
- Стоимость. Развертывание станет очень доступным, если обойтись дешевым уровнем. При этом другие инструменты могут оказаться конкурентоспособными по цене. Например, в данном случае я использовал Streamlit для демонстрации развертывания приложений в Azure, но если бы выбирал инструмент для проекта компании, активно инвестирующей в Microsoft Cloud, то учитывал бы, что Power BI Pro входит в каждую лицензию Microsoft 365 E5.
- Когда заниматься этим самостоятельно. Если вы хотите разработать что-то особенно нишевое, что вряд ли получит поддержку “из коробки” от большинства поставщиков, то здесь важно иметь представление о том, как создать собственный инструмент. Дело в том, что иногда приходится сталкиваться с ограничениями в готовых продуктах. Это касается многих стандартных компонентов любого решения — сетевого взаимодействия, управления секретами и т. д.
Определяя решение, наиболее подходящее для вашей конкретной ситуации, сначала все обдумайте. Такой шаг должен быть взвешенным.
Заключение
Подведем итоги того, что мы сделали.
- Выяснили, что такое Streamlit и как он работает. Это один из многих фреймворков для Python, который хорошо подходит для создания веб-приложений для взаимодействия с данными.
- Развернули работающее приложение Streamlit в облачной среде Azure, стараясь рассматривать проблему развертывания сквозь призму поиска методов, которые можно было бы распространить на приложения, основанные на других фреймворках.
- Рассмотрели некоторые общие соображения при выборе этого пути: безопасность, стоимость, методы развертывания и т. д.
Лично я нахожу огромное удовольствие в разработке действительно классного решения для интересной проблемы. Технологические команды могут создавать множество прототипов, но в конечном итоге их идеи должны воплощаться в жизнь, чтобы приносить прибыль. Если же будет доказано, что идея не так хороша, как кажется на первый взгляд, не стоит тратить время на ее реализацию.
Надеюсь, эта статья наглядно продемонстрировала, как с помощью облака можно легко запустить приложение и передать его в руки пользователей.
Читайте также:
- Использование WebSocket с Python
- Реализация архитектуры с сохранением состояния в Streamlit
- Запуск DBT в Azure Functions с помощью Snowflake
Читайте нас в Telegram, VK и Дзен
Перевод статьи Cillian Bissett: Deploying Python Applications to Azure
