mirror of
https://github.com/moby/moby.git
synced 2022-11-09 12:21:53 -05:00
Merge pull request #26256 from mstanleyjones/rewrite_understanding_docker
Rewrites to Understanding Docker topic for clarity
This commit is contained in:
commit
426a0af075
1 changed files with 191 additions and 167 deletions
|
@ -15,276 +15,300 @@ weight = -90
|
||||||
<![end-metadata]-->
|
<![end-metadata]-->
|
||||||
|
|
||||||
# Docker Overview
|
# Docker Overview
|
||||||
|
|
||||||
Docker is an open platform for developing, shipping, and running applications.
|
Docker is an open platform for developing, shipping, and running applications.
|
||||||
Docker is designed to deliver your applications faster. With Docker you can
|
Docker enables you to separate your applications from your infrastructure so
|
||||||
separate your applications from your infrastructure and treat your
|
you can deliver software quickly. With Docker, you can manage your infrastructure
|
||||||
infrastructure like a managed application. Docker helps you ship code faster,
|
in the same ways you manage your applications. By taking advantage of Docker's
|
||||||
test faster, deploy faster, and shorten the cycle between writing code and
|
methodoligies for shipping, testing, and deploying code quickly, you can
|
||||||
running code.
|
significantly reduce the delay between writing code and running it in production.
|
||||||
|
|
||||||
Docker does this by combining kernel containerization features with workflows
|
|
||||||
and tooling that help you manage and deploy your applications.
|
|
||||||
|
|
||||||
## What is the Docker platform?
|
## What is the Docker platform?
|
||||||
|
|
||||||
At its core, Docker provides a way to run almost any application securely
|
Docker provides the ability to package and run an application in a loosely isolated
|
||||||
isolated in a container. The isolation and security allow you to run many
|
environment called a container. The isolation and security allow you to run many
|
||||||
containers simultaneously on your host. The lightweight nature of containers,
|
containers simultaneously on a given host. Because of the lightweight nature of
|
||||||
which run without the extra load of a hypervisor, means you can get more out of
|
containers, which run without the extra load of a hypervisor, you can run more
|
||||||
your hardware.
|
containers on a given hardware combination than if you were using virtual machines.
|
||||||
|
|
||||||
Surrounding the container is tooling and a platform which can help you in
|
Docker provides tooling and a platform to manage the lifecycle of your containers:
|
||||||
several ways:
|
|
||||||
|
|
||||||
* Get your applications (and supporting components) into Docker containers
|
* Encapsulate your applications (and supporting components) into Docker containers
|
||||||
* Distribute and ship those containers to your teams for further development
|
* Distribute and ship those containers to your teams for further development
|
||||||
and testing
|
and testing
|
||||||
* Deploy those applications to your production environment,
|
* Deploy those applications to your production environment, whether it is in a
|
||||||
whether it is in a local data center or the Cloud
|
local data center or the Cloud
|
||||||
|
|
||||||
## What is Docker Engine?
|
## What is Docker Engine?
|
||||||
|
|
||||||
Docker Engine is a client-server application with these major components:
|
_Docker Engine_ is a client-server application with these major components:
|
||||||
|
|
||||||
* A server which is a type of long-running program called a daemon process.
|
* A server which is a type of long-running program called a daemon process.
|
||||||
|
|
||||||
* A REST API which specifies interfaces that programs can use to talk to the daemon and instruct it what to do.
|
* A REST API which specifies interfaces that programs can use to talk to the
|
||||||
|
daemon and instruct it what to do.
|
||||||
|
|
||||||
* A command line interface (CLI) client.
|
* A command line interface (CLI) client.
|
||||||
|
|
||||||
![Docker Engine Components Flow](article-img/engine-components-flow.png)
|
![Docker Engine Components Flow](article-img/engine-components-flow.png)
|
||||||
|
|
||||||
The CLI makes use of the Docker REST API to control or interact with the Docker daemon through scripting or direct CLI commands. Many other Docker applications make use of the underlying API and CLI.
|
The CLI uses the Docker REST API to control or interact with the Docker daemon
|
||||||
|
through scripting or direct CLI commands. Many other Docker applications use the
|
||||||
|
underlying API and CLI.
|
||||||
|
|
||||||
The daemon creates and manages Docker objects. Docker objects include images, containers, networks, data volumes, and so forth.
|
The daemon creates and manages Docker _objects_, such as images, containers,
|
||||||
|
networks, and data volumes.
|
||||||
|
|
||||||
> **Note:** Docker is licensed under the open source Apache 2.0 license.
|
> **Note:** Docker is licensed under the open source Apache 2.0 license.
|
||||||
|
|
||||||
## What can I use Docker for?
|
## What can I use Docker for?
|
||||||
|
|
||||||
*Faster delivery of your applications*
|
*Fast, consistent delivery of your applications*
|
||||||
|
|
||||||
Docker is perfect for helping you with the development lifecycle. Docker
|
Docker can streamline the development lifecycle by allowing developers to work in
|
||||||
allows your developers to develop on local containers that contain your
|
standardized environments using local containers which provide your applications
|
||||||
applications and services. It can then integrate into a continuous integration and
|
and services. You can also integrate Docker into your continuous integration and
|
||||||
deployment workflow.
|
continuous deployment (CI/CD) workflow.
|
||||||
|
|
||||||
For example, your developers write code locally and share their development stack via
|
Consider the following example scenario. Your developers write code locally and
|
||||||
Docker with their colleagues. When they are ready, they push their code and the
|
share their work with their colleagues using Docker containers. They can use
|
||||||
stack they are developing onto a test environment and execute any required
|
Docker to push their applications into a test environment and execute automated
|
||||||
tests. From the testing environment, you can then push the Docker images into
|
and manual tests. When developers find problems, they can fix them in the development
|
||||||
production and deploy your code.
|
environment and redeploy them to the test environment for testing. When testing is
|
||||||
|
complete, getting the fix to the customer is as simple as pushing the updated image
|
||||||
|
to the production environment.
|
||||||
|
|
||||||
*Deploying and scaling more easily*
|
*Responsive deployment and scaling*
|
||||||
|
|
||||||
Docker's container-based platform allows for highly portable workloads. Docker
|
Docker's container-based platform allows for highly portable workloads. Docker
|
||||||
containers can run on a developer's local host, on physical or virtual machines
|
containers can run on a developer's local host, on physical or virtual machines
|
||||||
in a data center, or in the Cloud.
|
in a data center, in the Cloud, or in a mixture of environments.
|
||||||
|
|
||||||
Docker's portability and lightweight nature also make dynamically managing
|
Docker's portability and lightweight nature also make it easy to dynamically manage
|
||||||
workloads easy. You can use Docker to quickly scale up or tear down applications
|
workloads, scaling up or tearing down applications and services as business
|
||||||
and services. Docker's speed means that scaling can be near real time.
|
needs dictate, in near real time.
|
||||||
|
|
||||||
*Achieving higher density and running more workloads*
|
*Running more workloads on the same hardware*
|
||||||
|
|
||||||
Docker is lightweight and fast. It provides a viable, cost-effective alternative
|
Docker is lightweight and fast. It provides a viable, cost-effective alternative
|
||||||
to hypervisor-based virtual machines. This is especially useful in high density
|
to hypervisor-based virtual machines, allowing you to use more of your compute
|
||||||
environments: for example, building your own Cloud or Platform-as-a-Service. But
|
capacity to achieve your business goals. This is useful in high density
|
||||||
it is also useful for small and medium deployments where you want to get more
|
environments and for small and medium deployments where you need to do more with
|
||||||
out of the resources you have.
|
fewer resources.
|
||||||
|
|
||||||
## What is Docker's architecture?
|
## What is Docker's architecture?
|
||||||
Docker uses a client-server architecture. The Docker *client* talks to the
|
Docker uses a client-server architecture. The Docker *client* talks to the
|
||||||
Docker *daemon*, which does the heavy lifting of building, running, and
|
Docker *daemon*, which does the heavy lifting of building, running, and
|
||||||
distributing your Docker containers. Both the Docker client and the daemon *can*
|
distributing your Docker containers. The Docker client and daemon *can*
|
||||||
run on the same system, or you can connect a Docker client to a remote Docker
|
run on the same system, or you can connect a Docker client to a remote Docker
|
||||||
daemon. The Docker client and daemon communicate via sockets or through a
|
daemon. The Docker client and daemon communicate via sockets or through a
|
||||||
RESTful API.
|
REST API.
|
||||||
|
|
||||||
![Docker Architecture Diagram](article-img/architecture.svg)
|
![Docker Architecture Diagram](article-img/architecture.svg)
|
||||||
|
|
||||||
### The Docker daemon
|
### The Docker daemon
|
||||||
As shown in the diagram above, the Docker daemon runs on a host machine. The
|
The Docker daemon runs on a host machine. The user uses the Docker client to
|
||||||
user does not directly interact with the daemon, but instead through the Docker
|
interact with the daemon.
|
||||||
client.
|
|
||||||
|
|
||||||
### The Docker client
|
### The Docker client
|
||||||
The Docker client, in the form of the `docker` binary, is the primary user
|
The Docker client, in the form of the `docker` binary, is the primary user
|
||||||
interface to Docker. It accepts commands from the user and communicates back and
|
interface to Docker. It accepts commands and configuration flags from the user and
|
||||||
forth with a Docker daemon.
|
communicates with a Docker daemon. One client can even communicate with multiple
|
||||||
|
unrelated daemons.
|
||||||
|
|
||||||
### Inside Docker
|
### Inside Docker
|
||||||
To understand Docker's internals, you need to know about three resources:
|
To understand Docker's internals, you need to know about _images_, _registries_,
|
||||||
|
and _containers_.
|
||||||
* Docker images
|
|
||||||
* Docker registries
|
|
||||||
* Docker containers
|
|
||||||
|
|
||||||
#### Docker images
|
#### Docker images
|
||||||
|
|
||||||
A Docker image is a read-only template. For example, an image could contain an Ubuntu
|
A Docker _image_ is a read-only template with instructions for creating a Docker
|
||||||
operating system with Apache and your web application installed. Images are used to create
|
container. For example, an image might contain an Ubuntu operating system with
|
||||||
Docker containers. Docker provides a simple way to build new images or update existing
|
Apache web server and your web application installed. You can build or update
|
||||||
images, or you can download Docker images that other people have already created.
|
images from scratch or download and use images created by others. An image may be
|
||||||
|
based on, or may extend, one or more other images. A docker image is described in
|
||||||
|
text file called a _Dockerfile_, which has a simple, well-defined syntax. For more
|
||||||
|
details about images, see [How does a Docker image work?](how-does-a-docker-image-work).
|
||||||
|
|
||||||
Docker images are the **build** component of Docker.
|
Docker images are the **build** component of Docker.
|
||||||
|
|
||||||
#### Docker registries
|
|
||||||
Docker registries hold images. These are public or private stores from which you
|
|
||||||
upload or download images. The public Docker registry is provided with the
|
|
||||||
[Docker Hub](http://hub.docker.com). It serves a huge collection of existing
|
|
||||||
images for your use. These can be images you create yourself or you can use
|
|
||||||
images that others have previously created. Docker registries are the
|
|
||||||
**distribution** component of Docker.
|
|
||||||
For more information, go to [Docker Registry](https://docs.docker.com/registry/overview/) and
|
|
||||||
[Docker Trusted Registry](https://docs.docker.com/docker-trusted-registry/overview/).
|
|
||||||
|
|
||||||
#### Docker containers
|
#### Docker containers
|
||||||
Docker containers are similar to a directory. A Docker container holds everything that
|
A Docker container is a runnable instance of a Docker image. You can run, start,
|
||||||
is needed for an application to run. Each container is created from a Docker
|
stop, move, or delete a container using Docker API or CLI commands. When you run
|
||||||
image. Docker containers can be run, started, stopped, moved, and deleted. Each
|
a container, you can provide configuration metadata such as networking information
|
||||||
container is an isolated and secure application platform. Docker containers are the
|
or environment variables. Each container is an isolated and secure application
|
||||||
**run** component of Docker.
|
platform, but can be given access to resources running in a different host or
|
||||||
|
container, as well as persistent storage or databases. For more details about
|
||||||
|
containers, see [How does a container work?](how-does-a-container-work).
|
||||||
|
|
||||||
|
Docker containers are the **run** component of Docker.
|
||||||
|
|
||||||
|
#### Docker registries
|
||||||
|
A docker registry is a library of images. A registry can be public or private,
|
||||||
|
and can be on the same server as the Docker daemon or Docker client, or on a
|
||||||
|
totally separate server. For more details about registries, see
|
||||||
|
[How does a Docker registry work?](how-does-a-docker-registry-work)
|
||||||
|
|
||||||
|
Docker registries are the **distribution** component of Docker.
|
||||||
|
|
||||||
|
#### Docker services
|
||||||
|
A Docker _service_ allows a _swarm_ of Docker nodes to work together, running a
|
||||||
|
defined number of instances of a replica task, which is itself a Docker image.
|
||||||
|
You can specify the number of concurrent replica tasks to run, and the swarm
|
||||||
|
manager ensures that the load is spread evenly across the worker nodes. To
|
||||||
|
the consumer, the Docker service appears to be a single application. Docker
|
||||||
|
Engine supports swarm mode in Docker 1.12 and higher.
|
||||||
|
|
||||||
|
Docker services are the **scalability** component of Docker.
|
||||||
|
|
||||||
### How does a Docker image work?
|
### How does a Docker image work?
|
||||||
We've already seen that Docker images are read-only templates from which Docker
|
Docker images are read-only templates from which Docker containers are instantiated.
|
||||||
containers are launched. Each image consists of a series of layers. Docker
|
Each image consists of a series of layers. Docker uses
|
||||||
makes use of [union file systems](http://en.wikipedia.org/wiki/UnionFS) to
|
[union file systems](http://en.wikipedia.org/wiki/UnionFS) to
|
||||||
combine these layers into a single image. Union file systems allow files and
|
combine these layers into a single image. Union file systems allow files and
|
||||||
directories of separate file systems, known as branches, to be transparently
|
directories of separate file systems, known as branches, to be transparently
|
||||||
overlaid, forming a single coherent file system.
|
overlaid, forming a single coherent file system.
|
||||||
|
|
||||||
One of the reasons Docker is so lightweight is because of these layers. When you
|
These layers are one of the reasons Docker is so lightweight. When you
|
||||||
change a Docker image—for example, update an application to a new version— a new layer
|
change a Docker image, such as when you update an application to a new version,
|
||||||
gets built. Thus, rather than replacing the whole image or entirely
|
a new layer is built and replaces only the layer it updates. The other layers
|
||||||
rebuilding, as you may do with a virtual machine, only that layer is added or
|
remain intact. To distribute the update, you only need to transfer the updated
|
||||||
updated. Now you don't need to distribute a whole new image, just the update,
|
layer. Layering speeds up distribution of Docker images. Docker determines which
|
||||||
making distributing Docker images faster and simpler.
|
layers need to be updated at runtime.
|
||||||
|
|
||||||
Every image starts from a base image, for example `ubuntu`, a base Ubuntu image,
|
An image is defined in a Dockerfile. Every image starts from a base image, such as
|
||||||
or `fedora`, a base Fedora image. You can also use images of your own as the
|
`ubuntu`, a base Ubuntu image, or `fedora`, a base Fedora image. You can also use
|
||||||
basis for a new image, for example if you have a base Apache image you could use
|
images of your own as the basis for a new image, for example if you have a base
|
||||||
this as the base of all your web application images.
|
Apache image you could use this as the base of all your web application images. The
|
||||||
|
base image is defined using the `FROM` keyword in the dockerfile.
|
||||||
|
|
||||||
> **Note:** [Docker Hub](https://hub.docker.com) is a public registry and stores
|
> **Note:** [Docker Hub](https://hub.docker.com) is a public registry and stores
|
||||||
images.
|
images.
|
||||||
|
|
||||||
Docker images are then built from these base images using a simple, descriptive
|
The docker image is built from the base image using a simple, descriptive
|
||||||
set of steps we call *instructions*. Each instruction creates a new layer in our
|
set of steps we call *instructions*, which are stored in a `Dockerfile`. Each
|
||||||
image. Instructions include actions like:
|
instruction creates a new layer in the image. Some examples of Dockerfile
|
||||||
|
instructions are:
|
||||||
|
|
||||||
* Run a command
|
* Specify the base image (`FROM`)
|
||||||
* Add a file or directory
|
* Specify the maintainer (`MAINTAINER`)
|
||||||
* Create an environment variable
|
* Run a command (`RUN`)
|
||||||
* What process to run when launching a container from this image
|
* Add a file or directory (`ADD`)
|
||||||
|
* Create an environment variable (`ENV`)
|
||||||
|
* What process to run when launching a container from this image (`CMD`)
|
||||||
|
|
||||||
These instructions are stored in a file called a `Dockerfile`. A `Dockerfile` is
|
Docker reads this `Dockerfile` when you request a build of
|
||||||
a text based script that contains instructions and commands for building the image
|
an image, executes the instructions, and returns the image.
|
||||||
from the base image. Docker reads this `Dockerfile` when you request a build of
|
|
||||||
an image, executes the instructions, and returns a final image.
|
|
||||||
|
|
||||||
### How does a Docker registry work?
|
### How does a Docker registry work?
|
||||||
The Docker registry is the store for your Docker images. Once you build a Docker
|
A Docker registry stores Docker images. After you build a Docker image, you
|
||||||
image you can *push* it to a public registry such as [Docker Hub](https://hub.docker.com)
|
can *push* it to a public registry such as [Docker Hub](https://hub.docker.com)
|
||||||
or to your own registry running behind your firewall.
|
or to a private registry running behind your firewall. You can also search for
|
||||||
|
existing images and pull them from the registry to a host.
|
||||||
|
|
||||||
Using the Docker client, you can search for already published images and then
|
[Docker Hub](http://hub.docker.com) is a public Docker
|
||||||
pull them down to your Docker host to build containers from them.
|
registry which serves a huge collection of existing images and allows you to
|
||||||
|
contribute your own. For more information, go to
|
||||||
|
[Docker Registry](https://docs.docker.com/registry/overview/) and
|
||||||
|
[Docker Trusted Registry](https://docs.docker.com/docker-trusted-registry/overview/).
|
||||||
|
|
||||||
[Docker Hub](https://hub.docker.com) provides both public and private storage
|
[Docker store](http://store.docker.com) allows you to buy and sell Docker images.
|
||||||
for images. Public storage is searchable and can be downloaded by anyone.
|
For image, you can buy a Docker image containing an application or service from
|
||||||
Private storage is excluded from search results and only you and your users can
|
the software vendor, and use the image to deploy the application into your
|
||||||
pull images down and use them to build containers. You can [sign up for a storage plan
|
testing, staging, and production environments, and upgrade the application by pulling
|
||||||
here](https://www.docker.com/pricing).
|
the new version of the image and redeploying the containers. Docker Store is currently
|
||||||
|
in private beta.
|
||||||
|
|
||||||
### How does a container work?
|
### How does a container work?
|
||||||
A container consists of an operating system, user-added files, and meta-data. As
|
A container uses the host machine's Linux kernel, and consists of any extra files
|
||||||
we've seen, each container is built from an image. That image tells Docker
|
you add when the image is created, along with metadata associated with the container
|
||||||
what the container holds, what process to run when the container is launched, and
|
at creation or when the container is started. Each container is built from an image.
|
||||||
a variety of other configuration data. The Docker image is read-only. When
|
The image defines the container's contents, which process to run when the container
|
||||||
Docker runs a container from an image, it adds a read-write layer on top of the
|
is launched, and a variety of other configuration details. The Docker image is
|
||||||
image (using a union file system as we saw earlier) in which your application can
|
read-only. When Docker runs a container from an image, it adds a read-write layer
|
||||||
then run.
|
on top of the image (using a UnionFS as we saw earlier) in which your application
|
||||||
|
runs.
|
||||||
|
|
||||||
### What happens when you run a container?
|
#### What happens when you run a container?
|
||||||
Either by using the `docker` binary or via the API, the Docker client tells the Docker
|
When you use the `docker run` CLI command or the equivalent API, the Docker Engine
|
||||||
daemon to run a container.
|
client instructs the Docker daemon to run a container. This example tells the
|
||||||
|
Docker daemon to run a container using the `ubuntu` Docker image, to remain in
|
||||||
|
the foreground in interactive mode (`-i`), and to run the `/bin/bash` command.
|
||||||
|
|
||||||
$ docker run -i -t ubuntu /bin/bash
|
$ docker run -i -t ubuntu /bin/bash
|
||||||
|
|
||||||
The Docker Engine client is launched using the `docker` binary with the `run` option
|
|
||||||
running a new container. The bare minimum the Docker client needs to tell the
|
|
||||||
Docker daemon to run the container is:
|
|
||||||
|
|
||||||
* What Docker image to build the container from, for example, `ubuntu`
|
When you run this command, Docker Engine does the following:
|
||||||
* The command you want to run inside the container when it is launched,
|
|
||||||
for example,`/bin/bash`
|
|
||||||
|
|
||||||
So what happens under the hood when we run this command?
|
1. **Pulls the `ubuntu` image:** Docker Engine checks for the presence of the
|
||||||
|
`ubuntu` image. If the image already exists locally, Docker Engine uses it for
|
||||||
In order, Docker Engine does the following:
|
the new container. Otherwise, then Docker Engine pulls it from
|
||||||
|
|
||||||
- **Pulls the `ubuntu` image:** Docker Engine checks for the presence of the `ubuntu`
|
|
||||||
image. If the image already exists, then Docker Engine uses it for the new container.
|
|
||||||
If it doesn't exist locally on the host, then Docker Engine pulls it from
|
|
||||||
[Docker Hub](https://hub.docker.com).
|
[Docker Hub](https://hub.docker.com).
|
||||||
- **Creates a new container:** Once Docker Engine has the image, it uses it to create a
|
|
||||||
container.
|
|
||||||
- **Allocates a filesystem and mounts a read-write _layer_:** The container is created in
|
|
||||||
the file system and a read-write layer is added to the image.
|
|
||||||
- **Allocates a network / bridge interface:** Creates a network interface that allows the
|
|
||||||
Docker container to talk to the local host.
|
|
||||||
- **Sets up an IP address:** Finds and attaches an available IP address from a pool.
|
|
||||||
- **Executes a process that you specify:** Runs your application, and;
|
|
||||||
- **Captures and provides application output:** Connects and logs standard input, outputs
|
|
||||||
and errors for you to see how your application is running.
|
|
||||||
|
|
||||||
You now have a running container! Now you can manage your container, interact with
|
1. **Creates a new container:** Docker uses the image to create a container.
|
||||||
your application and then, when finished, stop and remove your container.
|
|
||||||
|
1. **Allocates a filesystem and mounts a read-write _layer_:** The container is
|
||||||
|
created in the file system and a read-write layer is added to the image.
|
||||||
|
|
||||||
|
1. **Allocates a network / bridge interface:** Creates a network interface that
|
||||||
|
allows the Docker container to talk to the local host.
|
||||||
|
|
||||||
|
1. **Sets up an IP address:** Finds and attaches an available IP address from a
|
||||||
|
pool.
|
||||||
|
|
||||||
|
1. **Executes a process that you specify:** Executes the `/bin/bash` executable.
|
||||||
|
|
||||||
|
1. **Captures and provides application output:** Connects and logs standard input,
|
||||||
|
outputs and errors for you to see how your application is running, because you
|
||||||
|
requested interactive mode.
|
||||||
|
|
||||||
|
Your container is now running. You can manage and interact with it, use the services
|
||||||
|
and applications it provides, and eventually stop and remove it.
|
||||||
|
|
||||||
## The underlying technology
|
## The underlying technology
|
||||||
Docker is written in Go and makes use of several kernel features to
|
Docker is written in [Go](https://golang.org/) and takes advantage of several
|
||||||
deliver the functionality we've seen.
|
features of the Linux kernel to deliver its functionality.
|
||||||
|
|
||||||
### Namespaces
|
### Namespaces
|
||||||
Docker takes advantage of a technology called `namespaces` to provide the
|
Docker uses a technology called `namespaces` to provide the isolated workspace
|
||||||
isolated workspace we call the *container*. When you run a container, Docker
|
called the *container*. When you run a container, Docker creates a set of
|
||||||
creates a set of *namespaces* for that container.
|
*namespaces* for that container.
|
||||||
|
|
||||||
This provides a layer of isolation: each aspect of a container runs in its own
|
These namespaces provide a layer of isolation. Each aspect of a container runs
|
||||||
namespace and does not have access outside of it.
|
in a separate namespace and its access is limited to that namespace.
|
||||||
|
|
||||||
Some of the namespaces that Docker Engine uses on Linux are:
|
Docker Engine uses namespaces such as the following on Linux:
|
||||||
|
|
||||||
- **The `pid` namespace:** Process isolation (PID: Process ID).
|
- **The `pid` namespace:** Process isolation (PID: Process ID).
|
||||||
- **The `net` namespace:** Managing network interfaces (NET:
|
- **The `net` namespace:** Managing network interfaces (NET:
|
||||||
Networking).
|
Networking).
|
||||||
- **The `ipc` namespace:** Managing access to IPC
|
- **The `ipc` namespace:** Managing access to IPC
|
||||||
resources (IPC: InterProcess Communication).
|
resources (IPC: InterProcess Communication).
|
||||||
- **The `mnt` namespace:** Managing mount-points (MNT: Mount).
|
- **The `mnt` namespace:** Managing filesystem mount points (MNT: Mount).
|
||||||
- **The `uts` namespace:** Isolating kernel and version identifiers. (UTS: Unix
|
- **The `uts` namespace:** Isolating kernel and version identifiers. (UTS: Unix
|
||||||
Timesharing System).
|
Timesharing System).
|
||||||
|
|
||||||
### Control groups
|
### Control groups
|
||||||
Docker Engine on Linux also makes use of another technology called `cgroups` or control groups.
|
Docker Engine on Linux also relies on another technology called _control groups_
|
||||||
A key to running applications in isolation is to have them only use the
|
(`cgroups`). A cgroup limits an application to a specific set of resources.
|
||||||
resources you want. This ensures containers are good multi-tenant citizens on a
|
Control groups allow Docker Engine to share available hardware resources to
|
||||||
host. Control groups allow Docker Engine to share available hardware resources to
|
containers and optionally enforce limits and constraints. For example,
|
||||||
containers and, if required, set up limits and constraints. For example,
|
you can limit the memory available to a specific container.
|
||||||
limiting the memory available to a specific container.
|
|
||||||
|
|
||||||
### Union file systems
|
### Union file systems
|
||||||
Union file systems, or UnionFS, are file systems that operate by creating layers,
|
Union file systems, or UnionFS, are file systems that operate by creating layers,
|
||||||
making them very lightweight and fast. Docker Engine uses union file systems to provide
|
making them very lightweight and fast. Docker Engine uses UnionFS to provide
|
||||||
the building blocks for containers. Docker Engine can make use of several union file system variants
|
the building blocks for containers. Docker Engine can use multiple UnionFS variants,
|
||||||
including: AUFS, btrfs, vfs, and DeviceMapper.
|
including AUFS, btrfs, vfs, and DeviceMapper.
|
||||||
|
|
||||||
### Container format
|
### Container format
|
||||||
Docker Engine combines these components into a wrapper we call a container format. The
|
Docker Engine combines the namespaces, control groups, and UnionFS into a wrapper
|
||||||
default container format is called `libcontainer`. In the future, Docker may
|
called a container format. The default container format is `libcontainer`. In
|
||||||
support other container formats, for example, by integrating with BSD Jails
|
the future, Docker may support other container formats by integrating with
|
||||||
or Solaris Zones.
|
technologies such as BSD Jails or Solaris Zones.
|
||||||
|
|
||||||
## Next steps
|
## Next steps
|
||||||
Read about [Installing Docker Engine](installation/index.md#installation).
|
- Read about [Installing Docker Engine](installation/index.md#installation).
|
||||||
Learn about the [Docker Engine User Guide](userguide/index.md).
|
- Get hands-on experience with the [Get Started With Docker](getstarted/index.md)
|
||||||
|
tutorial.
|
||||||
|
- Check out examples and deep dive topics in the
|
||||||
|
[Docker Engine User Guide](userguide/index.md).
|
||||||
|
|
Loading…
Reference in a new issue