Будем расширять границы контента. Сейчас покажу магию, знать это должен каждый инженер. Мотай на ус, пригодится.
У нас в компании достаточно банальная инфраструктура, в которую входит балансировщик и несколько нод на которых крутится nodejs приложение с 3000м портом, короче говоря апиха.
bashdays-b1:443
-> bashdays-w1:3000
-> bashdays-w2:3000
-> bashdays-w3:3000
-> bashdays-w4:3000
К примеру от клиентов идут POST запросы к апихе, запросы попадают на сервер b1, затем nginx распределяет запросы по нодам w1-w4 и отдает в ответ json. Примитивная балансировка нагрузки, но достаточно стабильная.
В какой-то момент мне необходимо добавить еще одну ноду с новой версией nodejs приложения.
Назовем её bashdays-w5. Эта нода не должна обслуживать клиентов, но должна отдавать данные тестировщикам, чтобы те могли потыкать и протестировать в условиях продакшена. Ну а ты как думал? Тестируем на проде, можем себе позволить )))
Городим в nginx на b1 такой велосипед:
map $http_x_backend $backend {
bashdays-w5 192.168.0.5:3000; # w5
default backend;
}
upstream backend {
server 192.168.0.1:3000; # w1
server 192.168.0.2:3000; # w2
server 192.168.0.3:3000; # w3
server 192.168.0.4:3000; # w4
}
location / {
add_header X-Upstream $upstream_addr;
proxy_pass http://$backend;
}
Объясняю что происходит, клиенты идут на b1 и попадают по умолчанию в upstream backend, где прописаны ноды w1-w4.
Тестировщики подставляют заголовок X-Backend: bashdays-w5 в своих запросах и попадают на w5. То есть для обычных пользователей ничего не изменилось, но QA теперь с помощью заголовка X-Backend: bashdays-w5 могут попасть на новую ноду и затыкать ее своими тестами.
В location есть директива add_header X-Upstream, она выведет в ответе nginx на какую ноду ты попал, удобно для дебага.
В раздел map можно добавить еще кучу нод, которые не будут участвовать в обслуживании клиентов, но ты в любой момент сможешь на них попасть с помощью заголовка.
Если у тебя не апиха, а веб приложение, можешь воспользоваться плагином ModHeader, есть для фокса и хрома. В нём можно легко подставить все необходимые заголовки и попасть туда куда тебе нужно, или не нужно.
Конфигурация nginx это как стихи писать, есть какие-то базовые слова и правила, но в большинстве случаев 90% функционала вообще не используется. Потому что, документацию никто не читает и люди делают так, как научились или подсмотрели на stackoverflow. Вот такие пироги.
