K
Q

How to troubleshoot a deployment that keeps crashing

7/5/2019

I have a GKE project in which I am deploying a WP website using bitnami/wordpress repository. For some odd reason I am getting an error while the pod is restarting about the wp-config file.

This situation exposed an important issue to me and that is troubleshooting failures of other kinds as well. So I am trying to figure out what is the ideal or advisable way of troubleshooting deployments when the pod is never alive for me to actually check the Persistent Volume Claim where data is being kept (in case I need to manually adjust certain files or push through corrections while the deployment is inaccessible).

I've tried poking the file directly to at least get an idea of why the error and put simply it appears that the script is getting stalled in some process that does not let the entire execution complete, thus resulting in an incomplete wp-config file that results in the error above. The problem here is that since the pod is alive for just about 30 seconds while it is trying to restart, I don't actually have a lot of time inside the pod to further troubleshoot nor test anything else.

E 2019-07-05T18:38:12.336224194Z �[0m�[1mWelcome to the Bitnami wordpress container�[0m
E 2019-07-05T18:38:12.336229090Z �[0mSubscribe to project updates by watching �[1mhttps://github.com/bitnami/bitnami-docker-wordpress�[0m
E 2019-07-05T18:38:12.336234022Z �[0mSubmit issues and feature requests at �[1mhttps://github.com/bitnami/bitnami-docker-wordpress/issues�[0m
E 2019-07-05T18:38:12.336237673Z �[0m
I 2019-07-05T18:38:15.282309557Z nami    INFO  Initializing apache
I 2019-07-05T18:38:15.341679988Z nami    INFO  apache successfully initialized
I 2019-07-05T18:38:18.132225972Z nami    INFO  Initializing php
I 2019-07-05T18:38:18.169468837Z nami    INFO  php successfully initialized
I 2019-07-05T18:38:21.066019612Z nami    INFO  Initializing mysql-client
I 2019-07-05T18:38:21.115363595Z mysql-c INFO  Trying to connect to MySQL server
I 2019-07-05T18:38:21.117771115Z mysql-c INFO  Found MySQL server listening at mysql-sqlproxy-gcloud-sqlproxy.sqlproxy:3306
I 2019-07-05T18:38:21.148760516Z mysql-c INFO  MySQL server listening and working at mysql-sqlproxy-gcloud-sqlproxy.sqlproxy:3306
I 2019-07-05T18:38:21.178621769Z mysql-c INFO  ==> Found database dtb-fp-112-wp-dok42. Skipping database creation...
I 2019-07-05T18:38:21.179106832Z nami    INFO  mysql-client successfully initialized
I 2019-07-05T18:38:24.698919546Z nami    INFO  Initializing wordpress
I 2019-07-05T18:38:36.079448151Z wordpre INFO  WordPress has been already initialized, restoring...
I 2019-07-05T18:38:36.812451128Z mysql-c INFO  Trying to connect to MySQL server
I 2019-07-05T18:38:36.820733131Z mysql-c INFO  Found MySQL server listening at mysql-sqlproxy-gcloud-sqlproxy.sqlproxy:3306
I 2019-07-05T18:38:36.853653121Z mysql-c INFO  MySQL server listening and working at mysql-sqlproxy-gcloud-sqlproxy.sqlproxy:3306
I 2019-07-05T18:38:36.854253915Z wordpre INFO  Upgrading WordPress Database ...
E 2019-07-05T18:38:37.276642374Z Error executing 'postInstallation': PHP Notice:  Undefined index: HTTP_HOST in /bitnami/wordpress/wp-config.php on line 90
E 2019-07-05T18:38:37.276666760Z PHP Notice:  Undefined index: HTTP_HOST in /bitnami/wordpress/wp-config.php on line 91
E 2019-07-05T18:38:37.276680033Z

Is it possible to bind the same PVC to a different deployment? perhaps an FTP server or a file manager that would allow me to either retrieve files as a backup or fix / adjust files as required that may help recover from the failed deployment?

I appreciate the direction.

Thanks!

-- Jose R Lopez momon
docker
google-kubernetes-engine
kubernetes

Similar Questions

Maven/Gradle container fails to build project on internal k8s cluster
kustomize configmap command: what does it do?
Running an apache container on a port > 1024
Can not show images on harbor

3 Answers

7/5/2019

(I'm not positive how you're running this -- I'm assuming you've got a Docker image that you've built?)

If all you're after is keeping the pod alive for longer, you might try some dark magic with your ENTRYPOINT so that your error doesn't kill PID 1 and therefore kill the pod.

If your Dockerfile currently has:

ENTRYPOINT ./my_wp_script.sh

Try something like:

ENTRYPOINT ["/bin/sh", "-c", "./my_wp_script.sh; sleep 1000000"]

Your container will exit when PID 1 (i.e. the ENTRYPOINT) exits. With the above code, even if the wp_script returns a non-zero exit code, the container will go on to run the super-long sleep and hopefully therefore stick around long enough for you to debug.

-- maiamcc
Source: StackOverflow
7/5/2019

A PVC can only be attached to one pod, the main problem you have is you have not right configured your installation.

My advice is to generate your wp-config.php file in local and create a configmap with it, then mount it as a volume, one configmap can be mounted as many times you need on different pods because is read-only.

https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

-- wolmi
Source: StackOverflow
7/9/2019

  1. The best approach to deploy wp is to sue stable helm chart:

    helm install --name my-release stable/wordpress

  2. When your deployment will crash you can delete it and assign the same pvc to another POD in order to get data stored in pvc.

spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  1. You can also use kompose convert to get proper yaml files in order to deploy them on GKE.
  2. Having configuration stored in ConfigMap as described by wolmi it seems good options.
  3. Probably you can apply in your docker compose: command: tail -F anything or use solution provided by maiamcc
  4. Detailed information about "Creating and manage volumes in docker" you can find here
docker volume ls
docker volume inspect <your-volume>
-- Hanx
Source: StackOverflow