mirror of
https://github.com/clearlinux/docker.git
synced 2026-06-16 02:35:49 +00:00
Merge pull request #15701 from moxiegirl/819-publish-cherrypicks
819 publish cherrypicks
This commit is contained in:
moxiegirl
@@ -11,7 +11,7 @@ parent = "smn_images"
|
||||
# Create a base image
|
||||
|
||||
So you want to create your own [*Base Image*](
|
||||
/terms/image/#base-image)? Great!
|
||||
/reference/glossary/#base-image)? Great!
|
||||
|
||||
The specific process will depend heavily on the Linux distribution you
|
||||
want to package. We have some examples below, and you are encouraged to
|
||||
|
||||
@@ -57,7 +57,7 @@ These options :
|
||||
- Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
|
||||
- Listen for connections on `tcp://192.168.59.3:2376`
|
||||
|
||||
The command line reference has the [complete list of daemon flags](/reference/commandline/cli/#daemon)
|
||||
The command line reference has the [complete list of daemon flags](/reference/commandline/daemon)
|
||||
with explanations.
|
||||
|
||||
## Ubuntu
|
||||
@@ -114,7 +114,7 @@ These options :
|
||||
- Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
|
||||
- Listen for connections on `tcp://192.168.59.3:2376`
|
||||
|
||||
The command line reference has the [complete list of daemon flags](/reference/commandline/cli/#daemon)
|
||||
The command line reference has the [complete list of daemon flags](/reference/commandline/daemon)
|
||||
with explanations.
|
||||
|
||||
|
||||
@@ -207,7 +207,7 @@ These options :
|
||||
- Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
|
||||
- Listen for connections on `tcp://192.168.59.3:2376`
|
||||
|
||||
The command line reference has the [complete list of daemon flags](/reference/commandline/cli/#daemon)
|
||||
The command line reference has the [complete list of daemon flags](/reference/commandline/daemon)
|
||||
with explanations.
|
||||
|
||||
5. Save and close the file.
|
||||
|
||||
@@ -21,7 +21,7 @@ installation mechanisms. Using these packages ensures you get the latest release
|
||||
of Docker. If you wish to install using Fedora-managed packages, consult your
|
||||
Fedora release documentation for information on Fedora's Docker support.
|
||||
|
||||
##Prerequisites
|
||||
## Prerequisites
|
||||
|
||||
Docker requires a 64-bit installation regardless of your Fedora version. Also, your kernel must be 3.10 at minimum. To check your current kernel
|
||||
version, open a terminal and use `uname -r` to display your kernel version:
|
||||
|
||||
@@ -280,9 +280,9 @@ To verify this, run the following commands:
|
||||
|
||||
$ docker-machine ls
|
||||
NAME ACTIVE DRIVER STATE URL SWARM
|
||||
dev * virtualbox Running tcp://192.168.99.100:2376
|
||||
default * virtualbox Running tcp://192.168.99.100:2376
|
||||
|
||||
The `ACTIVE` machine, in this case `dev`, is the one your environment is pointing to.
|
||||
The `ACTIVE` machine, in this case `default`, is the one your environment is pointing to.
|
||||
|
||||
### Access container ports
|
||||
|
||||
@@ -319,9 +319,9 @@ The `ACTIVE` machine, in this case `dev`, is the one your environment is pointin
|
||||
not the localhost address (0.0.0.0) but is instead the address of the
|
||||
your Docker VM.
|
||||
|
||||
5. Get the address of the `dev` VM.
|
||||
5. Get the address of the `default` VM.
|
||||
|
||||
$ docker-machine ip dev
|
||||
$ docker-machine ip default
|
||||
192.168.59.103
|
||||
|
||||
6. Enter the `http://192.168.59.103:49157` address in your browser:
|
||||
|
||||
@@ -96,7 +96,7 @@ To upgrade your kernel and install the additional packages, do the following:
|
||||
|
||||
$ sudo reboot
|
||||
|
||||
5. After your system reboots, go ahead and [install Docker](#installing-docker-on-ubuntu).
|
||||
5. After your system reboots, go ahead and [install Docker](#installation).
|
||||
|
||||
|
||||
### For Saucy 13.10 (64 bit)
|
||||
|
||||
@@ -96,9 +96,9 @@ environment.
|
||||
|
||||
1. Open a terminal.
|
||||
|
||||
Mac users, use `boot2docker status` to make sure Boot2Docker is running. You
|
||||
may need to run `eval "$(boot2docker shellinit)"` to initialize your shell
|
||||
environment.
|
||||
Mac users, use `docker-machine status your_vm_name` to make sure your VM is
|
||||
running. You may need to run `eval "$(docker-machine env your_vm_name)"` to
|
||||
initialize your shell environment.
|
||||
|
||||
3. Change into the root of your forked repository.
|
||||
|
||||
@@ -193,7 +193,7 @@ environment.
|
||||
Keeping the ancestor images improves the build performance. When you rebuild
|
||||
the child image, the build process uses the local ancestors rather than
|
||||
retrieving them from the Hub. The build process gets new ancestors only if
|
||||
DockerHub has updated versions.
|
||||
Docker Hub has updated versions.
|
||||
|
||||
## Start a container and run a test
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
+46
-40
@@ -10,48 +10,50 @@ parent = "mn_reference"
|
||||
|
||||
# Dockerfile reference
|
||||
|
||||
**Docker can build images automatically** by reading the instructions
|
||||
from a `Dockerfile`. A `Dockerfile` is a text document that contains all
|
||||
the commands you would normally execute manually in order to build a
|
||||
Docker image. By calling `docker build` from your terminal, you can have
|
||||
Docker build your image step by step, executing the instructions
|
||||
successively.
|
||||
Docker can build images automatically by reading the instructions from a
|
||||
`Dockerfile`. A `Dockerfile` is a text document that contains all the commands a
|
||||
user could call on the command line to assemble an image. Using `docker build`
|
||||
users can create an automated build that executes several command-line
|
||||
instructions in succession.
|
||||
|
||||
This page discusses the specifics of all the instructions you can use in your
|
||||
`Dockerfile`. To further help you write a clear, readable, maintainable
|
||||
`Dockerfile`, we've also written a [`Dockerfile` Best Practices
|
||||
guide](/articles/dockerfile_best-practices). Lastly, you can test your
|
||||
Dockerfile knowledge with the [Dockerfile tutorial](/userguide/level1).
|
||||
This page describes the commands you can use in a `Dockerfile`. When you are
|
||||
done reading this page, refer to the [`Dockerfile` Best
|
||||
Practices](/articles/dockerfile_best-practices) for a tip-oriented guide.
|
||||
|
||||
## Usage
|
||||
|
||||
To [*build*](/reference/commandline/cli/#build) an image from a source repository,
|
||||
create a description file called `Dockerfile` at the root of your repository.
|
||||
This file will describe the steps to assemble the image.
|
||||
The [`docker build`](/reference/commandline/build/) command builds an image from
|
||||
a `Dockerfile` and a *context*. The build's context is the files at a specified
|
||||
location `PATH` or `URL`. The `PATH` is a directory on your local filesystem.
|
||||
The `URL` is a the location of a Git repository.
|
||||
|
||||
Then call `docker build` with the path of your source repository as the argument
|
||||
(for example, `.`):
|
||||
A context is processed recursively. So, a `PATH` includes any subdirectories and
|
||||
the `URL` includes the repository and its submodules. A simple build command
|
||||
that uses the current directory as context:
|
||||
|
||||
$ docker build .
|
||||
Sending build context to Docker daemon 6.51 MB
|
||||
...
|
||||
|
||||
The path to the source repository defines where to find the *context* of
|
||||
the build. The build is run by the Docker daemon, not by the CLI, so the
|
||||
whole context must be transferred to the daemon. The Docker CLI reports
|
||||
"Sending build context to Docker daemon" when the context is sent to the daemon.
|
||||
The build is run by the Docker daemon, not by the CLI. The first thing a build
|
||||
process does is send the entire context (recursively) to the daemon. In most
|
||||
cases, it's best to start with an empty directory as context and keep your
|
||||
Dockerfile in that directory. Add only the files needed for building the
|
||||
Dockerfile.
|
||||
|
||||
> **Warning**
|
||||
> Avoid using your root directory, `/`, as the root of the source repository. The
|
||||
> `docker build` command will use whatever directory contains the Dockerfile as the build
|
||||
> context (including all of its subdirectories). The build context will be sent to the
|
||||
> Docker daemon before building the image, which means if you use `/` as the source
|
||||
> repository, the entire contents of your hard drive will get sent to the daemon (and
|
||||
> thus to the machine running the daemon). You probably don't want that.
|
||||
>**Warning**: Do not use your root directory, `/`, as the `PATH` as it causes
|
||||
>the build to transfer the entire contents of your hard drive to the Docker
|
||||
>daemon.
|
||||
|
||||
In most cases, it's best to put each Dockerfile in an empty directory. Then,
|
||||
only add the files needed for building the Dockerfile to the directory. To
|
||||
increase the build's performance, you can exclude files and directories by
|
||||
adding a `.dockerignore` file to the directory. For information about how to
|
||||
[create a `.dockerignore` file](#dockerignore-file) on this page.
|
||||
To use a file in the build context, the `Dockerfile` refers to the file with
|
||||
an instruction, for example, a `COPY` instruction. To increase the build's
|
||||
performance, exclude files and directories by adding a `.dockerignore` file to
|
||||
the context directory. For information about how to [create a `.dockerignore`
|
||||
file](#dockerignore-file) see the documentation on this page.
|
||||
|
||||
Traditionally, the `Dockerfile` is called `Dockerfile` and located in the root
|
||||
of the context. You use the `-f` flag with `docker build` to point to a Dockerfile
|
||||
anywhere in your file system.
|
||||
|
||||
You can specify a repository and tag at which to save the new image if
|
||||
the build succeeds:
|
||||
@@ -100,7 +102,7 @@ be UPPERCASE in order to distinguish them from arguments more easily.
|
||||
|
||||
Docker runs the instructions in a `Dockerfile` in order. **The
|
||||
first instruction must be \`FROM\`** in order to specify the [*Base
|
||||
Image*](/terms/image/#base-image) from which you are building.
|
||||
Image*](/reference/glossary/#base-image) from which you are building.
|
||||
|
||||
Docker will treat lines that *begin* with `#` as a
|
||||
comment. A `#` marker anywhere else in the line will
|
||||
@@ -160,13 +162,13 @@ The instructions that handle environment variables in the `Dockerfile` are:
|
||||
the instructions above.
|
||||
|
||||
Environment variable substitution will use the same value for each variable
|
||||
throughout the entire command. In other words, in this example:
|
||||
throughout the entire command. In other words, in this example:
|
||||
|
||||
ENV abc=hello
|
||||
ENV abc=bye def=$abc
|
||||
ENV ghi=$abc
|
||||
|
||||
will result in `def` having a value of `hello`, not `bye`. However,
|
||||
will result in `def` having a value of `hello`, not `bye`. However,
|
||||
`ghi` will have a value of `bye` because it is not part of the same command
|
||||
that set `abc` to `bye`.
|
||||
|
||||
@@ -185,7 +187,7 @@ expansion) is done using Go's
|
||||
|
||||
You can specify exceptions to exclusion rules. To do this, simply prefix a
|
||||
pattern with an `!` (exclamation mark) in the same way you would in a
|
||||
`.gitignore` file. Currently there is no support for regular expressions.
|
||||
`.gitignore` file. Currently there is no support for regular expressions.
|
||||
Formats like `[^temp*]` are ignored.
|
||||
|
||||
The following is an example `.dockerignore` file:
|
||||
@@ -245,7 +247,7 @@ Or
|
||||
|
||||
FROM <image>@<digest>
|
||||
|
||||
The `FROM` instruction sets the [*Base Image*](/terms/image/#base-image)
|
||||
The `FROM` instruction sets the [*Base Image*](/reference/glossary/#base-image)
|
||||
for subsequent instructions. As such, a valid `Dockerfile` must have `FROM` as
|
||||
its first instruction. The image can be any valid image – it is especially easy
|
||||
to start by **pulling an image** from the [*Public Repositories*](
|
||||
@@ -304,7 +306,7 @@ commands using a base image that does not contain `/bin/sh`.
|
||||
|
||||
The cache for `RUN` instructions isn't invalidated automatically during
|
||||
the next build. The cache for an instruction like
|
||||
`RUN apt-get dist-upgrade -y` will be reused during the next build. The
|
||||
`RUN apt-get dist-upgrade -y` will be reused during the next build. The
|
||||
cache for `RUN` instructions can be invalidated by using the `--no-cache`
|
||||
flag, for example `docker build --no-cache`.
|
||||
|
||||
@@ -882,9 +884,9 @@ The `VOLUME` instruction creates a mount point with the specified name
|
||||
and marks it as holding externally mounted volumes from native host or other
|
||||
containers. The value can be a JSON array, `VOLUME ["/var/log/"]`, or a plain
|
||||
string with multiple arguments, such as `VOLUME /var/log` or `VOLUME /var/log
|
||||
/var/db`. For more information/examples and mounting instructions via the
|
||||
/var/db`. For more information/examples and mounting instructions via the
|
||||
Docker client, refer to
|
||||
[*Share Directories via Volumes*](/userguide/dockervolumes/#volume)
|
||||
[*Share Directories via Volumes*](/userguide/dockervolumes/#mount-a-host-directory-as-a-data-volume)
|
||||
documentation.
|
||||
|
||||
The `docker run` command initializes the newly created volume with any data
|
||||
@@ -900,6 +902,10 @@ This Dockerfile results in an image that causes `docker run`, to
|
||||
create a new mount point at `/myvol` and copy the `greeting` file
|
||||
into the newly created volume.
|
||||
|
||||
> **Note**:
|
||||
> If any build steps change the data within the volume after it has been
|
||||
> declared, those changes will be discarded.
|
||||
|
||||
> **Note**:
|
||||
> The list is parsed as a JSON array, which means that
|
||||
> you must use double-quotes (") around words not single-quotes (').
|
||||
|
||||
@@ -19,6 +19,10 @@ aufs (advanced multi layered unification filesystem) is a Linux [filesystem](#fi
|
||||
Docker supports as a storage backend. It implements the
|
||||
[union mount](http://en.wikipedia.org/wiki/Union_mount) for Linux file systems.
|
||||
|
||||
## Base image
|
||||
|
||||
An image that has no parent is a **base image**.
|
||||
|
||||
## boot2docker
|
||||
|
||||
[boot2docker](http://boot2docker.io/) is a lightweight Linux distribution made
|
||||
|
||||
+28
-25
@@ -19,11 +19,11 @@ parent = "mn_reference"
|
||||
**Docker runs processes in isolated containers**. When an operator
|
||||
executes `docker run`, she starts a process with its own file system,
|
||||
its own networking, and its own isolated process tree. The
|
||||
[*Image*](/terms/image/#image) which starts the process may define
|
||||
[*Image*](/reference/glossary/#image) which starts the process may define
|
||||
defaults related to the binary to run, the networking to expose, and
|
||||
more, but `docker run` gives final control to the operator who starts
|
||||
the container from the image. That's the main reason
|
||||
[*run*](/reference/commandline/cli/#run) has more options than any
|
||||
[*run*](/reference/commandline/run) has more options than any
|
||||
other `docker` command.
|
||||
|
||||
## General form
|
||||
@@ -87,7 +87,7 @@ In detached mode (`-d=true` or just `-d`), all I/O should be done
|
||||
through network connections or shared volumes because the container is
|
||||
no longer listening to the command line where you executed `docker run`.
|
||||
You can reattach to a detached container with `docker`
|
||||
[*attach*](/reference/commandline/cli/#attach). If you choose to run a
|
||||
[*attach*](/reference/commandline/attach). If you choose to run a
|
||||
container in the detached mode, then you cannot use the `--rm` option.
|
||||
|
||||
### Foreground
|
||||
@@ -360,8 +360,8 @@ Using the `--restart` flag on Docker run you can specify a restart policy for
|
||||
how a container should or should not be restarted on exit.
|
||||
|
||||
When a restart policy is active on a container, it will be shown as either `Up`
|
||||
or `Restarting` in [`docker ps`](/reference/commandline/cli/#ps). It can also be
|
||||
useful to use [`docker events`](/reference/commandline/cli/#events) to see the
|
||||
or `Restarting` in [`docker ps`](/reference/commandline/ps). It can also be
|
||||
useful to use [`docker events`](/reference/commandline/events) to see the
|
||||
restart policy in effect.
|
||||
|
||||
Docker supports the following restart policies:
|
||||
@@ -417,7 +417,7 @@ You can specify the maximum amount of times Docker will try to restart the
|
||||
container when using the **on-failure** policy. The default is that Docker
|
||||
will try forever to restart the container. The number of (attempted) restarts
|
||||
for a container can be obtained via [`docker inspect`](
|
||||
/reference/commandline/cli/#inspect). For example, to get the number of restarts
|
||||
/reference/commandline/inspect). For example, to get the number of restarts
|
||||
for container "my-container";
|
||||
|
||||
$ docker inspect -f "{{ .RestartCount }}" my-container
|
||||
@@ -505,18 +505,18 @@ parent group.
|
||||
The operator can also adjust the performance parameters of the
|
||||
container:
|
||||
|
||||
| Option | Description |
|
||||
|--------------------------------------|---------------------------------------------------------------------------------------------|
|
||||
| `-m`, `--memory="" ` | Memory limit (format: , where unit = b, k, m or g) |
|
||||
| `--memory-swap=""` | Total memory limit (memory + swap, format: , where unit = b, k, m or g) |
|
||||
| `-c`, `--cpu-shares=0` | CPU shares (relative weight) |
|
||||
| `--cpu-period=0` | Limit the CPU CFS (Completely Fair Scheduler) period |
|
||||
| `--cpuset-cpus="" ` | CPUs in which to allow execution (0-3, 0,1) |
|
||||
| `--cpuset-mems=""` | Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems. |
|
||||
| `--cpu-quota=0` | Limit the CPU CFS (Completely Fair Scheduler) quota |
|
||||
| `--blkio-weight=0` | Block IO weight (relative weight) accepts a weight value between 10 and 1000. |
|
||||
| `--oom-kill-disable=true` or `false` | Whether to disable OOM Killer for the container or not. |
|
||||
| `--memory-swappiness="" ` | Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100. |
|
||||
| Option | Description |
|
||||
|----------------------------|---------------------------------------------------------------------------------------------|
|
||||
| `-m`, `--memory="" ` | Memory limit (format: `<number>[<unit>]`, where unit = b, k, m or g) |
|
||||
| `--memory-swap=""` | Total memory limit (memory + swap, format: `<number>[<unit>]`, where unit = b, k, m or g) |
|
||||
| `-c`, `--cpu-shares=0` | CPU shares (relative weight) |
|
||||
| `--cpu-period=0` | Limit the CPU CFS (Completely Fair Scheduler) period |
|
||||
| `--cpuset-cpus="" ` | CPUs in which to allow execution (0-3, 0,1) |
|
||||
| `--cpuset-mems=""` | Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems. |
|
||||
| `--cpu-quota=0` | Limit the CPU CFS (Completely Fair Scheduler) quota |
|
||||
| `--blkio-weight=0` | Block IO weight (relative weight) accepts a weight value between 10 and 1000. |
|
||||
| `--oom-kill-disable=false` | Whether to disable OOM Killer for the container or not. |
|
||||
| `--memory-swappiness="" ` | Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100. |
|
||||
|
||||
### Memory constraints
|
||||
|
||||
@@ -908,7 +908,7 @@ container's logging driver. The following options are supported:
|
||||
|
||||
The `docker logs`command is available only for the `json-file` logging
|
||||
driver. For detailed information on working with logging drivers, see
|
||||
[Configure a logging driver](reference/logging/overview.md).
|
||||
[Configure a logging driver](/reference/logging/overview/).
|
||||
|
||||
|
||||
## Overriding Dockerfile image defaults
|
||||
@@ -1048,7 +1048,7 @@ variables automatically:
|
||||
|
||||
The container may also include environment variables defined
|
||||
as a result of the container being linked with another container. See
|
||||
the [*Container Links*](/userguide/dockerlinks/#container-linking)
|
||||
the [*Container Links*](/userguide/dockerlinks/#connect-with-the-linking-system)
|
||||
section for more details.
|
||||
|
||||
Additionally, the operator can **set any environment variable** in the
|
||||
@@ -1142,14 +1142,17 @@ volume mounted on the host).
|
||||
|
||||
### USER
|
||||
|
||||
The default user within a container is `root` (id = 0), but if the
|
||||
developer created additional users, those are accessible too. The
|
||||
developer can set a default user to run the first process with the
|
||||
Dockerfile `USER` instruction, but the operator can override it:
|
||||
`root` (id = 0) is the default user within a container. The image developer can
|
||||
create additional users. Those users are accessible by name. When passing a numeric
|
||||
ID, the user does not have to exist in the container.
|
||||
|
||||
The developer can set a default user to run the first process with the
|
||||
Dockerfile `USER` instruction. When starting a container, the operator can override
|
||||
the `USER` instruction by passing the `-u` option.
|
||||
|
||||
-u="": Username or UID
|
||||
|
||||
> **Note:** if you pass numeric uid, it must be in range 0-2147483647.
|
||||
> **Note:** if you pass a numeric uid, it must be in the range of 0-2147483647.
|
||||
|
||||
### WORKDIR
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ $ export DOCKER_CONTENT_TRUST_TAGGING_PASSPHRASE="l7pEQcTKJjUHm6Lpe4"
|
||||
|
||||
Then, when pushing a new tag the Docker client does not request these values but signs automatically:
|
||||
|
||||
``bash
|
||||
```bash
|
||||
$ docker push docker/trusttest:latest
|
||||
The push refers to a repository [docker.io/docker/trusttest] (len: 1)
|
||||
a9539b34a6ab: Image already exists
|
||||
@@ -45,7 +45,7 @@ Signing and pushing trust metadata
|
||||
|
||||
You can also build with content trust. Before running the `docker build` command, you should set the environment variable `DOCKER_CONTENT_TRUST` either manually or in in a scripted fashion. Consider the simple Dockerfile below.
|
||||
|
||||
```Dockerfilea
|
||||
```Dockerfile
|
||||
FROM docker/trusttest:latest
|
||||
RUN echo
|
||||
```
|
||||
|
||||
@@ -45,8 +45,7 @@ The Docker client stores the keys in the `~/.docker/trust/private` directory.
|
||||
Before backing them up, you should `tar` them into an archive:
|
||||
|
||||
```bash
|
||||
$ tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private
|
||||
$ chmod 600 private_keys_backup.tar.gz
|
||||
$ umask 077; tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private; umask 022
|
||||
```
|
||||
|
||||
## Lost keys
|
||||
|
||||
@@ -1,51 +0,0 @@
|
||||
<!--[metadata]>
|
||||
+++
|
||||
draft = true
|
||||
title = "Container"
|
||||
description = "Definitions of a container"
|
||||
keywords = ["containers, lxc, concepts, explanation, image, container"]
|
||||
[menu.main]
|
||||
parent = "mn_reference"
|
||||
+++
|
||||
<![end-metadata]-->
|
||||
|
||||
# Container
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
|
||||
Once you start a process in Docker from an [*Image*](/terms/image), Docker
|
||||
fetches the image and its [*Parent Image*](/terms/image), and repeats the
|
||||
process until it reaches the [*Base Image*](/terms/image/#base-image-def). Then
|
||||
the [*Union File System*](/terms/layer) adds a read-write layer on top. That
|
||||
read-write layer, plus the information about its [*Parent
|
||||
Image*](/terms/image)
|
||||
and some additional information like its unique id, networking
|
||||
configuration, and resource limits is called a **container**.
|
||||
|
||||
## Container state
|
||||
|
||||
Containers can change, and so they have state. A container may be
|
||||
**running** or **exited**.
|
||||
|
||||
When a container is running, the idea of a "container" also includes a
|
||||
tree of processes running on the CPU, isolated from the other processes
|
||||
running on the host.
|
||||
|
||||
When the container is exited, 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*](/terms/image) with `docker commit`.
|
||||
Once a container is an image, you can use it as a parent for new containers.
|
||||
|
||||
## Container IDs
|
||||
|
||||
All containers are identified by a 64 hexadecimal digit string
|
||||
(internally a 256bit value). To simplify their use, a short ID of the
|
||||
first 12 characters can be used on the command line. There is a small
|
||||
possibility of short id collisions, so the docker server will always
|
||||
return the long ID.
|
||||
@@ -1,42 +0,0 @@
|
||||
<!--[metadata]>
|
||||
+++
|
||||
draft = true
|
||||
title = "File system"
|
||||
description = "How Linux organizes its persistent storage"
|
||||
keywords = ["containers, files, linux"]
|
||||
[menu.main]
|
||||
parent = "mn_reference"
|
||||
+++
|
||||
<![end-metadata]-->
|
||||
|
||||
# File system
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
|
||||
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 kernel 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.
|
||||
|
||||
|
||||
@@ -1,47 +0,0 @@
|
||||
<!--[metadata]>
|
||||
+++
|
||||
draft = true
|
||||
title = "Image"
|
||||
description = "Definition of an image"
|
||||
keywords = ["containers, lxc, concepts, explanation, image, container"]
|
||||
[menu.main]
|
||||
parent = "mn_reference"
|
||||
+++
|
||||
<![end-metadata]-->
|
||||
|
||||
# Image
|
||||
|
||||
## Introduction
|
||||
|
||||
|
||||
|
||||
In Docker terminology, a read-only [*Layer*](/terms/layer/#layer) is
|
||||
called an **image**. An image never changes.
|
||||
|
||||
Since Docker uses a [*Union File System*](/terms/layer/#union-file-system), the
|
||||
processes think the whole file system is mounted read-write. But all the
|
||||
changes go to the top-most writeable layer, and underneath, the original
|
||||
file in the read-only image is unchanged. Since images don't change,
|
||||
images do not have state.
|
||||
|
||||
|
||||
|
||||
## Parent image
|
||||
|
||||
|
||||
|
||||
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**.
|
||||
|
||||
## Image IDs
|
||||
|
||||
All images are identified by a 64 hexadecimal digit string (internally a
|
||||
256bit value). To simplify their use, a short ID of the first 12
|
||||
characters can be used on the command line. There is a small possibility
|
||||
of short id collisions, so the docker server will always return the long
|
||||
ID.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 31 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB |
File diff suppressed because it is too large
Load Diff
|
Before Width: | Height: | Size: 263 KiB |
@@ -1,42 +0,0 @@
|
||||
<!--[metadata]>
|
||||
+++
|
||||
draft = true
|
||||
title = "Layers"
|
||||
description = "Organizing the Docker Root File System"
|
||||
keywords = ["containers, lxc, concepts, explanation, image, container"]
|
||||
[menu.main]
|
||||
parent = "mn_use_docker"
|
||||
+++
|
||||
<![end-metadata]-->
|
||||
|
||||
# Layers
|
||||
|
||||
## Introduction
|
||||
|
||||
In a traditional Linux boot, the kernel first mounts the root [*File
|
||||
System*](/terms/filesystem) as read-only, checks its
|
||||
integrity, and then switches the whole rootfs volume to read-write mode.
|
||||
|
||||
## Layer
|
||||
|
||||
When Docker mounts the rootfs, it starts read-only, as in a traditional
|
||||
Linux boot, but then, 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. We think
|
||||
of each one of these file systems as a **layer**.
|
||||
|
||||
|
||||
|
||||
At first, the top read-write 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.
|
||||
|
||||
## Union File System
|
||||
|
||||
We call the union of the read-write layer and all the read-only layers a
|
||||
**union file system**.
|
||||
@@ -1,27 +0,0 @@
|
||||
<!--[metadata]>
|
||||
+++
|
||||
draft = true
|
||||
title = "Registry"
|
||||
description = "Definition of an Registry"
|
||||
keywords = ["containers, concepts, explanation, image, repository, container"]
|
||||
[menu.main]
|
||||
parent = "mn_reference"
|
||||
+++
|
||||
<![end-metadata]-->
|
||||
|
||||
# Registry
|
||||
|
||||
## Introduction
|
||||
|
||||
A Registry is a hosted service containing
|
||||
[*repositories*](/terms/repository/#repository-def) of
|
||||
[*images*](/terms/image/#image-def) which responds to the Registry API.
|
||||
|
||||
The default registry can be accessed using a browser at
|
||||
[Docker Hub](https://hub.docker.com) or using the
|
||||
`docker search` command.
|
||||
|
||||
## Further reading
|
||||
|
||||
For more information see [*Working with
|
||||
Repositories*](/userguide/dockerrepos/#working-with-the-repository)
|
||||
@@ -1,42 +0,0 @@
|
||||
<!--[metadata]>
|
||||
+++
|
||||
draft = true
|
||||
title = "Repository"
|
||||
description = "Definition of an Repository"
|
||||
keywords = ["containers, concepts, explanation, image, repository, container"]
|
||||
[menu.main]
|
||||
parent = "identifier"
|
||||
+++
|
||||
<![end-metadata]-->
|
||||
|
||||
# Repository
|
||||
|
||||
## Introduction
|
||||
|
||||
A repository is a set of images either on your local Docker server, or
|
||||
shared, by pushing it to a [*Registry*](/terms/registry/#registry-def)
|
||||
server.
|
||||
|
||||
Images can be associated with a repository (or multiple) by giving them
|
||||
an image name using one of three different commands:
|
||||
|
||||
1. At build time (e.g., `docker build -t IMAGENAME`),
|
||||
2. When committing a container (e.g.,
|
||||
`docker commit CONTAINERID IMAGENAME`) or
|
||||
3. When tagging an image id with an image name (e.g.,
|
||||
`docker tag IMAGEID IMAGENAME`).
|
||||
|
||||
A Fully Qualified Image Name (FQIN) can be made up of 3 parts:
|
||||
|
||||
`[registry_hostname[:port]/][user_name/](repository_name:version_tag)`
|
||||
|
||||
`username` and `registry_hostname` default to an empty string. When
|
||||
`registry_hostname` is an empty string, then `docker push` will push to
|
||||
`index.docker.io:80`.
|
||||
|
||||
If you create a new repository which you want to share, you will need to
|
||||
set at least the `user_name`, as the `default` blank `user_name` prefix is
|
||||
reserved for [Official Repositories](/docker-hub/official_repos).
|
||||
|
||||
For more information see [*Working with
|
||||
Repositories*](/userguide/dockerrepos/#working-with-the-repository)
|
||||
@@ -133,8 +133,8 @@ This really long string is called a *container ID*. It uniquely
|
||||
identifies a container so we can work with it.
|
||||
|
||||
> **Note:**
|
||||
> The container ID is a bit long and unwieldy and a bit later
|
||||
> on we'll see a shorter ID and some ways to name our containers to make
|
||||
> The container ID is a bit long and unwieldy. A bit later,
|
||||
> we'll see a shorter ID and ways to name our containers to make
|
||||
> working with them easier.
|
||||
|
||||
We can use this container ID to see what's happening with our `hello world` daemon.
|
||||
@@ -157,8 +157,8 @@ is running, its status and an automatically assigned name,
|
||||
`insane_babbage`.
|
||||
|
||||
> **Note:**
|
||||
> Docker automatically names any containers you start, a
|
||||
> little later on we'll see how you can specify your own names.
|
||||
> Docker automatically generates names for any containers started.
|
||||
> We'll see how to specify your own names a bit later.
|
||||
|
||||
Okay, so we now know it's running. But is it doing what we asked it to do? To see this
|
||||
we're going to look inside the container using the `docker logs`
|
||||
|
||||
@@ -227,11 +227,11 @@ The components in this prefix are:
|
||||
Docker uses this prefix format to define three distinct environment variables:
|
||||
|
||||
* The `prefix_ADDR` variable contains the IP Address from the URL, for
|
||||
example `WEBDB_PORT_8080_TCP_ADDR=172.17.0.82`.
|
||||
example `WEBDB_PORT_5432_TCP_ADDR=172.17.0.82`.
|
||||
* The `prefix_PORT` variable contains just the port number from the URL for
|
||||
example `WEBDB_PORT_8080_TCP_PORT=8080`.
|
||||
example `WEBDB_PORT_5432_TCP_PORT=5432`.
|
||||
* The `prefix_PROTO` variable contains just the protocol from the URL for
|
||||
example `WEBDB_PORT_8080_TCP_PROTO=tcp`.
|
||||
example `WEBDB_PORT_5432_TCP_PROTO=tcp`.
|
||||
|
||||
If the container exposes multiple ports, an environment variable set is
|
||||
defined for each one. This means, for example, if a container exposes 4 ports
|
||||
@@ -240,7 +240,7 @@ that Docker creates 12 environment variables, 3 for each port.
|
||||
Additionally, Docker creates an environment variable called `<alias>_PORT`.
|
||||
This variable contains the URL of the source container's first exposed port.
|
||||
The 'first' port is defined as the exposed port with the lowest number.
|
||||
For example, consider the `WEBDB_PORT=tcp://172.17.0.82:8080` variable. If
|
||||
For example, consider the `WEBDB_PORT=tcp://172.17.0.82:5432` variable. If
|
||||
that port is used for both tcp and udp, then the tcp one is specified.
|
||||
|
||||
Finally, Docker also exposes each Docker originated environment variable
|
||||
|
||||
@@ -28,7 +28,7 @@ Docker.
|
||||
|
||||
A *data volume* is a specially-designated directory within one or more
|
||||
containers that bypasses the [*Union File
|
||||
System*](/terms/layer/#union-file-system). Data volumes provide several
|
||||
System*](/reference/glossary#union-file-system). Data volumes provide several
|
||||
useful features for persistent or shared data:
|
||||
|
||||
- Volumes are initialized when a container is created. If the container's
|
||||
@@ -74,16 +74,21 @@ The output will provide details on the container configurations including the
|
||||
volumes. The output should look something similar to the following:
|
||||
|
||||
...
|
||||
"Volumes": {
|
||||
"/webapp": "/var/lib/docker/volumes/fac362...80535"
|
||||
},
|
||||
"VolumesRW": {
|
||||
"/webapp": true
|
||||
}
|
||||
Mounts": [
|
||||
{
|
||||
"Name": "fac362...80535",
|
||||
"Source": "/var/lib/docker/volumes/fac362...80535/_data",
|
||||
"Destination": "/webapp",
|
||||
"Driver": "local",
|
||||
"Mode": "",
|
||||
"RW": true
|
||||
}
|
||||
]
|
||||
...
|
||||
|
||||
You will notice in the above 'Volumes' is specifying the location on the host and
|
||||
'VolumesRW' is specifying that the volume is read/write.
|
||||
You will notice in the above 'Source' is specifying the location on the host and
|
||||
'Destination' is specifying the volume location inside the container. `RW` shows
|
||||
if the volume is read/write.
|
||||
|
||||
### Mount a host directory as a data volume
|
||||
|
||||
|
||||
@@ -11,11 +11,11 @@ parent="smn_containers"
|
||||
# Working with containers
|
||||
|
||||
In the [last section of the Docker User Guide](/userguide/dockerizing)
|
||||
we launched our first containers. We launched two containers using the
|
||||
`docker run` command.
|
||||
we launched our first containers. We launched containers using the
|
||||
`docker run` command:
|
||||
|
||||
* Containers we ran interactively in the foreground.
|
||||
* One container we ran daemonized in the background.
|
||||
* Interactive container runs in the foreground.
|
||||
* Daemonized container runs in the background.
|
||||
|
||||
In the process we learned about several Docker commands:
|
||||
|
||||
@@ -43,17 +43,22 @@ version information on the currently installed Docker client and daemon.
|
||||
This command will not only provide you the version of Docker client and
|
||||
daemon you are using, but also the version of Go (the programming
|
||||
language powering Docker).
|
||||
|
||||
Client:
|
||||
Version: 1.8.1
|
||||
API version: 1.20
|
||||
Go version: go1.4.2
|
||||
Git commit: d12ea79
|
||||
Built: Thu Aug 13 02:35:49 UTC 2015
|
||||
OS/Arch: linux/amd64
|
||||
|
||||
Client version: 0.8.0
|
||||
Go version (client): go1.2
|
||||
|
||||
Git commit (client): cc3a8c8
|
||||
Server version: 0.8.0
|
||||
|
||||
Git commit (server): cc3a8c8
|
||||
Go version (server): go1.2
|
||||
|
||||
Last stable version: 0.8.0
|
||||
Server:
|
||||
Version: 1.8.1
|
||||
API version: 1.20
|
||||
Go version: go1.4.2
|
||||
Git commit: d12ea79
|
||||
Built: Thu Aug 13 02:35:49 UTC 2015
|
||||
OS/Arch: linux/amd64
|
||||
|
||||
## Get Docker command help
|
||||
|
||||
@@ -105,7 +110,7 @@ Lastly, we've specified a command for our container to run: `python app.py`. Thi
|
||||
|
||||
> **Note:**
|
||||
> You can see more detail on the `docker run` command in the [command
|
||||
> reference](/reference/commandline/cli/#run) and the [Docker Run
|
||||
> reference](/reference/commandline/run) and the [Docker Run
|
||||
> Reference](/reference/run/).
|
||||
|
||||
## Viewing our web application container
|
||||
@@ -219,8 +224,8 @@ the container.
|
||||
## Inspecting our web application container
|
||||
|
||||
Lastly, we can take a low-level dive into our Docker container using the
|
||||
`docker inspect` command. It returns a JSON hash of useful configuration
|
||||
and status information about Docker containers.
|
||||
`docker inspect` command. It returns a JSON document containing useful
|
||||
configuration and status information for the specified container.
|
||||
|
||||
$ docker inspect nostalgic_morse
|
||||
|
||||
@@ -297,7 +302,7 @@ this again by stopping the container first.
|
||||
And now our container is stopped and deleted.
|
||||
|
||||
> **Note:**
|
||||
> Always remember that deleting a container is final!
|
||||
> Always remember that removing a container is final!
|
||||
|
||||
# Next steps
|
||||
|
||||
|
||||
Reference in New Issue
Block a user