Веб-приложения в облаке - Так легко начать работу?
Быстрая установка и запуск веб-сервисов в сегодняшнем насыщенном облаками Интернете - простая задача. Например, страницы GitHub - это простой способ запустить персональный сайт за считанные минуты. Еще одна программа, которую я изучал недавно, Heroku, позволяет любителям легко настроить промежуточную среду из своих репозиториев кода. Однако для коммерческих приложений создание веб-приложений может быть намного сложнее, как видно из следующих проблем.
Как насчет настройки управляемых и масштабируемых веб-приложений для использования в производстве - в сочетании с другой необходимой инфраструктурой и рабочими процессами, такими как конвейер непрерывной интеграции + непрерывного развертывания / доставки (CICD)? Обычный способ - использовать разные сервисы для достижения каждой из этих целей, что иногда превращает управление одним сервисом в кошмар.
Еще одна проблема - это затраты на создание и обслуживание инфраструктуры - как время, так и деньги. Это сводится к двум факторам: техническим препятствиям и затратам на выбранную инфраструктуру, а также к инженерам, которые могут преодолеть эти препятствия.
Для решения этих двух проблем приходит Google Cloud Platform (GCP). Но прежде чем объяснять, как он решает эти проблемы, давайте рассмотрим, как мы можем настроить рабочий процесс с веб-приложением в облаке с помощью GCP менее чем за 10 минут.
10 шагов за 10 минут
Вот краткий обзор предпринятых шагов:
- Создайте проект GCP (10 секунд)
- Включите App Engine (10 секунд)
- Включить API администратора App Engine (10 секунд)
- Включить Cloud Run (10 секунд)
- Включить Cloud Build для рабочего процесса CICD (10 секунд)
- Отслеживайте изменения кода с помощью Cloud Build (1 минута)
- Настройте сервисный аккаунт Cloud Build с соответствующими ролями IAM (1 минута)
- Добавить конфигурацию App Engine (в базу кода) (1 минута)
- Добавить конфигурацию сборки Cloud (в базу кода) (1 минута)
- Зарегистрируйте конфигурации в репозитории кода и запустите рабочий процесс CICD для развертывания. (4 минуты, включая время сборки)
Обратите внимание, что для вышеуказанного мы развернули приложения App Engine (Standard) и Cloud Run as Node. Для App Engine (Standard) при развертывании требуется app.yaml файл в базе кода, который рассматривается в шаге 8. Cloud Run использует образы Docker, поэтому здесь предполагается, что в приложении будет файл Docker. Образец проекта, совместимого с App Engine и Cloud Run, можно увидеть здесь.
В общей сложности нам потребуется около 9 минут, чтобы начать с нуля, чтобы иметь два веб-приложения с рабочими процессами CICD и развертывать их непосредственно из изменений кода на GCP. Фактически, я проделывал этот процесс несколько раз, и мне удалось добиться меньшего времени.
Еще один заслуживающий внимания момент заключается в том, что и Cloud Run, и App Engine использовались выше в демонстрационных целях. В реальном производственном использовании нам нужно будет использовать только одно из них, а не запускать два одинаковых веб-приложения. Это могло означать только то, что вышеперечисленное можно сделать намного проще и в более короткие сроки.
10 шагов, подробное описание
Давайте подробнее рассмотрим 10 шагов и то, что мы должны делать на каждом шаге.
Шаг 1. Создайте проект GCP
Поскольку мы начинаем с чистого листа, нам необходимо создать новый проект GCP перед развертыванием в нем наших приложений. Вы можете перейти по этой ссылке, чтобы напрямую создать свой собственный проект GCP.
Шаг 2. Включите App Engine
Если вы решили использовать App Engine вместо Cloud Run, это один из шагов, которые вам необходимо выполнить.
Процесс прост - в меню навигации нажмите App Engine, затем Dashboard. Вы должны увидеть кнопку Create Application, как на изображении выше. После нажатия вы перейдете к процессу, в котором сможете выбрать регион для приложения App Engine и среду (стандартную или гибкую). Обратите внимание, что выбранный регион не может быть изменен в будущем, но окружение может быть изменено в любое время.
Дополнительные сведения о подходящей среде App Engine для использования см. Здесь.
Шаг 3. Включите API администратора App Engine
В продолжение этапа создания App Engine с шага 2 нам необходимо включить App Engine Admin API.
Чтобы выполнить этот шаг, в меню навигации щелкните APIs & Services, затем Dashboard. Найдите App Engine Admin API, и вы должны увидеть интерфейс с кнопкой Enable, как на изображении выше.
Включение этого API позволяет нам использовать SDKgcloud для непосредственного развертывания приложения, о чем будет сказано ниже.
Шаг 4. Включите Cloud Run
Если вы решили использовать Cloud Run вместо App Engine, вам нужно будет выполнить этот шаг.
Чтобы выполнить этот шаг, в меню навигации щелкните Cloud Run. Вы должны увидеть интерфейс с кнопкой Start Using Cloud Run, как на изображении выше.
Шаг 5. Включите Cloud Build для рабочего процесса CICD
Продукт, предлагаемый GCP для CICD, основан на использовании Cloud Build. Мы можем настроить Cloud Build для тестирования, сборки и развертывания наших приложений в App Engine и Cloud Run.
Чтобы получить доступ к интерфейсу выше, в меню навигации щелкните Cloud Build. Затем нажмите Enable Cloud Build API, чтобы включить Cloud Run для использования в вашем проекте.
Шаг 6. Отслеживайте изменения кода с помощью Cloud Build.
После включения Cloud Build нам нужно добавить соответствующие конфигурации для отслеживания и развертывания приложения из репозитория кода. Мы запускаем этот процесс из меню навигации, выбирая Cloud Build, затем Triggers.
Как только мы увидим интерфейс выше, мы можем нажать кнопку Connect Repository, чтобы перейти к следующему экрану.
На этом этапе мы можем выбрать сервис репозитория кода, который мы используем. Поскольку демонстрационный проект, который я использовал, был основан на GitHub, я выбрал этот вариант, как показано выше. Когда будете готовы, выберите Continue, чтобы перейти к следующему интерфейсу, где вам будет предложено выбрать репозиторий для этой конфигурации CICD.
После выбора репозитория последняя часть процесса - это добавление триггера. Этот триггер будет содержать критерии для запуска новых сборок.
В меню создания триггера важно выбрать вышеуказанный вариант Cloud Build configuration file в разделе «Конфигурация сборки» с местоположением cloudbuild.yaml. Это будет связано с более поздним шагом, который содержит шаги, которые нужно выполнить для каждой сборки.
Существуют также другие параметры, которые можно выбрать при создании триггера. Один из таких вариантов - создать регулярное выражение ветки для целевых ветвей, которые помечены для тестирования или развертывания.
Шаг 7. Настройте учетную запись службы Cloud Build с соответствующими ролями IAM.
Чтобы наши сборки CICD могли успешно развернуть созданное приложение в App Engine или Cloud Run, нам необходимо назначить соответствующие разрешения в GCP Identity and Access Management (IAM).
Доступ к вышеуказанному интерфейсу можно получить из меню навигации, из IAM & admin, а затем нажав IAM. При назначении разрешений для Cloud Build убедитесь, что вы назначаете их учетной записи службы @cloudbuild.gserviceaccount.com с префиксом ID вашего проекта. Идентификатор вашего проекта можно найти на домашней странице вашего проекта.
Шаг 8. Добавьте конфигурацию App Engine (в базу кода)
Если вы решили использовать App Engine вместо Cloud Run, вам придется выполнить этот шаг. Эта конфигурация необходима для App Engine, чтобы понимать зависимости и свойства приложения, которое он должен обслуживать. На основе приведенного выше фрагмента добавьте его в корневой каталог проекта как app.yaml.
Конфигурация App Engine различается в зависимости от среды (Standard VS Flexible). Обязательно ознакомьтесь со свойствами, которые можно настроить как на стандартные, так и гибкие.
Шаг 9. Добавьте конфигурацию сборки облака (в базу кода)
На основе приведенного выше фрагмента кода мы добавляем его как новый файл cloudbuild.yaml в корневой каталог кода приложения. В этом файле конфигурации подробно описаны шаги, выполняемые в рабочем процессе CICD, такие как запуск тестов, создание ресурсов и последующее развертывание приложения. Не пропустите шаг для Cloud Run или App Engine, в зависимости от того, какой инструмент вы решите не использовать в своем собственном проекте.
См. Здесь для получения дополнительных сведений о формате и свойствах файла конфигурации Cloud Build.
Шаг 10 - Зарегистрируйте конфигурации в репозитории кода и запустите рабочий процесс CICD для развертывания.
Поскольку мы добавили файлы конфигурации на последних двух шагах, мы должны проверить их в репозитории кода, прежде чем их можно будет использовать. После отправки фиксации на основе шага 6 запускается новая сборка на основе конфигурации шага 9, которая будет развертывать как App Engine, так и Cloud Run.
Вот и все! Мы достигли конца нашего 10 шага за 10 минут процесса. На данный момент все, что вам нужно сделать, это дождаться завершения процесса сборки и запуска процесса развертывания ваших веб-приложений.
Возвращаясь к первоначальному вопросу, как GCP решает две возникшие проблемы?
Хотите создать управляемое и масштабируемое веб-приложение для использования в производственной среде?
От GCP в своей экосистеме инструментов, использованных выше, таких как Cloud Build и Container Registry, можно удовлетворить потребности репозитория образов CICD и Docker соответственно. Все эти инструменты можно использовать в рамках одного проекта или области действия веб-приложения в GCP, что упрощает управление и разделение ресурсов для каждой группы приложений.
Выбирая использование бессерверных инструментов в GCP - AppEngine или Cloud Run, мы также можем воспользоваться преимуществами бессерверной работы. Одним из этих преимуществ является перенос логики масштабирования в GCP, что позволяет нам сосредоточиться исключительно на логике приложения, нашего продукта.
Огромные денежные и временные затраты на установку и обслуживание приложений?
Оба типа затрат в значительной степени зависят от выбранной инфраструктуры (виртуальные машины? Kubernetes? Docker?), И нанимающие инженеры разбираются в инфраструктуре. Обладая более опытными инженерами, вы могли бы наладить и запустить намеченную инфраструктуру намного быстрее и, возможно, сократить время простоя в производстве, хотя это происходит за счет предварительного инвестирования дополнительных финансовых ресурсов.
Обратное - горькая пилюля, которую нужно проглотить. Экономия на техническом опыте может первоначально привести к снижению затрат за счет скорости настройки. Однако могут иметь место длительные пагубные последствия, такие как плохо выбранная и дорогостоящая инфраструктура, более длительные, чем ожидалось, простои или плохо спланированная инфраструктура, которая быстро становится унаследованной, что в конечном итоге требует дополнительных затрат времени и денег на перезапись.
Переход без сервера с облачными поставщиками, такими как GCP, решает проблему за счет снижения сложности инфраструктуры, при этом обеспечивая соответствие отраслевым стандартам надежности и функциональности. Возьмем, к примеру, App Engine - его можно легко настроить, а проблемы с инфраструктурой абстрагируются от GCP. Это снижает потребность в выделении инженеров для ежедневного решения проблем инфраструктуры, позволяя предприятиям сосредоточить ресурсы на своих продуктах.
Что касается фактических затрат на App Engine и Cloud Run, ознакомьтесь с калькулятором цен GCP. По моему опыту, я запускал приложения AppEngine, которые по сути бесплатны (из-за бесплатного уровня в GCP) в течение нескольких месяцев, но они также могут масштабироваться, если входящий трафик увеличится, и я буду платить только за то, что использовал в любое время. .
Это все, ребята. Надеюсь, вам понравилось это пошаговое руководство и мой взгляд на бессерверность с GCP.
