<div dir="ltr">Hi Ed,<div><br></div><div>Mixlr did something along these lines before, where they scripted nginx with lua, looking up the data via redis:</div><div><br></div><div><a href="http://devblog.mixlr.com/2012/09/01/nginx-lua/">http://devblog.mixlr.com/2012/09/01/nginx-lua/</a><br>

</div><div><br></div><div>I looked into it at Shutl and found the custom compilation etc of nginx to be a real pain, the lua/nginx modules to be a bit of a ghetto and of course, hard to test. In the end, we ended up segmenting in nginx based on the request itself. In our case, most requests were https/api/json with identifying headers, so were able to use that header to segment. A relatively small customer list (our customers are big retailers, rather than consumers) meant we could just configure which customers went where in chef and redeploy.</div>

<div><br></div><div>HTH - this deployment stuff is my special area of interest and would be happy to kick around some ideas off list if helpful :)</div><div><br></div><div>Cheers,</div><div><br></div><div>Sam</div><div><br>

</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 4 March 2014 14:29, Ed James (Alt) <span dir="ltr"><<a href="mailto:ed.james.spam@gmail.com" target="_blank">ed.james.spam@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div>
                    Hi all
                </div><div><br></div><div>We make heavy use of AWS services and we are finding that ELB is not quite meeting our needs. ELB allows some level of control over traffic, but it’s dumb in the sense that it’s done purely on load. You cannot put any real logic into ELB. What we want is to direct a user’s requests based on an application setting - this could be in the db, memcache, redis, whatever. The retrieval of the setting is another problem I think. It’s the logic around that setting's value that I’m interested in.</div>

<div><br></div><div>We are doing a large upgrade of our platform and we want to run both the new version and old version in production in parallel. We want to control which customers get to see the new version and slowly increase the number of customer who can. If there is a problem we can just send all traffic back to the old version in an instant. This could just as easily apply to large feature deployments.</div>

<div><br></div><div>Does anyone have any experience with this kind of use-case?</div><div><br></div><div>Thanks,</div><div>Ed.</div>
            <br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>