<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 27, 2017 at 7:04 AM, Michael <span class="" id=":anu.1" tabindex="-1">Grauer</span> <span dir="ltr"><<a href="mailto:michael.grauer@kitware.com" target="_blank"><span class="" id=":anu.2" tabindex="-1">michael</span>.<span class="" id=":anu.3" tabindex="-1">grauer</span>@<span class="" id=":anu.4" tabindex="-1">kitware</span>.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>[...]</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I hope you don't mind if I ask you some follow-up questions :)  Just trying to understand your setup and choices in more detail.</div></div></blockquote><div><br></div><div>Of course! </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I agree that your security setup sounds reasonable, HTTPS to load balancer, HTTP from load balancer to Girder (though I have more questions on this below), assuming the instances are not visible to the outside world and only to the LB via the VPN, and Mongo/Instances talking to each other inside the same VPN.  Out of curiosity (rather than suggesting a policy), how do you handle ssh, are each of the machines accessible to ssh or do you have a VPN ssh gateway machine?</div></div></blockquote><div><br></div><div>Both the Girder instances and the EC2 machine with the <span class="" id=":anu.5" tabindex="-1">Mongo</span> database have public <span class="" id=":anu.6" tabindex="-1">IP</span> addresses, share the same <span class="" id=":anu.7" tabindex="-1">VPC</span> (private network) and all the machines support ssh access from the outside. On the instances under the Elastic Beanstalk (Girder instances), this is the default behavior (you can create a key pair .<span class="" id=":anu.8" tabindex="-1">pem</span> file for <span class="" id=":anu.9" tabindex="-1">sshing</span>). On the EC2 instance with the <span class="" id=":anu.10" tabindex="-1">Mongo</span> DB, you have to attach a security group that configures the access. The inbound rule for port 22 is set to 0.0.0.0 allowing access from machines outside the private network. On the other hand, the rule for port 27017 restricts the access only from machines belonging to the same <span class="" id=":anu.11" tabindex="-1">VPC</span>. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>When you say load balancer, does that mean Elastic Load Balancer or something else?  I'm confused about how you use Nginx, are you using ELB + Nginx, and if so how does ELB hand off to Nginx?  Where does Nginx live, is it in a separate Docker container that redirects to the Girder instances?</div></div></blockquote><div><br></div><div>I meant the load <span class="" id=":anu.12" tabindex="-1">balancer</span> provided by Elastic Beanstalk. If I'm not wrong, the request hits the <span class="" id=":anu.13" tabindex="-1">Nginx</span> running on the load <span class="" id=":anu.14" tabindex="-1">balancer</span>. Then, the request is forwarded to one of the Girder instances running another <span class="" id=":anu.15" tabindex="-1">Nginx</span>. Then, the request is forwarded to the HTTP server running within the Docker container. You can SSH into all the machines (including the load <span class="" id=":anu.16" tabindex="-1">balancer</span>) if you want to poke around and see configurations, logs, etc. I was playing with /etc/<span class="" id=":anu.17" tabindex="-1">nginx</span>/<span class="" id=":anu.18" tabindex="-1">conf</span>.d/ configurations, restarting the service, like in any regular machine.</div><div><br></div><div>EB offers a way (although a bit convoluted in my opinion) to overload <span class="" id=":anu.19" tabindex="-1">Nginx</span> configuration files when you deploy new versions of your code. I'm doing this for tweaking the <span class="" id=":anu.20" tabindex="-1">Nginx</span> configuration in the Girder instances for redirecting non-https requests to https. The solution involves creating files under the .<span class="" id=":anu.21" tabindex="-1">ebextension</span> directory with some specific syntax. I managed to solve the http-->https redirection in a non-<span class="" id=":anu.22" tabindex="-1">dockerized</span> instance but I still have some issues here using Docker for Girder. In particular, EB includes a health checker that monitors the instances. When I enable the redirection, the load <span class="" id=":anu.23" tabindex="-1">balancer</span> receives a 301 response with the https URL redirection. The expected response was a 200 OK, and that makes the load <span class="" id=":anu.24" tabindex="-1">balancer</span> think that the instances are not behaving correctly. Maybe you have more experience than me dealing with <span class="" id=":anu.25" tabindex="-1">Nginx</span> configurations. </div><div> </div></div></div></div>