Closed Bug 1287738 Opened 8 years ago Closed 8 years ago

Create activate.mozilla.community and point it to github

Categories

(Participation Infrastructure :: Community Ops, task)

Product:
Participation Infrastructure
Component:
Community Ops
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: Nukeador, Assigned: yousef)

References

Details

Hello,

We need to create activate.mozilla.community subdomain and point it to github pages.

https://help.github.com/articles/setting-up-a-custom-subdomain/

Project page is here:

https://github.com/mozilla/activate.mozilla.community

Thanks!
Hey :Nukeador

Instead of diving into the details of adding the DNS entry for this static github page I suggest you describe some requirements first.

From my point of view a blocker for hosting it as a github static page is that there is no way to add SSL support for custom domains directly in github. Here are my recommendations regarding hosting activate.mozilla.community (with SSL support).

* Create a docker image with just the static content (based eg. in nginx [1]) and deploy it in PaaS (less preferred)
* Create an amazon s3 bucket with the static content behind a cloudfront web distribution
* Host the github static site behind a cloudfront web distribution (seems the easiest to me)

There are probably other solutions too that I am open to discuss. Let me know if you have any other ideas.
I will also defer to Pierros for any other things we should take care of from a managerial point of view.

[1] https://hub.docker.com/_/nginx/
Flags: needinfo?(pierros)
We wanted to reduce the infra work needed for this project to zero (no hosting/server) and also being able to edit the site on the fly from github by non-technical people, also moving fast.

Unfortunately, we don't have the resources to create and maintain the infra you proposed.

Why not having SSL at the beginning is a blocker?
Let me explain how the proposal to use github + cloudfront works.

Cloudfront:
* acts as a middle layer between user and the github static page
* is where our domain points to
* is the layer where we also do SSL termination
* caches the static website pages from github

The configuration is done once. After that every change in the static site is going to be reflected to cloudfront automatically (needs some time until the cache gets invalidated).

That means that the only maintenance needed is in the static page side hosted in github.

> Why not having SSL at the beginning is a blocker?

For me it's a bad paradigm for a Mozilla hosted site in our days not to use SSL. On top of that in case this site evolves to something that also handles data (eg. form submission, email subscription, surveys etc) we are going to need SSL support and it's better to plan ahead.

Except of the actual technical part that we are trying to tackle here, there are valid reasons why we should use and promote encryption to our public facing sites as part of what we do as participation team.

I will wait for Pierros to chime in here. This is just my opinion about the standards/policies we should have when deploying production services.
When could the cloudfront thing be done? The main issue here is time, we want to launch as soon as possible (end of this week), even if v1 is not perfect.

If cloudfront is something we can set up in the following days, I'm fine, if not we should explore other possibilities, even using the github.io domain for the launch (which I don't like much since we own mozilla.community).

Thanks.
Just to weigh in here, we need a commitment today (yes short notice, acknowledged) if Part Infra can help in the setup as outlined here. We are planning to launch as soon as later this week / early next week.
We should move forward with deploying it through using Cloudfront.

Yousef will take care of that.
Assignee: nobody → yousef
Flags: needinfo?(pierros)
Thanks everyone!
user/yalam96 is not authorized to perform: cloudfront:CreateDistribution

Nemo, can I get access to cloudfront:*?

Nuke, can you confirm you have added activate.mozilla.community as a custom domain in the GitHub repo as per https://help.github.com/articles/adding-or-removing-a-custom-domain-for-your-github-pages-site/ ?
Flags: needinfo?(nukeador)
Flags: needinfo?(jgiannelos)
(In reply to Yousef Alam [:yalam96] from comment #8)
> Nuke, can you confirm you have added activate.mozilla.community as a custom
> domain in the GitHub repo as per
> https://help.github.com/articles/adding-or-removing-a-custom-domain-for-your-
> github-pages-site/ ?

I'm waiting for the domain to be ready to do the change, since we are testing the site using the github.io one (if I do the change now we loose access). Ping me here or on telegram and I can do the change in 1 minute.

Thanks!
Flags: needinfo?(nukeador)
I changed the IAM policy to also grant Community Ops full access to Cloudfront (fixed in bug 1288365).
Flags: needinfo?(jgiannelos)
https://github.com/mozilla/partinfra-terraform-cloudfrontssl

I've created a module to make this easy for us to do now and in the future. Will PR the final bits to get this going.
https://github.com/mozilla/partinfra-terraform/pull/25 Pull Request has been merged and has been deployed at https://activate.mozilla.community/

Nuke, once you change the custom domain in the GitHub repo settings the site should start fully working.

Note that it will take up to 20 minutes for changes made on GitHub to be reflected on the website.
Flags: needinfo?(nukeador)
Custom domain set, and I've changed some relative urls to work with the new domain.
Flags: needinfo?(nukeador)
I'm currently getting a redirect loop at https://activate.mozilla.community/
Turns out CF doesn't actually forward the host header so we didn't need the change in GitHub. Everything is working now.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Everything works OK. Marking this one as verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.