Развёртывание Angular в Azure: сначала спроектируйте среду выполнения

Развёртывание Angular может казаться обманчиво простым: собрать приложение, скопировать файлы в Azure и направить на них домен. Этот рецепт работает, пока прямая ссылка не вернёт 404, старый документ HTML не запросит уже удалённые части кода, значение среды не попадёт в ошибочный пакет или панель платформы не останется зелёной во время отказа оформления заказа в браузерах. Качество рабочей системы начинается до первого задания автоматизации: с точной модели исполняемых частей, места хранения состояния, ответственности каждого слоя за ответ и способа обнаружить и отменить неудачный выпуск.

Azure предлагает несколько подходящих мест для Angular, однако выбор службы является следствием архитектуры, а не её началом. Общедоступный сайт с отображением в браузере, корпоративная SPA с аутентификацией, магазин с серверным отображением и контейнерный интерфейс с собственной серверной частью предъявляют разные требования к выполнению, сети, безопасности, масштабированию и восстановлению. Это руководство превращает их в проект развёртывания, который команда способна объяснить, проверить, эксплуатировать и менять.

Сначала определите нужный продукту способ выполнения

Классифицируйте каждый ответ до выбора инфраструктуры. Обычная SPA Angular создаёт статические HTML, JavaScript, CSS, шрифты и изображения; браузер отображает маршруты и обращается к API. Серверное отображение Angular добавляет процесс Node.js, работающий для каждого запроса, а предварительное отображение создаёт статический HTML во время сборки. Смешанные приложения могут предварительно отображать устойчивые страницы, динамические — на сервере, а затем гидратировать оба вида в браузере. Зафиксируйте режим каждого URL-адреса, наличие личного содержимого и поведение при недоступности JavaScript, процесса отображения или API.

Нанесите полный путь запроса: DNS, пограничный узел, веб-узел, необязательный процесс SSR, шлюз API или серверную часть, поставщика идентификации, хранилища данных и сторонние вызовы. Добавьте ожидаемую нагрузку, географию, цели задержки, место хранения данных, требования частной сети, размеры файлов, частоту развёртываний и команду реагирования на сбой. Так становятся видны скрытые зависимости: глобально кешированная оболочка мало поможет медленному региональному API, а близкий к пользователю SSR всё равно будет ждать каждую синхронную серверную зависимость.

Определите измеримые цели обслуживания вокруг путей пользователя, а не только доступности инфраструктуры. Отслеживайте доступность и задержку входа, поиска, оформления заказа или основного рабочего пространства, долю ошибок JavaScript и успешных загрузок после выпуска. Установите границы размера пакета, Core Web Vitals, задержки API, времени восстановления и допустимой устарелости. Они определяют, достаточно ли статической поставки, полезна ли граница сети, какое резервирование оправданно и какие отказы должны автоматически останавливать или откатывать выпуск.

Выбирайте границу размещения в Azure, а не название службы

Для статического приложения Angular самый короткий путь эксплуатации часто даёт Azure Static Web Apps: служба размещает статические файлы, настраивает маршруты, создаёт среды предварительного просмотра, управляет сертификатами и аутентификацией и при необходимости объединяет API. Статический веб-сайт Azure Storage вместе с Azure Front Door даёт более точное управление хранилищем, глобальной поставкой, доменами, маршрутами и безопасностью, но команда самостоятельно собирает и сопровождает больше частей. Выбирайте этот контроль лишь при ясных требованиях сети, масштаба или платформы и определённом владельце.

SSR требует постоянной серверной среды. Azure App Service подходит для управляемого веб-приложения Node.js и поддерживает ячейки развёртывания и проверки работоспособности. Azure Container Apps уместен, когда сервер Angular упакован в контейнер, нужен поэтапный перевод между редакциями или он работает рядом с контейнерными службами. AKS оправдан при уже существующей платформе Kubernetes и модели её эксплуатации; отдельный кластер лишь для одного сервера Angular обычно создаёт больше работы с жизненным циклом, сетью, безопасностью и дежурствами, чем требует продукт.

Сохраняйте устойчивую общедоступную точку входа, позволяя менять источник. Собственный домен может завершать соединение в Static Web Apps или Front Door, который направляет статические пути, трафик SSR и API к определённым источникам. Закрепите ответственность за DNS, сертификаты, пограничные правила, заголовки узла, масштабирование и точки проверки. Рассчитывайте полную стоимость вместе с журналами, передачей данных, WAF, частным соединением, резервными мощностями и временем инженеров. Самый дешёвый ресурс в тарифах может образовать самую дорогую систему в эксплуатации.

Чётко определите маршруты SPA и смысл ошибок

Для маршрутизации в браузере узел должен возвращать входной документ Angular, когда маршрут приложения запрашивают напрямую. Настройте запасной переход к /index.html, исключив каталоги файлов, пути API, обратные вызовы аутентификации, служебные файлы, robots и sitemap и настоящие серверные точки. Слишком широкое переписывание, возвращающее HTML вместо отсутствующего JavaScript, превращает полезную 404 в ошибку типа содержимого и может запереть клиента в сломанном выпуске. Проверьте прямую ссылку, обновление браузера, скопированный URL-адрес, параметры, фрагмент и каждый префикс языка.

Сохраняйте правдивый смысл HTTP. Неизвестные маршруты приложения могут показывать оформленную страницу Angular «не найдено», но отсутствующие файлы и ресурсы API должны возвращать 404, ошибки аутентификации — 401 или 403, а ограничение частоты и серверные отказы — собственные коды. Определите место старых перенаправлений и перехода на канонический узел, не создавайте бесконечных цепочек и проверьте их до переключения DNS. Для SSR убедитесь, что средство отображения возвращает содержательный код, а не оформленную страницу ошибки с 200.

Настройте базовый URL-адрес и пути файлов для настоящего домена и подпути. Проверьте сжатие, типы содержимого, имена Unicode, чувствительность к регистру, правила конечной косой черты, крупные файлы и область действия служебного процесса браузера. Для прогрессивного веб-приложения испытайте обновление между несколькими развёрнутыми версиями и предусмотрите восстановление повреждённого кеша. Проверки маршрутизации должны работать в развёрнутой среде просмотра: правильный маршрутизатор Angular не исправит ошибочного правила пограничного узла или размещения.

Отделите материал сборки от настроек при запуске

Файлы сред Angular выполняют замену во время сборки, а не защищают секреты во время работы. Всё отправленное браузеру могут прочитать пользователи, карты исходного кода, расширения или автоматические сканеры. Общедоступные основы API, идентификаторы телеметрии, типовые переключатели и независимое от клиента оформление могут быть настройкой браузера. Учётные данные базы, закрытые ключи, служебные учётные данные и привилегированные токены API должны оставаться за API в Key Vault или другом защищённом серверном хранилище и по возможности читаться через управляемую учётную запись.

Создавайте один неизменяемый материал и продвигайте его между средами. До запуска Angular загружайте разрешённые значения из небольшого config.json, начального объекта или общедоступной точки настроек. Определите и версионируйте схему, проверяйте её и показывайте пригодное для диагностики сообщение при отсутствующих значениях. Не допускайте нежелательного кеширования точки и разрешайте только безопасные для любого браузера данные. Так уменьшается расхождение повторных сборок, а в рабочую систему попадает именно та сборка, которую проверили в промежуточной среде.

Передавайте серверным процессам настройки через параметры платформы, управляемые учётные записи, Azure App Configuration и ссылки Key Vault в соответствии с чувствительностью и частотой изменений. Разделяйте ресурсы и учётные записи разработки, проверки, промежуточной и рабочей сред. Предоставляйте самые узкие роли доступа к данным, завершайте временные права и проверяйте изменения настроек. Относитесь к переключателям возможностей как к рабочим изменениям: назначайте владельца, определяйте охваченную группу и срок действия, наблюдайте обе ветви и храните последнюю исправную настройку для независимого от кода восстановления.

Подбирайте правила кеша по частоте изменений файлов

Кешируйте по изменяемости. Имена созданных Angular файлов JavaScript и CSS обычно содержат хеш содержимого, поэтому им можно назначить долгий срок с immutable: изменённый файл получит новый URL-адрес. Так же поступайте с версионированными шрифтами и изображениями. Входной HTML нужно часто проверять повторно, поскольку он ссылается на текущий граф файлов. Настройки при запуске, манифесты и метаданные служебного процесса требуют явных, обычно коротких или повторно проверяемых правил, чтобы откат или исправление быстро дошло до клиентов.

Пусть за каждое решение о кеше отвечает один слой; задокументируйте взаимодействие кешей браузера, служебного процесса, Front Door, источника и API. Добавляйте в ключи параметры запроса и нужные заголовки лишь тогда, когда они действительно меняют представление: неуправляемые варианты снижают долю попаданий, а пропущенное различие может отдать ответ одного пользователя другому. Не кешируйте на границе аутентифицированное или чувствительное содержимое без доказанной изоляции. Принудительная очистка — аварийное средство, а не замена версионированных URL и правильных заголовков.

Проверяйте переход между выпусками, а не только чистую загрузку. Храните старые файлы с хешами достаточно долго для вкладок со старым HTML или согласуйте срок хранения с наибольшей продолжительностью сеанса. Воспроизведите клиента, который получил входной документ до развёртывания, а отложенную часть кода запросил после него. Измеряйте долю попаданий кеша, исходящий трафик источника, быстродействие первого и повторного посещения и устаревшие ответы по маршруту. При наличии служебного процесса включайте его жизненный цикл обновления в репетиции выпуска и отката.

Рассматривайте границу сети и источник как единую границу безопасности

Используйте HTTPS на всём пути и автоматически обновляйте сертификаты. Применяйте проверенные правила Content Security Policy, HSTS, ограничения встраивания, политики источника перехода и разрешений и защиту типа содержимого. Сначала запускайте CSP только с отчётами, исследуйте нарушения, а затем включите принудительно без широких шаблонов и постоянных опасных исключений. CORS относится к API и должен разрешать лишь нужные источники, методы и заголовки. Это правило браузера, а не аутентификация или защита от прямых запросов.

Если Front Door является общедоступным входом, не позволяйте клиентам обходить его и обращаться к источнику. Используйте Private Link, когда его поддерживают выбранный уровень и источник, или примените документированные служебные метки, идентификатор Front Door, проверку узла и ограничения доступа платформы. Включите WAF с управляемыми правилами, настройте его по наблюдаемому трафику, внедряйте разрушительные изменения поэтапно и отправляйте журналы в процесс безопасности. Никогда случайно не кешируйте личные данные на границе.

Разделяйте учётные записи управления и приложения, требуйте MFA и RBAC с наименьшими правами, а CI аутентифицируйте через объединение удостоверений рабочих процессов вместо долговечных секретов развёртывания. Храните инфраструктуру и пограничные правила в проверяемом коде. Решите, удалять ли карты исходного кода из рабочей системы, хранить частным образом или передавать службе ошибок, и не позволяйте телеметрии собирать токены или личные данные. Моделируйте угрозы перенаправлений аутентификации, хранения токенов, подделки серверных запросов SSR, зависимостей, загрузки файлов и отказа в обслуживании на всём пути.

Постройте процесс выпуска, способный отменить собственные решения

Надёжный процесс выпуска создаёт доказательства, а не только файлы. Зафиксируйте версии среды и управления пакетами, устанавливайте из файла зависимостей, проверяйте происхождение, стиль, типы и содержательные тесты, собирайте в рабочем режиме, сканируйте результат, контролируйте размер и публикуйте версионированный материал со сведениями об изменении кода и зависимостях. Собирайте один раз. После проверок среды продвигайте тот же материал, а не создавайте новый на каждом сервере или этапе.

Развёртывайте инфраструктуру через Bicep, Terraform или другую проверяемую декларативную систему. Сначала выпускайте в среду просмотра, ячейку App Service, редакцию Container Apps или на малую долю трафика. Через общедоступный домен проверяйте входной документ, прямую ссылку, статический файл, аутентификацию, критический API, телеметрию и заголовки безопасности. При необходимости прогревайте SSR, проверяйте работоспособность по настоящим зависимостям и переводите трафик лишь после технической и продуктовой приёмки.

Определите откат до выпуска. Запишите предыдущий материал, снимок настроек, версию инфраструктуры, доли маршрутизации и срок совместимости базы данных. Отдавайте предпочтение совместимым API и изменениям данных, чтобы более старый интерфейс мог сосуществовать с более новой серверной частью во время распространения и возврата. Автоматизируйте остановку по ошибкам пользователей, задержке, здоровью системы и событиям бизнеса и назовите ответственного за человеческое решение. После отката сохраните журналы и доказательства выпуска, а затем устраните причину вместо немедленного повторения.

Наблюдайте путь от браузера до источника

Платформа может показывать исправность, пока пользователи получают устаревший HTML, не загружают отложенную часть кода, зацикливаются на входе или ждут удалённый API. Добавьте телеметрию браузера для просмотров, времени навигации, Core Web Vitals, исключений JavaScript, неудачных сетевых запросов и ключевых результатов бизнеса. Соблюдайте конфиденциальность и правила выборки. Помечайте каждое событие версией выпуска, средой, маршрутом и идентификатором связи, который проходит через границу, шлюз API, службу и журналы зависимостей.

Соединяйте данные настоящих пользователей с синтетическими путями из нужных регионов, журналами доступа Front Door и WAF, показателями узлов, трассировкой SSR, задержкой API, отказами зависимостей и отметками развёртываний. Панели должны отвечать, кого затронуло, когда началось изменение, какой выпуск и маршрут причастны и где накапливаются время или ошибки. Оповещайте о признаках, связанных с целями и скоростью исчерпания допустимой погрешности, и привязывайте каждое оповещение к владельцу и проверенной инструкции. Большой объём журналов без пути к решению — дорогой шумовой фон.

Репетируйте отказы, которые архитектура обещает пережить: недоступный API, неисправный процесс SSR, заблокированный источник, просроченный сертификат, устаревшие настройки, частичное распространение на границе, отсутствующая часть кода, задержка поставщика идентификации и отказ телеметрии. После каждого значимого выпуска пересматривайте стоимость, быстродействие, доказательства восстановления, выводы безопасности и эксплуатационную нагрузку. Пересматривайте границу размещения с изменением трафика, способа отображения, требований закона, ответственности или ритма выпусков. Надёжное развёртывание Azure — не застывшая при запуске схема, а совокупность ясных решений, которые могут быть опровергнуты доказательствами рабочей системы.

• Смоделируйте выполнение: нанесите статические, предварительно и серверно отображаемые маршруты, полный путь запроса, цели пользователя, регионы, зависимости, ограничения данных и эксплуатационную ответственность.
• Выберите наименьшую достаточную платформу: сопоставьте Static Web Apps, Storage с Front Door, App Service, Container Apps или имеющуюся AKS с требованиями выполнения и управления.
• Сохраняйте смысл веб-протоколов: ограничьте запасной маршрут SPA, возвращайте правдивые коды, проверяйте прямые ссылки и перенаправления на развёрнутых узле и границе.
• Продвигайте один материал: храните секреты на сервере, проверяйте безопасные настройки запуска, используйте управляемые учётные записи и выпускайте именно проверенную сборку.
• Проектируйте переходы кеша: надолго кешируйте файлы с хешами, повторно проверяйте HTML и настройки, защищайте частные ответы, храните старые части кода и репетируйте обновление служебного процесса.
• Выпускайте с готовностью к восстановлению: защищайте границу и источник, развёртывайте поэтапно, проверяйте общедоступный путь, связывайте телеметрию браузера и сервера и сохраняйте доказанный откат.