Как настроить адрес внутреннего интерфейса при развертывании внешней среды

Архитектура внешний интерфейс
Как настроить адрес внутреннего интерфейса при развертывании внешней среды

Это третий день моего участия в Gengwen Challenge, смотрите подробности мероприятия:Обновить вызов

В настоящее время внешняя упаковка в основном состоит из двух аспектов: упаковки сжатых файлов и внутренних адресов доступа к API. Конечно, задействованы и другие развертывания, такие как nginx и docker, которые выходят за рамки этой статьи.

Команда упаковки на самом деле очень проста

npm run build

Адрес фонового доступа

Внешний доступ к фоновому адресу на самом деле должен различать локальную разработку и развертывание сервера.

Доступ к локальной разработке:

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

Чтобы единообразно обрабатывать доступ к интерфейсу, внешний интерфейс установит baseUrl, где bms — префикс адреса приложения.

// 路径地址：src/services/baseUrl.js

// eslint-disable-next-line import/no-mutable-exports
let baseUrl = '/api/bms';

export default baseUrl;

Файл конфигурации прокси

// 路径地址： config/config.js

proxy: {
  '/api/bms': {
    target: 'http://xxxxx:8000/', 
    changeOrigin: true,
    pathRewrite: { '^/api/bms': '/' },
  },
},

**/api/бмс здесьСоответствует baseUrl baseUrl.js. При обращении к адресу: интерфейс обращается к /api/bms/interface*. через прокси станетhttp://xxxxx:8000/interfaceЗдесь могут спросить, куда делись api/bms. Из-за этой строки кода:

pathRewrite: { '^/api/bms': '/' },

будет/api/bmsстать через прокси/

Адрес развертывания сервера:

Фронтальное развертывание:

Понимание локальной среды и развертывания сервера

Поскольку упакованные файлы, развернутые сервером, сильно отличаются от файлов локальной разработки, прокси-сервер отсутствует, и доступ осуществляется только к статическим файлам. Итак, на данный момент наш код имеет толькоbaseUrl.jsв /апи/бмс. Это относительный путь, с прямым доступом будут проблемы. Простой пример: текущий адрес развертывания среды разработки bms:
http://xxxxx:8000

Тогда адрес доступа к интерфейсу, развернутый нашим сервером:http://xxxxx:8000/api/bms/interface. Тогда swagger-адрес среды разработки:http://xxxxx:8001/interface. Это определенно не совпадает. Следовательно, внешний интерфейс должен быть в текущемbaseUrl.jsВнутри файла.

Теперь наш файл является относительным путем, поэтому его нужно преобразовать в абсолютный путь соответствующей среды.

Не будет ли здесь проблемы? Теперь у нас есть три среды: разработка, тестирование и производство. Какой из них написать, требует переменной для определения правильного набора интерфейсов адресов фонового доступа в разных средах.

Переменная BUILD_TYPE, которую можно использовать для определения среды

Это включает в себя концепцию внешней переменной среды упаковки: BUILD_TYPE. Что же касается этого понятия, то его можно игнорировать, как мы его понимали в то время? Поймите, что его можно рассматривать как переменную, ему можно задать значение, к нему можно получить доступ. Мы все можем получить к нему доступ в baseUrl.js. Мы можем определить, какой абсолютный адрес доступа API к среде baseUrl установлен, оценивая тип этой переменной.

let baseUrl = '/api/bms';

// eslint-disable-next-line no-undef
if (BUILD_TYPE === 'build') {
  baseUrl = 'http://xxxxxx:8001/api/bms';
}

if (BUILD_TYPE === 'qa') {
  baseUrl = 'http://yyyyy:8001/api/bms';
}

if (BUILD_TYPE === 'release') {
  baseUrl = 'http://zzzzzz:8001/api/bms';
}

export default baseUrl;

Установите переменную среды BUILD_TYPE.

Вышеупомянутое предназначено для использования BUILD_TYPE, но где устанавливается это значение, когда мы выполняем команду упаковки. файл package.json.

image.png
На картинке видно, что в том месте, где я рисую кружок, есть три команды. Во всех трех командах установлен BUILD_TYPE. Вы уже должны знать, для чего он здесь. Это для того, чтобы различать разные среды и использовать разные команды упаковки. , а затем установите другой BUILD_TYPE, см. здесь, с интерфейсом, с которым нужно разобраться, разобрались. Но тут как раз написана команда, а кто эту команду будет запускать, сервер сам не попросит нас выполнить команду, а если ему нужна ручная работа, то это маловато.

конфигурация команды cicd [файл .gitlab-ci.yml]

среда разработки
Потому что теперь развертывание нашей среды — это, по сути, команда docker + nginx + cicd. Так что знать об этом все же необходимо.

Конфигурация среды разработки:
Среда разработки перейдет к сборке пряжи, которая соответствует рисунку ниже, поэтому она образует замкнутый цикл.Отправьте код для разработки, cicd выполнит следующую команду, а затем установит BUILD_TYPE для сборки, а затем распечатает серверную часть. адрес доступа, то есть: адрес доступа среды разработки, настроенный вышеhttp://xxxxxx:8001/api/bms

image.png
image.png
Тестовая среда и производственная среда
Принцип тот же, что и выше, разница только в том, что при тегировании кода ветки в тестовой среде мы не можем выполнять команды среды разработки, а нужно выполнять команды тестовой среды.
image.png

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

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

отвечать: Из-за локальной среды на ранней стадии разработки обработка прокси интерфейса выполняется локально, а структура проекта идет вместе с ней, так что проблем не будет. После развертывания сервера для междоменной обработки требуется внутренний интерфейс. Поскольку существует множество способов решения междоменных проблем,Внешний проксиилиБэкэнд для кросс-доменногоиметь дело с. Таким образом, учащиеся, у которых есть время на интерфейсе или сервере, должны понимать политику единого источника и междоменную обработку.


Прокси-сервер Nginx решает проблему адреса серверной службы

После обнаружения в отдельных проектах иногда доступ к упакованному адресу интерфейса не осуществляется должным образом, когда существует среда развертывания.qa, но развернутый адрес по-прежнему является адресом среды разработки, конкретной причиной должна быть проблема переменной среды cicd. Позже наш проект должен был использовать nginx для равномерной пересылки

BaseUrl не задан при построении внешнего интерфейса., унифицировать относительный путь /api/ и одновременно настроить переадресацию прокси через сервер. Например: /api/ унифицированный интерфейс доступа, другие интерфейсные ресурсы доступа.

image.png

Категории