NextCloud - the end-all be-all cloud solution, on kubernetes.
Thank you Ali Cheaito via Github
I found a project here that used kustomize to deploy a Nextcloud instance with Apache, MariaDB, Cron, and Redis. I took it, modified it to fit my needs and then deployed it.
Deployment from Github project
- Update maradb/secret.yaml with MYSQL_PASSWORD and MYSQL_ROOT_PASSWORD (anything base64)
- Update nextcloud/ingress.yaml with k8s domain name
- Adjust storage size in nextcloud/pvc.yaml to fit needs
- Generate a configuration preview (
kubectl kustomize . > all-services.yaml) - As an aside, I also updated the configuration to use the
productionnamespace.
Everything from the project essentially just worked which made everything pretty easy.
With the exception of a few items such as services and moving them from ClusterIP to LoadBalancer I had no problems deploying the application.
A quick note on Gitops
I want to move towards gitops for my k8s environment, but cloning down repos and generating kustomize templates with all k8s resources is helping me to get there. I need to navigate secrets, but expect a repo in the near future.
HAPROXY
Setting up HAProxy wasn’t too difficult, however I did run into issues with timeouts from HAProxy to the nextcloud application. This will be explored later, but essentially I had to increase HA proxy timeouts from the standard 30000ms to 120000ms. This means it went from about a 30 second timeout to nearly two minutes. Normal page loads were nearly 38 seconds (this is garbage, nearly making the app unusable).
I was able to point the proxy at the LoadBalancerIP and after a painstakingly slow amount of time the page responded back with the nextcloud page asking me to configure an admin and the database.
This was easy to do, but the page load times were near about 38 seconds. This nearly made the app unusable. I was happy though as I was able to get at least a proof of concept out the door for myself.
The two issues I ran into with timeouts were 504 bad gateway leading me to believe it was a configuration issue, and also 503 server timeouts which led me to believe nextcloud was misbehaving.
Lucky for me though I had the internal IP up and it was working just fine.
Nextcloud Config.php Notes
A note on Nextcloud, you will have to update the app’s config.php file to allow for proxy connections and trusted connections. These are relatively easy to configure and boil down to adding an element to an array.
The config should look something like this in your config.php file.
'trusted_domains' => array(
0 => '10.0.1.202',
1 => '192.168.200.5',
2 => 'public.ip.goes.here',
),
'trusted_proxies' => array(
0 => '192.168.200.5',
1 => 'public.ip.goes.here',
),
Nextcloud Speeds - possible issues
This service could be running slow for a number of reasons. The first I suspect is that the application itself (nextcloud deployment) is running from the nfs instead of from the worker. This means every request has to go back to the nfs mount, compute and then generate the page. This is what I suspect, but I will have to check rw to NFS and network latency between nodes.
The environment is nearly all virtual so there shouldn’t be much latency, but I am sure there is a bottleneck somewhere. Check out the next few posts on diving more into the speed issue.