github.com/akerouanton/docker@v1.11.0-rc3/docs/understanding-docker.md (about) 1 <!--[metadata]> 2 +++ 3 aliases = ["/introduction/understanding-docker/"] 4 title = "Understand the architecture" 5 description = "Docker explained in depth" 6 keywords = ["docker, introduction, documentation, about, technology, understanding"] 7 [menu.main] 8 parent = "engine_use" 9 weight = -82 10 +++ 11 <![end-metadata]--> 12 13 # Understand the architecture 14 15 Docker is an open platform for developing, shipping, and running applications. 16 Docker is designed to deliver your applications faster. With Docker you can 17 separate your applications from your infrastructure and treat your 18 infrastructure like a managed application. Docker helps you ship code faster, 19 test faster, deploy faster, and shorten the cycle between writing code and 20 running code. 21 22 Docker does this by combining kernel containerization features with workflows 23 and tooling that help you manage and deploy your applications. 24 25 At its core, Docker provides a way to run almost any application securely 26 isolated in a container. The isolation and security allow you to run many 27 containers simultaneously on your host. The lightweight nature of containers, 28 which run without the extra load of a hypervisor, means you can get more out of 29 your hardware. 30 31 Surrounding the container is tooling and a platform which can help you in 32 several ways: 33 34 * Get your applications (and supporting components) into Docker containers 35 * Distribute and ship those containers to your teams for further development 36 and testing 37 * Deploy those applications to your production environment, 38 whether it is in a local data center or the Cloud 39 40 ## What can I use Docker for? 41 42 *Faster delivery of your applications* 43 44 Docker is perfect for helping you with the development lifecycle. Docker 45 allows your developers to develop on local containers that contain your 46 applications and services. It can then integrate into a continuous integration and 47 deployment workflow. 48 49 For example, your developers write code locally and share their development stack via 50 Docker with their colleagues. When they are ready, they push their code and the 51 stack they are developing onto a test environment and execute any required 52 tests. From the testing environment, you can then push the Docker images into 53 production and deploy your code. 54 55 *Deploying and scaling more easily* 56 57 Docker's container-based platform allows for highly portable workloads. Docker 58 containers can run on a developer's local host, on physical or virtual machines 59 in a data center, or in the Cloud. 60 61 Docker's portability and lightweight nature also make dynamically managing 62 workloads easy. You can use Docker to quickly scale up or tear down applications 63 and services. Docker's speed means that scaling can be near real time. 64 65 *Achieving higher density and running more workloads* 66 67 Docker is lightweight and fast. It provides a viable, cost-effective alternative 68 to hypervisor-based virtual machines. This is especially useful in high density 69 environments: for example, building your own Cloud or Platform-as-a-Service. But 70 it is also useful for small and medium deployments where you want to get more 71 out of the resources you have. 72 73 ## What are the major Docker components? 74 Docker has two major components: 75 76 77 * Docker Engine: the open source containerization platform. 78 * [Docker Hub](https://hub.docker.com): our Software-as-a-Service 79 platform for sharing and managing Docker containers. 80 81 82 > **Note:** Docker is licensed under the open source Apache 2.0 license. 83 84 ## What is Docker's architecture? 85 Docker uses a client-server architecture. The Docker *client* talks to the 86 Docker *daemon*, which does the heavy lifting of building, running, and 87 distributing your Docker containers. Both the Docker client and the daemon *can* 88 run on the same system, or you can connect a Docker client to a remote Docker 89 daemon. The Docker client and daemon communicate via sockets or through a 90 RESTful API. 91 92 ![Docker Architecture Diagram](article-img/architecture.svg) 93 94 ### The Docker daemon 95 As shown in the diagram above, the Docker daemon runs on a host machine. The 96 user does not directly interact with the daemon, but instead through the Docker 97 client. 98 99 ### The Docker client 100 The Docker client, in the form of the `docker` binary, is the primary user 101 interface to Docker. It accepts commands from the user and communicates back and 102 forth with a Docker daemon. 103 104 ### Inside Docker 105 To understand Docker's internals, you need to know about three resources: 106 107 * Docker images 108 * Docker registries 109 * Docker containers 110 111 #### Docker images 112 113 A Docker image is a read-only template. For example, an image could contain an Ubuntu 114 operating system with Apache and your web application installed. Images are used to create 115 Docker containers. Docker provides a simple way to build new images or update existing 116 images, or you can download Docker images that other people have already created. 117 Docker images are the **build** component of Docker. 118 119 #### Docker registries 120 Docker registries hold images. These are public or private stores from which you 121 upload or download images. The public Docker registry is provided with the 122 [Docker Hub](http://hub.docker.com). It serves a huge collection of existing 123 images for your use. These can be images you create yourself or you can use 124 images that others have previously created. Docker registries are the 125 **distribution** component of Docker. 126 For more information, go to [Docker Registry](https://docs.docker.com/registry/overview/) and 127 [Docker Trusted Registry](https://docs.docker.com/docker-trusted-registry/overview/). 128 129 #### Docker containers 130 Docker containers are similar to a directory. A Docker container holds everything that 131 is needed for an application to run. Each container is created from a Docker 132 image. Docker containers can be run, started, stopped, moved, and deleted. Each 133 container is an isolated and secure application platform. Docker containers are the 134 **run** component of Docker. 135 136 ### How does a Docker image work? 137 We've already seen that Docker images are read-only templates from which Docker 138 containers are launched. Each image consists of a series of layers. Docker 139 makes use of [union file systems](http://en.wikipedia.org/wiki/UnionFS) to 140 combine these layers into a single image. Union file systems allow files and 141 directories of separate file systems, known as branches, to be transparently 142 overlaid, forming a single coherent file system. 143 144 One of the reasons Docker is so lightweight is because of these layers. When you 145 change a Docker image—for example, update an application to a new version— a new layer 146 gets built. Thus, rather than replacing the whole image or entirely 147 rebuilding, as you may do with a virtual machine, only that layer is added or 148 updated. Now you don't need to distribute a whole new image, just the update, 149 making distributing Docker images faster and simpler. 150 151 Every image starts from a base image, for example `ubuntu`, a base Ubuntu image, 152 or `fedora`, a base Fedora image. You can also use images of your own as the 153 basis for a new image, for example if you have a base Apache image you could use 154 this as the base of all your web application images. 155 156 > **Note:** [Docker Hub](https://hub.docker.com) is a public registry and stores 157 images. 158 159 Docker images are then built from these base images using a simple, descriptive 160 set of steps we call *instructions*. Each instruction creates a new layer in our 161 image. Instructions include actions like: 162 163 * Run a command 164 * Add a file or directory 165 * Create an environment variable 166 * What process to run when launching a container from this image 167 168 These instructions are stored in a file called a `Dockerfile`. A `Dockerfile` is 169 a text based script that contains instructions and commands for building the image 170 from the base image. Docker reads this `Dockerfile` when you request a build of 171 an image, executes the instructions, and returns a final image. 172 173 ### How does a Docker registry work? 174 The Docker registry is the store for your Docker images. Once you build a Docker 175 image you can *push* it to a public registry such as [Docker Hub](https://hub.docker.com) 176 or to your own registry running behind your firewall. 177 178 Using the Docker client, you can search for already published images and then 179 pull them down to your Docker host to build containers from them. 180 181 [Docker Hub](https://hub.docker.com) provides both public and private storage 182 for images. Public storage is searchable and can be downloaded by anyone. 183 Private storage is excluded from search results and only you and your users can 184 pull images down and use them to build containers. You can [sign up for a storage plan 185 here](https://hub.docker.com/plans). 186 187 ### How does a container work? 188 A container consists of an operating system, user-added files, and meta-data. As 189 we've seen, each container is built from an image. That image tells Docker 190 what the container holds, what process to run when the container is launched, and 191 a variety of other configuration data. The Docker image is read-only. When 192 Docker runs a container from an image, it adds a read-write layer on top of the 193 image (using a union file system as we saw earlier) in which your application can 194 then run. 195 196 ### What happens when you run a container? 197 Either by using the `docker` binary or via the API, the Docker client tells the Docker 198 daemon to run a container. 199 200 $ docker run -i -t ubuntu /bin/bash 201 202 The Docker Engine client is launched using the `docker` binary with the `run` option 203 running a new container. The bare minimum the Docker client needs to tell the 204 Docker daemon to run the container is: 205 206 * What Docker image to build the container from, for example, `ubuntu` 207 * The command you want to run inside the container when it is launched, 208 for example,`/bin/bash` 209 210 So what happens under the hood when we run this command? 211 212 In order, Docker Engine does the following: 213 214 - **Pulls the `ubuntu` image:** Docker Engine checks for the presence of the `ubuntu` 215 image. If the image already exists, then Docker Engine uses it for the new container. 216 If it doesn't exist locally on the host, then Docker Engine pulls it from 217 [Docker Hub](https://hub.docker.com). If the image already exists, then Docker Engine 218 uses it for the new container. 219 - **Creates a new container:** Once Docker Engine has the image, it uses it to create a 220 container. 221 - **Allocates a filesystem and mounts a read-write _layer_:** The container is created in 222 the file system and a read-write layer is added to the image. 223 - **Allocates a network / bridge interface:** Creates a network interface that allows the 224 Docker container to talk to the local host. 225 - **Sets up an IP address:** Finds and attaches an available IP address from a pool. 226 - **Executes a process that you specify:** Runs your application, and; 227 - **Captures and provides application output:** Connects and logs standard input, outputs 228 and errors for you to see how your application is running. 229 230 You now have a running container! Now you can manage your container, interact with 231 your application and then, when finished, stop and remove your container. 232 233 ## The underlying technology 234 Docker is written in Go and makes use of several kernel features to 235 deliver the functionality we've seen. 236 237 ### Namespaces 238 Docker takes advantage of a technology called `namespaces` to provide the 239 isolated workspace we call the *container*. When you run a container, Docker 240 creates a set of *namespaces* for that container. 241 242 This provides a layer of isolation: each aspect of a container runs in its own 243 namespace and does not have access outside it. 244 245 Some of the namespaces that Docker Engine uses on Linux are: 246 247 - **The `pid` namespace:** Process isolation (PID: Process ID). 248 - **The `net` namespace:** Managing network interfaces (NET: 249 Networking). 250 - **The `ipc` namespace:** Managing access to IPC 251 resources (IPC: InterProcess Communication). 252 - **The `mnt` namespace:** Managing mount-points (MNT: Mount). 253 - **The `uts` namespace:** Isolating kernel and version identifiers. (UTS: Unix 254 Timesharing System). 255 256 ### Control groups 257 Docker Engine on Linux also makes use of another technology called `cgroups` or control groups. 258 A key to running applications in isolation is to have them only use the 259 resources you want. This ensures containers are good multi-tenant citizens on a 260 host. Control groups allow Docker Engine to share available hardware resources to 261 containers and, if required, set up limits and constraints. For example, 262 limiting the memory available to a specific container. 263 264 ### Union file systems 265 Union file systems, or UnionFS, are file systems that operate by creating layers, 266 making them very lightweight and fast. Docker Engine uses union file systems to provide 267 the building blocks for containers. Docker Engine can make use of several union file system variants 268 including: AUFS, btrfs, vfs, and DeviceMapper. 269 270 ### Container format 271 Docker Engine combines these components into a wrapper we call a container format. The 272 default container format is called `libcontainer`. In the future, Docker may 273 support other container formats, for example, by integrating with BSD Jails 274 or Solaris Zones. 275 276 ## Next steps 277 Read about [Installing Docker Engine](installation/index.md#installation). 278 Learn about the [Docker Engine User Guide](userguide/index.md).