Простые варианты развертывания

Последнее обновление 17 июля 2019 08:10:20 (UTC / GMT +8 часов)

script1adsense2code

script1adsense3code

Перед полным развертыванием приложения вы можете протестировать процесс, создать конфигурацию и развернутое поведение с помощью одного из этих промежуточных методов.

Сборка и обслуживание с диска

Во время разработки вы обычно используете команду ng serve для создания, просмотра и обслуживания приложения из локальной памяти, используя webpack-dev-server. Однако, когда вы будете готовы к развертыванию, вы должны использовать команду ng build для сборки приложения и развертывания артефактов сборки в другом месте.

Обе сборки ng и ng служат для очистки выходной папки перед сборкой проекта, но только команда сборки ng записывает сгенерированные артефакты сборки в выходную папку.

Выходная папка по умолчанию является dist / project-name /. Для вывода в другую папку измените outputPath в angular.json.

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

На первом терминале выполните команду ng build в режиме просмотра, чтобы скомпилировать приложение в папку dist.

````ng build -watch```

Как и команда ng serve, она восстанавливает выходные файлы при изменении исходных файлов.

На втором терминале установите веб-сервер (например, lite-server) и запустите его для выходной папки. Например:

lite-server --baseDir="dist"

Сервер автоматически перезагрузит ваш браузер при выводе новых файлов.

Базовое развертывание на удаленном сервере

Для простейшего развертывания создайте производственную сборку и скопируйте выходной каталог на веб-сервер.

Начните с производственной сборки:

ng build --prod

Скопируйте все содержимое выходной папки (по умолчанию dist /) в папку на сервере.
Настройте сервер для перенаправления запросов на отсутствующие файлы в index.html. Узнайте больше о перенаправлениях на стороне сервера ниже.

Это простейшее готовое к развертыванию развертывание вашего приложения.

Развертывание на страницах GitHub

Другой простой способ развернуть ваше приложение Angular - использовать GitHub Pages.

Вам необходимо создать учетную запись GitHub, если у вас ее нет, а затем создать репозиторий для вашего проекта. Запишите имя пользователя и имя проекта в GitHub.
Создайте свой проект, используя имя проекта Github, с помощью команды Angular CLI ng build и параметров, показанных здесь:

ng build --prod --output-path docs --base-href /<project_name>/

Когда сборка будет завершена, создайте копию файла docs / index.html и назовите его docs / 404.html.
Зафиксируйте свои изменения и нажмите.
На странице проекта GitHub настройте его для публикации из папки docs.

Вы можете увидеть развернутую страницу по адресу https: // <имя_пользователя> .github.io / <имя_проекта> /.

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

В этом разделе описываются изменения, которые вы могли внести на сервер или в файлы, развернутые на сервере.

Маршрутизированные приложения должны возвращаться к index.html

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

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

Маршрутизируемое приложение должно поддерживать «глубокие ссылки». Глубокая ссылка - это URL-адрес, который указывает путь к компоненту внутри приложения. Например, http://www.mysite.com/heroes/42 - это глубокая ссылка на страницу сведений о герое, которая отображает героя с id: 42.

Нет проблем, когда пользователь переходит на этот URL из запущенного клиента. Маршрутизатор Angular интерпретирует URL-адрес и маршруты к этой странице и герою.

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

Статический сервер обычно возвращает index.html, когда получает запрос на http://www.mysite.com/. Но он отклоняет http://www.mysite.com/heroes/42 и возвращает ошибку 404 - не найден, если только он не настроен для возврата index.html.

Примеры резервной конфигурации

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

Apache: добавьте правило перезаписи в файл .htaccess, как показано (https://ngmilk.rocks/2015/03/09/angularjs-html5-mode-or-pretty-urls-on-apache-using-htaccess/):

RewriteEngine On
    # If an existing asset or directory is requested go to it as it is
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
    RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
    RewriteRule ^ - [L]
    # If the requested resource doesn't exist, use index.html
RewriteRule ^ /index.html

Демонстрация в реальном времени:

См. Pen OYzpoa от w3resource ( @ w3resource ) на CodePen .

Nginx: используйте файлы try_files, как описано в шаблонах веб-приложений Front Controller, измененных для обслуживания index.html:

try_files $uri $uri/ /index.html;

Демонстрация в реальном времени:

См. Pen OYzpaa от w3resource ( @ w3resource ) в CodePen .

IIS: добавьте правило перезаписи в web.config, аналогичное показанному в примере кода ниже:

<system.webServer>
  <rewrite>
    <rules>
      <rule name="Angular Routes" stopProcessing="true">
        <match url=".*" />
        <conditions logicalGrouping="MatchAll">
          <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
          <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
        </conditions>
        <action type="Rewrite" url="/index.html" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

Демонстрация в реальном времени:

Смотрите Pen GayWeX от w3resource ( @ w3resource ) на CodePen .

GitHub Pages: вы не можете напрямую настроить сервер GitHub Pages, но вы можете добавить страницу 404. Скопируйте index.html в 404.html. Он все равно будет использоваться в качестве ответа 404, но браузер обработает эту страницу и загрузит приложение должным образом. Это также хорошая идея, чтобы обслуживать из docs / on master и создавать файл .nojekyll
Хостинг Firebase: добавьте правило перезаписи.

"rewrites": [ {
  "source": "**",
  "destination": "/index.html"
} ]

Демонстрация в реальном времени:

См. Pen QRapXL от w3resource ( @ w3resource ) в CodePen .

Запрос услуг с другого сервера (CORS)

Разработчики Angular могут столкнуться с ошибкой совместного использования ресурсов между источниками при отправке запроса на обслуживание (обычно запрос на обслуживание данных) на сервер, отличный от собственного хост-сервера приложения. Браузеры запрещают такие запросы, если сервер не разрешает их явно.

Клиентское приложение ничего не может сделать с этими ошибками. Сервер должен быть настроен на прием запросов приложения.

Предыдущий: Создание и обслуживание приложений Angular
Далее: Angular Language Service