We now have our service running inside a container, with all its dependencies properly defined and installed inside. But we still need a database server and we're still relying on MySQL, which is on our host.

A single container was not meant to run many services at once. Similar to microservices, a container should do only one job. But containers can communicate with the outside, so this means they can communicate with each other.

We can deploy an additional container to run our database server. There are official MySQL container images, so it's as easy as a simple command to start running a database. But first, we need to take care of two things:

• The database server needs to store the database content on the host, or we'll lose the data when we remove our deployment
• Our initial container needs to know where the database server is, and this changes dynamically on each deploy, so we need to have a way of knowing this

Docker has a way of knowing what host port was associated to a container port. This is by using Docker port, and its syntax is simple; you indicate the container to get all port assignments or you indicate a specific port to get only that one:

In the case of our original container, we know that we are associated with port 80, and that's what the command indicates. In a production environment, you'll have several containers competing for the same ports. Docker has networks to help us isolate container groups easily and allow us to create custom networks of containers.

Let's just dive in and create a network for our service using docker network:

That's it. We have a network named imagini with the ID returned by the command. We can get a list of current Docker networks with the given command:

There are now four networks, one of which is the one we created. The other three are:

• Bridge: The default one for new containers
• Host: If you want to attach a container directly to the host network
• None: If you don't want a container to have a network at all

Now, let's remove our current deployment and make a few changes. First, let's remove and stop the container:

Second, let's deploy our new database server container on our new network. We'll use the official container image. We'll also create a mysql folder to store the database and anything else the server needs to operate between deployments without losing information.

I'll also introduce another option from Docker, which enables us to name a container. You might have noticed some funny names when you previously listed containers. We can avoid those random names and use our own:

Docker automatically downloaded the latest MySQL version. We now have a database server called imagini-database running on our imagini network. Notice we didn't assign any of its ports to the host because we actually don't need to access it outside our custom network.

You can also see that I defined the database to be created initially, as well as the root password. We're specifying image mysql:5.7, which points to the latest revision of MySQL version 5.7.

This is specific to this image and you can read more about it on the official Docker Hub page. We can confirm that the server is up and running using our local folder by just looking at its content:

Before starting our main service container, we need to make just a few more changes. First, we need to change the settings file to point the configuration to our new database location.

One advantage of using a proper name for a container is that you can use that name just like it was a DNS name. We can confirm that our database server is reachable from another container we created on the same network.

Let's create a container to test this:

We just used an image that's already available and started the container with a bash console. We tried to ping our database server and it works. We then exited the container. Because we used the --rm command, the container is removed after the first stop.

Now, let's remove the settings file to point to the new location and to also change the root password:

{
    "db": "mysql://root:secret@imagini-database/imagini"
}

We can now deploy our container again. We'll just give this container a name, too:

We can see that our service is running correctly, with connections to the new database server by just hitting the stats address and seeing that there are no images there, contrary to our previous version that we used to test this: