O nginx pode ser executado tanto para o gitlab quanto para o taiga.io na mesma VM?

Question

Estou tendo problemas com o GitLab e Taiga.io no site mesma VM (ou seja, compartilhar o mesmo IP). Ambos usam nginx. Minha VM executa o Debian 8.

Eu tenho seguido a clássica instalação Omnibus do GitLab for Debian 8, e quando eu insiro o IP da minha VM em um navegador, o gitlab é exibido corretamente e tudo corre bem.

Depois, fechei ( sudo gitlab-ctl stop ) e instalei o Taiga, seguindo a produção configuração do ambiente . De acordo com o documento, ele usa Gunicorn e Circus para taiga-back (que serve APIs REST) e nginx para servir o frontend. Depois que /etc/nginx/sites-available|enabled/taiga , ~/taiga-back/settings/local.py e ~/taiga-front-dist/dist/conf.json forem todos configurados usando o mesmo endereço IP e nginx reiniciado ( sudo service nginx restart ) tudo vai bem também.

Agora, é possível alterar todos os endereços IP Taiga mencionados anteriormente com uma porta diferente (digamos, 8080 ), reiniciar o nginx e o Taiga agora é exibido a partir do endereço IP: 8080. Tudo bem!

Quando eu reinicio o GitLab ( sudo gitlab-ctl start ), ele diz que tudo começa suavemente. Mas quando eu tento acessá-lo (na porta padrão 80) eu recebo um 502 !

Se eu desligar o Taiga e reiniciar o GitLab, o GitLab está disponível! Basicamente, eu posso tê-los apenas separadamente, mas não ao mesmo tempo.

Eu também tentei manter o Taiga na porta 80 e mover o GitLab na porta 8080 (alterando a porta no arquivo /etc/gitlab/gitlab.rb e executando sudo gitlab-ctlr reconfigure ), mas nunca consegui executá-lo com êxito.

Eu também tentei configurar o GitLab para usar o sistema nginx (e não aquele incorporado), isto é, aquele usado por Taiga. Para isso, desativei o nginx em gitlab.rb após o doc e usando essa receita omnibus (não-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;
  }
}

junto com o Taiga:

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;
    }
}

Com essas duas configurações em /etc/nginx/sites-enabled , após uma reinicialização ( sudo service nginx restart ), meu servidor Taiga é acessível pela porta 8080, mas, estranhamente, o servidor gitlab não está mais acessível. Não 502 mas um tempo limite de conexão!

Alguém conhece nginx com uma ideia? Qualquer ajuda seria muito apreciada!

    

Answer 1

Graças à ajuda do meu provedor de TI, encontramos uma solução, que acompanha o ponto de partida da resposta do @Alex_hha: foi um erro vincular o Taiga à porta 8080 ( LSNED ...)

Então, finalmente, eu uso a instalação Debian do nginx em minha VM como um proxy reverso, desabilitei o nginx embutido dentro do GitLab (editando o arquivo /etc/gitlab/gitlab.rb ) e configurei o Taiga e o Gitlab com o arquivo de configurações dentro de /etc/nginx/sites-available ( e links simbólicos para /etc/nginx/sites-enabled ), da seguinte forma:

Taiga:

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

e o restante inalterado. E para o 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;
    }
}

Portanto, ambos são acessados pela porta 80, mas, dada a URL da solicitação, o serviço correto é chamado. Observe a ausência de default_server na configuração do GitLab.

Essa combinação de configuração faz com que todo o tráfego do GitLab seja direcionado para o GitLab e qualquer outra coisa (até mesmo URL inválido) que acabe no serviço da Taiga.

    

Answer 2

Não use a porta 8080 para o Taiga ou, pelo menos, não ligue o nginx ao localhost: 8080. Para Taiga você pode ligar o nginx a alguma interface externa específica, por exemplo algo como o seguinte

server {
    listen 192.168.127.1:8080;
    ...
}

Estou usando o Gitlab e o Jenkins na mesma máquina sem problemas. Ambos na porta 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)