Revert "update to use containerd seccomp package"

This reverts commit 4f8e065faf055d3f0463a92622297ca3afac07f4.

vendor/github.com/docker/docker-ce/components/engine/docs/api/version-history.md

@@ -0,0 +1,415 @@
+---
+title: "Engine API version history"
+description: "Documentation of changes that have been made to Engine API."
+keywords: "API, Docker, rcli, REST, documentation"
+---
+
+<!-- This file is maintained within the moby/moby GitHub
+     repository at https://github.com/moby/moby/. Make all
+     pull requests against that repo. If you see this file in
+     another repository, consider it read-only there, as it will
+     periodically be overwritten by the definitive file. Pull
+     requests which include edits to this file in other repositories
+     will be rejected.
+-->
+
+## v1.37 API changes
+
+[Docker Engine API v1.37](https://docs.docker.com/engine/api/v1.36/) documentation
+
+* `POST /containers/create` and `POST /services/create` now supports exposing SCTP ports.
+* `POST /configs/create` and `POST /configs/{id}/create` now accept a `Templating` driver.
+* `GET /configs` and `GET /configs/{id}` now return the `Templating` driver of the config.
+* `POST /secrets/create` and `POST /secrets/{id}/create` now accept a `Templating` driver.
+* `GET /secrets` and `GET /secrets/{id}` now return the `Templating` driver of the secret.
+
+## v1.36 API changes
+
+[Docker Engine API v1.36](https://docs.docker.com/engine/api/v1.36/) documentation
+
+* `Get /events` now return `exec_die` event when an exec process terminates.  
+
+
+## v1.35 API changes
+
+[Docker Engine API v1.35](https://docs.docker.com/engine/api/v1.35/) documentation
+
+* `POST /services/create` and `POST /services/(id)/update` now accepts an
+  `Isolation` field on container spec to set the Isolation technology of the
+  containers running the service (`default`, `process`, or `hyperv`). This
+  configuration is only used for Windows containers.
+* `GET /containers/(name)/logs` now supports an additional query parameter: `until`,
+  which returns log lines that occurred before the specified timestamp.
+* `POST /containers/{id}/exec` now accepts a `WorkingDir` property to set the
+  work-dir for the exec process, independent of the container's work-dir.
+* `Get /version` now returns a `Platform.Name` field, which can be used by products
+  using Moby as a foundation to return information about the platform.
+* `Get /version` now returns a `Components` field, which can be used to return
+  information about the components used. Information about the engine itself is
+  now included as a "Component" version, and contains all information from the
+  top-level `Version`, `GitCommit`, `APIVersion`, `MinAPIVersion`, `GoVersion`,
+  `Os`, `Arch`, `BuildTime`, `KernelVersion`, and `Experimental` fields. Going
+  forward, the information from the `Components` section is preferred over their
+  top-level counterparts.
+
+
+## v1.34 API changes
+
+[Docker Engine API v1.34](https://docs.docker.com/engine/api/v1.34/) documentation
+
+* `POST /containers/(name)/wait?condition=removed` now also also returns
+  in case of container removal failure. A pointer to a structure named
+  `Error` added to the response JSON in order to indicate a failure.
+  If `Error` is `null`, container removal has succeeded, otherwise
+  the test of an error message indicating why container removal has failed
+  is available from `Error.Message` field.
+
+## v1.33 API changes
+
+[Docker Engine API v1.33](https://docs.docker.com/engine/api/v1.33/) documentation
+
+* `GET /events` now supports filtering 4 more kinds of events: `config`, `node`,
+`secret` and `service`.
+
+## v1.32 API changes
+
+[Docker Engine API v1.32](https://docs.docker.com/engine/api/v1.32/) documentation
+
+* `POST /containers/create` now accepts additional values for the
+  `HostConfig.IpcMode` property. New values are `private`, `shareable`,
+  and `none`.
+* `DELETE /networks/{id or name}` fixed issue where a `name` equal to another
+  network's name was able to mask that `id`. If both a network with the given
+  _name_ exists, and a network with the given _id_, the network with the given
+  _id_ is now deleted. This change is not versioned, and affects all API versions
+  if the daemon has this patch.
+
+## v1.31 API changes
+
+[Docker Engine API v1.31](https://docs.docker.com/engine/api/v1.31/) documentation
+
+* `DELETE /secrets/(name)` now returns status code 404 instead of 500 when the secret does not exist.
+* `POST /secrets/create` now returns status code 409 instead of 500 when creating an already existing secret.
+* `POST /secrets/create` now accepts a `Driver` struct, allowing the
+  `Name` and driver-specific `Options` to be passed to store a secrets
+  in an external secrets store. The `Driver` property can be omitted
+  if the default (internal) secrets store is used.
+* `GET /secrets/(id)` and `GET /secrets` now return a `Driver` struct,
+  containing the `Name` and driver-specific `Options` of the external
+  secrets store used to store the secret. The `Driver` property is
+  omitted if no external store is used.
+* `POST /secrets/(name)/update` now returns status code 400 instead of 500 when updating a secret's content which is not the labels.
+* `POST /nodes/(name)/update` now returns status code 400 instead of 500 when demoting last node fails.
+* `GET /networks/(id or name)` now takes an optional query parameter `scope` that will filter the network based on the scope (`local`, `swarm`, or `global`).
+* `POST /session` is a new endpoint that can be used for running interactive long-running protocols between client and
+  the daemon. This endpoint is experimental and only available if the daemon is started with experimental features
+  enabled.
+* `GET /images/(name)/get` now includes an `ImageMetadata` field which contains image metadata that is local to the engine and not part of the image config.
+* `POST /services/create` now accepts a `PluginSpec` when `TaskTemplate.Runtime` is set to `plugin`
+* `GET /events` now supports config events `create`, `update` and `remove` that are emitted when users create, update or remove a config
+* `GET /volumes/` and `GET /volumes/{name}` now return a `CreatedAt` field,
+  containing the date/time the volume was created. This field is omitted if the
+  creation date/time for the volume is unknown. For volumes with scope "global",
+  this field represents the creation date/time of the local _instance_ of the
+  volume, which may differ from instances of the same volume on different nodes.
+* `GET /system/df` now returns a `CreatedAt` field for `Volumes`. Refer to the
+  `/volumes/` endpoint for a description of this field.
+
+## v1.30 API changes
+
+[Docker Engine API v1.30](https://docs.docker.com/engine/api/v1.30/) documentation
+
+* `GET /info` now returns the list of supported logging drivers, including plugins.
+* `GET /info` and `GET /swarm` now returns the cluster-wide swarm CA info if the node is in a swarm: the cluster root CA certificate, and the cluster TLS
+ leaf certificate issuer's subject and public key. It also displays the desired CA signing certificate, if any was provided as part of the spec.
+* `POST /build/` now (when not silent) produces an `Aux` message in the JSON output stream with payload `types.BuildResult` for each image produced. The final such message will reference the image resulting from the build.
+* `GET /nodes` and `GET /nodes/{id}` now returns additional information about swarm TLS info if the node is part of a swarm: the trusted root CA, and the
+ issuer's subject and public key.
+* `GET /distribution/(name)/json` is a new endpoint that returns a JSON output stream with payload `types.DistributionInspect` for an image name. It includes a descriptor with the digest, and supported platforms retrieved from directly contacting the registry.
+* `POST /swarm/update` now accepts 3 additional parameters as part of the swarm spec's CA configuration; the desired CA certificate for
+ the swarm, the desired CA key for the swarm (if not using an external certificate), and an optional parameter to force swarm to
+ generate and rotate to a new CA certificate/key pair.
+* `POST /service/create` and `POST /services/(id or name)/update` now take the field `Platforms` as part of the service `Placement`, allowing to specify platforms supported by the service.
+* `POST /containers/(name)/wait` now accepts a `condition` query parameter to indicate which state change condition to wait for. Also, response headers are now returned immediately to acknowledge that the server has registered a wait callback for the client.
+* `POST /swarm/init` now accepts a `DataPathAddr` property to set the IP-address or network interface to use for data traffic
+* `POST /swarm/join` now accepts a `DataPathAddr` property to set the IP-address or network interface to use for data traffic
+* `GET /events` now supports service, node and secret events which are emitted when users create, update and remove service, node and secret
+* `GET /events` now supports network remove event which is emitted when users remove a swarm scoped network
+* `GET /events` now supports a filter type `scope` in which supported value could be swarm and local
+
+## v1.29 API changes
+
+[Docker Engine API v1.29](https://docs.docker.com/engine/api/v1.29/) documentation
+
+* `DELETE /networks/(name)` now allows to remove the ingress network, the one used to provide the routing-mesh.
+* `POST /networks/create` now supports creating the ingress network, by specifying an `Ingress` boolean field. As of now this is supported only when using the overlay network driver.
+* `GET /networks/(name)` now returns an `Ingress` field showing whether the network is the ingress one.
+* `GET /networks/` now supports a `scope` filter to filter networks based on the network mode (`swarm`, `global`, or `local`).
+* `POST /containers/create`, `POST /service/create` and `POST /services/(id or name)/update` now takes the field `StartPeriod` as a part of the `HealthConfig` allowing for specification of a period during which the container should not be considered unhealthy even if health checks do not pass.
+* `GET /services/(id)` now accepts an `insertDefaults` query-parameter to merge default values into the service inspect output.
+* `POST /containers/prune`, `POST /images/prune`, `POST /volumes/prune`, and `POST /networks/prune` now support a `label` filter to filter containers, images, volumes, or networks based on the label. The format of the label filter could be `label=<key>`/`label=<key>=<value>` to remove those with the specified labels, or `label!=<key>`/`label!=<key>=<value>` to remove those without the specified labels.
+* `POST /services/create` now accepts `Privileges` as part of `ContainerSpec`. Privileges currently include
+  `CredentialSpec` and `SELinuxContext`.
+
+## v1.28 API changes
+
+[Docker Engine API v1.28](https://docs.docker.com/engine/api/v1.28/) documentation
+
+* `POST /containers/create` now includes a `Consistency` field to specify the consistency level for each `Mount`, with possible values `default`, `consistent`, `cached`, or `delegated`.
+* `GET /containers/create` now takes a `DeviceCgroupRules` field in `HostConfig` allowing to set custom device cgroup rules for the created container.
+* Optional query parameter `verbose` for `GET /networks/(id or name)` will now list all services with all the tasks, including the non-local tasks on the given network.
+* `GET /containers/(id or name)/attach/ws` now returns WebSocket in binary frame format for API version >= v1.28, and returns WebSocket in text frame format for API version< v1.28, for the purpose of backward-compatibility.
+* `GET /networks` is optimised only to return list of all networks and network specific information. List of all containers attached to a specific network is removed from this API and is only available using the network specific `GET /networks/{network-id}.
+* `GET /containers/json` now supports `publish` and `expose` filters to filter containers that expose or publish certain ports.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept the `ReadOnly` parameter, which mounts the container's root filesystem as read only.
+* `POST /build` now accepts `extrahosts` parameter to specify a host to ip mapping to use during the build.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept a `rollback` value for `FailureAction`.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept an optional `RollbackConfig` object which specifies rollback options.
+* `GET /services` now supports a `mode` filter to filter services based on the service mode (either `global` or `replicated`).
+* `POST /containers/(name)/update` now supports updating `NanoCPUs` that represents CPU quota in units of 10<sup>-9</sup> CPUs.
+
+## v1.27 API changes
+
+[Docker Engine API v1.27](https://docs.docker.com/engine/api/v1.27/) documentation
+
+* `GET /containers/(id or name)/stats` now includes an `online_cpus` field in both `precpu_stats` and `cpu_stats`. If this field is `nil` then for compatibility with older daemons the length of the corresponding `cpu_usage.percpu_usage` array should be used.
+
+## v1.26 API changes
+
+[Docker Engine API v1.26](https://docs.docker.com/engine/api/v1.26/) documentation
+
+* `POST /plugins/(plugin name)/upgrade` upgrade a plugin.
+
+## v1.25 API changes
+
+[Docker Engine API v1.25](https://docs.docker.com/engine/api/v1.25/) documentation
+
+* The API version is now required in all API calls. Instead of just requesting, for example, the URL `/containers/json`, you must now request `/v1.25/containers/json`.
+* `GET /version` now returns `MinAPIVersion`.
+* `POST /build` accepts `networkmode` parameter to specify network used during build.
+* `GET /images/(name)/json` now returns `OsVersion` if populated
+* `GET /info` now returns `Isolation`.
+* `POST /containers/create` now takes `AutoRemove` in HostConfig, to enable auto-removal of the container on daemon side when the container's process exits.
+* `GET /containers/json` and `GET /containers/(id or name)/json` now return `"removing"` as a value for the `State.Status` field if the container is being removed. Previously, "exited" was returned as status.
+* `GET /containers/json` now accepts `removing` as a valid value for the `status` filter.
+* `GET /containers/json` now supports filtering containers by `health` status.
+* `DELETE /volumes/(name)` now accepts a `force` query parameter to force removal of volumes that were already removed out of band by the volume driver plugin.
+* `POST /containers/create/` and `POST /containers/(name)/update` now validates restart policies.
+* `POST /containers/create` now validates IPAMConfig in NetworkingConfig, and returns error for invalid IPv4 and IPv6 addresses (`--ip` and `--ip6` in `docker create/run`).
+* `POST /containers/create` now takes a `Mounts` field in `HostConfig` which replaces `Binds`, `Volumes`, and `Tmpfs`. *note*: `Binds`, `Volumes`, and `Tmpfs` are still available and can be combined with `Mounts`.
+* `POST /build` now performs a preliminary validation of the `Dockerfile` before starting the build, and returns an error if the syntax is incorrect. Note that this change is _unversioned_ and applied to all API versions.
+* `POST /build` accepts `cachefrom` parameter to specify images used for build cache.
+* `GET /networks/` endpoint now correctly returns a list of *all* networks,
+  instead of the default network if a trailing slash is provided, but no `name`
+  or `id`.
+* `DELETE /containers/(name)` endpoint now returns an error of `removal of container name is already in progress` with status code of 400, when container name is in a state of removal in progress.
+* `GET /containers/json` now supports a `is-task` filter to filter
+  containers that are tasks (part of a service in swarm mode).
+* `POST /containers/create` now takes `StopTimeout` field.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept `Monitor` and `MaxFailureRatio` parameters, which control the response to failures during service updates.
+* `POST /services/(id or name)/update` now accepts a `ForceUpdate` parameter inside the `TaskTemplate`, which causes the service to be updated even if there are no changes which would ordinarily trigger an update.
+* `POST /services/create` and `POST /services/(id or name)/update` now return a `Warnings` array.
+* `GET /networks/(name)` now returns field `Created` in response to show network created time.
+* `POST /containers/(id or name)/exec` now accepts an `Env` field, which holds a list of environment variables to be set in the context of the command execution.
+* `GET /volumes`, `GET /volumes/(name)`, and `POST /volumes/create` now return the `Options` field which holds the driver specific options to use for when creating the volume.
+* `GET /exec/(id)/json` now returns `Pid`, which is the system pid for the exec'd process.
+* `POST /containers/prune` prunes stopped containers.
+* `POST /images/prune` prunes unused images.
+* `POST /volumes/prune` prunes unused volumes.
+* `POST /networks/prune` prunes unused networks.
+* Every API response now includes a `Docker-Experimental` header specifying if experimental features are enabled (value can be `true` or `false`).
+* Every API response now includes a `API-Version` header specifying the default API version of the server.
+* The `hostConfig` option now accepts the fields `CpuRealtimePeriod` and `CpuRtRuntime` to allocate cpu runtime to rt tasks when `CONFIG_RT_GROUP_SCHED` is enabled in the kernel.
+* The `SecurityOptions` field within the `GET /info` response now includes `userns` if user namespaces are enabled in the daemon.
+* `GET /nodes` and `GET /node/(id or name)` now return `Addr` as part of a node's `Status`, which is the address that that node connects to the manager from.
+* The `HostConfig` field now includes `NanoCPUs` that represents CPU quota in units of 10<sup>-9</sup> CPUs.
+* `GET /info` now returns more structured information about security options.
+* The `HostConfig` field now includes `CpuCount` that represents the number of CPUs available for execution by the container. Windows daemon only.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept the `TTY` parameter, which allocate a pseudo-TTY in container.
+* `POST /services/create` and `POST /services/(id or name)/update` now accept the `DNSConfig` parameter, which specifies DNS related configurations in resolver configuration file (resolv.conf) through `Nameservers`, `Search`, and `Options`.
+* `GET /networks/(id or name)` now includes IP and name of all peers nodes for swarm mode overlay networks.
+* `GET /plugins` list plugins.
+* `POST /plugins/pull?name=<plugin name>` pulls a plugin.
+* `GET /plugins/(plugin name)` inspect a plugin.
+* `POST /plugins/(plugin name)/set` configure a plugin.
+* `POST /plugins/(plugin name)/enable` enable a plugin.
+* `POST /plugins/(plugin name)/disable` disable a plugin.
+* `POST /plugins/(plugin name)/push` push a plugin.
+* `POST /plugins/create?name=(plugin name)` create a plugin.
+* `DELETE /plugins/(plugin name)` delete a plugin.
+* `POST /node/(id or name)/update` now accepts both `id` or `name` to identify the node to update.
+* `GET /images/json` now support a `reference` filter.
+* `GET /secrets` returns information on the secrets.
+* `POST /secrets/create` creates a secret.
+* `DELETE /secrets/{id}` removes the secret `id`.
+* `GET /secrets/{id}` returns information on the secret `id`.
+* `POST /secrets/{id}/update` updates the secret `id`.
+* `POST /services/(id or name)/update` now accepts service name or prefix of service id as a parameter.
+* `POST /containers/create` added 2 built-in log-opts that work on all logging drivers,
+  `mode` (`blocking`|`non-blocking`), and `max-buffer-size` (e.g. `2m`) which enables a non-blocking log buffer.
+* `POST /containers/create` now takes `HostConfig.Init` field to run an init
+  inside the container that forwards signals and reaps processes.
+
+## v1.24 API changes
+
+[Docker Engine API v1.24](v1.24.md) documentation
+
+* `POST /containers/create` now takes `StorageOpt` field.
+* `GET /info` now returns `SecurityOptions` field, showing if `apparmor`, `seccomp`, or `selinux` is supported.
+* `GET /info` no longer returns the `ExecutionDriver` property. This property was no longer used after integration
+  with ContainerD in Docker 1.11.
+* `GET /networks` now supports filtering by `label` and `driver`.
+* `GET /containers/json` now supports filtering containers by `network` name or id.
+* `POST /containers/create` now takes `IOMaximumBandwidth` and `IOMaximumIOps` fields. Windows daemon only.
+* `POST /containers/create` now returns an HTTP 400 "bad parameter" message
+  if no command is specified (instead of an HTTP 500 "server error")
+* `GET /images/search` now takes a `filters` query parameter.
+* `GET /events` now supports a `reload` event that is emitted when the daemon configuration is reloaded.
+* `GET /events` now supports filtering by daemon name or ID.
+* `GET /events` now supports a `detach` event that is emitted on detaching from container process.
+* `GET /events` now supports an `exec_detach ` event that is emitted on detaching from exec process.
+* `GET /images/json` now supports filters `since` and `before`.
+* `POST /containers/(id or name)/start` no longer accepts a `HostConfig`.
+* `POST /images/(name)/tag` no longer has a `force` query parameter.
+* `GET /images/search` now supports maximum returned search results `limit`.
+* `POST /containers/{name:.*}/copy` is now removed and errors out starting from this API version.
+* API errors are now returned as JSON instead of plain text.
+* `POST /containers/create` and `POST /containers/(id)/start` allow you to configure kernel parameters (sysctls) for use in the container.
+* `POST /containers/<container ID>/exec` and `POST /exec/<exec ID>/start`
+  no longer expects a "Container" field to be present. This property was not used
+  and is no longer sent by the docker client.
+* `POST /containers/create/` now validates the hostname (should be a valid RFC 1123 hostname).
+* `POST /containers/create/` `HostConfig.PidMode` field now accepts `container:<name|id>`,
+  to have the container join the PID namespace of an existing container.
+
+## v1.23 API changes
+
+[Docker Engine API v1.23](v1.23.md) documentation
+
+* `GET /containers/json` returns the state of the container, one of `created`, `restarting`, `running`, `paused`, `exited` or `dead`.
+* `GET /containers/json` returns the mount points for the container.
+* `GET /networks/(name)` now returns an `Internal` field showing whether the network is internal or not.
+* `GET /networks/(name)` now returns an `EnableIPv6` field showing whether the network has ipv6 enabled or not.
+* `POST /containers/(name)/update` now supports updating container's restart policy.
+* `POST /networks/create` now supports enabling ipv6 on the network by setting the `EnableIPv6` field (doing this with a label will no longer work).
+* `GET /info` now returns `CgroupDriver` field showing what cgroup driver the daemon is using; `cgroupfs` or `systemd`.
+* `GET /info` now returns `KernelMemory` field, showing if "kernel memory limit" is supported.
+* `POST /containers/create` now takes `PidsLimit` field, if the kernel is >= 4.3 and the pids cgroup is supported.
+* `GET /containers/(id or name)/stats` now returns `pids_stats`, if the kernel is >= 4.3 and the pids cgroup is supported.
+* `POST /containers/create` now allows you to override usernamespaces remapping and use privileged options for the container.
+* `POST /containers/create` now allows specifying `nocopy` for named volumes, which disables automatic copying from the container path to the volume.
+* `POST /auth` now returns an `IdentityToken` when supported by a registry.
+* `POST /containers/create` with both `Hostname` and `Domainname` fields specified will result in the container's hostname being set to `Hostname`, rather than `Hostname.Domainname`.
+* `GET /volumes` now supports more filters, new added filters are `name` and `driver`.
+* `GET /containers/(id or name)/logs` now accepts a `details` query parameter to stream the extra attributes that were provided to the containers `LogOpts`, such as environment variables and labels, with the logs.
+* `POST /images/load` now returns progress information as a JSON stream, and has a `quiet` query parameter to suppress progress details.
+
+## v1.22 API changes
+
+[Docker Engine API v1.22](v1.22.md) documentation
+
+* `POST /container/(name)/update` updates the resources of a container.
+* `GET /containers/json` supports filter `isolation` on Windows.
+* `GET /containers/json` now returns the list of networks of containers.
+* `GET /info` Now returns `Architecture` and `OSType` fields, providing information
+  about the host architecture and operating system type that the daemon runs on.
+* `GET /networks/(name)` now returns a `Name` field for each container attached to the network.
+* `GET /version` now returns the `BuildTime` field in RFC3339Nano format to make it
+  consistent with other date/time values returned by the API.
+* `AuthConfig` now supports a `registrytoken` for token based authentication
+* `POST /containers/create` now has a 4M minimum value limit for `HostConfig.KernelMemory`
+* Pushes initiated with `POST /images/(name)/push` and pulls initiated with `POST /images/create`
+  will be cancelled if the HTTP connection making the API request is closed before
+  the push or pull completes.
+* `POST /containers/create` now allows you to set a read/write rate limit for a
+  device (in bytes per second or IO per second).
+* `GET /networks` now supports filtering by `name`, `id` and `type`.
+* `POST /containers/create` now allows you to set the static IPv4 and/or IPv6 address for the container.
+* `POST /networks/(id)/connect` now allows you to set the static IPv4 and/or IPv6 address for the container.
+* `GET /info` now includes the number of containers running, stopped, and paused.
+* `POST /networks/create` now supports restricting external access to the network by setting the `Internal` field.
+* `POST /networks/(id)/disconnect` now includes a `Force` option to forcefully disconnect a container from network
+* `GET /containers/(id)/json` now returns the `NetworkID` of containers.
+* `POST /networks/create` Now supports an options field in the IPAM config that provides options
+  for custom IPAM plugins.
+* `GET /networks/{network-id}` Now returns IPAM config options for custom IPAM plugins if any
+  are available.
+* `GET /networks/<network-id>` now returns subnets info for user-defined networks.
+* `GET /info` can now return a `SystemStatus` field useful for returning additional information about applications
+  that are built on top of engine.
+
+## v1.21 API changes
+
+[Docker Engine API v1.21](v1.21.md) documentation
+
+* `GET /volumes` lists volumes from all volume drivers.
+* `POST /volumes/create` to create a volume.
+* `GET /volumes/(name)` get low-level information about a volume.
+* `DELETE /volumes/(name)` remove a volume with the specified name.
+* `VolumeDriver` was moved from `config` to `HostConfig` to make the configuration portable.
+* `GET /images/(name)/json` now returns information about an image's `RepoTags` and `RepoDigests`.
+* The `config` option now accepts the field `StopSignal`, which specifies the signal to use to kill a container.
+* `GET /containers/(id)/stats` will return networking information respectively for each interface.
+* The `HostConfig` option now includes the `DnsOptions` field to configure the container's DNS options.
+* `POST /build` now optionally takes a serialized map of build-time variables.
+* `GET /events` now includes a `timenano` field, in addition to the existing `time` field.
+* `GET /events` now supports filtering by image and container labels.
+* `GET /info` now lists engine version information and return the information of `CPUShares` and `Cpuset`.
+* `GET /containers/json` will return `ImageID` of the image used by container.
+* `POST /exec/(name)/start` will now return an HTTP 409 when the container is either stopped or paused.
+* `POST /containers/create` now takes `KernelMemory` in HostConfig to specify kernel memory limit.
+* `GET /containers/(name)/json` now accepts a `size` parameter. Setting this parameter to '1' returns container size information in the `SizeRw` and `SizeRootFs` fields.
+* `GET /containers/(name)/json` now returns a `NetworkSettings.Networks` field,
+  detailing network settings per network. This field deprecates the
+  `NetworkSettings.Gateway`, `NetworkSettings.IPAddress`,
+  `NetworkSettings.IPPrefixLen`, and `NetworkSettings.MacAddress` fields, which
+  are still returned for backward-compatibility, but will be removed in a future version.
+* `GET /exec/(id)/json` now returns a `NetworkSettings.Networks` field,
+  detailing networksettings per network. This field deprecates the
+  `NetworkSettings.Gateway`, `NetworkSettings.IPAddress`,
+  `NetworkSettings.IPPrefixLen`, and `NetworkSettings.MacAddress` fields, which
+  are still returned for backward-compatibility, but will be removed in a future version.
+* The `HostConfig` option now includes the `OomScoreAdj` field for adjusting the
+  badness heuristic. This heuristic selects which processes the OOM killer kills
+  under out-of-memory conditions.
+
+## v1.20 API changes
+
+[Docker Engine API v1.20](v1.20.md) documentation
+
+* `GET /containers/(id)/archive` get an archive of filesystem content from a container.
+* `PUT /containers/(id)/archive` upload an archive of content to be extracted to
+an existing directory inside a container's filesystem.
+* `POST /containers/(id)/copy` is deprecated in favor of the above `archive`
+endpoint which can be used to download files and directories from a container.
+* The `hostConfig` option now accepts the field `GroupAdd`, which specifies a
+list of additional groups that the container process will run as.
+
+## v1.19 API changes
+
+[Docker Engine API v1.19](v1.19.md) documentation
+
+* When the daemon detects a version mismatch with the client, usually when
+the client is newer than the daemon, an HTTP 400 is now returned instead
+of a 404.
+* `GET /containers/(id)/stats` now accepts `stream` bool to get only one set of stats and disconnect.
+* `GET /containers/(id)/logs` now accepts a `since` timestamp parameter.
+* `GET /info` The fields `Debug`, `IPv4Forwarding`, `MemoryLimit`, and
+`SwapLimit` are now returned as boolean instead of as an int. In addition, the
+end point now returns the new boolean fields `CpuCfsPeriod`, `CpuCfsQuota`, and
+`OomKillDisable`.
+* The `hostConfig` option now accepts the fields `CpuPeriod` and `CpuQuota`
+* `POST /build` accepts `cpuperiod` and `cpuquota` options
+
+## v1.18 API changes
+
+[Docker Engine API v1.18](v1.18.md) documentation
+
+* `GET /version` now returns `Os`, `Arch` and `KernelVersion`.
+* `POST /containers/create` and `POST /containers/(id)/start`allow you to  set ulimit settings for use in the container.
+* `GET /info` now returns `SystemTime`, `HttpProxy`,`HttpsProxy` and `NoProxy`.
+* `GET /images/json` added a `RepoDigests` field to include image digest information.
+* `POST /build` can now set resource constraints for all containers created for the build.
+* `CgroupParent` can be passed in the host config to setup container cgroups under a specific cgroup.
+* `POST /build` closing the HTTP request cancels the build
+* `POST /containers/(id)/exec` includes `Warnings` field to response.

vendor/github.com/docker/docker-ce/components/engine/docs/contributing/README.md

@@ -0,0 +1,8 @@
+### Get set up for Moby development
+
+ * [README first](who-written-for.md)
+ * [Get the required software](software-required.md)
+ * [Set up for development on Windows](software-req-win.md)
+ * [Configure Git for contributing](set-up-git.md)
+ * [Work with a development container](set-up-dev-env.md)
+ * [Run tests and test documentation](test.md)

vendor/github.com/docker/docker-ce/components/engine/docs/contributing/set-up-dev-env.md

@@ -0,0 +1,372 @@
+### Work with a development container
+
+In this section, you learn to develop like the Moby Engine core team.
+The `moby/moby` repository includes a `Dockerfile` at its root. This file defines
+Moby's development environment. The `Dockerfile` lists the environment's
+dependencies: system libraries and binaries, Go environment, Go dependencies,
+etc.
+
+Moby's development environment is itself, ultimately a Docker container.
+You use the `moby/moby` repository and its `Dockerfile` to create a Docker image,
+run a Docker container, and develop code in the container.
+
+If you followed the procedures that [set up Git for contributing](./set-up-git.md), you should have a fork of the `moby/moby`
+repository. You also created a branch called `dry-run-test`. In this section,
+you continue working with your fork on this branch.
+
+##  Task 1. Remove images and containers
+
+Moby developers run the latest stable release of the Docker software. They clean their local hosts of
+unnecessary Docker artifacts such as stopped containers or unused images.
+Cleaning unnecessary artifacts isn't strictly necessary, but it is good
+practice, so it is included here.
+
+To remove unnecessary artifacts:
+
+1. Verify that you have no unnecessary containers running on your host.
+
+   ```none
+   $ docker ps -a
+   ```
+
+   You should see something similar to the following:
+
+   ```none
+   CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
+   ```
+
+   There are no running or stopped containers on this host. A fast way to
+   remove old containers is the following:
+
+   You can now use the `docker system prune` command to achieve this:
+
+   ```none
+   $ docker system prune -a
+   ```
+
+   Older versions of the Docker Engine should reference the command below:
+
+   ```none
+   $ docker rm $(docker ps -a -q)
+   ```
+
+   This command uses `docker ps` to list all containers (`-a` flag) by numeric
+   IDs (`-q` flag). Then, the `docker rm` command removes the resulting list.
+   If you have running but unused containers, stop and then remove them with
+   the `docker stop` and `docker rm` commands.
+
+2. Verify that your host has no dangling images.
+
+   ```none
+   $ docker images
+   ```
+
+   You should see something similar to the following:
+
+   ```none
+   REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
+   ```
+
+   This host has no images. You may have one or more _dangling_ images. A
+   dangling image is not used by a running container and is not an ancestor of
+   another image on your system. A fast way to remove dangling image is
+   the following:
+
+   ```none
+   $ docker rmi -f $(docker images -q -a -f dangling=true)
+   ```
+
+   This command uses `docker images` to list all images (`-a` flag) by numeric
+   IDs (`-q` flag) and filter them to find dangling images (`-f dangling=true`).
+   Then, the `docker rmi` command forcibly (`-f` flag) removes
+   the resulting list. If you get a "docker: "rmi" requires a minimum of 1 argument."
+   message, that means there were no dangling images. To remove just one image, use the
+   `docker rmi ID` command.
+
+## Task 2. Start a development container
+
+If you followed the last procedure, your host is clean of unnecessary images and
+containers. In this section, you build an image from the Engine development
+environment and run it in the container. Both steps are automated for you by the
+Makefile in the Engine code repository. The first time you build an image, it
+can take over 15 minutes to complete.
+
+1. Open a terminal.
+
+   For [Docker Toolbox](../../toolbox/overview.md) 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. If you use Docker for Mac or Docker for Windows, you do not need
+   to use Docker Machine.
+
+2. Change into the root of the `moby-fork` repository.
+
+   ```none
+   $ cd ~/repos/moby-fork
+   ```
+
+   If you are following along with this guide, you created a `dry-run-test`
+   branch when you [set up Git for contributing](./set-up-git.md).
+
+3. Ensure you are on your `dry-run-test` branch.
+
+   ```none
+   $ git checkout dry-run-test
+   ```
+
+   If you get a message that the branch doesn't exist, add the `-b` flag (`git checkout -b dry-run-test`) so the
+   command both creates the branch and checks it out.
+
+4. Use `make` to build a development environment image and run it in a container.
+
+   ```none
+   $ make BIND_DIR=. shell
+   ```
+
+   Using the instructions in the
+   `Dockerfile`, the build may need to download and / or configure source and other images. On first build this process may take between 5 - 15 minutes to create an image. The command returns informational messages as it runs.  A
+   successful build returns a final message and opens a Bash shell into the
+   container.
+
+   ```none
+   Successfully built 3d872560918e
+   Successfully tagged docker-dev:dry-run-test
+   docker run --rm -i --privileged -e BUILDFLAGS -e KEEPBUNDLE -e DOCKER_BUILD_GOGC -e DOCKER_BUILD_PKGS -e DOCKER_CLIENTONLY -e DOCKER_DEBUG -e DOCKER_EXPERIMENTAL -e DOCKER_GITCOMMIT -e DOCKER_GRAPHDRIVER=devicemapper -e DOCKER_INCREMENTAL_BINARY -e DOCKER_REMAP_ROOT -e DOCKER_STORAGE_OPTS -e DOCKER_USERLANDPROXY -e TESTDIRS -e TESTFLAGS -e TIMEOUT -v "home/ubuntu/repos/docker/bundles:/go/src/github.com/docker/docker/bundles" -t "docker-dev:dry-run-test" bash
+   #
+   ```
+
+   At this point, your prompt reflects the container's BASH shell.
+
+5. List the contents of the current directory (`/go/src/github.com/docker/docker`).
+
+   You should see the image's source from the  `/go/src/github.com/docker/docker`
+   directory.
+
+   ![List example](images/list_example.png)
+
+6. Make a `dockerd` binary.
+
+   ```none
+   # hack/make.sh binary
+   Removing bundles/
+
+   ---> Making bundle: binary (in bundles/binary)
+   Building: bundles/binary-daemon/dockerd-17.06.0-dev
+   Created binary: bundles/binary-daemon/dockerd-17.06.0-dev
+   Copying nested executables into bundles/binary-daemon
+
+   ```
+
+7. Run `make install`, which copies the binary to the container's
+   `/usr/local/bin/` directory.
+
+   ```none
+   # make install
+   ```
+
+8. Start the Engine daemon running in the background.
+
+   ```none
+   # dockerd -D &
+   ...output snipped...
+   DEBU[0001] Registering POST, /networks/{id:.*}/connect
+   DEBU[0001] Registering POST, /networks/{id:.*}/disconnect
+   DEBU[0001] Registering DELETE, /networks/{id:.*}
+   INFO[0001] API listen on /var/run/docker.sock
+   DEBU[0003] containerd connection state change: READY
+   ```
+
+   The `-D` flag starts the daemon in debug mode. The `&` starts it as a
+   background process. You'll find these options useful when debugging code
+   development. You will need to hit `return` in order to get back to your shell prompt.
+
+   > **Note**: The following command automates the `build`,
+   > `install`, and `run` steps above. Once the command below completes, hit `ctrl-z` to suspend the process, then run `bg 1` and hit `enter` to resume the daemon process in the background and get back to your shell prompt.
+
+   ```none
+   hack/make.sh binary install-binary run
+   ```
+
+9. Inside your container, check your Docker versions:
+
+   ```none
+   # docker version
+   Client:
+    Version:      17.06.0-ce
+    API version:  1.30
+    Go version:   go1.8.3
+    Git commit:   02c1d87
+    Built:        Fri Jun 23 21:15:15 2017
+    OS/Arch:      linux/amd64
+
+   Server:
+    Version:      dev
+    API version:  1.35 (minimum version 1.12)
+    Go version:   go1.9.2
+    Git commit:   4aa6362da
+    Built:        Sat Dec  2 05:22:42 2017
+    OS/Arch:      linux/amd64
+    Experimental: false
+   ```
+
+   Notice the split versions between client and server, which might be
+   unexpected. In more recent times the Docker CLI component (which provides the
+   `docker` command) has split out from the Moby project and is now maintained in:
+   
+   * [docker/cli](https://github.com/docker/cli) - The Docker CLI source-code;
+   * [docker/docker-ce](https://github.com/docker/docker-ce) - The Docker CE
+     edition project, which assembles engine, CLI and other components.
+   
+   The Moby project now defaults to a [fixed
+   version](https://github.com/docker/docker-ce/commits/v17.06.0-ce) of the
+   `docker` CLI for integration tests.
+
+   You may have noticed the following message when starting the container with the `shell` command:
+   
+   ```none
+   Makefile:123: The docker client CLI has moved to github.com/docker/cli. For a dev-test cycle involving the CLI, run:
+   DOCKER_CLI_PATH=/host/path/to/cli/binary make shell
+   then change the cli and compile into a binary at the same location.
+   ```
+
+   By setting `DOCKER_CLI_PATH` you can supply a newer `docker` CLI to the
+   server development container for testing and for `integration-cli`
+   test-execution:
+
+   ```none
+   make DOCKER_CLI_PATH=/home/ubuntu/git/docker-ce/components/packaging/static/build/linux/docker/docker BIND_DIR=. shell
+   ...
+   # which docker
+   /usr/local/cli/docker
+   # docker --version
+   Docker version 17.09.0-dev, build 
+   ```
+
+    This Docker CLI should be built from the [docker-ce
+    project](https://github.com/docker/docker-ce) and needs to be a Linux
+    binary.
+
+   Inside the container you are running a development version. This is the version
+   on the current branch. It reflects the value of the `VERSION` file at the
+   root of your `docker-fork` repository.
+
+10. Run the `hello-world` image.
+
+    ```none
+    # docker run hello-world
+    ```
+
+11. List the image you just downloaded.
+
+    ```none
+    # docker images
+	REPOSITORY   TAG     IMAGE ID      CREATED        SIZE
+	hello-world  latest  c54a2cc56cbb  3 months ago   1.85 kB
+    ```
+
+12. Open another terminal on your local host.
+
+13. List the container running your development container.
+
+    ```none
+    ubuntu@ubuntu1404:~$ docker ps
+    CONTAINER ID        IMAGE                     COMMAND             CREATED             STATUS              PORTS               NAMES
+    a8b2885ab900        docker-dev:dry-run-test   "hack/dind bash"    43 minutes ago      Up 43 minutes                           hungry_payne
+    ```
+
+    Notice that the tag on the container is marked with the `dry-run-test` branch name.
+
+
+## Task 3. Make a code change
+
+At this point, you have experienced the "Moby inception" technique. That is,
+you have:
+
+* forked and cloned the Moby Engine code repository
+* created a feature branch for development
+* created and started an Engine development container from your branch
+* built a binary inside of your development container
+* launched a `docker` daemon using your newly compiled binary
+* called the `docker` client to run a `hello-world` container inside
+  your development container
+
+Running the `make BIND_DIR=. shell` command mounted your local Docker repository source into
+your Docker container.
+
+   > **Note**: Inspecting the `Dockerfile` shows a `COPY . /go/src/github.com/docker/docker` instruction, suggesting that dynamic code changes will _not_ be reflected in the container. However inspecting the `Makefile` shows that the current working directory _will_ be mounted via a `-v` volume mount.
+
+When you start to develop code though, you'll
+want to iterate code changes and builds inside the container. If you have
+followed this guide exactly, you have a bash shell running a development
+container.
+
+Try a simple code change and see it reflected in your container. For this
+example, you'll edit the help for the `attach` subcommand.
+
+1. If you don't have one, open a terminal in your local host.
+
+2. Make sure you are in your `moby-fork` repository.
+
+   ```none
+   $ pwd
+   /Users/mary/go/src/github.com/moxiegirl/moby-fork
+   ```
+
+   Your location should be different because, at least, your username is
+   different.
+
+3. Open the `cmd/dockerd/docker.go` file.
+
+4. Edit the command's help message.
+
+   For example, you can edit this line:
+
+   ```go
+   Short:         "A self-sufficient runtime for containers.",
+   ```
+
+   And change it to this:
+
+   ```go
+   Short:         "A self-sufficient and really fun runtime for containers.",
+   ```
+
+5. Save and close the `cmd/dockerd/docker.go` file.
+
+6. Go to your running docker development container shell.
+
+7. Rebuild the binary by using the command `hack/make.sh binary` in the docker development container shell.
+
+8. Stop Docker if it is running.
+
+9. Copy the binaries to **/usr/bin** by entering the following commands in the docker development container shell.
+
+   ```
+   hack/make.sh binary install-binary
+   ```
+
+10. To view your change, run the `dockerd --help` command in the docker development container shell.
+
+   ```bash
+   # dockerd --help
+
+   Usage:        dockerd COMMAND
+
+   A self-sufficient and really fun runtime for containers.
+
+   Options:
+   ...
+
+   ```
+
+You've just done the basic workflow for changing the Engine code base. You made
+your code changes in your feature branch. Then, you updated the binary in your
+development container and tried your change out. If you were making a bigger
+change, you might repeat or iterate through this flow several times.
+
+## Where to go next
+
+Congratulations, you have successfully achieved Docker inception. You've had a
+small experience of the development process. You've set up your development
+environment and verified almost all the essential processes you need to
+contribute. Of course, before you start contributing, [you'll need to learn one
+more piece of the development process, the test framework](test.md).

vendor/github.com/docker/docker-ce/components/engine/docs/contributing/set-up-git.md

@@ -0,0 +1,280 @@
+### Configure Git for contributing
+
+Work through this page to configure Git and a repository you'll use throughout
+the Contributor Guide. The work you do further in the guide, depends on the work
+you do here.
+
+## Task 1. Fork and clone the Moby code
+
+Before contributing, you first fork the Moby code repository. A fork copies
+a repository at a particular point in time. GitHub tracks for you where a fork
+originates.
+
+As you make contributions, you change your fork's code. When you are ready,
+you make a pull request back to the original Docker repository. If you aren't
+familiar with this workflow, don't worry, this guide walks you through all the
+steps.
+
+To fork and clone Moby:
+
+1. Open a browser and log into GitHub with your account.
+
+2. Go to the <a href="https://github.com/moby/moby"
+target="_blank">moby/moby repository</a>.
+
+3. Click the "Fork" button in the upper right corner of the GitHub interface.
+
+    ![Branch Signature](images/fork_docker.png)
+
+    GitHub forks the repository to your GitHub account. The original
+    `moby/moby` repository becomes a new fork `YOUR_ACCOUNT/moby` under
+    your account.
+
+4. Copy your fork's clone URL from GitHub.
+
+    GitHub allows you to use HTTPS or SSH protocols for clones. You can use the
+    `git` command line or clients like Subversion to clone a repository.
+
+    ![Copy clone URL](images/copy_url.png)
+
+    This guide assume you are using the HTTPS protocol and the `git` command
+    line. If you are comfortable with SSH and some other tool, feel free to use
+    that instead. You'll need to convert what you see in the guide to what is
+    appropriate to your tool.
+
+5. Open a terminal window on your local host and change to your home directory.
+
+   ```bash
+   $ cd ~
+   ```
+
+    In Windows, you'll work in your Docker Quickstart Terminal window instead of
+    Powershell or a `cmd` window.
+
+6. Create a `repos` directory.
+
+   ```bash
+   $ mkdir repos
+   ```
+
+7. Change into your `repos` directory.
+
+   ```bash
+   $ cd repos
+   ```
+
+8. Clone the fork to your local host into a repository called `moby-fork`.
+
+   ```bash
+   $ git clone https://github.com/moxiegirl/moby.git moby-fork
+   ```
+
+    Naming your local repo `moby-fork` should help make these instructions
+    easier to follow; experienced coders don't typically change the name.
+
+9. Change directory into your new `moby-fork` directory.
+
+   ```bash
+   $ cd moby-fork
+   ```
+
+    Take a moment to familiarize yourself with the repository's contents. List
+    the contents.
+
+## Task 2. Set your signature and an upstream remote
+
+When you contribute to Docker, you must certify you agree with the
+<a href="http://developercertificate.org/" target="_blank">Developer Certificate of Origin</a>.
+You indicate your agreement by signing your `git` commits like this:
+
+```
+Signed-off-by: Pat Smith <pat.smith@email.com>
+```
+
+To create a signature, you configure your username and email address in Git.
+You can set these globally or locally on just your `moby-fork` repository.
+You must sign with your real name. You can sign your git commit automatically
+with `git commit -s`. Moby does not accept anonymous contributions or contributions
+through pseudonyms.
+
+As you change code in your fork, you'll want to keep it in sync with the changes
+others make in the `moby/moby` repository. To make syncing easier, you'll
+also add a _remote_ called `upstream` that points to `moby/moby`. A remote
+is just another project version hosted on the internet or network.
+
+To configure your username, email, and add a remote:
+
+1. Change to the root of your `moby-fork` repository.
+
+   ```bash
+   $ cd moby-fork
+   ```
+
+2. Set your `user.name` for the repository.
+
+   ```bash
+   $ git config --local user.name "FirstName LastName"
+   ```
+
+3. Set your `user.email` for the repository.
+
+   ```bash
+   $ git config --local user.email "emailname@mycompany.com"
+   ```
+
+4. Set your local repo to track changes upstream, on the `moby/moby` repository.
+
+   ```bash
+   $ git remote add upstream https://github.com/moby/moby.git
+   ```
+
+5. Check the result in your `git` configuration.
+
+   ```bash
+   $ git config --local -l
+   core.repositoryformatversion=0
+   core.filemode=true
+   core.bare=false
+   core.logallrefupdates=true
+   remote.origin.url=https://github.com/moxiegirl/moby.git
+   remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
+   branch.master.remote=origin
+   branch.master.merge=refs/heads/master
+   user.name=Mary Anthony
+   user.email=mary@docker.com
+   remote.upstream.url=https://github.com/moby/moby.git
+   remote.upstream.fetch=+refs/heads/*:refs/remotes/upstream/*
+   ```
+
+	To list just the remotes use:
+
+   ```bash
+   $ git remote -v
+   origin	https://github.com/moxiegirl/moby.git (fetch)
+   origin	https://github.com/moxiegirl/moby.git (push)
+   upstream https://github.com/moby/moby.git (fetch)
+   upstream https://github.com/moby/moby.git (push)
+   ```
+
+## Task 3. Create and push a branch
+
+As you change code in your fork, make your changes on a repository branch.
+The branch name should reflect what you are working on. In this section, you
+create a branch, make a change, and push it up to your fork.
+
+This branch is just for testing your config for this guide. The changes are part
+of a dry run, so the branch name will be dry-run-test. To create and push
+the branch to your fork on GitHub:
+
+1. Open a terminal and go to the root of your `moby-fork`.
+
+   ```bash
+   $ cd moby-fork
+   ```
+
+2. Create a `dry-run-test` branch.
+
+   ```bash
+   $ git checkout -b dry-run-test
+   ```
+
+    This command creates the branch and switches the repository to it.
+
+3. Verify you are in your new branch.
+
+   ```bash
+   $ git branch
+   * dry-run-test
+     master
+   ```
+
+    The current branch has an * (asterisk) marker. So, these results show you
+    are on the right branch.
+
+4. Create a `TEST.md` file in the repository's root.
+
+   ```bash
+   $ touch TEST.md
+   ```
+
+5. Edit the file and add your email and location.
+
+    ![Add your information](images/contributor-edit.png)
+
+    You can use any text editor you are comfortable with.
+
+6. Save and close the file.
+
+7. Check the status of your branch.
+
+   ```bash
+   $ git status
+   On branch dry-run-test
+   Untracked files:
+     (use "git add <file>..." to include in what will be committed)
+
+       TEST.md
+
+   nothing added to commit but untracked files present (use "git add" to track)
+   ```
+
+	You've only changed the one file. It is untracked so far by git.
+
+8. Add your file.
+
+   ```bash
+   $ git add TEST.md
+   ```
+
+    That is the only _staged_ file. Stage is fancy word for work that Git is
+    tracking.
+
+9. Sign and commit your change.
+
+   ```bash
+   $ git commit -s -m "Making a dry run test."
+   [dry-run-test 6e728fb] Making a dry run test
+    1 file changed, 1 insertion(+)
+    create mode 100644 TEST.md
+   ```
+
+    Commit messages should have a short summary sentence of no more than 50
+    characters. Optionally, you can also include a more detailed explanation
+    after the summary. Separate the summary from any explanation with an empty
+    line.
+
+10. Push your changes to GitHub.
+
+    ```bash
+    $ git push --set-upstream origin dry-run-test
+    Username for 'https://github.com': moxiegirl
+    Password for 'https://moxiegirl@github.com':
+    ```
+
+    Git prompts you for your GitHub username and password. Then, the command
+    returns a result.
+
+    ```bash
+    Counting objects: 13, done.
+    Compressing objects: 100% (2/2), done.
+    Writing objects: 100% (3/3), 320 bytes | 0 bytes/s, done.
+    Total 3 (delta 1), reused 0 (delta 0)
+    To https://github.com/moxiegirl/moby.git
+     * [new branch]      dry-run-test -> dry-run-test
+    Branch dry-run-test set up to track remote branch dry-run-test from origin.
+    ```
+
+11. Open your browser to GitHub.
+
+12. Navigate to your Moby fork.
+
+13. Make sure the `dry-run-test` branch exists, that it has your commit, and the
+commit is signed.
+
+    ![Branch Signature](images/branch-sig.png)
+
+## Where to go next
+
+Congratulations, you have finished configuring both your local host environment
+and Git for contributing. In the next section you'll [learn how to set up and
+work in a Moby development container](set-up-dev-env.md).

vendor/github.com/docker/docker-ce/components/engine/docs/contributing/software-req-win.md

@@ -0,0 +1,177 @@
+### Build and test Moby on Windows
+
+This page explains how to get the software you need to build, test, and run the
+Moby source code for Windows and setup the required software and services:
+
+- Windows containers
+- GitHub account
+- Git
+
+## Prerequisites
+
+### 1. Windows Server 2016 or Windows 10 with all Windows updates applied
+
+The major build number must be at least 14393. This can be confirmed, for example,
+by running the following from an elevated PowerShell prompt - this sample output
+is from a fully up to date machine as at mid-November 2016:
+
+
+    PS C:\> $(gin).WindowsBuildLabEx
+    14393.447.amd64fre.rs1_release_inmarket.161102-0100
+
+### 2. Git for Windows (or another git client) must be installed
+
+https://git-scm.com/download/win.
+
+### 3. The machine must be configured to run containers
+
+For example, by following the quick start guidance at
+https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start or https://github.com/docker/labs/blob/master/windows/windows-containers/Setup.md
+
+### 4. If building in a Hyper-V VM
+
+For Windows Server 2016 using Windows Server containers as the default option,
+it is recommended you have at least 1GB of memory assigned;
+For Windows 10 where Hyper-V Containers are employed, you should have at least
+4GB of memory assigned.
+Note also, to run Hyper-V containers in a VM, it is necessary to configure the VM
+for nested virtualization.
+
+## Usage
+
+The following steps should be run from an elevated Windows PowerShell prompt.
+
+>**Note**:  In a default installation of containers on Windows following the quick-start guidance at https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/quick_start,
+the `docker.exe` client must run elevated to be able to connect to the daemon).
+
+### 1. Windows containers
+
+To test and run the Windows Moby engine, you need a system that supports Windows Containers:
+
+- Windows 10 Anniversary Edition
+- Windows Server 2016 running in a VM, on bare metal or in the cloud
+
+Check out the [getting started documentation](https://github.com/docker/labs/blob/master/windows/windows-containers/Setup.md) for details.
+
+### 2. GitHub account
+
+To contribute to the Docker project, you need a <a href="https://github.com" target="_blank">GitHub account</a>.
+A free account is fine. All the Moby project repositories are public and visible to everyone.
+
+This guide assumes that you have basic familiarity with Git and Github terminology
+and usage.
+Refer to [GitHub For Beginners: Don’t Get Scared, Get Started](http://readwrite.com/2013/09/30/understanding-github-a-journey-for-beginners-part-1/)
+to get up to speed on Github.
+
+### 3. Git
+
+In PowerShell, run:
+
+    Invoke-Webrequest "https://github.com/git-for-windows/git/releases/download/v2.7.2.windows.1/Git-2.7.2-64-bit.exe" -OutFile git.exe -UseBasicParsing
+    Start-Process git.exe -ArgumentList '/VERYSILENT /SUPPRESSMSGBOXES /CLOSEAPPLICATIONS /DIR=c:\git\' -Wait
+    setx /M PATH "$env:Path;c:\git\cmd"
+
+You are now ready clone and build the Moby source code.
+
+### 4. Clone Moby
+
+In a new (to pick up the path change) PowerShell prompt, run:
+
+    git clone https://github.com/moby/moby
+    cd moby
+
+This clones the main Moby repository. Check out [Moby Project](https://mobyproject.org)
+to learn about the other software that powers the Moby platform.
+
+### 5. Build and run
+
+Create a builder-container with the Moby source code. You can change the source
+code on your system and rebuild any time:
+
+    docker build -t nativebuildimage -f .\Dockerfile.windows .
+    docker build -t nativebuildimage -f Dockerfile.windows -m 2GB .  # (if using Hyper-V containers)
+
+To build Moby, run:
+
+    $DOCKER_GITCOMMIT=(git rev-parse --short HEAD)
+    docker run --name binaries -e DOCKER_GITCOMMIT=$DOCKER_GITCOMMIT nativebuildimage hack\make.ps1 -Binary
+    docker run --name binaries -e DOCKER_GITCOMMIT=$DOCKER_GITCOMMIT -m 2GB nativebuildimage hack\make.ps1 -Binary  # (if using Hyper-V containers)
+
+Copy out the resulting Windows Moby Engine binary to `dockerd.exe` in the
+current directory:
+
+    docker cp binaries:C:\go\src\github.com\moby\moby\bundles\docker.exe docker.exe
+    docker cp binaries:C:\go\src\github.com\moby\moby\bundles\dockerd.exe dockerd.exe
+
+To test it, stop the system Docker daemon and start the one you just built:
+
+    Stop-Service Docker
+    .\dockerd.exe -D
+
+The other make targets work too, to run unit tests try:
+`docker run --rm docker-builder sh -c 'cd /c/go/src/github.com/docker/docker; hack/make.sh test-unit'`.
+
+### 6. Remove the interim binaries container
+
+_(Optional)_
+
+    docker rm binaries
+
+### 7. Remove the image
+
+_(Optional)_
+
+It may be useful to keep this image around if you need to build multiple times.
+Then you can take advantage of the builder cache to have an image which has all
+the components required to build the binaries already installed.
+
+    docker rmi nativebuildimage
+
+## Validation
+
+The validation tests can only run directly on the host.
+This is because they calculate information from the git repo, but the .git directory
+is not passed into the image as it is excluded via `.dockerignore`.
+Run the following from a Windows PowerShell prompt (elevation is not required):
+(Note Go must be installed to run these tests)
+
+    hack\make.ps1 -DCO -PkgImports -GoFormat
+
+## Unit tests
+
+To run unit tests, ensure you have created the nativebuildimage above.
+Then run one of the following from an (elevated) Windows PowerShell prompt:
+
+    docker run --rm nativebuildimage hack\make.ps1 -TestUnit
+    docker run --rm -m 2GB nativebuildimage hack\make.ps1 -TestUnit  # (if using Hyper-V containers)
+
+To run unit tests and binary build, ensure you have created the nativebuildimage above.
+Then run one of the following from an (elevated) Windows PowerShell prompt:
+
+    docker run nativebuildimage hack\make.ps1 -All
+    docker run -m 2GB nativebuildimage hack\make.ps1 -All  # (if using Hyper-V containers)
+
+## Windows limitations
+
+Don't attempt to use a bind mount to pass a local directory as the bundles
+target directory.
+It does not work (golang attempts for follow a mapped folder incorrectly).
+Instead, use docker cp as per the example.
+
+`go.zip` is not removed from the image as it is used by the Windows CI servers
+to ensure the host and image are running consistent versions of go.
+
+Nanoserver support is a work in progress. Although the image will build if the
+`FROM` statement is updated, it will not work when running autogen through `hack\make.ps1`.
+It is suspected that the required GCC utilities (eg gcc, windres, windmc) silently
+quit due to the use of console hooks which are not available.
+
+The docker integration tests do not currently run in a container on Windows,
+predominantly due to Windows not supporting privileged mode, so anything using a volume would fail.
+They (along with the rest of the docker CI suite) can be run using
+https://github.com/jhowardmsft/docker-w2wCIScripts/blob/master/runCI/Invoke-DockerCI.ps1.
+
+## Where to go next
+
+In the next section, you'll [learn how to set up and configure Git for
+contributing to Moby](set-up-git.md).

vendor/github.com/docker/docker-ce/components/engine/docs/contributing/software-required.md

@@ -0,0 +1,94 @@
+### Get the required software for Linux or macOS
+
+This page explains how to get the software you need to use a Linux or macOS
+machine for Moby development. Before you begin contributing you must have:
+
+*  a GitHub account
+* `git`
+* `make`
+* `docker`
+
+You'll notice that `go`, the language that Moby is written in, is not listed.
+That's because you don't need it installed; Moby's development environment
+provides it for you. You'll learn more about the development environment later.
+
+## Task 1. Get a GitHub account
+
+To contribute to the Moby project, you will need a <a
+href="https://github.com" target="_blank">GitHub account</a>. A free account is
+fine. All the Moby project repositories are public and visible to everyone.
+
+You should also have some experience using both the GitHub application and `git`
+on the command line.
+
+## Task 2. Install git
+
+Install `git` on your local system. You can check if `git` is on already on your
+system and properly installed with the following command:
+
+```bash
+$ git --version
+```
+
+This documentation is written using `git` version 2.2.2. Your version may be
+different depending on your OS.
+
+## Task 3. Install make
+
+Install `make`. You can check if `make` is on your system with the following
+command:
+
+```bash
+$ make -v
+```
+
+This documentation is written using GNU Make 3.81. Your version may be different
+depending on your OS.
+
+## Task 4. Install or upgrade Docker
+
+If you haven't already, install the Docker software using the
+<a href="https://docs.docker.com/engine/installation/" target="_blank">instructions for your operating system</a>.
+If you have an existing installation, check your version and make sure you have
+the latest Docker.
+
+To check if `docker` is already installed on Linux:
+
+```bash
+docker --version
+Docker version 17.10.0-ce, build f4ffd25
+```
+
+On macOS or Windows, you should have installed Docker for Mac or
+Docker for Windows.
+
+```bash
+$ docker --version
+Docker version 17.10.0-ce, build f4ffd25
+```
+
+## Tip for Linux users
+
+This guide assumes you have added your user to the `docker` group on your system.
+To check, list the group's contents:
+
+```
+$ getent group docker
+docker:x:999:ubuntu
+```
+
+If the command returns no matches, you have two choices. You can preface this
+guide's `docker` commands with `sudo` as you work. Alternatively, you can add
+your user to the `docker` group as follows:
+
+```bash
+$ sudo usermod -aG docker ubuntu
+```
+
+You must log out and log back in for this modification to take effect.
+
+
+## Where to go next
+
+In the next section, you'll [learn how to set up and configure Git for
+contributing to Moby](set-up-git.md).

vendor/github.com/docker/docker-ce/components/engine/docs/contributing/test.md

@@ -0,0 +1,244 @@
+### Run tests
+
+Contributing includes testing your changes. If you change the Moby code, you
+may need to add a new test or modify an existing test. Your contribution could
+even be adding tests to Moby. For this reason, you need to know a little
+about Moby's test infrastructure.
+
+This section describes tests you can run in the `dry-run-test` branch of your Docker
+fork. If you have followed along in this guide, you already have this branch.
+If you don't have this branch, you can create it or simply use another of your
+branches.
+
+## Understand how to test Moby
+
+Moby tests use the Go language's test framework. In this framework, files
+whose names end in `_test.go` contain test code; you'll find test files like
+this throughout the Moby repo. Use these files for inspiration when writing
+your own tests. For information on Go's test framework, see <a
+href="http://golang.org/pkg/testing/" target="_blank">Go's testing package
+documentation</a> and the <a href="http://golang.org/cmd/go/#hdr-Test_packages"
+target="_blank">go test help</a>.
+
+You are responsible for _unit testing_ your contribution when you add new or
+change existing Moby code. A unit test is a piece of code that invokes a
+single, small piece of code (_unit of work_) to verify the unit works as
+expected.
+
+Depending on your contribution, you may need to add _integration tests_. These
+are tests that combine two or more work units into one component. These work
+units each have unit tests and then, together, integration tests that test the
+interface between the components. The `integration` and `integration-cli`
+directories in the Docker repository contain integration test code.  Note that
+`integration-cli` tests are now deprecated in the Moby project, and new tests
+cannot be added to this suite - add `integration` tests instead using the API
+client.
+
+Testing is its own specialty. If you aren't familiar with testing techniques,
+there is a lot of information available to you on the Web. For now, you should
+understand that, the Docker maintainers may ask you to write a new test or
+change an existing one.
+
+## Run tests on your local host
+
+Before submitting a pull request with a code change, you should run the entire
+Moby Engine test suite. The `Makefile` contains a target for the entire test
+suite, named `test`. Also, it contains several targets for
+testing:
+
+| Target                 | What this target does                          |
+| ---------------------- | ---------------------------------------------- |
+| `test`                 | Run the unit, integration, and docker-py tests |
+| `test-unit`            | Run just the unit tests                        |
+| `test-integration`     | Run the integration tests                      |
+| `test-docker-py`       | Run the tests for the Docker API client        |
+
+Running the entire test suite on your current repository can take over half an
+hour. To run the test suite, do the following:
+
+1.  Open a terminal on your local host.
+
+2.  Change to the root of your Docker repository.
+
+    ```bash
+    $ cd moby-fork
+    ```
+
+3.  Make sure you are in your development branch.
+
+    ```bash
+    $ git checkout dry-run-test
+    ```
+
+4.  Run the `make test` command.
+
+    ```bash
+    $ make test
+    ```
+
+    This command does several things, it creates a container temporarily for
+    testing. Inside that container, the `make`:
+
+    * creates a new binary
+    * cross-compiles all the binaries for the various operating systems
+    * runs all the tests in the system
+
+    It can take approximate one hour to run all the tests. The time depends
+    on your host performance. The default timeout is 60 minutes, which is
+    defined in `hack/make.sh` (`${TIMEOUT:=60m}`). You can modify the timeout
+    value on the basis of your host performance. When they complete
+    successfully, you see the output concludes with something like this:
+
+    ```none
+    Ran 68 tests in 79.135s
+    ```
+
+## Run targets inside a development container
+
+If you are working inside a development container, you use the
+`hack/test/unit` script to run unit-tests, and `hack/make.sh` script to run
+integration and other tests. The `hack/make.sh` script doesn't
+have a single target that runs all the tests. Instead, you provide a single
+command line with multiple targets that does the same thing.
+
+Try this now.
+
+1.  Open a terminal and change to the `moby-fork` root.
+
+2.  Start a Moby development image.
+
+    If you are following along with this guide, you should have a
+    `dry-run-test` image.
+
+    ```bash
+    $ docker run --privileged --rm -ti -v `pwd`:/go/src/github.com/docker/docker dry-run-test /bin/bash
+    ```
+
+3.  Run the unit tests using the `hack/test/unit` script.
+
+    ```bash
+    # hack/test/unit
+    ```
+
+4.  Run the tests using the `hack/make.sh` script.
+
+    ```bash
+    # hack/make.sh dynbinary binary cross test-integration test-docker-py
+    ```
+
+    The tests run just as they did within your local host.
+
+    Of course, you can also run a subset of these targets too. For example, to run
+    just the integration tests:
+
+    ```bash
+    # hack/make.sh dynbinary binary cross test-integration
+    ```
+
+    Most test targets require that you build these precursor targets first:
+    `dynbinary binary cross`
+
+
+## Run unit tests
+
+We use golang standard [testing](https://golang.org/pkg/testing/)
+package or [gocheck](https://labix.org/gocheck) for our unit tests.
+
+You can use the `TESTDIRS` environment variable to run unit tests for
+a single package.
+
+```bash
+$ TESTDIRS='opts' make test-unit
+```
+
+You can also use the `TESTFLAGS` environment variable to run a single test. The
+flag's value is passed as arguments to the `go test` command. For example, from
+your local host you can run the `TestBuild` test with this command:
+
+```bash
+$ TESTFLAGS='-test.run ^TestValidateIPAddress$' make test-unit
+```
+
+On unit tests, it's better to use `TESTFLAGS` in combination with
+`TESTDIRS` to make it quicker to run a specific test.
+
+```bash
+$ TESTDIRS='opts' TESTFLAGS='-test.run ^TestValidateIPAddress$' make test-unit
+```
+
+## Run integration tests
+
+We use [gocheck](https://labix.org/gocheck) for our integration-cli tests.
+You can use the `TESTFLAGS` environment variable to run a single test. The
+flag's value is passed as arguments to the `go test` command. For example, from
+your local host you can run the `TestBuild` test with this command:
+
+```bash
+$ TESTFLAGS='-check.f DockerSuite.TestBuild*' make test-integration
+```
+
+To run the same test inside your Docker development container, you do this:
+
+```bash
+# TESTFLAGS='-check.f TestBuild*' hack/make.sh binary test-integration
+```
+
+## Test the Windows binary against a Linux daemon
+
+This explains how to test the Windows binary on a Windows machine set up as a
+development environment. The tests will be run against a daemon
+running on a remote Linux machine. You'll use **Git Bash** that came with the
+Git for Windows installation. **Git Bash**, just as it sounds, allows you to
+run a Bash terminal on Windows.
+
+1.  If you don't have one open already, start a Git Bash terminal.
+
+    ![Git Bash](images/git_bash.png)
+
+2.  Change to the `moby` source directory.
+
+    ```bash
+    $ cd /c/gopath/src/github.com/docker/docker
+    ```
+
+3.  Set `DOCKER_REMOTE_DAEMON` as follows:
+
+    ```bash
+    $ export DOCKER_REMOTE_DAEMON=1
+    ```
+
+4.  Set `DOCKER_TEST_HOST` to the `tcp://IP_ADDRESS:2376` value; substitute your
+    Linux machines actual IP address. For example:
+
+    ```bash
+    $ export DOCKER_TEST_HOST=tcp://213.124.23.200:2376
+    ```
+
+5.  Make the binary and run the tests:
+
+    ```bash
+    $ hack/make.sh binary test-integration
+    ```
+    Some tests are skipped on Windows for various reasons. You can see which
+    tests were skipped by re-running the make and passing in the
+   `TESTFLAGS='-test.v'` value. For example
+
+    ```bash
+    $ TESTFLAGS='-test.v' hack/make.sh binary test-integration
+    ```
+
+    Should you wish to run a single test such as one with the name
+    'TestExample', you can pass in `TESTFLAGS='-check.f TestExample'`. For
+    example
+
+    ```bash
+    $ TESTFLAGS='-check.f TestExample' hack/make.sh binary test-integration
+    ```
+
+You can now choose to make changes to the Moby source or the tests. If you
+make any changes, just run these commands again.
+
+## Where to go next
+
+Congratulations, you have successfully completed the basics you need to
+understand the Moby test framework.

vendor/github.com/docker/docker-ce/components/engine/docs/contributing/who-written-for.md

@@ -0,0 +1,49 @@
+### README first
+
+This section of the documentation contains a guide for Moby project users who want to
+contribute code or documentation to the Moby Engine project. As a community, we
+share rules of behavior and interaction. Make sure you are familiar with the <a
+href="https://github.com/moby/moby/blob/master/CONTRIBUTING.md#docker-community-guidelines"
+target="_blank">community guidelines</a> before continuing.
+
+## Where and what you can contribute
+
+The Moby project consists of not just one but several repositories on GitHub.
+So, in addition to the `moby/moby` repository, there is the
+`containerd/containerd` repo, the `moby/buildkit` repo, and several more.
+Contribute to any of these and you contribute to the Moby project.
+
+Not all Moby repositories use the Go language. Also, each repository has its
+own focus area. So, if you are an experienced contributor, think about
+contributing to a Moby project repository that has a language or a focus area you are
+familiar with.
+
+If you are new to the open source community, to Moby, or to formal
+programming, you should start out contributing to the `moby/moby`
+repository. Why? Because this guide is written for that repository specifically.
+
+Finally, code or documentation isn't the only way to contribute. You can report
+an issue, add to discussions in our community channel, write a blog post, or
+take a usability test. You can even propose your own type of contribution.
+Right now we don't have a lot written about this yet, but feel free to open an issue
+to discuss other contributions.
+
+## How to use this guide
+
+This is written for the distracted, the overworked, the sloppy reader with fair
+`git` skills and a failing memory for the GitHub GUI. The guide attempts to
+explain how to use the Moby Engine development environment as precisely,
+predictably, and procedurally as possible.
+
+Users who are new to Engine development should start by setting up their
+environment. Then, they should try a simple code change. After that, you should
+find something to work on or propose a totally new change.
+
+If you are a programming prodigy, you still may find this documentation useful.
+Please feel free to skim past information you find obvious or boring.
+
+## How to get started
+
+Start by getting the software you require. If you are on Mac or Linux, go to
+[get the required software for Linux or macOS](software-required.md). If you are
+on Windows, see [get the required software for Windows](software-req-win.md).