Add a rough README

README.md

+Someone should probably write a real README, for how to run this without
+accidentally destroying our storage.
+
+Anyway, you'll need the `fdo-gitlab` project active in Kubernetes, and Helm
+installed. You'll also need the helm-gitlab-omnibus (our custom chart),
+helm-gitlab-config (our running configuration), and
+helm-gitlab-secrets (ssshhhhhh) repositories checked out.
+
+Check that you can see the running services:
+
+```
+$ kubectl get deployments
+NAME                            DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
+gitlab-prod-gitlab              1         1         1            1           5h
+gitlab-prod-gitlab-postgresql   1         1         1            1           7h
+gitlab-prod-gitlab-redis        1         1         1            1           7h
+gitlab-prod-gitlab-runner       1         1         1            1           7h
+```
+
+Change into the Omnibus chart directory, make any changes, and check the
+changes with a dry run:
+
+```
+$ cd helm-gitlab-omnibus
+$ helm upgrade --dry-run -f ../helm-gitlab-config/config.yaml -f ../helm-gitlab-secrets/secrets.yaml gitlab-prod ./charts/gitlab-omnibus
+```
+
+This will spew out the generated Kubernetes chart, which you can double-check.
+If you're happy with it, you can deploy for real by removing `--dry-run`.
+
+Once it's up, wait for the instance to come back:
+```
+$ kubectl get deployment -w gitlab-prod-gitlab
+```
+
+You'll see AVAILABLE as 0 whilst GitLab restarts, then come back up as 1 when
+it's started.
+
+You can run `kubectl get pods` to discover the name of the K8s pod that GitLab
+is running in. Once you have the name of the pod, you can run various commands
+in it, such as looking at the logs:
+`kubectl exec gitlab-prod-gitlab-307067958-z7s47 -c gitlab -it gitlab-ctl tail`
+
+or opening a Ruby console and destroying as much data as possible:
+`kubectl exec gitlab-prod-gitlab-307067958-z7s47 -c gitlab -it gitlab-rails console production`