And for that, inside of the source folder,
inside of this newly created Laravel application,
I will first of all go to the .env file
which you should find in there.
This was generated by Laravel
and it holds some configuration for Laravel.
So not for our Docker setup but for Laravel.
And the most important piece of information
for us is this block here,
which holds the connection information
Laravel will use for connecting to a MySQL database.
And we need to adjust this such that Laravel is able
to connect to the database.
Now for that, we first of all need to tweak the database
it's trying to use, the name of the database,
the username and the password.
And here we should of course work with the values
we set up for launching our MySQL server.
And here you see I picked a username of homestead
and then a password of secret.
So back in .env, we should use homestead here
as a database name because that's what I also used there,
and then as a username add secret as a password.
And then very important,
the host here is not this IP address,
instead it is the name of our MySQL service.
In this case mysql.
Because this request will then be sent
from inside the PHP Laravel application
and therefore from inside to the container,
and hence Docker will be able
to resolve this container name to an IP address,
since these application servers will run
in the same network.
So with these adjustments made,
we don't need to adjust anything else here for now.
We can save this .env file
and we can try running this application.
And to do that, we need to use docker-compose again.
And we will be able to use docker-compose up
to bring up the services we wanna start.
But before we use that, let's quickly pause
and let's evaluate which services that will be.
Well it will be the server, the PHP and the MySQL services.
The server is our main entry point
which will serve the application
and which will then forward requests
to the PHP interpreter for example.
And the PHP interpreter will eventually
indirectly talk to the MySQL database,
because in our code we will connect to that.
But we'll have a problem here.
Our server, which is the main entry point currently
doesn't know anything about our source code.
Our interpreter does but that's not enough.
The incoming request hits our server first,
and it only forwards requests to PHP files
to the PHP interpreter.
That means that these PHP files need to be exposed
to the server and that simply means that we need
to add an extra volume here.
And that extra volume, will be another bind mount
where I bind my source folder
to the var www html folder inside of the container.
And I'm picking this folder because in the nginx config,
it's the var www html folder
from which we're serving our content
and where we are looking for files.
Well, of course we're looking in the public folder
but that is a folder which exists in the source folder.
So binding source to var www html is
what we need to do to ensure
that our content is made available through that server.
Adding this volume is important.
And now we can look into starting our services.
So now to run our services
and run our application containers
and test this application,
we use docker-compose up again.
And up to this point in the course,
we always used it just like this.
Now however, I don't wanna bring up all the services.
I don't wanna bring up composer for example,
but I wanna bring up three of the services
I specified in docker-compose,
server, PHP and MySQL.
And the great thing is that the docker-compose up command
has a special feature here.
We can see it if we enter --help here
and have a look at the documentation so to say.
We can also target specific services,
one or more services which should be brought up.
By default, if we just run docker-compose up
all services specified in the docker-compose yaml file
are brought up.
But we could hold the target just server,
PHP and MySQL and not composer.
And then only these three services would be started.
Now let's do that in detached mode here
and see whether that works.
If I hit enter here this now starts,
but I'm not sure if it succeeded.
If I inspect the running containers,
I see that there are two containers running,
but it looks like the nginx container did not start.
Instead we can find that as a container
which exited here.
So something is not working about that.
And the thing that is not working
is a tiny mistake from my side.
This config file which I'm copying
or which I'm binding to my nginx volume
is bound to the wrong path.
We shouldn't bind it to this nginx config file,
but instead we should target a conf.d folder
in etc nginx and then they are a default.conf file.
And that is a special file
which in the end you could say will be merged
into a bigger nginx config
which is set up inside of the nginx image.
So we should merge our own file into that file
with this bind mount.
With that, let's bring everything down
with docker-compose down to make sure
we got no running services anymore.
And then let's repeat this docker-compose up command
with server, PHP and MySQL.
And this now looks better.
Now, if we visit local host 8000 and reload this page,
we should see our Laravel application here.
We should see the Laravel starting screen.
And that is from the Laravel application we created
in this folder.
Now one other word
about the docker-compose up command though,
it works fine like this,
but naming all the individual services
which should be started is a bit annoying.
It would be better if we could just name
the server service for example,
and the other two services would
then be started automatically.
And we can let docker-compose know
that something like this should happen
by adding dependencies to this server service.
We can add depends_on and specify PHP and MySQL as services
on which this server service depends.
Which makes a lot of sense.
The nginx server really only works,
if it's able to talk to the PHP service
and if that service is able to talk to MySQL.
So in the end we depend on both services here.
Alternatively, we specify MySQL as a dependency of PHP,
that would also work.
But I'll stick to this setup.
And with this added,
with this depends_on configuration added,
docker-compose makes sure that if we bring up
this server service,
it also automatically brings up the services
on which depend.
In this case PHP and MySQL.
So if I save this and I hit enter,
we still start all these dependent services.
Doesn't look like it here,
for that let me first of all bring everything down,
and then let me run up again.
And you see it still starts all three services.
So with that I'll bring it down again,
because I want to tweak the up command even more.
It works absolutely fine the way we're using it right now,
but there is a little extra option
which I wanna add to the up command.
The little tweak I wanna make is related
to our custom images like the PHP image.
Right now, what docker-compose does as a default
is it looks if an image exists,
and if it exists it use a that.
It never rebuilds that image.
Which means that if we made a change to the Docker file
or to some files that were copied in through
the Docker file, something we're not doing here,
but which we could be doing of course,
then those changes would not be picked up by docker-compose.
It would not rebuild our images.
And I guess that makes sense.
Without docker-compose,
we also had to run docker build manually
to build a changed image again.
So therefore, to force docker-compose
to reevaluate our Docker files
and rebuild images if required,
we should also add the --build option here.
This forces docker-compose to go
through the Docker files again
and then recreate the images if something changed.
If nothing changed because
of that layer concept in images
and because layers are cached,
it will of course not rebuild the image.
It will effectively not rebuild anything,
it will just reuse these cached layers.
So if I now hit enter,
you'll see initially it goes through the image build process
for the PHP image.
It's super quick because nothing really changed there,
so it's able to use the cache.
But still we ensure that any changes
we might've made will be picked up.
And with that it still runs fine,
but now that's the command I recommend using here
to ensure that you always use the latest images.
Of course the alternative is
that you use it without --build
and you only add --build if you know that something changed
about your image because you changed the Docker file,
or because you changed some folders
or files that are copied into the image
through the Docker file.
But you can also always add it
to always check this and that's what I'll do here.
But now, we got a Laravel application up and running
and we can change our code here in the source folder.
For example we can go to resources views
and go to this welcome file
and simply add h1 tag here, Hello.
Save this, reload and we see it here.
So now we can work on that code
and work on this Laravel application with this setup.
Now, there's just a little work left
and that would be the other two utility containers
which we don't need to just start the application,
but which we for example need to run migrations
or handle a client side JavaScript code.
So let's now tackle these two containers.