mirror of
https://github.com/moby/moby.git
synced 2022-11-09 12:21:53 -05:00
97 lines
3.8 KiB
ReStructuredText
97 lines
3.8 KiB
ReStructuredText
:title: Image & Container
|
|
:description: Definitions of an image and container
|
|
:keywords: containers, lxc, concepts, explanation, image, container
|
|
|
|
File Systems
|
|
============
|
|
|
|
.. image:: images/docker-filesystems-generic.png
|
|
|
|
In order for a Linux system to run, it typically needs two `file
|
|
systems <http://en.wikipedia.org/wiki/Filesystem>`_:
|
|
|
|
1. boot file system (bootfs)
|
|
2. root file system (rootfs)
|
|
|
|
The **boot file system** contains the bootloader and the kernel. The
|
|
user never makes any changes to the boot file system. In fact, soon
|
|
after the boot process is complete, the entire kernel is in memory,
|
|
and the boot file system is unmounted to free up the RAM associated
|
|
with the initrd disk image.
|
|
|
|
The **root file system** includes the typical directory structure we
|
|
associate with Unix-like operating systems: ``/dev, /proc, /bin, /etc,
|
|
/lib, /usr,`` and ``/tmp`` plus all the configuration files, binaries
|
|
and libraries required to run user applications (like bash, ls, and so
|
|
forth).
|
|
|
|
While there can be important kernal differences between different
|
|
Linux distributions, the contents and organization of the root file
|
|
system are usually what make your software packages dependent on one
|
|
distribution versus another. Docker can help solve this problem by
|
|
running multiple distributions at the same time.
|
|
|
|
.. image:: images/docker-filesystems-multiroot.png
|
|
|
|
Layers and Union Mounts
|
|
=======================
|
|
|
|
In a traditional Linux boot, the kernel first mounts the root file
|
|
system as read-only, checks its integrity, and then switches the whole
|
|
rootfs volume to read-write mode. Docker does something similar,
|
|
*except* that instead of changing the file system to read-write mode,
|
|
it takes advantage of a `union mount
|
|
<http://en.wikipedia.org/wiki/Union_mount>`_ to add a read-write file
|
|
system *over* the read-only file system. In fact there may be multiple
|
|
read-only file systems stacked on top of each other.
|
|
|
|
.. image:: images/docker-filesystems-multilayer.png
|
|
|
|
At first, the top layer has nothing in it, but any time a process
|
|
creates a file, this happens in the top layer. And if something needs
|
|
to update an existing file in a lower layer, then the file gets copied
|
|
to the upper layer and changes go into the copy. The version of the
|
|
file on the lower layer cannot be seen by the applications anymore,
|
|
but it is there, unchanged.
|
|
|
|
We call the union of the read-write layer and all the read-only layers
|
|
a **union file system**.
|
|
|
|
Image
|
|
=====
|
|
|
|
In Docker terminology, a read-only layer is called an **image**. An
|
|
image never changes. Because Docker uses a union file system, the
|
|
applications think the whole file system is mounted read-write,
|
|
because any file can be changed. But all the changes go to the
|
|
top-most layer, and underneath, the image is unchanged. Since they
|
|
don't change, images do not have state.
|
|
|
|
Each image may depend on one more image which forms the layer beneath
|
|
it. We sometimes say that the lower image is the **parent** of the
|
|
upper image.
|
|
|
|
Base Image
|
|
==========
|
|
|
|
An image that has no parent is a **base image**.
|
|
|
|
Container
|
|
=========
|
|
|
|
Once you start a process in Docker from an image, Docker fetches the
|
|
image and its parent, and repeats the process until it reaches the
|
|
base image. Then the union file system adds a read-write layer on
|
|
top. That read-write layer, plus the information about its parent and
|
|
some additional information like its unique id, is called a
|
|
**container**.
|
|
|
|
Containers can change, and so they have state. A container may be
|
|
running or exited. In either case, the state of the file system and
|
|
its exit value is preserved. You can start, stop, and restart a
|
|
container. The processes restart from scratch (their memory state is
|
|
**not** preserved in a container), but the file system is just as it
|
|
was when the container was stopped.
|
|
|
|
You can promote a container to an image with ``docker commit``. Once a
|
|
container is an image, you can use it as a parent for new containers.
|