Розгортання 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 і налаштування, захищайте приватні відповіді, зберігайте старі частини коду й репетируйте оновлення службового процесу.
• Випускайте з готовністю до відновлення: захищайте межу й джерело, розгортайте поетапно, перевіряйте загальнодоступний шлях, пов’язуйте телеметрію браузера й сервера та зберігайте доведене відкочування.