Поэтому, используя docker и docker-compose, мне нравится предоставлять инструменты, встроенные в контейнеры, чтобы другим людям в команде разработчиков не приходилось бороться с настройкой битов и бобов. В этом конкретном случае у меня возникают проблемы с настройкой xdebug. Он работает абсолютно нормально, используя Connect Back при отладке из браузера. Но попытка заставить работать xdebug через cli внутри контейнера - это настоящий кошмар. По какой-то причине требуется (наряду с remote_autostart = 1) параметр remote_host для указания сети, в которой находится контейнер докера.
Это мое текущее решение, которое находится в моем ~ / .bashrc, и оно работает,но это ужасноОн работает исходя из предположения, что сетевой ip будет просто ip контейнеров, но последняя цифра заменяется на 1. Я надеюсь, что у кого-то есть лучший способ заставить работать xdebug или более хороший способ получить сетевой ip.
# If xdebug doesn't get provided a remote address then it will default to this. This is the case for cli debugging.
# This ip should be the network this container is running on
own_private=$(hostname -i | awk '{print $1}')
# Replaces the final number from the containers own private ip with a 1 for the network address
network="${own_private%.*}.1"
# For some reason xdebug won't work unless you give it the network ip
export XDEBUG_CONFIG="remote_host=$network"
Настройки Xdebug:
[xdebug]
zend_extension=xdebug.so
xdebug.remote_enable = 1
xdebug.remote_connect_back = 1
xdebug.remote_port = 9000
xdebug.show_local_vars = 0
xdebug.var_display_max_data = 10000
xdebug.var_display_max_depth = 20
xdebug.show_exception_trace = 0
xdebug.remote_autostart=1
xdebug.idekey = "PHPSTORM"
xdebug.remote_log = /srv/www/var/log/xdebug.log
xdebug.profiler_enable = 0;
xdebug.profiler_enable_trigger = 1;
xdebug.profiler_output_dir = /srv/www/var/profiler/