kotovalexarian-likes-github/moby--moby
1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Code Releases Activity

Docs edits for dropping SSLv3 and under + release notes for 1.3.1

Browse source 
Signed-off-by: Tibor Vass <teabee89@gmail.com>

Conflicts:
	docs/sources/index.md

Conflicts:
	docs/sources/index.md
This commit is contained in:
Tibor Vass 2014-10-22 08:30:48 -04:00
parent 6a1ff022b0
commit e43d9f713e
6 changed files with 334 additions and 85 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
docs/mkdocs.yml Executable file → Normal file
View file

@ -26,6 +26,7 @@ pages:
# Introduction:
- ['index.md', 'About', 'Docker']
- ['release-notes.md', 'About', 'Release Notes']
- ['introduction/index.md', '**HIDDEN**']
- ['introduction/understanding-docker.md', 'About', 'Understanding Docker']

61
docs/sources/index.md
View file

@ -88,63 +88,4 @@ implementation, check out the [Docker User Guide](/userguide/).
## Release Notes
**Version 1.3.0**
This version fixes a number of bugs and issues and adds new functions and other
improvements. The [GitHub 1.3 milestone](https://github.com/docker/docker/issues?q=milestone%3A1.3.0+) has
more detailed information. Major additions and changes include:
*New command: `docker exec`*
The new `docker exec` command lets you run a process in an existing, active
container. The command has APIs for both the daemon and the client. With
`docker exec`, you'll be able to do things like add or remove devices from
running containers, debug running containers, and run commands that are not
part of the container's static specification. Details in the [command line
reference](/reference/commandline/cli/#exec).
*New command: `docker create`*
Traditionally, the `docker run` command has been used to both create a
container and spawn a process to run it. The new `docker create` command breaks
this apart, letting you set up a container without actually starting it. This
provides more control over management of the container lifecycle, giving you the
ability to configure things like volumes or port mappings before the container
is started. For example, in a rapid-response scaling situation, you could use
`create` to prepare and stage ten containers in anticipation of heavy loads.
Details in the [command line reference](/reference/commandline/cli/#create).
*Tech preview of new provenance features*
This release offers a sneak peek at new image signing capabilities that are
currently under development. Soon, these capabilities will allow any image
author to sign their images to certify they have not been tampered with. For
this release, Official images are now signed by Docker, Inc. Not only does this
demonstrate the new functionality, we hope it will improve your confidence in
the security of Official images. Look for the blue ribbons denoting signed
images on the [Docker Hub](https://hub.docker.com/).
The Docker Engine has been updated to automatically verify that a given
Official Repo has a current, valid signature. When pulling a signed image,
you'll see a message stating `the image you are pulling has been verified`. If
no valid signature is detected, Docker Engine will fall back to pulling a
regular, unsigned image.
*Other improvements & changes*
* We've added a new security options flag to the `docker run` command,
`--security-opt`, that lets you set SELinux and AppArmor labels and profiles.
This means you'll no longer have to use `docker run --privileged` on kernels
that support SE Linux or AppArmor. For more information, see the
[command line reference](/reference/commandline/cli/#run).
* A new flag, `--add-host`, has been added to `docker run` that lets you add
lines to `/etc/hosts`. This allows you to specify different name
resolution for the container than it would get via DNS. For more information,
see the [command line reference](/reference/commandline/cli/#run).
* You can now set a `DOCKER_TLS_VERIFY` environment variable to secure
connections by default (rather than having to pass the `--tlsverify` flag on
every call). For more information, see the [https guide](/articles/https).
* Three security issues have been addressed in this release: [CVE-2014-5280,
CVE-2014-5270, and CVE-2014-5282](https://groups.google.com/forum/#!msg/docker-announce/aQoVmQlcE0A/smPuBNYf8VwJ).
A summary of the changes in each release in the current series can now be found on the separate [Release Notes page](/release-notes/)

30
docs/sources/reference/api/hub_registry_spec.md
View file

@ -4,7 +4,9 @@ page_keywords: docker, registry, api, hub
# The Docker Hub and the Registry spec
## The 3 roles
## The three roles
There are three major components playing a role in the Docker ecosystem.
### Docker Hub
@ -21,13 +23,15 @@ The Docker Hub has different components:
- Authentication service
- Tokenization
The Docker Hub is authoritative for those information.
The Docker Hub is authoritative for that information.
We expect that there will be only one instance of the Docker Hub, run and
There is only one instance of the Docker Hub, run and
managed by Docker Inc.
### Registry
The registry has the following characteristics:
- It stores the images and the graph for a set of repositories
- It does not have user accounts data
- It has no notion of user accounts or authorization
@ -37,35 +41,35 @@ managed by Docker Inc.
- It doesn't have a local database
- [Source Code](https://github.com/docker/docker-registry)
We expect that there will be multiple registries out there. To help to
We expect that there will be multiple registries out there. To help you
grasp the context, here are some examples of registries:
- **sponsor registry**: such a registry is provided by a third-party
hosting infrastructure as a convenience for their customers and the
docker community as a whole. Its costs are supported by the third
Docker community as a whole. Its costs are supported by the third
party, but the management and operation of the registry are
supported by dotCloud. It features read/write access, and delegates
supported by Docker, Inc. It features read/write access, and delegates
authentication and authorization to the Docker Hub.
- **mirror registry**: such a registry is provided by a third-party
hosting infrastructure but is targeted at their customers only. Some
mechanism (unspecified to date) ensures that public images are
pulled from a sponsor registry to the mirror registry, to make sure
that the customers of the third-party provider can “docker pull”
that the customers of the third-party provider can `docker pull`
those images locally.
- **vendor registry**: such a registry is provided by a software
vendor, who wants to distribute docker images. It would be operated
vendor who wants to distribute docker images. It would be operated
and managed by the vendor. Only users authorized by the vendor would
be able to get write access. Some images would be public (accessible
for anyone), others private (accessible only for authorized users).
Authentication and authorization would be delegated to the Docker Hub.
The goal of vendor registries is to let someone do “docker pull
basho/riak1.3” and automatically push from the vendor registry
(instead of a sponsor registry); i.e. get all the convenience of a
The goal of vendor registries is to let someone do `docker pull
basho/riak1.3` and automatically push from the vendor registry
(instead of a sponsor registry); i.e., vendors get all the convenience of a
sponsor registry, while retaining control on the asset distribution.
- **private registry**: such a registry is located behind a firewall,
or protected by an additional security layer (HTTP authorization,
SSL client-side certificates, IP address authorization...). The
registry is operated by a private entity, outside of dotCloud's
registry is operated by a private entity, outside of Docker's
control. It can optionally delegate additional authorization to the
Docker Hub, but it is not mandatory.
@ -77,7 +81,7 @@ grasp the context, here are some examples of registries:
> - local mount point;
> - remote docker addressed through SSH.
The latter would only require two new commands in docker, e.g.,
The latter would only require two new commands in Docker, e.g.,
`registryget` and `registryput`,
wrapping access to the local filesystem (and optionally doing
consistency checks). Authentication and authorization are then delegated

29
docs/sources/reference/api/registry_api.md
View file

@ -21,30 +21,30 @@ grasp the context, here are some examples of registries:
- **sponsor registry**: such a registry is provided by a third-party
hosting infrastructure as a convenience for their customers and the
docker community as a whole. Its costs are supported by the third
Docker community as a whole. Its costs are supported by the third
party, but the management and operation of the registry are
supported by dotCloud. It features read/write access, and delegates
supported by Docker. It features read/write access, and delegates
authentication and authorization to the Index.
- **mirror registry**: such a registry is provided by a third-party
hosting infrastructure but is targeted at their customers only. Some
mechanism (unspecified to date) ensures that public images are
pulled from a sponsor registry to the mirror registry, to make sure
that the customers of the third-party provider can “docker pull”
that the customers of the third-party provider can `docker pull`
those images locally.
- **vendor registry**: such a registry is provided by a software
vendor, who wants to distribute docker images. It would be operated
vendor, who wants to distribute Docker images. It would be operated
and managed by the vendor. Only users authorized by the vendor would
be able to get write access. Some images would be public (accessible
for anyone), others private (accessible only for authorized users).
Authentication and authorization would be delegated to the Index.
The goal of vendor registries is to let someone do “docker pull
basho/riak1.3” and automatically push from the vendor registry
(instead of a sponsor registry); i.e. get all the convenience of a
The goal of vendor registries is to let someone do `docker pull
basho/riak1.3` and automatically push from the vendor registry
(instead of a sponsor registry); i.e., get all the convenience of a
sponsor registry, while retaining control on the asset distribution.
- **private registry**: such a registry is located behind a firewall,
or protected by an additional security layer (HTTP authorization,
SSL client-side certificates, IP address authorization...). The
registry is operated by a private entity, outside of dotCloud's
registry is operated by a private entity, outside of Docker's
control. It can optionally delegate additional authorization to the
Index, but it is not mandatory.
@ -52,7 +52,7 @@ grasp the context, here are some examples of registries:
> Mirror registries and private registries which do not use the Index
> don't even need to run the registry code. They can be implemented by any
> kind of transport implementing HTTP GET and PUT. Read-only registries
> can be powered by a simple static HTTP server.
> can be powered by a simple static HTTPS server.
> **Note**:
> The latter implies that while HTTP is the protocol of choice for a registry,
@ -60,13 +60,20 @@ grasp the context, here are some examples of registries:
>
> - HTTP with GET (and PUT for read-write registries);
> - local mount point;
> - remote docker addressed through SSH.
> - remote Docker addressed through SSH.
The latter would only require two new commands in docker, e.g.,
The latter would only require two new commands in Docker, e.g.,
`registryget` and `registryput`, wrapping access to the local filesystem
(and optionally doing consistency checks). Authentication and authorization
are then delegated to SSH (e.g., with public keys).
> **Note**:
> Private registry servers that expose an HTTP endpoint need to be secured with
> TLS (preferably TLSv1.2, but at least TLSv1.0). Make sure to put the CA
> certificate at /etc/docker/certs.d/my.registry.com:5000/ca.crt on the Docker
> host, so that the daemon can securely access the private registry.
> Support for SSLv3 and lower is not available due to security issues.
The default namespace for a private repository is `library`.
# Endpoints

7
docs/sources/reference/commandline/cli.md
View file

@ -112,7 +112,12 @@ direct access to the Docker daemon - and should be secured either using the
[built in https encrypted socket](/articles/https/), or by putting a secure web
proxy in front of it. You can listen on port `2375` on all network interfaces
with `-H tcp://0.0.0.0:2375`, or on a particular network interface using its IP
address: `-H tcp://192.168.59.103:2375`.
address: `-H tcp://192.168.59.103:2375`. It is conventional to use port `2375`
for un-encrypted, and port `2376` for encrypted communication with the daemon.
> **Note** If you're using an HTTPS encrypted socket, keep in mind that only TLS1.0
> and greater are supported. Protocols SSLv3 and under are not supported anymore
> for security reasons.
On Systemd based systems, you can communicate with the daemon via
[systemd socket activation](http://0pointer.de/blog/projects/socket-activation.html), use

291
docs/sources/release-notes.md Normal file
View file

@ -0,0 +1,291 @@
page_title: Docker 1.x Series Release Notes page_description: Release Notes for
Docker 1.x. page_keywords: docker, documentation, about, technology,
understanding, release
#Release Notes
##Version 1.3.1
(2014-10-28)
This release fixes some bugs and addresses some security issues.
*Security fixes*
Patches and changes were made to address CVE-2014-5277 and CVE-2014-3566. Specifically, changes were made to:
* Prevent fallback to SSL protocols < TLS 1.0 for client, daemon and registry
* Secure HTTPS connection to registries with certificate verification and without HTTP fallback unless `--insecure-registry` is specified.
*Runtime fixes*
* Fixed issue where volumes would not be shared
*Client fixes*
* Fixed issue with `--iptables=false` not automatically setting
`--ip-masq=false`
* Fixed docker run output to non-TTY stdout
*Builder fixes*
* Fixed escaping `$` for environment variables
* Fixed issue with lowercase `onbuild` Dockerfile instruction
##Version 1.3.0
This version fixes a number of bugs and issues and adds new functions and other
improvements. The [GitHub 1.3milestone](https://github.com/docker/docker/issues?q=milestone%3A1.3.0+) has
more detailed information. Major additions and changes include:
###New Features
*New command: `docker exec`*
The new `docker exec` command lets you run a process in an existing, active
container. The command has APIs for both the daemon and the client. With `docker
exec`, you'll be able to do things like add or remove devices from running
containers, debug running containers, and run commands that are not part of the
container's static specification. Details in the [command line reference](/reference/commandline/cli/#exec).
*New command: `docker create`*
Traditionally, the `docker run` command has been used to both create a container
and spawn a process to run it. The new `docker create` command breaks this
apart, letting you set up a container without actually starting it. This
provides more control over management of the container lifecycle, giving you the
ability to configure things like volumes or port mappings before the container
is started. For example, in a rapid-response scaling situation, you could use
`create` to prepare and stage ten containers in anticipation of heavy loads.
Details in the [command line reference](/reference/commandline/cli/#create).
*Tech preview of new provenance features*
This release offers a sneak peek at new image signing capabilities that are
currently under development. Soon, these capabilities will allow any image
author to sign their images to certify they have not been tampered with. For
this release, Official images are now signed by Docker, Inc. Not only does this
demonstrate the new functionality, we hope it will improve your confidence in
the security of Official images. Look for the blue ribbons denoting signed
images on the [Docker Hub](https://hub.docker.com/). The Docker Engine has been
updated to automatically verify that a given Official Repo has a current, valid
signature. When pulling a signed image, you'll see a message stating `the image
you are pulling has been verified`. If no valid signature is detected, Docker
Engine will fall back to pulling a regular, unsigned image.
###Other improvements & changes*
* We've added a new security options flag to the `docker run` command,
`--security-opt`, that lets you set SELinux and AppArmor labels and profiles.
This means you'll no longer have to use `docker run --privileged` on kernels
that support SE Linux or AppArmor. For more information, see the [command line
reference](/reference/commandline/cli/#run).
* A new flag, `--add-host`, has been added to `docker run` that lets you add
lines to `/etc/hosts`. This allows you to specify different name resolution for
the container than it would get via DNS. For more information, see the [command
line reference](/reference/commandline/cli/#run).
* You can now set a `DOCKER_TLS_VERIFY` environment variable to secure
connections by default (rather than having to pass the `--tlsverify` flag on
every call). For more information, see the [https guide](/articles/https).
* Three security issues have been addressed in this release: [CVE-2014-5280,
CVE-2014-5270, and
CVE-2014-5282](https://groups.google.com/forum/#!msg/docker-announce/aQoVmQlcE0A/smPuBNYf8VwJ).
##Version 1.2.0
This version fixes a number of bugs and issues and adds new functions and other
improvements. These include:
###New Features
*New restart policies*
We added a `--restart flag` to `docker run` to specify a restart policy for your
container. Currently, there are three policies available:
* `no` – Do not restart the container if it dies. (default) * `on-failure` –
Restart the container if it exits with a non-zero exit code. This can also
accept an optional maximum restart count (e.g. `on-failure:5`). * `always` –
Always restart the container no matter what exit code is returned. This
deprecates the `--restart` flag on the Docker daemon.
*New flags for `docker run`: `--cap-add` and `–-cap-drop`*
In previous releases, Docker containers could either be given complete
capabilities or they could all follow a whitelist of allowed capabilities while
dropping all others. Further, using `--privileged` would grant all capabilities
inside a container, rather than applying a whitelist. This was not recommended
for production use because it’s really unsafe; it’s as if you were directly in
the host.
This release introduces two new flags for `docker run`, `--cap-add` and
`--cap-drop`, that give you fine-grain control over the specific capabilities
you want grant to a particular container.
*New `-–device` flag for `docker run`*
Previously, you could only use devices inside your containers by bind mounting
them (with `-v`) in a `--privileged` container. With this release, we introduce
the `--device flag` to `docker run` which lets you use a device without
requiring a privileged container.
*Writable `/etc/hosts`, `/etc/hostname` and `/etc/resolv.conf`*
You can now edit `/etc/hosts`, `/etc/hostname` and `/etc/resolve.conf` in a
running container. This is useful if you need to install BIND or other services
that might override one of those files.
Note, however, that changes to these files are not saved when running `docker
build` and so will not be preserved in the resulting image. The changes will
only “stick” in a running container.
*Docker proxy in a separate process*
The Docker userland proxy that routes outbound traffic to your containers now
has its own separate process (one process per connection). This greatly reduces
the load on the daemon, which increases stability and efficiency.
###Other improvements & changes
* When using `docker rm -f`, Docker now kills the container (instead of stopping
it) before removing it . If you intend to stop the container cleanly, you can
use `docker stop`.
* Added support for IPv6 addresses in `--dns`
* Added search capability in private registries
##Version 1.1.0
###New Features
*`.dockerignore` support*
You can now add a `.dockerignore` file next to your `Dockerfile` and Docker will
ignore files and directories specified in that file when sending the build
context to the daemon. Example:
https://github.com/docker/docker/blob/master/.dockerignore
*Pause containers during commit*
Doing a commit on a running container was not recommended because you could end
up with files in an inconsistent state (for example, if they were being written
during the commit). Containers are now paused when a commit is made to them. You
can disable this feature by doing a `docker commit --pause=false <container_id>`
*Tailing logs*
You can now tail the logs of a container. For example, you can get the last ten
lines of a log by using `docker logs --tail 10 <container_id>`. You can also
follow the logs of a container without having to read the whole log file with
`docker logs --tail 0 -f <container_id>`.
*Allow a tar file as context for docker build*
You can now pass a tar archive to `docker build` as context. This can be used to
automate docker builds, for example: `cat context.tar | docker build -` or
`docker run builder_image | docker build -`
*Bind mounting your whole filesystem in a container*
`/` is now allowed as source of `--volumes`. This means you can bind-mount your
whole system in a container if you need to. For example: `docker run -v
/:/my_host ubuntu:ro ls /my_host`. However, it is now forbidden to mount to /.
###Other Improvements & Changes
* Port allocation has been improved. In the previous release, Docker could
prevent you from starting a container with previously allocated ports which
seemed to be in use when in fact they were not. This has been fixed.
* A bug in `docker save` was introduced in the last release. The `docker save`
command could produce images with invalid metadata. The command now produces
images with correct metadata.
* Running `docker inspect` in a container now returns which containers it is
linked to.
* Parsing of the `docker commit` flag has improved validation, to better prevent
you from committing an image with a name such as `-m`. Image names with dashes
in them potentially conflict with command line flags.
* The API now has Improved status codes for `start` and `stop`. Trying to start
a running container will now return a 304 error.
* Performance has been improved overall. Starting the daemon is faster than in
previous releases. The daemon’s performance has also been improved when it is
working with large numbers of images and containers.
* Fixed an issue with white-spaces and multi-lines in Dockerfiles.
##Version 1.1.0
###New Features
*`.dockerignore` support*
You can now add a `.dockerignore` file next to your `Dockerfile` and Docker will
ignore files and directories specified in that file when sending the build
context to the daemon. Example:
https://github.com/dotcloud/docker/blob/master/.dockerignore
*Pause containers during commit*
Doing a commit on a running container was not recommended because you could end
up with files in an inconsistent state (for example, if they were being written
during the commit). Containers are now paused when a commit is made to them. You
can disable this feature by doing a `docker commit --pause=false <container_id>`
*Tailing logs*
You can now tail the logs of a container. For example, you can get the last ten
lines of a log by using `docker logs --tail 10 <container_id>`. You can also
follow the logs of a container without having to read the whole log file with
`docker logs --tail 0 -f <container_id>`.
*Allow a tar file as context for docker build*
You can now pass a tar archive to `docker build` as context. This can be used to
automate docker builds, for example: `cat context.tar | docker build -` or
`docker run builder_image | docker build -`
*Bind mounting your whole filesystem in a container*
`/` is now allowed as source of `--volumes`. This means you can bind-mount your
whole system in a container if you need to. For example: `docker run -v
/:/my_host ubuntu:ro ls /my_host`. However, it is now forbidden to mount to /.
###Other Improvements & Changes
* Port allocation has been improved. In the previous release, Docker could
prevent you from starting a container with previously allocated ports which
seemed to be in use when in fact they were not. This has been fixed.
* A bug in `docker save` was introduced in the last release. The `docker save`
command could produce images with invalid metadata. The command now produces
images with correct metadata.
* Running `docker inspect` in a container now returns which containers it is
linked to.
* Parsing of the `docker commit` flag has improved validation, to better prevent
you from committing an image with a name such as `-m`. Image names with dashes
in them potentially conflict with command line flags.
* The API now has Improved status codes for `start` and `stop`. Trying to start
a running container will now return a 304 error.
* Performance has been improved overall. Starting the daemon is faster than in
previous releases. The daemon’s performance has also been improved when it is
working with large numbers of images and containers.
* Fixed an issue with white-spaces and multi-lines in Dockerfiles.
##Version 1.0.0
First production-ready release. Prior development history can be found by
searching in [GitHub](https://github.com/docker/docker).