Hello, I am trying to get a stream of events but can't find the way to do it.

I tried this:

package main

import (
    "fmt"
    "time"

    "github.com/docker/engine-api/client"
    "github.com/docker/engine-api/types"
    "golang.org/x/net/context"
)

func main() {
    defaultHeaders := map[string]string{"User-Agent": "engine-api-cli-1.0"}
    cli, err := client.NewClient("unix:///var/run/docker.sock", "v1.22", nil, defaultHeaders)
    if err != nil {
        panic(err)
    }

    eventOptions := types.EventsOptions{Since: "0", Until: fmt.Sprintf("%d", time.Now().Second()+1000000000)}
    reader, err := cli.Events(context.Background(), eventOptions)
    if err != nil {
        panic(err)
    }

    for {
        var buffer []byte
        _, err := reader.Read(buffer)
        if err != nil {
            panic(err)
        }
        fmt.Println(string(buffer))
        time.Sleep(time.Second)
    }
}

But the stream is empty when I run containers so I assume it doesn't work.
What am I doing wrong?

Thanks a lot!

with the usual TLS settings docker ps works fine:

DOCKER_HOST=tcp://192.168.59.103:2376 \
DOCKER_CERT_PATH=~/.boot2docker/certs/boot2docker-vm \
DOCKER_TLS_VERIFY=1 \
  docker ps

but using the same ENV vars with the NewEnvClient() throws x509: certificate signed by unknown authority

DOCKER_HOST=tcp://192.168.59.103:2376 \
DOCKER_CERT_PATH=~/.boot2docker/certs/boot2docker-vm \
DOCKER_TLS_VERIFY=1 \
  go run main.go

panic: An error occurred trying to connect: Get https://192.168.59.103:2376/containers/json?all=1&limit=0: x509: certificate signed by unknown authority

Im using OSX with boot2docker 1.9.1

workaround

Unsetting DOCKER_TLS_VERIFY makes the sample go program fine, but than docker ps fails with:

Get http://192.168.59.103:2376/v1.21/containers/json: malformed HTTP response "\x15\x03\x01\x00\x02\x02".
* Are you trying to connect to a TLS-enabled daemon without TLS?

sample code

Contents of main.go:

package main

import (
        "fmt"
        "github.com/docker/engine-api/client"
        "github.com/docker/engine-api/types"
)

func main() {
        cli, err := client.NewEnvClient()
        if err != nil {
                panic(err)
        }

        options := types.ContainerListOptions{All: true}
        containers, err := cli.ContainerList(options)
        if err != nil {
                panic(err)
        }

        for _, c := range containers {
                fmt.Println(c.ID)
        }
}

These API functions take an integer number of seconds for a timeout. It would be much more idiomatic Go to use time.Duaration to specify the timeout.

Hey, I was trying to mock the docker client behavior by overwriting the httpclient. Unfortunately the httpclient is private https://github.com/docker/engine-api/blob/master/client/client.go#L29
Anyway to workaround this?
Thanks!

If I write the content to a file its adding some header and footer to the file.
What is the issue?

Sample code

reader, _, err = CopyFromContainer(context.TODO(), containerId, path)
f, err = os.Create("tempFile")
n, err = io.Copy(f, reader)

The following code:

package main

import (
    "fmt"

    "github.com/docker/engine-api/client"
    "github.com/docker/engine-api/types"
)

func main() {
    cli, err := client.NewEnvClient()
    if err != nil {
        panic(err)
    }

    options := types.ContainerListOptions{All: true}
    containers, err := cli.ContainerList(options)
    if err != nil {
        panic(err)
    }

    for _, c := range containers {
        fmt.Println(c.ID)
    }
}

produces the following error:

panic: An error occurred trying to connect: Get https://192.168.99.100:2376/containers/json?all=1&limit=0: x509: certificate signed by unknown authority

goroutine 1 [running]:
main.main()
    /Users/me/src/go/src/github.com/maliceio/malice/test-docker/doctest.go:19 +0x120

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/Cellar/go/1.5.3/libexec/src/runtime/asm_amd64.s:1721 +0x1
exit status 2

I am running the following on updated docker and updated docker-machine

docker version                                                                                                                      ⏎ ✱ ◼
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.3
 Git commit:   a34a1d5
 Built:        Sun Jan 17 16:14:45 UTC 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

Hi,

I see that in the type for Config there is a field for ExposedPorts, however, I'm trying to replicate the functionality of docker run -dP [image name].

I have tried just creating an empty map (not that I expected this to work):

emptyMap := make(map[nat.Port]struct{})
configOptions := container.Config{Image: c.RegistryURL + "/" + containerType, ExposedPorts: emptyMap}
hostConfig := container.HostConfig{}
networkConfig := network.NetworkingConfig{}
createResponse, err := cli.ContainerCreate(context.Background(), &configOptions, &hostConfig, &networkConfig, containerName)

However, the end result of this is just a container with no exposed ports. Am I missing the correct way to expose all ports like the -P flag does?

I think it would make sense to provide constants or an enumerate type for valid Restart Policies. Before I submit a PR, I'd like to know what's the more idiomatic way to do that. Can somebody help?

We should really find a way to auto-document the engine api based on this repository. It should be the cannonical place to read the API schema and it's changes over time.

I don't know if we can reuse the swagger document published in this other repo:

https://github.com/stage1/docker-php/blob/1.x/docker-swagger.json

Hi Docker developers :)

I just heard about this project, and having a officially supported Go binding to interact with Docker API is great.

However, like other Go bindings such as go-dockerclient that provide it, it would be very nice to be able to get a map[string]types.AuthConfig from ~/.docker/config.json/.dockercfg.
In docker/docker, this feature is provided by the cliconfig.

Would it be possible to migrate at least the reading part of cliconfig to engine-api ?

I'd be glad to provide a PR if you like.

This error hides the context cancellation by wrapping it a string. There are several errors that try to add "helpful" messages to errors, but they just result in missing import context to an error.

We may want to consider addressing this with pkg/errors, but that may be overkill.

Currently, the /info endpoint for the Swarm API uses DriverStatus field in the Engine API. We would like to create a new field exclusively for Swarm to use.

The current suggestion is to name the field CustomStatus.

Related issues: moby/moby#19277, docker-archive/classicswarm#1625, samalba/dockerclient#215

cc @calavera @vieux

I was just wondering it was possible to have some consistence since some attributes have "omitempty" and others doesn't. For example: https://github.com/docker/engine-api/blob/master/types/types.go#L296
Are there any cons in using the "omitempty" tag?

It came up a lot in the Docker Remote API rework discussions: moby/moby#15188 moby/moby#5893 I also think swagger is a great way to describe APIs.

If there's a way maybe we can declare types/* in swagger specs and generate source files using swagger code generators, that would be very preferable as other language SDKs can take advantage of the swagger specs as well.

Just leaving this here.

Reference: https://github.com/docker/engine-api/blob/master/types/filters/parse.go
Currently, the Args struct looks like this

type Args struct {
    fields map[string]map[string]bool
}

but not too long ago, it looked like this

type Args map[string][]string

So basically I can’t use the newer client to work with older daemons, because I will get a json unmarshaling error. This is a problem for Swarm since we're moving to the engine-api and can't support older daemons on the cluster as a result.

Current Swarm PR blocked due to this issue: docker-archive/classicswarm#1983

This issue is in the same category as #144.

So what seems to be happening is I have an app and when I try and run:

defaultHeaders := map[string]string{"User-Agent": "engine-api-cli-1.0"}
client, err = docker.NewClient("unix:///var/run/docker.sock", "v1.22", nil, defaultHeaders)
if err != nil {
    log.Fatal(err)
}

ctx, cancel := context.WithTimeout(context.Background(), 120*time.Second)
defer cancel()

// Check if client can connect
_, err = client.Info(ctx)
if err != nil {
    handleClientError(err)
}

I get the error: An error occurred trying to connect: context deadline exceeded IF I am running it from a go installed bin.

So if I do a go run main.go from the go get source directory GOPATH/src/github.com/me/mythang it works just fine, but when I then do a go install and then cd ~ and run the install go bin I get the above error. Very strange indeed?

Any help much preesh.

There is a bottleneck for updating anything api facing in docker daemon after engine-api was separated out. Previously some aspects of it were discussed in moby/moby#19957 . The gist of it is that for some changes in daemon, code needs to be changed in this repo although they can really only be tested with a daemon. Also, because of docker/docker vendors engine-api there is a delay on getting changes merged and possibility on different changes getting mixed up or bugfixes getting blocked by features.

My proposal is to remove engine-api dependancy from docker/docker/daemon pkg(also container, builder etc.). The docker/docker/client pkg would keep it's imports. Once the client binary is moved out of docker/docker repo, the main repo would not depend on API any more.

This change would mean the types that engine requires would be defined in docker/docker repo. For easier client side usage engine-api could redefine all the types with aliases or even keep exceptions if they should be needed for some backwards compatibility features. The engine-api would vendor one specific version of the types from docker/docker, not the other way like it is now. To keep the library size small we would keep the convention in docker/docker that we always define exported types in separate packages.

The product on docker-engine is the HTTP API, not engine-api. So docker-engine should define the types that HTTP API is using.

Honestly, it's rocket science to pull an image. Ignore the black magic required to do trusted pulls, just parsing a string to ImageID and Tag is not even straight forward. Let alone who knows what RegistryAuth is supposed to be. It would be greatly appreciated to move as much logic from https://github.com/docker/docker/blob/master/api/client/pull.go to this project in the form of some util methods or something.

I see that as a particular problem when it comes to signed/trusted images. While Docker may have all this great signing stuff, if clients outside of the docker CLI can't figure out how to use it, then that's a problem. Honestly I don't even know what I'm talking about here because I don't even fully understand what is required to do trusted pulls. I just look at https://github.com/docker/docker/blob/master/api/client/trust.go and get overwhelmed.

Docker Swarm is planning to switch to using the engine-api, and move away from samalba/dockerclient.

One of the important provisions in dockerclient is the mockclient functionality (https://github.com/samalba/dockerclient/tree/master/mockclient), which Swarm needs for unit tests.

engine-api also provides this, but with an important difference - a single mock client takes in a function that defines mock behavior for a single API endpoint. It would be nice to have a single mock client support mock behavior for multiple API endpoints, much like https://github.com/samalba/dockerclient/tree/master/mockclient. Is this something that would be acceptable if built into engine-api?

Docker Swarm is planning to switch to using the engine-api, and move away from samalba/dockerclient.

One of the important provisions in dockerclient is the nopclient functionality (https://github.com/samalba/dockerclient/tree/master/nopclient), which Swarm needs for efficiency reasons.

engine-api currently does not provide this, but it is simple to build. Is this something that would be acceptable if built into engine-api?

we're piggybacking on docker for testing. We should add our own tests.

We can investigate if we can use the mock in Sam Alba's client to make them work:

https://github.com/samalba/dockerclient/tree/master/mockclient

Hi,

I'm reading a folder from terminated container, the folder is returned as tar from CopyFromContainer which is great.
The problem is with the metadata. The pathStat returned in the same call has wrong value for the size of the tar file - 4096.

Could it be solvable?

Thanks,
Shay

Hi, All,

Today, I found that docker network inspect NETWORK shows engine details when this command is against Swarm.

See docker-archive/classicswarm#2349 and docker-archive/classicswarm#2275

In the response of NetworkInspectWithRaw from Swarm, there is additional Engine field in it. And dockercli implemented by github.com/spf13/cobra takes []byte to format the output.
If the initial purpose of NetworkInspectWithRaw, is it []byte should be exactly correspond to types.NetworkResource.

func (cli *Client) NetworkInspectWithRaw(ctx context.Context, networkID string) (types.NetworkResource, []byte, error)

If the answer is yes, I think we should fix this. Maybe I can do the change.

The api call in README.md is incorrect since the call requires the first argument to be context.

containers, err := cli.ContainerList(options)

should be:

containers, err := cli.ContainerList(context.Background(), options)

Please see this code: https://github.com/docker/engine-api/blob/master/client/image_pull.go#L30. The status code is not checked after running privilegeFunc. This could return a completely invalid body and result in undetectable error.

I'm not sure about a fix since it is not entirely clear what this code is supposed to be doing. Why wouldn't privilegeFunc be called on the first time through?

Having an empty implementation of APIClient (and possibly some of the other engine-api interfaces as well) is very useful for testing. @vdemeester wrote an implementation that we use in libcompose. This might be something to consider adding to engine-api.

It would be good to avoid this dependency on stdcopy (as it is a dependency to docker/docker).

cc @tamird & cockroachdb/cockroach#4712

panic: runtime error: index out of range

github.com/docker/engine-api/client.NewClient(0x0, 0x0, 0x42e060, 0x5, 0xc8200ca750, 0xc82000b260, 0x0, 0x0, 0x0)
    /Users/rob/workspace/go/src/github.com/docker/engine-api/client/client.go:70 +0x586

At least a decent error message should be given but I think that using the docker default (unix:///var/run/docker.sock)when the host is empty is even a better option.

Currently, there's no real way (other than tagging or parsing server output manually) to get what the final image ID of a successful build is. This is quite annoying, and it should be possible to have a field in types.ImageBuildResponse -- we'd just need to append to the end of the build output a JSON object describing the final ImageID. Or we'll have to implement build IDs.

When attaching to a container, I can attach to a container when I'm not using the TTY, however I use the TTY it doesn't return any data.

Here's the relevant code. If you uncomment the Tty line, at least for me, it exhibits the behaviour. If its commented out, everything works fine.

cfg := &container.Config{
    AttachStdin:  false,
    AttachStdout: true,
    AttachStderr: true,
    Image:        <image name>,
    Labels:       map[string]string{},
    //Tty:          true,
}
hostCfg := &container.HostConfig{}
netCfg := &network.NetworkingConfig{
    EndpointsConfig: map[string]*network.EndpointSettings{},
}

resp, err := client.ContainerCreate(cfg, hostCfg, netCfg, <image name>)
if err != nil {
    log.Fatalf("Couldn't create container '%s': %s", <image name>, err)
}
cId := resp.ID
aResp, err := client.ContainerAttach(types.ContainerAttachOptions{
    ContainerID: cId,
    Stream:      true,
    Stdin:       false,
    Stdout:      true,
    Stderr:      true,
})
if err != nil {
    log.Fatalf("Couldn't attach to container: %s", err)
}

if err = client.ContainerStart(cId); err != nil {
    log.Error("There was a problem running the container")
    return 1, err
}

go func() {
    defer aResp.Close()
    stdcopy.StdCopy(os.Stdout, os.Stderr, aResp.Reader)
}()

rc, err := client.ContainerWait(cId)
if err != nil {
    log.Errorf("Error waiting for container to finished: %s", err)
    return rc, err
}

I want to retrieve all docker images of a remote machine, I was successful in returning the docker images of my local machine with the code provided in the Readme.md file,
but the question is how can i retrieve docker images of a remote machine given its address,username, and password?

For example there are no specific error type for

• network already existing with the same name (if CheckDuplicate flag is enabled) during create
• network having active endpoints when trying to delete

When using engine-api built with Go(<=1.4) with Docker daemon built with Go(>=1.6), it keeps complaining "Error response from daemon: 400 Bad Request: malformed Host header".

I think the reason is that:

1. After golang/go@6e11f45, the http server in Go 1.6 will validate the HTTP Host header conforming to HTTP 1.1 (See golang/go#13624)
2. On the http client side, Go writes the HTTP Host header with request.Host or request.URL.Host(if the former is empty) (See here)
3. When using the default docker endpoint (unix:///var/run/docker.sock), engine-api will set request.Host="", request.URL.Host="/var/run/docker.sock" (See set request.URL.Host and set request.Host)
4. When the engine-api is built with Go >= 1.5, everything goes well, because Go will clean up the Host making both request.Host and request.URL.Host to "". Then the HTTP Host header will be "". (See golang/go#11206))
5. But when the engine-api is built with Go<=1.4, Go won't clean up the Host, so the HTTP Host header will be "/var/run/docker.sock". It will break Go 1.6 http server side validation in 1. because '/'is not a valid character, causing 400 Bad Request: malformed Host header.

I could fix this by set some random but valid thing like "docker.sock" in the request.URL.Host. If it is not used for unix endpoint, why don't we just set it to a valid Host?

Hope this could be fixed, thanks! :)

More information kubernetes/kubernetes#23809

It makes no sense to have the primary arguments for API operations inside of an options structure. It makes the API unwieldy and challenging to use. Let's take the example of Client.ImagePull:

func (cli *Client) ImagePull(ctx context.Context, options types.ImagePullOptions, privilegeFunc RequestPrivilegeFunc) (io.ReadCloser, error)

We then dive into types.ImagePullOptions. Ok, it takes an ImageID. Does that mean name? Who knows. It also requires the user to parse the tag portion out of the name.

Furthermore, the only real option, privilegeFunc is for some reason not an option.

The method signature should be this:

func (cli *Client) ImagePull(ctx context.Context, ref string, options types.ImagePullOptions) (io.ReadCloser, error)

Note a few things about this design. The ref can contain whatever is supported by the target engine. We don't require a user of this API to parse out a tag, which is non-trivial. Futhermore, one can simply pass an empty options structure and 95% of use cases would be covered.

With the options type, as follows:

type ImagePullOptions struct {
    RegistryAuth string // RegistryAuth is the base64 encoded credentials for the registry
    PrivilegesFunc RequestPrivilegesFunc
}

As it is, this is confusing and challenging to use correctly.

I'm not sure if I have time to do a PR for this, as it seems to be a systematic inconsistency.

Because ContainerCreateConfig takes a Container.Config (types/configs.go#L13), we should have an older version that allows the extra fields available in v1p19's (types/versions/v1p19/types.go#L23) and v1p20's ContainerConfig (types/v1p20/types.go#L20)

Currently, the engine-api client does not export or allow a way to get the underlying http client and scheme.

Would it be possible to add a function to do this?

I see the following behavior:

• ContainersList returns all .Mounts empty
• ContainerInspect fills in all .Mounts properly

Is this expected (or what I am doing wrong) ? And if it is expected, why types.Container even has Mounts []MountPointif it's left empty by ContainerList ?

How to reproduce:
I am running a small test below, which enumerates containers with ContainersList and checks the content of .Mounts, and then does per-container ContainerInspect and checks the content of .Mounts again.

Docker 1.10.3 , Ubuntu 14.04 Kernel 3.13. Engine-API is used via vendoring, taken on March 2

Test run output:

• Output refcount using List 0 shows there was 0 local mounts (which is wrong, and I did check and .Mounts all have len 0 in the ContainerList resutl)
• Output refcount using Inspect 103 shows all data volume mounts were accurately counted

The test assumes some containers with local volumes; and your counts will obviously vary

try$ ./mounts_check
2016/04/01 16:40:11 Connected to unix:///var/run/docker.sock
2016/04/01 16:40:14 103 containers found
2016/04/01 16:40:14 total refcount: using List 0 using Inspect 103

Test

//
// A simple check for Container.Mounts content in engine-api
//

package main

import (
    "github.com/docker/engine-api/client"
    "github.com/docker/engine-api/types"
    "log"
)

const (
    apiVersion = "v1.22"
    driverName = "local"
    endPoint   = "unix:///var/run/docker.sock"
)

func main() {
    defaultHeaders := map[string]string{"User-Agent": "engine-api-client-1.0"}

    c, err := client.NewClient(endPoint, apiVersion, nil, defaultHeaders)
    if err != nil {
        log.Printf("Failed to connect to %s, err: %v\n", endPoint, err)
        return
    }

    log.Printf("Connected to %s\n", endPoint)
    containers, err := c.ContainerList(types.ContainerListOptions{
        All: true, Size: true,
    })
    if err != nil {
        log.Printf("Faild to get containers list (err: %v)\n", err)
        return
    }
    log.Printf("%d containers found\n", len(containers))

    refcnt1 := 0
    refcnt2 := 0
    for _, ct := range containers {
        for _, mount := range ct.Mounts {
            if mount.Driver == driverName {
                refcnt1++
            }
        }

        ct_json, err := c.ContainerInspect(ct.ID)
        if err != nil {
            log.Printf("Inspect failed on %s : %v\n", ct.Names, err)
            continue
        } 

        for _, mount := range ct_json.Mounts {
            if mount.Driver == driverName {
                refcnt2++

            }
        }
    }
    log.Printf("total refcount: using List %d using Inspect %d\n", refcnt1, refcnt2)
}

Files in client/transport/cancellable refer to missing "BSD-style" LICENSE file.

When using APIClient.ContainerCreate, I found that no context argument is present: https://github.com/docker/engine-api/blob/master/client/container_create.go#L21. This ends up using (*Client).post, which uses the background context.

This basically makes the integration of context useless.

Engine-api v0.2.2 and v0.2.3 FTBFS when built with latest release of go-units v0.2.0:

src/github.com/docker/engine-api/types/container/host_config.go:185: undefined: units.Ulimit 

As swarm uses engine-api to manage docker engines , there must be some api compatibility between swarm and docker engine.

Now latest version of Swarm is 1.2.3, it uses engine-api. If engine-api does not support lower api version, there is no way for Swarm to support lower version of docker engine, such as docker 1.6.x, docker 1.7.x.

I was wondering how to use engine-api to support api version 1.19, 1.18 or lower?

related issue in swarm:docker-archive/classicswarm#2330

Thanks in advance.

When doing a streaming request we can end-up leaking connections to the docker daemon if there's no activity on the stream. A simple example of this is calling Client.ContainerLogs() with Follow:true and stopping. No new logs must be generated from that point on. While we do have access to http.Response.Body to close it, the connection will only close on the next write error.

This module would make cancellation fairly easy to integrate with the current code.

hello,

is there a way via engine-api to retrieve the image manifest only instead of pulling full image?

maybe it will be part of the server part of the lib, but as I know not ported here yet. any date on that?

This is caused by moby/moby#12845

package main

import (
  "fmt"
  "io/ioutil"

  "github.com/docker/engine-api/client"
  "github.com/docker/engine-api/types"
  "golang.org/x/net/context"
)

// Some basic nginx container running
const ContainerID string = "ce5d8b318ca0"

func main() {
  c, _ := client.NewClient("unix:///var/run/docker.sock", "", nil, nil)

  body, _ := c.ContainerLogs(context.Background(), ContainerID, types.ContainerLogsOptions{
    ShowStdout: true,
    ShowStderr: true,
  })

  defer body.Close()

  // This line causes ContainerExecStart to fail with
  // Error response from daemon: http: Hijack is incompatible with use of CloseNotifier
  _, _ = ioutil.ReadAll(body)

  exec, _ := c.ContainerExecCreate(context.Background(), ContainerID, types.ExecConfig{
    Cmd: []string{"date"},
  })

  err := c.ContainerExecStart(context.Background(), exec.ID, types.ExecStartCheck{})
  fmt.Println(err)
}

$ go run engine-api-bug.go 
Error response from daemon: http: Hijack is incompatible with use of CloseNotifier

How can I fix this with engine-api?

Hi,

This is more of a question - I've been thinking about how to use the backward compatibility structs defined in https://github.com/docker/engine-api/tree/master/types/versions/. The older structs are implemented there, but the method signatures in the interface only refer to the latest ones.

What's the recommended way to implement functions that make use of legacy structs?

Also, is there any reason why p1v18 isn't part of the backward compatibility versions?

Thanks!

Currently the only way to deserialize events from the io.ReadCloser returned from (*Client).ImagePull is to use github.com/docker/docker/pkg/jsonmessage.JSONMessage which forces a dependency on the docker repo. Here's what code currently has to look like:

    rc, err := cli.ImagePull(context.Background(), types.ImagePullOptions{
        ImageID: containerConfig.Image,
        Tag:     tag,
    }, nil)
    if err != nil {
        return err
    }
    defer rc.Close()
    dec := json.NewDecoder(rc)
    for {
        var message jsonmessage.JSONMessage
        if err := dec.Decode(&message); err != nil {
            if err == io.EOF {
                break
            }
            return err
        }
        log.Infof("ImagePull response: %s", message)
    }

Please introduce a new type in the engine-api repo (akin to github.com/docker/engine-api/types/events.Message) that would allow deserializing these events.

HI all：
I use engine-api for my docker monitor，my program run all the time。
I find that
taishan 47434 root 9u unix 0xffff882025aae180 0t0 4493265 socket
taishan 47434 root 10u unix 0xffff880cbdc1bfc0 0t0 6003816 socket
taishan 47434 root 11u unix 0xffff880cbdc1a1c0 0t0 6003974 socket
taishan 47434 root 12u unix 0xffff880cbdc1cec0 0t0 6004348 socket
taishan 47434 root 13u unix 0xffff880e2e081e00 0t0 5991382 socket
taishan 47434 root 14u unix 0xffff882025aae540 0t0 4493267 socket
taishan 47434 root 15u unix 0xffff880c82125dc0 0t0 6009421 socket
taishan 47434 root 16u unix 0xffff8830273c2d00 0t0 5978477 socket
taishan 47434 root 17u unix 0xffff880f8d234b00 0t0 5998242 socket
So I advise add a Close function to close the client unix socket。

Right now, the docker issue moby/moby#22231
because of engine-api

NetworkInspect(ctx context.Context, networkID string) (types.NetworkResource, error)

it need a new interface like container/image inspect, defined as following

NetworkInspectWithRaw(ctx context.Context, networkID string) (types.NetworkResource, []byte, error)

Then the inspect can -f (go template) with Id like container/image did

Hi

I've been using the API and I did not understand why Client.ContainerStop accepts a pointer to time.Duration for the timeout parameter?

https://github.com/docker/engine-api/blob/master/client/container_stop.go#L13

Is this intended and has a meaning? I found it difficult the need to pass this as an address.

The main thing missing from this library that is stopping people from switching from samalba/dockerclient is event management.

@vdemeester has created a separate library for parsing and handling events. Something like this should probably be in this library.