00:00:03
in this video we're going to have a look
00:00:04
at how to run symfony's demo application
00:00:07
in a docker container
00:00:09
and setting up debugging with vs code or
00:00:11
visual studio code
00:00:13
i have created a demo project with
00:00:16
composer
00:00:17
called xd book symphony i can start
00:00:19
php's web server to run this
00:00:23
in my browser window you can see that
00:00:26
this application works
00:00:28
the first step is to configure docker
00:00:29
itself to make that work i have created
00:00:31
three extra files in the symfony demo
00:00:34
root directory
00:00:35
the first one to look at is the
00:00:36
dockerfile itself i have created a
00:00:39
minimal dockerfile here
00:00:40
we're using the php docker 7.4 cli image
00:00:44
and then i'm installing the xd book
00:00:47
extension as well as
00:00:48
copying its configuration file to the
00:00:50
rights directory
00:00:51
we'll have a look at this configuration
00:00:53
file in a moment we're exposing our web
00:00:55
server at port 8111 and as my docker
00:00:58
entry point
00:00:59
i'm changing to the demo xdebug symfony
00:01:02
directory and start my web server
00:01:04
with the correct argument in the docker
00:01:05
compose file we are setting up a few
00:01:07
more things
00:01:08
we only have one servers the php servers
00:01:11
and we name our container xdebug
00:01:13
symphony if you're on linux
00:01:15
you need to create an extra host
00:01:16
configuration to point host.internal
00:01:20
to hostgateway this allows applications
00:01:22
in a docker container
00:01:24
to connect back to the host that runs
00:01:26
the docker container itself
00:01:28
this is the way how xdebug can talk back
00:01:30
to your ide running on the same machine
00:01:32
we expose the port 811 we create a
00:01:36
volume to set our target directory slash
00:01:38
demo
00:01:38
and we also create a volume to put our
00:01:40
log files in as perhaps in the future
00:01:42
profiling files and trace files in the
00:01:44
xdiba configuration we load our
00:01:46
extension
00:01:47
with the zend extension line we
00:01:49
configure xd box modes to develop comma
00:01:51
debug
00:01:52
this enables the step debugger we tell
00:01:54
xd book to start with every request
00:01:56
we make sure to turn off the discover
00:01:59
client host
00:02:00
setting because that does not work in a
00:02:02
docker environment we set the client
00:02:04
host
00:02:04
to host.docker.internal which is the one
00:02:07
that we have configured
00:02:09
in a docker compose jammel file xdebug
00:02:11
will use this host to connect to
00:02:13
to start a debugging session we also
00:02:15
configure xdbox lock so that we can see
00:02:17
what is going on there
00:02:19
we can now create our docker container
00:02:20
through docker compose
00:02:23
it warns about the xdebug underscore
00:02:24
mode variable not being set
00:02:26
but that's okay once we have built our
00:02:29
docker container
00:02:30
we can start it in our browser we can
00:02:34
now access
00:02:35
our application again if we look at the
00:02:37
log file that has been created
00:02:39
you see that xdebug is trying to connect
00:02:42
to host docker internal on port 9003
00:02:45
but we can't connect that is of course
00:02:47
because we don't have our ide running
00:02:49
yet
00:02:50
let's start vs code i have already
00:02:53
loaded it in the right folder
00:02:54
but we want to debug this in order to
00:02:57
debug we need to install the xdebug
00:02:59
plugin we go to preferences extensions
00:03:02
and search for xdebug the extension that
00:03:05
you want to install is a php debug
00:03:07
extension
00:03:08
by felix becker now that we have
00:03:10
installed the extension
00:03:12
we need to create a launch configuration
00:03:14
to do that
00:03:15
we go to run and debug and select create
00:03:18
a launch.json file
00:03:19
and as environment we select php the
00:03:22
standard launch.json file
00:03:24
that the extension creates still has the
00:03:26
old
00:03:27
xdebuc.2 port 9000 in there which we
00:03:30
need to change
00:03:31
to 9003 in order to start a debugger
00:03:35
you select run and debug and in the top
00:03:38
you pick the listen for xdebug
00:03:40
configuration
00:03:41
and then click the start debugging arrow
00:03:43
this now put vs code
00:03:45
in debugging mode in our browser we can
00:03:47
reload a new file
00:03:49
vs code pops up with a warning saying
00:03:51
that it cannot open its file
00:03:53
that is because we have not created a
00:03:55
path mapping pop mappings are a way
00:03:58
to map the parts on a remote file in
00:04:00
this case demo xdebug symphony
00:04:02
vendor doctrine annotations lib doctrine
00:04:04
blah blah blah
00:04:05
to our local file system because we
00:04:07
haven't made that vs code
00:04:09
cannot find the file on the local system
00:04:11
and hence cannot find a file and debug
00:04:14
it that is our next
00:04:15
step making part mappings let's stop
00:04:17
debugging for now
00:04:19
part mappings are made in the
00:04:20
launch.json file
00:04:22
let's add them to the configuration
00:04:28
in our docker composer gemma file we
00:04:30
have mapped the project's route to the
00:04:32
demo directory
00:04:33
we need to make the exact same mapping
00:04:36
in vs code's path mappings
00:04:37
so let's change the documented variant
00:04:40
to what we actually want to do
00:04:42
and save the file now we can start the
00:04:44
debugger again
00:04:45
go to run and debug and go to listen for
00:04:48
x debug
00:04:49
we can then press the arrow again we put
00:04:52
vs code in debugging mode
00:04:53
and load a new page in our symfony demo
00:04:56
application
00:04:57
now vs code no longer warns that it
00:04:59
can't find a files because it can now
00:05:01
resolve them through our part mappings
00:05:03
however it will stop on the first
00:05:05
exception that occurs
00:05:07
this is perhaps not as expected but it
00:05:09
is part of the vs code debugging
00:05:11
extension
00:05:12
by default the vs code extension breaks
00:05:15
on everything
00:05:15
which you can see in the breakpoints
00:05:17
here this is not often
00:05:19
something that you want so you need to
00:05:21
disable this we can now press f5 or
00:05:23
continue to continue debugging
00:05:25
and you see it does not stop again in
00:05:27
order to set a breakpoint in some codes
00:05:29
you can click in the margin so that our
00:05:31
vat dot shows up
00:05:33
when we now request a page through our
00:05:34
browser it should stop on that line
00:05:38
and here we go after reloading it
00:05:41
instantly stops on the line where we
00:05:43
want it to do
00:05:44
in the top left you have now all the
00:05:45
local variables some of them are still
00:05:47
being uninitialized
00:05:48
but you can also see the path and the
00:05:50
locale that are being passed
00:05:52
in as arguments to this function by
00:05:54
clicking on the debug buttons above
00:05:57
you can step over lines
00:06:02
as i'm doing here you can also step into
00:06:05
functions
00:06:06
by f11 or clicking the step into button
00:06:08
you can use step
00:06:09
out to step out of the current function
00:06:11
and go back to its parent function
00:06:13
on the left hand side you can check all
00:06:15
your variables
00:06:16
you can see the call stack and go to
00:06:18
previous stack elements
00:06:20
explore the contents of objects and its
00:06:22
properties
00:06:23
and so on and so on hopefully this
00:06:25
showed you how you can set up
00:06:27
xdebug running in docker with vs.code
00:06:30
thank you very much