Docker build pipeline

[tgross]

This PR completes the configuration of Jenkins via the autopilot pattern, and includes fetching job definitions from GitHub and being able to build a container on Triton via our docker build support.

Done in this PR:

• Split compose file so that it's easier to have a working local environment during development
• Did some minor sprucing up of the Dockerfile so that the most frequently changed layers (i.e. config files) are last so we can take better advantage of layer caching.
• Bumped Containerbuddy to 1.2.1 and force a check of the checksums.
• Inject the Consul hostname into Containerbuddy at startup so we can use either links (for local development) or Triton CNS
• Add our assert-the-world script (until I can replace a bunch of it with stuff from the updated Triton CLI)
• Identify which creds we need to inject and design a way to do so.
• Move first-run scripts into a Containerbuddy onStart handler.
• sanity-checked the Docker build configuration done so far
• building jobs persisted on GitHub
• incoming web hooks are working for the job-building job
• README update

Being left for phase 2:

• get Nginx and TLS in front of it
• work up how to sync jobs back to GitHub if modified in the web UI (unclear if we really want to support this)

cc @misterbisson and @dekobon

[tgross]

@dekobon and @misterbisson I'd like some thoughts re: securing Jenkins and the web hooks.

From the GitHub plugin docs:

This plugin requires that you have an HTTP URL reachable from GitHub, which means it's reachable from the whole internet. So it is implemented carefully with the possible malicious fake post-receive POSTS in mind. To cope with this, upon receiving a POST, Jenkins will talk to GitHub to ensure the push was actually made.

For example, this will receive a 200OK:

curl -sv -XPOST
    -H 'Content-Type: application/json'
    -H 'X-GitHub-Event: push' \
    -o /dev/null \
    -d '{"ref":"ref/heads/docker_pipeline","head": "0a00893ec709560ec9653b06af26335dc8620ad0","before": "ca31de0dc150a1331889b1f88d98cf7a32d6b5d8", "size": 1}' \
    http://$(docker-machine ip default):8080/github-webhook/

But will result in the following log entry:

Mar 24, 2016 5:47:25 PM org.jenkinsci.plugins.github.extension.GHEventsSubscriber$4 applyNullSafe SEVERE: Subscriber org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber failed to process PUSH hook, skipping... (giant Java stack trace follows)

Right now the hooks are being set up via manual mode which means that the user has to set up the hooks in GitHub themselves. The reason for this is that our user needs to be able to give GitHub the appropriate CNS name, which Jenkins doesn't have access to. The nice side-effect is that you can tear down a Jenkins and stand up a new one at the same svc. record and GitHub is none-the-wiser.

The result of this is that we need to secure the communication path between GitHub and Jenkins via SSL so that we can ensure integrity of the GitHub callback we make, but other than that we're good-to-go.

Accordingly, I think the next area to tackle is getting Nginx w/ SSL in front of Jenkins.

[tgross]

@misterbisson and @dekobon I think this is ready for review and merge. Per offline discussion we'll consider the end-user adding SSL out-of-scope for now but I've included it as a caveat in the README.

[misterbisson]

:house_with_garden: :walking:

[dekobon]

LGTM

[tgross]

I'll merge this but it was to the cb-integration branch. Should we merge that into master as well?