--- tags: docker,practical --- # Docker Practical ![](https://i.imgur.com/mtx99iM.png) Learn to build and deploy your distributed applications easily to the cloud with `Docker` > [TOC] --- # Introduction ## What is Docker? Wikipedia defines `Docker` as > an open-source project that automates the deployment of software applications inside containers by providing an additional layer of abstraction and automation of OS-level virtualization on Linux. Wow! That's a mouthful. In simpler words, `Docker` is a tool that allows developers, sys-admins etc. to easily deploy their applications in a sandbox (called containers) to run on the host operating system i.e. Linux. The key benefit of Docker is that it allows users to package an application with all of its dependencies into a standardized unit for software development. Unlike virtual machines, containers do not have high overhead and hence enable more efficient usage of the underlying system and resources. ## What are containers? The industry standard today is to use Virtual Machines (VMs) to run software applications. VMs run applications inside a guest Operating System, which runs on virtual hardware powered by the server’s host OS. VMs are great at providing full process isolation for applications: there are very few ways a problem in the host operating system can affect the software running in the guest operating system, and vice-versa. But this isolation comes at great cost — the computational overhead spent virtualizing hardware for a guest OS to use is substantial. Containers take a different approach: by leveraging the low-level mechanics of the host operating system, containers provide most of the isolation of virtual machines at a fraction of the computing power. ## Why use containers? Containers offer a logical packaging mechanism in which applications can be abstracted from the environment in which they actually run. This decoupling allows container-based applications to be deployed easily and consistently, regardless of whether the target environment is a private data center, the public cloud, or even a developer’s personal laptop. This gives developers the ability to create predictable environments that are isolated from the rest of the applications and can be run anywhere. From an operations standpoint, apart from portability containers also give more granular control over resources giving your infrastructure improved efficiency which can result in better utilization of your compute resources. ![Google Trends](https://i.imgur.com/lURSAP0.png) ###### Google Trends for Docker Due to these benefits, containers (& Docker) have seen widespread adoption. Companies like Google, Facebook, Netflix and Salesforce leverage containers to make large engineering teams more productive and to improve utilization of compute resources. In fact, Google credited containers for eliminating the need for an entire data center. ## What will this tutorial teach me? This tutorial aims to be the one-stop shop for getting your hands dirty with Docker. Apart from demystifying the Docker landscape, it'll give you hands-on experience with building and deploying your own webapps. --- # Getting Started This document contains a series of several sections, each of which explains a particular aspect of Docker. In each section, we will be typing commands (or writing code). All the code used in the tutorial is available in the [Github repo](http://github.com/prakhar1989/docker-curriculum). > **Note**: This tutorial uses version 18.05.0-ce of Docker. If you find any part of the tutorial incompatible with a future version, please [raise an issue](https://github.com/prakhar1989/docker-curriculum/issues). Thanks! ## Prerequisites There are no specific skills needed for this tutorial beyond a basic comfort with the command line and using a text editor. This tutorial uses git clone to clone the repository locally. If you don't have Git installed on your system, either install it or remember to manually download the zip files from Github. Prior experience in developing web applications will be helpful but is not required. ## Setting up your computer Getting all the tooling setup on your computer can be a daunting task, but thankfully as Docker has become stable, getting Docker up and running on your favorite OS has become very easy. Until a few releases ago, running Docker on OSX and Windows was quite a hassle. Lately however, Docker has invested significantly into improving the on-boarding experience for its users on these OSes, thus running Docker now is a cakewalk. The getting started guide on Docker has detailed instructions for setting up Docker on [Mac](https://docs.docker.com/docker-for-mac/install), [Linux](https://docs.docker.com/install/linux/docker-ce/ubuntu) and [Windows](https://docs.docker.com/docker-for-windows/install). Once you are done installing Docker, test your Docker installation by running the following: ```bash= $ docker run hello-world Hello from Docker. This message shows that your installation appears to be working correctly. ... ``` --- # Hello World ## Playing with Busybox Now that we have everything setup, it's time to get our hands dirty. In this section, we are going to run a [Busybox](https://en.wikipedia.org/wiki/BusyBox) container on our system and get a taste of the `docker run` command. To get started, let's run the following in our terminal: ```bash= $ docker pull busybox ``` > **Note**: Depending on how you've installed docker on your system, you might see a `permission denied` error after running the above command. If you're on a Mac, make sure the Docker engine is running. If you're on Linux, then prefix your `docker` commands with `sudo`. Alternatively, you can [create a docker group](https://docs.docker.com/engine/installation/linux/linux-postinstall/) to get rid of this issue. The `pull` command fetches the [busybox image](https://hub.docker.com/_/busybox/) from the [Docker registry](https://hub.docker.com/explore/) and saves it to our system. You can use the `docker images` command to see a list of all images on your system. ```bash= $ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE busybox latest c51f86c28340 4 weeks ago 1.109 MB ``` --- ## Docker Run Great! Let's now run a Docker container based on this image. To do that we are going to use the almighty `docker run` command. ```bash= $ docker run busybox ``` Wait, nothing happened! Is that a bug? Well, no. Behind the scenes, a lot of stuff happened. When you call `run`, the Docker client finds the image (busybox in this case), loads up the container and then runs a command in that container. When we run `docker run busybox`, we didn't provide a command, so the container booted up, ran an empty command and then exited. Well, yeah - kind of a bummer. Let's try something more exciting. ```bash= $ docker run busybox echo "hello from busybox" hello from busybox ``` Nice - finally we see some output. In this case, the Docker client dutifully ran the `echo` command in our busybox container and then exited it. If you've noticed, all of that happened pretty quickly. Imagine booting up a virtual machine, running a command and then killing it. Now you know why they say containers are fast! Ok, now it's time to see the `docker ps` command. The `docker ps` command shows you all containers that are currently running. ```bash= $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ``` Since no containers are running, we see a blank line. Let's try a more useful variant: `docker ps -a` ```bash= $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 305297d7a235 busybox "uptime" 11 minutes ago Exited (0) 11 minutes ago distracted_goldstine ff0a5c3750b9 busybox "sh" 12 minutes ago Exited (0) 12 minutes ago elated_ramanujan 14e5bd11d164 hello-world "/hello" 2 minutes ago Exited (0) 2 minutes ago thirsty_euclid ``` So what we see above is a list of all containers that we ran. Do notice that the `STATUS` column shows that these containers exited a few minutes ago. You're probably wondering if there is a way to run more than just one command in a container. Let's try that now: ```bash= $ docker run -it busybox sh / # ls bin dev etc home proc root sys tmp usr var / # uptime 05:45:21 up 5:58, 0 users, load average: 0.00, 0.01, 0.04 ``` Running the `run` command with the `-it` flags attaches us to an interactive tty in the container. Now we can run as many commands in the container as we want. Take some time to run your favorite commands. > **Danger Zone**: If you're feeling particularly adventurous you can try `rm -rf bin` in the container. Make sure you run this command in the container and **not** in your laptop/desktop. Doing this will make any other commands like `ls`, `uptime` not work. Once everything stops working, you can exit the container (type `exit` and press Enter) and then start it up again with the `docker run -it busybox sh` command. Since Docker creates a new container every time, everything should start working again. That concludes a whirlwind tour of the mighty `docker run` command, which would most likely be the command you'll use most often. It makes sense to spend some time getting comfortable with it. To find out more about `run`, use `docker run --help` to see a list of all flags it supports. As we proceed further, we'll see a few more variants of `docker run`. Before we move ahead though, let's quickly talk about deleting containers. We saw above that we can still see remnants of the container even after we've exited by running `docker ps -a`. Throughout this tutorial, you'll run `docker run` multiple times and leaving stray containers will eat up disk space. Hence, as a rule of thumb, I clean up containers once I'm done with them. To do that, you can run the `docker rm` command. Just copy the container IDs from above and paste them alongside the command. ```bash= $ docker rm 305297d7a235 ff0a5c3750b9 305297d7a235 ff0a5c3750b9 ``` On deletion, you should see the IDs echoed back to you. If you have a bunch of containers to delete in one go, copy-pasting IDs can be tedious. In that case, you can simply run - ```bash= $ docker rm $(docker ps -a -q -f status=exited) ``` This command deletes all containers that have a status of `exited`. In case you're wondering, the `-q` flag, only returns the numeric IDs and `-f` filters output based on conditions provided. One last thing that'll be useful is the `--rm` flag that can be passed to `docker run` which automatically deletes the container once it's exited from. For one off docker runs, `--rm` flag is very useful. In later versions of Docker, the `docker container prune` command can be used to achieve the same effect. ```bash= $ docker container prune WARNING! This will remove all stopped containers. Are you sure you want to continue? [y/N] y Deleted Containers: 4a7f7eebae0f63178aff7eb0aa39f0627a203ab2df258c1a00b456cf20063 f98f9c2aa1eaf727e4ec9c0283bcaa4762fbdba7f26191f26c97f64090360 Total reclaimed space: 212 B ``` Lastly, you can also delete images that you no longer need by running `docker rmi`. --- ## Terminology In the last section, we used a lot of Docker-specific jargon which might be confusing to some. So before we go further, let me clarify some terminology that is used frequently in the Docker ecosystem. * **Images** - The blueprints of our application which form the basis of containers. In the demo above, we used the `docker pull` command to download the busybox image. * **Containers** - Created from Docker images and run the actual application. We create a container using `docker run` which we did using the busybox image that we downloaded. A list of running containers can be seen using the `docker ps` command. * **Docker Daemon** - The background service running on the host that manages building, running and distributing Docker containers. The daemon is the process that runs in the operating system which clients talk to. * **Docker Client** - The command line tool that allows the user to interact with the daemon. More generally, there can be other forms of clients too - such as [Kitematic](https://kitematic.com/) which provide a GUI to the users. * **Docker Hub** - A [registry](https://hub.docker.com/explore/) of Docker images. You can think of the registry as a directory of all available Docker images. If required, one can host their own Docker registries and can use them for pulling images. --- # Webapps with Docker Great! So we have now looked at `docker run`, played with a Docker container and also got a hang of some terminology. Armed with all this knowledge, we are now ready to get to the real-stuff, i.e. deploying web applications with Docker! ## Static Sites Let's start by taking baby-steps. The first thing we're going to look at is how we can run a dead-simple static website. We're going to pull a Docker image from Docker Hub, run the container and see how easy it is to run a webserver. The image that we are going to use is a single-page [website](http://github.com/prakhar1989/docker-curriculum) that was already created for the purpose of this demo and hosted on the [registry](https://hub.docker.com/r/prakhar1989/static-site/) - `prakhar1989/static-site`. We can download and run the image directly in one go using `docker run`. As noted above, the `--rm` flag automatically removes the container when it exits. ```bash= $ docker run --rm prakhar1989/static-site ``` Since the image doesn't exist locally, the client will first fetch the image from the registry and then run the image. If all goes well, you should see a `Nginx is running...` message in your terminal. Okay now that the server is running, how to see the website? What port is it running on? And more importantly, how do we access the container directly from our host machine? Hit Ctrl+C to stop the container. Well, in this case, the client is not exposing any ports so we need to re-run the `docker run` command to publish ports. While we're at it, we should also find a way so that our terminal is not attached to the running container. This way, you can happily close your terminal and keep the container running. This is called **detached** mode. ```bash= $ docker run -d -P --name static-site prakhar1989/static-site ``` In the above command, `-d` will detach our terminal, `-P` will publish all exposed ports to random ports and finally `--name` corresponds to a name we want to give. Now we can see the ports by running the `docker port [CONTAINER]` command ```bash= $ docker port static-site 80/tcp -> 0.0.0.0:32769 443/tcp -> 0.0.0.0:32768 ``` You can open http://localhost:32769 :warning: 32769 is the port shown in our example, if you get a different number in your terminal change 32769 for the number shown in your terminal in your browser. > Note: If you're using docker-toolbox, then you might need to use `docker-machine ip default` to get the IP. You can also specify a custom port to which the client will forward connections to the container. ```bash= $ docker run -p 8888:80 prakhar1989/static-site Nginx is running... ``` ![Hello Docker Image](https://i.imgur.com/zKfRdAq.png) To stop a detached container, run `docker stop` by giving the container ID. In this case, we can use the name `static-site` we used to start the container. ```bash= $ docker stop static-site static-site ``` I'm sure you agree that was fairly simple. To deploy this on a real server you would just need to install Docker, and run the above Docker command. Now that you've seen how to run a webserver inside a Docker image, you must be wondering - how do I create my own Docker image? This is the question we'll be exploring in the next section. --- ## Docker Images We've looked at images before, but in this section we'll dive deeper into what Docker images are and build our own image! Lastly, we'll also use that image to run our application locally! Excited? Great! Let's get started. Docker images are the basis of containers. In the previous example, we pulled the Busybox image from the registry and asked the Docker client to run a container based on that image. To see the list of images that are available locally, use the `docker images` command. ```bash= $ docker images REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE prakhar1989/catnip latest c7ffb5626a50 2 hours ago 697.9 MB prakhar1989/static-site latest b270625a1631 21 hours ago 133.9 MB python 3-onbuild cf4002b2c383 5 days ago 688.8 MB martin/docker-cleanup-volumes latest b42990daaca2 7 weeks ago 22.14 MB ubuntu latest e9ae3c220b23 7 weeks ago 187.9 MB busybox latest c51f86c28340 9 weeks ago 1.109 MB hello-world latest 0a6ba66e537a 11 weeks ago 960 B ``` The above gives a list of images that I've pulled from the registry, along with ones that I've created myself (we'll shortly see how). The `TAG` refers to a particular snapshot of the image and the `IMAGE ID` is the corresponding unique identifier for that image. For simplicity, you can think of an image akin to a git repository - images can be [committed](https://docs.docker.com/engine/reference/commandline/commit/) with changes and have multiple versions. If you don't provide a specific version number, the client defaults to `latest`. For example, you can pull a specific version of `ubuntu` image ```bash= $ docker pull ubuntu:18.04 ``` To get a new Docker image you can either get it from a registry (such as the Docker Hub) or create your own. There are tens of thousands of images available on [Docker Hub](https://hub.docker.com/explore/). You can also search for images directly from the command line using `docker search`. An important distinction to be aware of when it comes to images is the difference between base and child images. * Base images are images that have no parent image, usually images with an OS like ubuntu, busybox or debian. * Child images are images that build on base images and add additional functionality. Then there are official and user images, which can be both base and child images. * Official images are images that are officially maintained and supported by the folks at Docker. These are typically one word long. In the list of images above, the `python`, `ubuntu`, `busybox` and `hello-world` images are official images. * User images are images created and shared by users like you and me. They build on base images and add additional functionality. Typically, these are formatted as `user/image-name`. --- ## Our First Image Now that we have a better understanding of images, it's time to create our own. Our goal in this section will be to create an image that sandboxes a simple [Flask](http://flask.pocoo.org/) application. For the purposes of this workshop, I've already created a fun little [Flask app](https://github.com/prakhar1989/docker-curriculum/tree/master/flask-app) that displays a random cat `.gif` every time it is loaded - because you know, who doesn't like cats? If you haven't already, please go ahead and clone the repository locally like so - ```bash= $ git clone https://github.com/prakhar1989/docker-curriculum.git $ cd docker-curriculum/flask-app ``` > This should be cloned on the machine where you are running the docker commands and not inside a docker container. --- ## Dockerfile A [Dockerfile](https://docs.docker.com/engine/reference/builder/) is a simple text file that contains a list of commands that the Docker client calls while creating an image. It's a simple way to automate the image creation process. The best part is that the [commands](https://docs.docker.com/engine/reference/builder/#from) you write in a Dockerfile are almost identical to their equivalent Linux commands. This means you don't really have to learn new syntax to create your own dockerfiles. The application directory does contain a `Dockerfile` but since we're doing this for the first time, we'll create one from scratch. To start, create a new blank file in our favorite text-editor and save it in the same folder as the flask app by the name of `Dockerfile`. We start with specifying our base image. Use the `FROM` keyword to do that - ```dockerfile= FROM python:3.8 ``` The next step usually is to write the commands of copying the files and installing the dependencies. First, we set a working directory and then copy all the files for our app. ```dockerfile= # set a directory for the app WORKDIR /usr/src/app # copy all the files to the container COPY . . ``` Now, that we have the files, we can install the dependencies. ```dockerfile= # install dependencies RUN pip install --no-cache-dir -r requirements.txt ``` The next thing we need to specify is the port number that needs to be exposed. Since our flask app is running on port `5000`, that's what we'll indicate. ```dockerfile= EXPOSE 5000 ``` The last step is to write the command for running the application, which is simply - `python ./app.py`. We use the CMD command to do that - ```dockerfile= CMD ["python", "./app.py"] ``` The primary purpose of `CMD` is to tell the container which command it should run when it is started. With that, our `Dockerfile` is now ready. This is how it looks - ```dockerfile= FROM python:3.8 # set a directory for the app WORKDIR /usr/src/app # copy all the files to the container COPY . . # install dependencies RUN pip install --no-cache-dir -r requirements.txt # define the port number the container should expose EXPOSE 5000 # run the command CMD ["python", "./app.py"] ``` Now that we have our `Dockerfile`, we can build our image. The `docker build` command does the heavy-lifting of creating a Docker image from a `Dockerfile`. The section below shows you the output of running the same. The `docker build` command is quite simple - it takes an optional tag name with `-t` and a location of the directory containing the `Dockerfile`. ```bash= $ docker build -t catnip . Sending build context to Docker daemon 8.704 kB Step 1 : FROM python:3.8 # Executing 3 build triggers... Step 1 : COPY requirements.txt /usr/src/app/ ---> Using cache Step 1 : RUN pip install --no-cache-dir -r requirements.txt ---> Using cache Step 1 : COPY . /usr/src/app ---> 1d61f639ef9e Removing intermediate container 4de6ddf5528c Step 2 : EXPOSE 5000 ---> Running in 12cfcf6d67ee ---> f423c2f179d1 Removing intermediate container 12cfcf6d67ee Step 3 : CMD python ./app.py ---> Running in f01401a5ace9 ---> 13e87ed1fbc2 Removing intermediate container f01401a5ace9 Successfully built 13e87ed1fbc2 ``` If you don't have the `python:3.8` image, the client will first pull the image and then create your image. Hence, your output from running the command will look different from mine. If everything went well, your image should be ready! Run `docker images` and see if your image shows. The last step in this section is to run the image and see if it actually works (replacing my username with yours). ```bash= $ docker run -p 8888:5000 catnip * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit) ``` The command we just ran used port `5000` for the server inside the container and exposed this externally on port `8888`. Head over to the URL with port `8888`, where your app should be live. ![cat iamge website](https://i.imgur.com/WrRYWqV.png) Congratulations! You have successfully created your first docker image. --- # Conclusion! And that's a wrap! After a long, exhaustive but fun tutorial you are now ready to take the container world by storm! If you followed along till the very end then you should definitely be proud of yourself. You learned how to setup Docker, run your own containers and play with static and dynamic websites. I hope that finishing this tutorial makes you more confident in your abilities to deal with servers. When you have an idea of building your next app, you can be sure that you'll be able to get it in front of people with minimal effort. Thank you for going through this practical, based on the [Docker Tutorial for Beginners by Prakhar Srivastav](https://docker-curriculum.com/) and adapted for Manchester Codes as a practical without the Cloud deployment sections.