Nginx location / vs /artifactory - nginx

Question

I am looking at the nginx configuration to set up a docker repository
###########################################################
## 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;
}
}
Why is the location directive set to /artifactory Vs / the root location

Answer 1

The location directive is /artifactory/ and not / because you are using a public context. That is to say, all access to Artifactory will be in the form of servername/artifactory/ and not servername/. This has the advantage that you can use the same URL for multiple applications, for example, something like this:
Artifactory -> servername/artifactory/
Jenkins -> servername/jenkins/
My Custom Service -> servername/myapp/
In other words, it allows you to reuse the same servername (and port) with different contexts for different applications. If your reverse proxy was listening at the root level, all the requests would be forwarded to Artifactory.
Now to answer your specific question, why does Artifactory do this? That is likely for clarity/consistency since the default tomcat shipped with Artifactory uses the artifactory keyword for its context. You are of course free to remove the public context from the NGINX configuration and everything will work as expected with the root context servername/, provided you make all the necessary changes (removing it from the rewrites, location, and X-Artifactory-Override-Base-Url).

Answer 2

Wow, this is old but ranked high on Jfrogs 'Community' Portal. Basically if you are trying to configure a reverse proxy in front of Artifactory you will have an uphill job. From Artifactory 7.x they split out ui functions and api functions across ports 8082 and 8081. Maybe good for some technical reason, but really bad for anyone trying to configure a reverse proxy in front of it. Our only currently working nginx configurations are in front of Artifactory 6.x implementations. In 7.x they made things even harder by pulling the reverse proxy config generator. The examples they have for both nginx and haproxy today on their website DO NOT WORK. The haproxy example is closest but uses old syntax that has been update in past years (regirp becomes http-request replace-path). Honestly, we are looking for alternatives to Artifactory due to lack of real support on the Internet apart from additional paid service level plans above the license cost.