On 09/03, J. Lewis Muir wrote:
> On 09/02, Francis Daly wrote:
> > But if "the app" involves a http request to part1.php and then a http
> > request to part2.php (or: a second http request to part1.php), I don't
> > think that the symlink+realpath thing will prevent those two requests
> > going to different release versions.
>
> Hmm, good point.
>
> I'm not sure how to do a seamless web app update deploy, then. Maybe
> it's not possible without additional constraints.
After searching the web and failing to find anything addressing this
(maybe it's out there, but I couldn't find it), I'm inclined to believe
that there are roughly two choices: either the web app maintains
backward compatibility in its request API, or it doesn't.
The web app that maintains backward compatibility in its request API
will work with the symlink+realpath approach, assuming the FastCGI
server either does no caching or caches based on the file path. (The
path-based caching works because the path changes when an app update is
deployed because the version is encoded in the path.) Note, however,
that even for an app that maintains backward compatibility like this,
rolling back a deploy to a previous release would not work unless it
was a patch update (as defined in the Semantic Versioning scheme). For
example, you could safely roll back from 1.0.3 to 1.0.2, but not from
1.1.0 to 1.0.3, and not from 2.0.0 to 1.2.3.
The web app that does *not* maintain backward compatibility in its
request API will *not* work with the symlink+realpath approach. It
might work by chance depending on the timing of the deploy, the timing
of the requests, and which requests were in flight at the time of the
deploy. Or you could orchestrate the deploy to shut down the nginx
server, wait for an amount of time deemed to be the maximum time that
should ever elapse between the "part1.php" request and the "part2.php"
request (which may be impossible to determine, or may be infinite) such
that all "part2.php" requests will happen and fail because they couldn't
connect to the nginx server, deploy the app update, and then start the
nginx server again. This approach will never be 100% correct.
I'd love to be enlightened on other choices, but this is my
understanding as of now, and I think I'll proceed with the
symlink+realpath approach under the expectation that the web apps I
deploy maintain backward compatibility in their request API, or they
might just break for some users when I deploy an update in which case I
might choose my deploy time to be the time of least demand on average.
Regards,
Lewis
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
