We've learned how to use kubectl patch for local testing
We've also abandoned the automation between github and dockerhub
because we publish updates with sufficient irregularity that it is
better if we take the steps more manually and verify each as we go.
Now that both chrome and firefox understand *.localhost domains we can
remove our suggestion of using localtest.me subdomains.
Also update the brew install instructions now that brew cask install
is deprecated in favor of brew install --cask
My favorite improvement is finding a way to use yaml block labels and
references to reduce the duplication in the ingress config.
I suppose the last important thing to mention about this changes is
that k3d seems to have switched from traefik to nginx for its ingress
loadbalancer. We no longer need the traefik annotation.
Should remove one step from the instructions for developing plugins.
It's a step I consistently miss in my haste to get on with the hacking
and don't notice myself skip.
We now map ~/.wiki-k8s in MacOS into the .wiki folder inside the
container and similarly with MacOS ~/workspace/fedwiki
First, when we create the k3d cluster, we include directives that are
passed through to docker to mount the MacOS directories into the
kubernetes host.
Second, we use hostPath volumes in the kubernetes deployment config.
These will work great for the primary use case of a local wiki.
Deployments to remote kubernetes clusters will want to do this with
the PersistentVolumeClaim that was removed with this change.
One luxury of using hostPath and the legacy_security is that we no
longer require an init container.
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)
