The Dockerfile and .dockerignore files are ready. Docker provides us with the tools to generate a real image, which we can run or share with others. Having a Dockerfile on its own does not make an application dockerized.

Make sure that the database credentials specified in the /server/config/index.js file for the back end are valid for development, because they are statically saved there. Furthermore, the MySQL host must allow for remote connections from inside the container.

Execute the following command to build the Docker image on your local machine:

docker build -t sgrebe/graphbook .

This command requires you to have the Docker CLI and daemon installed.

The first option that we use is -t, following a string (in our case, sgrebe/graphbook). The finished build will be saved under the username sgrebe and the application name graphbook. This text is also called a tag. The only required parameter of the docker build command is the build context, or the set of files that Docker will use for the container. We specified the current directory as the build context by adding the dot at the end of the command. Furthermore, the build action expects the Dockerfile to be located within this folder. If you want the file to be taken from somewhere else, you can specify it with the --file option.

When the command has finished generating the image, it should be available locally. To prove this, you can use the Docker CLI by running the following command:

docker images

The output from Docker should look as follows:

You should see two containers; the first one is the sgrebe/graphbook container image, or whatever you used as a tag name. The second one should be the node image, which we used as the base for our custom Docker image. The size of the custom image should be much higher, because we installed all npm packages.

Now, we should be able to start our Docker container with this new image. The following command will launch your Docker container:

docker run -p 8000:8000 -d --env-file .env sgrebe/graphbook

The docker run command also has only one required parameter, which is the image to start the container with. In our case, this is sgrebe/graphbook, or whatever you specified as a tag name. Still, we define some optional parameters that we need to get our application working. You can find an explanation of each of them, as follows:

• We set the -p option to 8000:8000. The parameter is used to map ports from the actual host operating system to a specific port inside of the Docker container. The first port is the port of the host machine, and the second one is the port of the container. This option gives us access to the exposed port 8000, where the application is running under the http://localhost:8000 of our local machine.
• The --env-file parameter is required to pass environment variables to the container. Those can be used to hand over the NODE_ENV or JWT_SECRET variables, for example, which we require throughout our application. We will create this file in a second.

• You can also pass the environment variables one by one using the -e option. It is much easier to provide a file, however.
• The -d option sets the container to detached mode. This means that your container will not run in the foreground after executing it inside the shell. Instead, after running the command, you will have access to the shell again, and will see no output from the container. If you remove the option again, you will see all of the logs that our application triggers.

Let's create the .env file in the root directory of our project. Insert the following content, replacing all placeholders with the correct value for every environment variable:

ENGINE_KEY=YOUR_APLLO_ENGINE_API_KEY
NODE_ENV=development
JWT_SECRET=YOUR_JWT_SECRET
AWS_ACCESS_KEY_ID=YOUR_AWS_KEY_ID
AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_ACCESS_KEY

The .env file is a simple key-value list, where you can specify one variable per line, which our application can access from its environment variables.

It is vital that you do not commit this file to the public at any stage. Please add this file directly to the .gitignore file.

If you have filled out this file, you will be able to start the Docker container with the previous command that I showed you. Now that the container is running in the detached mode, you will have the problem that you cannot be sure whether Graphbook has started to listen. Consequently, Docker also provides a command to test this, as follows:

docker ps

The docker ps command gives you a list of all running containers. You should find the Graphbook container in there, too. The output should appear as follows:

Our container is running, and it uses the database that we have specified. You should be able to use Graphbook as you know it by visiting http://localhost:8000.

If you take a look at the preceding image, you will see that all running containers receive their own ids. This id can be used in various situations to interact with the container.

In development, it makes sense to have access to the command-line printouts that our application generates. When running the container in the detached mode, you have to use the Docker CLI to see the printouts, using the following command. Replace the id at the end of the command with the id of your container:

docker logs 08499322a998

The docker logs command will show you all of the printouts that have been made by our application or container recently. Replace the preceding id with the one given to you by the docker ps command. If you want to see the logs in real time, while using Graphbook, you can add the --follow option.

As we are running the container in the detached mode, you will not be able to stop it by just using Ctrl + C, like before. Instead, you have to use the Docker CLI again.

To stop the container again, run the following command:

docker rm 08499322a998

The docker rm command stops and removes the container from the system. Any changes made to the filesystem inside of the container will be lost. If you start the image again, a new container will be created, with a clean filesystem. Alternatively, you can also use the stop command instead, which only shuts down the container.

When working and developing with Docker frequently, you will probably generate many images to test and verify the deployment of your application. These take up a lot of space on your local machine. To remove the images, you can execute the following command:

docker rmi fe30bceb0268

The id can be taken from the docker images command, the output of which you can see in the first image in this section. You can only remove an image if it is not used in a running container.

We have come far. We have successfully dockerized our application. However, it is still running in development mode, so there is a lot to do.