‫Well, hello, or should I say whalecome ‫to the future of software management
‫with Docker and container tooling.
‫This video is specifically about Docker.
‫It had lots of tools over the years, ‫but this video is about the three
‫major innovations that started the ‫Docker whole evolution of software
‫in 2013, that is mainly three things.
‫The Docker image, that Docker registry, ‫and then the Docker container.
‫Most of us, when we think of Docker, ‫we think of the container, but
‫these three innovations go together ‫like bread and butter and they
‫call it at Docker build ship run.
‫Those are the three steps.
‫To take previously non containerd ‫software, turn it into a Docker
‫image, put it on a registry, get ‫it to wherever you need to run it.
‫And then finally create ‫a container from it.
‫In fact, the CNCF or the Cloud ‫Native Computing Foundation, which
‫a lot of the tools we'll talk ‫about throughout all my videos.
‫Those products and tools and ‫workflows make the assumption, in
‫most cases, that you are using a ‫container workflow of build ship run.
‫So let's break these down and ‫exactly what the three are.
‫First up the container image.
‫And I like to think of it as a universal ‫app packager, And we've had lots
‫of package managers over the years.
‫In fact, I've lost count, ‫and I've been around a while,
‫of all the package managers.
‫But there's never been anything that ‫I can recall, that's been cross OS,
‫cross platform, and application ‫language agnostic, meaning it will run
‫everywhere, and it runs on anything, as ‫long as it's running Linux or Windows.
‫Now let's take a real quick look at a ‫Dockerfile, which is the recipe or set
‫of instructions to make a container ‫image, Docker image and container image
‫are the same term for the same thing.
‫In fact, the Docker image specification ‫was so popular it's now a standard
‫known as the OCI image standard.
‫So you see a set of instructions and every ‫Dockerfile needs a FROM, to start with,
‫we can start from someone else's image.
‫We can have many images from many ‫FROMs, so we'll get into all that
‫complexity later, but we're starting with ‫Python here and we work our way down.
‫In fact, we start with these as ‫layers each one of these commands
‫in the Dockerfile, sometimes called ‫a stanza, with capital letters.
‫Including the, FROM, and then the ‫RUN and working their way down
‫because it processes them from ‫the top down, will create layers.
‫Which get moved around servers ‫as tarballs and inside those
‫layers are files, directories and ‫file permissions, and sometimes
‫metadata that we'll get into later.
‫When I start building this image, it ‫will start that first line and go find
‫the Python image from Docker Hub or ‫wherever I told it to get the image from.
‫and that includes just Python ‫its binaries and its libraries.
‫It doesn't contain host drivers ‫or the Linux Kernel, or anything
‫outside of what Python needs to run.
‫If Python needs OpenSSL, then that's ‫included in that layer of the image.
‫Then we can move on to the ‫next line of the Dockerfile.
‫That's a PIP command for a ‫Python dependency installer,
‫and it's installing flask.
‫So that will start a new layer ‫that adds flask just like you would
‫with a normal PIP install command.
‫In fact, what's happening in the ‫background is we're executing quick
‫little containers for each of these ‫layers, running the commands or
‫doing whatever you need to do inside ‫those layers, and then storing them
‫as their own distinct location.
‫On the Linux host, that's building this.
‫So we're stacking up layers here.
‫And then we go to the next ‫line, the COPY command.
‫The WORKDIR there is just a ‫metadata change, it just changes
‫locations in the file system.
‫No big deal.
‫The COPY command copies our source code ‫from the host we're building on into its
‫own layer, stacked on top of the others.
‫These together form an image ‫using the command Docker build.
‫This is one of those things about Docker ‫that became so easy to use because we
‫only needed this simple Docker build ‫command to take a bunch of complex things
‫going on in the Dockerfile and turn it ‫into a single image that is just our
‫application and only the dependencies ‫that it needs and nothing else.
‫That's the first part ‫of the build ship run.
‫Being Docker build.
‫Next up, let's talk about the registry.
‫The Docker registry is for ‫application distribution.
‫Every application packaging system has ‫a way to get those packages around and
‫the Docker registry is no different.
‫Now it's just known as the ‫OCI distribution spec or
‫OCI registry specification.
‫So it's a standard again in ‫the whole industry for how to
‫move container images around.
‫and it is everywhere.
‫Every cloud has one.
‫Docker Hub is the default and ‫probably the most popular.
‫GitHub has one.
‫Bitbucket, GitLab, they all ‫have their own image registries,
‫and you could run your own.
‫There's probably at least a dozen ‫projects of free open source and
‫paid software that allow you to ‫store your Docker images in them.
‫so let's break down how that works.
‫First.
‫We have our image that we just built ‫and that image has a unique SHA hash
‫that identifies all those layers ‫together in a way that we can guarantee,
‫that if we look at the hash on two ‫different systems, we can be certain
‫that it's the exact same files, the ‫exact same metadata that we just built.
‫Those image layers go together ‫and distribute themselves.
‫We can use something like Docker ‫push to take those image layers
‫and push them up to a registry.
‫You can use one of many registries, like ‫I mentioned, But once it's there, you
‫can then go to another machine and do a ‫Docker pull, which will pull an identical
‫copy of that image down on that machine.
‫Just like we had built ‫it on the first machine.
‫And this is one of the core principles ‫of Docker is that we're able to take
‫the software that we made on one machine ‫with all of its dependencies and run it
‫exactly that same way on another system ‫that might be completely different
‫distributions of Linux or Windows.
‫If you're on Linux and you build a ‫Linux image, which has to run on Linux
‫since it's running Linux binaries, if ‫you built it on CentOS and you ran
‫it on Ubuntu, it would be the exact ‫same application and dependencies,
‫regardless of that distrobution.
‫Finally, we get to the Docker ‫container itself . Once we've done
‫all those steps of building the ‫image, putting it in a location, we
‫can access it from our servers and ‫then downloading it into our servers.
‫We can run it.
‫Let's imagine we have ‫a server running Linux.
‫It might be running Windows, but in ‫this case, we'll just focus on Linux.
‫It's going to have Docker ‫running in the background.
‫That's known as the Docker Engine and ‫the engine on this single machine will
‫orchestrate or manage all the different ‫things that need to happen in order to
‫download images, verify that they're ‫the exact thing that was meant to be
‫downloaded, and then finally run them.
‫Then we got the image, we just ‫downloaded with a Docker pull, and
‫then we're gonna run a command.
‫It's not really important to ‫you learn the command yet,
‫but it's a Docker run command.
‫This is the run part of build ship run.
‫And in this case, we're running that ‫Python app in its own container.
‫That container is known as a namespace.
‫That's that Linux feature that ‫prevents the application running
‫in this container from seeing ‫the rest of the operating system.
‫It gets its own blank file system, ‫and it will only include the files
‫that were in that image we just built.
‫It'll get its own IP address and its own ‫virtual NIC and its own process list.
‫And basically looks like ‫its own system inside there.
‫Then, if we run that Docker, run ‫command again with our image name or
‫image hash, then we get an identical ‫container running side by side.
‫Now these two processes are ‫isolated from each other.
‫So the Python app in container one can't ‫see the Python app in container two.
‫And if you change a file in ‫container two, container one
‫won't see that file by default.
‫If we added a second server with a ‫second instance of the Docker Engine
‫running and did the same thing, we ‫could have a highly available setup
‫with our application running many times ‫for redundancy or better performance
‫or whatever our reason might be ‫for running more than one of them.
‫They will be identical from the ‫point of view of the file system,
‫the permissions and the metadata.
‫Now there's a ton more that we can ‫learn about this stuff, which is why
‫the course that I have is so long now.
‫But these are still the three ‫things that haven't changed after
‫Docker first conceptualized them.
‫The build ship run idea is ‫one of the core principles of
‫container, and Kubernetes, Helm.
‫You name the project in the cloud native ‫ecosystem, and it probably assumes you
‫have this typical kind of workflow for ‫getting your apps out of your developers
‫hands, into the testing systems, and ‫then finally into production servers.
‫It's these same three steps.
‫So, hopefully it's starting to ‫sink in just a little bit that you
‫get why these are the three key ‫components, even today, many, many
‫years after all this was invented.
‫Let's find out what's next.