Closed Bug 1128040 Opened 11 years ago Closed 10 years ago

Need to set up subdomain to route to an AWS EC2 instance for MDN sample back-end server

Categories

(Infrastructure & Operations :: DNS and Domain Registration, task)

Product:
Infrastructure & Operations
Component:
DNS and Domain Registration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: sheppy, Assigned: ckolos)

Details

Is there a way to arrange for a subdomain (either mdn-samples.mozilla.org or, if you prefer, samples.developer.mozilla.org) to be configured to route to an EC2-based instance? This would be an instance which will be restarted semi-frequently at first while we upgrade and enhance features, but should settle down after a while. This EC2 instance is being built as a place to run and/or host back-end server components required for examples on MDN to work. These include things like web chat clients using WebSocket, hosting videos, and presenting complex examples which can't be displayed in-content on the MDN wiki. My trick question here is: can this be made to work and automatically register when the server is relaunched with a different IP and name due to this ongoing testing and engineering work? Even though the code we're building to manage the samples isn't finished yet, we do have some code samples we'd like to manually put into place so that we can start documenting some key new technologies, and so we can share examples without their locations changing in the future. I'm honestly not even sure how you would identify this instance, since it's ID changes, presumably, when terminated and started anew.
Have you considered using an abstracted and persistent interface like an ENI, EIP, or ELB? In the case of an ENI or EIP you would need to reattach your instance to it when it came back up, but the IP address would persist.
There is no trivially simple way to do this, today. We've taken note of this for our future Amazon architecture discussions, but here's the options I can find for you right now. You can create an Elastic Load Balancer (ELB) instance at Amazon, and then (whenever necessary) re-associate the instance with the ELB, so that traffic to the endpoint is directed to the appropriate server of your choice. There are, theoretically, ways to automatically associate the EC2 instance with the ELB, something about "autoscale group" (ASG). And the ELB can act as an SSL endpoint, which keeps your EC2 instance focused on plain HTTP. Several of us recommend the ELB solution for your request; it is not apparent whether ASG would be appropriate or not at this early stage, but presumably growth will make ELB (and ELB+ASG) more valuable over time. You can request an Elastic IP (EIP) from Amazon (limit 5 per Amazon account), and then (whenever necessary) re-associate the instance with the EIP, so that there's always a single external IP. It can only be associated with one instance at a time, and it may be simpler to automate but prevents any sort of scaling up if you need to use multiple servers or handle additional load. I'm led to believe that this can be done automatically with an instance create parameter. Amazon Route 53 may also offer a mechanism where you can (whenever necessary) re-associate the instance with an external DNS record hosted at Route 53, and then we refer DNS requests for that particular record to Route 53. I'm not familiar with whether this can be done automatically at instance creation or not. This is not an ideal solution for your problem, but I'm noting that it exists. We can work with you given any of the above options, as they each provide something we can point DNS towards.
I am now using the EIP with the external address 52.0.70.144 for this site. We will need HTTPS to enable seamless, secure integration with our existing content on MDN, which is aos Would like to have one of the following names (or similar, as adjusted bade on your preferences): * samples.developer.mozilla.org * mdn-samples.mozilla.org For what it's worth, if it affects decision making on priority and/or ease of completion, here's a link to a Google doc outlining what we're doing with this server: http://bit.ly/1DJ7BoF Let me know what other steps I might need to take!
Assignee: infra → ckolos
Flags: needinfo?(ckolos)
Is there a technical reason why you're going the EIP route over the ELB? If not, I strongly suggest that you proceed as atoll recommends in #c2. As for adding the DNS records to point the domains to your ELB/EIP, that's not a problem. You can either have them added as CNAME's or as full A's to the required resource.
Flags: needinfo?(ckolos)
(In reply to Chris Kolosiwsky [:ckolos] from comment #5) > Is there a technical reason why you're going the EIP route over the ELB? If > not, I strongly suggest that you proceed as atoll recommends in #c2. > > As for adding the DNS records to point the domains to your ELB/EIP, that's > not a problem. You can either have them added as CNAME's or as full A's to > the required resource. I set up the EIP because I was advised by several people that for something as simple as what we're trying to establish here, it was the easiest solution that would allow us to open arbitrary ports for incoming traffic. Does the ELB support a server on which the software that's running can arbitrarily start listening on ports assigned by a master program running on that server?
Each ELB instance includes the port and protocol, so if you're experimenting heavily with lots of arbitrary and frequently-changing ports, then I have no objections to this *specific* case of using an EIP.
Yeah, this is a scenario in which we are going to be adding an ever-growing number of examples, each of which may need one or more non-HTTP ports. It's a little bit more organic, since it's intended to be a writing-team maintained suite of samples with a bit of startup code that helps keep everything working -- all of which is maintained on github and pulled onto the server during instantiation. Given that, it was generally figured that EIP was the least painful way to go.
With that all said, what do we do next in order to establish the linkage of a mozilla.org subdomain name to the EIP?
Flags: needinfo?(ckolos)
What is the external hostname provided by Amazon for your EIP? We can CNAME whatever Mozilla hostnames to that.
(In reply to Richard Soderberg [:atoll] from comment #10) > What is the external hostname provided by Amazon for your EIP? We can CNAME > whatever Mozilla hostnames to that. The EIP's external hostname is ec2-52-0-70-144.compute-1.amazonaws.com. Cloud Services tells me that we're going to handle this as a dev server, since it won't be administrated by them or anyone else in ops, but by the developer docs staff. According to what I see on mana, that means normally "dev" would be in the server name. For our purposes, that wouldn't be ideal, since there isn't going to be a production server. For that reason, I'd like to use the name samples.developer.mozilla.org, if that's acceptable, or mdn-samples.mozilla.org if that was too long. Or feel free to make a recommendation.
Speaking as cloud services, I'll say the following: 1) We can name it whatever you want. The "dev" designator is a nice-to-have but not required. We (sadly?) have precedent running dev-level things in the prod env and prod-level things in dev. Both of these require a clear understanding on all sides that they are exceptions to the "guideline". ;) 2) If this is a dev-level resource, you need to accept/understand that there could be little attention paid to the fact that this instance is not working or has AWS-disappeared. Of course, we're available to assist in whatever way possible, but if it's not prod, then it will not be given the same care and feeding as our prized world famous lipperzaner prod instances. This includes abbreviated monitoring and alerting in the case that something has failed or gone wrong. For this reason, you should also be aware of the data you are storing on this/these instances and do so in a way that would allow the data to survive an instance disappearing (i.e. don't use ephemeral drives or the hosts boot drive for anything you want to survive a reboot). 3) I would ask you to be clear on the determination of when this has graduated to a needed/required-for-work production-level product. At that time we'll want to "make it official" and spin a jenkins/ansible/CFN stack to handle creation of the same stack in production. There's nothing that says the dev machine will go away or that your development has to stop, but at the time that you find you're relying on specific resources on *this* instance to do your day-to-day, it's time to think about putting those services/resources into production. Apologies if all of this is redundant or "no-duh" information. I'm guessing a bit here that you've not run much in AWS and wanted to establish a clear understanding so you're not upset at us later ;) :atoll with MDN moving to Cloud Services, should I handle the DNS on this request, or would you prefer to do so? Or, third option, should I just open a ticket with infra for this? I don't control the mozilla.org domain, but I can make the change or whatever. Please advise.
Flags: needinfo?(ckolos) → needinfo?(rsoderberg)
Works for me, go ahead.
Flags: needinfo?(rsoderberg)
$ nslookup mdn-samples.mozilla.org Server: 10.19.73.244 Address: 10.19.73.244#53 Non-authoritative answer: mdn-samples.mozilla.org canonical name = ec2-52-0-70-144.compute-1.amazonaws.com. Name: ec2-52-0-70-144.compute-1.amazonaws.com Address: 52.0.70.144
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to Chris Kolosiwsky [:ckolos] from comment #12) > 2) If this is a dev-level resource, you need to accept/understand that there > could be little attention paid to the fact that this instance is not working > or has AWS-disappeared. Of course, we're available to assist in whatever way > possible, but if it's not prod, then it will not be given the same care and > feeding as our prized world famous lipperzaner prod instances. This includes > abbreviated monitoring and alerting in the case that something has failed or > gone wrong. Yes, I had a nice chat with Travis about this, and we are definitely aware that this instance is entirely our responsibility. > For this reason, you should also be aware of the data you are storing on > this/these instances and do so in a way that would allow the data to survive > an instance disappearing (i.e. don't use ephemeral drives or the hosts boot > drive for anything you want to survive a reboot). There will be no data that needs to persist across reboots. In fact, the instances will be set up specifically to pull all needed content (HTML, JS, CSS, any background scripts, etc) from github, set them up, and launch them during instantiation and reboot. > 3) I would ask you to be clear on the determination of when this has > graduated to a needed/required-for-work production-level product. At that > time we'll want to "make it official" and spin a jenkins/ansible/CFN stack > to handle creation of the same stack in production. Understood. > Apologies if all of this is redundant or "no-duh" information. I'm guessing > a bit here that you've not run much in AWS and wanted to establish a clear > understanding so you're not upset at us later ;) No offense taken at all. You're totally correct, and it's important to have all this down to be sure we know what's what.
You need to log in before you can comment on or make changes to this bug.