2016-09-30 5 views
8

ich an der nginx Konfiguration freue mich auf ein Docker RepositoryNginx Standort/vs/artifactory

########################################################### 
## this configuration was generated by JFrog Artifactory ## 
########################################################### 

## add ssl entries when https has been set in config 
ssl_certificate  /etc/nginx/ssl/demo.pem; 
ssl_certificate_key /etc/nginx/ssl/demo.key; 
ssl_session_cache shared:SSL:1m; 
ssl_prefer_server_ciphers on; 
## server configuration 
server { 
    listen 443 ssl; 
    listen 80 ; 
    server_name ~(?<repo>.+)\.art.local art.local; 

    if ($http_x_forwarded_proto = '') { 
     set $http_x_forwarded_proto $scheme; 
    } 
    ## Application specific logs 
    ## access_log /var/log/nginx/art.local-access.log timing; 
    ## error_log /var/log/nginx/art.local-error.log; 
    rewrite ^/$ /artifactory/webapp/ redirect; 
    rewrite ^/artifactory/?(/webapp)?$ /artifactory/webapp/ redirect; 
    rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/$repo/$1/$2; 
    chunked_transfer_encoding on; 
    client_max_body_size 0; 
    location /artifactory/ { 
    proxy_read_timeout 900; 
    proxy_pass_header Server; 
    proxy_cookie_path ~*^/.* /; 
    proxy_pass   http://localhost:8081/artifactory/; 
    proxy_set_header X-Artifactory-Override-Base-Url $http_x_forwarded_proto://$host:$server_port/artifactory; 
    proxy_set_header X-Forwarded-Port $server_port; 
    proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; 
    proxy_set_header Host    $http_host; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    } 
} 

einzurichten Warum ist die Lage Richtlinie auf/artifactory Vs/die Wurzel Lage

+0

Persönliche Präferenz. Manchmal wird auf Anwendungen über ihren URI zugegriffen, zu anderen Zeiten über eine Subdomain (z. B. artectory.example.com). Es gibt noch andere geringfügige Implikationen bei der Verwendung vieler, vieler Subdomains, aber das ist hier nicht das Thema. –

Antwort

0

Die Lage Richtlinie ist /artifactory/ und nicht /, weil Sie einen öffentlichen Kontext verwenden. Das heißt, jeder Zugriff auf Artifactory erfolgt in Form von servername/artifactory/ und nicht servername/. Dies hat den Vorteil, dass Sie die gleiche URL für mehrere Anwendungen verwenden können, zum Beispiel, so etwas wie diese:

Artifactory ->servername/artifactory/ Jenkins ->servername/jenkins/ My Custom Service ->servername/myapp/

Mit anderen Worten, Sie können denselben Servernamen (und Port) mit unterschiedlichen Kontexten für verschiedene Anwendungen wiederverwenden. Wenn Ihr Reverseproxy auf der Stammebene abhört, werden alle Anfragen an Artifactory weitergeleitet.

Jetzt, um Ihre spezifische Frage zu beantworten, warum tut Artifactory dies? Dies ist wahrscheinlich für Klarheit/Konsistenz, da der Standard-Tomcat, der mit Artifactory ausgeliefert wird, das Schlüsselwort artifactory für seinen Kontext verwendet. Natürlich können Sie den öffentlichen Kontext aus der NGINX-Konfiguration entfernen, und alles funktioniert erwartungsgemäß mit dem Stammkontext servername/, vorausgesetzt, Sie nehmen alle notwendigen Änderungen vor (Entfernen aus den Umschreibungen, dem Speicherort und der X-Artefactory-Override-Base) -Url).