So let's now configure
our individual services and therefore containers.
And let's start with Mongo.
For this I'll have a look at the command we used
for launching our MongoDB container.
In the end we used the Mongo image here,
the official Mongo image which exists on Docker hub.
We don't use our own image,
we don't use our own Docker file here,
so we use this image.
We then also attach it to a network
we run it in detach mode and we remove it if it's shut down.
We have this volume, this named volume
for persisting the database data,
and we pass into environment variables.
So how can we translate this to docker-compose.yaml now.
Well for MongoDB,
we again start by pointing at the image we wanna use.
And we do this by using an image key here,
below the container to which it belongs.
So indented by two blanks below MongoDB.
And here we then specify the image as a string 'mongo'.
So between single or double quotes here,
you specify 'mongo' as a image name
because that is the image name we wanna use.
It's the same name we use here for a Docker Run.
And this will tell Docker Compose
and therefore Docker in the end
that the MongoDB container
should be based on this Mongo image.
And this can be just the image name,
which will then be looked up locally
and in the Docker hub repository,
it could be a full URL to another repository, for example,
where this image might be stored,
it could be your own repository, like academind,
hello-world, which we created early in this course.
So this is all valid.
It can of course all the be accustomed image
which you built on your system,
which you now reference.
For example,
goals-node is an image we built in the last course section.
Of course, the wrong image for MongoDB
it's just an example, what would be allowed.
So here it's 'mongo', that's the image we wanna use.
And now let's see what else we would add.
We wanna run this in detached mode
and remove it when it shut down.
Well great news, you don't need to specify this here
by default when you use Docker Compose,
when you bring your services down,
they will be removed and regarding the detached mode,
that's also something we can specify
when we then start all services together.
So we don't need to add the remove or detach flag here
to our MongoDB container configuration here.
We definitely do wanna add our volume though.
I'll come back to the network in a second by the way,
but I'll start with the volume
and we can add that to a container
by adding the volumes' key here.
So next to image nested below MongoDB
on the same level as image I add volumes.
And now again,
we can have more nested values for our volumes
because we can have more than one volume.
And here the syntax is really, really easy.
For every volume you wanna have here, you add a dash
so that you have a list of dashes here eventually
if you have multiple volumes.
But here we only need one
we'll see multiple volumes later for other containers.
And then after this dash
you define a volume as you learned it.
So for a named volume named data,
which is the volume name we used here for the database data,
you add data:data/db for the container internal path.
So this syntax is exactly the same
as we used it here with dash V flag,
we add our volume name, then a colon,
and then the container internal path.
And with the number of colon,
we could always add extra options, like read only,
which of course doesn't make sense here,
but we could add this.
So with that, we added all the volumes, the single volume,
the MongoDB container needs.
And now we are left with the two environment variables
and the network.
Now let's start with the environment variables,
here we can add an environment option
on the same level as image and volumes
because it configures the same container
not nested in volumes of course.
And then here we got two alternative syntaxes
for specifying our environment variables.
We can specify the environment variable
like MONGO_INITDB_ROOT_USERNAME, then a colon
and then the value for this variable, for example max,
or if we don't wanna do that, if I comment this out,
which you can do by adding a hash in front of it,
then this will have no effect.
If we don't wanna do this,
then we can also add a dash here
and specify the environment variable as a key value player
with an equal sign in between, like this.
Both is possible, it's up to you, what you prefer.
I prefer this first Syntax,
therefore I will use that
and I'll do the same for the root password.
And with that,
we're specifying the environment variables
for this MongoDB container.
You also have another option,
you also can specify an environment variable file.
And I also wanna show this to you as a side note,
we also can do this with Docker Run of course
I showed this earlier in the course already,
you can add the --env-file option here,
and then point at a file that contains
the environment variables.
But the equivalent for that here for Docker Compose
would be that you for example, at a sub folder env
and then in there let's say we have the mongo.env file.
And in here we could then grab this,
the environment variables and add them, however,
like this with an equal sign and removing all wide space
that might be in front of the environment variables.
And then we can read in this file
by not using this environment key here,
which absolutely is an option.
But in case you wanna move your environment variables
out of this conflict file
so that you have them in a separate file,
which you then may be exclude from get and so on
to not share it in a repository,
that's why you might wanna use a file.
Then you can add the env_file option here
and then add all the environment files
that should be used for this container in a list.
So again,
with a dash here and then a relative path
seen from your docker-compose-yaml file on
to the environment variable file you wanna use.
In this case, this would be created with dot slash,
which means start in the same directory as I'm currently in
so the directory,
the docker-compose-yaml file is in
and then going in the env folder and then the mongo.env
is the file we wanna use.
And then the environment variables stored in this file
would be read in and would be considered in this container.
So that's how you can add environment variables.
And in case it's not clear why we need the dash here
and why we don't need it the environment variables
if we specify them like this, you need a dash,
whatever you have a single value here.
So whenever you have a list of single values,
if you have key value peers, so if you have a colon here,
then this creates a yaml object
and or you don't need dashes.
So for a single values
where you don't have a colon and a wide space,
you need a dash.
If you have key value pairs with name,
colon wide space value, then you don't need dashes.
That's just another side note.
And with that, I talked a lot about these different options,
but it is all brand new, I guess.
But we're now done with MongoDB with one exception
and that's the network.
Now you can add a network by adding the networks' key here,
and then you can specify all the networks
this container should belong to.
But in many cases, you don't need to do this.
You don't need to do this
because when you use Docker Compose,
Docker will automatically create a new environment
for all the services specified in this compose file
and it will add all the services to that network
out of the box.
So all these services which are defined in one
and the same compose file will already be part
of one and the same network that was created for them
by Docker.
So that's a little convenience feature,
which we get out of the box and which is why here
we don't need to specify a network.
You could, of course do it though.
You could add a network's key, for example,
to add them to the goals-net network,
which we added in the last course section.
If you wanna use your own network like this,
this is absolutely something you can do
there's nothing wrong with that.
In this case, the MongoDB service
would not just be added to the default network
that is created, but also to this special network,
which you specified here.
So that is something you can do
you can manage and use your own networks.
But here I will actually go with the default network
Docker Compose creates for us, and they are fried
don't specify the networks key here.
But with that, we're done with MongoDB.
We should have all the configuration we need
for bringing up that MongoDB service,
and therefore I'll comment out backend and frontend,
and I'll give this a try.
Now all that I've ever ever known about volumes
for named volumes,
you should also add a volumes' key next to services
so not indented instead on the same level as services
at top level volumes' key
and any named volumes you're using in your services
have to be listed here in this case data.
And you're simply added like this with a colon
and then no value thereafter.
This might look strange,
but this is the syntax Docker wants
for being aware of named volumes
it should create for your services.
As an additional note,
if you then use the same volume name in different services,
the volume will be shared so different containers
can use the same volume,
the same folder on your hosting machine.
That is something which is possible.
So named volumes should be specified here.
Anonymous volumes and bind mounts
don't need to specified here.