Как работают сетевые псевдонимы docker, если существует несколько экземпляров для обновления контейнера с нулевым временем простоя? - PullRequest
Новая
       31

Как работают сетевые псевдонимы docker, если существует несколько экземпляров для обновления контейнера с нулевым временем простоя?

5 голосов
/ 29 января 2020

Итак, у меня есть: 

version: "3.6"

services:
  nginx:
    image: nginx
  app:
    image: node:latest

И моя конфигурация nginx: 

upstream project_app {
  server app:4000;
}

server {
  listen 80;
  server_name example.com;

  location / {
    proxy_pass http://project_app;
  }

Чтобы обновить контейнер без простоев (непрерывные обновления), я сначала увеличил масштаб app service to 2: 

docker-compose up -d --no-deps --scale app=2 --no-recreate app

Это создаст project_app_1 вдоль project_app.

Но на этом этапе, даже когда новый контейнер project_app_1 готов, все трафик c идет к project_app, бывшему контейнеру.

Чтобы их использовать, мне нужно запустить docker-compose restart nginx.

Теперь траффи c маршрутизатор к project_app и project_app_1, что действительно круто.

Теперь я готов убить project_app, который сейчас устарел.

Мои вопросы:

  • Нужно ли перезапускать nginx снова после его смерти, чтобы убедиться, что all traffi c маршрутизируется на project_app_1 или это несколько автоматизировано c?
  • Факт, что http://app:4000 работает, из-за конфигурации имени хоста DNS, верно? Где можно узнать больше об этом?
  • Если обнаружение завершения работы работает автоматически в nginx, нет способа сделать обнаружение запуска также автоматическим c, чтобы избежать перезапуска nginx, который вызывает Время простоя 2 секунды?

Спасибо

PS: Если вам интересен весь сценарий, который я использую, я сообщил об этом в связанной проблеме github .

Ответы [ 2 ]

1 голос
/ 05 марта 2020

Итак, я наконец-то нашел больше информации об этом.

  1. При записи server app:4000;, app - это запись DNS, которая разрешается в нескольких экземплярах.

  2. можно обновить эти записи DNS без перезапуска nginx. Подробности здесь: https://serverfault.com/a/916786/182596

Этот реддит пост и n nginx эта статья помогла также .

Обычно в конфигурации nginx необходимо установить

  1. использовать docker DNS-сервер 127.0.0.11
  2. Поместить прокси в переменную , Вот конф: 
resolver 127.0.0.11 valid=10s;

server {
  set $app app:4000;
  location / {
    proxy_pass http://$app;
  }
}

После вызова docker-compose up -d --no-deps --scale app=2 --no-recreate app он начинает маршрутизацию на оба экземпляра.

Проблема заключается в том, что при уменьшении он принимает запись DNS TTL чтобы обновить его, он больше недействителен, следовательно, с 10s у меня 50% моего трафика c снижается на [0-10s], что вполне прилично, но не идеально.

Я в настоящее время выясняется:

  • что такое хорошая длительность TTL
  • , если есть способ вручную запустить записи DNS refre sh
1 голос
/ 15 февраля 2020

вы можете использовать: 

upstream project_app {
  server app:4000 down;
  server app1:4000 down;
}

, если приложение не работает, оно переходит на app1, если приложение резервное копирование, оно использует его.

...