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
