Как устранить неполадки в развертывании, которое продолжает падать

Question

У меня есть проект GKE, в котором я развертываю сайт WP с использованием репозитория bitnami / wordpress. По какой-то странной причине я получаю сообщение об ошибке при перезапуске модуля с файлом wp-config.

Эта ситуация открыла для меня важную проблему, а также устранение неисправностей других типов. Поэтому я пытаюсь выяснить, каков идеальный или рекомендуемый способ устранения неполадок развертываний, когда модуль никогда не активен для меня, чтобы на самом деле проверить заявление о постоянных томах, где хранятся данные (в случае, если мне нужно вручную настроить определенные файлы или протолкнуть исправления, пока развертывание недоступно).

Я попытался засовывать файл напрямую, чтобы хотя бы понять причину ошибки и просто сказать, что сценарий застревает в каком-то процессе, который не позволяет завершить все выполнение, что приводит к неполному wp -config файл, который приводит к ошибке выше. Проблема здесь в том, что, поскольку модуль работает примерно 30 секунд, пока он пытается перезапуститься, на самом деле у меня не так много времени внутри модуля, чтобы продолжить устранение неполадок или тестирование чего-либо еще.

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

(я не уверен, как у вас это работает - я предполагаю, что у вас есть изображение 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 2

1. Наилучший подход к развертыванию wp - подать в суд на stable helm график

   helm install --name my-release stable/wordpress

2. Когда ваше развертывание рухнет, вы можете удалить его и назначить тот же ПВХ в другой POD для получения данных, хранящихся в ПВХ .

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

3. Вы также можете использовать kompose convert, чтобы получить нужные файлы yaml для развертывания их в GKE.
4. Сохранение конфигурации в ConfigMap, как описано в wolmi , кажется хорошим вариантом.
5. Возможно, вы можете подать заявку в своем докере: command: tail -F anything или использовать решение, предоставленное maiamcc
6. Подробную информацию о " Создание и управление томами в Docker " вы можете найти здесь

docker volume ls
docker volume inspect <your-volume>

Answer 3

PVC может быть прикреплен только к одному модулю. Основная проблема, которую вы имеете, заключается в том, что вы неправильно настроили установку.

Мой совет - сгенерировать локальный файл wp-config.php и создать с ним файл config, а затем смонтировать его как том. Один файл конфигурации можно монтировать столько раз, сколько вам нужно, на разных модулях, поскольку он доступен только для чтения.

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