Deployment to rancher fails

Question

Deployment to rancher fails

Closed this issue 4 years ago · 4 comments

Trying to deploy the helm chart in a vanilla rancher installation.

Added this repo as Chart Repository in rancher by adding https://robjuz.github.io/helm-charts/
Tried deploying it totally vanilla. No changes to anything in the values.yaml.

This results for me in:

4 secrets
2 PVCs
3 ConfigMaps
2 Services
2 Pods
1 StatefulSet
1 Deployment
of which everything except the pod from the image kimai/kimai2:apache works.

kimai/kimai2:apache is in a "Crashloopback" state, and examining the logs it shows that during deployment, just after it connects to the database the first time, it tries to create a folder named /opt/kimai/var/cache/prod which fails 5 times with the same message: "In Kernel.php line 688: Unable to create the "cache" directory (/opt/kimai/var/cache/prod).". Next, it fails (which I assume is a follow-up problem) with the message: "/startup.sh: line 53: /opt/kimai/var/installed: Permission denied". It then states "Kimai2 ready" and goes into the Crashloopback state with continuing messages:

[Wed May 26 12:53:04.873550 2021] [php7:error] [pid 59] [client 10.42.4.1:39814] PHP Fatal error: Uncaught RuntimeException: Unable to create the "cache" directory (/opt/kimai/var/cache/prod). in /opt/kimai/vendor/symfony/http-kernel/Kernel.php:688\nStack trace:\n#0 /opt/kimai/vendor/symfony/http-kernel/Kernel.php(595): Symfony\\Component\\HttpKernel\\Kernel->buildContainer()\n#1 /opt/kimai/vendor/symfony/http-kernel/Kernel.php(136): Symfony\\Component\\HttpKernel\\Kernel->initializeContainer()\n#2 /opt/kimai/vendor/symfony/http-kernel/Kernel.php(196): Symfony\\Component\\HttpKernel\\Kernel->boot()\n#3 /opt/kimai/public/index.php(32): Symfony\\Component\\HttpKernel\\Kernel->handle()\n#4 {main}\n thrown in /opt/kimai/vendor/symfony/http-kernel/Kernel.php on line 688

Not sure where to start debugging...

Answer 1 · 2021-05-26T12:21:52.000Z

Found something! Entering the container to check the permissions, it seems like the PVC is mounted correctly to /opt/kimai/var but is owned by root, whereas the user of the container is www-data, thus the "Permission denied."

Is it set somehow in the helm chart what the ownership of the PVCs are?

I checked the mariadb PVC for comparison, and the mount is still owned by root, but the group is set to 1001 and the group also has write permissions.

Answer 2 · 2021-05-26T12:23:40.000Z

Thanks for the feedback! I will fix the permissions in the evening. W dniu śr., 26.05.2021 o 14:22 Gustav Johansson ***@***.***> napisał(a):

…

Found something! Entering the container to check the permissions, it seems like the PVC is mounted correctly to /opt/kimai/var but is owned by root, whereas the user of the container is www-data, thus the "Permission denied." Is it set somehow in the helm chart what the ownership of the PVCs are? I checked the *mariadb* PVC for comparison, and the mount is still owned by root, but the group is set to 1001 and the group also has write permissions. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFLPUHFTWOLONZPH33QMKLTPTRXJANCNFSM45R4FK5A> .

Answer 3 · 2021-05-26T18:11:45.000Z

@neerdoc please try again

Answer 4 · 2021-05-27T12:37:50.000Z

That solved this issue! Thank you!

I can now follow the instructions in the "Release Notes" of the helm chart and connect to my fresh kimai2 installation! Great work!

I shall now continue and see if I can figure out how to leverage rancher's ingress (traefik by default) and let'sEncrypt certificates to access kimai externally.