Как использовать один и тот же файл nginx.conf для обратного прокси-сервера для docker-compose и kubernetes - PullRequest
Новая
       10

Как использовать один и тот же файл nginx.conf для обратного прокси-сервера для docker-compose и kubernetes

0 голосов
/ 06 сентября 2018

в Кубе, у меня есть один контейнер с двумя контейнерами * контейнер 1: обратный прокси-сервер nginx * контейнер 2: myapp

для целей тестирования, у меня также есть файл составления докера, включающий две службы * сервис 1 обратный прокси nginx * сервис 2: myapp

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

//for docker, nginx.conf
...
   upstream  web{
        server myapp:8080;
    }
....
            proxy_pass         http://web;

//for Kube, nginx.conf


   ...
    upstream  web{
        server localhost:8080;
    }
    ....

            proxy_pass         http://web;
    }

Я хотел бы иметь один файл nginx.conf для поддержки как kube, так и docker-compose. Один из способов, который я могу придумать, - передать переменную времени выполнения env, чтобы я мог разместить вышестоящий хост в entrypoint.sh.

Есть ли другие способы сделать это?

спасибо

Ответы [ 3 ]

0 голосов
/ 06 сентября 2018

Вам нужно сделать две вещи.

Сначала разделите это на две капсулы. (Как правило, у вас должен быть один контейнер в модуле; типичными исключениями являются такие вещи, как журналы и сетевые контейнеры "sidecar", которые должны совместно использовать файловую систему и сетевое пространство с основным контейнером.) Это, вероятно, означает, что вы берете свои существующие спецификация pod (или лучшая спецификация развертывания), взятие всего материала вокруг блока containers: и создание его второй копии, и помещение одного контейнера в каждый.

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

metadata:
  name: web
  labels:
    app: web

Во-вторых, вам нужно создать сервис Kubernetes, который будет указывать на "веб" модуль. Это соответствует на этикетках, которые мы только что установили 

metadata:
  name: web
spec:
  selector:
    app: web

Теперь имя службы приведет к существованию DNS-имени web.default.svc.cluster.local (где «default» - это имя пространства имен Kubernetes). default.svc.cluster.local устанавливается в качестве домена поиска DNS по умолчанию, поэтому web разрешит службе пересылку в модуль.

Документация Kubernetes содержит более полный пример такого рода вещей (с использованием PHP и nginx, но единственным кодом являются манифесты YAML Kubernetes, поэтому он должен быть довольно применимым).

0 голосов
/ 19 марта 2019

Я сталкивался с этим вопросом, потому что у нас та же проблема.

Я заметил, что другие ответы предлагали разделить nginx и сервер приложений на две разные службы / модули. Хотя это, безусловно, решение, мне больше нравится автономный Pod с nginx и сервером приложений вместе. Это хорошо работает для нас, особенно с php-fpm, который может использовать сокет unix для связи в одном модуле, что значительно снижает внутреннюю сеть http.

Вот одна идея:

Создайте базовый файл конфигурации nginx, например, proxy.conf и настройте docker, чтобы добавить его в каталог conf.d при создании образа. Команда: 

ADD proxy.conf /etc/nginx/conf.d/proxy.conf

В proxy.conf опустите конфигурацию upstream, оставив ее на потом. Создайте другой файл, run.sh, и добавьте его к изображению, используя Dockerfile. Файл может быть следующим: 

#!/bin/sh

(echo "upstream theservice { server $UPSTREAM_NAME:$UPSTREAM_PORT; }" && cat /etc/nginx/conf.d/proxy.conf) > proxy.conf.new
mv proxy.conf.new /etc/nginx/conf.d/proxy.conf

nginx -g 'daemon off;'

Наконец, запустите nginx из скрипта run.sh. Команда Dockerfile: 

CMD /bin/sh run.sh

Хитрость в том, что поскольку контейнер инициализируется таким образом, файл конфигурации не записывается постоянно, и конфигурация обновляется соответствующим образом. Установите соответствующие значения ENV в зависимости от того, используете ли вы из docker-compose или Kubernetes.

Позвольте мне также поделиться менее подходящим решением , которое более хакерно , но также проще ...

В Kubernetes мы изменили образ докера CMD таким образом, чтобы он изменял конфигурацию nginx до запуска контейнера. Мы используем sed, чтобы обновить имя верхнего уровня до localhost, чтобы сделать его совместимым с сетью Kubernetes Pod. В нашем случае это выглядит так: 

  - name: nginx
    image: our_custom_nginx:1.14-alpine
    command: ["/bin/ash"]
    args: ["-c", "sed -i 's/web/127.0.0.1/g' /etc/nginx/conf.d/default.conf && exec nginx -g 'daemon off;'"]

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

0 голосов
/ 06 сентября 2018

Я думаю, что лучший способ сделать это - использовать kubernetes Сервис Вы можете сопоставить имя службы docker-compose с именем службы kubernetes. Таким образом, вам не нужно изменять файл nginx.conf

...