Docker for Beginners: A Comprehensive Guide to Containerization

Hello and welcome to the Docker for beginners  course. My name is moonshot 100, and I will be   your instructor for this course. I'm a DevOps  and cloud trainer at code cloud comm, which is   an interactive hands on online learning platform.  I've been working in the industry as a consultant  

for over 13 years and have helped hundreds of  1000s of students learn technology in a fun and   interactive way. In this course, you will learn  Docker through a series of lectures that use   animation illustration, and some fun analogies  that simplify complex concepts with demos that  

will show you how to install and get started with  Docker. And most importantly, we have hands on   labs that you can access right in your browser.  I will explain more about it in a bit. But first,   let's look at the objectives of this course.  In this course, we first try to understand what  

containers are, what Docker is, and why you might  need it and what it can do for you. We will see   how to run a Docker container how to build your  own Docker image, we will see networking in Docker   and how to use Docker compose what Docker registry  is how to deploy your own private registry. And we  

then look at some of these concepts in depth. And  we try to understand how Docker really works under   the hood. We look at Docker for Windows and Mac  before finally getting a basic introduction to   container orchestration tools like Docker, swarm,  and Kubernetes. Here's a quick note about hands on  

labs. First of all, to complete this course, you  don't have to set up your own labs. Well, you may   set it up if you wish to, if you wish to have your  own environment, and we have a demo as well. But   as part of this course, we provide real labs that  you can access right in your browser anywhere,  

anytime and as many times as you want. The labs  give you instant access to a terminal to a Docker   host and an accompanying quiz portal. The quiz  portal asks a set of questions such as exploring   the environment and gathering information. Or you  might be asked to perform an action such as run  

Docker container. The quiz portal then validates  your work and gives you feedback instantly. every   lecture in this course is accompanied by  such challenging interactive quizzes that   makes learning Docker a fun activity. So I hope  you're as thrilled as I am to get started. So let  

us begin. We're going to start by looking at  a high level overview on why you need Docker,   and what it can do for you. Let me start by  sharing how I got introduced to Docker. And one   of my previous projects, I had this requirement  to set up an end to end application stack,  

including various different technologies, like  a web server using node j s, and a database such   as MongoDB, and a messaging system like Redis,  and an orchestration tool like Ansible, we had   a lot of issues developing this application stack  with all these different components. First of all,  

their compatibility with the underlying OS was an  issue, we had to ensure that all these different   services were compatible with the version of OS  we were planning to use. There have been times   when certain version of the services were not  compatible with the OS. And we've had to go back  

and look at different OS that was compatible with  all of these different services. Secondly, we had   to check the compatibility between the services  and the libraries and dependencies on the OS.   We've had issues where one service requires one  version of a dependent library, whereas another  

service requires another version, the architecture  of our application changed over time, we've had to   upgrade to newer versions of these components, or  change the database, etc. And every time something   changed, we had to go through the same process  of checking compatibility between these various  

components, and the underlying infrastructure.  This compatibility matrix issue is usually   referred to ask the matrix from hell. Next, every  time we had a new developer on board, we found it   really difficult to set up a new environment,  the new developers had to follow a large set  

of instructions and run hundreds of commands to  finally set up their environments, we had to make   sure they were using the right operating system,  the right versions of each of these components.   And each developer had to set all that up  by himself each time. He also had different  

development tests and production environments. One  developer may be comfortable using one or less and   the others may be comfortable using another one.  And so we couldn't guarantee that the application   that we were building would run the same way in  different environments. And so all of this made  

our life in developing better Building and  shipping the application really difficult.   So I needed something that could help us with the  compatibility issue. And something that will allow   us to modify or change these components without  affecting the other components and even modify the  

underlying operating systems as required. And  that search landed me on Docker. with Docker,   I was able to run each component in a  separate container with its own dependencies,   and its own libraries, all on the same VM  and the OS, but within separate environments,  

or containers. We just had to build the Docker  configuration once and all our developers could   now get started with a simple Docker run command.  irrespective of what the underlying operating   system they're on. All they needed to do was  to make sure they had Docker installed on their  

systems. So what are containers, containers  are completely isolated environments. As in   they can have their own processes or services,  their own network interfaces, their own mounts,   just like washing machines, except they all share  the same OS kernel. We will look at what that  

means in a bit. But it's also important to note  that containers are not new with Docker containers   have existed for about 10 years now and some of  the different types of containers are Aleksey LSD   like CFS, etc. Docker utilizes Aleksey containers.  Setting up these container environments is hard as  

they are very low level and that is where Docker  offers a high level two, with several powerful   functionalities making it really easy for end  users like us. To understand how Docker works,   let us revisit some basic concepts of operating  systems First, if you look at operating systems  

like Ubuntu, Fedora, Susi or CentOS, they all  consist of two things, an OS kernel and a set   of software. The OS kernel is responsible for  interacting with the underlying hardware, while   the OS kernel remains the same, which is Linux. In  this case, it's the software above it that makes  

these operating systems different. This software  may consist of a different user interface drivers,   compilers, file managers, developer tools, etc. So  you have a common Linux kernel shared across all   OSS and some custom software that differentiate  operating systems from each other. We said earlier  

that Docker containers share the underlying  kernel. So what does that actually mean? Sharing   the kernel? Let's say we have a system with an  Ubuntu OS with Docker installed on it. Docker   can run any flavor of OS on top of it, as long  as they're all based on the same kernel. In this  

case, Linux. If the underlying OS is Ubuntu,  Docker can run a container based on another   distribution like Debian Fedora Susi or CentOS  each Docker container only has the additional   software that we just talked about in the  previous slide that makes these operating systems  

different. And Docker utilizes the underlying  kernel of the Docker host, which works with all   OSS above. So what is an OS that do not share the  same kernel as this windows. And so you won't be   able to run a Windows based container on a Docker  host with Linux on it. For that you will require  

Docker on a Windows Server. Now it is when I say  this, that most of my students go, Hey, hold on   there. That's not true. And they install Docker  on Windows, run a container based on Linux and go   see it's possible. Well, when you install Docker  on Windows and run a Linux container on Windows,  

you're not really running a Linux container on  Windows, Windows runs a Linux container on a Linux   virtual machine under the hoods. So it's really  a Linux container on Linux virtual machine on   Windows. We discuss more about this on the Docker  on Windows or Mac later during this course. Now,  

you might ask, isn't that a disadvantage then not  being able to run another kernel? On the OS? The   answer is no. Because unlike hypervisors,  Docker is not meant to virtualize and run   different operating systems and kernels on the  same hardware. The main purpose of Docker is  

to package and containerize applications and  to ship them and to run them anywhere anytime,   as many times as you want. So that brings us  to the differences between virtual machines   and containers, something that we tend to do  especially those from a virtualization background.  

As you can see on the right, in case of Docker,  we have the underlying hardware, infrastructure   and then the OS and then Docker installed on  the OS. Docker then manages the containers that   run with libraries and dependencies alone.  In case of virtual machines, we have the  

hypervisor like ESX on the hardware, and then  the virtual machines on them. As you can see,   each virtual machine has its own oil inside it.  Then the dependencies and then the application.   The overhead causes higher utilization of  underlying resources as there are multiple  

virtual operating systems and kernels running. The  virtual machines also consumed higher disk space,   as each VM is heavy, and is usually in gigabytes  in size, whereas Docker containers are lightweight   and are usually in megabytes in size. This allows  Docker containers to boot up faster, usually in a  

matter of seconds, whereas VMs as we know, takes  minutes to boot up as it needs to boot up the   entire operating system. It's also important  to note that Docker has less isolation as   more resources are shared between the containers  like kernel, whereas VMs have complete isolation  

from each other. Since VMs, don't rely on the  underlying OS or kernel, you can run different   types of applications built on different services  such as Linux based or Windows based apps on the   same hypervisor. So those are some differences  between the two. Now, having said that, it's not  

an either container or virtual machine situation.  Its containers and virtual machines. Now, when you   have large environments with 1000s of application  containers running on 1000s of Docker hosts,   you will often see containers provisioned on  virtual Docker hosts. That way, we can utilize the  

advantages of both technologies, we can use the  benefits of virtualization, to easily provision   or decommission Docker hosts, as required, at the  same time make use of the benefits of Docker to   easily provision applications and quickly scale  them as required. But remember that in this case,  

we will not be provisioning that many virtual  machines as we used to before, because earlier,   we provisioned a virtual machine for each  application. Now, you might provision a virtual   machine for hundreds or 1000s of containers. So  how is it done? There are lots of containerized  

versions of applications readily available as of  today. So most organizations have their products   containerized and available in a public Docker  repository called Docker Hub, or Docker store.   For example, you can find images of most common  operating systems, databases, and other services  

and tools. Once you identify the images you need,  and you install Docker on your host. Bringing up   an application is as easy as running a Docker run  command with the name of the image. In this case,   running a Docker run Ansible command will run an  instance of Ansible on the Docker host. Similarly  

run an instance of MongoDB Redis and node j s  using the Docker run command. If we need to run   multiple instances of the web service, simply  add as many instances as you need and configure   a load balancer of some kind in the front.  In case one of the instances were to fail,  

simply destroy that instance and launch anyone.  There are other solutions available for handling   such cases that we will look at later during  this course. And for now, don't focus too much   on the commands. We'll get to that in a bit.  We've been talking about images and containers,  

let's understand the difference between the  two. An image is a package or a template,   just like a VM template that you might have worked  within the virtualization world, it is used to   create one or more containers. Containers are  running instances of images that are isolated and  

have their own environments and set of processes.  As we have seen before, a lot of products have   been dockerized already, in case you cannot find  what you're looking for. You could create your own   image and push it to Docker Hub repository, making  it available for public. So if you look at it,  

traditionally, developers developed applications,  then they hand it over to ops team to deploy and   manage it in production environments. They do  that by providing a set of instructions such   as information about how the host must be set up,  what prerequisites are to be installed on the host  

and how the dependencies are to be configured  etc. Since the ops team did not really develop   the application on their own, they struggle  with setting it up. When they hit an issue,   they work with the developers to resolve it.  with Docker, developers and operations teams work  

hand in hand to transform the guide into a Docker  file with both of their requirements. This Docker   file is then used to create an image for their  applications. This image can now run on any host   with Docker installed on it, and is guaranteed  to run the same way everywhere. So the ops  

team can now simply use the image to deploy the  application. Since the image was already working,   when the developer built it, and operations are  have not modified it. It continues to work the   same way when deployed in production. And that's  one example of how a tool like Docker contributes  

to the DevOps culture. Well, that's it for now.  In the upcoming lecture, we will look at how to   get started with Docker. We'll now see how to get  started with Docker. Now Docker has two editions,   the Community Edition and the Enterprise Edition.  The Community Edition is the set of free Docker  

products. The Enterprise Edition is the certified  and supported container platform that comes with   enterprise add ons like the image management image  security, universal control plane for managing   and orchestrating container runtimes. But of  course, these come with a price. We will discuss  

more about container orchestration later in this  course, and along with some alternatives. For now,   we will go ahead with the Community Edition.  The Community Edition is available on Linux,   Mac, Windows, or on cloud platforms like AWS, or  Azure. In the upcoming demo, we will take a look  

at how to install and get started with Docker on  a Linux system. Now, if you are on Mac or Windows,   you have two options, either install a Linux VM  using VirtualBox or some kind of virtualization   platform. And then follow along with the upcoming  demo, which is really the most easiest way to get  

started with Docker. The second option is  to install Docker desktop for Mac or adopt   Docker desktop for Windows, which are native  applications. So if that is really what you   want the check out the Docker for Mac and the  windows sections towards the end of this course,  

and then head back here. Once you're all  set up. We will now head over to our demo,   and we will take a look at how to install Docker  on a Linux machine. In this demo, we look at how   to install and get started with Docker. First  of all, identify a system physical or virtual  

machine or laptop that has a supported operating  system. In my case, I have an Ubuntu VM. Go to   Doc's dot Docker comm and click on Get Docker.  You will be taken to the Docker engine Community   Edition page. That is the free version that we're  after. From the left hand menu, select your system  

type. I choose Linux In my case, and then select  your OS flavor. I choose Ubuntu read through the   prerequisites and requirements. Your Ubuntu system  must be 64 bit and one of the supported versions   like this called cosmic bionic or sannio. In my  case, I have a bionic version to confirm view the  

Etsy release file. Next uninstaller any older  version if one exists, so let's just make sure   that there's none on my host. So I'll just copy  and paste that command. And I confirm that there   are no older version that exists on my system. The  next step is to set up a repository and install  

the software. Now there are two ways to go about  this. The first is using the package manager by   first updating the repository using the apt get  update command, then installing the prerequisite   packages, and then adding Dockers official GPG  keys and then installing Docker. But I'm not  

going to go that route. There is an easier way.  If you scroll all the way to the bottom you will   find the instructions to install Docker using the  convenience script. It's a script that automates   the entire installation process and works on  most operating systems. Run the first command  

to download a copy of the script and then run the  second command to execute the script to install   Docker automatically. Give it a few minutes to  complete the installation. The installation is   now successful. Let us now check the version  of Docker using the Docker version command. We  

have installed version 19.0 3.1. We will now run  a simple container to ensure everything is working   as expected. For this, head over to Docker Hub at  hub Docker Comm. Here you will find a list of the   most popular Docker images like nginx MongoDB,  Alpine, no jazz Redis, etc. Let's search for a  

fun image called we'll say we'll say is Dockers  version of kousei which is basically A simple   application that trains a cow saying something. In  this case, it happens to be a well copy the Docker   run command given here. Remember to add sudo  and we will change the message to hello world.  

On running this command, Docker pulls the image  of the willsey application from Docker Hub and   runs it. And we have our avail, saying, hello.  Great. We're all set. Remember, for the purpose   of this course, you don't really need to set up  a Docker system on your own. We provide hands  

on labs that you will get access to but if you  wish to experiment on your own and follow along,   feel free to do so. We now look at some of the  Docker commands. At the end of this lecture,   you will go through a hands on quiz where you will  practice working with these commands. Let's start  

by looking at Docker run command. The Docker run  command is used to run a container from an image   running the Docker run nginx command will run an  instance of the nginx application from the Docker   host if it already exists. If the image is not  present on the host, he will go out to Docker Hub  

and pull the image down. But this is only done  the first time. For the subsequent executions,   the same image will be reduced. The docker  ps command lists all running containers and   some basic information about them. Such as  the container ID, the name of the image we  

use to run the containers, the current status  and the name of the container. Each container   automatically gets a random ID and Name created  for it by Docker, which in this case is silly   summit. To see all containers running or not  use the dash eight option. This output all  

running as well as previously stopped or exited  containers. We'll talk about the command and   port fields shown in this output later in this  course. For now let's just focus on the basic   commands. To stop a running container use the  Docker stop command, but you must provide either  

the container ID or the container name in the  stop command. If you're not sure of the name,   run the docker ps command to get it on success.  You will see the name printed out and running   docker ps again will show no running containers.  Running docker ps dash a, however shows the  

container silly summit and that it is now an exit  state a few seconds ago. Now what if we don't   want this container lying around consuming space?  What if we want to get rid of it for good? Use the   Docker rm command to remove a stopped or exited  container permanently. If it prints the name back,  

we're good. Run the docker ps command again to  verify that it's no longer present. Good. But   what about the nginx image that was downloaded? At  first? We're not using that anymore. So how do we   get rid of that image? But first, how do we see a  list of images present on our host run the Docker  

images command to see a list of available images  and their sizes. On our host we have four images   nginx Redis, Ubuntu and Alpine. We will talk about  tags later in this course when we discuss about   images. To remove an image that you no longer  plan to use. Run the Docker Rmi command. Remember,  

you must ensure that no containers are running  off of that image before attempting to remove   the image. You must stop and delete all dependent  containers to be able to delete an image. When we   ran the Docker run command earlier, it downloaded  the Ubuntu image as it couldn't find one locally.  

What if we simply want to download the image and  keep so when we run the run Docker run command,   we don't want to wait for it to download. Use the  Docker pull command to only pull the image and   not run the container. So in this case, the  Docker pull Ubuntu command pulls the Ubuntu  

image and stores it on our host. Let's look at  another example. Say you were to run a Docker   container from an Ubuntu image. When you run the  Docker run Ubuntu command it runs an instance of   Ubuntu image and exits immediately. If you were to  list the running containers, you wouldn't see the  

container running. If you list all containers,  including those that are stopped, you will see   that the new container you ran is in an exit  state. Now why is that? Unlike virtual machine   containers are not meant to host an operating  system. Containers are meant to run a specific  

task or process such as to host an instance of a  web server or application server or a database,   or simply to carry some kind of computation  or analysis task. Once the task is complete,   the container exits a container only lives as  long as the process inside it is alive. If the  

web service inside the container is stopped, or  crash, then the container exits. This is why when   you run a container from an Ubuntu image, it  stops immediately. Because Ubuntu is just an   image of an operating system that is used as the  base image. For other applications. There is no  

process or application running in it by default.  If the image isn't running any service, as is   the case with Ubuntu, you could instruct Docker  to run a process with the Docker run command.   For example, a sleep command with a duration  of five seconds. When the container starts,  

it runs the sleep command and goes into sleep for  five seconds post with the sleep command exit,   and the container stops. What we just saw was  executing a command when we run the container,   but what if we would like to execute a command  on a running container. For example, when I run  

the docker ps command, I can see that there is  a running container which uses the Ubuntu image   and sleeps 400 seconds. Let's say I would like to  see the contents of a file inside this particular   container. I could use the Docker exec command to  execute a command on my Docker container, in this  

case to print the contents of the Etsy hosts file.  Finally, let's look at one more option before we   head over to the practice exercises. I'm now going  to run a Docker image I developed for a simple web   application. The repository name is cloud slash  simple web app. It runs a simple web server that  

listens on port 8080. When you run a Docker run  command like this, it runs in the foreground or   in an attached mode, meaning you will be attached  to the console or the standard out of the Docker   container. And you will see the output of the  web service on your screen. You won't be able  

to do anything else on this console other than  view the output until this Docker container   stops. It won't respond to your inputs. press the  ctrl plus c combination to stop the container and   the application hosted on the container exits and  you get back to your prompt. Another option is to  

run the Docker container in the detached mode  by providing the dash D option. This will run   the Docker container in the background mode, and  you will be back to your prompt immediately. The   container will continue to run in the backend,  run the docker ps command to view the running  

container. Now if you would like to attach back to  the running container later, run the Docker attach   command and specify the name or ID of the Docker  container. Now remember, if you're specifying the   ID of a container in any Docker command, you can  simply provide the first few characters alone,  

just so it is different from the other container  IDs on the host. In this case, I specify a 043 D.   Now don't worry about accessing the UI of the web  server for now. We will look more into that in the   upcoming lectures. For now let's just understand  the basic commands will now get our hands dirty  

with the Docker COI. So let's take a look at how  to access the practice lab environments. Next.   Let me now walk you through the hands on lab  practice environment. The links to access the labs   associated with this course are available at code  cloud at code cloud.com slash p slash Docker dash  

labs. This link is also given in the description  of this video. Once you're on this page, use the   links given there to access the labs associated  to your lecture. Each lecture has its own lab. So   remember to choose the right lab for your lecture.  The labs open up right in your browser, I would  

recommend to use Google Chrome while working with  the labs. The interface consists of two parts,   a terminal on the left and a quiz portal on the  right. The quiz portal on the right gives you   challenges to solve. Follow the quiz and try and  answer the questions asked and complete the tasks  

given to you. Each scenario consists of anywhere  from 10 to 20 questions that need to be answered.   Within 30 minutes to an hour. At the top, you have  the question numbers below that is the remaining   time for your lab below that is the question.  If you are not able to solve the challenge,  

look for hints in the head section, you may skip  a question by hitting the skip button in the top   right corner. But remember that you will not be  able to go back to a previous question once you   have skipped. If the quiz portal gets stuck for  some reason, click on the quiz portal tab at the  

top to open the quiz portal in a separate window.  The terminal gives you access to a real system   running Docker, you can run any Docker command  here and run your own containers or applications.   You will typically be running commands to solve  the task assigned in the quiz portal. You may play  

around and experiment with this environment. But  make sure you do that after you've gone through   the quiz so that your work does not interfere with  the tasks provided by the quiz. So let me walk you   through a few questions. There are two types of  questions. Each lab scenario starts with a set of  

exploratory multiple choice questions where you're  asked to explore and find information in the given   environment and select the right answer. This is  to get you familiarized with the setup. You're   then asked to perform tasks like run a container,  stop them, delete them, build your own image,  

etc. Here, the first question asks us to find  the version of Docker server engine running on   the host. Run the Docker version command in  the terminal and identify the right version.   Then select the appropriate option from the given  choices. Another example is the fourth question  

where it asks you to run a container using the  Redis image. If you're not sure of the command,   click on hence and it will show you a hint. We  now run a Redis container using the Docker run   Redis command, wait for the container to run. Once  done, click on Check to check your work. You have  

now successfully completed the task. Similarly,  follow along and complete all tasks. Once the   lab exercise is completed. Remember to leave a  feedback and let us know how it went. A few things   to note. These are publicly accessible labs that  anyone can access. So if you catch yourself logged  

out during a peak hour, please wait for some time  and try again. Also remember to not store any   private or confidential data on these systems.  Remember that this environment is for learning   purposes only and is only alive for an hour, after  which the lab is destroyed. So does all your work.  

But you may start over and access these labs as  many times as you want. until you feel confident.   I will also post solutions to these lab quizzes.  So if you run into issues, you may refer to   those. That's it for now, head over to the first  challenge. And I will see you on the other side.  

We will now look at some of the other Docker run  commands. At the end of this lecture, you will go   through a hands on quiz where you will practice  working with these commands. We learned that we   could use the Docker run Redis command to run a  container running a Redis service, in this case,  

the latest version of Redis, which happens to be  5.0 dot five as of today. But what if we want to   run another version of Redis like for example,  an older version, say 4.0. Then you specify the   version separated by a colon. This is called a  tag. In that case, Docker pulls an image of the  

photo zero version of Redis and runs that. Also,  notice that if you don't specify any tag as in the   first command, Docker will consider the default  tag to be latest. Latest is a tag associated   to the latest version of that software, which  is governed by the authors of their software.  

So as a user, how do you find information about  these versions and what is the latest? At Docker   hub.com look up an image and you will find all the  support tags in its description. Each version of   the software can have multiple short and long tags  associated with it, as seen here. In this case,  

the version 5.0 dot five also has the latest tag  on it. Let's now look at inputs. I have a simple   prompt application that when run asked for my name  and on entering my name prints a welcome message   if If I were to Docker eyes this application  and run it as a Docker container like this,  

it wouldn't wait for the prompt. It just prints  whatever the application is supposed to bring on   standard out. That is because by default, the  Docker container does not listen to a standard   input. Even though you're attached to its console,  it is not able to read any input from you. It  

doesn't have a terminal to read inputs from it  runs in a non interactive mode. If you'd like   to provide your input, you must map the standard  input of your host to the Docker container using   the dash I parameter. The dash I parameter is  for interactive mode. And when I input my name,  

it prints the expected output. But there is  something still missing from this, the prompt   when we run the app, at first, it asked us for our  name. But when dockerized that prompt is missing,   even though it seems to have accepted my input.  That is because the application prompt on the  

terminal and we have not attest to the containers  terminal. For this use the dash t option as well.   The dash T stands for a pseudo terminal. So with  the combination of dash IMT. We're now attached   to the terminal, as well as in an interactive mode  on the container. We will now look at Port mapping  

or port publishing on containers. Let's go back to  the example where we run a simple web application   in a Docker container on my Docker host. Remember  the underlying host where Docker is installed is   called Docker host or Docker engine. When we run  a containerized web application it runs and we're  

able to see that the server is running. But how  does the user access my application. As you can   see, my application is listening on port 5000. So  I could access my application by using Port 5000.   But what IP do I use to access it from a web  browser. There are two options available. One  

is to use the IP of the Docker container. Every  Docker container gets an IP assigned by default,   in this case it is 172 dot 17 dot 0.2. Remember  that this is an internal IP and is only accessible   within the Docker host. So if you open a browser  from within the Docker host, you can go to HTTP,  

colon forward slash forward slash 172 dot 17 dot  0.1 colon 5000 to access the IP address. But since   this is an internal IP users outside of the Docker  host cannot access it using this IP. For this,   we could use the IP of the Docker host, which  is 190 2.1 68 dot five. But for that to work,  

you must have mapped the port inside the Docker  container to a free port on the Docker host.   For example, if I want the users to access my  application through Port 80, on my Docker host,   I could map Port 80 of local host to Port 5000 on  the Docker container using the dash p parameter  

in my run command like this. And so the user can  access my application by going to the URL HTTP,   colon slash slash 190 2.1 68 dot 1.5 colon 80. And  all traffic on port 80 on my Docker host, will get   routed to Port 5000 inside the Docker container.  This way you can run multiple instances of your  

application and map them to different ports on  the Docker host or run instances of different   applications on different ports. For example, in  this case, I'm running an instance of MySQL that   runs a database on my host and listens on the  default MySQL port, which happens to be 3306,  

or another instance of MySQL on another port 8306.  So you can run as many applications like this,   and map them to as many ports as you want. And  of course, you cannot map to the same port on the   Docker host more than once. We will discuss more  about port mapping and networking of containers  

in the network lecture later on. Let's now look  at how data is persisted in a Docker container.   For example, let's say you were to run a MySQL  container. When databases and tables are created,   the data files are stored in location slash four  lib MySQL inside the Docker container. Remember,  

the Docker container has its own isolated file  system and any changes to any files happen within   the kernel. tainer let's assume you dump a lot  of data into the database. What happens if you   were to delete the MySQL container and remove  it. As soon as you do that, the container along  

with all the data inside it gets blown away,  meaning all your data is gone. If you would   like to persist data, you would want to map a  directory outside the container on the Docker   host to a directory inside the container. In this  case, I create a directory called slash OBT slash  

data dir and map that to var lib MySQL inside  the Docker container using the dash v option,   and specifying the directory on the Docker host,  followed by a colon and the directory inside the   Docker container. This way when Docker container  runs, it will implicitly mount the external  

directory to a folder inside the Docker container.  This way all your data will now be stored in the   external volume at slash RPT slash data directory.  And this will remain even if you delete the Docker   container. The docker ps command is good enough  to get basic details about containers like  

their names and IDs. But if you'd like to see  additional details about a specific container,   use the Docker inspect command and provide the  container name or ID. It returns all details   of a container in a JSON format, such as the state  mounts, configuration data, network settings, etc.  

Remember to use it when you're required to find  details on a container. And finally, how do we see   the logs of a container we run in the background.  For example, I ran my simple web application using   the dash D parameter and it ran the container  in a detached mode. How do I view the logs  

which happens to be the contents written to the  standard out of that container. Use the Docker   logs command and specify the container ID or  name like this. Well, that's it for this lecture,   how to work with the challenges and practice  working with Docker commands. Let's start with  

a simple web application written in Python. This  piece of code is used to create a web application   that displays a web page with a background color.  If you look closely into the application code,   you will see a line that sets the background  color to red. Now, that works just fine. However,  

if you decide to change the color in the future,  you will have to change the application code. It   is a best practice to move such information out of  the application code and into say an environment   variable called app color. The next time you run  the application set an environment variable called  

add color to a desired value. And the application  now has a new color. Once your application gets   packaged into a Docker image, you will then  run it with the Docker run command followed   by the name of the image. However, if you wish to  pass the environment variable as he did before,  

he would now use the Docker run commands dash  e option to set an environment variable within   the container. To deploy multiple containers with  different colors. He would run the Docker command   multiple times and set a different value for the  environment variable each time. So how do you find  

the environment variable set on a container that's  already running? Use the Docker inspect command to   inspect the properties of a running container.  Under the config section, you will find the list   of Environment Variables set on the container.  Well that's it for this lecture on configuring  

environment variables in Docker. Hello, and  welcome to this lecture on Docker images. In this   lecture, we're going to see how to create your  own image. Now before that, why would you need to   create your own image? It could either be because  you cannot find a component or a service that you  

want to use as part of your application on Docker  Hub already, or you and your team decided that the   application you're developing will be dockerized  for ease of shipping and deployment. In this case,   I'm going to containerize an application a simple  web application that I have built using the Python  

flask framework. First we need to understand  what we are containerizing or what application   we are creating an image for How the application  is built. So start by thinking what you might do.   If you want to deploy the application manually,  we write down the steps required in the right  

order. I'm creating an image for a simple web  application. If I were to set it up manually,   I would start with an operating system like  Ubuntu, then update the source repositories using   the abt command, then install dependencies using  the abt command, then install Python dependencies  

using the PIP command, then copy over the source  code of my application to a location like RPT   and then finally, run the web server using the  floss command. Now that I have the instructions,   create a Docker file using this. Here's a  quick overview of the process of creating  

your own image. First, create a Docker file named  Docker file and write down the instructions for   setting up your application in it, such as  installing dependencies, where to copy the   source code from and to and what the entry  point of the application is, etc. Once done,  

build your image using the Docker build command  and specify the Docker file as input as well   as a tag name for the image. This will create an  image locally on your system. To make it available   on the public Docker Hub registry, run the Docker  push command and specify the name of the image you  

just created. In this case, the name of the image  is my account name which is mm shot, followed by   the image name, which is my custom app. Now  let's take a closer look at that Docker file.   Docker file is a text file written in a specific  format that Docker can understand. It's in an  

instruction and arguments format. For example,  in this Docker file, everything on the left in   caps is an instruction. In this case from run,  copy and entry point are all instructions. Each   of these instruct Docker to perform a specific  action while creating the image. Everything on the  

right is an argument to those instructions. The  first line from Ubuntu defines what the base OS   should be for this container. Every Docker image  must be based off of another image, either an OS   or another image that was created before based  on an OS, you can find official releases of all  

operating systems on Docker Hub. It's important  to note that all Docker files must start with the   from instruction. The run instruction instructs  Docker to run a particular command on those base   images. So at this point, Docker runs the abt get  update commands to fetch the updated packages,  

and installs required dependencies on the image.  Then the copy instruction copies files from the   local system onto the Docker image. In this  case, the source code of our application is in   the current folder, and I'll be copying it over  to the location property source code inside the  

Docker image. And finally, entry point allows  us to specify a command that will be run when   the image is run as a container. When Docker  builds the images, it builds these in a layered   architecture. Each line of instruction creates  a new layer in the Docker image with just the  

changes from the previous layer. For example, the  first layer is a base Ubuntu OS, followed by the   second instruction that creates a second layer  which installs all the IPT packages. And then   the third instruction creates a third layer with  a Python packages followed by the fourth layer  

that copies the source code over and the final  layer that updates the entry point of the image.   Since each layer only stores the changes from  the previous layer, it is reflected in the size   as well. If you look at the base Ubuntu image, it  is around 120 MB in size. The IPT packages that  

are installed is around 300 Mb and the remaining  layers are small. You can see this information if   you run the Docker history command followed by the  image name. When you run the Docker build command,   you can see the various steps involved and the  result of each task. All the layers built are  

cast. So the layered architecture helps you  restart Docker build from that particular step   in case it fails. Or if you were to add new steps  in the build process, you wouldn't have to start   all over again. All the layers built out cached by  Docker. So in case a particular step was to fail,  

for example, in this case, step three failed, and  you were to fix the issue and rerun Docker build,   it will reuse the previous layers from  cache and continue to build the remaining   layers. The same is true if you were to add  additional steps in the Docker file. This way,  

rebuilding your image is faster. And you don't  have to wait for Docker to rebuild the entire   image each time. This is helpful, especially when  you update source code of your application. As it   may change more frequently, only the layers above  the updated layers needs to be rebuilt. We just  

saw a number of products containerized such as  databases, development tools, operating systems,   etc. But that's just not it. You can containerize  almost all of the application even simple ones,   like browsers or utilities, like curl  applications like Spotify, Skype,  

etc. Basically, you can containerize everything  and going forward and see that's how everyone   is going to run applications. Nobody is going to  install anything anymore going forward. Instead,   they're just going to run it using Docker. And  when they don't need it anymore, get rid of it  

easily without having to clean up too much. In  this lecture, we will look at commands arguments   and entry points in Docker. Let's start with a  simple scenario. Say you were to run a Docker   container from an Ubuntu image. When you run the  Docker run Ubuntu command it runs an instance of  

Ubuntu image and exits immediately. If you were to  list the running containers, you wouldn't see the   container running. If you list all containers,  including those that are stopped, you will see   that the new container you ran is in an exited  state. Now why is that? Unlike virtual machines,  

containers are not meant to host an operating  system. Containers are meant to run a specific   task or process, such as to host an instance of a  web server or application server or a database or   simply to carry out some kind of computation  or analysis. Once the task is complete, the  

container exits a container only lives as long as  the process inside ID is alive. If the web service   inside the container is stopped or crashes, the  container exits. So who defines what process   is run within the container. If you look at the  Docker file for popular Docker images like ngi Nx,  

you will see an instruction called CMD, which  stands for command that defines the program that   will be run within the container when it starts.  For the ngi nx image. It is the ngi nx command for   the MySQL image. It is the MySQL D command. What  we tried to do earlier was to run a container with  

a plain Ubuntu Operating System. Let us look at  the Docker file for this image. You will see that   it uses bash as the default command. Now bash is  not really a process like a web server or database   server. It is a shell that listens for inputs  from a terminal. If it cannot find the terminal it  

exits. When we ran the Ubuntu container earlier,  Docker created a container from the Ubuntu image   and launch the bash program. By default, Docker  does not attach a terminal to a container when   it is run. And so the bash program does not find  the terminal. And so it exits. Since the process  

that was started when the container was created,  finished the container exits as well. So how   do you specify a different command to start the  container? One option is to append a command to   the Docker run command. And that way it overrides  the default command specified within the image.  

In this case, I run the Docker run Ubuntu command  with the sleep five command as the added option.   This way when the container starts, it runs the  sleep program waits for five seconds and then   exits. But how do you make that change permanent?  Say you want the image to always run the sleep  

command when it starts. You will then create  your own image from the base Ubuntu image and   specify a new command. There are different ways of  specifying the command either the command simply   as a In a shell form, or in a JSON array format  like this, but remember, when you specify in a  

JSON array format, the first element in the array  should be the executable. In this case, the sleep   program did not specify the command and parameters  together like this, the command and its parameters   should be separate elements in the list. So I now  build my new image using the Docker build command,  

and name it as a boon to sleeper. I could now  simply run the Docker boon to sleeper command and   get the same results. It always sleeps for five  seconds and exits. But what if I wish to change   the number of seconds it sleeps? Currently, it is  hard coded to five seconds. As we learned before,  

One option is to run the Docker run command with  the new command appended to it, in this case,   sleep 10. And so the command that will be run  at startup will be sleep 10. But it doesn't look   very good. The name of the image, Ubuntu sleeper  in itself implies that the container will sleep,  

so we shouldn't have to specify the sleep command  again. Instead, we would like it to be something   like this Docker run Ubuntu sleeper 10, we  only want to pass in the number of seconds the   container should sleep and sleep command should  be invoked automatically. And that is where the  

entry point instruction comes into play. The entry  point instruction is like the command instruction.   As in, you can specify the program that will be  run when the container starts. And whatever you   specify on the command line, in this case, 10  will get appended to the entry point. So the  

command that will be run when the container starts  is sleep 10. So that's the difference between the   two. In case of the CMD instruction, the command  line parameters passed will get replaced entirely.   Whereas in case of entry point, the command line  parameters will get appended. Now, in the second  

case, what if I run the open to sleeper image  command without appending the number of seconds,   then the command at startup will be just sleep and  you get the error that the opposite is missing.   So how do you configure a default value for the  command if one was not specified in the command  

line, that's where you would use both entry point  as well as the command instruction. In this case,   the command instruction will be appended to  the entry point instruction. So at startup, the   command would be sleep five, if you didn't specify  any parameters in the command line. If you did,  

then that will override the command instruction.  And remember for this to happen, you should always   specify the entry point and command instructions  in a JSON format. Finally, what if you really   really want to modify the entry point during  runtime, say from sleep to an imaginary sleep 2.0  

command? Well, in that case, you can override it  by using the entry point option in the Docker run   command. The final command at startup would then  be sleep 2.0 10. Well, that's it for this lecture,   and I will see you in the next. We now look at  networking in Docker. When you install Docker,  

it creates three networks automatically. Bridge  no and host bridge is the default network a   container gets attached to if you would like to  associate the container with any other network,   specify the network information using the network  command line parameter like this. We will now look  

at each of these networks. The bridge network is  a private internal network created by Docker on   the host all containers attached to this network  by default, and they get an internal IP address,   usually in the range 172 dot 17 series. The  containers can access each other using this  

internal IP if required. To access any of these  containers from the outside world, map the ports   of these containers to port on the Docker host,  as we have seen before. Another way to access   the containers externally is to associate the  container to the host network. This takes out  

any network isolation between the Docker host and  the Docker container. Meaning if you were to run   a web server on port 5000. In a web app container,  it is automatically as accessible on the same port   externally without requiring any port mapping  as the web container uses the hosts network.  

This will also mean that unlike before, you will  now not be able to run multiple web containers on   the same host on the same port, as the ports  are now common to all containers in the host   network. With the non network, the containers  are not attached to any network and doesn't  

have any access to the external network, or other  containers. They run in an isolated network. So   we just saw the default burst network where the  network ID 172 dot 70 dot 0.1. So all containers   associated to this default network will be able to  communicate to each other. But what if we wish to  

isolate the containers within the Docker host, for  example, the first two web containers on internal   network 172 and the second two containers on a  different internal network, like 182. By default,   Docker only creates one internal bridge network,  we could create our own internal network using  

the command Docker network, create and specify  the driver which is bridge in this case, and the   subnet for that network followed by the custom  isolated network name. Run the Docker network ls   command to list all networks. So how do we see the  network settings and the IP address assigned to an  

existing container? Run the Docker inspect command  with the ID or name of the container, and you will   find a section on network settings. There you can  see the type of network the container is attached   to its internal IP address, MAC address, and other  settings. Containers can reach each other using  

their names. For example, in this case, I have a  web server and a MySQL database container running   on the same node. How can I get my web server to  access the database on the database container. One   thing I could do is to use the internal IP address  signed to the MySQL container, which in this case  

is 172 dot 70 dot 0.3. But that is not very ideal  because it is not guaranteed that the container   will get the same IP when the system reboots. The  right way to do it is to use the container name.   All containers in a Docker host can resolve each  other with the name of the container. Docker has  

a built in DNS server that helps the containers  to resolve each other using the container name.   Note that the built in DNS server always runs at  address 127 dot 0.0 dot 11. So how does Docker   implement networking? What's the technology behind  it? Like how are the containers isolated within  

the host? Docker uses network namespaces that  creates a separate namespace for each container.   It then uses virtual Ethernet pairs to connect  containers together. Well, that's all we can talk   about it for now. More about these are advanced  concepts that we discussed in the advanced course  

on Docker on code cloud. That's all for now.  From this lecture on networking, head over to the   practice test and practice working with networking  in Docker. I will see you in the next lecture.   Hello and welcome to this lecture and we are  learning advanced Docker concepts. In this  

lecture we're going to talk about Docker storage  drivers and file systems. We're going to see where   and how Docker stores data and how it manages  file systems of the containers. Let us start with   how Docker stores data on the local file system.  When you install Docker on a system, it creates  

this folder structure at var lib Docker. You have  multiple folders under it called au Fs containers,   image volumes, etc. This is where Docker stores  all its data by default. When I say data, I mean   files related to images and containers running on  the Docker host. For example, all files related to  

containers are stored under the containers folder.  And the files related to images are stored under   the image folder. Any volumes created by the  Docker containers. I created under the volumes   folder. Well, don't worry about that for now. We  will come back to that in a bit. For now, let's  

just understand where Docker stores its files,  and in what format. So how exactly does Docker   store the files of an image and a container?  To understand that we need to understand   Dockers layered architecture. Let's quickly recap  something we learned when Docker builds images,  

it builds these in a layered architecture. Each  line of instruction in the Docker file creates   a new layer in the Docker image with just the  changes from the previous layer. For example,   the first layer is a base Ubuntu Operating System,  followed by the second instruction that creates a  

second layer, which installs all the Add packages.  And then the third instruction creates a third   layer, which with the Python packages, followed  by the fourth layer that copies the source code   over and then finally the fifth layer that  updates the entry point of the image. Since  

each layer only stores the changes from the  previous layer, it is reflected in the size as   well. If you look at the base, a boon to image it  is around 120 megabytes in size. The abt packages   that are installed is around 300 Mb, and then  the remaining layers are small. To understand  

the advantages of this layered architecture, let's  consider a second application. This application   has a different Docker file. But it's very similar  to our first application, as it uses the same base   image as Ubuntu uses the same Python and flask  dependencies, but uses a different source code  

to create a different application. And so  a different entry point as well. When I run   the Docker build command to build a new image for  this application, since the first three layers of   both the applications are the same, Docker is not  going to build the first three layers. Instead,  

it reuses the same three layers it built  for the first application from the cache,   and only creates the last two layers with the  new sources and the new entry point. This way,   Docker builds images faster and efficiently saves  disk space. This is also applicable if you were to  

update your application code. Whenever you update  your application code, such as the app dot p y. In   this case, Docker simply reuses all the previous  layers from cash, and quickly rebuilds the   application image by updating the latest source  code, thus saving us a lot of time during rebuilds  

and updates. Let's rearrange the layers bottom up  so we can understand it better. At the bottom we   have the base Ubuntu layer, then the packages,  then the dependencies, and then the source code   of the application, and then the entry point. All  of these layers are created when we run the Docker  

build command to form the final Docker image. So  all of these are the Docker image layers. Once the   build is complete, you cannot modify the contents  of these layers and so they are read only and you   can only modify them by initiating a new build.  When you run a container based off of this image  

using the Docker run command, Docker creates a  container based off of these layers and creates   a new writable layer on top of the image layer.  The writable layer is used to store data created   by the container, such as log files written by the  applications, any temporary files generated by the  

container, or just any file modified by the user  on that container. The life of this layer though,   is only as long as the container is alive. When  the container is destroyed. This layer and all   of the changes stored in it are also destroyed.  Remember that the same image layer is shared by  

all containers created using this image. If I were  to log into the newly created container and say,   create a new file called temp dot txt, it will  create that file in the container layer which is   read and write. We just said that the files in the  image layer are read only meaning you cannot edit  

anything in those layers. Let's take an example of  our application code. Since we bake our code into   the image, the code is part of the image layer  and as such is read only after running a container   What if I wish to modify the source code to say  test to change. Remember, the same image layer may  

be shared between multiple containers created from  this image. So does it mean that I cannot modify   this file inside the container. Now, I can still  modify this file. But before I save the modified   file, Docker automatically creates a copy of the  file in the readwrite layer, and I will then be  

modifying a different version of the file in the  readwrite layer. All future modifications will   be done on this copy of the file in the readwrite  layer. This is called copy on write mechanism. The   image layer being read only just means that the  files in these layers will not be modified in the  

image itself. So the image will remain the same  all the time, until you rebuild the image using   the Docker build command. What happens when we  get rid of the container, all of the data that was   stored in the container layer also gets deleted,  the changes we made to the app.pi and the new temp  

file we created will also get removed. So what if  we wish to persist this data? For example, if we   were working with a database, and we would like  to preserve the data created by the container,   we could add a persistent volume to the container.  To do this, first create a volume using the Docker  

volume create command. So when I run the Docker  volume create data underscore volume command,   it creates a folder called Data underscore volume  under the var lib Docker volumes directory. Then   when I run the Docker container using the Docker  run command, I could mount this volume inside  

the Docker containers rewrite layer using the  dash v option like this. So I would do a Docker   run dash v then specify my newly created volume  name followed by a colon and the location inside   my container, which is the default location  where MySQL stores data and that is where lib  

MySQL and then the image name MySQL. This will  create a new container and mount the data volume   we created into var lib MySQL folder inside the  container. So all data written by the database   is in fact stored on the volume created on the  Docker host. Even if the container is destroyed,  

the data is still active. Now what if you didn't  run the Docker volume create command to create the   volume before the Docker run command. For example,  if I run the Docker run command to create a new   instance of MySQL container with the volume data  underscore Volume Two, which I have not created  

yet, Docker will automatically create a volume  named data underscore Volume Two and mounted   to the container. You should be able to see all  these volumes if you list the contents of the var   lib Docker volumes folder. This is called volume  mounting. As we are mounting a volume created by  

Docker under the var lib Docker volumes folder.  But what if we had our data already at another   location for example, let's say we have some  external storage on the Docker host at four   slash data. And we would like to store database  data on that volume and not in the default var lib  

Docker volumes folder. In that case, we will run  a container using the command Docker run dash v.   But in this case, we will provide the complete  path to the folder we would like to mount that   is for slash data forward slash MySQL and so it  will create a container and mount the folder to  

the container. This is called bind mounting. So  there are two types of mounts a volume mounting   and a bind mount volume mount mount a volume  from the volumes directory and bind mount mounts   a directory from any location on the Docker host.  One final point note before I let you go using the  

dash V is an old style. The new way is to use dash  mount option. The dash dash mount is the preferred   way as it is more verbose. So you have to specify  each parameter in a key equals value format. For   example, the previous command can be written with  the dash mount option as this using the type,  

source and target options. The type in this  case is bind. The source is the location on my   host and target is the location on my container.  So who He's responsible for doing all of these   operations, maintaining the layered architecture,  creating a writable layer moving files across  

layers to enable, copy and write etc. It's the  storage drivers. So Docker uses storage drivers   to enable layered architecture. Some of the common  storage drivers are au Fs btrfs DFS device mapper   Overlay and overlay to the selection of the  storage driver depends on the underlying OS  

being used, for example, with a boon to the  default storage driver is au Fs whereas this   storage driver is not available on other operating  systems like Fedora or CentOS. In that case,   device mapper may be a better option. Docker  will choose the best storage driver available  

automatically based on the operating system. The  different storage drivers also provide different   performance and stability characteristics. So you  may want to choose one that fits the needs of your   application, and your organization. If you would  like to read more on any of these stories drivers,  

please refer to the links in the  attached documentation. For now,   that is all from the Docker architecture concepts.  See you in the next lecture. Hello, and welcome to   this lecture on Docker compose. Going forward, we  will be working with configurations in yamo file,  

so it is important that you are comfortable with  tmo. Let's recap a few things real quick course we   first learned how to run a Docker container using  the Docker run command. If we needed to set up a   complex application running multiple services, a  better way to do it is to use Docker compose with  

Docker compose, we could create a configuration  file in yamo format called Docker compose dot yamo   and put together the different services and the  options specific to this to running them in this   file. Then we could simply run a Docker compose  up command to bring up the entire application  

stack is easier to implement, run and maintain  as all changes are always stored in the Docker   compose configuration file. However, this is all  only applicable to running containers on a single   Docker host. And for now, don't worry about the  yamo file, we will take a closer look at the yamo  

file in a bit and see how to put it together.  That was a really simple application that I   put together. Let us look at a better example.  I'm going to use the same sample application   that everyone uses to demonstrate Docker. It's  a simple yet comprehensive application developed  

by Docker to demonstrate the various features  available in running an application stack on   Docker. So let's first get familiarized with the  application, because we will be working with the   same application in different sections through  the rest of this course. This is a sample voting  

application which provides an interface for a user  to vote and another interface to show the results.   The application consists of various components  such as the voting app, which is a web application   developed in Python, to provide the user with  an interface to choose between two options,  

a cat and the dog. When you make a selection,  the vote is stored in Redis. For those of you   who are new to Redis Redis, in this case serves as  a database in memory. This vote is then processed   by the worker which is an application written in  dotnet. The worker application takes the new vote  

and updates the persistent database, which is  a Postgres SQL, in our case, the Postgres SQL   simply has a table with a number of votes for  each category, cats and dogs. In this case,   it increments the number of votes for cats as  our vote was for cats. Finally, the result of  

the vote is displayed in a web interface, which is  another web application developed in Node JS. This   resulting application rates the count of votes  from the Postgres SQL database and displays it   to the user. So that is the architecture and  data flow of this simple voting application  

stack. As you can see, this sample application is  built with a combination of different services,   different development tools, and multiple  different development platforms. So As Python,   no js, dotnet, etc. This sample application will  be used to showcase how easy it is to set up an  

entire application stack consisting of diverse  components in Docker. Let us keep aside Docker   swarm services and stacks for a minute and see  how we can put together this application stack   on a single Docker engine using first Docker run  commands, and then Docker compose. Let us assume  

that all images of applications are already  built and are available on Docker repository.   Let's start with the data layer. First, we run  the Docker run command to start an instance of   Redis. By running the Docker run Redis command,  we will add the dash D parameter to run this  

container in the background. And we will also name  the container Redis. Now naming the containers is   important. Why is that important? Hold that  thought we will come to that in a bit. Next,   we will deploy the Postgres SQL database by  running the Docker run Postgres command. This  

time too, we will add the dash D option to run  this in the background and name this container   DB for database. Next, we will start with the  application services. We will deploy a front end   app for voting interface by running an instance  of voting app image, run the Docker run command  

and name the instance vote. Since this is a web  server, it has a web UI instance running on port   80. We will publish that port to 5000 on the host  system, so we can access it from a browser. Next,   we will deploy the result web application  that shows the results to the user. For this  

we deploy a container using the results stash  app image and publish Port 80 to Port 5001 on   the host. This way, we can access the web UI  of the resulting app on a browser. Finally,   we deploy the worker by running an instance of  the worker image. Okay, now this is all good. And  

we can see that all the instances are running on  the host. But there is some problem, it just does   not seem to work. The problem is that we have  successfully run all the different containers,   but we haven't actually linked them together. As  in we haven't told the voting web application to  

use this particular Redis instance, there could  be multiple Redis instances running. We haven't   told the worker and the resulting app to use this  particular Postgres SQL database that we ran. So   how do we do that? That is where we use links.  Link is a command line option, which can be used  

to link two containers together. For example, the  voting app web service is dependent on the Redis   service. When the web server starts, as you can  see, in this piece of code on the web server, it   looks for a Redis service running on host Redis.  But the voting app container cannot resolve a host  

by the name Redis. To make the voting app aware  of the Redis service, we add a link option while   running the voting app container to link it to the  Redis container, adding a dash dash link option to   the Docker run command and specifying the name  of the Redis container which is which in this  

case is Redis followed by a colon and the name  of the host that the voting app is looking for,   which is also Redis. In this case, remember that  this is why we named the container when we ran   it the first time so we could use its name while  creating a link. What this is, in fact doing is  

it creates an entry into the EDC host file on  the voting app container, adding an entry with   the host name Redis with the internal IP of the  Redis container. Similarly, we add a link for   the result app to communicate with the database by  adding a link option to refer the database by the  

name dB. As you can see, in this source code of  the application, it makes an attempt to connect   to a Postgres database on host dB. Finally, the  worker application requires access to both the   Redis as well as the Postgres database. So we  add two links to the worker application, one  

link to link the Redis and the other link to link  Postgres database. Note that using links this way,   is deprecated and the support may be removed in  future in Docker. This is because as we will see   in some time Advanced and newer concepts in  Docker swarm and networking supports better  

ways of achieving what we just did here with  links. But I wanted to mention it anyways, so   you learn the concept from the very basics. Once  we have the Docker run commands tested and ready,   it is easy to generate a Docker compose file from  it. We start by creating a dictionary of container  

names, we will use the same name we used in the  Docker run commands. So we take all the names and   create a key with each of them. Then under each  item, we specify which image to use. The key is   the image and the value is the name of the image  to use. Next, inspect the commands and see what  

are the other options used. We published ports.  So let's move those ports under the respective   containers. So we create a property called ports  and list all the ports that you would like to   publish under that. Finally, we are left with  links. So whichever container requires the link,  

create a property under it called links and  provide an array of links such as Redis, or TP.   Note that you could also specify the name of the  link this way without the semicolon and and the   target target name, and it will create a link with  the same name as the target name. specifying the  

DB colon DB is similar to simply specifying dB,  we will assume the same value to create a link.   Now that we're all done with our Docker compose  file, bringing up the stack is really simple from   the Docker compose up command to bring up the  entire application stack. When we looked at the  

example of the sample voting application, we  assumed that all images are already built out   of the five different components. Two of them  Redis and Postgres images we know are already   available on Docker Hub. There are official images  from Redis and Postgres. But the remaining three  

are our own application, it is not necessary  that they are already built and available in   the Docker registry. If we would like to instruct  Docker compose to run a Docker build, instead of   trying to pull an image, we can replace the image  line with a built line and specify the location  

of a directory, which contains the application  code, and a Docker file with instructions to   build the Docker image. In this example, for the  voting app, I have all the application code in a   folder named vote which contains all application  code, and a Docker file. This time when you run  

the Docker compose up command, it will first  build the images, give a temporary name for it,   and then use those images to run containers using  the options you specified before. Similarly use   build option to build the two other services  from the respective folders. We will now look  

at different versions of Docker compose file. This  is important because you might see Docker compose   files in different formats at different places  and wonder why some look different. Docker compose   evolved over time, and now supports a lot more  options than it did in the beginning. For example,  

this is the trimmed down version of the Docker  compose file we used earlier. This is in fact,   the original version of Docker compose file known  as version one. This had a number of limitations.   For example, if you wanted to deploy containers on  a different network other than the default bridge  

network, there was no way of specifying  that in this version of the file. Also,   say you have a dependency or startup order of some  kind. For example, your database container must   come up first and only then I should the voting  application be started. There was no way you could  

specify that in the version one of the Docker  compose file support for these came in version   two. With version two and up, the format of the  file also changed a little bit. You no longer   specify your stack information directly as you  did before. It is all encapsulated in Services  

section. So create a property called services  in the root of the file, and then move all the   services underneath that. You will still use the  same Docker compose up command to bring up your   application stack. But how does Docker compose  know what version of the file you're using? You're  

free to use version one or version two depending  on your needs. So how does the Docker compose,   know what format you're using. For version two  and up, you must specify the version of Docker   compose file you're intending to use by specifying  the version at the top of the file. In this case,  

version, colon two. Another difference is with  networking. In version one, Docker compose   attaches all the containers, it runs to the  default bridged network. And then use links to   enable communication between the containers as  we did before. With version two Docker compose  

automatically creates a dedicated bridged network  for this application, and then attaches all   containers to that new network. All containers are  then able to communicate to each other using each   other's service name. So you basically don't need  to use links in version two of Docker compose,  

you can simply get rid of all the links you  mentioned in version one when you convert a   file from version one to version two. And finally,  motion to also introduces a depends on feature.   If you wish to specify a startup order. For  instance, say the voting web application is  

dependent on the Redis service. So you need to  ensure that Redis container is started first,   and only then the voting web application must  be started. We could add a depends on property   to the voting application and indicate that it  is dependent on Redis. Then comes version three,  

which is the latest as of today. version three  is similar to version two in the structure,   meaning it has a version specification at the top  and the Services section under which you put all   your services just like in version two, make sure  to specify the version number as three at the top.  

version three comes with support for Docker swarm,  which we will see later on. There are some options   that were removed and added. To see details on  those you can refer to the documentation section   using the link in the reference page. Following  this lecture. We will see version three in much  

detail later, when we discuss about Docker  stacks. Let's talk about networks in Docker   compose. Getting back to our application. So far,  we've been just deploying all containers on the   default bridge network. Let us say we modify the  architecture a little bit to contain the traffic  

from the different sources. For example, we would  like to separate the user generated traffic from   the applications internal traffic. So we create  a front end network dedicated for traffic from   users, and a back end network dedicated for  traffic within the application. We then connect  

the user facing applications which are the voting  app and the result app to the front end network   and all the components to an internal back end  network. So back in our Docker compose file,   note that I have actually stripped out  the port section for simplicity's sake,  

there's still there, but they're just not shown  here. The first thing we need to do if we were   to use networks is to define the networks we are  going to use. In our case, we have two networks,   front end and back end. So create a new property  called networks at the root level, and listen to  

the services in the Docker compose file and add  a map of networks we are planning to use. Then,   under each service, create a network's property  and provide a list of networks that service must   be attached to. In case of Redis and dB. It's  only the back end network. In case of the front  

end applications such as the voting app and the  result app, they're required to be a test to both   a front end and back end network. You must also  add a section for worker container to be added   to the back end network. I have just omitted that  in this slide due to space constraints. Now that  

you have seen Docker compose files, head over  to the coding exercises and practice developing   some Docker compose files. That's it for this  lecture. And I will see you in the next lecture.   We will now look at Docker registry. So what is  a registry if the containers Where the rain then  

they will rain from the Docker registry, which  are the clouds. That's where Docker images are   stored. It's a central repository of all Docker  images. Let's look at a simple nginx container.   We run the Docker run nginx command to run  an instance of the nginx image. Let's take a  

closer look at that image name. Now the name is  nginx. But what is this image and where is this   image pulled from? This name follows Dockers image  naming convention nginx. Here is the image or the   repository name. When you say nginx, it's actually  nginx slash nginx. The first part stands for the  

user or account name. So if you don't provide an  account or a repository name, it assumes that it   is the same as the given name, which in this case  is nginx. The usernames is usually your Docker   Hub account name or if it is an organization,  then it's the name of the organization. If you  

were to create your own account and create  your own repositories or images under it,   then you would use a similar pattern. Now, where  are these images stored and pulled from? Since   we have not specified the location where these  images are to be pulled from, it is assumed to be  

on Dockers default registry, Docker Hub, the DNS  name for which is docker.io. The registry is where   all the images are stored. Whenever you create a  new image or update an existing image, you push   it to the registry and every time anyone deploys  this application, it is pulled from that registry.  

There are many other popular registries as well.  For example, Google's registry is that dcr.io,   where a lot of Kubernetes related images are  stored, like the ones used for performing end to   end tests on the cluster. These are all publicly  accessible images that anyone can download,  

and access. When you have applications built in  house that shouldn't be made available to the   public. hosting an internal private registry may  be a good solution. Many cloud service providers   such as AWS, Azure, or GCP, provide a private  registry by default, when you open an account with  

them. on any of these solutions via Docker Hub, or  Google registry or your internal private registry,   you may choose to make a repository private,  so that it can only be accessed using a set   of credentials from Dockers perspective. To run a  container using an image from a private registry.  

you first log into your private registry using  the Docker login command, input your credentials.   Once successful, run the application using private  registry as part of the image name like this. Now,   if you did not log into the private registry, it  will come back saying that the image cannot be  

found. So remember to always log in before pulling  or pushing to a private registry. We said that   cloud providers like AWS or GCP provide a private  registry when you create an account with them.   But what if you're running your application on  premise and don't have a private registry? How do  

you deploy your own private registry within your  organization, the Docker registry, itself another   application, and of course, is available as a  Docker image. The name of the image is registry,   and it exposes the API on port 5000. Now that you  have your custom registry running at Port 5000,  

on this Docker host, how do you push your own  image to it? Use the Docker image tag command   to tag the image with the private registry URL  in it. In this case, since it's running on the   same Docker host, I can use local host semi colon  5000 followed by the image name. I can then push  

my image to my local private registry using the  command Docker push and the new image name with   the Docker registry information in it. From there  on, I can pull my image from anywhere within this   network using either localhost if you're on the  same host, or the IP or domain name of my Docker  

host, if I'm accessing from another host in my  environment. Well, that's it for this lecture,   head over to the practice test and practice  working with private Docker registries.   Welcome to this lecture on Docker engine.  In this lecture, we will take a deeper look  

at Dockers architecture, how it actually runs  applications in isolated containers and how it   works under the hood. Docker engine as we have  learned before you simply refer to a host with   Docker installed on it. When you install Docker  on a Linux host, you're actually installing three  

different components. The Docker daemon, the REST  API server, and the Docker CLA. The Docker daemon   is a background process that manages Docker  objects such as the images, containers, volumes   and networks. The Docker REST API server is the  API interface that programs can use to talk to the  

daemon and provide instructions, you could create  your own tools using this REST API. And the Docker   CLA is nothing but the command line interface  that we've been using, until now to perform   actions such as running a container stopping  containers, destroying images, etc. It uses  

the REST API to interact with the Docker daemon.  Something to note here is that the Docker CLA need   not necessarily be on the same host. It could be  on another system like a laptop, and can still   work with a remote Docker engine. Simply use the  dash H option on the Docker command and specify  

the remote Docker engine address and a port  as shown here. For example, to run a container   based on nginx on a remote Docker host, run the  command Docker dash H equals 10.1 23 dot 2.1 colon   2375 run ngi nx. Now let's try and understand how  exactly our applications containerized in Docker,  

how does it work under the hood, Docker uses  namespaces to isolate workspace, process IDs,   network, inter process communication, mounds  and Unix time sharing systems are created in   their own namespace thereby providing isolation  between containers. Let's take a look at one of  

the namespace isolation technique. process ID  namespaces. Whenever a Linux system boots up,   it starts with just one process with a process  ID of one. This is the root process and kicks   off all the other processes in the system.  By the time the system boots up completely,  

we have a handful of processes running. This can  be seen by running the PS command to list all the   running processes. The process IDs are unique  and two processes cannot have the same process   ID. Now if we were to create a container, which is  basically like a child system within the current  

system, the child system needs to think that it  is an independent system on its own. And it has   its own set of processes originating from a root  process with a process ID of one. But we know that   there is no hard isolation between the containers  and the underlying host. So the processes running  

inside the container are in fact processes running  on the underlying host. And so two processes   cannot have the same process ID of one. This is  where namespaces come into play. With process   ID namespaces. Each process can have multiple  process IDs associated with it. For example,  

when the processes start in the container, it's  actually just another set of processes on the   base Linux system. And it gets the next available  process ID in this case, five and six. However,   they also get another process ID starting with P  ID one in the container namespace which is only  

visible inside the container. So the container  things that it has its own route process tree. And   so it is an independent system. So how does that  relate to an actual system? How do you see this on   a host? Let's say I were to run an nga next server  as a container. We know that the nginx container  

runs and nginx service. If we were to list all the  services inside the Docker container, we see that   the next service running with a process ID of one.  This is the process ID of the service inside of   the container namespace. If we list the services  on the Docker host, we will see the same service  

but with a different process ID that indicates  that all processes are in fact running on the same   host but separated into their own containers using  namespaces. So we learned that the underlying   Docker host as well as the containers share the  same system resources such as CPU and memory. How  

much of the resources are dedicated to the host  and the containers? And how does Docker manage   and share the resources between the containers.  By default, there is no restriction as to how   much of a resource a container can use. And  hence, a container may end up utilizing all  

of the resources on the underlying host. But there  is a way to restrict the amount of CPU or memory   a container can use. Docker uses thi groups or  control groups to restrict the amount of hardware   resources allocated to each container. This can  be done by providing the dash dash CPUs option  

to the Docker run command. Providing a value of  point five will ensure that the container does   not take up more than 50% of the host CPU at any  given time. The same goes with memory. Setting a   value of 100 M to the dash dash memory option  limits the amount of memory the container can  

use to 100 megabytes. If you're interested in  reading more on this topic, refer to the links   I posted in the reference page. That's it for now  on Docker engine. In the next lecture, we talked   about other advanced topics on Docker storage and  file systems. See you in the next lecture. During  

this course, we learned that containers share the  underlying OS kernel. And as a result, we cannot   have a Windows container running on Linux hosts  or vice versa. We need to keep this in mind while   going through this lecture, as it's very important  concept and most beginners tend to have an issue  

with it. So what are the options available  for Docker on Windows? There are two options   available. The first one is Docker on Windows  using Docker toolbox. And the second one is the   Docker desktop for Windows option. We will look at  each of these now. Let's take a look at the first  

option. Docker toolbox. This was the original  support for Docker on Windows. Imagine that you   have a Windows laptop and no access to any Linux  system whatsoever. But you would like to try   Docker, you don't have access to a Linux system in  the lab or in the cloud. What would you do? What  

I did was to install a virtualization software  on my Windows system like Oracle VirtualBox or   VMware Workstation and deploy a Linux VM on it  such as Ubuntu or Debian, then install Docker on   the Linux VM and then play around with it. This  is what the first option really does. It doesn't  

really have anything much to do with Windows,  you cannot create Windows based Docker images,   or run Windows based Docker containers. You  obviously cannot run Linux container directly on   Windows either. You're just working with Docker on  a Linux virtual machine on a Windows host. Docker,  

however, provides us with a set of tools to make  this easy which is called as the Docker toolbox.   The Docker toolbox contains a set of tools like  Oracle VirtualBox, Docker engine, Docker machine,   Docker compose and a user interface called  kite Matic. This will help you get started  

by simply downloading and running the Docker  toolbox executable. Ever install VirtualBox,   deploy a lightweight VM called boot to Docker,  which has Docker running in it already so that   you are all set to start with Docker easily  and with within a short period of time. Now  

what about requirements, you must ensure that  your operating system is 64 bit Windows seven   or higher and that the virtualization  is enabled on the system. Now remember,   Docker toolbox is legacy version for older  Windows systems that do not meet requirements  

for the newer Docker for Windows option. The  second option is the newer option called Docker   desktop for Windows. In the previous option,  we saw that we had Oracle VirtualBox installed   on Windows and then a Linux system and then Docker  on that Linux system. Now with Docker for Windows,  

we take out Oracle VirtualBox and use the native  virtualization technology available with Windows   called Microsoft Hyper V. During the installation  process for Docker for Windows, it will still   automatically create a Linux system underneath.  But this time it is created on the Microsoft Hyper  

V instead of Oracle VirtualBox and have Docker  running on that system. Because of this dependency   on Hyper V. This option is only supported for  Windows 10 Enterprise or Professional Edition   and on Windows Server 2016. Because both  these operating systems come with Hyper V  

support by default. Now here's the most important  point. So far whatever we've been discussing,   with Dockers support for Windows. It is strictly  for Linux containers, Linux applications packaged   into Linux Docker images. We're not talking  about Windows applications. Windows images  

or Windows containers. Both the options we just  discussed will help you run a Linux container on a   Windows host. With Windows Server 2016, Microsoft  announced support for Windows containers for the   first time. You can now package applications  Windows applications into Windows Docker  

containers and run them on a Windows Docker host  using Docker desktop for Windows. When you install   Docker desktop for Windows, the default option  is to work with Linux containers. But if you   would like to run Windows containers, then you  must explicitly configure Docker for Windows to  

switch to using Windows containers. In early  2016, Microsoft announced windows containers.   Now you could create Windows based images and  run Windows containers on a Windows Server just   like how you would run Linux containers on a  Linux system. You can create windows images,  

containerize your applications and share them  through the Docker store as well. Unlike in Linux,   there are two types of containers in Windows. The  first one is a Windows Server container, which   works exactly like Linux containers where the OS  kernel is shared with the underlying operating  

system to allow better security boundary between  containers and to have kernels with different   versions and configurations to coexist. The  second option was introduced known as the Hyper   V isolation. With Hyper V isolation each container  is run within a highly optimized virtual machine  

guaranteeing complete kernel isolation between the  containers and the underlying host. Now while in   the Linux world, you had a number of base images  for Linux systems such as Ubuntu, Debian, Fedora,   Alpine etc. If you remember that, that is what you  specify at the beginning of the Docker file. In  

the windows world, we have two options the Windows  Server Core and Nano Server. A Nano Server is a   headless deployment option for Windows Server  which runs at a fraction of size of the full   operating system. You can think of this like the  Alpine image in Linux. The Windows Server Core,  

though is not as light weight as you might  expect it to be. Finally, Windows containers   are supported on Windows Server 2016 Nano  Server and Windows 10 professional Enterprise   Edition. Remember on Windows 10 professional  and Enterprise Edition only supports Hyper V  

isolated containers. Meaning as we just discussed,  every container deployed is deployed on a highly   optimized virtual machine. Well, that's it about  Docker on Windows. Now before I finish, I want to   point out one important fact. We saw two ways of  running a Docker container using VirtualBox or  

Hyper V. But remember, VirtualBox and Hyper  V cannot coexist on the same windows host.   So if you started off with Docker toolbox with  VirtualBox and if you plan to migrate to Hyper V,   remember you cannot have both solutions at the  same time. There is a migration guide available  

on Docker documentation page on how to migrate  from VirtualBox to Hyper V. That's it for now.   Thank you and I will see you the next lecture. We  now look at Docker on Mac Docker on Mac is similar   to Docker on Windows. There are two options to  get started Docker on Mac using Docker toolbox,  

or Docker desktop for Mac option. Let's look at  the first option. Docker toolbox. This was the   original support for Docker on Mac. It is Docker  on Linux VM created using VirtualBox on Mac as   Windows It has nothing to do with Mac applications  or Mac based images or Mac containers. It purely  

runs Linux containers on a Mac OS. Docker toolbox  contains a set of tools like Oracle VirtualBox,   Docker engine, Docker machine, Docker compose,  and a user interface called cadmatic. When you   download and install the Docker toolbox  executable, installs VirtualBox deploys  

lightweight VM called boot to Docker, which has  Docker running in it already. This requires mac   os 10.8 or newer. The second option is the newer  option called Docker desktop for Mac with Docker   desktop for Mac, we take out Oracle VirtualBox  and use hypercard virtualization technology  

during the installation process for Docker for  Mac, it will still automatically create a Linux   system underneath. But this time it is created on  hypercard instead of Oracle VirtualBox and have   Docker running on that system. This requires Mac  OS Sierra 10 or 12 or newer, and my and the Mac  

hardware must be 2010 or newer. Finally, remember  that all of this is to be able to run the Linux   container on Mac. As of this recording, there are  no Mac based images or containers. Well, that's it   with Docker on Mac for now. We will now try to  understand what container orchestration is. So  

far in this course, we have seen that with Docker,  you can run a single instance of the application   with a simple Docker run command. In this case,  to run a Node JS based application, you run the   Docker run node j s command. But that's just one  instance of your application on one Docker host,  

what happens when the number of users increase,  and that instance is no longer able to handle the   load, you deploy additional instance of your  application by running the Docker run command   multiple times. So that's something you have to  do yourself, you have to keep a close watch on  

the load and performance of your application and  deploy additional instances yourself. And not just   that, you have to keep a close watch on the health  of these applications. If a container was to fail,   you should be able to detect that and run the  Docker run command again to deploy another  

instance of that application. What about the  health of the Docker host itself? What if the host   crashes and is inaccessible? The containers hosted  on that host become inaccessible to so what do you   do in order to solve these issues, you will need  a dedicated engineer who can sit and monitor the  

state performance and health of the containers and  take necessary actions to remediate the situation.   But when you have large applications deployed  with 10s of 1000s of containers that that's   not a practical approach. So you can build your  own scripts. And that will help you tackle these  

issues. To some extent. container orchestration  is just a solution for that. It is a solution   that consists of a set of tools and scripts  that can help host containers in a production   environment. Typically, a container orchestration  solution consists of multiple Docker hosts that  

can host containers. That way, even if one fails,  the application is still accessible through the   others. A container orchestration solution  easily allows you to deploy hundreds or 1000s   of instances of your application with a single  command. This is a command used for Docker swarm,  

we will look at the command itself in a bit. Some  orchestration solutions can help you automatically   scale up the number of instances when users  increase and scale down the number of instances   when the demand decreases. Some solutions can even  help you in automatically adding additional hosts  

to support the user load, and not just clustering  and scaling. The container orchestration solutions   also provide support for advanced networking  between these containers across different hosts,   as well as load balancing user requests across  different house. They also provide support for  

sharing storage between the house as well as  support for configuration management and security   within the cluster. There are multiple container  orchestration solutions available today. Docker   has Docker swarm Kubernetes from Google and mezzos  from patchy while Docker swarm is really easy to  

set up and get started. It lacks some of the  advanced auto scaling features required for   complex production grade applications. mezzos on  the other hand, is quite difficult to set up and   get started, but supports many advanced features.  Kubernetes is arguably the most popular of it all  

is a bit difficult to set up and get started but  provides a lot of options to customize deployments   and has support for many different vendors.  Kubernetes is now supported on all public cloud   service providers like GCP, Azure and AWS and  the Kubernetes project is one of the top ranked  

projects on GitHub and upcoming lectures. We will  take a quick look at Docker swarm and Kubernetes.   We will now get a quick introduction to Docker  swarm. Docker swarm has a lot of concepts to   cover and requires its own course. But we will  try to take a quick look at some of the basic  

details so you can get a brief idea on what it is.  with Docker swarm. You could now combine multiple   Docker machines together into a single cluster.  Docker swarm will take care of distributing your   services or your application instances into  separate hosts for high availability For load  

balancing across different systems and hardware  to set up a Docker swarm, you must first have   hosts or multiple hosts with Docker installed on  them, then you must designate one host to be the   manager or the master or the swarm manager as it  is called, and others as slaves or workers. Once  

you're done with that, run the Docker swarm in  it command on the swarm manager, and that will   initialize the swarm manager. The output will also  provide the command to be run on the workers to   copy the command and run it on the worker nodes  to join the manager. After joining the swarm,  

the workers are also referred to as nodes. And  you're now ready to create services and deploy   them on the swarm cluster. So let's get into  some more details. As you already know, to run   an instance of my web server, I run the Docker run  command and specify the name of the image I wish  

to run. This creates a new container instance of  my application and serves my web server. Now that   we have learned how to create a swarm cluster, how  do I utilize my cluster to run multiple instances   of my web server. Now one way to do this would  be to run the Docker run command on each worker  

node. But that's not ideal as I might have to log  into each node and run this command. And there,   there could be hundreds of nodes that will have  to set up load balancing myself, I like to monitor   the state of each instance myself. And if  instances were to fail, I'll have to restart them  

myself. So it's going to be an impossible task.  And that is where Docker swarm orchestration comes   in. Docker swarm orchestrator does all of this for  us. So far, we've only set up the swarm cluster,   but we haven't seen orchestration in action.  The key component of swarm orchestration is  

the Docker a service. Docker services are one or  more instances of a single application or service   that runs across the saw the nodes in the swarm  cluster for example. In this case, I could create   a Docker service to run multiple instances of my  web server application across worker nodes in my  

swarm cluster. For this, I run the Docker service,  create command on the manager node and specify my   image name there, which is my web server in this  case, and use the option replicas to specify the   number of instances of my web server I would like  to run across the cluster, since I specified three  

replicas, and I get three instances of my web  server distributed across the different worker   nodes. Remember, the Docker service command  must be run on the manager node and not on the   worker node. The Docker service create command is  similar to the Docker run command in terms of the  

options passed, such as the dash e environment  variable, the dash p for publishing ports,   the network option to attach container to  a network, etc. Well, that's a high level   introduction to Docker swarm, there is a lot more  To know such as configuring multiple managers,  

overlay networks, etc. As I mentioned, it requires  its own separate course. Well, that's it for now.   In the next lecture, we will look at Kubernetes at  a high level. We will now get a brief introduction   to basic Kubernetes concepts. Again Kubernetes  requires its own course, well, a few courses,  

at least five, but we will try to get a brief  introduction to it here. with Docker, you were   able to run a single instance of an application  using the Docker COI by running the Docker run   command, which is great. running an application  has never been so easy before. with Kubernetes  

using the Kubernetes COI, known as cube control,  you can run 1000 instances of the same application   with a single command Kubernetes can scale it up  to 2000 with another command Kubernetes can be   even configured to do this automatically so that  instances and the infrastructure itself can scale  

up and down. based on user load Kubernetes can  upgrade these 2000 instances of the application   in a rolling upgrade fashion, one at a time  with a single command. If something goes wrong,   it can help you roll back these images with a  single command Kubernetes can help you test new  

features of your application. By only upgrading  a percentage of these instances through a B   testing methods. The Kubernetes open architecture  provides support for many, many different network   and storage vendors. Any network or storage brand  that you can think of has a plugin for Kubernetes  

Kubernetes supports a variety of authentication  and authorization mechanisms. All major cloud   service providers have native support for  Kubernetes. So what's the relation between   Docker and Kubernetes Kubernetes uses Docker  host to host applications in the form of Docker  

containers. Well, it need not be Docker all the  time. Kubernetes supports as natives to Dockers as   well, such as rocket, or a crier. But let's take  a quick look at the Kubernetes architecture. A   Kubernetes cluster consists of a set of nodes, let  us start with nodes. A node is a machine physical  

or virtual on which a Kubernetes the Kubernetes  software set of tools are installed. And node is a   worker machine. And that is where containers will  be launched by Kubernetes. But what if the node   on which the application is running fails? Well,  obviously, our application goes down. So you need  

to have more than one nodes. A cluster is a set of  nodes grouped together this way, even if one node   fails, you have your application still accessible  from the other nodes. Now we have a cluster but   who is responsible for managing this cluster?  Where is the information about the members of  

the cluster stored? How are the nodes monitored?  When a node fails? How do you move the workload of   the failed nodes to another worker node, that's  where the master comes in. The Master is a node   with the Kubernetes control plane components  installed. The master watches over the notes are  

in the cluster and is responsible for the actual  orchestration of containers on the worker nodes.   When you install Kubernetes on a system, you're  actually installing the following components,   an API server and actually server, a cubelet  service container runtime engine like Docker, and  

a bunch of controllers and the scheduler. The API  server acts as the front end for Kubernetes. The   users management devices command line interfaces  all talk to the API server to interact with the   Kubernetes cluster. Next is the Etsy d a key value  store. The Etsy D is a distributed reliable key  

value store used by Kubernetes to store all data  used to manage the cluster. Think of it this way,   when you have multiple nodes and multiple  masters in your cluster. etsy D stores all   that information on all the nodes in the cluster  in a distributed manner. NCD is responsible for  

implementing a locks within the cluster to ensure  there are no conflicts between the masters. The   scheduler is responsible for distributing work  or containers across multiple nodes. It looks   for newly created containers and assigns them  to nodes. The controllers are the brain behind  

orchestration, they're responsible for noticing  and responding when nodes containers or endpoints   goes down. The controllers makes decisions  to bring up new containers. In such cases,   the container runtime is the underlying software  that is used to run containers. In our case,  

it happens to be Docker. And finally, cubelet is  the agent that runs on each node in the cluster.   The agent is responsible for making sure that the  containers are running on the nodes as expected.   And finally, we also need to learn a little bit  about one of the command line utilities known  

as the cube command line tool or the cube control  tool or cube cuddle as it is also called the cube   control tool is the Kubernetes CLA, which is used  to deploy and manage applications on a Kubernetes   cluster to get cluster related information to get  the status of the nodes in the cluster, and many  

other things. The Cube control run command is  used to deploy an application on the cluster.   The Cube control cluster info command is used to  view information about the cluster. And the cube   control get nodes command is used to list all the  nodes part of the cluster. So to run hundreds of  

instances of your application across hundreds  of nodes. All I need is a single Kubernetes   command like this. Well, that's all we have for  now, a quick introduction to Kubernetes and its   architecture. We currently have three courses on  code cloud on Kubernetes that will take you from  

the absolute beginner to a certified expert.  So have a look at it when you get a chance.   So we're at the end of this beginner's course  to Docker. I hope you had a great learning   experience. If so please leave a comment  below. If you'd like my way of teaching,  

you will love my other courses hosted on my site  at code cloud. We have courses for Docker swarm   Kubernetes advanced courses on Kubernetes  certification, as well as openshift. We have   courses for automation tools like Ansible  Chef and Puppet and many more on the way,  

visit code cloud@www.cloud.com. Well, thank you so  much for your time, and until next time, goodbye.