I’ve just migrated this blog site itself into the kubernetes cluster I built with Raspberry Pi 4s, and this post is about the steps and approach I used to achieve this goal. Yes, what you have been reading is served by 1 of the Raspberry Pi boards.
First of all, a bit introduction on kustomize: It’s a bit late to the game but better late than never. Since kubectl v1.14, kustomize has been merged as a switch like kubectl apply -k test.yaml ...
I guess the reason behind something like kustomize is when a guy like me deploying apps into k8s clusters, it’s actually a lot of “YAML engineering”, ie. writing YAML files for the Namespace, Deployment, Service, etc. It’s OK to do it for the first time, but very soon I felt repeating myself with all those metadata or annotation tags.
helm is the other tool to manage kubernetes schema files and it started quite earlier than kustomize. I never liked it though. A sample helm chart template looks like this. The main reason I don’t like it is that it brings placeholders like {{ .Values.stuff }} into yaml and they are everywhere, just like good old asp/jsp templates, this makes the template no longer a valid YAML any more. Also I’m not a fan to put a lot of logic into configuration files.
Here’s a very good blog on how to kustomize. With kustomize I can put values associated with some conditions, eg. git branch, or ops environments, etc. into YAML files without any efforts to template the original schema, which enabling me to check-in the base schema into a public repository without the need to worry if I put any database password there.
Here’s the github repository where I store the YAML files which I used to deploy wordpress into my cluster, including following implementations:
- Namespace for each installation
- typical WordPress on PHP7.2-FPM and nginx containers running as non-root user
- K8s PersistedVolume on NFS shared partition for files, eg. photos, plug-ins, etc.
- Redis cache for PHP session
- Ingress routing for nginx-ingress-controller
The wordpress-base directory has almost all the schema and with some dummy values. And the wordress-site directory has kustomize patch files which should hold your domain name, NFS server address for storage, etc.
To reuse my schema, you can simply duplicate the wordpress-site directory along side with the wordpress-base directory and put in real configuration as fit. Such as:
pik8s/ + wordpress-base/ + wordpress-site/ + wordpress-mysite/
Then assuming you’ve configured kubectl, database and NFS already, you can preview the wordpress deployment with:
# in pik8s/wordpress-mysite/ $ kubectl apply -k . --dry-run -o yaml |less
And do the real thing without the --dry-run switch.
But the secret referenced in deploy.yaml is not checked in obviously. You need to create it manually with:
# prepare files to be used in the secret $ echo -n 'mydbpass' > dbpass # do the similar for dbhost, dbname, dbuser ... # then create the secret $ kubectl create secret --namespace wordpress-mysite generic wordpress-secret --from-file=dbuser --from-file=dbhost --from-file=dbname --from-file=dbpass
🙂