Я вижу много путаницы здесь. Я объясню как можно лучше.
Когда вы обслуживаете приложение с помощью команды ng serve, вы собираетесь запустить веб-сервер, локально выполненный в nodeJS. По умолчанию он работает на порту 4200, но вы можете изменить его, используя флаг: ng serve --port 4567. Делая это, вы не достигнете своего сайта, если вы наберете localhost:4200 в браузере, но вам нужно будет использовать порт 4567.
Причина, по которой порт по умолчанию равен 4200, заключается в том, что большинство скорее всего, нет других приложений, использующих этот порт.
Когда вы создаете свое приложение, в результате получается папка dist, содержащая список файлов. Все эти файлы могут быть интерпретированы браузером, а *.ts - нет.
Поскольку Typescript имеет значение superset из Javascript, его необходимо скомпилировать. То, что делает сборка, в основном. Итак, теперь у вас есть этот список файлов, готовых к развертыванию. Вот вам вопрос, который вы задали: do I need a web server?
Это зависит.
Если приложению не требуется go онлайн и он не выполняет http звонки вообще или взаимодействие с бэкэндом / дБ, вы можете просто открыть index.html прямо в браузере, и он будет работать нормально. Следовательно, нет необходимости использовать web-server.
. Если это не ваш случай, то вам нужен веб-сервер. Причина проста, каждый сайт размещен на сервере. Машина с общедоступным c IP-адресом, который может быть разрешен везде (исключая случаи, когда национальный провайдер (поставщик услуг inte rnet) разрывал соединение в начале).
Давайте возьмем SO в качестве примера. Если вы введете в браузере www.stackoverflow.com, вы попадете на сайт. Если вы введете www.stackoverflow.com:80, вы получите тот же результат.
Посмотрите здесь: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Если вы прокрутите немного вниз, вы увидите, что порт 80 используется для HTTP requests. Это стандарт, и все браузеры по умолчанию, когда вы пытаетесь перейти на сайт, будут использовать этот порт (для HTTPS-запросов порт меняется на 443, но logi c вроде бы тот же).
Вы также можете настроить брандмауэр вашего сервера так, чтобы он НЕ принимал никаких подключений к порту 80, а к порту 12443, и установить веб-сервер, который прослушивает этот порт. В результате, если вы введете www.mysite.com, браузер выдаст вам сообщение об ошибке classi c «Cannot достигают www.mysite.com». Но если вы введете mysite.com:12443, вы получите желаемый результат. В этом случае содержимое папки dist.
Вы также спросили: что произойдет, если на сервере более одного веб-приложения?
У вас есть два варианта, мне:
1) Каждый веб-сервер использует разные порты. Затем вы можете перейти к указанному вами c контенту, используя разные порты для запросов:
www.mysite.com -> standard site on port 80.
www.mysite.com:456 -> another site on port 456
and so on...
2) Используйте reverse-proxy для обработки всех различных запросов на указанном порту (по умолчанию 80 и 443 | HTTP и HTTPS).
Эта topi c действительно сложна, но давайте рассмотрим это в качестве примера. У вас есть три разных сайта, которые вы хотите разместить на своем сервере.
Вы можете использовать docker с nginx (nginx - это веб-сервер, такой как IIS или apache ) и nginx-proxy, чтобы настроить идеальный сценарий. Я опубликую некоторый код, который я лично использую на своем VPS, если кому-то это интересно.
У меня есть Dockerfile для создания основного контейнера:
FROM nginx:alpine
COPY ./site/ /usr/share/nginx/site_volume
COPY ./static/ /usr/share/nginx/assets_volume
COPY ./site.conf /etc/nginx/conf.d/default.conf
nginx config:
server {
listen 80;
server_name mysite.com;
root /usr/share/nginx/site_volume;
}
server {
listen 80;
server_name www.mysite.com
root /usr/share/nginx/site_volume;
}
server {
listen 80;
server_name static.mysite.com;
root /usr/share/nginx/assets_volume;
}
Результат после сборки и запуска контейнера:
docker build -t my-site .
docker run -d -p 80:80 my-site
заключается в том, что при переходе к mysite.com или www.mysite.com я что-то вижу. Если я перейду к static.mysite.com, я увижу что-то другое, не связанное с контентом в первых двух навигациях.
РЕДАКТИРОВАТЬ, если кому-то интересно, как запустить эти контейнеры с HTTPS-редиректом I Можно добавить код с некоторыми подробностями.