On 08/30, j94305 wrote: > I've been following this, and I would take a slightly different approach. > > 1. Serve all apps under /{app}/releases/{version}/{path} as you have them > organized in the deployment structure in the file system. > > 2. Forget about symbolic links and other makeshift versioning/defaulting in > the file system. > > 3. Use a keyval mapping to handle redirections (307) of > /{app}/current/{stuff} to /{app}/releases/{currentVersion}/{stuff}, where > the keyval mapping provides {app} => {currentVersion}. You can update an > manage this during deployment.
Sorry, I forgot about your post! Thank you for your suggestions! Is this a keyval? https://nginx.org/en/docs/http/ngx_http_keyval_module.html > We usually include this in a CI/CD pipeline after deployment to dynamically > switch to the last version (using a curl request to the NGINX API). If you > can't use keyvals, use a static map and dynamically generate that "map" > directive's mapping. Restart NGINX to reflect changes. Keyvals let you do > this on the fly. Is this a static map? https://nginx.org/en/docs/http/ngx_http_map_module.html And by "dynamically generate" do you mean generate the map directive as a config file that would be included from the main config and then cause nginx to reload its config? > The major advantage of this approach is with updates. You are most likely > going to run into issues with browser or proxy caching if you provide > different versions of files/apps under the same path. By having a canonical > form that respects the version structure, you are avoiding this altogether. > Yet, you have the flexibility to run hotfixes (replace existing files in an > existing version without creating a new one), or experimental versions > (which won't update the "current" pointer). Interesting. What I was trying to do with $realpath_root, I thought was similar to what you're describing. However, when you mention browser or proxy caching, then I'm not sure. Are you suggesting serving from a different URI for each version of the app? If not, then I don't understand how your proposal behaves differently than the symlink+realpath idea. (But this may be because you wrote this on Aug 30, and the symlink+realpath idea had not been clearly stated yet.) > I would try to keep the complexity low. Agreed! However, changing a symlink (albeit with some nginx config changes to use $realpath_root and such) is pretty simple to me, so it's a little harder for me to see using a keyval or a static map as keeping the complexity low. But if I understand your proposal correctly, it would be more straightforward in terms of not needing to use symlinks at all and not needing to worry about $realpath_root vs. $document_root. Instead, you just use variables, and to update the variables, you just use the API if using a keyval, or cause nginx to reload its config if using the static map. Thank you for the suggestions! Regards, Lewis _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx