Docker the program

- [Instructor] And now a little interlude to talk about what kernels do. Kernels are either part of a corn, a respectable military rank or decor of every computer you interact with depending on your perspective. So kernel runs directly on the hardware and it has a bunch of jobs, most of which are pretty simple and very important. It receives messages from the hardware, a new disc has been attached, a network packet arrived, everything that goes on electrically bubbles up to the kernel and gets dealt with.

It starts and it schedules programs. It says what's allowed to run, what, when and it lets your computer do all the things you're asking it to do at the same time. It controls and it organizes the storage devices on the computer. When you say write to this file the kernel says ahh, when he says write to the file he actually means this little spot on the disc. And it goes there and writes the data. Someone has to make that decision and that's the role of the file system inside the kernel. It passes messages between programs.

When two programs in the computer want to communicate, or two programs on different computers want to communicate over a network. They ask the kernel to pass a message, the kernel passes the message, gets it ready, sends it over to the kernel on the computer which receives the message, gets it ready for the program and sends it to the program over there. It allocates resources, memory, time to actually do work on a CPU, how much network bandwidth to give to who, all of that stuff is managed by the kernel.

And Docker is a program which manages the kernel. So Docker is well, three things. It's a program written in Go, Go is a nice upcoming systems language and its job is to manage several features of the kernel and use these features to build the concept of containers and images. So Docker primarily uses C groups or control groups to group processes together and give them the idea of being contained within their own little world.

That's what keeps one container from interfering with another. It uses name spaces, which is a feature of the Linux kernel which allows it to split the networking stack so you have one set of addresses for one container, another set of addresses for another container and other addresses for things that are not in containers at all. It uses copy on write file systems and various other approaches to build the idea of images to say you have this image, it doesn't change but you can run stuff on top of it.

And people have been doing this for years. Honestly almost none of what Docker does is truly new. They took things that people were working very hard to do and they made it easy, approachable, and they created a language around it for people to talk about it. And they made these things popular. So what Docker really does is make scripting distributed systems easy. And that's why it's taking off the way it is. These things that used to be the realm of very large enterprises with enormous budgets are now easily done on anyone's computer.

Of course you have to have a fairly peculiar definition of the word easy. So Docker is divided into two programs. It's the client and the server. These two programs communicate over a socket. That can be a network socket where the client is running on one computer and the server is running on a computer somewhere on a Cloud provider across the world, or they can be running directly on the same hardware, or they can be running on the same hardware with the server in a virtual machine, which is a common case for people doing this course.

In that case the client communicates over a network and sends message to the Docker server to say make a container, start a container, stop a container, that kind of stuff. When the client and server are running on the same computer, they can connect through a special file called a socket. And since they can communicate through a file and Docker can efficiently share files between hosts and containers, it means you can run the client inside Docker itself. So the traditional Docker scenario with a single host, you have Docker the program connects to the socket, sends commands to Docker the program, which is the server side.

And that creates containers or deletes containers all the rest. But it's pretty easy to run the client inside one of the containers and share the socket into that container, which allows the same messages to go through the same socket, get to the server running on the host and do everything that it would do normally. So let's take a little look at what that looks like in practice. The idea is to get a visceral feel for what it means to control Docker through its socket.

Now let's take a look at that Docker control socket. And as we see, it's just a file. If you write the proper data into this file in the right format then it will cause the Docker server to do things. If you're following along with this course from a Windows machine, this file won't be directly accessible though it's still available from other Docker containers. Next I'm gonna run the Docker client inside a container and give it access to the Docker control socket on my computer.

Docker run dash TI dash dash RM so it cleans up after itself, then the volume mount where I mount slash VAR slash RUN slash Docker dot sock into the container under exactly the same path. So we've given the Docker container a hook for its client to control its own server. Then I'm gonna use the image named Docker provided by Docker the company and we'll just run a shell.

Now that it's downloaded the image, let me clear the screen, and let's look at Docker. Docker info, yep we're running Docker. Docker run dash TI RM ubuntu bash. So now I am starting another container from a client within a container. And here I have it. Now this is not Docker in Docker, this is a client within a Docker container controlling a server that's outside that container.

This flexibility in where you control Docker from is one of the key ideas behind Docker and has been a major contributor to its success and popularity.