Welcome back, and in this part of the course,


I want to step through the architecture


of containers and container images.


Now it's important that you understand


how each of them work,


but also how they relate to each other.


Now we've got a lot of important things to cover,


so let's jump in and get started.


The first thing that I want to cover


is the high level relationship


between container images and containers.


A container image or docker Image should be thought of


as a read only immutable template.


When you create them, they don't change.


If you do change them, you're actually making a new image.


But container images are used to run containers,


and containers need storage.


So how does that work?


Well, let's say that we Launch a game server


from this container image.


What actually happens is a writeable layer is added.


Conceptually, imagine this as attached to the container.


And this means that any data writes


which happen inside the container


rather than changing the image itself


are written to this layer.


And this is the default way that containers


have a form of local storage.


This writeable layer is what makes one container


unique from another,


where both use the same container image.


If we launch another container from the same image,


that container gets its own unique writeable layer,


making it, i.e. the Container on the right,


unique from the container on the left.


Writeable layers are linked


to the lifecycle of the container.


They don't persist, and they don't offer a way


to move data between containers.


Think of them as isolated to a container.


Additionally, writeable layers use a union file system.


They have a driver specifically to allow


the shared read only image


and then any written data to be stored


in this separate layer.


Now, this does come with a slight performance hit,


and there are also tightly coupled to a host


so data cannot easily be moved.


If you need to share data,


there are other more advanced types of storage


that we'll be covering elsewhere in the course.


Container writeable layers are just there


to allow a container to have its own system state.


Now talking about layers,


I should probably talk more about that.


So let's look at that next.


So far, I've talked about docker images


as though there are monolithic thing.


They're actually not.


Images are a collection of independent file system layers.


Let's review how this works.


For our game server image,


if we peek inside, what we might see


is three different file system layers.


Layers within docker images are differential,


meaning each layer only contains


the differences from the layer below.


Let's say this bottom layer


is a base Linux file system layer,


so it contains the files required to boot a Linux container.


The middle layer contains some runtime environment files


and libraries, which our application needs.


And notice how this is less data,


shown as one cube versus the three on the layer below.


This file system layer only contains data


which is changed from the bottom layer.


At the top, we have our application layer,


which also contains some data,


but this doesn't change anything from layers below.


Instead, it adds new data.


Each of these are separate layers,


but when working with images,


because the image consists of these three layers,


what a docker container might see is this.


Each of these are separate layers,


but when working with images,


because the image consists


of these three independent layers,


what a docker container might see is this,


where it sees what is in effect one single store of data


containing these four blocks, but in actual fact,


they're each taken from independent layers.


Each layer stores the differences in data.


And from a docker container perspective,


it reads all of these individual layers


and interacts as though it was one store of data.


Now, it's critical for you to understand, though,


that layers can be reused.


And because layers are treated as individual things,


it helps avoid unnecessary uploads and downloads.


For example, if you run a docker pull to pull down an image,


if you already have any of the layers,


they don't need to be pulled down again.


Now, at a high level, that's how docker images


and layers interact with containers.


So a docker image is read only and it's immutable,


and each image consists of a number of different


file system layers that are all used together


and form an image.


But crucially, these layers are treated as separate things.


They can be reused,


and when you're doing docker pull or push operations


that you'll experience later in the course,


you'll see that these operate individually


on layers of images.


Now, don't worry if this seems confusing.


As you move through the course,


you're going to get more in depth theory understanding


as well as practical exposure for how you can interact


with docker images and the layers within those images.


For now, though, that's everything I wanted to cover


in this part of the course.


Hopefully it all makes sense.


When you are ready, go ahead and move on in the course,


and we can continue diving into docker.