Alright, now that we have the basics down of what Docker is and how to spin up containers, we can move on to customizing a container. In the previous video, we were pulling in containers through their names and tags based on images in the Docker Hub, like ubuntu-latest. There are a lot of these images that we can use for a variety of different purposes, but what if we needed to build something of our own? We can easily do that by creating and using our own custom Dockerfile. Let's start out by setting up a project root folder, and creating a file called just Dockerfile. The aim of this file is to provide a set of instructions for Docker to use that builds and prepares our container when we use docker run.

The aim of this file is to provide a set of instructions for Docker to use that builds and prepares our container when we use docker run. Before we start writing those out, let's think of something that we can do with this container. How about, let's spin something up that runs this JSON server package, which creates a few API test endpoints based off of a JSON file. The first thing that has to be included in every Dockerfile is the FROM command. This is followed by the base image that you want to build your container off of. It could be something like ubuntu:latest, but since JSON server is a Node package, I'm going to build it off of node:latest. And at this point we basically have a blank slate with both Node and npm installed and

going to build it off of node-latest. And at this point we basically have a blank slate with both node and npm installed and ready. So our next step should be installing JSON server. Before we get to that, we'll use Docker's workdir command, which lets you determine what directory we're going to be in when we run any following command. We'll use home-server. Oh, and if the directory isn't available, it'll be created for us. Okay, on our local machine, we would install JSON server by running npm install -g json-server. And now our container needs the same command.

Okay, on our local machine, we would install JSON server by running npm install -g json-server. And now our container needs the same command. We can run commands inside of a container by using the aptly named run command. And next, we need a way to provide JSON server with a file for its data. Let's open up our project root and create one called db.json. And I'm going to add a few posts to it, as well as a basic profile. All right, that looks good. Back in our Dockerfile, we can use the copy command, which takes two arguments, a directory or file on your local machine, like our db.json file, and the directory or file we're going to copy to, which is inside of the built container, /home/server/db.json.

or file on your local machine, like our db.json file, and the directory or file we're going to copy to, which is inside of the built container, home-server-db.json. Now the last thing we need to do is tell Docker to actually run JSON server. There's two ways to do this, and neither of them involve the previous run command that we used. There's ENTRYPOINT and CMD. ENTRYPOINT is the main command ran by the Docker container. This is what the entire container is built for, and basically, its sole purpose. It cannot be overwritten by commands on the host machine. Instead, commands are added to it.

It cannot be overwritten by commands on the host machine. Instead, commands are added to it. Cmd, on the other hand, is for additional commands or options that will run after the entrypoint command. For what we're doing, entrypoint is what we're after. And then our command, json-server db.json. Except there's a slight hiccup with writing the entrypoint command like this. This is called the shell form, and it runs the command as a parameter to /bin/sh with the -c flag. Instead we want to use the exec form, which takes your original command and makes it an

the c flag. Instead we want to use the exec form, which takes your original command and makes it an array of strings replacing the original spaces. So our new entrypoint looks like this. Alright let's save this, and it's time to build. Back in our terminal, we can run docker build and pass in the current directory. Docker looks for a Dockerfile with the same name as the one we created. However, if you named yours something differently, you'll pass that in instead. Alright once that finishes up, we can run docker image ls, which will provide a list of all the Docker images available on our machine.

Alright once that finishes up, we can run docker image ls, which will provide a list of all the docker images available on our machine. These are sorted by when they were created, with the newest ones first. We just have the one that we just built, so we'll copy the id and put it to use. Like the previous video, we can run docker run with the --rm flag and pass in the id. And now we're seeing the hello screen from JSON Server, and it looks like our db.json file was copied in and parsed into a posts and profile route. Let's see if we can load up this domain. localhost:3000. Uh oh, we are not seeing anything available to us.

Localhost 3000. Uh oh, we are not seeing anything available to us. That's because JSON server is running on port 3000, but that port is isolated inside of the docker container. It's not exposed to our local machine, and so we can't send or receive any data from it. But we can change that. First let's bring down the docker container that's running. In a new tab, we'll run docker ps. This gets us all of the images that are currently running, which right now is just ours.

In a new tab, we'll run docker ps. This gets us all of the images that are currently running, which right now is just ours. We'll copy the id of the container, and then run docker stop, pasting in the id. Alright let's open up our docker file again. After our copy statement, we'll add another command called expose. This expects a port number, and gives our container the ability to map a port from our host machine into the docker container at the port specified. By default we saw that JSON server runs at port 3000, so that's what we'll use. One more thing. By default JSON server runs at localhost, but we need to specify a different IP address.

One more thing. By default JSON server runs at localhost, but we need to specify a different IP address. In our entry point, let's add the host flag, and then the address 0.0.0.0, which is the default docker bridge network IP, essentially connecting our host machine to the docker instance. Alright, save, and let's rebuild the container. docker build, current directory, and I'm going to throw in this --no-cache flag, which should help disregard any cached files that might have changed. And once that's done, we'll get the id again through the docker image list command. After run, rm, and remember that expose 3000 port that we specified in our Dockerfile?

And once that's done, we'll get the id again through the docker image list command. After run, rm, and remember that expose 3000 port that we specified in our Dockerfile? Passing in the -p flag, we can choose which port on our local machine we bind that to. For simplicity's sake, I'm just going to use this same one: 3000:3000. The first number is our local system, and the second number is the docker container. And then our image id. Our container's up and running again, so let's take a look at localhost:3000 in our browser. Perfect, we are seeing the JSON server landing page as expected, and we can click through the routes and see the data that we provided.

Perfect, we are seeing the JSON server landing page as expected, and we can click through the routes and see the data that we provided. There's one last thing I'd like to show, and that's how we can use this cmd command I talked about earlier to specify some optional arguments. Let's bring down this container. docker ps, grab the container id, docker stop container. Okay, opening up our Dockerfile again, and under the COPY command, let's copy another file. This one will be called alt.json. Copy to the same directory as db.json.

This one will be called alt.json. Copy to the same directory as db.json. And we'll remove the db.json string from the entry point. At the end of our Dockerfile, we'll add a CMD line, and using the same exec method as the entry point, pass in an array of strings just consisting of the db.json file. And in our project directory, we'll copy db.json as alt.json. And let's make a few changes to it so that we know there's a difference. Okay, let's rebuild our Docker container one more time. After build, current directory, --no-cache. And actually, we can use the -t flag and pass in a tag name, so we don't have to get the

After build, current directory, no cache. And actually, we can use the -t flag and pass in a tag name, so we don't have to get the image ID each time. If you want this published to the Docker Hub, it's recommended to specify an image name, then a colon and a version tag. But for this demo, we can just use a name, json-server. And after it's built, we can run it again with docker run --rm -p 3000:3000 json-server. Taking a look in the browser, we can see that it's pulled in the db.json file, since that was the default value given in our cmd line. But if we bring this container down and rerun it, specifying the alt.json file at the end,

was the default value given in our cmd line. But if we bring this container down and rerun it, specifying the alt.json file at the end, this overrides that cmd line with the value that we provided, which means that the file pulled in was our copied and modified one instead. And we can see that here. In the next video, we're going to use this info to start scaffolding out a Dockerfile for a Laravel application.