mirror of https://github.com/docker/docs.git
Rewrites to Docker Overview content (#2689)
This commit is contained in:
Misty Stanley-Jones
GitHub
parent
4d940d87ce
commit
f9d6b41fcf
|
|
@ -164,6 +164,8 @@ guides:
|
|||
title: Network containers
|
||||
- path: /engine/tutorials/dockervolumes/
|
||||
title: Manage data in containers
|
||||
- path: /engine/docker-overview/
|
||||
title: Docker overview
|
||||
- sectiontitle: User Guide
|
||||
section:
|
||||
- path: /engine/userguide/intro/
|
||||
|
|
|
|||
|
|
@ -0,0 +1,274 @@
|
|||
---
|
||||
description: Docker explained in depth
|
||||
keywords: docker, introduction, documentation, about, technology, understanding
|
||||
redirect_from:
|
||||
- /introduction/understanding-docker/
|
||||
- /engine/userguide/basics/
|
||||
- /engine/introduction/understanding-docker/
|
||||
- /engine/understanding-docker/
|
||||
title: Docker overview
|
||||
---
|
||||
|
||||
Docker is an open platform for developing, shipping, and running applications.
|
||||
Docker enables you to separate your applications from your infrastructure so
|
||||
you can deliver software quickly. With Docker, you can manage your infrastructure
|
||||
in the same ways you manage your applications. By taking advantage of Docker's
|
||||
methodologies for shipping, testing, and deploying code quickly, you can
|
||||
significantly reduce the delay between writing code and running it in production.
|
||||
|
||||
## The Docker platform
|
||||
|
||||
Docker provides the ability to package and run an application in a loosely isolated
|
||||
environment called a container. The isolation and security allow you to run many
|
||||
containers simultaneously on a given host. Containers are lightweight because
|
||||
they don't need the extra load of a hypervisor, but run directly within the host
|
||||
machine's kernel. This means you can run more containers on a given hardware
|
||||
combination than if you were using virtual machines. You can even run Docker
|
||||
containers within host machines that are actually virtual machines!
|
||||
|
||||
Docker provides tooling and a platform to manage the lifecycle of your containers:
|
||||
|
||||
* Develop your application and its supporting components using containers.
|
||||
* The container becomes the unit for distributing and testing your application.
|
||||
* When you're ready, deploy your application into your production environment,
|
||||
as a container or an orchestrated service. This works the same whether your
|
||||
production environment is a local data center, a cloud provider, or a hybrid
|
||||
of the two.
|
||||
|
||||
## Docker Engine
|
||||
|
||||
_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 (the
|
||||
`dockerd` command).
|
||||
|
||||
* 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 (the `docker` command).
|
||||
|
||||
|
||||
|
||||
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_, such as images, containers,
|
||||
networks, and volumes.
|
||||
|
||||
> **Note**: Docker is licensed under the open source Apache 2.0 license.
|
||||
|
||||
For more details, see [Docker Architecture](#docker-architecture) below.
|
||||
|
||||
## What can I use Docker for?
|
||||
|
||||
**Fast, consistent delivery of your applications**
|
||||
|
||||
Docker streamlines the development lifecycle by allowing developers to work in
|
||||
standardized environments using local containers which provide your applications
|
||||
and services. Containers are great for continuous integration and continuous
|
||||
development (CI/CD) workflows.
|
||||
|
||||
Consider the following example scenario.
|
||||
|
||||
- Your developers write code locally and share their work with their colleagues
|
||||
using Docker containers.
|
||||
- They use Docker to push their applications into a test environment and execute
|
||||
automated and manual tests.
|
||||
- When developers find bugs, they can fix them in the development environment
|
||||
and redeploy them to the test environment for testing and validation.
|
||||
- When testing is complete, getting the fix to the customer is as simple as
|
||||
pushing the updated image to the production environment.
|
||||
|
||||
**Responsive deployment and scaling**
|
||||
|
||||
Docker's container-based platform allows for highly portable workloads. Docker
|
||||
containers can run on a developer's local laptop, on physical or virtual
|
||||
machines in a data center, on cloud providers, or in a mixture of environments.
|
||||
|
||||
Docker's portability and lightweight nature also make it easy to dynamically
|
||||
manage workloads, scaling up or tearing down applications and services as
|
||||
business needs dictate, in near real time.
|
||||
|
||||
**Running more workloads on the same hardware**
|
||||
|
||||
Docker is lightweight and fast. It provides a viable, cost-effective alternative
|
||||
to hypervisor-based virtual machines, so you can use more of your compute
|
||||
capacity to achieve your business goals. Docker is perfect for high density
|
||||
environments and for small and medium deployments where you need to do more with
|
||||
fewer resources.
|
||||
|
||||
## Docker architecture
|
||||
|
||||
Docker uses a client-server architecture. The Docker *client* talks to the
|
||||
Docker *daemon*, which does the heavy lifting of building, running, and
|
||||
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
|
||||
daemon. The Docker client and daemon communicate using a REST API, over UNIX
|
||||
sockets or a network interface.
|
||||
|
||||
|
||||
|
||||
### The Docker daemon
|
||||
|
||||
The Docker daemon (`dockerd`) listens for Docker API requests and manages Docker
|
||||
objects such as images, containers, networks, and volumes. A daemon can also
|
||||
communicate with other daemons to manage Docker services.
|
||||
|
||||
### The Docker client
|
||||
|
||||
The Docker client (`docker`) is the primary way that many Docker users interact
|
||||
with Docker. When you use commands such as `docker run`, the client sends these
|
||||
commands to `dockerd`, which carries them out. The `docker` command uses the
|
||||
Docker API. The Docker client can communicate with more than one daemon.
|
||||
|
||||
### Docker registries
|
||||
|
||||
A Docker _registry_ stores Docker images. Docker Hub and Docker Cloud are public
|
||||
registries that anyone can use, and Docker is configured to look for images on
|
||||
Docker Hub by default. You can even run your own private registry. If you use
|
||||
Docker Datacenter (DDC), it includes Docker Trusted Registry (DTR).
|
||||
|
||||
When you use the `docker pull` or `docker run` commands, the required images are
|
||||
pulled from your configured registry. When you use the `docker push` command,
|
||||
your image is pushed to your confiured registry.
|
||||
|
||||
[Docker store](http://store.docker.com) allows you to buy and sell Docker images
|
||||
or distribute them for free. For instance, you can buy a Docker image containing
|
||||
an application or service from a software vendor and use the image to deploy
|
||||
the application into your testing, staging, and production environments. You can
|
||||
upgrade the application by pulling the new version of the image and redeploying
|
||||
the containers.
|
||||
|
||||
### Docker objects
|
||||
|
||||
When you use Docker, you are creating and using images, containers, networks,
|
||||
volumes, plugins, and other objects. This section is a brief overview of some
|
||||
of those objects.
|
||||
|
||||
#### Images
|
||||
|
||||
An _image_ is a read-only template with instructions for creating a Docker
|
||||
container. Often, an image is _based on_ another image, with some additional
|
||||
customization. For example, you may build an image which is based on the `ubuntu`
|
||||
image, but installs the Apache web server and your application, as well as the
|
||||
configuration details needed to make your application run.
|
||||
|
||||
You might create your own images or you might only use those created by others
|
||||
and published in a registry. To build your own image, you create a _Dockerfile_
|
||||
with a simple syntax for defining the steps needed to create the image and run
|
||||
it. Each instruction in a Dockerfile creates a layer in the image. When you
|
||||
change the Dockerfile and rebuild the image, only those layers which have
|
||||
changed are rebuilt. This is part of what makes images so lightweight, small,
|
||||
and fast, when compared to other virtualization technologies.
|
||||
|
||||
#### Containers
|
||||
|
||||
A container is a runnable instance of an image. You can create, run, stop,
|
||||
move, or delete a container using the Docker API or CLI. You can connect a
|
||||
container to one or more networks, attach storage to it, or even create a new
|
||||
image based on its current state.
|
||||
|
||||
By default, a container is relatively well isolated from other containers and
|
||||
its host machine. You can control how isolated a container's network, storage,
|
||||
or other underlying subsystems are from other containers or from the host
|
||||
machine.
|
||||
|
||||
A container is defined by its image as well as any configuration options you
|
||||
provide to it when you create or run it. When a container stops, any changes to
|
||||
its state that are not stored in persistent storage disappears.
|
||||
|
||||
##### Example `docker run` command
|
||||
|
||||
The following command runs an `ubuntu` container, attaches interactively to your
|
||||
local command-line session, and runs `/bin/bash`.
|
||||
|
||||
```bash
|
||||
$ docker run -i -t ubuntu /bin/bash
|
||||
```
|
||||
|
||||
When you run this command, the following happens (assuming you have are using
|
||||
the default registry configuration):
|
||||
|
||||
1. If you do not have the `ubuntu` image locally, Docker pulls it from your
|
||||
configured registry, as though you had run `docker pull ubuntu` manually.
|
||||
|
||||
2. Docker creates a new container, as though you had run a `docker create`
|
||||
command manually.
|
||||
|
||||
3. Docker allocates a read-write filesystem to the container, as its final
|
||||
layer. This allows a running container to create or modify files and
|
||||
directories in its local filesystem.
|
||||
|
||||
4. Docker creates a network interface to connect the container to the default
|
||||
network, since you did not specify any networking options. This includes
|
||||
assigning an IP address to the container. By default, containers can
|
||||
connect to external networks using the host machine's network connection.
|
||||
|
||||
5. Docker starts the container and executes `/bin/bash`. Because the container
|
||||
is run interactively and attached to your terminal (due to the `-i` and `-t`)
|
||||
flags, you can provide input using your keyboard and output is logged to
|
||||
your terminal.
|
||||
|
||||
6. When you type `exit` to terminate the `/bin/bash` command, the container
|
||||
stops but is not removed. You can start it again or remove it.
|
||||
|
||||
#### Services
|
||||
|
||||
Services allow you to scale containers across multiple Docker daemons, which
|
||||
all work together as a _swarm_ with multiple _managers_ and _workers_. Each
|
||||
member of a swarm is a Docker daemon, and the daemons all communicate using
|
||||
the Docker API. A service allows you to define the desired state, such as the
|
||||
number of replicas of the service that must be available at any given time.
|
||||
By default, the service is load-balanced across all 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.
|
||||
|
||||
## The underlying technology
|
||||
Docker is written in [Go](https://golang.org/) and takes advantage of several
|
||||
features of the Linux kernel to deliver its functionality.
|
||||
|
||||
### Namespaces
|
||||
Docker uses a technology called `namespaces` to provide the isolated workspace
|
||||
called the *container*. When you run a container, Docker creates a set of
|
||||
*namespaces* for that container.
|
||||
|
||||
These namespaces provide a layer of isolation. Each aspect of a container runs
|
||||
in a separate namespace and its access is limited to that namespace.
|
||||
|
||||
Docker Engine uses namespaces such as the following on Linux:
|
||||
|
||||
- **The `pid` namespace:** Process isolation (PID: Process ID).
|
||||
- **The `net` namespace:** Managing network interfaces (NET:
|
||||
Networking).
|
||||
- **The `ipc` namespace:** Managing access to IPC
|
||||
resources (IPC: InterProcess Communication).
|
||||
- **The `mnt` namespace:** Managing filesystem mount points (MNT: Mount).
|
||||
- **The `uts` namespace:** Isolating kernel and version identifiers. (UTS: Unix
|
||||
Timesharing System).
|
||||
|
||||
### Control groups
|
||||
Docker Engine on Linux also relies on another technology called _control groups_
|
||||
(`cgroups`). A cgroup limits an application to a specific set of resources.
|
||||
Control groups allow Docker Engine to share available hardware resources to
|
||||
containers and optionally enforce limits and constraints. For example,
|
||||
you can limit the memory available to a specific container.
|
||||
|
||||
### Union file systems
|
||||
Union file systems, or UnionFS, are file systems that operate by creating layers,
|
||||
making them very lightweight and fast. Docker Engine uses UnionFS to provide
|
||||
the building blocks for containers. Docker Engine can use multiple UnionFS variants,
|
||||
including AUFS, btrfs, vfs, and DeviceMapper.
|
||||
|
||||
### Container format
|
||||
Docker Engine combines the namespaces, control groups, and UnionFS into a wrapper
|
||||
called a container format. The default container format is `libcontainer`. In
|
||||
the future, Docker may support other container formats by integrating with
|
||||
technologies such as BSD Jails or Solaris Zones.
|
||||
|
||||
## Next steps
|
||||
- Read about [Installing Docker Engine](installation/index.md#installation).
|
||||
- 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).
|
||||
|
|
@ -9,46 +9,35 @@ title: Learn more
|
|||
notoc: true
|
||||
---
|
||||
|
||||
This tutorial provided very basic essentials for using Docker. If you want to learn more about end-to-end development, start with the full install instructions and feature overviews in the platform-specific guides, then follow up with more advanced tutorials and user guides.
|
||||
This tutorial provided very basic essentials for using Docker. If you want to
|
||||
learn more about end-to-end development, start with the full install
|
||||
instructions and feature overviews in the platform-specific guides, then follow
|
||||
up with more advanced tutorials and user guides.
|
||||
|
||||
Depending on your interest, the Docker documentation contains a wealth of information. Here are some places to start:
|
||||
Depending on your interest, the Docker documentation contains a wealth of
|
||||
information. Here are some places to start:
|
||||
|
||||
<style type="text/css">
|
||||
</style>
|
||||
<table class="tutorial" width="100%">
|
||||
<col style="width:50%">
|
||||
<col style="width:50%">
|
||||
<tr>
|
||||
<th class="tg-031e">If you are looking for</th>
|
||||
<th class="tg-031e">Where to find it</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e" style="width: 50%">Tutorials and sample app walkthroughs.<br><br>
|
||||
A logical next step after completing the basic getting started
|
||||
example, this tutorial walks you through using a Docker stack file
|
||||
to define a set of services and deploy them to a <a href="/engine/reference/glossary/#swarm">swarm</a>.
|
||||
</td>
|
||||
<td class="tg-031e"><a href="/engine/getstarted-voting-app/">Define and deploy apps in Swarm Mode</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">A palette of sample applications and training labs from Docker and community contributors.</td>
|
||||
<td class="tg-031e"><a href="/samples/">Samples and labs</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">A more in-depth exploration of concepts introduced in the basic getting started: running containers, building your own images, networking containers, managing data for containers, and storing images on Docker Hub.</td>
|
||||
<td class="tg-031e"><a href="/engine/tutorials/">Learn by example</a></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">Platform-specific getting started guides. You can find install steps, release notes, basic Docker command examples, FAQs, troubleshooting, and more in these guides. </td>
|
||||
<td class="tg-031e">
|
||||
<a href="/docker-for-mac/">Getting Started with Docker for Mac</a><br>
|
||||
<a href="/docker-for-windows/">Getting Started with Docker for Windows</a><br>
|
||||
<a href="/toolbox/overview/">Docker Toolbox Overview</a><font color="gray"> (legacy for older platforms)</font><br>
|
||||
<a href="/engine/installation/linux/">Install Docker Engine on Linux</a><br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td class="tg-031e">Information about the Docker product line</td>
|
||||
<td class="tg-031e"><a href="http://www.docker.com/products/">The product explainer is a good place to start.</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
* **[Docker Overview](/engine/docker-overview.md)**: More about Docker images,
|
||||
containers, and internals
|
||||
|
||||
* **[Define and deploy apps in swarm mode](/engine/getstarted-voting-app.md)**:
|
||||
Get started with [swarm mode](/engine/reference/glossary.md#swarm), Docker's
|
||||
orchestration model.
|
||||
|
||||
* **[Samples and labs](/samples/)**: A palette of sample applications and
|
||||
training labs from Docker and community contributors.
|
||||
|
||||
* **[Learn by example](/engine/tutorials/)**: A more in-depth exploration of
|
||||
concepts introduced in the basic getting started: running containers, building
|
||||
your own images, networking containers, managing data for containers, and
|
||||
storing images on Docker Hub.
|
||||
|
||||
* **Platform-specific Getting-Started guides**: Installation, release notes,
|
||||
basic command-line examplees, and more for your specific platform:
|
||||
|
||||
- [Get started with Docker for Mac](/docker-for-mac/)
|
||||
- [Get started with Docker for Windows](/docker-for-windows/)
|
||||
- [Get started with Docker Toolbox](/toolbox/overview/) (legacy for older platforms)
|
||||
- [Get started with Docker for Linux](/engine/installation/linux/)
|
||||
* **[Information about Docker products](http://www.docker.com/products)**:
|
||||
Information about the full line of Docker products and services.
|
||||
|
|
|
|||
|
|
@ -1,307 +0,0 @@
|
|||
---
|
||||
description: Docker explained in depth
|
||||
keywords: docker, introduction, documentation, about, technology, understanding
|
||||
redirect_from:
|
||||
- /introduction/understanding-docker/
|
||||
- /engine/userguide/basics/
|
||||
- /engine/introduction/understanding-docker/
|
||||
title: Docker Overview
|
||||
---
|
||||
|
||||
Docker is an open platform for developing, shipping, and running applications.
|
||||
Docker enables you to separate your applications from your infrastructure so
|
||||
you can deliver software quickly. With Docker, you can manage your infrastructure
|
||||
in the same ways you manage your applications. By taking advantage of Docker's
|
||||
methodologies for shipping, testing, and deploying code quickly, you can
|
||||
significantly reduce the delay between writing code and running it in production.
|
||||
|
||||
## What is the Docker platform?
|
||||
|
||||
Docker provides the ability to package and run an application in a loosely isolated
|
||||
environment called a container. The isolation and security allow you to run many
|
||||
containers simultaneously on a given host. Because of the lightweight nature of
|
||||
containers, which run without the extra load of a hypervisor, you can run more
|
||||
containers on a given hardware combination than if you were using virtual machines.
|
||||
|
||||
Docker provides tooling and a platform to manage the lifecycle of your containers:
|
||||
|
||||
* Encapsulate your applications (and supporting components) into Docker containers
|
||||
* Distribute and ship those containers to your teams for further development
|
||||
and testing
|
||||
* Deploy those applications to your production environment, whether it is in a
|
||||
local data center or the Cloud
|
||||
|
||||
## What is Docker Engine?
|
||||
|
||||
_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 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.
|
||||
|
||||
|
||||
|
||||
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_, such as images, containers,
|
||||
networks, and data volumes.
|
||||
|
||||
> **Note**: Docker is licensed under the open source Apache 2.0 license.
|
||||
|
||||
## What can I use Docker for?
|
||||
|
||||
*Fast, consistent delivery of your applications*
|
||||
|
||||
Docker can streamline the development lifecycle by allowing developers to work in
|
||||
standardized environments using local containers which provide your applications
|
||||
and services. You can also integrate Docker into your continuous integration and
|
||||
continuous deployment (CI/CD) workflow.
|
||||
|
||||
Consider the following example scenario. Your developers write code locally and
|
||||
share their work with their colleagues using Docker containers. They can use
|
||||
Docker to push their applications into a test environment and execute automated
|
||||
and manual tests. When developers find problems, they can fix them in the development
|
||||
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.
|
||||
|
||||
*Responsive deployment and scaling*
|
||||
|
||||
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
|
||||
in a data center, in the Cloud, or in a mixture of environments.
|
||||
|
||||
Docker's portability and lightweight nature also make it easy to dynamically manage
|
||||
workloads, scaling up or tearing down applications and services as business
|
||||
needs dictate, in near real time.
|
||||
|
||||
*Running more workloads on the same hardware*
|
||||
|
||||
Docker is lightweight and fast. It provides a viable, cost-effective alternative
|
||||
to hypervisor-based virtual machines, allowing you to use more of your compute
|
||||
capacity to achieve your business goals. This is useful in high density
|
||||
environments and for small and medium deployments where you need to do more with
|
||||
fewer resources.
|
||||
|
||||
## What is Docker's architecture?
|
||||
Docker uses a client-server architecture. The Docker *client* talks to the
|
||||
Docker *daemon*, which does the heavy lifting of building, running, and
|
||||
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
|
||||
daemon. The Docker client and daemon communicate using a REST API, over UNIX
|
||||
sockets or a network interface.
|
||||
|
||||
|
||||
|
||||
### The Docker daemon
|
||||
The Docker daemon runs on a host machine. The user uses the Docker client to
|
||||
interact with the daemon.
|
||||
|
||||
### The Docker client
|
||||
The Docker client, in the form of the `docker` binary, is the primary user
|
||||
interface to Docker. It accepts commands and configuration flags from the user and
|
||||
communicates with a Docker daemon. One client can even communicate with multiple
|
||||
unrelated daemons.
|
||||
|
||||
### Inside Docker
|
||||
To understand Docker's internals, you need to know about _images_, _registries_,
|
||||
and _containers_.
|
||||
|
||||
#### Docker images
|
||||
|
||||
A Docker _image_ is a read-only template with instructions for creating a Docker
|
||||
container. For example, an image might contain an Ubuntu operating system with
|
||||
Apache web server and your web application installed. You can build or update
|
||||
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 containers
|
||||
A Docker container is a runnable instance of a Docker image. You can run, start,
|
||||
stop, move, or delete a container using Docker API or CLI commands. When you run
|
||||
a container, you can provide configuration metadata such as networking information
|
||||
or environment variables. Each container is an isolated and secure application
|
||||
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?
|
||||
Docker images are read-only templates from which Docker containers are instantiated.
|
||||
Each image consists of a series of layers. Docker uses
|
||||
[union file systems](http://en.wikipedia.org/wiki/UnionFS) to
|
||||
combine these layers into a single image. Union file systems allow files and
|
||||
directories of separate file systems, known as branches, to be transparently
|
||||
overlaid, forming a single coherent file system.
|
||||
|
||||
These layers are one of the reasons Docker is so lightweight. When you
|
||||
change a Docker image, such as when you update an application to a new version,
|
||||
a new layer is built and replaces only the layer it updates. The other layers
|
||||
remain intact. To distribute the update, you only need to transfer the updated
|
||||
layer. Layering speeds up distribution of Docker images. Docker determines which
|
||||
layers need to be updated at runtime.
|
||||
|
||||
An image is defined in a Dockerfile. Every image starts from a base image, such as
|
||||
`ubuntu`, a base Ubuntu image, or `fedora`, a base Fedora image. You can also use
|
||||
images of your own as the basis for a new image, for example if you have a base
|
||||
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
|
||||
images.
|
||||
|
||||
The docker image is built from the base image using a simple, descriptive
|
||||
set of steps we call *instructions*, which are stored in a `Dockerfile`. Each
|
||||
instruction creates a new layer in the image. Some examples of Dockerfile
|
||||
instructions are:
|
||||
|
||||
* Specify the base image (`FROM`)
|
||||
* Specify image metadata (`LABEL`)
|
||||
* Run a command (`RUN`)
|
||||
* Add a file or directory (`ADD`)
|
||||
* Create an environment variable (`ENV`)
|
||||
* What process to run when launching a container from this image (`CMD`)
|
||||
|
||||
Docker reads this `Dockerfile` when you request a build of
|
||||
an image, executes the instructions, and returns the image.
|
||||
|
||||
### How does a Docker registry work?
|
||||
A Docker registry stores Docker images. After you build a Docker image, you
|
||||
can *push* it to a public registry such as [Docker Hub](https://hub.docker.com)
|
||||
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.
|
||||
|
||||
[Docker Hub](http://hub.docker.com) is a public Docker
|
||||
registry which serves a huge collection of existing images and allows you to
|
||||
contribute your own. For more information, go to
|
||||
[Docker Registry](/registry/index.md) and
|
||||
[Docker Trusted Registry](/datacenter/dtr/2.1/guides/index.md).
|
||||
|
||||
[Docker store](http://store.docker.com) allows you to buy and sell Docker images.
|
||||
For instance, you can buy a Docker image containing an application or service from
|
||||
the software vendor, and use the image to deploy the application into your
|
||||
testing, staging, and production environments, and upgrade the application by pulling
|
||||
the new version of the image and redeploying the containers. Docker Store is currently
|
||||
in private beta.
|
||||
|
||||
### How does a container work?
|
||||
A container uses the host machine's Linux kernel, and consists of any extra files
|
||||
you add when the image is created, along with metadata associated with the container
|
||||
at creation or when the container is started. Each container is built from an image.
|
||||
The image defines the container's contents, which process to run when the container
|
||||
is launched, and a variety of other configuration details. The Docker image is
|
||||
read-only. When Docker runs a container from an image, it adds a read-write layer
|
||||
on top of the image (using a UnionFS as we saw earlier) in which your application
|
||||
runs.
|
||||
|
||||
#### What happens when you run a container?
|
||||
When you use the `docker run` CLI command or the equivalent API, the Docker Engine
|
||||
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
|
||||
|
||||
|
||||
When you run this command, Docker Engine does the following:
|
||||
|
||||
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
|
||||
the new container. Otherwise, then Docker Engine pulls it from
|
||||
[Docker Hub](https://hub.docker.com).
|
||||
|
||||
1. **Creates a new container:** Docker uses the image to create a 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
|
||||
Docker is written in [Go](https://golang.org/) and takes advantage of several
|
||||
features of the Linux kernel to deliver its functionality.
|
||||
|
||||
### Namespaces
|
||||
Docker uses a technology called `namespaces` to provide the isolated workspace
|
||||
called the *container*. When you run a container, Docker creates a set of
|
||||
*namespaces* for that container.
|
||||
|
||||
These namespaces provide a layer of isolation. Each aspect of a container runs
|
||||
in a separate namespace and its access is limited to that namespace.
|
||||
|
||||
Docker Engine uses namespaces such as the following on Linux:
|
||||
|
||||
- **The `pid` namespace:** Process isolation (PID: Process ID).
|
||||
- **The `net` namespace:** Managing network interfaces (NET:
|
||||
Networking).
|
||||
- **The `ipc` namespace:** Managing access to IPC
|
||||
resources (IPC: InterProcess Communication).
|
||||
- **The `mnt` namespace:** Managing filesystem mount points (MNT: Mount).
|
||||
- **The `uts` namespace:** Isolating kernel and version identifiers. (UTS: Unix
|
||||
Timesharing System).
|
||||
|
||||
### Control groups
|
||||
Docker Engine on Linux also relies on another technology called _control groups_
|
||||
(`cgroups`). A cgroup limits an application to a specific set of resources.
|
||||
Control groups allow Docker Engine to share available hardware resources to
|
||||
containers and optionally enforce limits and constraints. For example,
|
||||
you can limit the memory available to a specific container.
|
||||
|
||||
### Union file systems
|
||||
Union file systems, or UnionFS, are file systems that operate by creating layers,
|
||||
making them very lightweight and fast. Docker Engine uses UnionFS to provide
|
||||
the building blocks for containers. Docker Engine can use multiple UnionFS variants,
|
||||
including AUFS, btrfs, vfs, and DeviceMapper.
|
||||
|
||||
### Container format
|
||||
Docker Engine combines the namespaces, control groups, and UnionFS into a wrapper
|
||||
called a container format. The default container format is `libcontainer`. In
|
||||
the future, Docker may support other container formats by integrating with
|
||||
technologies such as BSD Jails or Solaris Zones.
|
||||
|
||||
## Next steps
|
||||
- Read about [Installing Docker Engine](installation/index.md#installation).
|
||||
- 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 New Issue