Как маршрутизировать на разные серверы и пространства имен - PullRequest
Новая
       79

Как маршрутизировать на разные серверы и пространства имен

0 голосов
/ 03 апреля 2020

Пожалуйста, прости меня, если это немного глупо, мои навыки DevOps / архитектуры минимальны, поэтому я не совсем уверен в правильной терминологии.

У меня есть приложение реакции, размещенное на AWS, которое я хочу разместить на root mysite.com, а также некоторые «подкаталоги», например, mysite.com/items и mysite.com/category.

Кроме того, я хочу иметь блог, размещенный в другом месте, но доступный по адресу mysite.com/blog и некоторые другие страницы c, такие как mysite.com/about, mysite.com/contact. Я хотел бы, чтобы эти stati c страницы были размещены в одном месте (я думаю, веб-поток).

Это похоже на сложную настройку, но мне интересно, что было бы лучшим решением , будет ли работать обратный прокси с Nginx, если да, то как бы вы его настроили? Существуют ли другие «безсерверные» решения, которые могут работать?

Возможно, есть способ отправить весь трафик c на сервер stati c pages, если это не root, а specii c /items или /category или /blog?

1 Ответ

1 голос
/ 03 апреля 2020

Привет базовая c конфигурация может выглядеть следующим образом: 

server {
    listen 8080;
    return 200 "Blog \n";
}

server {
    listen 8081;
    return 200 "About and Contact \n";
}

server {
    listen 80;

    location = /about {
        proxy_pass http://localhost:8081;
    }

    location  /blog {
        proxy_pass http://localhost:8080;
    }
}

Позвольте мне добавить к ней немного текста:)

, если вы просто хотите иметь местоположение / около без что-нибудь еще в месте, которое вы можете использовать = /about

, попытка добавить что-то позади /about вроде /about/foo приведет к 404.

Если вы захотите прокси-блог для некоторых другое место использования /blog. С этой конфигурацией вы можете добавить что-нибудь в ваше местоположение, например /blog/test/, и оно все равно ответит 200. 

[root@localhost conf.d]# curl -v localhost/blog/test
* About to connect() to localhost port 80 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET /blog/test HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.17.6
< Date: Tue, 17 Mar 2020 06:09:31 GMT
< Content-Type: application/octet-stream
< Content-Length: 12
< Connection: keep-alive
<
/blog/test
* Connection #0 to host localhost left intact

Безсерверный путь в разработке

использует что-то в вашем отреагируйте приложение, чтобы направить трафик c к нужной цели.

https://create-react-app.dev/docs/proxying-api-requests-in-development#configuring -the-proxy-вручную

Я сделал это для одного из моих проектов и его работа велика!

Я поделюсь своим файлом, не адаптируя его к вашему вопросу, просто как общее руководство и идея. 

const proxy = require('http-proxy-middleware');

module.exports = function (app) {
    app.use('/api', proxy({
        target: 'http://localhost:8080',
        changeOrigin: true,
    }));

    app.use('/img', proxy({
        target: 'http://localhost:8080',
        changeOrigin: true,
    }));

    app.use('/oauth', proxy({
        target: 'http://localhost:8080',
        changeOrigin: true,
    }));
};

Этот файл (setupProxy. js) находится в каталоге thr sr c на уровне root.

Для производства

Я просто знать о некоторой интеграции с express ontop node.js. Поскольку проксирование глубоко связано с http-protocoll, вам крайне необходим какой-то серверный компонент, понимающий протокол http.

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

...