1204521 - Move Bugherder from Mozilla's Stackato instance to Heroku

Status: RESOLVED FIXED

(Tree Management :: Bugherder, defect)

Description

[Ed Morley [:emorley]]

Mozilla's Stackato instance (*.paas.{mozilla,allizom}.org) isn't actively updated, is using an ancient version of Stackato that isn't compatible with the latest buildpacks (so I've had to fork the staticfiles buildpack we were using) and is generally a pain.

It was suggested we move to Heroku instead.

I have a demo up and running at:
https://mozilla-bugherder-test.herokuapp.com/
...however it was using the ruby buildpack (since that was what one heroku guide used, though it turned out the guide was broken in lots of places), but I think a nodejs solution makes more sense, since if bugherder started using grunt or gulp as part of the build later, we wouldn't have to use several buildpacks. (Ideally we'd just use a nginx-only buildpack, but there isn't an official heroku one, unless we use the php buildpack and disable PHP support within).

The spin-up time for the free tier is annoying when I've tried it. The hobby tier is only $7/month, is a pretty cheap price to pay to avoid that issue IMO. (Particularly when we'll be paying $20/month for the SSL addon anyway, if we want a non *.herokuapp.com domain).

(I don't think we need to pay the extra for the $25 P1 dyno; see the "Detailed Comparison" link on https://www.heroku.com/pricing)

Comment 1

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

I'm getting (and Ed confirms) 404 errors from Stackato for most of today when trying to load Bugherder. (This sounds similar to bug 1200220 where it just randomly happens and then goes away for a while, then comes back.)

I've tried logging into the management console and restarting the app, but the 404s persist. Sounds like Heroku will save us all. :)

Comment 2

[Ed Morley [:emorley]]

Attachment: Add a Node.js static webserver & Heroku configuration

Comment 3

[Ed Morley [:emorley]]

Testing that:
* HTTP is redirected to HTTPS
* Max age is set correctly for a couple of content types
* Last-modified and etag are set

[~/src/bugherder]$ curl -I http://mozilla-bugherder.herokuapp.com/
HTTP/1.1 301 Moved Permanently
Server: Cowboy
Connection: keep-alive
X-Powered-By: Express
Location: https://mozilla-bugherder.herokuapp.com/
Vary: Accept
Content-Type: text/plain; charset=utf-8
Content-Length: 74
Date: Mon, 26 Oct 2015 22:51:14 GMT
Via: 1.1 vegur

[~/src/bugherder]$ curl -I https://mozilla-bugherder.herokuapp.com/
HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
X-Powered-By: Express
Accept-Ranges: bytes
Cache-Control: public, max-age=900
Last-Modified: Mon, 26 Oct 2015 18:44:20 GMT
Etag: W/"1b22-150a57723a0"
Content-Type: text/html; charset=UTF-8
Content-Length: 6946
Date: Mon, 26 Oct 2015 22:51:19 GMT
Via: 1.1 vegur

[~/src/bugherder]$ curl -I https://mozilla-bugherder.herokuapp.com/js/Config.js
HTTP/1.1 200 OK
Server: Cowboy
Connection: keep-alive
X-Powered-By: Express
Accept-Ranges: bytes
Cache-Control: public, max-age=900
Last-Modified: Mon, 26 Oct 2015 18:44:20 GMT
Etag: W/"22f4-150a57723a0"
Content-Type: application/javascript
Content-Length: 8948
Date: Mon, 26 Oct 2015 22:51:40 GMT
Via: 1.1 vegur

etc

Comment 4

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Comment on attachment 8679102 [details] [review]
Add a Node.js static webserver & Heroku configuration

Looks good to me, and the steps in the readme all work.

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

One question: Should 'npm test' successfully run the tests locally? Doing it right now from the PR branch, I get:

[:~/mozilla/bugherder] heroku-deployment 130 ± npm test

> bugherder@0.0.1 test /home/kwierso/mozilla/bugherder
> karma start karma.conf.js --single-run

module.js:339
    throw err;
    ^

Error: Cannot find module 'async-each'
    at Function.Module._resolveFilename (module.js:337:15)
    at Function.Module._load (module.js:287:25)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at Object.<anonymous> (/home/kwierso/mozilla/bugherder/node_modules/karma/node_modules/chokidar/index.js:5:12)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at Object.<anonymous> (/home/kwierso/mozilla/bugherder/node_modules/karma/lib/watcher.js:1:78)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:311:12)
npm ERR! Test failed.  See above for more details.




Is this something that should just fix itself once merged to master? I see the runs in the PR worked just fine...

Comment 6

[Ed Morley [:emorley]]

(In reply to Wes Kocher (:KWierso) from comment #5)
> One question: Should 'npm test' successfully run the tests locally? Doing it
> right now from the PR branch, I get:
...
> Is this something that should just fix itself once merged to master? I see
> the runs in the PR worked just fine...

It works for me locally and on Travis. Perhaps you need to run |npm install| - there may be missing dependencies.

Comment 7

[Ed Morley [:emorley]]

Also make sure that |npm install| not |npm install -g| was used; the latter means certain libs can't be found, and is intended for global CLI tools etc, rather than a project's dependencies.

Comment 8

[Ed Morley [:emorley]]

So this has landed on master, and auto-deploy (when CI is passing) is now enabled. Bugherder can be visited at:
https://mozilla-bugherder.herokuapp.com/

In addition, I've set up the free Papertrail plan, so we can see rudimentary logs:
https://addons-sso.heroku.com/apps/mozilla-bugherder/addons/papertrail

All that is left is setting up the custom bugherder.mozilla.org domain.

This involves:

1) $ heroku addons:create ssl:endpoint
2) Get webops to give us a certificate+private key for bugherder.mozilla.org
3) $ heroku certs:add server.crt server.key
4) Verify with `heroku certs` and `heroku certs:info`. (For more info see: https://devcenter.heroku.com/articles/ssl-endpoint#endpoint-details).
5) $ heroku domains:add <subdomain>.mozilla.org
6) Find out the ssl CNAME target using `heroku domains` (https://devcenter.heroku.com/articles/custom-domains#view-existing-domains)
7) Get the DNS for bugherder.mozilla.org updated to point to the ssl CNAME target from step #6.
8) Verify SSL using the steps at: https://devcenter.heroku.com/articles/ssl-endpoint#testing-ssl

I've done #1 already. I'll file a bug to do #2, after which I can proceed with the rest.

Comment 9

[Ed Morley [:emorley]]

#2, #3 and #7 were done in bug 1219214 - and I did #5 in-between them.

Bugherder is now operational at https://bugherder.mozilla.org/

The cert looks fine:

[~/src/bugherder]$ curl -kvI https://bugherder.mozilla.org
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
*        subject: C=US; ST=California; L=Mountain View; O=Mozilla Corporation; CN=bugherder.mozilla.org
*        start date: Oct 28 00:00:00 2015 GMT
*        expire date: Nov  1 12:00:00 2017 GMT
*        issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
*        SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x6000572e0; line 1275 (connection #0)
> HEAD / HTTP/1.1
> Host: bugherder.mozilla.org
> User-Agent: curl/7.45.0
...