What is a Container?

[Music] hi my name is Ben khari and I'm here to talk to you about what is a container now that may sound like a very basic question to be asking in 2017 but I can tell you every time we go to VMworld every year we talk about vSphere integrated containers and and container technologies all the kinds of stuff that we're working on here at vmware oftentimes we get a kind of a sheepish look and like actually what is it container like you know I may be you've heard a few things about it I you know I know some things maybe some of the things I know are wrong so before I deep dive into vSphere integrated containers which is going to be a subsequent whiteboard I had you just want to tackle this fundamental question of what is a container so I think the word container to some extent is used to cover a multitude of things that's one of the things that I think is a little bit confusing about it so let's start the very most simple the very simplest form of water container is so here we have an operating system okay operating system this could be in a VM it could be bare metal doesn't matter but it's an operating system and for argument's sake let's say that it's Linux I mean these days most containers are in Linux and inside of that operating system you can run processes okay now in the normal scheme of things you can run any number of processes inside this operating system and these processes share an address space they share a process name space they share pretty much everything now that's useful absolutely you know in many cases you will be running all sorts of things inside of all these operating systems it's designed to do that it's designed to schedule these things and that's all well and good however what if you actually want to isolate one of these processes from one of the other processes what if you want some kind of sandbox for that process to run in okay that at its most basic is the notion and the concept of the container right least as it was originally envisaged it's basically a sandbox for a process now one of the mean by sandbox well what I mean by sandbox is that the process for start has its own process namespace and okay so when you if I were to get a shell into this container I would see just the processes running inside of that container it has its own process name space so we've got a process name space we also have we also have cgroups which allows us to also restrict what this process is able to do there are certain capabilities there are certain resource limits that we can apply this container and that allows us for a certain degree of isolation when it's combined with the process namespace and that's the most fundamental notion of the runtime definition of a container it's basically an isolated process a process running in a sandbox that typically only sees other processes or other things that have started in the same container now in the concept in the container concepts that I've drawn here you see one process per container and that's typically the the way that containers are used and in fact the way that a container is used in in the docker sense and in most cases that you'll see the container process is actually completely tied in with the lifecycle of the container itself so when you start the container it starts the container process when the container process exits the container ends right so the container process and and the container lifecycle are completely tightly coupled now within the container you may have other processes running right there may be threads for the kicked off there may be a daemon process that started you can actually go in and execute other process processes in containers but typically you've got this one lean process and then and then other things running so this is what I would say the run time is a basic runtime definition of what a container is it's a sandbox for a process so then let's think about you know I said earlier on this whole notion of the container is somewhat overloaded let's think about what other things the word container can mean well in such a thing as a container image and whatever we talk about containers we actually conflate the word container with with an image we actually mean an image and what does it contain image well an image is very simply a binary representation it's just a bunch of bits on a filesystem somewhere right in the same way as a VMDK is a disk image and an OVA is an image for a VM it's basically an image that contains some binary state the interesting thing there about a container image at least in the way that we think about containers today is that there's also a notion of a parent-child relationship and image layering let me explain what I mean so if we start at the the root of this parent-child tree we have an image called scratch the scratch image basically is just in completely and think of it as an empty formatter facet right it's basically nothing now on top of scratch we might have the basics of an operating system so let's say we have something like busybox or you might have debian or we might have whatever right that's there's some image built off of scratch that is just a bare bones of an operating system then that image can be the parent of another image and let's say that that image is I know let's add something into this let's say we add sshd into here let's say we add I don't know some let's say we had Perl into here whatever it is we want to add but now we have an image based off of busybox that also have sh sh d in Perl then on top of that maybe we'll have another image that has I don't know maybe it may be a small application right the whole point though is that the images are arranged in this image hierarchy and it's think of it it's very much like the notion of snapshots right like disk snapshots you know you've got this binary state here and you add something and that creates a snapshot you add something else to it and that creates a snapshot the beauty of this was a number of advantages to this a number of reasons it is really one of the good things about this is that it allows you to share images right because you end up with this tree effectively and anytime that you want to run an application well you'll pull a branch of this tree but the other nodes may well be shared by other things that you're running so it actually allows the quite a lot of consolidation of binary state which is a good thing right you're not having to shift around the entire application stacks in single files which is which can be kind of painful another big advantage of this is it allows you to concentrate specific things in specific places right and know where they are so for example this busy box here it could be a bun so it could be it could be anything could be sent off but let's say that I discover a particular vulnerability in the user libraries in CentOS right or in busybox and I'm like oh wow okay I need to replace this well now I need to understand all of the other applications that I'm running that is going to be impacted by that vulnerability well now because of this tree structure that's actually pretty easy to figure out because every single child node every descendant of this busybox node is going to be impacted by that vulnerability because I know that it's here and I know that all these things inherit from that node so by rebuilding this and then rebuilding everything else and redeploying everything else I have a high degree of certainty that the thing that I patched here is now inherited by everything else so that's also a good thing so this whole question of images is tied in with this this whole question of the runtime motion of a container and it's a little bit like the whole class object concept right an image is like a class right it's a template for something and then you can create any number of instances of that template and it has this runtime representation so let's talk them in more detail about how we tie these things together and actually before we do that let's talk about how we build images and in fact by implication how we build containers so let's talk specifically about the docker use case because it's helpful to do that docker has added a ton of really useful abstractions to the whole container abstraction that this basic construction that makes life way easier and is huge value to this whole experience so let's talk about the dockerfile okay you may have heard of a docker file but what is the docker file a docker file is basically an environment in a file in a text file and you may not know but the start of a docker file is just from right from what what does that mean well from is the parent image but this docker file is inheriting from so here we'll say from and we'll say from busybox for example and then within here we can basically run any number of things that we want to configure the image that this docker file is going to create so a docker file ultimately ends up creating an image so we use docker files and dock a build to create this image tree of images that we can then use to instantiate containers now every line in the docker file is is also a layer their cache layers that's a little bit more advanced but suffice to say that a docker file is typically a starting point for an image because it makes that really really easy then how do we make containers or containers confront images so we go from docker file to image to container but we can also create image from a container we can actually go from here back to here again and the way we can do that is we can say okay I'm going to run a container and I'm going to login to it I'm going to get a shell into it and I'm going to run install this and modify that and add this configuration file to do whatever modifications I want to make and then I can commit that as an image and then from that image create more containers so I don't have to start from the docker file I can move between these two things here but hopefully that's a good and helpful illustration of the relationship between these things now another thing that's worth worth calling out here is that you'll notice that a container is packaged with all of its dependencies which again is distinct to some extent from for most applications most applications you'll install into your operating system and your operating system will already have quite a few dependencies in it that will certainly have the user libraries it may well have basics like sh-t pearl they may already be installed in there and there's a presumption that there's a whole bunch of configuration and and and an operating system state already there when you type apt-get install whatever you type to install your application well with with containers it's expected that all of the dependencies pretty much above the kernel are packaged inside of the container so when you run the container in an operating system you actually don't install anything right nothing is actually installed into this thing it just it sits above the operating system in its own in its own world and its own stack and that again is a really powerful thing that is partly why we use this word container because the whole notion of the container is it contains right it contains everything that you need to run an application so one of the things people have found about containers it's actually really nice is you can run any number of different versions of applications that require different versions of libraries and you can run them all on top of a single operating system because none of these dependencies are installed if you delete these images it's all gone like you just the whole thing is back to a completely clean state and so in the in the in the world of things like Jenkins slaves this is this is a huge boon because we can actually run stuff on them without polluting them right so oK we've got the images we've looked at the runtime motion of containers and we've looked at docker file so let's tie all of this together so we have a thing called a docker host and again I'm being specific to darker at this point because it's the most popular thing out there and it's a helpful illustration so we'll say docker host ok so how do we tie all these things together well out there in the world somewhere they will be a thing called a registry now the registry is a thing that contains these images right these snapshots that I mentioned and you can pull and push from the registry at will ok remember when you're pulling and pushing you're typically only pulling and pushing the bits that you need because inside of this host there is an image cache so if I want to run let's say my application and I do docker pull what it's going to do is it's going to say ok how many of these parent nodes do I already have in this image cache and it will pull the ones that it needs and if I then create choose to create a derivative of this a child of this I can push that to registry but I'm only pushing the disk because that's all I need to push because everything else is in the registry so the beauty of this relationship here is we're pulling and pushing dips and this image tree is then basically replicated here inside the cache inside the image cache as as necessary so how do I actually do all this docker pulled up a post-doc or whatever well it was a client so there is a doctor client and the client talks to a daemon that runs in here daemon ok the client talks to demon a demon exposes an API of the client and the client can do all sorts of useful things like pulling and pushing images like creating a container like running a container like committing a container we've been through some of these things already but these are some of the basic things the clients or the client manages the lifecycle of containers inside this docker host but it actually does more than that and not only manages the lifecycle of the containers but it's also designed to be able to configure the infrastructure inside of this docker host as well so it's not only container lifecycle management but it's also able to do network configuration and storage configuration so what I mean by network and storage configuration well inside of this docker host docker will set up certain kinds of networking right now we're not going to go into detail on that because that that would be a topic for another day but using the client it's a kind of network virtualization that happens in here using the client I can basically choose to do port forwarding I can choose to do all sorts of I mean there's all sorts of plugins as well that give me much more complex overlay networking and other capabilities but from the client I can control all of that networking and I can say okay I want to create a network for containers to talk to each other on I want to you know assign this container to this network I want to create links so that containers can refer to each other by certain types of hostname there's all sorts of network configuration I could do from this docker client in terms of storage configuration typically the main thing I want to do with storage is to create volumes so there is a thing in docker called a volume and a volume is very simply a persistent area of storage so container will have or may have a volume if it wants to persist any data beyond the lifecycle of the container remember early on we talked about how the process is completely tied to the lifecycle of the container well the containers state is also ephemeral and completely tied to its lifecycle the moment you delete the container you delete all of the state that it wrote so if you actually want to persist any state you've really got two options you either create a volume and you mount it to a container or you'll push it out on a network socket to somewhere right those are the two things that you typically do so the client managers storage the client manages let's just put a network in here right the client managers networking and it manages the container lifecycle so let's say we start a container let's say we start my app well we go to client docker run my app ok well let's say this pulls all of the images it needs from the registry and the images are in the image cache or what it's been able to do is it's been able to set up the see groups in the process namespace and do all the magic with the networks and all the magic with am ancing and everything that needs to happen to run your application in a sandbox inside of this linux host and of course you know lifecycle management you've got stop you've got kill you've got delete but all the fundamentals are there in terms of what I just described so to summarize when we talk about a container we're talking about a whole bunch of things we're talking about the container image it's related to other images we're talking about the runtime represent a representation of a container we're talking about the way in which we create and build and define what a container is and then when we tie all that together with something like a registry and a client we have this ecosystem this world in which we can then spin up containers control infrastructure and tie all these things together I hope that was informative thanks very much [Music]

Channel: VMware Cloud Native Apps

Views: 541,960

Rating: 4.8662162 out of 5

Keywords: Cloud Native, Container Networking, Software Defined Networking, SDN, Cloud Computing, Virtual Infrastructure, Kubernetes, K8s, VMware, Cloud Architecture, Application Development, Docker

Id: EnJ7qX9fkcU

Length: 18min 23sec (1103 seconds)

Published: Tue May 16 2017