Планируйте ваше статическое веб-приложение Azure
- 5 мин
Ваша конечная цель — разместить свое приложение в Azure. Статические веб-приложения Azure заботятся о подготовке всех необходимых ресурсов Azure для вас.
Однако, прежде чем вы сможете разместить свое приложение, вам нужно иметь средство для его сборки, чтобы вносить изменения. Изменения могут быть внесены с помощью коммитов или pull-запросов в ваш репозиторий. Основная функция службы статических веб-приложений Azure состоит в том, что она настраивает рабочий процесс GitHub Actions, необходимый для сборки и публикации вашего приложения.
При создании ресурса Azure Static Web Apps, он создает рабочий процесс GitHub Actions. Рабочий процесс активируется незамедлительно и выполняет сборку и публикацию вашего приложения. Рабочий процесс также запускается каждый раз, когда вы вносите изменения в отслеживаемую ветвь в своем репозитории.
Служба статических веб-приложений Azure
Существуют два автоматизированных аспекта развертывания веб-приложения. Первый подготавливает базовые ресурсы Azure, из которых состоит приложение. Второй — это рабочий процесс GitHub Actions, который выполняет сборку и публикацию приложения.
При публикации приложения в Интернете с помощью службы статических веб-приложений Azure вы получаете быстрое размещение своего веб-приложения и масштабируемые API. Плюс вы также получаете единый процесс сборки и развертывания, предоставляемый GitHub Actions.
Подключите экземпляр статических веб-приложений к GitHub
Служба статических веб-приложений Azure предназначена для размещения приложений, в которых исходный код находится в GitHub. Когда вы создадите экземпляр службы статических веб-приложений, войдите в GitHub и укажите репозиторий, содержащий код вашего приложения.
Чтобы сборка и развертывание вашего приложения были выполнены автоматически, вам также нужно указать пути к трем папкам в репозитории.
| Расположение | Пример расположения | Описание | Обязательное поле |
|---|---|---|---|
| Расположение приложения | / | Расположение исходного кода для веб-приложения | Да |
| Расположение выходных файлов сборки приложения | дистрибутив | Расположение выходных данных сборки по отношению к месту нахождения вашего приложения | Нет |
| Расположение API | API | Расположение исходного кода для API | Нет |
Выходные данные сборки приложения — это относительный путь к каталогу выходных данных сборки вашего приложения. Допустим, например, что у нас есть приложение в папке my-app, которое выводит создаваемые им активы в папку my-app/dist. В этом случае укажите dist для этого местоположения.
От исходного кода к статическим ресурсам с помощью GitHub Actions
Репозиторий GitHub содержит исходный код, поэтому перед публикацией нужно выполнить его сборку.
Когда вы создаете экземпляр службы статических веб-приложений, Azure создает рабочий процесс GitHub Actions в вашем репозитории. Процесс работы создает ваше приложение каждый раз, когда вы отправляете изменения или создаете запрос на вытягивание в ветку, которую вы выбрали для отслеживания. Этот процесс сборки преобразует ваш исходный код в статические ресурсы, которые обслуживаются через Azure. После завершения сборки, действие развертывает ресурсы.
Действие GitHub добавляется в ваш репозиторий в папке .github/workflows. При необходимости вы можете проверить или изменить этот файл. Параметры, которые вы вводите при создании ресурса, сохраняются в файле действия GitHub.
Интеграция API с Функциями Azure
Если приложению требуется API, его можно реализовать как проект Функций Azure в своем репозитории. Ваш API будет автоматически развернут и размещен в рамках экземпляра Статического веб-приложения. Рабочий процесс GitHub Actions, который выполняет сборку и развертывание вашего приложения, находит API в репозитории по имени указанной вами папки.
Обычно приложение API помещается в папку с именем api или functions, но при желании вы можете назвать ее любым другим именем.
Что делать, если у вас нет API? Не волнуйся. Если служба статических веб-приложений Azure не найдет API в указанной вами папке, она не опубликует API, но все равно опубликует ваше приложение.
Обработать резервные маршруты
Ошибка 404 возникает, когда вы обновляете страницу, поскольку браузер отправляет запрос на платформу размещения для обработки /products. На сервере нет страницы для обслуживания с именем products. К счастью, эту проблему легко решить, создав резервный маршрут. Резервный маршрут — это маршрут, который сопоставляет все несопоставленные запросы страниц с сервером.
Статические веб-приложения Azure поддерживают пользовательские правила маршрутизации, определяемые во вспомогательном файле staticwebapp.config.json, который находится в папке выходных данных сборки приложения.
Чтобы реализовать резервный маршрут, вы можете настроить для приложения правила с подстановочным знаком и фильтром файлов, как показано в следующем примере:
{
"navigationFallback": {
"rewrite": "index.html",
"exclude": ["/images/*.{png,jpg,gif,ico}", "/*.{css,scss,js}"]
}
}
Это правило указывает, что Статические веб-приложения Azure должны обслуживать index.html в случае, если запрос ресурса не найден, исключая изображения и файлы CSS, отображаемые в выражении exclude.
Расположение файлов маршрутов
Статические веб-приложения Azure по умолчанию ищут файл staticwebapp.config.json в папке output_location. Если в процессе сборки файл staticwebapp.config.json копируется в output_location, никакие другие действия выполнять не нужно. Для большинства проектов output_location относительно app_location.
Файл staticwebapp.config.json для приложения находится в папке angular-app/src/assets.
Файл staticwebapp.config.json находится в папке react-app.
Файл staticwebapp.config.json находится в папке svelte-app/public.
Файл staticwebapp.config.json находится в папке vue-app/public.
Следующие шаги
Итак, что вам нужно, чтобы опубликовать свое веб-приложение в службе статических веб-приложений Azure? Вам нужно только разместить свое приложение в репозитории GitHub.