Bug(s) already


So that didn’t take long, after only 24 hours I’ve run into my first issue thankfully the fix was simple. When I went to create a post or edit a post I kept seeing the following error message “Updating failed. Error message: The response is not a valid JSON response.” After some Googling around I found this thread https://wordpress.org/support/topic/updating-failed-error-message-the-response-is-not-a-valid-json-response-2/ scrolling down I found my answer, head back to admin settings > permalinks and re-save your settings I changed mine so WordPress can respond to API calls, well apparently something funky happens to those settings after the upgrade and you need to just hit the save button again. Hopefully this is the only thing that goes wrong.


k8s upgrade

Well I decided to upgrade my k8s cluster this morning to see what kind of damage I could inflict on the site, well a lot I took it down, I think a huge part of it is, I am only running 2 nodes and they are 2×4(2CPU, 4GB of RAM) and there just wasn’t enough resource once the rolling upgrade began. Also once the upgrade was complete my front end deployment was still broken I am running a service mesh and it seems the proxies timed-out waiting for resources, so the deployment was half up half down; luckily this was a simple fix, kubectl rollout restart deploy my_deploy again I think the core issue here is just not enough resource in the cluster.


Kubernetes migration

Well the migration to Kubernetes is complete the blog is now running on a managed k8s cluster on DigitalOcean. I will have some write ups on how I got here and where I go from here, but for now I’m just monitoring the blog to see how it performs, and make certain there are no security holes. I did very quickly find the source of my WP admin slowness thanks to a nice little WP plugin QueryMonitor again much, much more to come.



So I had some challenges getting this up and running but I found a few blog post that helped me out:


the first issue I had was a lot of Linux distros use systemd-resolved I am using photon OS and of course it does also so the first thing to do is

sudo systemctl stop systemd-resolved

sudo systemct disable systemd-resolved

the reason for this is it consumes udp 53 which you’re container needs to run on the next issue I had was usually I can docker exec bash into a container, well this container is slim and I mean slim there is not bash no anything I kept getting an OCI error when I attempted to run any exec commands so I had to use the below docker command

docker run -d -p 53:53/udp --rm --name coredns -v /static_content/coredns_config/:/root/ coredns/coredns -conf /root/Corefile

again big help from the above blog postings. Then the final issue I had was I’m pretty sure after you disable systemd-networkd you need to reboot photon OS our whatever flavor of linux because after changing the DNS server to itself again it’s running the coredns container I couldn’t get resolution, again a simple reboot fixed my issue Note I have 3 files in this repo to be modified for your specific use case the files are Corefile, db.lab.io, and db.192.168.99 But now I am finally free of having to always stand up a Windows VM for DNS