插件开发 - Docker17.03-CE插件开发举例 - 《Docker 手册（Docker Handbook）》

关于docker plugin enable失败的问题
问题解决

看了文章后你可能会觉得，官网上的可能是个假🌰。虽然官网上的文档写的有点不对，不过你使用docker-ssh-volume的开源代码自己去构建plugin的还是可以成功的！

首先docker官方给出了一个，这篇文章基本就是告诉你docker目前支持哪些插件，罗列了一系列连接，不过对不起，这些不是docker官方插件，有问题去找它们的开发者去吧😂

Docker plugin貌似开始使用了新的v2 plugin了，legacy版本的plugin可以能在后期被废弃。

从docker的源码plugin/store.go中可以看到：

真正要开发一个docker plugin还是得看docker plugin API，这篇文档告诉我们：

插件发现

当你开发好一个插件docker engine怎么才能发现它们呢？有三种方式：


- **.spec**，比如**convoy**插件在`/etc/docker/plugins/convoy.spec `定义，内容为`unix:///var/run/convoy/convoy.sock`
- **.json**，比如**infinit**插件在`/usr/lib/docker/plugins/infinit.json `定义，内容为`{"Addr":"https://infinit.sh","Name":"infinit"}`

文章中的其它部分貌似都过时了，新的插件不是作为systemd进程运行的，而是完全通过docker plugin命令来管理的。

当你使用docker plugin enable 来激活了插件后，理应在/run/docker/plugins目录下生成插件的.sock文件，但是现在只有一个以runc ID命名的目录，这个问题下面有详细的叙述过程，你也可以跳过，直接看issue-31723

官方示例文档（这个文档有问题）

官方以开发一个sshfs的volume plugin为例。

执行docker plugin create命令的目录下必须包含以下内容：

config.json文件，里面是插件的配置信息，plugin config参考文档
rootfs目录，插件镜像解压后的目录。v2版本的docker plugin都是以docker镜像的方式包装的。

$ git clone https://github.com/vieux/docker-volume-sshfs
$ cd docker-volume-sshfs
$ go get github.com/docker/go-plugins-helpers/volume
$ go build -o docker-volume-sshfs main.go  
$ docker build -t rootfsimage .
$ id=$(docker create rootfsimage true) # id was cd851ce43a403 when the image was created
$ sudo mkdir -p myplugin/rootfs
$ sudo docker export "$id" | sudo tar -x -C myplugin/rootfs
$ docker rm -vf "$id"
$ docker rmi rootfsimage

我们可以看到sshfs的Dockerfile是这样的：

FROM alpine
RUN apk update && apk add sshfs
RUN mkdir -p /run/docker/plugins /mnt/state /mnt/volumes
COPY docker-volume-sshfs docker-volume-sshfs
CMD ["docker-volume-sshfs"]

实际上是编译好的可执行文件复制到alpine linux容器中运行。

编译rootfsimage镜像的过程。

docker build -t rootfsimage .
Sending build context to Docker daemon 11.71 MB
Step 1/5 : FROM alpine
 ---> 4a415e366388
Step 2/5 : RUN apk update && apk add sshfs
 ---> Running in 1551ecc1c847
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.5/community/x86_64/APKINDEX.tar.gz
v3.5.2-2-ge626ce8c3c [http://dl-cdn.alpinelinux.org/alpine/v3.5/main]
v3.5.1-71-gc7bb9a04f0 [http://dl-cdn.alpinelinux.org/alpine/v3.5/community]
OK: 7959 distinct packages available
(1/10) Installing openssh-client (7.4_p1-r0)
(2/10) Installing fuse (2.9.7-r0)
(3/10) Installing libffi (3.2.1-r2)
(4/10) Installing libintl (0.19.8.1-r0)
(5/10) Installing libuuid (2.28.2-r1)
(6/10) Installing libblkid (2.28.2-r1)
(7/10) Installing libmount (2.28.2-r1)
(8/10) Installing pcre (8.39-r0)
(9/10) Installing glib (2.50.2-r0)
(10/10) Installing sshfs (2.8-r0)
Executing busybox-1.25.1-r0.trigger
Executing glib-2.50.2-r0.trigger
OK: 11 MiB in 21 packages
 ---> 1a73c501f431
Removing intermediate container 1551ecc1c847
Step 3/5 : RUN mkdir -p /run/docker/plugins /mnt/state /mnt/volumes
 ---> Running in 032af3b2595a
 ---> 30c7e8463e96
Removing intermediate container 032af3b2595a
Step 4/5 : COPY docker-volume-sshfs docker-volume-sshfs
 ---> a924c6fcc1e4
Removing intermediate container ffc5e3c97707
Step 5/5 : CMD docker-volume-sshfs
 ---> Running in 0dc938fe4f4e
 ---> 0fd2e3d94860
Removing intermediate container 0dc938fe4f4e
Successfully built 0fd2e3d94860

编写config.json文档

{
    "description": "sshFS plugin for Docker",
    "entrypoint": [
        "/docker-volume-sshfs"
    ],
        {
            "name": "DEBUG",
            "settable": [
                "value"
            ],
            "value": "0"
        }
    ],
    "interface": {
        "socket": "sshfs.sock",
        "types": [
            "docker.volumedriver/1.0"
        ]
    },
    "linux": {
        "capabilities": [
            "CAP_SYS_ADMIN"
        ],
        "devices": [
            {
                "path": "/dev/fuse"
            }
        ]
    },
    "mounts": [
        {
            "destination": "/mnt/state",
            "options": [
                "rbind"
            ],
            "source": "/var/lib/docker/plugins/",
            "type": "bind"
        }
    ],
    "network": {
        "type": "host"
    },
    "propagatedmount": "/mnt/volumes"
}

该插件使用host网络类型，使用/run/docker/plugins/sshfs.sock接口与docker engine通信。

创建plugin

使用docker plugin create <plugin_name> /path/to/plugin/data/命令创建插件。

具体到sshfs插件，在myplugin目录下使用如下命令创建插件：

docker plugin create jimmmysong/sshfs:latest .

现在就可以看到刚创建的插件了

push plugin

先登录你的docker hub账户，然后使用docker plugin push jimmysong/sshfs:latest即可以推送docker plugin到docker hub中。

目前推送到harbor镜像仓库有问题，报错信息：

c08c951b53b7: Preparing 
denied: requested access to the resource is denied

已给harbor提

plugin的使用

有发现了个问题docker issue-31723，使用plugin创建volume的时候居然找不到sshfs.sock文件！😢刚开始手动创建plugin的时候测试了下是正常的，不知道为啥弄到这台测试机器上出问题了。

当docker plugin创建成功并enable的时候docker并没有报错，这与docker plugin的activate机制有关，只有当你最终使用该plugin的时候才会激活它。

使用sshfs插件创建volume。

docker volume create -d jimmysong/sshfs --name sshvolume -o sshcmd=1.2.3.4:/remote -o password=password

报错如下：

Error response from daemon: create sshvolume: Post http://%2Frun%2Fdocker%2Fplugins%2F8f7b8f931b38a4ef53d0e4f8d738e26e8f10ef8bd26c8244f4b8dcc7276b685f%2Fsshfs.sock/VolumeDriver.Create: dial unix /run/docker/plugins/8f7b8f931b38a4ef53d0e4f8d738e26e8f10ef8bd26c8244f4b8dcc7276b685f/sshfs.sock: connect: no such file or directory

Docker daemon在enable这个插件的时候会寻找这个.sock文件，然后在自己的plugindb中注册它，相关代码在这个文件里：

https://github.com/docker/docker/blob/17.03.x/plugin/manager_linux.go

相关代码片段：

func (pm *Manager) enable(p *v2.Plugin, c *controller, force bool) error {
    ...
    return pm.pluginPostStart(p, c)
}
func (pm *Manager) pluginPostStart(p *v2.Plugin, c *controller) error {
    //这里需要获取.sock文件的地址 
    //pm.conifg.ExecRoot就是/run/docker/plugins
    //p.GetID()返回的就是很长的那串plugin ID
    sockAddr := filepath.Join(pm.config.ExecRoot, p.GetID(), p.GetSocket())
    client, err := plugins.NewClientWithTimeout("unix://"+sockAddr, nil, c.timeoutInSecs)
    if err != nil {
        c.restart = false
        shutdownPlugin(p, c, pm.containerdClient)
        return errors.WithStack(err)
    }
    p.SetPClient(client)
    maxRetries := 3
        time.Sleep(3 * time.Second)
        retries++
        if retries > maxRetries {
            logrus.Debugf("error net dialing plugin: %v", err)
            c.restart = false
            shutdownPlugin(p, c, pm.containerdClient)
            return err
        }
        // net dial into the unix socket to see if someone's listening.
        conn, err := net.Dial("unix", sockAddr)
        if err == nil {
            conn.Close()
            break
        }
    }
    pm.config.Store.SetState(p, true)
    pm.config.Store.CallHandler(p)
    return pm.save(p)
}

注意这段代码里的sockAddr := filepath.Join(pm.config.ExecRoot, p.GetID(), p.GetSocket())，我在上面添加了注释。

这个.sock文件应该有docker plugin来生成，具体怎样生成的呢？还以docker-volume-ssh这个插件为例。

logrus.Error(h.ServeUnix(socketAddress, 0))

这行代码调用docker/go-plugin-helpers/sdk/handler.go中的:

//unix_listener_unsupoorted.go
func newUnixListener(pluginName string, gid int) (net.Listener, string, error) {
    return nil, "", errOnlySupportedOnLinuxAndFreeBSD
}

看了上面这这些，你看出socket文件是怎么创建的吗？

这又是一个

如果你修改config.json文件，将其中的interfaces - socket指定为/run/docker/plugins/sshfs.sock然后创建plugin，则能成功生成socket文件，但是当你enable它的时候又会报错

Error response from daemon: Unix socket path "/run/docker/plugins/ac34f7b246ac6c029023b1ebd48e166eadcdd2c9d0cc682cadca0336951d72f7/run/docker/plugins/sshfs.sock" is too long

从docker daemon的日志里可以看到详细报错：

Mar 13 17:15:20 sz-pg-oam-docker-test-001.tendcloud.com dockerd[51757]: time="2017-03-13T17:15:20+08:00" level=info msg="standard_init_linux.go:178: exec user process caused \"no such file or directory\"" plugin=ac34f7b246ac6c029023b1ebd48e166eadcdd2c9d0cc682cadca0336951d72f7
Mar 13 17:15:20 sz-pg-oam-docker-test-001.tendcloud.com dockerd[51757]: time="2017-03-13T17:15:20.321277088+08:00" level=error msg="Sending SIGTERM to plugin failed with error: rpc error: code = 2 desc = no such process"
Mar 13 17:15:20 sz-pg-oam-docker-test-001.tendcloud.com dockerd[51757]: time="2017-03-13T17:15:20.321488680+08:00" level=error msg="Handler for POST /v1.26/plugins/sshfs/enable returned error: Unix socket path \"/run/docker/plugins/ac34f7b246ac6c029023b1ebd48e166eadcdd2c9d0cc682cadca0336951d72f7/run/docker/plugins/sshfs.sock\" is too long\ngithub.com/docker/docker/plugin.(*Manager).pluginPostStart\n\t/root/rpmbuild/BUILD/docker-engine/.gopath/src/github.com/docker/docker/plugin/manager_linux.go:84\ngithub.com/docker/docker/plugin.(*Manager).enable\n\t/root/rpmbuild/BUILD/docker-

正好验证了上面的enable代码，docker默认是到/run/docker/plugins目录下找sshfs.sock这个文件的。

我在docker daemon中发现一个很诡异的错误，

Mar 13 17:29:41 sz-pg-oam-docker-test-001.tendcloud.com dockerd[51757]: time="2017-03-13T17:29:41+08:00" level=info msg="standard_init_linux.go:178: exec user process caused \"no such file or directory\"" plugin=85760810b4850009fc965f5c20d8534dc9aba085340a2ac0b4b9167a6fef7d53

我查看了下

github.com/libnetwork/vendor/github.com/opencontainers/run/libcontainer/standard_init_linux.go

文件，这个那个文件只有114行，见 standard_init_linux.go

但是在opencontainers的github项目里才有那么多行，见

这个报错前后的函数是：

// PR_SET_NO_NEW_PRIVS isn't exposed in Golang so we define it ourselves copying the value
// the kernel
const PR_SET_NO_NEW_PRIVS = 0x26
func (l *linuxStandardInit) Init() error {
    if !l.config.Config.NoNewKeyring {
        ringname, keepperms, newperms := l.getSessionRingParams()
        // do not inherit the parent's session keyring
        sessKeyId, err := keys.JoinSessionKeyring(ringname)
        if err != nil {
            return err
        }
        // make session keyring searcheable
        if err := keys.ModKeyringPerm(sessKeyId, keepperms, newperms); err != nil {
            return err
        }
    }
...
    }
    if l.config.Config.Seccomp != nil && l.config.NoNewPrivileges {
         //下面这行是第178行
        if err := seccomp.InitSeccomp(l.config.Config.Seccomp); err != nil {
            return newSystemErrorWithCause(err, "init seccomp")
        }
    }
    // close the statedir fd before exec because the kernel resets dumpable in the wrong order
    // https://github.com/torvalds/linux/blob/v4.9/fs/exec.c#L1290-L1318
    syscall.Close(l.stateDirFD)
    if err := syscall.Exec(name, l.config.Args[0:], os.Environ()); err != nil {
        return newSystemErrorWithCause(err, "exec user process")
    }
    return nil

~~到此了问题还没解决。~~

问题的关键是执行docker create plugin之后.sock文件创建到哪里去了？为什么在config.json指定成/run/docker/plugins/sshfs.sock就可以在指定的目录下创建出.sock文件，说明创建socket的定义和get socket时寻找的路径不一样，创建socket时就是固定在/run/docker/plugins目录下创建，而enable plugin的时候，Get socket的时候还要加上docker plugin的ID，可是按照官网的配置在本地create plugin后并没有在/run/docker/plugins目录下生成插件的socket文件，直到enable插件的时候才会生成以plugin ID命名的目录，但是socket文件没有！☹️

问题解决

之所以出现上面的那些问题，是因为create docker plugin的时候有问题，也就是那个二进制文件有问题，我在Mac上build的image，而且还没有用Dockerfile.dev这个专门用来搭建二进制文件编译环境的Dockerfile来创建golang的编译环境，虽然docker plugin是创建成功了，但是当docker plugin enable的时候，这个热紧张文件不能正确的运行，所以就没能生成sshfs.sock文件。

微信打赏