Ответ 1

Запускаете ли вы приложение в качестве пользователя root? Поскольку для более низких номеров портов требуются привилегии root. Возможно, работает sudo node app.js?

НО, вы НЕ должны запускать любое приложение node.js на порту 80 с привилегиями root!!! НИКОГДА!

Мои предложения - запустить nginx перед обратным прокси-сервером в ваше приложение node.js, работающее на порту, например. 3000

Ответ 2

Если вы действительно хотите это сделать, вы можете перенаправить трафик на порт от 80 до 3000.

sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 3000

Ответ 3

Возможно, что-то еще работает на порту 80 ранее?

Возможно сделать сканирование порта и подтвердить, что он не используется уже?

nc -z <<your IP>> 80

Ответ 4

Держите это глупо просто: netcap, systemd

На обычном VPS (таком как Digital Ocean, Linode, Vultr или Scaleway), где диск является постоянным, используйте " Netcap". Это позволит пользователю без полномочий root связываться с привилегированными портами.

sudo setcap 'cap_net_bind_service=+ep' $(which node)

Помимо:

Вы также можете использовать systemd, чтобы остановить и запустить свой сервис. Поскольку systemd иногда является p.i.t.a., я написал скрипт-обертку на Go, который действительно упрощает развертывание проектов узлов:

curl https://rootprojects.org/serviceman/dist/linux/amd64/serviceman -o serviceman
chmod +x ./serviceman
sudo serviceman /usr/local/bin

cd ./my/node/project
sudo serviceman --username $(whoami) add npm start

или, если ваш сервер не называется server.js (стандарт де-факто), или дополнительные параметры:

cd ./my/node/project
sudo serviceman --username $(whoami) add node ./my-server-thing.js -- --my-options

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

Эфемерные экземпляры (т.е. EC2) не предназначены для долго работающих серверов

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

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

Вы не "настраиваете сервер", а "развертываете образ". Единственная причина, по которой вы заходите на такой сервер, - это создание прототипа или отладка создаваемого вами изображения.

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

Поэтому: хотя это правда, что, как правило, вы не должны запускать службу от имени root, типы ситуаций, в которых вы обычно используете изменчивую виртуализацию... это не имеет большого значения. У вас есть одна служба, одна учетная запись пользователя, и как только экземпляр перестает работать или иным образом "перезагружается" (или вы запускаете новый экземпляр вашего образа), у вас снова появляется новая система (что означает, что.

Межсетевые экраны: эфемерный против VPS

Такие материалы, как EC2, как правило, предназначены только для частного использования, а не для публичного просмотра. Это системы "облачного сервиса". Ожидается, что вы будете использовать дюжину различных сервисов и автоматическое масштабирование. Таким образом, вы будете использовать службу балансировки нагрузки для переадресации портов в вашу группу EC2. Обычно брандмауэр по умолчанию запрещает все. Вам необходимо перейти к управлению брандмауэром и убедиться, что порты, которые вы собираетесь использовать, действительно открыты.

Иногда у провайдеров VPS есть "корпоративные" конфигураторы брандмауэров, но чаще всего вы просто получаете необработанный доступ к виртуальной машине, и, в первую очередь, только те порты, которые вы действительно прослушиваете, получают доступ к внешнему миру (по умолчанию они обычно этого не делают). запускать случайные службы), вы можете не получить никакой дополнительной выгоды от брандмауэра. Конечно, хорошая идея, но не требование делать то, что нужно.

Не используйте EC2 в качестве VPS

Приведенный выше вариант использования может быть гораздо лучшим кандидатом для традиционной услуги VPS (как упоминалось выше: Digital Ocean, Linode, Vultr, Scaleway и т.д.), Которые намного проще в использовании и имеют гораздо меньше проблем с управлением, чтобы начать работу. Все, что вам нужно, это немного ноу-хау в bash CLI.

И, как дополнительный бонус, вам не нужно угадывать, какой будет стоимость. Они говорят вам просто $/месяц, а не ¢ /cpu/hour/gb/internal-network/external-network/etc - поэтому, если что-то идет не так, вы получаете предупреждение по электронной почте или через консоль администратора. а не неожиданный счет на 6 527 долларов.

Итог: Если вы решите использовать EC2, а вы не являетесь экспертом по DevOps с бухгалтером в штате... вам будет трудно.