I am still experimenting with deploying Gibbon on a Kubernetes cluster. In my deployment, I am spinning up three instances of the gibbon web server front-ended by a load balancer. I am leveraging portworx for persistent storage and all nodes have access to the core files (common mount is /var/www/html/gibbon). What I have noticed is that I get the following error randomly when browsing: “Your request failed because you do not have access to this action.”
I am guessing this is related to MetalLB not being sticky with the client session and sending the request to a different container each time. If I change the number of web instances back down to 1, or if I refresh the page twice, then the error does not appear.
How does gibbon handle client sessions, and could multiple instances share that session info for load balancing purposes?
Sounds like a interesting project! If you get it up and running let us know if you’d like to share some documentation
Gibbon uses the $guid value from config.php to separate the php $_SESSION data for different installs. It sounds like your instances are all sharing the same files, so as long as they all read the same config.php this should be good.
Another consideration might be where the php install is saving its session data. http://php.net/manual/en/function.session-save-path.php Often this defaults to somewhere in the system folders (depending on the server setup), so changing this to somewhere that the instances have common access to may also work.
I left the default path in the php.ini file (defaults to /var/lib/php/sessions) for now, but created a volumeMount for that path on a persistentVolumeClaim (using portworx for persistent clustered storage). In this case I just edited my deployment yaml file and redeployed my app back into my local k8 cluster.
I can share the code soon, but it is very primitive as it is my first attempt at kubernetes (infrastructure/security person who is trying to keep up with my devops teams). For now I have code to deploy mysql, apache2/php7.2, portworx, metallb. I am still working on traefik with auto deployment of Lets Encrypt certs, DB commands to create the DB user and DB as well as deploying the gibbon code and modules to the shared storage. The goal is to create a fully working gibbon deployment that could be deployed locally or to Azure AKS. This is all probably overkill, but it helps me learn the new products.