Планирование статического веб-приложения Azure
Ваша конечная цель — разместить свое приложение в Azure. Статические веб-приложения Azure заботится о подготовке всех необходимых ресурсов Azure.
Однако, прежде чем вы сможете разместить свое приложение, нужно будет внести в него изменения. Для внесения изменений можно использовать запросы к репозиторию на фиксацию или вытягивание. Основная функция службы статических веб-приложений Azure состоит в том, что она настраивает рабочий процесс GitHub Actions, необходимый для сборки и публикации вашего приложения.
При создании ресурса службы статических веб-приложений Azure она создает рабочий процесс GitHub Actions. Рабочий процесс активируется незамедлительно и выполняет сборку и публикацию вашего приложения. Рабочий процесс также запускается каждый раз, когда вы вносите изменения в отслеживаемую ветвь в своем репозитории.
Служба статических веб-приложений Azure
Существуют два автоматизированных аспекта развертывания веб-приложения. Первый подготавливает базовые ресурсы Azure, из которых состоит приложение. Второй — это рабочий процесс GitHub Actions, который выполняет сборку и публикацию приложения.
При публикации приложения в Интернете с помощью службы статических веб-приложений Azure вы получаете быстрое размещение своего веб-приложения и масштабируемые API. Плюс вы также получаете единый процесс сборки и развертывания, предоставляемый GitHub Actions.
Подключение экземпляра Статических веб-приложений к GitHub
Служба статических веб-приложений Azure предназначена для размещения приложений, в которых исходный код находится в GitHub. Когда вы создадите экземпляр службы статических веб-приложений, войдите в GitHub и укажите репозиторий, содержащий код вашего приложения.
Чтобы сборка и развертывание вашего приложения были выполнены автоматически, вам также нужно указать пути к трем папкам в репозитории.
| Расположение | Пример расположения | Description | Обязательное поле |
|---|---|---|---|
| Расположение приложения | / | Расположение исходного кода для веб-приложения | Да |
| Расположение выходных данных сборки приложения | dist | Расположение выходных данных сборки приложения относительно расположения приложения | No |
| Расположение API | api | Расположение исходного кода для API | No |
Расположение выходных данных сборки приложения — это относительный путь к выходному каталогу сборки вашего приложения. Допустим, например, что у нас есть приложение в папке 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.