Question

我有一个GKE项目，其中我正在使用bitnami / wordpress存储库部署WP网站。出于某种奇怪的原因，在pod重新启动有关wp-config文件的过程中，我遇到了一个错误。

这种情况向我暴露了一个重要问题，那就是对其他类型的故障进行故障排除。因此，我试图找出一种方法来对部署进行故障排除是一种理想的或可取的方法，当该Pod永不活动时，我无法实际检查保存数据的持久卷声明（以防万一我需要手动调整某些文件或通过部署无法访问时进行更正）。

我尝试直接戳文件，至少可以弄清为什么会出错，并简单地说，脚本似乎在某个进程中停滞了，而该进程无法使整个执行完成，从而导致wp不完整-config文件导致上述错误。这里的问题是，由于Pod在尝试重新启动时仍处于活动状态约30秒钟，所以我实际上没有足够的时间在pod内进行进一步的故障排除或测试其他任何事情。

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

是否可以将同一PVC绑定到其他部署？也许是FTP服务器或文件管理器，可以让我检索文件作为备份或按要求修复/调整文件，从而有助于从失败的部署中恢复？

我很欣赏这个方向。

谢谢！

Answer 1

PVC只能连接到一个吊舱，主要问题是您没有正确配置安装。

我的建议是在本地生成wp-config.php文件并创建一个configmap，然后将其作为卷挂载，一个configmap可以根据需要挂载多次，因为它是只读的。

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

Answer 2

（我不太肯定如何运行此程序-我假设您已经构建了一个Docker映像？）

如果您只是想让豆荚存活更长的时间，则可以尝试用ENTRYPOINT尝试一些黑魔法，以使您的错误不会杀死PID 1，从而杀死豆荚。

如果您的Dockerfile当前具有：

ENTRYPOINT ./my_wp_script.sh

尝试类似的东西：

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

当PID 1（即ENTRYPOINT）退出时，您的容器将退出。使用上面的代码，即使wp_script返回一个非零的退出代码，该容器也将继续运行超长sleep，因此希望停留足够长的时间供您调试。

Answer 3

部署wp的最佳方法是起诉stable helm chart：

helm install --name my-release stable/wordpress
当部署崩溃时，您可以将其删除并分配给它 pvc到另一个POD，以获取存储在pvc中的数据。

spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim

您也可以使用kompose convert获取正确的yaml文件，以便将其部署在GKE上。
如wolmi所述，配置已存储在ConfigMap中，这似乎是个不错的选择。
可能您可以在docker compose中申请command: tail -F anything或使用maiamcc提供的解决方案
有关“ 在docker中创建和管理卷”的详细信息，您可以找到here

docker volume ls
docker volume inspect <your-volume>

如何对不断崩溃的部署进行故障诊断

3 个答案: