April 24, 2026 • 21 mins
In this lesson, you’ll learn about: Docker basics, images vs containers, and how Docker builds applications1. Your First Docker Run (Hello World)
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
- You start by running a simple container using Docker
- Behind the scenes:
- Docker CLI sends a command
- Docker Daemon processes it
- Image is pulled from Docker Hub
- Key insight:
- Docker only downloads missing layers → future runs are much faster
- Immutable (cannot be changed)
- Contains:
- File system
- Dependencies
- Configuration
- A live instance of an image
- Can be started, stopped, deleted
- Using Alpine Linux (~2MB):
- Run a container
- Make changes inside it
- Stop the container
- Result:
- Changes are lost
- Containers are ephemeral by design
- Main public registry for images
- Contains:
- Official images (trusted)
- Community images
- Example:
- python:3.11
- nginx:latest
- Help you:
- Control versions
- Ensure consistency
- Docker integrates with tools like:
- GitHub
- Features:
- Automated builds
- Webhooks
- Continuous delivery pipelines
- Instead of manual setup, use:
- Dockerfile = Recipe
- Defines:
- Base image
- Dependencies
- Commands to run
- Benefits:
- Reproducible builds
- Version-controlled environments
- Easy collaboration
- Images are built in layers:
- Each instruction in a Dockerfile = layer
- Advantages:
- Reuse unchanged layers
- Faster builds
- Smaller downloads (only differences)
- Enables:
- Rapid development
- Consistent environments
- Easy deployment
- Foundation for:
- Microservices
- CI/CD pipelines
- Cloud-native apps
- Images = immutable blueprints
- Containers = running instances
- Docker Hub provides ready-to-use images
- Dockerfiles make builds repeatable and scalable
- Layers make Docker fast and efficien
You can listen and download our episodes for free on more than 10 different platforms:
https://linktr.ee/cybercode_academy
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Imagine spending like three weeks perfectly configuring a web server
on your laptop. You know, you have the exact right
versions of Python, the precise system libraries, literally every environment
variable tuned flawlessly.
Speaker 2 (00:14):
Oh yeah, the absolute dream setup, right.
Speaker 1 (00:17):
And then you push it to production. You're ready to celebrate,
and you just watch the entire application instantly crash.
Speaker 2 (00:22):
It's the worst feeling in the world.
Speaker 1 (00:24):
Why does it happen because the production server is running
a slightly older version of Linux, or maybe there's a
conflicting background process. That used to be the daily inescapable
nightmare of software development.
Speaker 2 (00:37):
Yeah, it was total chaos. I mean, you couldn't just
magically teleport your software. You had to take it apart,
pack it, ship it, and then basically try to rebuild
it in a completely different.
Speaker 1 (00:45):
Environment exactly, And it inevitably led to that classic developer
excuse right, Well it worked on my machine.
Speaker 2 (00:51):
Oh I've said that more times than I care to admit.
Speaker 1 (00:54):
We all have. But then you step into the world
of Docker and suddenly that chaotic movie day is just gone.
We're looking at this landscape of standardized shipping containers. It's clean,
it's isolated and well it just works.
Speaker 2 (01:09):
It really does. It completely changed the industry standard.
Speaker 1 (01:12):
Welcome to the deep dive. Our mission today is to
completely demystified Docker, and we are going to do it
with absolutely no screens required. We're going to guide you
step by step through an audio show and tell to
understand exactly how Docker's core tools come together.
Speaker 2 (01:28):
Yeah, because the goal here isn't just to throw buzzwords
at you. Whether you're a student of programming, maybe moving
into cybersecurity, or just a self taught tech enthusiast, you
really need to understand the underlying mechanisms.
Speaker 1 (01:39):
Right like what's actually happening behind the.
Speaker 2 (01:41):
Curtain, exactly what exactly happens under the hood when you
spin up a container, how does the system isolate your code?
And you know, how do you engineer your own architecture
entirely from scratch?
Speaker 1 (01:53):
Okay, let's unpack this. Imagine you're opening up your terminal
right now, just a blank black screen with a blinking.
Speaker 2 (01:58):
Cursor, a very familiar say.
Speaker 1 (02:00):
To really grasp Docker, we have to start with the
simplest action imaginable. You take three words Docker run Hello world,
and you hit enter. In a few seconds, this friendly
greeting pops up on your screen.
Speaker 2 (02:14):
Right, it feels instant.
Speaker 1 (02:15):
But behind the scenes of those three little words, a
highly orchestrated four step sequence just kicked off.
Speaker 2 (02:22):
It really is a beautiful orchestration. When you hit enter
on that Docker run hello World command, the first invisible
step is communication. Okay, the Docker CLI, the command line
interface you just typed into, isn't actually doing the heavy
lifting there. It essentially acts as a rest client.
Speaker 1 (02:39):
Oh interesting, Yeah, it.
Speaker 2 (02:40):
Takes your command and sends a message to the Docker damon.
The damon is the actual engine, a background service that's
just running continuously on your machine.
Speaker 1 (02:48):
Wait, so the CLI is just the messenger knocking on
the daemon's door saying, hey, we need to run this
Hello World.
Speaker 2 (02:54):
Program precisely, which leads us a step two. The daemon
checks is local cash, first looks at your computer's hard
drive and realizes it doesn't actually have the files required
for this specific Hello World.
Speaker 1 (03:07):
Program, right, because it's a brand new setup exactly.
Speaker 2 (03:10):
So it reaches out to the internet, specifically to a
public registry called Docker Hub, and it pulls the image
down to your machine.
Speaker 1 (03:18):
Right. Hold on, So, if it's pulling an image, isn't
that just a standard Internet download. I mean, pulling an
entire operating system environment should take minutes and eat up
massive bandwidth, shouldn't.
Speaker 2 (03:29):
It You would think so, But no, it's drastically smarter
than a standard file download, and image is not one massive,
monolithic chunk of data. It's actually constructed from layers.
Speaker 1 (03:39):
Lawyers.
Speaker 2 (03:40):
Yeah, When Docker pulls an image, it communicates with the
registry to compare cryptographic hashes specifically saha, two, five, six
hashes of the layers you need against the layers you
might already have on your machine.
Speaker 1 (03:53):
Oh wow, So it's checking for exact matches, right.
Speaker 2 (03:55):
It only downloads the specific differences or diffs that are missing.
So if another project on your laptop already downloaded the
base Linux layer, doctor just skips downloading it again entirely.
Speaker 1 (04:06):
That is incredibly efficient. So once the demon has those
specific layers locally, it can't just let them sit there
on your hard drive, right, It has to actually execute them,
which transforms that static file into our running container. I
guess that would be step three.
Speaker 2 (04:20):
Spot on. That execution phase is where Docker's true power lies.
The demon takes that assembled image and creates the active.
Speaker 1 (04:29):
Container, so it's bringing it to life.
Speaker 2 (04:31):
Basically. Yeah. In this specific case, the Hello world image
is simply programmed to execute a tiny script that outputs
some text. But whether that text was generated by a
complex no JS application, a Python script, or just a
basic UNUX command, the Demon handles the execution environment perfectly.
Speaker 1 (04:50):
And the final step, step four, is just writing that output. Right.
The demon captures the standard output from the container's execution
and pipes it back to your CLI, printing the greeting
on your terminal screen. Yep.
Speaker 2 (05:01):
Four steps, request, pull, execute, output, all in a matter
of seconds.
Speaker 1 (05:06):
And if you were to say, hit the up arrow
in your terminal and run Docker run hello world a
second time, you'd notice it finishes almost instantaneously.
Speaker 2 (05:13):
Because it completely skips the network download in step two.
Speaker 1 (05:16):
Right, the demon checks locally, sees the image layers are
already sitting in its cash, and jump straight to creating
the container. It basically removes the Internet from the equation.
Speaker 2 (05:26):
It really highlights how fast containerization is. But notice how
we are strictly separating our vocabulary here.
Speaker 1 (05:34):
Oh true.
Speaker 2 (05:35):
Yeah, we mentioned downloading the image in step two and
running it to create a container in step three.
Speaker 1 (05:40):
Which is funny because people definitely use those words interchangeably
in casual conversation all the time. Yeah, but in reality
they are completely different concepts.
Speaker 2 (05:48):
They really are, And honestly, understanding the strict boundary between
an image and a container is like the single most
critical hurdle in mastering Docker.
Speaker 1 (05:57):
So how should we visualize the difference.
Speaker 2 (06:00):
Think of an image as a blueprint. It's a combination
of a file system and parameters. Basically, it's a package
that rolls up everything your application needs to run, the
source code, the run time engine, the system tools, system libraries,
all of it.
Speaker 1 (06:14):
But an image itself doesn't actually do anything right. It's
completely static.
Speaker 2 (06:19):
Entirely static. An image has absolutely no state once it's built.
It is immutable, it never ever changes. A container, on
the other hand, is the active running process spawn from
that static blueprint.
Speaker 1 (06:31):
Okay, I love this. So if I'm thinking like a developer,
the Docker image is basically the class definition in my
object oriented code, and the Docker container is an instance
of that class.
Speaker 2 (06:43):
That is a perfect analogy.
Speaker 1 (06:45):
Right, because you define the class once, writing all the rules,
the methods, and variables. But then you can spin up
as many unique, separate instances containers from that one class
as you want in your computer's memory.
Speaker 2 (06:57):
It maps perfectly. And the beautiful part is how this
architectural choice impacts your system resources. You know, you only
paid the disk space cost for the single image. Wait really, Yeah,
Let's say you have an image for a web server
that takes up fifty megabytes on your hard drive. You
could launch one container, or you could launch a thousand
active containers from that exact same image, and my hard.
Speaker 1 (07:17):
Drive doesn't suddenly lose fifty gigabytes of space. It still
only costs me that original fifty megabytes.
Speaker 2 (07:23):
Not a single byte more on your hard drive. Now.
Of course, each running container uses its own separate chunk
of RAM to handle its active computations, but the storage
footprint remains incredibly.
Speaker 1 (07:36):
Tiny, which actually brings up a massive question for me. Yeah,
we keep saying these containers are isolated, right, but if
a thousand containers are running on the exact same laptop,
sharing the exact same underlying hard drive and operating system,
how are they actually kept separate from each other? I mean,
for someone moving into cybersecurity, just saying it's isolated doesn't
(07:57):
really explain the mechanism that is.
Speaker 2 (07:58):
A vital distinction to me. Containers are not virtual machines. Okay,
a virtual machine literally emulates hardware. It pretends to be
a physical motherboard and CPU running a really heavy, completely
separate guest operating system.
Speaker 1 (08:11):
Right which takes forever to boot up.
Speaker 2 (08:13):
Exactly. Docker doesn't do that at all. Docker utilizes native
features built directly into the Linux kernel, primarily two mechanisms
called name spaces and C groups.
Speaker 1 (08:23):
Name spaces and C groups, so it's basically tricking the
processes into thinking they are alone.
Speaker 2 (08:27):
Precisely, name spaces dictate what a process can see. When
Docker creates a container, it wraps the process in a
new name space, so as far as the application inside
the container is concerned, it is the only process running
on the entire computer.
Speaker 1 (08:42):
Wow.
Speaker 2 (08:42):
Yeah, it has its own isolated network interface, its own
isolated filetree. Then, ce groups, which stands for control groups,
dictate what the process can use.
Speaker 1 (08:51):
Ah, so that's the resource limit exactly.
Speaker 2 (08:54):
It limits the container so it can only access say,
five hundred megabytes of RAM or ten percent of the CPU.
Speaker 1 (09:00):
So it's just process isolation running natively on your existing kernel.
That completely explains why they boot up in milliseconds instead
of the minutes. It takes to boot a virtual machine.
Speaker 2 (09:09):
It's incredibly lightweight.
Speaker 1 (09:10):
Well, let's solidify this immutability concept with a mental experiment
for the listener. Imagine you're back at your terminal. We
are going to run a different command, this time Docker
run elipine shesh oh.
Speaker 2 (09:20):
That's a fantastic exercise for context. Alpine is a very specific,
stripped down distribution of Linux.
Speaker 1 (09:27):
Super tiny, right.
Speaker 2 (09:29):
Extremely tiny. If we used a Buntu for this experiment,
you'd be pulling down tens of megabytes, but Alpine is
aggressively optimized. It's only about two or three megabytes in total.
It is incredibly fast, which makes it a total staple
in the Docker ecosystem.
Speaker 1 (09:46):
Okay, so you run that command and instantly your terminal
prompt changes. You are no longer navigating your Mac or
your Windows machine. Thanks to those name spaces we just
talked about, you have been seamlessly dropped into the command
line of a running Linux system, completely isolated from your
host computer.
Speaker 2 (10:04):
Right now, let's test that concept of immutability. You're inside
this Alpine container. You type l's ala to list the files,
and you see a standard Linux directory structure.
Speaker 1 (10:13):
Makes sense.
Speaker 2 (10:14):
You navigate to the home directory, and you decide to
create a brand new text file. You type touch my file.
You run the list command again and verify it's there.
You can see it, it exists.
Speaker 1 (10:23):
Okay. Then you type exit. The container immediately stops running.
You're back on your normal computer. Prompt. But wait, you
realize you forgot to do something, so you run the
exact same command again, doctor run alpine sha, and you're
back in. You navigate back to the home directory, you
look for your file and it is completely gone, poof vanished.
Speaker 2 (10:43):
And that is exactly what we mean when we say
containers are immutable. A container always starts as a perfect
carbon copy of the original image.
Speaker 1 (10:51):
But I made a file, where did it go?
Speaker 2 (10:53):
Any changes you make while the containers running, like creating
that text file or installing a new package, happen in
a te temporary, ephemeral layer.
Speaker 1 (11:01):
Ah. So it's not permanently written to the image. No.
Speaker 2 (11:04):
Never the exact moment the container stops, that temporary layer
is literally thrown in the trash. When you start a
new container from the image, it reverts entirely to its
pristine baseline state.
Speaker 1 (11:16):
It's like a hotel room. No matter what you do
during your stay, you move the chairs around, leave a
book on the nightstand, empty the mini bar. When you
check out, the cleaning crew resets the room to its
exact original floor plan for the very next guest.
Speaker 2 (11:29):
That is exactly how it works, and it guarantees absolute reliability.
You know exactly how your application is going to behave
every single time it starts, because it's physically impossible for
a previous run to leave behind corrupted data or conflicting file.
Speaker 1 (11:43):
Okay, so if a container wipes out all its changes
to return to its original image state, that pristine original
image has to be stored somewhere safe. We know the
demon pulls it down, but where is it actually getting
it from? Mentioned docker Hub earlier.
Speaker 2 (11:57):
Yeah, Docker hub is basically the absolute center of the ecosystem.
It functions as a registry. If you're familiar with GitHub
for storing and sharing code, Docker hub is the exact equivalent,
just for storing and sharing Docker images.
Speaker 1 (12:10):
So it's a massive library, right.
Speaker 2 (12:12):
The structural hierarchy is very clear. The registry holds repositories.
Repositories hold collections of images, and those specific variations of
images are version controlled by tags, like tagging an image
version one point zero versus version two point zero.
Speaker 1 (12:26):
Okay, so if I need a pre configured database or
like a Python environment, I just searched the registry. But
since anyone can upload to Docker Hub, how do I
know I'm not downloading a Python image that some random
developer filled with malware or crypto miners.
Speaker 2 (12:41):
That is a very valid cybersecurity concern. To solve this,
Docker implements a strict division between official and community images.
Speaker 1 (12:49):
Oh so there are official channels exactly.
Speaker 2 (12:51):
If you search for Python on Docker Hub, the very
first result will be the official image. This means it's
actively engineered and maintained by Docker into direct collaboration with
the Python Software Foundation.
Speaker 1 (13:02):
Itself, so it's highly vetted. But what does that vetting
actually look like? In practice?
Speaker 2 (13:06):
Official images go through an automated vulnerability scanning mechanism. Before
an official image is even published, Docker's security tools analyze
every single layer of the image.
Speaker 1 (13:17):
Every single layer.
Speaker 2 (13:19):
Yeah, it breaks down the system packages and checks their
versions against massive global CVE databases common vulnerabilities and exposures.
If an old version of a networking tool in the
image has a known security flaw, the scan flags it
and those results are displayed publicly right on the images page.
Speaker 1 (13:36):
That's amazing. You see the exact security posture before you
ever take the poll command. That is massive for enterprise security.
But what about the community images, Well.
Speaker 2 (13:46):
Anyone can create a free account and upload images. To
prevent chaos and naming collisions, Docker utilizes namespaces within the registry, like.
Speaker 1 (13:55):
The local name spaces we talked about earlier.
Speaker 2 (13:57):
Similar concept. Yeah, under the hood, those highly vetted official
images operate in a hidden name space called library, So
when you ran hello World earlier, the demon actually translated
your request to library hello World. But for community images,
the name space is simply the creator's username. So if
a developer named Nick created a chat application called fay,
(14:17):
you would pull it by typing his username, a slash
and the app name. So Nick jjfay makes total sense.
Speaker 1 (14:24):
Since we are pulling these images from docker Hub and
businesses rely on them being constantly up to date, there
has to be a way to automate this. Oh absolutely,
because I notice on Docker Hub there's a tab for
build settings on custom images. If I'm building my own app,
do I really have to manually push a new image
every single time I update my code? I can't imagine
(14:45):
doing that every time I fix a typo.
Speaker 2 (14:47):
What's fascinating here is that you absolutely do.
Speaker 1 (14:49):
Not have to.
Speaker 2 (14:50):
Modern software engineering relies entirely on automation, specifically through continuous
integration pipelines and web hucks.
Speaker 1 (14:57):
Okay, walk us through the mechanics of that automation. How
does that pipeline actually flow?
Speaker 2 (15:01):
It starts with your source code. You finish writing a
new feature and push your code up to a repository on.
Speaker 1 (15:07):
Githubs standard developer workflow.
Speaker 2 (15:09):
Right, and you've previously linked your docker hub account to
that specific GitHub repository. The moment GitHub receives your new code,
it sends a signal to docker Hub. Docker hub servers
automatically spin up read your code, and build a brand new,
updated image for you entirely in the cloud.
Speaker 1 (15:26):
Wait. Really, so the registry updates itself without my laptop
doing any of the heavy computational lifting at all.
Speaker 2 (15:31):
Exactly, And the pipeline actually goes even further. Once docker
hub finishes compiling that new image, it can trigger a
web hoook.
Speaker 1 (15:39):
A WebBook.
Speaker 2 (15:40):
Yeah, webook is essentially an automated post request sent across
the internet. Docerhub fires this webhook directly at your live
production sir. Wow, A listener on your server receives the message,
realizes there's an update, automatically pulls down the new image layers,
shuts down the old container, and starts a new with
(16:00):
your fresh code.
Speaker 1 (16:01):
So I literally just push code from my laptop, go,
get a cup of coffee, and five minutes later, my
live website updates itself automatically without me even touching the
production server.
Speaker 2 (16:10):
Yep, it's that seamless.
Speaker 1 (16:11):
That distributed deployment is incredible. Yeah, but since we're automating
the building of these images on Docker Hub, there has
to be a standardized way to instruct Docker how to
build the image in the first place.
Speaker 2 (16:23):
Historically, there are actually two distinct ways to build a
custom image. The first method was entirely manual. You would
start a basic Linux container, log into it using the
terminal manually type commands to install your software packages, configure
your files, and then use a special command called Docker
commit to save that current running state as a brand
(16:44):
new image.
Speaker 1 (16:45):
I guess doing things manually like that is a terrible
idea for production.
Speaker 2 (16:50):
Oh, you should avoid the commit command at all costs.
In the real world, building an image manually basically creates
a black.
Speaker 1 (16:56):
Box, right, because how would anyone know what.
Speaker 2 (16:57):
You did exactly? If you type commands into a terminal
and save the result, there is zero record of what
you actually typed. Six months from now, neither you nor
your team will remember what specific libraries you installed or
what configuration files you tweaked. It's impossible to version control
and impossible to reliably reproduce.
Speaker 1 (17:15):
This connects directly to how we manage dependencies in programming. Actually,
so making manual commits inside a container sounds exactly like
manually installing thirty different MPM packages for Node or pit
packages for Python, one by one via the command line.
Speaker 2 (17:30):
It's the exact same problem.
Speaker 1 (17:32):
It's just tedious, prone to human error, and leave zero documentation.
The docer file is basically like your package dot json
or requirements dot txt. It's your documented recipe.
Speaker 2 (17:44):
That's a great way to look at it. The industry
standard has to be declarative, and that standard is the
docker file. A Docker file is just a simple plaintext
document read sequentially from top to bottom by the Docker.
Speaker 1 (17:56):
Demon So it's just a list of instructions.
Speaker 2 (17:58):
Literally, a step by step recipe. Line one start with
Alpine Linux. Line two, copy my application code into the image.
Line three, run the command to install dependencies. Line four,
expose port eighty for web traffic.
Speaker 1 (18:12):
It's completely transparent. Anyone on your team can read your
Docker file and know the exact anatomy of your application environment, and.
Speaker 2 (18:19):
The execution of that Docker file introduces the most brilliant
engineering feat in the entire Docker ecosystem, the Union file system.
Speaker 1 (18:26):
The Union file system.
Speaker 2 (18:27):
Yeah, remember earlier when we talked about pulling images. Now
they're made of different.
Speaker 1 (18:31):
Layers, Yes, the layers that allow us to only download
the specific difts we're missing.
Speaker 2 (18:35):
So it's super fast, right, Every single actionable step in
your Docker file creates a brand new distinct layer.
Speaker 1 (18:43):
Okay. So to visualize this Union file system, uh huh,
imagine a stack of transparent tracing paper.
Speaker 2 (18:49):
Ooh, I like that.
Speaker 1 (18:50):
The very bottom sheet of paper is your base operating system,
say Alpine Linux. Then the next sheet of tracing paper
placed on top has your software dependencies drawn on it. Yep,
the sheet above that have your custom code. If you
look down from the very top of the stack, your
eyes compress all those sheets together and it looks like
one single cohesive picture, which is how the container views
(19:11):
its hard drive.
Speaker 2 (19:12):
That is a phenomenal visualization. The container genuinely thinks it
has one normal hard drive, but the demon is secretly
managing a stack of independent layers. This is why Docker
is so incredibly efficient at caching. How so, well, Let's
say your docger file has ten lines creating ten sheets
of tracing paper. You update a typo in your source code,
which is on step ten. You tell Dogger to rebuild
(19:33):
the image.
Speaker 1 (19:34):
Oh, it doesn't have to redraw the first nine sheets
of paper.
Speaker 2 (19:37):
Precisely. It looks at the first nine layers, realizes the
instructions haven't changed at all, instantly grabs them from the
local cash and only recalculates and saves the very last layer.
That's so spot It saves massive amounts of time during
the build process and saves massive amounts of bandwidth when
pushing that image to Docker Hub, because you are only
transferring the one layer that changed our.
Speaker 1 (19:59):
Journey today has covered massive ground. I mean, we started
by typing a simple Hello World command, breaking down the
RESC communication between the CLI and the demon.
Speaker 2 (20:09):
We really unpacked the whole flow.
Speaker 1 (20:11):
We explore the deep. So let's see if you, the listener,
have internalized the core rules of this architecture. Quick review
for you. If you launch an Alpine container, navigate into
its file system, create a new text file called my
file inside the home directory, and then completely stop the container.
What happens to that file the very next time you
(20:32):
start a container from that same Alpine image.
Speaker 2 (20:34):
It's gone forever. It vanished the exact second the container stopped.
Because containers are strictly immutable, they throw away their ephemeral
layer and always return to the pristine baseline of their blueprint.
Speaker 1 (20:45):
The hotel room was clean perfectly. But that architectural reality
leads to a really fascinating dilemma. We've established how isolated
and immutable containers are wiping the slate clean every single
time they shut down.
Speaker 2 (20:58):
Which is incredibly efficient for running code right.
Speaker 1 (21:01):
But in the real world, applications actually need to save
things permanently. Think about a global bank's database recording transactions,
or an e commerce site tracking the items in your
shopping cart. State has to exist somewhere.
Speaker 2 (21:13):
It raises the ultimate question of modern infrastructure. If a
container genuinely forgets everything the exact moment it shuts down,
how do global tech companies manage to keep your personal
data perfectly safe and permanent while relying on thousands of
these amnesiac containers every single second.
Speaker 1 (21:33):
It's quite the paradox.
Speaker 2 (21:34):
Bridging the gap between immutable code and mutable data is
the next great puzzle of containerization.
Speaker 1 (21:40):
It certainly is, and maybe that's a rabbit hole for
you to explore as you continue building your own systems.
But for now, we've unpacked the boxes, we've organized the
shipping containers, and hopefully your digital moving day just got
a whole lot easier. Thanks for joining us on this
deep dive.
Speaker 2 (21:54):
Keep experimenting,
Imagine spending like three weeks perfectly configuring a web server
on your laptop. You know, you have the exact right
versions of Python, the precise system libraries, literally every environment
variable tuned flawlessly.
Speaker 2 (00:14):
Oh yeah, the absolute dream setup, right.
Speaker 1 (00:17):
And then you push it to production. You're ready to celebrate,
and you just watch the entire application instantly crash.
Speaker 2 (00:22):
It's the worst feeling in the world.
Speaker 1 (00:24):
Why does it happen because the production server is running
a slightly older version of Linux, or maybe there's a
conflicting background process. That used to be the daily inescapable
nightmare of software development.
Speaker 2 (00:37):
Yeah, it was total chaos. I mean, you couldn't just
magically teleport your software. You had to take it apart,
pack it, ship it, and then basically try to rebuild
it in a completely different.
Speaker 1 (00:45):
Environment exactly, And it inevitably led to that classic developer
excuse right, Well it worked on my machine.
Speaker 2 (00:51):
Oh I've said that more times than I care to admit.
Speaker 1 (00:54):
We all have. But then you step into the world
of Docker and suddenly that chaotic movie day is just gone.
We're looking at this landscape of standardized shipping containers. It's clean,
it's isolated and well it just works.
Speaker 2 (01:09):
It really does. It completely changed the industry standard.
Speaker 1 (01:12):
Welcome to the deep dive. Our mission today is to
completely demystified Docker, and we are going to do it
with absolutely no screens required. We're going to guide you
step by step through an audio show and tell to
understand exactly how Docker's core tools come together.
Speaker 2 (01:28):
Yeah, because the goal here isn't just to throw buzzwords
at you. Whether you're a student of programming, maybe moving
into cybersecurity, or just a self taught tech enthusiast, you
really need to understand the underlying mechanisms.
Speaker 1 (01:39):
Right like what's actually happening behind the.
Speaker 2 (01:41):
Curtain, exactly what exactly happens under the hood when you
spin up a container, how does the system isolate your code?
And you know, how do you engineer your own architecture
entirely from scratch?
Speaker 1 (01:53):
Okay, let's unpack this. Imagine you're opening up your terminal
right now, just a blank black screen with a blinking.
Speaker 2 (01:58):
Cursor, a very familiar say.
Speaker 1 (02:00):
To really grasp Docker, we have to start with the
simplest action imaginable. You take three words Docker run Hello world,
and you hit enter. In a few seconds, this friendly
greeting pops up on your screen.
Speaker 2 (02:14):
Right, it feels instant.
Speaker 1 (02:15):
But behind the scenes of those three little words, a
highly orchestrated four step sequence just kicked off.
Speaker 2 (02:22):
It really is a beautiful orchestration. When you hit enter
on that Docker run hello World command, the first invisible
step is communication. Okay, the Docker CLI, the command line
interface you just typed into, isn't actually doing the heavy
lifting there. It essentially acts as a rest client.
Speaker 1 (02:39):
Oh interesting, Yeah, it.
Speaker 2 (02:40):
Takes your command and sends a message to the Docker damon.
The damon is the actual engine, a background service that's
just running continuously on your machine.
Speaker 1 (02:48):
Wait, so the CLI is just the messenger knocking on
the daemon's door saying, hey, we need to run this
Hello World.
Speaker 2 (02:54):
Program precisely, which leads us a step two. The daemon
checks is local cash, first looks at your computer's hard
drive and realizes it doesn't actually have the files required
for this specific Hello World.
Speaker 1 (03:07):
Program, right, because it's a brand new setup exactly.
Speaker 2 (03:10):
So it reaches out to the internet, specifically to a
public registry called Docker Hub, and it pulls the image
down to your machine.
Speaker 1 (03:18):
Right. Hold on, So, if it's pulling an image, isn't
that just a standard Internet download. I mean, pulling an
entire operating system environment should take minutes and eat up
massive bandwidth, shouldn't.
Speaker 2 (03:29):
It You would think so, But no, it's drastically smarter
than a standard file download, and image is not one massive,
monolithic chunk of data. It's actually constructed from layers.
Speaker 1 (03:39):
Lawyers.
Speaker 2 (03:40):
Yeah, When Docker pulls an image, it communicates with the
registry to compare cryptographic hashes specifically saha, two, five, six
hashes of the layers you need against the layers you
might already have on your machine.
Speaker 1 (03:53):
Oh wow, So it's checking for exact matches, right.
Speaker 2 (03:55):
It only downloads the specific differences or diffs that are missing.
So if another project on your laptop already downloaded the
base Linux layer, doctor just skips downloading it again entirely.
Speaker 1 (04:06):
That is incredibly efficient. So once the demon has those
specific layers locally, it can't just let them sit there
on your hard drive, right, It has to actually execute them,
which transforms that static file into our running container. I
guess that would be step three.
Speaker 2 (04:20):
Spot on. That execution phase is where Docker's true power lies.
The demon takes that assembled image and creates the active.
Speaker 1 (04:29):
Container, so it's bringing it to life.
Speaker 2 (04:31):
Basically. Yeah. In this specific case, the Hello world image
is simply programmed to execute a tiny script that outputs
some text. But whether that text was generated by a
complex no JS application, a Python script, or just a
basic UNUX command, the Demon handles the execution environment perfectly.
Speaker 1 (04:50):
And the final step, step four, is just writing that output. Right.
The demon captures the standard output from the container's execution
and pipes it back to your CLI, printing the greeting
on your terminal screen. Yep.
Speaker 2 (05:01):
Four steps, request, pull, execute, output, all in a matter
of seconds.
Speaker 1 (05:06):
And if you were to say, hit the up arrow
in your terminal and run Docker run hello world a
second time, you'd notice it finishes almost instantaneously.
Speaker 2 (05:13):
Because it completely skips the network download in step two.
Speaker 1 (05:16):
Right, the demon checks locally, sees the image layers are
already sitting in its cash, and jump straight to creating
the container. It basically removes the Internet from the equation.
Speaker 2 (05:26):
It really highlights how fast containerization is. But notice how
we are strictly separating our vocabulary here.
Speaker 1 (05:34):
Oh true.
Speaker 2 (05:35):
Yeah, we mentioned downloading the image in step two and
running it to create a container in step three.
Speaker 1 (05:40):
Which is funny because people definitely use those words interchangeably
in casual conversation all the time. Yeah, but in reality
they are completely different concepts.
Speaker 2 (05:48):
They really are, And honestly, understanding the strict boundary between
an image and a container is like the single most
critical hurdle in mastering Docker.
Speaker 1 (05:57):
So how should we visualize the difference.
Speaker 2 (06:00):
Think of an image as a blueprint. It's a combination
of a file system and parameters. Basically, it's a package
that rolls up everything your application needs to run, the
source code, the run time engine, the system tools, system libraries,
all of it.
Speaker 1 (06:14):
But an image itself doesn't actually do anything right. It's
completely static.
Speaker 2 (06:19):
Entirely static. An image has absolutely no state once it's built.
It is immutable, it never ever changes. A container, on
the other hand, is the active running process spawn from
that static blueprint.
Speaker 1 (06:31):
Okay, I love this. So if I'm thinking like a developer,
the Docker image is basically the class definition in my
object oriented code, and the Docker container is an instance
of that class.
Speaker 2 (06:43):
That is a perfect analogy.
Speaker 1 (06:45):
Right, because you define the class once, writing all the rules,
the methods, and variables. But then you can spin up
as many unique, separate instances containers from that one class
as you want in your computer's memory.
Speaker 2 (06:57):
It maps perfectly. And the beautiful part is how this
architectural choice impacts your system resources. You know, you only
paid the disk space cost for the single image. Wait really, Yeah,
Let's say you have an image for a web server
that takes up fifty megabytes on your hard drive. You
could launch one container, or you could launch a thousand
active containers from that exact same image, and my hard.
Speaker 1 (07:17):
Drive doesn't suddenly lose fifty gigabytes of space. It still
only costs me that original fifty megabytes.
Speaker 2 (07:23):
Not a single byte more on your hard drive. Now.
Of course, each running container uses its own separate chunk
of RAM to handle its active computations, but the storage
footprint remains incredibly.
Speaker 1 (07:36):
Tiny, which actually brings up a massive question for me. Yeah,
we keep saying these containers are isolated, right, but if
a thousand containers are running on the exact same laptop,
sharing the exact same underlying hard drive and operating system,
how are they actually kept separate from each other? I mean,
for someone moving into cybersecurity, just saying it's isolated doesn't
(07:57):
really explain the mechanism that is.
Speaker 2 (07:58):
A vital distinction to me. Containers are not virtual machines. Okay,
a virtual machine literally emulates hardware. It pretends to be
a physical motherboard and CPU running a really heavy, completely
separate guest operating system.
Speaker 1 (08:11):
Right which takes forever to boot up.
Speaker 2 (08:13):
Exactly. Docker doesn't do that at all. Docker utilizes native
features built directly into the Linux kernel, primarily two mechanisms
called name spaces and C groups.
Speaker 1 (08:23):
Name spaces and C groups, so it's basically tricking the
processes into thinking they are alone.
Speaker 2 (08:27):
Precisely, name spaces dictate what a process can see. When
Docker creates a container, it wraps the process in a
new name space, so as far as the application inside
the container is concerned, it is the only process running
on the entire computer.
Speaker 1 (08:42):
Wow.
Speaker 2 (08:42):
Yeah, it has its own isolated network interface, its own
isolated filetree. Then, ce groups, which stands for control groups,
dictate what the process can use.
Speaker 1 (08:51):
Ah, so that's the resource limit exactly.
Speaker 2 (08:54):
It limits the container so it can only access say,
five hundred megabytes of RAM or ten percent of the CPU.
Speaker 1 (09:00):
So it's just process isolation running natively on your existing kernel.
That completely explains why they boot up in milliseconds instead
of the minutes. It takes to boot a virtual machine.
Speaker 2 (09:09):
It's incredibly lightweight.
Speaker 1 (09:10):
Well, let's solidify this immutability concept with a mental experiment
for the listener. Imagine you're back at your terminal. We
are going to run a different command, this time Docker
run elipine shesh oh.
Speaker 2 (09:20):
That's a fantastic exercise for context. Alpine is a very specific,
stripped down distribution of Linux.
Speaker 1 (09:27):
Super tiny, right.
Speaker 2 (09:29):
Extremely tiny. If we used a Buntu for this experiment,
you'd be pulling down tens of megabytes, but Alpine is
aggressively optimized. It's only about two or three megabytes in total.
It is incredibly fast, which makes it a total staple
in the Docker ecosystem.
Speaker 1 (09:46):
Okay, so you run that command and instantly your terminal
prompt changes. You are no longer navigating your Mac or
your Windows machine. Thanks to those name spaces we just
talked about, you have been seamlessly dropped into the command
line of a running Linux system, completely isolated from your
host computer.
Speaker 2 (10:04):
Right now, let's test that concept of immutability. You're inside
this Alpine container. You type l's ala to list the files,
and you see a standard Linux directory structure.
Speaker 1 (10:13):
Makes sense.
Speaker 2 (10:14):
You navigate to the home directory, and you decide to
create a brand new text file. You type touch my file.
You run the list command again and verify it's there.
You can see it, it exists.
Speaker 1 (10:23):
Okay. Then you type exit. The container immediately stops running.
You're back on your normal computer. Prompt. But wait, you
realize you forgot to do something, so you run the
exact same command again, doctor run alpine sha, and you're
back in. You navigate back to the home directory, you
look for your file and it is completely gone, poof vanished.
Speaker 2 (10:43):
And that is exactly what we mean when we say
containers are immutable. A container always starts as a perfect
carbon copy of the original image.
Speaker 1 (10:51):
But I made a file, where did it go?
Speaker 2 (10:53):
Any changes you make while the containers running, like creating
that text file or installing a new package, happen in
a te temporary, ephemeral layer.
Speaker 1 (11:01):
Ah. So it's not permanently written to the image. No.
Speaker 2 (11:04):
Never the exact moment the container stops, that temporary layer
is literally thrown in the trash. When you start a
new container from the image, it reverts entirely to its
pristine baseline state.
Speaker 1 (11:16):
It's like a hotel room. No matter what you do
during your stay, you move the chairs around, leave a
book on the nightstand, empty the mini bar. When you
check out, the cleaning crew resets the room to its
exact original floor plan for the very next guest.
Speaker 2 (11:29):
That is exactly how it works, and it guarantees absolute reliability.
You know exactly how your application is going to behave
every single time it starts, because it's physically impossible for
a previous run to leave behind corrupted data or conflicting file.
Speaker 1 (11:43):
Okay, so if a container wipes out all its changes
to return to its original image state, that pristine original
image has to be stored somewhere safe. We know the
demon pulls it down, but where is it actually getting
it from? Mentioned docker Hub earlier.
Speaker 2 (11:57):
Yeah, Docker hub is basically the absolute center of the ecosystem.
It functions as a registry. If you're familiar with GitHub
for storing and sharing code, Docker hub is the exact equivalent,
just for storing and sharing Docker images.
Speaker 1 (12:10):
So it's a massive library, right.
Speaker 2 (12:12):
The structural hierarchy is very clear. The registry holds repositories.
Repositories hold collections of images, and those specific variations of
images are version controlled by tags, like tagging an image
version one point zero versus version two point zero.
Speaker 1 (12:26):
Okay, so if I need a pre configured database or
like a Python environment, I just searched the registry. But
since anyone can upload to Docker Hub, how do I
know I'm not downloading a Python image that some random
developer filled with malware or crypto miners.
Speaker 2 (12:41):
That is a very valid cybersecurity concern. To solve this,
Docker implements a strict division between official and community images.
Speaker 1 (12:49):
Oh so there are official channels exactly.
Speaker 2 (12:51):
If you search for Python on Docker Hub, the very
first result will be the official image. This means it's
actively engineered and maintained by Docker into direct collaboration with
the Python Software Foundation.
Speaker 1 (13:02):
Itself, so it's highly vetted. But what does that vetting
actually look like? In practice?
Speaker 2 (13:06):
Official images go through an automated vulnerability scanning mechanism. Before
an official image is even published, Docker's security tools analyze
every single layer of the image.
Speaker 1 (13:17):
Every single layer.
Speaker 2 (13:19):
Yeah, it breaks down the system packages and checks their
versions against massive global CVE databases common vulnerabilities and exposures.
If an old version of a networking tool in the
image has a known security flaw, the scan flags it
and those results are displayed publicly right on the images page.
Speaker 1 (13:36):
That's amazing. You see the exact security posture before you
ever take the poll command. That is massive for enterprise security.
But what about the community images, Well.
Speaker 2 (13:46):
Anyone can create a free account and upload images. To
prevent chaos and naming collisions, Docker utilizes namespaces within the registry, like.
Speaker 1 (13:55):
The local name spaces we talked about earlier.
Speaker 2 (13:57):
Similar concept. Yeah, under the hood, those highly vetted official
images operate in a hidden name space called library, So
when you ran hello World earlier, the demon actually translated
your request to library hello World. But for community images,
the name space is simply the creator's username. So if
a developer named Nick created a chat application called fay,
(14:17):
you would pull it by typing his username, a slash
and the app name. So Nick jjfay makes total sense.
Speaker 1 (14:24):
Since we are pulling these images from docker Hub and
businesses rely on them being constantly up to date, there
has to be a way to automate this. Oh absolutely,
because I notice on Docker Hub there's a tab for
build settings on custom images. If I'm building my own app,
do I really have to manually push a new image
every single time I update my code? I can't imagine
(14:45):
doing that every time I fix a typo.
Speaker 2 (14:47):
What's fascinating here is that you absolutely do.
Speaker 1 (14:49):
Not have to.
Speaker 2 (14:50):
Modern software engineering relies entirely on automation, specifically through continuous
integration pipelines and web hucks.
Speaker 1 (14:57):
Okay, walk us through the mechanics of that automation. How
does that pipeline actually flow?
Speaker 2 (15:01):
It starts with your source code. You finish writing a
new feature and push your code up to a repository on.
Speaker 1 (15:07):
Githubs standard developer workflow.
Speaker 2 (15:09):
Right, and you've previously linked your docker hub account to
that specific GitHub repository. The moment GitHub receives your new code,
it sends a signal to docker Hub. Docker hub servers
automatically spin up read your code, and build a brand new,
updated image for you entirely in the cloud.
Speaker 1 (15:26):
Wait. Really, so the registry updates itself without my laptop
doing any of the heavy computational lifting at all.
Speaker 2 (15:31):
Exactly, And the pipeline actually goes even further. Once docker
hub finishes compiling that new image, it can trigger a
web hoook.
Speaker 1 (15:39):
A WebBook.
Speaker 2 (15:40):
Yeah, webook is essentially an automated post request sent across
the internet. Docerhub fires this webhook directly at your live
production sir. Wow, A listener on your server receives the message,
realizes there's an update, automatically pulls down the new image layers,
shuts down the old container, and starts a new with
(16:00):
your fresh code.
Speaker 1 (16:01):
So I literally just push code from my laptop, go,
get a cup of coffee, and five minutes later, my
live website updates itself automatically without me even touching the
production server.
Speaker 2 (16:10):
Yep, it's that seamless.
Speaker 1 (16:11):
That distributed deployment is incredible. Yeah, but since we're automating
the building of these images on Docker Hub, there has
to be a standardized way to instruct Docker how to
build the image in the first place.
Speaker 2 (16:23):
Historically, there are actually two distinct ways to build a
custom image. The first method was entirely manual. You would
start a basic Linux container, log into it using the
terminal manually type commands to install your software packages, configure
your files, and then use a special command called Docker
commit to save that current running state as a brand
(16:44):
new image.
Speaker 1 (16:45):
I guess doing things manually like that is a terrible
idea for production.
Speaker 2 (16:50):
Oh, you should avoid the commit command at all costs.
In the real world, building an image manually basically creates
a black.
Speaker 1 (16:56):
Box, right, because how would anyone know what.
Speaker 2 (16:57):
You did exactly? If you type commands into a terminal
and save the result, there is zero record of what
you actually typed. Six months from now, neither you nor
your team will remember what specific libraries you installed or
what configuration files you tweaked. It's impossible to version control
and impossible to reliably reproduce.
Speaker 1 (17:15):
This connects directly to how we manage dependencies in programming. Actually,
so making manual commits inside a container sounds exactly like
manually installing thirty different MPM packages for Node or pit
packages for Python, one by one via the command line.
Speaker 2 (17:30):
It's the exact same problem.
Speaker 1 (17:32):
It's just tedious, prone to human error, and leave zero documentation.
The docer file is basically like your package dot json
or requirements dot txt. It's your documented recipe.
Speaker 2 (17:44):
That's a great way to look at it. The industry
standard has to be declarative, and that standard is the
docker file. A Docker file is just a simple plaintext
document read sequentially from top to bottom by the Docker.
Speaker 1 (17:56):
Demon So it's just a list of instructions.
Speaker 2 (17:58):
Literally, a step by step recipe. Line one start with
Alpine Linux. Line two, copy my application code into the image.
Line three, run the command to install dependencies. Line four,
expose port eighty for web traffic.
Speaker 1 (18:12):
It's completely transparent. Anyone on your team can read your
Docker file and know the exact anatomy of your application environment, and.
Speaker 2 (18:19):
The execution of that Docker file introduces the most brilliant
engineering feat in the entire Docker ecosystem, the Union file system.
Speaker 1 (18:26):
The Union file system.
Speaker 2 (18:27):
Yeah, remember earlier when we talked about pulling images. Now
they're made of different.
Speaker 1 (18:31):
Layers, Yes, the layers that allow us to only download
the specific difts we're missing.
Speaker 2 (18:35):
So it's super fast, right, Every single actionable step in
your Docker file creates a brand new distinct layer.
Speaker 1 (18:43):
Okay. So to visualize this Union file system, uh huh,
imagine a stack of transparent tracing paper.
Speaker 2 (18:49):
Ooh, I like that.
Speaker 1 (18:50):
The very bottom sheet of paper is your base operating system,
say Alpine Linux. Then the next sheet of tracing paper
placed on top has your software dependencies drawn on it. Yep,
the sheet above that have your custom code. If you
look down from the very top of the stack, your
eyes compress all those sheets together and it looks like
one single cohesive picture, which is how the container views
(19:11):
its hard drive.
Speaker 2 (19:12):
That is a phenomenal visualization. The container genuinely thinks it
has one normal hard drive, but the demon is secretly
managing a stack of independent layers. This is why Docker
is so incredibly efficient at caching. How so, well, Let's
say your docger file has ten lines creating ten sheets
of tracing paper. You update a typo in your source code,
which is on step ten. You tell Dogger to rebuild
(19:33):
the image.
Speaker 1 (19:34):
Oh, it doesn't have to redraw the first nine sheets
of paper.
Speaker 2 (19:37):
Precisely. It looks at the first nine layers, realizes the
instructions haven't changed at all, instantly grabs them from the
local cash and only recalculates and saves the very last layer.
That's so spot It saves massive amounts of time during
the build process and saves massive amounts of bandwidth when
pushing that image to Docker Hub, because you are only
transferring the one layer that changed our.
Speaker 1 (19:59):
Journey today has covered massive ground. I mean, we started
by typing a simple Hello World command, breaking down the
RESC communication between the CLI and the demon.
Speaker 2 (20:09):
We really unpacked the whole flow.
Speaker 1 (20:11):
We explore the deep. So let's see if you, the listener,
have internalized the core rules of this architecture. Quick review
for you. If you launch an Alpine container, navigate into
its file system, create a new text file called my
file inside the home directory, and then completely stop the container.
What happens to that file the very next time you
(20:32):
start a container from that same Alpine image.
Speaker 2 (20:34):
It's gone forever. It vanished the exact second the container stopped.
Because containers are strictly immutable, they throw away their ephemeral
layer and always return to the pristine baseline of their blueprint.
Speaker 1 (20:45):
The hotel room was clean perfectly. But that architectural reality
leads to a really fascinating dilemma. We've established how isolated
and immutable containers are wiping the slate clean every single
time they shut down.
Speaker 2 (20:58):
Which is incredibly efficient for running code right.
Speaker 1 (21:01):
But in the real world, applications actually need to save
things permanently. Think about a global bank's database recording transactions,
or an e commerce site tracking the items in your
shopping cart. State has to exist somewhere.
Speaker 2 (21:13):
It raises the ultimate question of modern infrastructure. If a
container genuinely forgets everything the exact moment it shuts down,
how do global tech companies manage to keep your personal
data perfectly safe and permanent while relying on thousands of
these amnesiac containers every single second.
Speaker 1 (21:33):
It's quite the paradox.
Speaker 2 (21:34):
Bridging the gap between immutable code and mutable data is
the next great puzzle of containerization.
Speaker 1 (21:40):
It certainly is, and maybe that's a rabbit hole for
you to explore as you continue building your own systems.
But for now, we've unpacked the boxes, we've organized the
shipping containers, and hopefully your digital moving day just got
a whole lot easier. Thanks for joining us on this
deep dive.
Speaker 2 (21:54):
Keep experimenting,
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Breakfast Club
The World's Most Dangerous Morning Show, The Breakfast Club, With DJ Envy, Jess Hilarious, And Charlamagne Tha God!
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.