Closed burakovsky closed 2 years ago
Hi @burakovsky,
I'm sorry but I may not be able to help you if it is an issue with EFS storage, since it would be out of my scope if it is not a problem with the Wordpress chart or image.
I have seen some users having similar issues with EFS when using non-root containers. My recommendation would be to try a simple test deployment, fine-tune EFS-related settings, then use it with the chart. Maybe the following helps you: https://devops.stackexchange.com/questions/13939/how-to-allow-a-non-root-user-to-write-to-a-mounted-efs-in-eks
If the problem persists, it would be helpful if you could log into the pod and check permissions under /bitnami/wordpress
.
Hi @migruiz4,
Thank you for your responce! Yes, I checked the permissions and everything is ok but looks like efs performance is the main issue here. I started chart in diagnostic mode and ran entrypoint command manually - it finished successfully, but it took ~ 5 min to finish, so liveness probe just restarted a container earlier than all preparation steps finished.
Close this issue as there is no issues with Wordpress chart. Thank you!
Thank you so much @burakovsky. I was stuck with this issue. I'm running Kubernetes in Azure VMs with blob storage and I couldn't understand what was missing. The container takes more than 5 minutes to complete the installation of WordPress. You saved my day! I couldn't understand also why I got sometimes HTTP 503 (the wordpress service was missing because of the container issue).
So, I have the same issue, and I'm using Amazon EFS driver. What helped is to enable startupProbe, which is disabled by default, and set the start time to around ~ 8 minutes.
startupProbe:
enabled: true
initialDelaySeconds: 660
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 9
successThreshold: 1
The startup probe runs first and should be enabled. Liveness and Readiness should be set by default as is. I have tried with 16Gi volume.
Name and Version
bitnami/wordpress 13.1.3
What steps will reproduce the bug?
Are you using any custom parameters or values?
custom values.yaml:
What is the expected behavior?
WordPress preparation steps will be finished successfully during the first run
What do you see instead?
Wordress installation is stuck on Persisting WordPress installation step until liveness probe restarts the container (readiness probes also failed) because Apache starts after WordPress preparation steps. After container restart, it became ready, because persisting step does not run after restart.
Additional information
I have 2 WordPress installations in my EKS cluster:
Both installations use the same values. The difference is only in PersistentVolumeClaim configuration and different databases (hosted on the same host) are used.
The first installation works as expected, but when I used EFS storage, persisting Wordpress installation is not finish successfully. I don't see any errors in container logs even when container run with
BITNAMI_DEBUG=true
. I tried bothand
Also, I tried different mounting options (uid, gid, permissions), but the result was the same.
Final manifests (deployment and persistentVolumeClaim):
with EBS (works correctly):
with EFS (doesn't work as expected):
I also tested EFS with ReadWriteOnce access mode but it doesn't help.
After liveness probe failed and container became ready, some WordPress plugins does not work as expected (for example WP rocket). I read some related issues and possible solutions related to WP rocket plugin problem (for example this one), but in my case, I don't see any errors in WordPress admin console, and this plugin can write to necessary config files like .htaccess or wp-config.php. Anyway, even though the problem with WP rocket can be not related to the EFS issue, I'm not sure that WordPress is configured properly because of failures in preparation steps.
Thank you in advance!