Mapeando hudson para um subdomínio por meio de proxying nginx

6

Agora estou tentando configurar o nginx como um proxy reverso para o Hudson, para que possa ser acessado em

http://build.example.com
diretamente. Eu já instalei o Hudson no Tomcat e verifiquei que posso acessar o Hudson em
http://127.0.0.1:8080/hudson

Foi muito fácil chegar onde é possível acessar o hudson no link . Mas quando eu tentei configurar o proxy para remapear o diretório / hudson, as coisas começam a dar errado. Nenhum dos arquivos de imagem ou css estão sendo carregados.

Uma rápida olhada no log de acesso do nginx indica que muitas solicitações estão sendo feitas para os recursos em / hudson ou / hudson / static. Essas solicitações não estão sendo encaminhadas (ou reescritas) para o Tomcat corretamente. Mas depois de cavar por várias horas, estou perdido em como consertar esse problema simples.

As configurações do nginx que estou usando parecem

server {
    listen          80;
    server_name     build.example.com;
    location / {
        proxy_pass        http://127.0.0.1:8080/hudson;
        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;
    }
}

Alguém pode lançar alguma luz sobre isso? Tem que ser muito simples de configurar, mas não consigo encontrar a solução em qualquer lugar na rede.

Atualizar

Meus sinceros agradecimentos a todos aqueles que dedicaram tempo para responder a esta pergunta. Depois de tentar várias soluções, acho que a maneira mais direta de lidar com esse problema específico é ...

A) Deixe sozinho Como o @VonC sugeriu, deixe-o ficar em um subdiretório. É direto e vamos ter certeza de que nada vai quebrar. Ou ...

B) Implante o aplicativo no diretório ROOT do tomcat webapp Talvez esta não seja a melhor maneira de fazer as coisas se você quiser hospedar várias aplicações web com uma instalação de tomcat. Mas um administrador pode querer configurar uma instalação separada do tomcat apenas para executar o Hudson / Jenkins de qualquer maneira. O Tomcat não é capaz de executar diferentes aplicativos hospedados como usuários diferentes e qualquer um que configure o Hudson / Jenkins para CI provavelmente desejará executá-lo como um usuário específico ("build", por exemplo). Nesse caso, a implementação no ROOT faz mais sentido, o que pode ser mapeado para build.example.com de maneira muito simples.

    
por odie 29.03.2011 / 07:13

3 respostas

3

Aqui está o meu arquivo de configuração nginx, apesar de eu acessar o Hudson por meio de https (porta 443):

O truque com o proxy reverso (Apache ou Nginx) é sempre manter o mesmo caminho :
Se você quiser redirecionar para a_long_and_complex_address/hudson , mantenha a parte / hudson : myserver/hudson .
Não tente redirecionar myserver para a_long_and_complex_address/hudson : todos os tipos de scripts e imagens, com caminhos absolutos (' / ') serão quebrados.
Redirecionar myserver/hudson para a_long_and_complex_address/hudson .

Além disso, você pode redirecionar myserver/other_services para a_long_and_complex_address/other_services também;)

worker_processes  1;

error_log  logs/error.log  debug;
pid        logs/nginx.pid;

events {
    worker_connections  250;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    access_log  logs/access.log  main;

    sendfile        on;
    #tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  150;
    #gzip  on;

    port_in_redirect   on;
    proxy_redirect     off;
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

    server {
        listen       443;
        server_name  (some alias);
        # default max client body size was 1m! => Error code is 413
        # here: max 10Go
        client_max_body_size 10000m;

        ssl                  on;
        ssl_certificate      /home/xxx/.ssl/my.crt;
        ssl_certificate_key  /home/xxx/.ssl/my.key;
        ssl_session_timeout  5m;
        #ssl_protocols SSLv2 SSLv3 TLSv1; # NO: SSLv2 prohibited
        ssl_protocols  SSLv3 TLSv1;
        ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
        ssl_prefer_server_ciphers   on;

        rewrite ^/hudson$ https://myserver/hudson/ redirect;
        location /hudson/ {
          proxy_pass https://complex_address:8xx3/hudson/;
        }
    }
}
    
por 29.03.2011 / 08:20
2

A partir das experiências que tive com o nginx, a maneira como você especifica URLs para o proxy é um pouco estranha (porque você precisa especificar o URL completo em vez de apenas um diretório). Acredito que sua configuração poderia ser algo assim:

upstream 127.0.0.1:8080 {
  ip_hash;
  server 127.0.0.1:8080;
}

location ~* ^/(.*) {
  proxy_pass http://127.0.0.1:8080/hudson/$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;
}

Deixe-me saber se funciona para você.

Editar: para solucionar as solicitações absolutas, você precisará adicionar uma segunda definição de local

location ~* ^/hudson/(.*) {
  proxy_pass http://127.0.0.1:8080/hudson/$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;
}

ou adicione o redirecionamento que Alaz recomendou:

location /hudson {
  rewrite ^/hudson(.*)$ $1 redirect;
}

Infelizmente, a menos que você reescreva a fonte do hudson para recuperar arquivos de recursos por caminho relativo, esta é sua única solução, a menos que o nginx tenha um plugin de modificação de fluxo http que não conheço mod_proxy_html para o apache ...

    
por 29.03.2011 / 11:23
1

Provavelmente, o Hudson retorna uma página HTML que se refere a recursos usando caminhos absolutos. E calcula esses caminhos usando o "contextPath" do aplicativo da Web (igual a "/ hudson" no seu caso).

O Nginx apenas passa o HTML para um navegador e não altera o conteúdo da página. Portanto, seu navegador solicita URLs "/ hudson / ...".

Tente adicionar mais um local à configuração do Nginx (não testei, você deve entender a ideia):

location /hudson {
  rewrite ^/hudson(.*)$ $1 break;
}

Se você não quiser que seus usuários vejam o prefixo "/ hudson", emita 301/302 redirecionamentos sobre essas solicitações:

location /hudson {
  rewrite ^/hudson(.*)$ $1 redirect;
}

redirect resulta em 302; permanent resulta em 301

    
por 29.03.2011 / 11:53