YT YouTube2Text

YouTube2Text → Transcripts → Docker Explained for Absolute Beginners [2026]

Docker Explained for Absolute Beginners [2026] — Transcript

by KodeKloud · 8,858 words · 1,364 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Hello and welcome to the Docker for
0:01beginners course. My name is Mumshad
0:04Manambed and I'll be your instructor for
0:06this course.
0:07In this course, you will learn Docker
0:09through a series of lectures that use
0:11illustrations and animations and some
0:13fun analogies that simplify complex
0:15concepts.
0:17We have demos that will show you how to
0:18install and get started with Docker and
0:21most importantly, we have hands-on labs
0:23that you can access right in your
0:25browser. First, let's look at the
0:27objectives of this course.
0:29In this course, we'll first try to
0:30understand what containers are, what
0:32Docker is and why you might need it.
0:35We'll see how to run Docker container
0:36and how to build your own Docker image.
0:39We will see networking in Docker and how
0:41to use Docker compose, and what Docker
0:43registry is, how to deploy your own
0:45private registry and we then look at
0:48some of these concepts in depth and we
0:49try to understand how Docker really
0:51works under the hood.
0:53We look at Docker for Windows and Mac
0:55before finally getting a basic
0:57introduction to container orchestration
0:59tools like Docker Swarm and Kubernetes.
1:03Now, here's a quick note about hands-on
1:04labs. We provide real labs that you can
1:06access right in your browser, anywhere,
1:08anytime and as many times as you want.
1:11The labs give you instant access to a
1:13terminal, to a Docker host and an
1:14accompanying quiz portal.
1:16The quiz portal asks a set of questions
1:18such as exploring the environment and
1:20gathering information or you might be
1:22asked to perform an action such as run a
1:24Docker container or troubleshoot and fix
1:26an issue. The quiz portal then validates
1:28your work and gives you feedback
1:30instantly.
1:31Every lecture in the course is
1:33accompanied by such challenging
1:35interactive quizzes that makes learning
1:38Docker a fun activity.
1:40So, I hope you're as thrilled as I am to
1:42get started. So, let us begin.
1:46>> [music]
1:50>> We're going to start by looking at a
1:52high-level overview on why you need
1:54Docker. Let me start by sharing how I
1:56got introduced to Docker. In one of my
1:58previous projects, I had this
2:00requirement to set up an end-to-end
2:02application stack including various
2:04different technologies like a web server
2:06using Node.js, a database such as
2:08MongoDB, a messaging system like Redis,
2:11and an orchestration tool like Ansible.
2:13We had a lot of issues developing this
2:14application stack with all of these
2:16different components. First of all,
2:19their compatibility with the underlying
2:21OS was an issue. We had to make sure
2:23that all of these different services
2:25were compatible with of OS we were
2:27planning to use. There have been times
2:29when certain versions of the services
2:31were not compatible with the OS and
2:33we've had to go back and look at
2:35different operating systems that was
2:37compatible with all of these different
2:38services. Secondly, we had to check the
2:40compatibility between the services and
2:43the libraries and dependencies on the
2:44OS. We've had issues where one service
2:47requires one version of a dependent
2:48library, whereas another service
2:50requires another version.
2:52The architecture of our application
2:53changed over time. We've had to upgrade
2:55to newer versions of these components or
2:58change the database and so on.
3:00Every time something changed, we had to
3:02go through the same process of checking
3:04compatibility between these various
3:06components and the underlying
3:07infrastructure. This compatibility
3:09matrix issue is usually referred to as
3:12the matrix from hell.
3:14Next, every time we had a new developer
3:17on board, we found it really difficult
3:19to set up a new environment. The new
3:21developers had to follow a large set of
3:23instructions and run hundreds of
3:25commands to finally set up their
3:26environments. We had to make sure they
3:28were using the right operating system,
3:30the right versions of each of these
3:32components, and each developer had to
3:34set up all that by themselves each time.
3:37We also had different development, test,
3:39and production environments. One
3:41developer may be comfortable using one
3:43OS, and the others may be comfortable
3:45using another one. Also, we couldn't
3:47guarantee that the application that we
3:48were building would run the same way in
3:51different environments.
3:52All of these made our life in
3:54developing, building, and shipping the
3:55application really difficult. So, I
3:58needed something that could help us with
4:00the compatibility issue, and something
4:02that will let us modify or change these
4:05components without affecting the other
4:07components. And even modify the
4:09underlying operating systems as
4:10required.
4:12That search landed me on Docker.
4:14With Docker, I was able to run each
4:16component in a separate container with
4:19its own dependencies and its own
4:20libraries, all on the same VM and the
4:23OS, but within separate environments or
4:25containers.
4:26We had to build a Docker configuration
4:28once, and all our developers could now
4:30get started with a single Docker run
4:33command.
4:34Irrespective of what the underlying
4:36operating system they run, all they
4:37needed to do was to make sure they had
4:40Docker installed on their systems.
4:43And that's the problem Docker solves.
4:45Docker takes the matrix from hell, the
4:48tangle of services, libraries,
4:50dependencies, and operating systems, and
4:52packages each piece into its own
4:54self-contained container. The same setup
4:56runs the same way on every developer's
4:58laptop in test and in production. No
5:01more chasing version conflicts, no more
5:03pages of setup instructions for new
5:06developer, one Docker run command, and
5:08you're up.
5:11So, what are containers? Containers are
5:13completely isolated environments. They
5:15can have their own processes or
5:17services, their own network interfaces,
5:20their own mounts, just like virtual
5:21machines, except they all share the same
5:24OS kernel. We will look at what that
5:26means in a bit, but it's also important
5:29to note that containers are not new with
5:32Docker. Containers have existed for
5:34about 10 years now, and some of the
5:36different types of containers are LXC,
5:38LXD, LXCFS, and so on.
5:41Now, here's the thing that's actually
5:43changed since the early days. Docker
5:45started out using LXC under the hood,
5:48but Docker moved away from LXC back in
5:51version 0.9.0, and that was around 2014,
5:54and switched to its own library called
5:57libcontainer.
5:58libcontainer later became runC, which is
6:01the reference implementation of the OCI
6:03runtime specification. So, OCI stands
6:05for Open Container Initiative, and it's
6:07the open standard that defines how
6:09container runtimes and image formats
6:12should work. So, today when Docker runs
6:15a container, it's actually going through
6:17containerD and runC, not LXC, LXD, or
6:21LXCFS, which are still around as
6:24separate Linux container technologies,
6:26but Docker itself doesn't use them
6:27anymore.
6:29Now, setting up these low-level
6:30container environments is hard, and that
6:32is where Docker offers a high-level tool
6:35with several powerful functionalities,
6:38making it really easy for end users like
6:40us. And this is how Docker became so
6:43popular.
6:45To understand how Docker works, let us
6:47revisit some basic concepts of operating
6:49systems first. If you look at operating
6:51systems like Ubuntu, Fedora, openSUSE,
6:54or AlmaLinux and the rest, they all
6:57consist of two things:
6:59an OS kernel and a set of software. The
7:02OS kernel is responsible for interacting
7:04with the underlying hardware. The kernel
7:06remains the same, which is Linux in this
7:08case. It's the software above it that
7:11makes the operating systems different.
7:14This software may consist of a different
7:17user interface, drivers, compilers, file
7:19managers, developer tools, and so on.
7:22And you have a common Linux kernel
7:23shared across OSes and some custom
7:26software that differentiates operating
7:28systems from each other.
7:29Now, we said earlier that Docker
7:31containers share the underlying kernel.
7:33So, what does that mean?
7:35Sharing the kernel. Let's say we have a
7:37system with an Ubuntu OS with Docker
7:39installed on it.
7:41Docker can run any flavor of OS on top
7:44of it as long as they're all based on
7:46the same kernel, in this case Linux. So,
7:48if the underlying OS is Ubuntu, Docker
7:50can run a container based on another
7:52distribution like Debian, Fedora,
7:54openSUSE, or AlmaLinux.
7:57Each Docker container only has the
7:59additional software that we just talked
8:01about that makes these operating systems
8:03different. And Docker uses the
8:05underlying kernel of the Docker host,
8:08which works with all operating systems
8:10above.
8:10So, what is an OS that does not share
8:13the same kernel as these?
8:15Windows. So, you won't be able to run a
8:17Windows-based container on a Docker host
8:19with Linux on it. For that, you will
8:21need a Docker on a Windows server. Now,
8:23it is this when I say that most of my
8:25students go, "Hey, hold on. That's not
8:27true. They install Docker on Windows,
8:30they run a container based on Linux, and
8:32go, 'See, it's possible.'"
8:34Well, when you install Docker on Windows
8:36and run a Linux container on Windows,
8:38you're not really running a Linux
8:40container on Windows. Windows runs a
8:42Linux container on a Linux virtual
8:44machine under the host. So, it's really
8:47a Linux container on a Linux virtual
8:49machine on a Windows machine. So, we'll
8:52discuss more about this on the Docker on
8:54Windows or Mac
8:56lessons later in this course.
8:58Now, you might ask, "Isn't that a
8:59disadvantage then? Well, not being able
9:01to run another kernel on the OS?" Well,
9:04the answer is no, because unlike
9:05hypervisors, Docker is not meant to
9:08virtualize and run different operating
9:09systems and kernels on the same
9:11hardware.
9:12The main purpose of Docker is to package
9:15and containerize applications and to
9:17ship them and to run them anywhere,
9:19anytime, as many times as you want.
9:23Now, let us look at the difference
9:25between virtual machines and containers,
9:27something that we tend to do, especially
9:29those from a virtualization background.
9:31Now, in the case of Docker, we have the
9:33underlying hardware infrastructure, and
9:35then the OS, and then the Docker
9:38software itself installed on the OS.
9:41Docker then manages the containers that
9:43run with libraries and dependencies
9:44alone.
9:45In the case of virtual machines, we have
9:47the hypervisor like the ESX on the
9:49hardware, and then the virtual machines
9:51on them, and each virtual machine has
9:53its own OS inside it, and then the
9:56dependencies, and then the application.
9:58The overhead causes higher utilization
10:00of underlying resources as there are
10:02multiple virtual operating systems and
10:04kernels running.
10:06Virtual machines also consume higher
10:08disk space as each VM is heavy and is
10:10usually in gigabytes in size. Whereas
10:13Docker containers are lightweight and
10:14are usually in megabytes in size. This
10:17lets Docker containers boot up faster,
10:19usually in a matter of seconds, whereas
10:21VMs, as we know, take minutes to boot up
10:23because they need to boot up the entire
10:25operating system.
10:27It is also important to note that Docker
10:29has less isolation as more resources are
10:32shared between the containers, like the
10:34kernel, whereas VMs have complete
10:36isolation from each other. Now, since
10:38VMs don't rely on the underlying OS or
10:41kernel, you can run different types of
10:43applications built on different OSs such
10:45as
10:49Now, those are some of the differences
10:51between the two. And now, having said
10:53that, it's not an either container or
10:54virtual machine situation. It's
10:56containers and virtual machines. So,
10:58when you have large environments with
11:00thousands of applications, containers
11:02running on thousands of Docker hosts,
11:04you will often see containers
11:05provisioned on virtual Docker hosts.
11:08That way, we can use the advantages of
11:10both technologies. We get the benefits
11:11of virtualization to easily provision or
11:14decommission Docker hosts as required,
11:16and at the same time, you make use of
11:19the benefits of Docker to easily
11:20provision applications and quickly scale
11:22them as required. Remember that in this
11:25case, we will not be provisioning that
11:27many virtual machines as we might have
11:29before because earlier, we provisioned a
11:32virtual machine for each application.
11:34Now you might provision a virtual
11:36machine for hundreds or thousands of
11:38containers.
11:40There are a lot of containerized
11:42versions of applications readily
11:43available today. Most organizations have
11:45their products containerized and
11:47available in public Docker repository
11:49called Docker Hub. Docker Hub is the
11:50most popular registry, but there are
11:52many others, too. So, you have GitHub
11:54container registry, Google Artifact
11:56Registry, AWS ECR, and Azure Container
11:59Registry. You can find images of most
12:02common operating systems, databases, and
12:04other services and tools there. Once you
12:06identify the images that you need and
12:08you install Docker on your host,
12:10bringing up an application is as easy as
12:13running a Docker run command with the
12:14name of the image. So, running a Docker
12:16run Ansible command will run an instance
12:18of Ansible on the Docker host.
12:20Similarly, you can run an instance of
12:21MongoDB, Redis, and Node.js using the
12:24Docker run command. If you need to run
12:26multiple instances of the web service,
12:29you simply add as many instances as you
12:31need and configure a load balancer of
12:33some kind in the front.
12:35In case of one of the instances were
12:38to fail, simply destroy that instance
12:40and launch a new one. There are other
12:42solutions available for handling such
12:44cases that we will look at later in this
12:45course. For now, don't focus too much on
12:47the commands. We'll get to that in a
12:49bit.
12:50So, we've been talking about images and
12:52containers. Let's understand the
12:54difference between the two.
12:55An image is a package or a template,
12:58just like uh VM template that you might
13:00have worked with in the virtualization
13:01world.
13:02It is used to create one or more
13:04containers.
13:05Containers are running instances of
13:07images that are isolated and have their
13:09own environments and set of processes.
13:12As we have seen before, a lot of
13:14products have been Dockerized already.
13:16In case you cannot find what you're
13:17looking for, you could create your own
13:19image and push it to a Docker Hub
13:21repository, making it available for the
13:24public.
13:26If you look at it, traditionally,
13:28developers developed applications. Then
13:30they handed it over to the ops team to
13:31deploy and manage it in production
13:33environments.
13:34They did that by providing a set of
13:36instructions, information about how the
13:38host must be set up, what prerequisites
13:40are to be installed on the host, how the
13:42dependencies are to be configured, and
13:44so on. Since the ops team did not really
13:46develop the application on their own,
13:48they struggled with setting it up. When
13:50they had an issue, they worked with the
13:51developers to resolve it.
13:53With Docker, the developers and
13:55operations teams work hand in hand to
13:58transform the guide into a Dockerfile
14:01with both of their requirements.
14:03This Dockerfile is then used to create
14:05an image for their applications. This
14:08image can now run on any host with
14:10Docker installed on it, and it's
14:11guaranteed to run the same way
14:13everywhere.
14:14So, the ops team can now simply use the
14:17image to deploy the application, since
14:19the image was already working when the
14:21developer built it, and the operations
14:23have not modified it, it continues to
14:25work the same way when deployed in
14:27production.
14:28And that's one example of how a tool
14:30like Docker contributes to the DevOps
14:32culture.
14:34We will now see how to get started with
14:36Docker.
14:37Now, the way Docker is packaged today is
14:39a little different from the early days.
14:41So, let's clear that up before we
14:43install anything.
14:44In the past, Docker came in two
14:46editions, the community edition and the
14:49enterprise edition. The community
14:51edition was the free set of Docker
14:53products, and the enterprise edition was
14:55the certified supported container
14:57platform that came with enterprise
14:59add-ons like image management and image
15:01security, and a universal control plane
15:04for managing and orchestrating container
15:06runtimes. Of course, those came with a
15:09price.
15:10That split doesn't exist anymore. So,
15:12back in November 2019, Docker sold the
15:15enterprise edition to a company called
15:17Mirantis, and it's now sold as the
15:19Mirantis container runtime. That's a
15:22separate product from Docker.
15:24So, when you read older blog posts that
15:26mention Docker EE or Docker Enterprise
15:29Edition or compare Docker CE versus EE,
15:32that's the history. Those terms don't
15:34appear on Docker's site anymore.
15:38What you will see today is a free open
15:40source piece called Docker Engine plus a
15:43set of subscription tiers around it. So,
15:45Docker Engine itself, the CLI you type
15:47Docker and the daemon that does the
15:49work, Docker D is still free and open
15:52source.
15:53That's the part you install on a Linux
15:55server and that's what we'll use
15:57throughout this course.
15:59The subscription side wraps around
16:01Docker Desktop and Docker Hub and Docker
16:03offers four tiers. You have the
16:05personal, pro, team, and business.
16:08Personal is free and covers individuals,
16:10students, small teams, education, and
16:12non-commercial open source.
16:15Teams, pro, team, and business are paid.
16:19So, pro is for individual developers who
16:20want more from Docker Desktop and Docker
16:23Hub. Team for small teams that need
16:25collaboration features and business is
16:27for enterprises that need single
16:29sign-on, a hardened desktop, and image
16:32access management.
16:34Worth knowing if you work in a larger
16:36company because Docker Desktop on
16:38machines used for commercial work at
16:40companies above a certain size needs a
16:43paid subscription.
16:45So, for this course, the free path
16:47covers everything we need. The free
16:49Docker Engine is available on Linux,
16:51Mac, Windows, and on cloud platforms
16:53like AWS or Azure.
16:55In the upcoming demo, we'll take a look
16:57at how to install and get started with
16:59Docker on a Linux system. Now, if you
17:01are on Mac or Windows, you have two
17:03options, either install a Linux VM using
17:06VirtualBox or some kind of
17:07virtualization platform and then follow
17:09along with the upcoming demo, which is
17:12really the easiest way to get started
17:14with Docker. The second option is to
17:16install Docker Desktop for Mac or Docker
17:19Desktop for Windows, which are native
17:21applications. So, if that is really what
17:23you want, then check out the Docker for
17:25Mac and the Docker for Windows sections
17:27towards the end of this course to get
17:29yourselves set up and then head back
17:31here. Okay, so let's now head over to
17:34the demo where we'll take a look at how
17:36to install Docker on a Linux machine.
17:39Okay, we're now going to see how to
17:41install Docker on a
17:43Linux VM. So, here I have my Ubuntu VM.
17:47I'm logged into it and on the right I
17:49have a browser open. So, I'm going to go
17:50into docs.docker.com.
17:53And I'm going to go into manuals. And
17:56here on the left I have a few sections.
17:58So, there's Docker Desktop which we'll
18:00look at later. First, I'm going to go to
18:03Docker Engine and we'll see how to
18:05install Docker Engine on my Ubuntu VM.
18:07So, I'm going to keep it super simple in
18:09this first demo.
18:11Later on we're going to see what Docker
18:12Desktop is. So, Docker Desktop is
18:14basically
18:15a set of tools that are around Docker
18:17Engine. But, in this first demo I want
18:19to keep things super simple so you
18:20understand Docker without any anything
18:23else, right? So, we're just going to
18:24install Docker Engine. That's the first
18:26step. So, my system is Ubuntu so I'm
18:28going to select Ubuntu. And here I have
18:30my instructions on the right. So, let's
18:32read through this. So, at first it says
18:34to get started with Docker Engine on
18:36Ubuntu, make sure you meet the
18:37prerequisites. And there are
18:39a couple of prerequisites around
18:40firewall limitations. So, Docker is only
18:43compatible with IP tables and NFT and IP
18:44tables legacy.
18:46So, rules created with NFT are not
18:47supported. So, you can just read through
18:49those.
18:50Then the first requirement is that you
18:52need to be on a 64-bit version of one of
18:54these Ubuntu systems, right? So, these
18:56are the different versions available.
18:57Let's see where we are. So, if I go to
19:00my Ubuntu VM and run the cat command
19:02/etc/
19:04*release*.
19:06It's going to display the details of my
19:08VM. So, I can see that it's an Ubuntu
19:10distribution and it's 24.04
19:13noble version, right? And if I go here
19:15in the documentation page, I can see
19:16that this is a supported version. So,
19:18that's great. Next,
19:20I want to see what architecture I'm on.
19:22So, I should be on a 64-bit version of
19:23the OS.
19:25For this, we're going to run the D
19:27package command and the option print
19:30architecture.
19:31And I can see that I'm on an arm64
19:34version and I can see that that's
19:36supported. All right, so the
19:37prerequisites are good.
19:38Uh the next step is to uninstall any old
19:41versions.
19:42So, there are a bunch of packages that
19:43are going to get installed when you
19:44install Docker and we'll make sure that
19:46your system does not already have one of
19:47these. Now, remember,
19:49you want to be careful if you're running
19:50on an existing VM that is probably
19:52already in production with some other
19:54things already installed. So, you might
19:56want to be careful in that situation
19:57because this is a new VM. I'm just going
19:58to run this command and I can see that
20:01there are no packages that are installed
20:02already.
20:04The next step is to install using the
20:05app repository. So, the first thing is
20:07to set up the Docker's app repositories.
20:09I'm going to copy this command. As you
20:11can see, it's going to do an app update
20:12first and then install the certificates
20:14and then download the latest version of
20:17the Docker package
20:19and then make that executable and
20:21install it. So, I'm just going to copy
20:23that and run that those set of commands.
20:29Okay, when it's asking me for
20:30confirmation, I'm going to say yes.
20:38Okay, so that's done.
20:40And as the next step, we're going to
20:41install the latest version by running
20:43the app install command.
20:46Now, as you can see, it installs a bunch
20:47of things. So, there's the Docker CE,
20:48which is the community edition. There's
20:50the CE CLI. Then there's the containerd.
20:52We're going to discuss some of these
20:53later about Docker Compose and and build
20:56X plugins later in this course. So, for
20:57now, I'm just going to proceed with the
20:59installation.
21:07Okay, so that's completed.
21:09The next step is to verify that it's
21:11running. So, I'm going to copy this
21:12command.
21:13I'm going to run the system cuddle
21:15status docker command and it tells me
21:16that the status is now active and
21:18running.
21:20Perfect.
21:21Okay, I don't need to run this the next
21:23command. So, I'm just going to verify
21:24the installation is successful by
21:26running the hello world image. I'm going
21:27to copy this.
21:29Run that. So, in this case, what it's
21:31doing is it's pulling the hello world
21:33docker image from docker hub and it's
21:35going to run that
21:37an instance of that locally. So, here it
21:39is. It's downloaded the new image and
21:41there's a message hello from docker. And
21:43that means it's successfully installed.
21:46We now look at some of the docker
21:47commands.
21:48At the end of this lecture, you will go
21:50through a hands-on quiz where you will
21:52practice working with these commands.
21:54Let's start by looking at the docker run
21:56command. The docker run command is used
21:58to run a container from an image.
22:01Running the docker run engine x command
22:03will run an instance of the engine x
22:06application on the docker host if it
22:07already exists. If the image is not
22:09present on the host, it will go out to
22:11docker hub and pull that image down. But
22:14this is only done the first time. For
22:16subsequent executions, the same image
22:19will be reused. Now, one heads-up before
22:21we go further, docker hub limits
22:24unauthenticated pulls to 100 every 6
22:27hours per IP address.
22:29You log in with docker login, that goes
22:31up to 200 every 6 hours on the free
22:33personal tier and unlimited on the paid
22:36pro team or business plans. So, if you
22:38start hitting too many requests
22:40errors during this lesson, that's why
22:43login or use a paid account for CI work.
22:46The docker PS command lists all running
22:49containers and some basic information
22:51about them, such as the container ID,
22:53the name of the image we used to run the
22:55container, the current status, and the
22:56name of the container. Each container
22:58automatically gets a random ID and name
23:00created for it by docker, in this case
23:02silly sammich. To see all containers
23:05running or not use the dash a option.
23:07This outputs all running as well as
23:09previously stopped or exited containers.
23:12We'll talk about the command and port
23:14fields shown in this output later in
23:16this course.
23:17For now, let's just focus on the basic
23:19commands. To stop a running container
23:21use the Docker stop command, but you
23:23must provide either the container ID or
23:25the container name in the stop command.
23:27If you're not sure of the name, run the
23:29Docker PS command to get it. On success,
23:31you will see the name printed out and
23:33running Docker PS again will show no
23:35running containers. Running Docker PS A
23:38flag however, shows the container silly
23:40sammich and that it is in an exited
23:43state a few seconds ago. Now, what if we
23:45don't want this container lying around
23:47consuming space? What if we want to get
23:49rid of it for good? Use the Docker RM
23:51command to remove a stopped or exited
23:54container permanently. If it prints the
23:56name back, we are good. Run the Docker
23:58PS command again to verify that it is no
24:01longer present. Good. But, what about
24:04the Engine X image that was downloaded
24:06at first? We're not using that anymore.
24:08So, how do we get rid of that image? But
24:10first, how do we see a list of images
24:12present on our host? Run the Docker
24:14images command to see a list of
24:16available images and their sizes.
24:18On our host, we have four images: Engine
24:20X, Redis, Ubuntu, and Alpine. We will
24:23talk about tags later in this course
24:25when we discuss images. To remove an
24:27image that you no longer plan to use,
24:30run the Docker RMI command. Remember,
24:32you must make sure that no containers
24:34are running off of that image before
24:36attempting to remove the image. You must
24:38stop and delete all dependent containers
24:40to be able to delete an image.
24:43When we ran the Docker run command
24:44earlier, it downloaded the Ubuntu image
24:46as it couldn't find one locally. What if
24:48we simply want to download the image and
24:50keep it? So, when we run the Docker run
24:52command, we don't want to wait for it to
24:54download. Use the Docker pull command to
24:56only pull that image and not run the
24:58container. So, in this case, the docker
25:00pull
25:01uh Ubuntu command pulls the Ubuntu image
25:03and stores it on our host.
25:05The same Docker Hub rate limit caveat
25:08applies here. If you're pulling a lot,
25:10log in first. Let's look at another
25:12example. Say you were to run a Docker
25:14container from an Ubuntu image. When you
25:17run the docker uh run Ubuntu command, uh
25:19it runs an instance of the Ubuntu image
25:21and exits immediately. If you were to
25:23list the running containers, you
25:24wouldn't see the container running. If
25:26you list all containers, including those
25:28that are stopped, you will see that the
25:30new container you ran is in an exited
25:32state. Now, why is that? Unlike virtual
25:35machines, containers are not meant to
25:38host an operating system. Containers are
25:40meant to run a specific task or process,
25:43such as to host an instance of a web
25:45server or an application server or a
25:47database or simply to carry out some
25:50kind of computation or analysis task.
25:53Once the task is complete, the container
25:55exits. A container only lives as long as
25:57the process inside it is alive.
26:00If the web service inside the container
26:01is stopped or crashed, then the
26:03container exits. This is why, when you
26:06run a container from an Ubuntu image, it
26:08stops immediately. Because Ubuntu is
26:10just an image of an operating system
26:12that is used as the base image for other
26:15applications. There is no process or
26:17application running in it by default. If
26:20the image isn't running any service, as
26:22is the case with Ubuntu, you could
26:23instruct Docker to run a process with
26:25the docker run command.
26:27For example, a sleep command with a
26:29duration of 5 seconds. When the
26:31container starts, it runs the sleep
26:33command and goes into sleep for 5
26:34seconds, after which the sleep command
26:36exits and the container stops. What we
26:39just saw was executing a command when we
26:41run the container, but what if we would
26:42like to execute a command on a running
26:44container? For example, when I run
26:46the docker uh ps command, I can see that
26:49there is a running container which uses
26:51the Ubuntu image, and uh sleeps for 100
26:54seconds.
26:55Let's say I would like to see the
26:56contents of a file inside this
26:59particular container, I could use the
27:00Docker exec command to execute a command
27:03on my Docker container, in this case to
27:05print the contents of the {slash} etc.
27:07{slash} hosts file. That's also how you
27:09debug or poke around inside a running
27:11container, change a config, check a log,
27:13run a quick query.
27:15Finally, let's look at one more option
27:17before we head over to the practice
27:19exercises.
27:20I'm now going to run image I developed
27:22for a simple web application.
27:25The repository name is codecloud {slash}
27:27simple web app. It runs a simple web
27:30server that listens on port 8080.
27:32When you run a Docker run command like
27:34this, it runs in the foreground or in
27:36attached mode, meaning you will be
27:38attached to the console or the standard
27:40out of the Docker container, and you
27:43will see the output of the web service
27:44on your screen.
27:46You won't be able to do anything else on
27:47this console other than view the output
27:50until this Docker container stops. It
27:52won't respond to your inputs. Press the
27:54control C combination to stop the
27:56container, and the application hosted on
27:58the container exits, and you get back to
28:00your prompt. Another option is to run
28:02the Docker container in detached mode by
28:04providing the {dash} D option. This will
28:06run the Docker container in the
28:07background, and you will be back to your
28:09prompt immediately. The container will
28:11continue to run in the back end. Run the
28:13Docker ps command to view the running
28:15container. Now, if you would like to
28:17attach back to the running container
28:19later, run the Docker attach command and
28:21specify the name or ID of the Docker
28:23container. Now, remember, if you're
28:25specifying the ID of a container in any
28:27Docker command, you can simply provide
28:29the first few characters alone, just
28:31enough so it is different from the other
28:33container IDs on the host. In this case,
28:35I just typed the first five characters.
28:37Now, don't worry about accessing the UI
28:39of the web server. For now, we will look
28:41more into that in the upcoming lectures.
28:44For now, let's just understand the basic
28:46commands. We will now get our hands
28:48dirty with the Docker CLI. So, let's
28:51take a look at how to access the
28:53practice lab environments next.
28:56Okay, so the next thing that we're going
28:57to do is run a Docker container, run our
28:59first container. So, if you go to uh
29:02hub.docker.com,
29:05you'll find images that you can run. So,
29:07this is Docker Hub. This is Docker's
29:08central repository of all
29:11containers or all images that can be
29:13used to run containers. And if you see
29:15here, there are all sorts of images
29:16available. For example, for machine
29:18learning and AI, you have TensorFlow,
29:19Py- PyTorch.
29:21You have an image for Python. So, there
29:23are images available for almost anything
29:24that you can think of, for any versions
29:26of those softwares or applications.
29:29There are web servers, there's operating
29:31system uh base images like Alpine. Uh
29:33there are databases like Postgres,
29:35MySQL, MongoDB, and there's images for
29:38Grafana. So, almost anything that you
29:40can think of
29:41would probably have Docker image here.
29:43So, we're going to start simple. So,
29:45we'll go to operating systems, and we'll
29:46select one of these operating systems.
29:48So, there's Ubuntu, Debian. So, I'm
29:50going to go with Alpine. So, Alpine is a
29:52minimal
29:53Docker image
29:54based on Alpine Linux. So, Alpine Linux
29:56is a
29:58minimal operating system. And as you can
30:00see, its size is uh 3.6 MB. So, that's a
30:02super lightweight uh image. And all you
30:05need to do is copy this name from here,
30:08and we're going to run an instance of
30:10this image. So, back in my terminal, I'm
30:11going to run a Docker run command and
30:14paste the name of the image, which is
30:16Alpine. And the first time that I'm
30:18running this, it's going to download the
30:21uh layers of the image. And because it's
30:23so small, it's less than 5 MB, it's
30:24downloaded that in a matter of seconds.
30:27So, I now have the image locally, and
30:28it's already run it. Now, because this
30:30is an operating systems image, it's a
30:32base image, it doesn't have any
30:33application running on it currently. So,
30:35it just exits immediately, which is why
30:37I'm not able to see that, and I'm back
30:38on my terminal.
30:40So, I could run commands inside this
30:41container. So, I could run the docker
30:44run command again and I can
30:47run a command such as cat /etc/
30:50star release star. So, it's going to
30:52print So, there is nothing much I could
30:54do with it. What I could do is maybe run
30:57an application or a program that's
30:58inside the image already. So, I'll
31:01probably run a sleep command and sleep
31:03for say 10 seconds. And what's going to
31:05happen is it's going to create container
31:08from the image and then it's going to
31:10invoke the sleep command and it's going
31:11to sleep for 10 seconds. And for those
31:13for that 10 seconds, I'm going to be on
31:15on the terminal and now I'm Now, it's
31:16done and I'm back. Now, another thing
31:17that we could do is maybe we can explore
31:19another application maybe like a a web
31:22server. So, if I go back to the hub and
31:24if I go to web servers, I have a bunch
31:26of different web servers here. I'm just
31:27going to pick engine X for now and you
31:30can see that there are all sorts of
31:31different versions of engine X available
31:33here. There's slim versions and alpine
31:35versions and for now I'm just going to
31:37be look more into tags and versions
31:39later in the course. For now, I'm just
31:40going to copy the name from here. I'm
31:42going to run an instance of the engine X
31:44container. And again, what it's going to
31:47do now is it's going to pull the images
31:48needed to run an instance locally. So,
31:50it's going to do that and this is a
31:52slightly heavier image. So, it's about
31:5434 MB. So, it's going to download that
31:56and it's downloaded that and it's
31:57immediately run the engine X web server.
31:59So, the engine X web server is now
32:01running
32:02on on this host.
32:05Okay, we'll now see how to run a
32:06container in the background. So, earlier
32:08when I ran the docker run engine X
32:10command,
32:12it immediately started the engine X
32:14container on the foreground. So, I'm
32:15kind of in that stuck in that terminal.
32:18To get out of it, I'm going to do
32:19control C and now now I'm back to my
32:21terminal, but it's also killed that
32:23server as you can see here. So, the
32:25solution to that is to run it in the
32:27background. So, I'm going to do a docker
32:28run engine X, but I'm also going to add
32:30a {dash}d flag and what and what that's
32:33going to do is it's going to run the
32:34container in the background. So, now
32:36it's running, and this is the container
32:39ID. This is This is a long format of the
32:41ID, but you can refer to the container
32:43with the short form as well.
32:45Now, to list the running containers, you
32:47could do a docker PS command, and it
32:49lists all the running containers. As you
32:50can see here, this is the first
32:51container, and this is the ID. This is
32:53the short form of the ID, which is the
32:55first part of this long form ID that you
32:57see here. The image is nginx. It has an
33:00internal entry point command that it's
33:02run to run the server itself. It's been
33:05up for 21 seconds, and it's exporting
33:08port 80. So, the actual server itself is
33:10running on port 80. Again, we'll see
33:12later how to access this web server. And
33:14then it's also got a a funny name to it.
33:16It's called adoring uh Zukowski. And
33:20every container kind of gets this
33:23kind of nickname. So,
33:25next, to stop this container, you could
33:27do a docker stop command, and either
33:29specify this container ID or this name,
33:31or just even just the first four
33:32characters of this ID. Anything that can
33:34uniquely identify this container. So,
33:36I'm going to do a docker stop dbb4, and
33:38it's going to return the same ID that I
33:40gave. That means it's killed. So, if I
33:42do a docker PS command, I no longer see
33:44any container running. Now, how do I see
33:47the killed containers? So, I could do a
33:49docker PS, and do a {dash} A to list all
33:51containers, and now I see
33:53all the containers that I have run. So,
33:56the Alpine containers that I ran earlier
33:57with the sleep commands, all of them are
33:59here. And then I also see the latest
34:01container that I just ran, which exited
34:02about a minute ago, and it's just been
34:0414 seconds that it's exited. So, now how
34:08do I get rid of all of these? I have all
34:10of these containers that are in an
34:11exited state. That's just staying there.
34:13They're just living on my system. How do
34:14I delete and get rid of them? For that,
34:16I could do a docker RM command.
34:18So, I do a docker RM, and then specify
34:20the name of the container.
34:22And this is again again going to go
34:24ahead with just the first four letters,
34:25or I could provide
34:27multiple containers at the same time.
34:28So, I could do af6a.
34:31That's the first container, and then I
34:32have this 6F, that's the second
34:34container. And then there's the 2E0E,
34:37that's the third one. So, we're going to
34:38run all of that and it's going to remove
34:40all of them at once.
34:42Now, when I do a docker ps -a, I see
34:44that there's these many remaining. And I
34:47can just go ahead and uh remove all of
34:48them one after the other.
34:51Okay, now we're going to look at images.
34:53So, when we ran the docker run command
34:56earlier, say docker run nginx,
35:00we learned that it downloaded the docker
35:03image for nginx
35:05web server and it it ran it. Now, I
35:08could run the docker images command to
35:10view the images. So, currently I have
35:12two of them. I have the Alpine latest,
35:14which we downloaded earlier, and as you
35:16can see the size of it's less than 5 MB,
35:18and then you have the nginx image, which
35:20is about 64 MB. Now, to delete these
35:22images, I could run the docker rmi
35:25command. So, to delete the containers,
35:27it's the rm command, and to delete
35:28images, it's the rmi command. So, I'm
35:30going to do a docker rmi and then
35:32specify the name of the image. In this
35:34case, it's Alpine uh latest. And if I
35:36just type Alpine and hit a tab, it's
35:38going to auto-fill for me.
35:40When I run it, it says it's deleted. So,
35:42it first untags the image and then then
35:44deletes it. And it returns the ID of
35:47that uh image. So, if I do a docker
35:48images again,
35:50I see that
35:52it's gone. Now, if I try to delete the
35:54nginx image, I'm going to do a docker
35:56rmi command again and then specify
35:58nginx, then hit enter. It now says that
36:01uh there is an error and it says unable
36:02to delete the nginx image because
36:05there's a container that is using it,
36:06that's referencing it. So, if you look
36:08here, uh earlier if you means this
36:09information section here, it says U
36:11means in use. So, it's just giving you a
36:13hint here that this image is already in
36:15use.
36:16So, if we look at the docker ps command,
36:18we see that there's nothing running. So,
36:19there's no running container that's
36:21using this image, but if you do a docker
36:22ps -a command, we'll see all the exited
36:25images as well. And then here we see
36:27that there's this
36:28container that's using the engine x
36:29image, which is why we're unable to
36:31delete that image. So, first we need to
36:33remove the container, so I'm going to do
36:34a docker rm 292e. That's the first four
36:37characters of the container ID.
36:39So, I'm now going to verify that there
36:40are no containers running or exited
36:42that's using this image. And now I'm
36:44going to do a docker
36:45rmi
36:47engine x
36:48command, and
36:49that should ideally remove the image.
36:52So, now I'm in a fully clean state. So,
36:54if I do a docker ps, docker ps -a, or
36:58docker images, I don't see any anything
37:01whatsoever.
37:02Another command that could come handy if
37:04you have a lot of containers and a lot
37:05of images, and if you're just playing
37:07around,
37:08is the docker system prune command. So,
37:11if you run the docker system prune
37:12command, what it's going to do is going
37:14to it's going to stop all the running
37:15containers,
37:16and it's going to remove all the stopped
37:18containers, it's going to remove all the
37:19networks uh not used by at least one
37:21container, it's going to remove all
37:23dangling images, and remove unused build
37:25cache. So, it's going to kind of clear
37:26out your system. So, if you are playing
37:28around in a development environment, and
37:29if you have a lot of running containers
37:31and images, and if you want to kind of
37:32clean out your system, you could run
37:33this docker system prune command, and
37:34it's just going to go through and delete
37:36and remove all the containers and images
37:38that are not used. And in this case,
37:40because I didn't have any containers, it
37:42says total reclaimed space is zero
37:43bytes, but if you did have some, it's
37:45going to help you reclaim space.
37:48We will now look at some of the other
37:50docker run commands.
37:51In this first part, let's talk about
37:53image tags. We learned that we could run
37:55a Redis container with a simple run
37:57command, which gives us the latest
37:59version of Redis, currently version
38:018.6.1.
38:03But what if uh we want to run another
38:05version, like say an older uh version
38:07such as 7.4? Well, you specify the
38:10version separated by a colon. This is
38:11called a tag. In that case, docker pulls
38:14an image of the 7.4 version of Redis and
38:17runs that. Also notice that if you don't
38:19specify any tag, uh like in the first
38:22command, Docker considers the default
38:24tag to be latest. The latest tag points
38:27to the latest version of that software,
38:29which is governed by the authors of that
38:31software. So, as a user, how do you find
38:33information about these versions and
38:35what is latest? Over at Docker Hub,
38:38look up an image and you'll find all the
38:40supported tags in its description. Each
38:42version of the software can have
38:43multiple short and long tags associated
38:46with it. For example, version 8.6.1 also
38:49carries the latest tag today. Now, every
38:52time we pull a new version of an image,
38:54Docker stores it on the host as a
38:56separate entry. So, if I pulled both
38:58Redis 8 6.1 and Redis 7.4 earlier,
39:02they're both sitting there on my host.
39:04To see all the images I have locally, I
39:06run the Docker images command and it
39:08gives me a table, the repository, the
39:10tag, and the image ID for each one. And
39:14if I want to clean up a specific version
39:16that I no longer need, I run Docker RMI
39:19followed by the exact tag. For example,
39:22Docker RMI Redis 7.4.
39:25That removes just that tagged image and
39:27leaves the other versions alone.
39:30Now, one quick note on the latest tag
39:32before we move on. The latest tag is
39:34convenient for quick experiments and
39:36trying things out, but in production,
39:38you should always pin to a specific tag,
39:41something like Redis 7
39:43for Alpine.
39:45The reason is that latest is a moving
39:47target. The day you redeploy, the image
39:49authors may have pushed a new version
39:52and your container quietly upgrades
39:53under you, sometimes with breaking
39:55changes. A pinned tag gives you the
39:58exact same image every time and you
40:00decide when to bump the version, not the
40:02upstream maintainers.
40:05Now, let's look at inputs. I have a
40:07simple prompt application that, when
40:09run, asks for my name. And on entering
40:11my name, it prints a welcome message. If
40:14I were to dockerize this application and
40:16run it as a Docker container, it
40:18wouldn't wait for the prompt. It just
40:20prints whatever the application is
40:21supposed to print on standard out.
40:23That's because by default, the Docker
40:24container does not listen to standard
40:26input. Even though you're attached to
40:28its console, it isn't able to read any
40:30input from you. It doesn't have a
40:31terminal to read inputs from. It runs in
40:33a non-interactive mode. If you'd like to
40:35provide your input, you must map the
40:37standard input of your host to the
40:39Docker container using the dash i
40:41parameter.
40:43The dash i parameter is for interactive
40:45mode, and when I input my name, it
40:47prints the expected output. But, there's
40:50something still missing, the prompt.
40:52When we ran the app at first, it asked
40:54us for our name, but when Dockerized,
40:56that prompt is missing, even though it
40:58seems to have accepted my input. That's
41:01because the application prompts on the
41:03terminal, and we have not attached to
41:05the container's terminal. For this, use
41:07the dash t option as well. The dash t
41:09stands for pseudo terminal. So, with the
41:11combination of dash i and dash t, we're
41:14now attached to the terminal as well as
41:15in interactive mode on the container.
41:18Now, you might be wondering, "Why would
41:20I ever use dash i alone or dash t alone
41:23if dash i t is the real combination?"
41:26Well, they both have honest use cases.
41:28They're just narrower. The dash i flag
41:30alone is the right choice when I'm
41:32piping data into the container. I want
41:34standard input connected so the
41:36container can read my data, but I don't
41:38need a terminal because I'm not typing
41:40anything. The classic example is piping
41:43a SQL file into a Postgres container. If
41:46I tried dash i t here, Docker would
41:49actually refuse because pipes aren't
41:51terminals and dash t insists on one. So,
41:54for any kind of streaming pipeline, dash
41:57i alone is exactly what you want. The
42:00dash t flag alone is for when I want
42:02colored output or progress bars, but I
42:04don't need to type anything. Programs
42:07check whether they're attached to a
42:08terminal to decide whether to emit
42:10colors and pretty formatting. With dash
42:12t, the program thinks it's talking to a
42:14real terminal and gives me the rich
42:16output.
42:17And without {dash} i,
42:19I skip wiring up the keyboard I'm not
42:21actually using.
42:22In practice, I reach for {dash} it most
42:24of the time.
42:25{Dash} i alone when I'm piping data in.
42:29Now let's look at port mapping or port
42:31publishing
42:32on containers.
42:33Let's go back to the example where
42:36we run a simple web application in a
42:37Docker container on my Docker host.
42:40Remember the underlying host where
42:42Docker is installed is called the Docker
42:44host or Docker engine. When we run the
42:46containerized web application, it runs
42:48and we can see that the server is
42:51running. But how does a user actually
42:53access my application? My application is
42:55listening on port 5000, so I could
42:57access it on port 5000. But what IP do I
43:00use to reach it from a web browser?
43:02There are two options. One is to use the
43:03IP of the Docker container. Every Docker
43:05container gets an IP assigned by default
43:08like the one here.
43:09But remember this is an internal IP and
43:11is only accessible within the Docker
43:13host.
43:14So if you open a browser from within the
43:16Docker host, you can go to that
43:17container IP on port 5000. But since
43:20this is an internal IP, users outside
43:23the Docker host cannot reach it. For
43:25that, we use the IP of the Docker host,
43:27the
43:28the one you see here. But for that to
43:30work, you must have mapped a port inside
43:32the Docker container to a free port on
43:34the Docker host. For example, if I want
43:36users to reach my application through
43:37port 80 on my Docker host, I map port 80
43:40of the host to port 5000 on the
43:42container using the P parameter. And so,
43:45the user can now reach my application by
43:47going to that host IP on port 80. And
43:50all traffic on port 80 of my Docker host
43:53gets routed to port 5000 inside the
43:55container. This way, you can run
43:56multiple instances of your application
43:59and map them to different ports on the
44:01Docker host or instances of different
44:03applications on different ports. For
44:05example, you could run an instance of
44:07MySQL listening
44:08on its default port 3306 and another
44:11instance of MySQL on port 8306. So, you
44:14can run as many applications like this
44:16and map them to as many ports as you
44:18want. And of course, you cannot map to
44:20the same port on the Docker host more
44:22than once. We'll discuss more about port
44:24mapping and networking of containers in
44:26the network lesson later on.
44:29Now, let's look at how data is persisted
44:31in a Docker container. Let's say you
44:33were to run a MySQL container. When
44:35databases and tables are created, the
44:37data files are stored in var/lib/mysql
44:40inside the container. Remember, the
44:42Docker container has its own isolated
44:44file system and any changes to any files
44:47happen within the container. Let's
44:48assume you dump a lot of data into the
44:51database. What happens if you were to
44:53delete the MySQL container and remove
44:55it? As soon as you do that, the
44:57container along with all the data inside
44:59it gets blown away, meaning all your
45:01data is gone.
45:03If you'd like to persist data, you'd
45:05want to map a directory outside the
45:07container on the Docker host to a
45:10directory inside the container. In this
45:12case, I create a directory called
45:14opt/data dir and map that to
45:17var/lib/mysql
45:19inside the Docker container using the
45:21dash v flag specifying the directory on
45:23the Docker host followed by a colon and
45:25the directory inside the container. This
45:27way, when the Docker container runs, it
45:29implicitly mounts the external directory
45:30to a folder inside the container. All
45:32your data will now be stored in the
45:34external volume at
45:36data dir and will remain even if you
45:39delete the container. Now, a quick note
45:41on the dash v form versus the dash dash
45:44mount form.
45:45Modern Docker has a more explicit syntax
45:48called the dash dash mount form. The
45:50same bind mount is rewritten using key
45:52value pairs, type, source, and target
45:54instead of a single colon separated
45:56string. Both work. The dash v form is
45:59not deprecated, but the dash dash mount
46:02form makes the type of mount explicit,
46:04bind, volume, or tempfs, which becomes
46:07more useful as your setup gets more
46:09complex.
46:11The Docker ps command is good enough to
46:13get basic details about containers like
46:15their names and IDs, but if you'd like
46:17to see additional details about a
46:18specific container, use the Docker
46:20inspect command and provide the
46:22container name or ID. It returns all the
46:25details of a container in JSON format,
46:27state, mounts, configuration data,
46:29network settings, and more. Remember to
46:31use it when you need to find details on
46:34a container. And finally, how do we see
46:36the logs of a container we ran in the
46:38background? Uh for example, um I ran my
46:41simple web application using the {dash}d
46:43parameter, and it ran the container in
46:45detached mode. How do I view the logs,
46:47which happen to be the contents written
46:49to the standard out of that container?
46:51Use the Docker logs command and specify
46:53the container ID or name. An example
46:55output might look like this. Well,
46:57that's it for this lesson. Head over to
46:59the challenges and practice working with
47:01Docker commands.
47:04>> [music]

About this transcript

This page contains the full transcript of Docker Explained for Absolute Beginners [2026] by KodeKloud, generated from the public captions YouTube serves with the video. The transcript has 8,858 words across 1,364 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.