This configuration partially works with kubernetes 1.15 running
locally using Docker Desktop for Mac and kind (k8s in docker).
For completeness, we installed kind & created a cluster like this:
cd /tmp/ && GO111MODULE="on" go get sigs.k8s.io/kind
kind create cluster --name workshop
export KUBECONFIG="$(kind get kubeconfig-path --name="workshop")"
We describe finicky details discovered while creating wiki.yaml.
The persistent volume when mounted in wiki-config begins its life with
all files owned by root. This prevented our node user inside the
container from creating the config files inside .wiki. It took a while
to discover the correct securityContext for the wiki-config container.
We tested this configuration as follows:
alias k=kubectl
k apply -f wiki.yaml
export POD=$(k get pod -lapp=wiki -o jsonpath='{.items[*].metadata.name}')
export PASSWORD=$(k exec svc/wiki-service -- jq -r .admin .wiki/config.json)
k port-forward svc/wiki-service 3000:80 > /dev/null &
pbcopy <<<"$PASSWORD"
open http://localhost:3000
# click lock icon in the browser to login to wiki page
# paste the password from the clipboard
# click wiki to toggle editing on
# make a few edits to the wiki page
Something about authentication is NOT working for anything except
localhost. When we try the same tests using http://localtest.me or
configuring foo.local in the MacOS /etc/hosts file, for some reason
the cookies don't seem to be passed through to the server. All edits
on other pages end up in browser localStorage.
Nevertheless, I'll commit what I have for now.
We should only need to run the configure-wiki script once instead of
every time we start the container. Also, I don't think that script
was correctly handling PID 1 role (e.g. don't think we forwarded
signals to node nor reaped zombies)
