No substantial code change.
- Api --> API
- Cli --> CLI
- Http, Https --> HTTP, HTTPS
- Id --> ID
- Uid,Gid,Pid --> UID,PID,PID
- Ipam --> IPAM
- Tls --> TLS (TestDaemonNoTlsCliTlsVerifyWithEnv --> TestDaemonTLSVerifyIssue13964)
Didn't touch in this commit:
- Git: because it is officially "Git": https://git-scm.com/
- Tar: because it is officially "Tar": https://www.gnu.org/software/tar/
- Cpu, Nat, Mac, Ipc, Shm: for keeping a consistency with existing production code (not changable, for compatibility)
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
Upstream-commit: 7fb7a477d79c67ab53c432977780662ccbfeec57
Component: engine
`Mounts` allows users to specify in a much safer way the volumes they
want to use in the container.
This replaces `Binds` and `Volumes`, which both still exist, but
`Mounts` and `Binds`/`Volumes` are exclussive.
The CLI will continue to use `Binds` and `Volumes` due to concerns with
parsing the volume specs on the client side and cross-platform support
(for now).
The new API follows exactly the services mount API.
Example usage of `Mounts`:
```
$ curl -XPOST localhost:2375/containers/create -d '{
"Image": "alpine:latest",
"HostConfig": {
"Mounts": [{
"Type": "Volume",
"Target": "/foo"
},{
"Type": "bind",
"Source": "/var/run/docker.sock",
"Target": "/var/run/docker.sock",
},{
"Type": "volume",
"Name": "important_data",
"Target": "/var/data",
"ReadOnly": true,
"VolumeOptions": {
"DriverConfig": {
Name: "awesomeStorage",
Options: {"size": "10m"},
Labels: {"some":"label"}
}
}]
}
}'
```
There are currently 2 types of mounts:
- **bind**: Paths on the host that get mounted into the
container. Paths must exist prior to creating the container.
- **volume**: Volumes that persist after the
container is removed.
Not all fields are available in each type, and validation is done to
ensure these fields aren't mixed up between types.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: fc7b904dced4d18d49c8a6c47ae3f415d16d0c43
Component: engine
This moves the types for the `engine-api` repo to the existing types
package.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 91e197d614547f0202e6ae9b8a24d88ee131d950
Component: engine
This fix tries to address the issue in 25000 where `docker stats`
will not show network stats with `NetworkDisabled=true`.
The `NetworkDisabled=true` could be either invoked through
remote API, or through `docker daemon -b none`.
The issue was that when `NetworkDisabled=true` either by API or
by daemon config, there is no SandboxKey for container so an error
will be returned.
This fix fixes this issue by skipping obtaining SandboxKey if
`NetworkDisabled=true`.
Additional test has bee added to cover the changes.
This fix fixes 25000.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 7bb9c5397e69866fcb1142cda430b842a710f751
Component: engine
If AutoRemove is set, wait until client get `destroy` events, or get
`detach` events that implies container is detached but not stopped.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 6dd8e10d6ed7a7371c5c1824ad58c4403a7b3bfd
Component: engine
This endpoint has been deprecated since 1.8. Return an error starting
from this API version (1.24) in order to make sure it's not used for the
next API version and so that we can remove it some times later.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 428328908dc529b1678fb3d8b033fb0591a294e3
Component: engine
This fix tries to fix the http panics caused by container deletion
with empty names in #22210.
The issue was because when an empty string was passed, `GetByName()`
tried to access the first element of the name string without checking
the length. A length check has been added.
A test case for #22210 has been added.
This fix fixes#22210.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 9d8071a74db20556d0fc1b6ef3270326b3583de9
Component: engine
Other places referring to the same configuration, including docs, have
the correct spelling.
Signed-off-by: Rodolfo Carvalho <rhcarvalho@gmail.com>
Upstream-commit: fee7e7c7a31023be9f0c26608e6cbd4e8a97d25b
Component: engine
Moving all strings to the errors package wasn't a good idea after all.
Our custom implementation of Go errors predates everything that's nice
and good about working with errors in Go. Take as an example what we
have to do to get an error message:
```go
func GetErrorMessage(err error) string {
switch err.(type) {
case errcode.Error:
e, _ := err.(errcode.Error)
return e.Message
case errcode.ErrorCode:
ec, _ := err.(errcode.ErrorCode)
return ec.Message()
default:
return err.Error()
}
}
```
This goes against every good practice for Go development. The language already provides a simple, intuitive and standard way to get error messages, that is calling the `Error()` method from an error. Reinventing the error interface is a mistake.
Our custom implementation also makes very hard to reason about errors, another nice thing about Go. I found several (>10) error declarations that we don't use anywhere. This is a clear sign about how little we know about the errors we return. I also found several error usages where the number of arguments was different than the parameters declared in the error, another clear example of how difficult is to reason about errors.
Moreover, our custom implementation didn't really make easier for people to return custom HTTP status code depending on the errors. Again, it's hard to reason about when to set custom codes and how. Take an example what we have to do to extract the message and status code from an error before returning a response from the API:
```go
switch err.(type) {
case errcode.ErrorCode:
daError, _ := err.(errcode.ErrorCode)
statusCode = daError.Descriptor().HTTPStatusCode
errMsg = daError.Message()
case errcode.Error:
// For reference, if you're looking for a particular error
// then you can do something like :
// import ( derr "github.com/docker/docker/errors" )
// if daError.ErrorCode() == derr.ErrorCodeNoSuchContainer { ... }
daError, _ := err.(errcode.Error)
statusCode = daError.ErrorCode().Descriptor().HTTPStatusCode
errMsg = daError.Message
default:
// This part of will be removed once we've
// converted everything over to use the errcode package
// FIXME: this is brittle and should not be necessary.
// If we need to differentiate between different possible error types,
// we should create appropriate error types with clearly defined meaning
errStr := strings.ToLower(err.Error())
for keyword, status := range map[string]int{
"not found": http.StatusNotFound,
"no such": http.StatusNotFound,
"bad parameter": http.StatusBadRequest,
"conflict": http.StatusConflict,
"impossible": http.StatusNotAcceptable,
"wrong login/password": http.StatusUnauthorized,
"hasn't been activated": http.StatusForbidden,
} {
if strings.Contains(errStr, keyword) {
statusCode = status
break
}
}
}
```
You can notice two things in that code:
1. We have to explain how errors work, because our implementation goes against how easy to use Go errors are.
2. At no moment we arrived to remove that `switch` statement that was the original reason to use our custom implementation.
This change removes all our status errors from the errors package and puts them back in their specific contexts.
IT puts the messages back with their contexts. That way, we know right away when errors used and how to generate their messages.
It uses custom interfaces to reason about errors. Errors that need to response with a custom status code MUST implementent this simple interface:
```go
type errorWithStatus interface {
HTTPErrorStatusCode() int
}
```
This interface is very straightforward to implement. It also preserves Go errors real behavior, getting the message is as simple as using the `Error()` method.
I included helper functions to generate errors that use custom status code in `errors/errors.go`.
By doing this, we remove the hard dependency we have eeverywhere to our custom errors package. Yes, you can use it as a helper to generate error, but it's still very easy to generate errors without it.
Please, read this fantastic blog post about errors in Go: http://dave.cheney.net/2014/12/24/inspecting-errors
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: a793564b2591035aec5412fbcbcccf220c773a4c
Component: engine
This will allow us to have a windows-to-linux CI, where the linux host
can be anywhere, connecting with TLS.
Signed-off-by: Tibor Vass <tibor@docker.com>
Upstream-commit: f4a1e3db998816e5fcb0df56c29519c488890464
Component: engine
Most of them were found and fixed by codespell.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Upstream-commit: 2eee613326fb59fd168849618d14a9054a40f9f5
Component: engine
1. Replace raw `docker inspect -f xxx` with `inspectField`, to make code
cleaner and more consistent
2. assert the error in function `inspectField*` so we don't need to
assert the return value of it every time, this will make inspect easier.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 62a856e9129c9d5cf7db9ea6322c9073d68e3ea4
Component: engine
Add `runSleepingContainer` and `runSleepingContainerInImage` helper
functions to factor out the way to run system-specific idle containers.
Define a sleeping container as command `top` in image `busybox` for
Unix and as command `sleep 60` in image `busybox` for Windows. Provide a
single point of code to update those.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
Upstream-commit: 777ee34b075292e5aee16c4088444508899f8f35
Component: engine
Adds the `--userns-remap` flag to the master build
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 557c7cb888ad8e2f1f378c9cf34e5fba14551904
Component: engine
Don't rely on sqlite db for name registration and linking.
Instead register names and links when the daemon starts to an in-memory
store.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 0f9f99500c40f2a46682967ca358cd2346fd5e13
Component: engine
dockerfile.Config is almost redundant with ImageBuildOptions.
Unify the two so that the latter can be removed. This also
helps build's API endpoint code to be less dependent on package
dockerfile.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: 5190794f1d85d5406611eb69c270df62ac1cdc7f
Component: engine
- Make the API client library completely standalone.
- Move windows partition isolation detection to the client, so the
driver doesn't use external types.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 7ac4232e70fe7cf7318333cd0890db7f95663079
Component: engine
After addition of multi-host networking in Docker 1.9, Docker Remote
API is still returning only the network specified during creation
of the container in the “List Containers” (`/containers/json`) endpoint:
...
"HostConfig": {
"NetworkMode": "default"
},
The list of networks containers are attached to is only available at
Get Container (`/containers/<id>/json`) endpoint.
This does not allow applications utilizing multi-host networking to
be built on top of Docker Remote API.
Therefore I added a simple `"NetworkSettings"` section to the
`/containers/json` endpoint. This is not identical to the NetworkSettings
returned in Get Container (`/containers/<id>/json`) endpoint. It only
contains a single field `"Networks"`, which is essentially the same
value shown in inspect output of a container.
This change adds the following section to the `/containers/json`:
"NetworkSettings": {
"Networks": {
"bridge": {
"EndpointID": "2cdc4edb1ded3631c81f57966563e...",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"MacAddress": "02:42:ac:11:00:02"
}
}
}
This is of type `SummaryNetworkSettings` type, a minimal version of
`api/types#NetworkSettings`.
Actually all I need is the network name and the IPAddress fields. If folks
find this addition too big, I can create a `SummaryEndpointSettings` field
as well, containing just the IPAddress field.
Signed-off-by: Ahmet Alp Balkan <ahmetalpbalkan@gmail.com>
Upstream-commit: 755f8609f699a20cb47ec7269e3a9469541a9419
Component: engine
