Updated doc structure (#9)

manuscript/recipies/gitlab-runner.md

@@ -0,0 +1,60 @@
+# Gitlab Runner
+
+Some features of GitLab require a "[runner](https://docs.gitlab.com/runner/)" (_in the sense of a "gopher" or a "minion"_). A runner "registers" itself with a GitLab instance, and is given tasks to run. Tasks include running Continuous Integration (CI) builds, and building container images.
+
+While a runner isn't strictly required to use GitLab, if you want to do CI, you'll need at least one. There are many was to deploy a runner - this recipe focuses on the docker container model.
+
+## Ingredients
+
+1. [Docker swarm cluster](/ha-docker-swarm/) with [persistent shared storage](/ha-docker-swarm/shared-storage-ceph.md)
+2. [GitLab](/ha-docker-swarm/gitlab) installation (see previous recipe)
+
+## Preparation
+
+### Setup data locations
+
+We'll need several directories to bind-mount into our runner containers, so create them in /var/data/gitlab:
+
+```
+cd /var/data
+mkdir gitlab
+cd gitlab
+mkdir -p {runners/1,runners/2}
+```
+
+
+### Configure runners
+
+From your GitLab UI, you can retrieve a "token" necessary to register a new runner. To register the runner, you can either create config.toml in each runner's bind-mounted folder (example below), or just "docker exec" into each runner container and execute ```gitlab-container register``` to interactively generate config.toml.
+
+Sample runner config.toml:
+```
+concurrent = 1
+check_interval = 0
+
+[[runners]]
+  name = "myrunner1"
+  url = "https://gitlab.example.com"
+  token = "<long string here>"
+  executor = "docker"
+  [runners.docker]
+    tls_verify = false
+    image = "ruby:2.1"
+    privileged = false
+    disable_cache = false
+    volumes = ["/cache"]
+    shm_size = 0
+  [runners.cache]
+```
+## Serving
+
+### Launch runners
+
+Launch the mail server stack by running ```docker stack deploy gitlab-runner -c <path -to-docker-compose.yml>```
+
+Log into your new instance at https://**YOUR-FQDN**, with user "root" and the password you specified in gitlab.env.
+
+## Chef's Notes
+
+1. You'll note that I setup 2 runners. One is locked to a single project (this cookbook build), and the other is a shared runner. I wanted to ensure that one runner was always available to run CI for this project, even if I'd tied up another runner on something heavy-duty, like a container build. Customize this to your use case.
+2. Originally I deployed runners in the same stack as GitLab, but I found that they would frequently fail to start properly when I launched the stack. I think that this was because the runners started so quickly (and GitLab starts so slowly!), that they always started up reporting that the GitLab instance was invalid or unavailable. I had issues with CI builds stuck permanently in a "pending" state, which were only resolved by restarting the runner. Having the runners deployed in a separate stack to GitLab avoids this problem.