Развёртывание

Когда вы готовы развернуть Angular-приложение на удалённом сервере, есть несколько вариантов.

Автоматическое развёртывание с помощью CLI

Команда Angular CLI ng deploy выполняет CLI builder deploy, связанный с вашим проектом. Ряд сторонних builders реализует возможности развёртывания на разные платформы. Любой из них можно добавить в проект с помощью ng add.

Когда вы добавляете пакет с возможностью развёртывания, он автоматически обновляет конфигурацию workspace (angular.json) секцией deploy для выбранного проекта. После этого можно использовать команду ng deploy для развёртывания этого проекта.

Например, следующая команда автоматически разворачивает проект на Firebase.

ng add @angular/fire
ng deploy

Команда интерактивна. В этом случае необходимо иметь или создать аккаунт Firebase и пройти аутентификацию. Команда предложит выбрать Firebase-проект для развёртывания, затем соберёт приложение и загрузит production-артефакты в Firebase.

В таблице ниже перечислены инструменты, реализующие развёртывание на разные платформы. Команда deploy для каждого пакета может требовать разные опции командной строки. Подробнее — по ссылкам, связанным с именами пакетов ниже:

Если вы разворачиваете на самостоятельно управляемом сервере или для вашей облачной платформы нет builder, можно либо создать builder, позволяющий использовать ng deploy, либо прочитать это руководство, чтобы узнать, как развернуть приложение вручную.

Ручное развёртывание на удалённый сервер

Чтобы развернуть приложение вручную, создайте production-сборку и скопируйте выходной каталог на веб-сервер или CDN. По умолчанию ng build использует конфигурацию production. Если вы настроили конфигурации сборки, перед развёртыванием стоит убедиться, что применяются production-оптимизации.

ng build по умолчанию выводит собранные артефакты в dist/my-app/, однако этот путь можно настроить опцией outputPath в builder @angular/build:application. Скопируйте этот каталог на сервер и настройте его на раздачу каталога.

Хотя это минимальное решение для развёртывания, для корректной раздачи Angular-приложения к серверу есть несколько требований.

Конфигурация сервера

В этом разделе описаны изменения, которые может потребоваться настроить на сервере для запуска Angular-приложения.

Приложения с маршрутизацией должны возвращать index.html

Клиентские Angular-приложения хорошо подходят для раздачи статическим HTML-сервером, потому что весь контент статичен и генерируется на этапе сборки.

Если приложение использует Angular router, необходимо настроить сервер так, чтобы он возвращал главную страницу приложения (index.html), когда запрашивается отсутствующий файл.

Приложение с маршрутизацией должно поддерживать «deep links». Deep link — это URL, указывающий путь к компоненту внутри приложения. Например, http://my-app.test/users/42 — это deep link на страницу деталей пользователя с id 42.

Проблемы нет, когда пользователь сначала загружает index-страницу, а затем переходит по этому URL из работающего клиента. Angular router выполняет навигацию на клиенте и не запрашивает новую HTML-страницу.

Но клик по deep link в письме, ввод его в адресной строке браузера или даже обновление страницы, уже находясь на deep-linked странице, обрабатываются самим браузером вне работающего приложения. Браузер делает прямой запрос к серверу за /users/42, обходя роутер Angular.

Статический сервер обычно возвращает index.html, когда получает запрос к http://my-app.test/. Но большинство серверов по умолчанию отклонят http://my-app.test/users/42 и вернут ошибку 404 - Not Found, если не настроены возвращать вместо этого index.html. Настройте fallback-маршрут или страницу 404 на index.html для вашего сервера, чтобы Angular отдавался для deep links и мог отобразить правильный маршрут. Некоторые серверы называют это поведение режимом «Single-Page Application» (SPA).

После загрузки приложения браузером Angular router прочитает URL, определит текущую страницу и корректно отобразит /users/42.

Для «настоящих» страниц 404, таких как http://my-app.test/does-not-exist, серверу не требуется дополнительная конфигурация. Страницы 404, реализованные в Angular router, отобразятся корректно.

Запрос данных с другого сервера (CORS)

Веб-разработчики могут столкнуться с ошибкой cross-origin resource sharing при сетевом запросе к серверу, отличному от хост-сервера приложения. Браузеры запрещают такие запросы, если сервер явно их не разрешает.

Angular или клиентское приложение ничего не могут сделать с этими ошибками. Сервер должен быть настроен на приём запросов приложения. О том, как включить CORS для конкретных серверов, читайте на enable-cors.org.

Production-оптимизации

ng build использует конфигурацию production, если не указано иное. Эта конфигурация включает следующие возможности оптимизации сборки.

См. ng build для подробностей об опциях сборки CLI и их эффектах.

Возможности только для разработки

Когда вы запускаете приложение локально с помощью ng serve, Angular во время выполнения использует конфигурацию development, которая включает:

• Дополнительные проверки безопасности, такие как обнаружение expression-changed-after-checked.
• Более подробные сообщения об ошибках.
• Дополнительные утилиты отладки, такие как глобальная переменная ng с функциями отладки и поддержка Angular DevTools.

Эти возможности полезны при разработке, но требуют дополнительного кода в приложении, что нежелательно в production. Чтобы они не влияли отрицательно на размер бандла для конечных пользователей, Angular CLI удаляет код только для разработки из бандла при сборке для production.

Сборка приложения с ng build по умолчанию использует конфигурацию production, которая удаляет эти возможности из вывода для оптимального размера бандла.

--deploy-url

--deploy-url — опция командной строки для указания базового пути разрешения относительных URL для ресурсов, таких как изображения, скрипты и таблицы стилей, на этапе компиляции.

ng build --deploy-url /my/assets

Эффект и назначение --deploy-url пересекаются с <base href>. Оба можно использовать для начальных скриптов, таблиц стилей, ленивых скриптов и CSS-ресурсов.

В отличие от <base href>, который можно определить в одном месте во время выполнения, --deploy-url нужно жёстко задать в приложении на этапе сборки. По возможности предпочитайте <base href>.