Назад | Перейти на главную страницу

Может ли nginx работать как для gitlab, так и для taiga.io на одной виртуальной машине?

У меня проблемы с бегом GitLab и Taiga.io на одной виртуальной машине (т.е. с одним и тем же IP). Оба используют nginx. Моя виртуальная машина работает под управлением Debian 8.

Я следил за классикой Установка омнибуса GitLab для Debian 8, и когда я ввожу IP-адрес своей виртуальной машины в браузере, gitlab обслуживается правильно, и все идет хорошо.

Потом выключил (sudo gitlab-ctl stop), и я установил Тайгу, следуя настройка производственной среды. Согласно документу, он использует Gunicorn и Circus для taiga-back (который обслуживает REST API) и nginx для обслуживания интерфейса. однажды /etc/nginx/sites-available|enabled/taiga, ~/taiga-back/settings/local.py и ~/taiga-front-dist/dist/conf.json все настроены с использованием одного и того же IP-адреса, и nginx перезапускается (sudo service nginx restart) тоже все идет хорошо.

Теперь можно изменить все вышеупомянутые IP-адреса Тайги на другой порт (скажем, 8080), перезапустите nginx, и Тайга теперь обслуживается с IP-адреса: 8080. Все в порядке!

Когда я перезапускаю GitLab (sudo gitlab-ctl start), там написано, что все запускается гладко. Но когда я пытаюсь получить к нему доступ (по умолчанию порт 80), я получаю 502!

Если я выключу Тайгу и перезапущу GitLab, хо-хо, GitLab станет доступен! В принципе, я могу иметь их только по отдельности, но не одновременно.

Я также пытался сохранить Тайгу на 80-м порту и перенести GitLab на 8080-й (изменив порт в файле /etc/gitlab/gitlab.rb и бег sudo gitlab-ctlr reconfigure), но мне так и не удалось его успешно запустить.

Я также попытался настроить GitLab для использования системного nginx (а не встроенного), то есть того, который используется Тайгой. Для этого я отключил nginx на gitlab.rb после док, и используя этот рецепт омнибуса (без SSL):

## GitLab 8.3+
##
## Lines starting with two hashes (##) are comments with information.
## Lines starting with one hash (#) are configuration parameters that can be uncommented.
##
##################################
##        CONTRIBUTING          ##
##################################
##
## If you change this file in a Merge Request, please also create
## a Merge Request on https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests
##
###################################
##         configuration         ##
###################################
##
## See installation.md#using-https for additional HTTPS configuration details.

upstream gitlab-workhorse {
  server unix:/var/opt/gitlab/gitlab-workhorse/socket;
}

## Normal HTTP host
server {
  ## Either remove "default_server" from the listen line below,
  ## or delete the /etc/nginx/sites-enabled/default file. This will cause gitlab
  ## to be served if you visit any address that your server responds to, eg.
  ## the ip address of the server (http://x.x.x.x/)n 0.0.0.0:80 default_server;
  listen 80 default_server;
  #listen [::]:80 default_server;
  server_name gitlab.<replaced with company URL> <replace with VM IP address>; ## Replace
  server_tokens off; ## Don't show the nginx version number, a security best practice
  root /opt/gitlab/embedded/service/gitlab-rails/public;

  ## See app/controllers/application_controller.rb for headers set

  ## Individual nginx logs for this GitLab vhost
  access_log  /var/log/nginx/gitlab_access.log;
  error_log   /var/log/nginx/gitlab_error.log;

  location / {
    client_max_body_size 0;
    gzip off;

    ## https://github.com/gitlabhq/gitlabhq/issues/694
    ## Some requests take more than 30 seconds.
    proxy_read_timeout      300;
    proxy_connect_timeout   300;
    proxy_redirect          off;

    proxy_http_version 1.1;

    proxy_set_header    Host                $http_host;
    proxy_set_header    X-Real-IP           $remote_addr;
    proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    proxy_set_header    X-Forwarded-Proto   $scheme;

    proxy_pass http://gitlab-workhorse;
  }
}

вместе с этим для Тайги:

server {
    listen 8080 default_server;
    server_name taiga.<replaced with company URL> <replace with VM IP address>; 

    large_client_header_buffers 4 32k;
    client_max_body_size 50M;
    charset utf-8;

    access_log /opt/taiga/logs/nginx.access.log;
    error_log /opt/taiga/logs/nginx.error.log;

    # Frontend
    location / {
        root /opt/taiga/taiga-front-dist/dist/;
        try_files $uri $uri/ /index.html;
    }

    # Backend
    location /api {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://127.0.0.1:8001/api;
        proxy_redirect off;
    }

    # Django admin access (/admin/)
    location /admin {
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Scheme $scheme;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://127.0.0.1:8001$request_uri;
        proxy_redirect off;
    }

    # Static files
    location /static {
        alias /opt/taiga/taiga-back/static;
    }

    # Media files
    location /media {
        alias /opt/taiga/taiga-back/media;
    }
}

С этими двумя конфигами в /etc/nginx/sites-enabled, после перезапуска (sudo service nginx restart) мой сервер Taiga доступен через порт 8080, но, как ни странно, сервер gitlab больше не доступен. Нет 502, но таймаут соединения!

Кто-нибудь знает nginx с идеей? Любая помощь будет принята с благодарностью!

Благодаря помощи моего ИТ-провайдера мы нашли решение, которое соответствует отправной точке ответа @Alex_hha: было ошибкой привязать Тайгу к порту 8080 (LSNED...)

Итак, наконец, я использую установку nginx в Debian в моей виртуальной машине в качестве обратного прокси, отключил встроенный nginx внутри GitLab (отредактировав файл /etc/gitlab/gitlab.rb файл) и настроил и Тайгу, и Gitlab с файлом конфигурации внутри /etc/nginx/sites-available (и символические ссылки на /etc/nginx/sites-enabled), в дальнейшем:

Тайга:

server {
    listen 80 default_server;
    server_name taiga.<company URL> <VM IP address>;

а остальные без изменений. А для Gitlab:

server {
    listen 80;
    server_name gitlab.<company URL>;

    large_client_header_buffers 4 32k;
    client_max_body_size 50M;
    charset utf-8;

    access_log /opt/gitlab/logs/nginx.access.log;
    error_log /opt/gitlab/logs/nginx.error.log;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host               $host;
        proxy_set_header X-Real-IP          $remote_addr;
        proxy_set_header X-Forwarded-For    $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto  $scheme;
    }
}

Таким образом, оба доступны через порт 80, но с учетом URL-адреса запроса вызывается нужная служба. Обратите внимание на отсутствие default_server в конфигурации GitLab.

Эта комбинация конфигурации заставляет весь трафик GitLab идти в GitLab, а все остальное (даже недействительный URL) попадает в сервис Taiga.

Не используйте порт 8080 для Тайги или хотя бы не привязывайте nginx к localhost: 8080. Для Тайги вы можете привязать nginx к определенному внешнему интерфейсу, например, примерно так

server {
    listen 192.168.127.1:8080;
    ...
}

Я без проблем использую Gitlab и Jenkins на одной машине. Оба они на порту 8080

# lsof -n -P -i tcp:8080
COMMAND   PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java    18983 jenkins  155u  IPv6 639617      0t0  TCP 192.168.88.87:8080 (LISTEN)
ruby    19098     git    9u  IPv4 113752      0t0  TCP 127.0.0.1:8080 (LISTEN)
ruby    19141     git    9u  IPv4 113752      0t0  TCP 127.0.0.1:8080 (LISTEN)
ruby    19144     git    9u  IPv4 113752      0t0  TCP 127.0.0.1:8080 (LISTEN)
ruby    19147     git    9u  IPv4 113752      0t0  TCP 127.0.0.1:8080 (LISTEN)
ruby    19150     git    9u  IPv4 113752      0t0  TCP 127.0.0.1:8080 (LISTEN)