Running with Kubernetes
Requirements
- Docker
- Kubernetes version 1.9 or greater:
- [kubectl]
- A configured Kubernetes cluster
- helm (optional)
Starting game services locally
- Obtain the source for the root project (gameontext/gameon)
- HTTPS:
git clone https://github.com/gameontext/gameon.git - SSH:
git clone git@github.com:gameontext/gameon.git
- HTTPS:
Change to the gameon directory
$ cd gameon
Setup your environment (one time, see below).
$ ./go-admin.sh choose # choose Docker Compose $ eval $(./go-admin.sh env) # set script aliases $ alias go-run # confirm `docker/go-run.sh`
Set up core game services (repeatable):
$ go-run setup
This will ensure you have the right versions of applications we use, prompt to use helm or not, and create a certificate for signing JWTs.
If your cluster IP changes (or you have made changes to some templated files and want to start over), use:
$ go-run reset
All script commands in the following steps will show the command (
kubectlorhelm) being invoked, so you can follow along, or invoke on your own.Start core game services:
$ go-run up
This step will also create a
gameon-systemname space and a generic kubernetes secret containing that certificate.Wait for the system warm up
$ go-run wait
or, to watch the action, visit the kubernetes dashboard. For example, with
minikube, try:$ minikube dashboard
- Carry on with building your room!
Clean up
$ go-run down
Files supporting Kubernetes
The kubernetes subdirectory of the root project contains the following:
chart/gameon-system(directory) defines a helm chart for deploying core game serviceskubectl(directory) defines individual YAML files to create Kubernetes artifacts (config maps, services, and deployments).template.configmap.yaml,.template.ingress.yaml, and.template.values.yamlare copied into thekubectlandchartdirectories by the setup script once the cluster IP address is known.go-run.shhelps with starting, stopping, and cleaning up Game On! core services.k8s-functionscontains most of the functions working directly withkubectlorhelm.
Configuration
When Game On! runs in the cloud, it uses etcd to obtain its configuration. When running locally it expects all this to be fed to it via the environment.
With Kubernetes, configuration is injected via ConfigMap objects:
* When using kubectl alone, configuration attributes are provided by
kubectl/configmap.yaml.
* When using helm, configuration attributes are provided by
chart/gameon-system/values.yaml
As referenced earlier, these files won’t exist until the setup script has run at least once.
Rebuilding Core Game services with Kubernetes
TBD