Commit fd246f4a authored by Daniel Stone's avatar Daniel Stone
Browse files

Add a rough README

parent e85bc35f
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`
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment