Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
package remote // import "github.com/docker/docker/libcontainerd/remote"
|
2017-09-22 09:52:41 -04:00
|
|
|
|
|
|
|
import (
|
|
|
|
"context"
|
|
|
|
"encoding/json"
|
|
|
|
"io"
|
|
|
|
"os"
|
|
|
|
"path/filepath"
|
|
|
|
"reflect"
|
|
|
|
"runtime"
|
|
|
|
"strings"
|
|
|
|
"sync"
|
|
|
|
"syscall"
|
|
|
|
"time"
|
|
|
|
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
"github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options"
|
2017-09-22 09:52:41 -04:00
|
|
|
"github.com/containerd/containerd"
|
2018-04-18 17:55:50 -04:00
|
|
|
apievents "github.com/containerd/containerd/api/events"
|
2017-09-22 09:52:41 -04:00
|
|
|
"github.com/containerd/containerd/api/types"
|
|
|
|
"github.com/containerd/containerd/archive"
|
2017-11-29 19:15:20 -05:00
|
|
|
"github.com/containerd/containerd/cio"
|
2017-09-22 09:52:41 -04:00
|
|
|
"github.com/containerd/containerd/content"
|
2017-11-28 23:09:37 -05:00
|
|
|
containerderrors "github.com/containerd/containerd/errdefs"
|
2018-04-18 17:55:50 -04:00
|
|
|
"github.com/containerd/containerd/events"
|
2017-09-22 09:52:41 -04:00
|
|
|
"github.com/containerd/containerd/images"
|
2018-06-08 20:39:07 -04:00
|
|
|
"github.com/containerd/containerd/runtime/linux/runctypes"
|
2017-09-22 09:52:41 -04:00
|
|
|
"github.com/containerd/typeurl"
|
2018-01-11 14:53:06 -05:00
|
|
|
"github.com/docker/docker/errdefs"
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
"github.com/docker/docker/libcontainerd/queue"
|
|
|
|
libcontainerdtypes "github.com/docker/docker/libcontainerd/types"
|
|
|
|
|
2017-09-22 09:52:41 -04:00
|
|
|
"github.com/docker/docker/pkg/ioutils"
|
2018-12-17 05:22:37 -05:00
|
|
|
v1 "github.com/opencontainers/image-spec/specs-go/v1"
|
2018-06-08 20:39:07 -04:00
|
|
|
specs "github.com/opencontainers/runtime-spec/specs-go"
|
2017-09-22 09:52:41 -04:00
|
|
|
"github.com/pkg/errors"
|
|
|
|
"github.com/sirupsen/logrus"
|
2018-06-08 20:39:07 -04:00
|
|
|
"google.golang.org/grpc/codes"
|
|
|
|
"google.golang.org/grpc/status"
|
2017-09-22 09:52:41 -04:00
|
|
|
)
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
// DockerContainerBundlePath is the label key pointing to the container's bundle path
|
|
|
|
const DockerContainerBundlePath = "com.docker/engine.bundle.path"
|
2017-12-15 11:32:08 -05:00
|
|
|
|
2017-09-22 09:52:41 -04:00
|
|
|
type client struct {
|
2018-05-23 15:15:21 -04:00
|
|
|
client *containerd.Client
|
2017-09-22 09:52:41 -04:00
|
|
|
stateDir string
|
|
|
|
logger *logrus.Entry
|
2018-05-23 15:15:21 -04:00
|
|
|
ns string
|
2017-09-22 09:52:41 -04:00
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
backend libcontainerdtypes.Backend
|
|
|
|
eventQ queue.Queue
|
|
|
|
oomMu sync.Mutex
|
|
|
|
oom map[string]bool
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
2018-05-23 15:15:21 -04:00
|
|
|
// NewClient creates a new libcontainerd client from a containerd client
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
func NewClient(ctx context.Context, cli *containerd.Client, stateDir, ns string, b libcontainerdtypes.Backend) (libcontainerdtypes.Client, error) {
|
2018-05-23 15:15:21 -04:00
|
|
|
c := &client{
|
2019-03-25 16:17:17 -04:00
|
|
|
client: cli,
|
|
|
|
stateDir: stateDir,
|
|
|
|
logger: logrus.WithField("module", "libcontainerd").WithField("namespace", ns),
|
|
|
|
ns: ns,
|
|
|
|
backend: b,
|
|
|
|
oom: make(map[string]bool),
|
2018-05-23 15:15:21 -04:00
|
|
|
}
|
2018-03-23 14:25:53 -04:00
|
|
|
|
2018-05-23 15:15:21 -04:00
|
|
|
go c.processEventStream(ctx, ns)
|
2018-01-31 17:32:40 -05:00
|
|
|
|
2018-05-23 15:15:21 -04:00
|
|
|
return c, nil
|
2018-01-31 17:32:40 -05:00
|
|
|
}
|
|
|
|
|
2017-11-02 20:21:18 -04:00
|
|
|
func (c *client) Version(ctx context.Context) (containerd.Version, error) {
|
2018-05-23 15:15:21 -04:00
|
|
|
return c.client.Version(ctx)
|
2017-11-02 20:21:18 -04:00
|
|
|
}
|
|
|
|
|
2018-04-10 11:05:11 -04:00
|
|
|
// Restore loads the containerd container.
|
|
|
|
// It should not be called concurrently with any other operation for the given ID.
|
2019-03-25 16:17:17 -04:00
|
|
|
func (c *client) Restore(ctx context.Context, id string, attachStdio libcontainerdtypes.StdioCallback) (alive bool, pid int, p libcontainerdtypes.Process, err error) {
|
2018-01-04 16:12:23 -05:00
|
|
|
var dio *cio.DirectIO
|
2017-09-22 09:52:41 -04:00
|
|
|
defer func() {
|
2018-01-04 16:12:23 -05:00
|
|
|
if err != nil && dio != nil {
|
|
|
|
dio.Cancel()
|
|
|
|
dio.Close()
|
|
|
|
}
|
2017-09-22 09:52:41 -04:00
|
|
|
err = wrapError(err)
|
|
|
|
}()
|
|
|
|
|
2018-05-23 15:15:21 -04:00
|
|
|
ctr, err := c.client.LoadContainer(ctx, id)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
2019-03-25 16:17:17 -04:00
|
|
|
return false, -1, nil, errors.WithStack(wrapError(err))
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
2018-01-04 16:12:23 -05:00
|
|
|
attachIO := func(fifos *cio.FIFOSet) (cio.IO, error) {
|
|
|
|
// dio must be assigned to the previously defined dio for the defer above
|
|
|
|
// to handle cleanup
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
dio, err = c.newDirectIO(ctx, fifos)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
2018-01-04 16:12:23 -05:00
|
|
|
return attachStdio(dio)
|
|
|
|
}
|
|
|
|
t, err := ctr.Task(ctx, attachIO)
|
2018-02-08 12:57:38 -05:00
|
|
|
if err != nil && !containerderrors.IsNotFound(err) {
|
2019-03-25 16:17:17 -04:00
|
|
|
return false, -1, nil, errors.Wrap(wrapError(err), "error getting containerd task for container")
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
if t != nil {
|
|
|
|
s, err := t.Status(ctx)
|
|
|
|
if err != nil {
|
2019-03-25 16:17:17 -04:00
|
|
|
return false, -1, nil, errors.Wrap(wrapError(err), "error getting task status")
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
alive = s.Status != containerd.Stopped
|
|
|
|
pid = int(t.Pid())
|
|
|
|
}
|
2018-04-10 11:05:11 -04:00
|
|
|
|
2017-09-22 09:52:41 -04:00
|
|
|
c.logger.WithFields(logrus.Fields{
|
|
|
|
"container": id,
|
|
|
|
"alive": alive,
|
|
|
|
"pid": pid,
|
|
|
|
}).Debug("restored container")
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
return alive, pid, &restoredProcess{
|
|
|
|
p: t,
|
|
|
|
}, nil
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) Create(ctx context.Context, id string, ociSpec *specs.Spec, runtimeOptions interface{}) error {
|
2019-03-25 16:17:17 -04:00
|
|
|
bdir := c.bundleDir(id)
|
2017-09-22 09:52:41 -04:00
|
|
|
c.logger.WithField("bundle", bdir).WithField("root", ociSpec.Root.Path).Debug("bundle dir created")
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
_, err := c.client.NewContainer(ctx, id,
|
2017-09-22 09:52:41 -04:00
|
|
|
containerd.WithSpec(ociSpec),
|
2019-03-25 14:19:09 -04:00
|
|
|
containerd.WithRuntime(runtimeName, runtimeOptions),
|
|
|
|
WithBundle(bdir, ociSpec),
|
|
|
|
)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
2019-03-25 16:17:17 -04:00
|
|
|
if containerderrors.IsAlreadyExists(err) {
|
|
|
|
return errors.WithStack(errdefs.Conflict(errors.New("id already in use")))
|
|
|
|
}
|
2018-03-27 10:03:53 -04:00
|
|
|
return wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// Start create and start a task for the specified containerd id
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
func (c *client) Start(ctx context.Context, id, checkpointDir string, withStdin bool, attachStdio libcontainerdtypes.StdioCallback) (int, error) {
|
2019-03-25 16:17:17 -04:00
|
|
|
ctr, err := c.getContainer(ctx, id)
|
|
|
|
if err != nil {
|
|
|
|
return -1, err
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
var (
|
|
|
|
cp *types.Descriptor
|
|
|
|
t containerd.Task
|
2017-11-29 19:15:20 -05:00
|
|
|
rio cio.IO
|
2017-09-22 09:52:41 -04:00
|
|
|
stdinCloseSync = make(chan struct{})
|
|
|
|
)
|
|
|
|
|
|
|
|
if checkpointDir != "" {
|
|
|
|
// write checkpoint to the content store
|
|
|
|
tar := archive.Diff(ctx, "", checkpointDir)
|
|
|
|
cp, err = c.writeContent(ctx, images.MediaTypeContainerd1Checkpoint, checkpointDir, tar)
|
|
|
|
// remove the checkpoint when we're done
|
|
|
|
defer func() {
|
|
|
|
if cp != nil {
|
2018-05-23 15:15:21 -04:00
|
|
|
err := c.client.ContentStore().Delete(context.Background(), cp.Digest)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
c.logger.WithError(err).WithFields(logrus.Fields{
|
|
|
|
"ref": checkpointDir,
|
|
|
|
"digest": cp.Digest,
|
|
|
|
}).Warnf("failed to delete temporary checkpoint entry")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}()
|
|
|
|
if err := tar.Close(); err != nil {
|
|
|
|
return -1, errors.Wrap(err, "failed to close checkpoint tar stream")
|
|
|
|
}
|
|
|
|
if err != nil {
|
|
|
|
return -1, errors.Wrapf(err, "failed to upload checkpoint to containerd")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
spec, err := ctr.Spec(ctx)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return -1, errors.Wrap(err, "failed to retrieve spec")
|
|
|
|
}
|
2019-03-25 16:17:17 -04:00
|
|
|
labels, err := ctr.Labels(ctx)
|
|
|
|
if err != nil {
|
2019-06-04 11:33:04 -04:00
|
|
|
return -1, errors.Wrap(err, "failed to retrieve labels")
|
2019-03-25 16:17:17 -04:00
|
|
|
}
|
|
|
|
bundle := labels[DockerContainerBundlePath]
|
2017-09-22 09:52:41 -04:00
|
|
|
uid, gid := getSpecUser(spec)
|
2019-03-25 16:17:17 -04:00
|
|
|
t, err = ctr.NewTask(ctx,
|
2017-11-29 19:15:20 -05:00
|
|
|
func(id string) (cio.IO, error) {
|
2019-03-25 16:17:17 -04:00
|
|
|
fifos := newFIFOSet(bundle, libcontainerdtypes.InitProcessName, withStdin, spec.Process.Terminal)
|
2018-05-31 20:03:28 -04:00
|
|
|
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
rio, err = c.createIO(fifos, id, libcontainerdtypes.InitProcessName, stdinCloseSync, attachStdio)
|
2017-11-29 19:15:20 -05:00
|
|
|
return rio, err
|
2017-09-22 09:52:41 -04:00
|
|
|
},
|
|
|
|
func(_ context.Context, _ *containerd.Client, info *containerd.TaskInfo) error {
|
|
|
|
info.Checkpoint = cp
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
if runtime.GOOS != "windows" {
|
|
|
|
info.Options = &runctypes.CreateOptions{
|
|
|
|
IoUid: uint32(uid),
|
|
|
|
IoGid: uint32(gid),
|
|
|
|
NoPivotRoot: os.Getenv("DOCKER_RAMDISK") != "",
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// Make sure we set the runhcs options to debug if we are at debug level.
|
|
|
|
if c.logger.Level == logrus.DebugLevel {
|
|
|
|
info.Options = &options.Options{Debug: true}
|
|
|
|
}
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
return nil
|
|
|
|
})
|
|
|
|
if err != nil {
|
|
|
|
close(stdinCloseSync)
|
2017-11-29 19:15:20 -05:00
|
|
|
if rio != nil {
|
|
|
|
rio.Cancel()
|
|
|
|
rio.Close()
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
2018-03-27 10:03:53 -04:00
|
|
|
return -1, wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
// Signal c.createIO that it can call CloseIO
|
|
|
|
close(stdinCloseSync)
|
|
|
|
|
|
|
|
if err := t.Start(ctx); err != nil {
|
|
|
|
if _, err := t.Delete(ctx); err != nil {
|
|
|
|
c.logger.WithError(err).WithField("container", id).
|
|
|
|
Error("failed to delete task after fail start")
|
|
|
|
}
|
2018-03-27 10:03:53 -04:00
|
|
|
return -1, wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
return int(t.Pid()), nil
|
|
|
|
}
|
|
|
|
|
2018-10-10 02:54:00 -04:00
|
|
|
// Exec creates exec process.
|
|
|
|
//
|
|
|
|
// The containerd client calls Exec to register the exec config in the shim side.
|
|
|
|
// When the client calls Start, the shim will create stdin fifo if needs. But
|
|
|
|
// for the container main process, the stdin fifo will be created in Create not
|
|
|
|
// the Start call. stdinCloseSync channel should be closed after Start exec
|
|
|
|
// process.
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
func (c *client) Exec(ctx context.Context, containerID, processID string, spec *specs.Process, withStdin bool, attachStdio libcontainerdtypes.StdioCallback) (int, error) {
|
2019-03-25 16:17:17 -04:00
|
|
|
ctr, err := c.getContainer(ctx, containerID)
|
|
|
|
if err != nil {
|
|
|
|
return -1, err
|
2017-12-15 11:32:08 -05:00
|
|
|
}
|
2019-03-25 16:17:17 -04:00
|
|
|
t, err := ctr.Task(ctx, nil)
|
|
|
|
if err != nil {
|
|
|
|
if containerderrors.IsNotFound(err) {
|
|
|
|
return -1, errors.WithStack(errdefs.InvalidParameter(errors.New("container is not running")))
|
|
|
|
}
|
|
|
|
return -1, wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
var (
|
|
|
|
p containerd.Process
|
2017-11-29 19:15:20 -05:00
|
|
|
rio cio.IO
|
2017-09-22 09:52:41 -04:00
|
|
|
stdinCloseSync = make(chan struct{})
|
|
|
|
)
|
2017-11-13 17:53:56 -05:00
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
labels, err := ctr.Labels(ctx)
|
|
|
|
if err != nil {
|
|
|
|
return -1, wrapError(err)
|
|
|
|
}
|
|
|
|
|
|
|
|
fifos := newFIFOSet(labels[DockerContainerBundlePath], processID, withStdin, spec.Terminal)
|
2017-11-13 17:53:56 -05:00
|
|
|
|
2017-09-22 09:52:41 -04:00
|
|
|
defer func() {
|
|
|
|
if err != nil {
|
2017-11-29 19:15:20 -05:00
|
|
|
if rio != nil {
|
|
|
|
rio.Cancel()
|
|
|
|
rio.Close()
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}()
|
|
|
|
|
2017-12-15 11:32:08 -05:00
|
|
|
p, err = t.Exec(ctx, processID, spec, func(id string) (cio.IO, error) {
|
2018-06-08 20:39:07 -04:00
|
|
|
rio, err = c.createIO(fifos, containerID, processID, stdinCloseSync, attachStdio)
|
2017-11-29 19:15:20 -05:00
|
|
|
return rio, err
|
2017-09-22 09:52:41 -04:00
|
|
|
})
|
|
|
|
if err != nil {
|
|
|
|
close(stdinCloseSync)
|
2019-03-25 16:17:17 -04:00
|
|
|
if containerderrors.IsAlreadyExists(err) {
|
|
|
|
return -1, errors.WithStack(errdefs.Conflict(errors.New("id already in use")))
|
|
|
|
}
|
2018-03-27 10:03:53 -04:00
|
|
|
return -1, wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
// Signal c.createIO that it can call CloseIO
|
2018-10-10 02:54:00 -04:00
|
|
|
//
|
|
|
|
// the stdin of exec process will be created after p.Start in containerd
|
|
|
|
defer close(stdinCloseSync)
|
2017-09-22 09:52:41 -04:00
|
|
|
|
|
|
|
if err = p.Start(ctx); err != nil {
|
2018-12-17 05:22:37 -05:00
|
|
|
// use new context for cleanup because old one may be cancelled by user, but leave a timeout to make sure
|
|
|
|
// we are not waiting forever if containerd is unresponsive or to work around fifo cancelling issues in
|
|
|
|
// older containerd-shim
|
|
|
|
ctx, cancel := context.WithTimeout(context.Background(), 45*time.Second)
|
|
|
|
defer cancel()
|
|
|
|
p.Delete(ctx)
|
2018-03-27 10:03:53 -04:00
|
|
|
return -1, wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
return int(p.Pid()), nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) SignalProcess(ctx context.Context, containerID, processID string, signal int) error {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, containerID, processID)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
2017-12-15 10:00:15 -05:00
|
|
|
return wrapError(p.Kill(ctx, syscall.Signal(signal)))
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) ResizeTerminal(ctx context.Context, containerID, processID string, width, height int) error {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, containerID, processID)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
return p.Resize(ctx, uint32(width), uint32(height))
|
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) CloseStdin(ctx context.Context, containerID, processID string) error {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, containerID, processID)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
return p.CloseIO(ctx, containerd.WithStdinCloser)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) Pause(ctx context.Context, containerID string) error {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, containerID, libcontainerdtypes.InitProcessName)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2018-03-27 10:03:53 -04:00
|
|
|
return wrapError(p.(containerd.Task).Pause(ctx))
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) Resume(ctx context.Context, containerID string) error {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, containerID, libcontainerdtypes.InitProcessName)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
|
|
|
return p.(containerd.Task).Resume(ctx)
|
|
|
|
}
|
|
|
|
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
func (c *client) Stats(ctx context.Context, containerID string) (*libcontainerdtypes.Stats, error) {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, containerID, libcontainerdtypes.InitProcessName)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
m, err := p.(containerd.Task).Metrics(ctx)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
v, err := typeurl.UnmarshalAny(m.Data)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
return libcontainerdtypes.InterfaceToStats(m.Timestamp, v), nil
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) ListPids(ctx context.Context, containerID string) ([]uint32, error) {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, containerID, libcontainerdtypes.InitProcessName)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
pis, err := p.(containerd.Task).Pids(ctx)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
var pids []uint32
|
|
|
|
for _, i := range pis {
|
|
|
|
pids = append(pids, i.Pid)
|
|
|
|
}
|
|
|
|
|
|
|
|
return pids, nil
|
|
|
|
}
|
|
|
|
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
func (c *client) Summary(ctx context.Context, containerID string) ([]libcontainerdtypes.Summary, error) {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, containerID, libcontainerdtypes.InitProcessName)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
pis, err := p.(containerd.Task).Pids(ctx)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
var infos []libcontainerdtypes.Summary
|
2017-09-22 09:52:41 -04:00
|
|
|
for _, pi := range pis {
|
|
|
|
i, err := typeurl.UnmarshalAny(pi.Info)
|
|
|
|
if err != nil {
|
|
|
|
return nil, errors.Wrap(err, "unable to decode process details")
|
|
|
|
}
|
|
|
|
s, err := summaryFromInterface(i)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
infos = append(infos, *s)
|
|
|
|
}
|
|
|
|
|
|
|
|
return infos, nil
|
|
|
|
}
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
type restoredProcess struct {
|
|
|
|
p containerd.Process
|
|
|
|
}
|
|
|
|
|
|
|
|
func (p *restoredProcess) Delete(ctx context.Context) (uint32, time.Time, error) {
|
|
|
|
if p.p == nil {
|
|
|
|
return 255, time.Now(), nil
|
|
|
|
}
|
|
|
|
status, err := p.p.Delete(ctx)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return 255, time.Now(), nil
|
|
|
|
}
|
2019-03-25 16:17:17 -04:00
|
|
|
return status.ExitCode(), status.ExitTime(), nil
|
|
|
|
}
|
2017-09-22 09:52:41 -04:00
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
func (c *client) DeleteTask(ctx context.Context, containerID string) (uint32, time.Time, error) {
|
|
|
|
p, err := c.getProcess(ctx, containerID, libcontainerdtypes.InitProcessName)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return 255, time.Now(), nil
|
|
|
|
}
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
status, err := p.Delete(ctx)
|
|
|
|
if err != nil {
|
|
|
|
return 255, time.Now(), nil
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
return status.ExitCode(), status.ExitTime(), nil
|
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) Delete(ctx context.Context, containerID string) error {
|
2019-03-25 16:17:17 -04:00
|
|
|
ctr, err := c.getContainer(ctx, containerID)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
2019-03-25 16:17:17 -04:00
|
|
|
labels, err := ctr.Labels(ctx)
|
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
bundle := labels[DockerContainerBundlePath]
|
|
|
|
if err := ctr.Delete(ctx); err != nil {
|
2018-03-27 10:03:53 -04:00
|
|
|
return wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
2019-03-25 16:17:17 -04:00
|
|
|
c.oomMu.Lock()
|
|
|
|
delete(c.oom, containerID)
|
|
|
|
c.oomMu.Unlock()
|
2017-11-13 17:53:56 -05:00
|
|
|
if os.Getenv("LIBCONTAINERD_NOCLEAN") != "1" {
|
2019-03-25 16:17:17 -04:00
|
|
|
if err := os.RemoveAll(bundle); err != nil {
|
2017-09-22 09:52:41 -04:00
|
|
|
c.logger.WithError(err).WithFields(logrus.Fields{
|
|
|
|
"container": containerID,
|
2019-03-25 16:17:17 -04:00
|
|
|
"bundle": bundle,
|
2017-09-22 09:52:41 -04:00
|
|
|
}).Error("failed to remove state dir")
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
2019-04-04 14:46:02 -04:00
|
|
|
func (c *client) Status(ctx context.Context, containerID string) (containerd.ProcessStatus, error) {
|
2019-03-25 16:17:17 -04:00
|
|
|
t, err := c.getProcess(ctx, containerID, libcontainerdtypes.InitProcessName)
|
|
|
|
if err != nil {
|
|
|
|
return containerd.Unknown, err
|
2017-12-15 11:32:08 -05:00
|
|
|
}
|
|
|
|
s, err := t.Status(ctx)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
2019-04-04 14:46:02 -04:00
|
|
|
return containerd.Unknown, wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
2019-04-04 14:46:02 -04:00
|
|
|
return s.Status, nil
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) CreateCheckpoint(ctx context.Context, containerID, checkpointDir string, exit bool) error {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, containerID, libcontainerdtypes.InitProcessName)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2018-06-27 20:53:12 -04:00
|
|
|
opts := []containerd.CheckpointTaskOpts{}
|
|
|
|
if exit {
|
2018-08-17 16:08:22 -04:00
|
|
|
opts = append(opts, func(r *containerd.CheckpointTaskInfo) error {
|
|
|
|
if r.Options == nil {
|
|
|
|
r.Options = &runctypes.CheckpointOptions{
|
|
|
|
Exit: true,
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
opts, _ := r.Options.(*runctypes.CheckpointOptions)
|
|
|
|
opts.Exit = true
|
|
|
|
}
|
|
|
|
return nil
|
|
|
|
})
|
2018-06-27 20:53:12 -04:00
|
|
|
}
|
|
|
|
img, err := p.(containerd.Task).Checkpoint(ctx, opts...)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
2018-03-27 10:03:53 -04:00
|
|
|
return wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
// Whatever happens, delete the checkpoint from containerd
|
|
|
|
defer func() {
|
2018-05-23 15:15:21 -04:00
|
|
|
err := c.client.ImageService().Delete(context.Background(), img.Name())
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
c.logger.WithError(err).WithField("digest", img.Target().Digest).
|
|
|
|
Warnf("failed to delete checkpoint image")
|
|
|
|
}
|
|
|
|
}()
|
|
|
|
|
2018-05-23 15:15:21 -04:00
|
|
|
b, err := content.ReadBlob(ctx, c.client.ContentStore(), img.Target())
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
2017-11-28 23:09:37 -05:00
|
|
|
return errdefs.System(errors.Wrapf(err, "failed to retrieve checkpoint data"))
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
var index v1.Index
|
|
|
|
if err := json.Unmarshal(b, &index); err != nil {
|
2017-11-28 23:09:37 -05:00
|
|
|
return errdefs.System(errors.Wrapf(err, "failed to decode checkpoint data"))
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
var cpDesc *v1.Descriptor
|
|
|
|
for _, m := range index.Manifests {
|
|
|
|
if m.MediaType == images.MediaTypeContainerd1Checkpoint {
|
|
|
|
cpDesc = &m
|
|
|
|
break
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if cpDesc == nil {
|
2017-11-28 23:09:37 -05:00
|
|
|
return errdefs.System(errors.Wrapf(err, "invalid checkpoint"))
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
2018-05-23 15:15:21 -04:00
|
|
|
rat, err := c.client.ContentStore().ReaderAt(ctx, *cpDesc)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
2017-11-28 23:09:37 -05:00
|
|
|
return errdefs.System(errors.Wrapf(err, "failed to get checkpoint reader"))
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
defer rat.Close()
|
|
|
|
_, err = archive.Apply(ctx, checkpointDir, content.NewReader(rat))
|
|
|
|
if err != nil {
|
2017-11-28 23:09:37 -05:00
|
|
|
return errdefs.System(errors.Wrapf(err, "failed to read checkpoint reader"))
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
|
|
|
return err
|
|
|
|
}
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
func (c *client) getContainer(ctx context.Context, id string) (containerd.Container, error) {
|
|
|
|
ctr, err := c.client.LoadContainer(ctx, id)
|
|
|
|
if err != nil {
|
|
|
|
if containerderrors.IsNotFound(err) {
|
|
|
|
return nil, errors.WithStack(errdefs.NotFound(errors.New("no such container")))
|
|
|
|
}
|
|
|
|
return nil, wrapError(err)
|
|
|
|
}
|
|
|
|
return ctr, nil
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
func (c *client) getProcess(ctx context.Context, containerID, processID string) (containerd.Process, error) {
|
|
|
|
ctr, err := c.getContainer(ctx, containerID)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
2017-12-15 11:32:08 -05:00
|
|
|
}
|
2019-03-25 16:17:17 -04:00
|
|
|
t, err := ctr.Task(ctx, nil)
|
|
|
|
if err != nil {
|
|
|
|
if containerderrors.IsNotFound(err) {
|
|
|
|
return nil, errors.WithStack(errdefs.NotFound(errors.New("container is not running")))
|
|
|
|
}
|
|
|
|
return nil, wrapError(err)
|
2017-12-15 11:32:08 -05:00
|
|
|
}
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
if processID == libcontainerdtypes.InitProcessName {
|
2017-12-15 11:32:08 -05:00
|
|
|
return t, nil
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := t.LoadProcess(ctx, processID, nil)
|
|
|
|
if err != nil {
|
|
|
|
if containerderrors.IsNotFound(err) {
|
|
|
|
return nil, errors.WithStack(errdefs.NotFound(errors.New("no such exec")))
|
|
|
|
}
|
|
|
|
return nil, wrapError(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
return p, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// createIO creates the io to be used by a process
|
|
|
|
// This needs to get a pointer to interface as upon closure the process may not have yet been registered
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
func (c *client) createIO(fifos *cio.FIFOSet, containerID, processID string, stdinCloseSync chan struct{}, attachStdio libcontainerdtypes.StdioCallback) (cio.IO, error) {
|
2018-05-31 20:03:28 -04:00
|
|
|
var (
|
|
|
|
io *cio.DirectIO
|
|
|
|
err error
|
|
|
|
)
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
io, err = c.newDirectIO(context.Background(), fifos)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
|
|
|
|
if io.Stdin != nil {
|
|
|
|
var (
|
|
|
|
err error
|
|
|
|
stdinOnce sync.Once
|
|
|
|
)
|
|
|
|
pipe := io.Stdin
|
|
|
|
io.Stdin = ioutils.NewWriteCloserWrapper(pipe, func() error {
|
|
|
|
stdinOnce.Do(func() {
|
|
|
|
err = pipe.Close()
|
|
|
|
// Do the rest in a new routine to avoid a deadlock if the
|
|
|
|
// Exec/Start call failed.
|
|
|
|
go func() {
|
|
|
|
<-stdinCloseSync
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(context.Background(), containerID, processID)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err == nil {
|
|
|
|
err = p.CloseIO(context.Background(), containerd.WithStdinCloser)
|
|
|
|
if err != nil && strings.Contains(err.Error(), "transport is closing") {
|
|
|
|
err = nil
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}()
|
|
|
|
})
|
|
|
|
return err
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2017-11-29 19:15:20 -05:00
|
|
|
rio, err := attachStdio(io)
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
io.Cancel()
|
|
|
|
io.Close()
|
|
|
|
}
|
2017-11-29 19:15:20 -05:00
|
|
|
return rio, err
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
func (c *client) processEvent(ctx context.Context, et libcontainerdtypes.EventType, ei libcontainerdtypes.EventInfo) {
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
c.eventQ.Append(ei.ContainerID, func() {
|
2017-09-22 09:52:41 -04:00
|
|
|
err := c.backend.ProcessEvent(ei.ContainerID, et, ei)
|
|
|
|
if err != nil {
|
|
|
|
c.logger.WithError(err).WithFields(logrus.Fields{
|
|
|
|
"container": ei.ContainerID,
|
|
|
|
"event": et,
|
|
|
|
"event-info": ei,
|
|
|
|
}).Error("failed to process event")
|
|
|
|
}
|
|
|
|
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
if et == libcontainerdtypes.EventExit && ei.ProcessID != ei.ContainerID {
|
2019-03-25 16:17:17 -04:00
|
|
|
p, err := c.getProcess(ctx, ei.ContainerID, ei.ProcessID)
|
|
|
|
if err != nil {
|
|
|
|
|
2017-09-22 09:52:41 -04:00
|
|
|
c.logger.WithError(errors.New("no such process")).
|
|
|
|
WithFields(logrus.Fields{
|
2019-03-25 16:17:17 -04:00
|
|
|
"error": err,
|
2017-09-22 09:52:41 -04:00
|
|
|
"container": ei.ContainerID,
|
|
|
|
"process": ei.ProcessID,
|
|
|
|
}).Error("exit event")
|
|
|
|
return
|
|
|
|
}
|
2017-12-15 11:32:08 -05:00
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
ctr, err := c.getContainer(ctx, ei.ContainerID)
|
|
|
|
if err != nil {
|
2017-11-13 17:53:56 -05:00
|
|
|
c.logger.WithFields(logrus.Fields{
|
|
|
|
"container": ei.ContainerID,
|
2019-03-25 16:17:17 -04:00
|
|
|
"error": err,
|
2017-11-13 17:53:56 -05:00
|
|
|
}).Error("failed to find container")
|
|
|
|
} else {
|
2019-03-25 16:17:17 -04:00
|
|
|
labels, err := ctr.Labels(ctx)
|
|
|
|
if err != nil {
|
|
|
|
c.logger.WithFields(logrus.Fields{
|
|
|
|
"container": ei.ContainerID,
|
|
|
|
"error": err,
|
2019-06-20 16:21:42 -04:00
|
|
|
}).Error("failed to get container labels")
|
2019-03-25 16:17:17 -04:00
|
|
|
return
|
|
|
|
}
|
|
|
|
newFIFOSet(labels[DockerContainerBundlePath], ei.ProcessID, true, false).Close()
|
2017-11-13 17:53:56 -05:00
|
|
|
}
|
2019-06-20 16:21:42 -04:00
|
|
|
_, err = p.Delete(context.Background())
|
|
|
|
if err != nil {
|
|
|
|
c.logger.WithError(err).WithFields(logrus.Fields{
|
|
|
|
"container": ei.ContainerID,
|
|
|
|
"process": ei.ProcessID,
|
|
|
|
}).Warn("failed to delete process")
|
|
|
|
}
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2018-05-23 15:15:21 -04:00
|
|
|
func (c *client) processEventStream(ctx context.Context, ns string) {
|
2017-09-22 09:52:41 -04:00
|
|
|
var (
|
2018-04-18 17:55:50 -04:00
|
|
|
err error
|
|
|
|
ev *events.Envelope
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
et libcontainerdtypes.EventType
|
|
|
|
ei libcontainerdtypes.EventInfo
|
2017-09-22 09:52:41 -04:00
|
|
|
)
|
|
|
|
|
2018-04-18 17:55:50 -04:00
|
|
|
// Filter on both namespace *and* topic. To create an "and" filter,
|
|
|
|
// this must be a single, comma-separated string
|
2018-05-23 15:15:21 -04:00
|
|
|
eventStream, errC := c.client.EventService().Subscribe(ctx, "namespace=="+ns+",topic~=|^/tasks/|")
|
2017-09-22 09:52:41 -04:00
|
|
|
|
2018-05-23 15:15:21 -04:00
|
|
|
c.logger.Debug("processing event stream")
|
2018-01-31 17:32:40 -05:00
|
|
|
|
2017-09-22 09:52:41 -04:00
|
|
|
for {
|
2019-03-25 16:17:17 -04:00
|
|
|
var oomKilled bool
|
2018-04-18 17:55:50 -04:00
|
|
|
select {
|
|
|
|
case err = <-errC:
|
|
|
|
if err != nil {
|
|
|
|
errStatus, ok := status.FromError(err)
|
|
|
|
if !ok || errStatus.Code() != codes.Canceled {
|
|
|
|
c.logger.WithError(err).Error("failed to get event")
|
2019-07-12 18:29:57 -04:00
|
|
|
|
|
|
|
// rate limit
|
|
|
|
select {
|
|
|
|
case <-time.After(time.Second):
|
|
|
|
go c.processEventStream(ctx, ns)
|
|
|
|
return
|
|
|
|
case <-ctx.Done():
|
|
|
|
}
|
2018-04-18 17:55:50 -04:00
|
|
|
}
|
2019-07-12 18:29:57 -04:00
|
|
|
c.logger.WithError(ctx.Err()).Info("stopping event stream following graceful shutdown")
|
2017-11-14 17:00:47 -05:00
|
|
|
}
|
2017-09-22 09:52:41 -04:00
|
|
|
return
|
2018-04-18 17:55:50 -04:00
|
|
|
case ev = <-eventStream:
|
|
|
|
if ev.Event == nil {
|
|
|
|
c.logger.WithField("event", ev).Warn("invalid event")
|
|
|
|
continue
|
|
|
|
}
|
2017-09-22 09:52:41 -04:00
|
|
|
|
2018-04-18 17:55:50 -04:00
|
|
|
v, err := typeurl.UnmarshalAny(ev.Event)
|
|
|
|
if err != nil {
|
|
|
|
c.logger.WithError(err).WithField("event", ev).Warn("failed to unmarshal event")
|
|
|
|
continue
|
|
|
|
}
|
2017-09-22 09:52:41 -04:00
|
|
|
|
2018-04-18 17:55:50 -04:00
|
|
|
c.logger.WithField("topic", ev.Topic).Debug("event")
|
2017-09-22 09:52:41 -04:00
|
|
|
|
2018-04-18 17:55:50 -04:00
|
|
|
switch t := v.(type) {
|
|
|
|
case *apievents.TaskCreate:
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
et = libcontainerdtypes.EventCreate
|
|
|
|
ei = libcontainerdtypes.EventInfo{
|
2018-04-18 17:55:50 -04:00
|
|
|
ContainerID: t.ContainerID,
|
|
|
|
ProcessID: t.ContainerID,
|
|
|
|
Pid: t.Pid,
|
|
|
|
}
|
|
|
|
case *apievents.TaskStart:
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
et = libcontainerdtypes.EventStart
|
|
|
|
ei = libcontainerdtypes.EventInfo{
|
2018-04-18 17:55:50 -04:00
|
|
|
ContainerID: t.ContainerID,
|
|
|
|
ProcessID: t.ContainerID,
|
|
|
|
Pid: t.Pid,
|
|
|
|
}
|
|
|
|
case *apievents.TaskExit:
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
et = libcontainerdtypes.EventExit
|
|
|
|
ei = libcontainerdtypes.EventInfo{
|
2018-04-18 17:55:50 -04:00
|
|
|
ContainerID: t.ContainerID,
|
|
|
|
ProcessID: t.ID,
|
|
|
|
Pid: t.Pid,
|
|
|
|
ExitCode: t.ExitStatus,
|
|
|
|
ExitedAt: t.ExitedAt,
|
|
|
|
}
|
|
|
|
case *apievents.TaskOOM:
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
et = libcontainerdtypes.EventOOM
|
|
|
|
ei = libcontainerdtypes.EventInfo{
|
2018-04-18 17:55:50 -04:00
|
|
|
ContainerID: t.ContainerID,
|
|
|
|
OOMKilled: true,
|
|
|
|
}
|
|
|
|
oomKilled = true
|
|
|
|
case *apievents.TaskExecAdded:
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
et = libcontainerdtypes.EventExecAdded
|
|
|
|
ei = libcontainerdtypes.EventInfo{
|
2018-04-18 17:55:50 -04:00
|
|
|
ContainerID: t.ContainerID,
|
|
|
|
ProcessID: t.ExecID,
|
|
|
|
}
|
|
|
|
case *apievents.TaskExecStarted:
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
et = libcontainerdtypes.EventExecStarted
|
|
|
|
ei = libcontainerdtypes.EventInfo{
|
2018-04-18 17:55:50 -04:00
|
|
|
ContainerID: t.ContainerID,
|
|
|
|
ProcessID: t.ExecID,
|
|
|
|
Pid: t.Pid,
|
|
|
|
}
|
|
|
|
case *apievents.TaskPaused:
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
et = libcontainerdtypes.EventPaused
|
|
|
|
ei = libcontainerdtypes.EventInfo{
|
2018-04-18 17:55:50 -04:00
|
|
|
ContainerID: t.ContainerID,
|
|
|
|
}
|
|
|
|
case *apievents.TaskResumed:
|
Windows: Experimental: Allow containerd for runtime
Signed-off-by: John Howard <jhoward@microsoft.com>
This is the first step in refactoring moby (dockerd) to use containerd on Windows.
Similar to the current model in Linux, this adds the option to enable it for runtime.
It does not switch the graphdriver to containerd snapshotters.
- Refactors libcontainerd to a series of subpackages so that either a
"local" containerd (1) or a "remote" (2) containerd can be loaded as opposed
to conditional compile as "local" for Windows and "remote" for Linux.
- Updates libcontainerd such that Windows has an option to allow the use of a
"remote" containerd. Here, it communicates over a named pipe using GRPC.
This is currently guarded behind the experimental flag, an environment variable,
and the providing of a pipename to connect to containerd.
- Infrastructure pieces such as under pkg/system to have helper functions for
determining whether containerd is being used.
(1) "local" containerd is what the daemon on Windows has used since inception.
It's not really containerd at all - it's simply local invocation of HCS APIs
directly in-process from the daemon through the Microsoft/hcsshim library.
(2) "remote" containerd is what docker on Linux uses for it's runtime. It means
that there is a separate containerd service running, and docker communicates over
GRPC to it.
To try this out, you will need to start with something like the following:
Window 1:
containerd --log-level debug
Window 2:
$env:DOCKER_WINDOWS_CONTAINERD=1
dockerd --experimental -D --containerd \\.\pipe\containerd-containerd
You will need the following binary from github.com/containerd/containerd in your path:
- containerd.exe
You will need the following binaries from github.com/Microsoft/hcsshim in your path:
- runhcs.exe
- containerd-shim-runhcs-v1.exe
For LCOW, it will require and initrd.img and kernel in `C:\Program Files\Linux Containers`.
This is no different to the current requirements. However, you may need updated binaries,
particularly initrd.img built from Microsoft/opengcs as (at the time of writing), Linuxkit
binaries are somewhat out of date.
Note that containerd and hcsshim for HCS v2 APIs do not yet support all the required
functionality needed for docker. This will come in time - this is a baby (although large)
step to migrating Docker on Windows to containerd.
Note that the HCS v2 APIs are only called on RS5+ builds. RS1..RS4 will still use
HCS v1 APIs as the v2 APIs were not fully developed enough on these builds to be usable.
This abstraction is done in HCSShim. (Referring specifically to runtime)
Note the LCOW graphdriver still uses HCS v1 APIs regardless.
Note also that this does not migrate docker to use containerd snapshotters
rather than graphdrivers. This needs to be done in conjunction with Linux also
doing the same switch.
2019-01-08 17:30:52 -05:00
|
|
|
et = libcontainerdtypes.EventResumed
|
|
|
|
ei = libcontainerdtypes.EventInfo{
|
2018-04-18 17:55:50 -04:00
|
|
|
ContainerID: t.ContainerID,
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
c.logger.WithFields(logrus.Fields{
|
|
|
|
"topic": ev.Topic,
|
|
|
|
"type": reflect.TypeOf(t)},
|
|
|
|
).Info("ignoring event")
|
|
|
|
continue
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
2018-04-18 17:55:50 -04:00
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
c.oomMu.Lock()
|
2018-04-18 17:55:50 -04:00
|
|
|
if oomKilled {
|
2019-03-25 16:17:17 -04:00
|
|
|
c.oom[ei.ContainerID] = true
|
2018-04-18 17:55:50 -04:00
|
|
|
}
|
2019-03-25 16:17:17 -04:00
|
|
|
ei.OOMKilled = c.oom[ei.ContainerID]
|
|
|
|
c.oomMu.Unlock()
|
2017-09-22 09:52:41 -04:00
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
c.processEvent(ctx, et, ei)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (c *client) writeContent(ctx context.Context, mediaType, ref string, r io.Reader) (*types.Descriptor, error) {
|
2018-05-23 15:15:21 -04:00
|
|
|
writer, err := c.client.ContentStore().Writer(ctx, content.WithRef(ref))
|
2017-09-22 09:52:41 -04:00
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
defer writer.Close()
|
|
|
|
size, err := io.Copy(writer, r)
|
|
|
|
if err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
labels := map[string]string{
|
|
|
|
"containerd.io/gc.root": time.Now().UTC().Format(time.RFC3339),
|
|
|
|
}
|
|
|
|
if err := writer.Commit(ctx, 0, "", content.WithLabels(labels)); err != nil {
|
|
|
|
return nil, err
|
|
|
|
}
|
|
|
|
return &types.Descriptor{
|
|
|
|
MediaType: mediaType,
|
|
|
|
Digest: writer.Digest(),
|
|
|
|
Size_: size,
|
|
|
|
}, nil
|
|
|
|
}
|
|
|
|
|
2019-03-25 16:17:17 -04:00
|
|
|
func (c *client) bundleDir(id string) string {
|
|
|
|
return filepath.Join(c.stateDir, id)
|
|
|
|
}
|
|
|
|
|
2017-09-22 09:52:41 -04:00
|
|
|
func wrapError(err error) error {
|
2017-12-15 10:00:15 -05:00
|
|
|
switch {
|
2018-01-04 16:12:23 -05:00
|
|
|
case err == nil:
|
|
|
|
return nil
|
2017-11-28 23:09:37 -05:00
|
|
|
case containerderrors.IsNotFound(err):
|
|
|
|
return errdefs.NotFound(err)
|
2017-12-15 10:00:15 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
msg := err.Error()
|
|
|
|
for _, s := range []string{"container does not exist", "not found", "no such container"} {
|
|
|
|
if strings.Contains(msg, s) {
|
2017-11-28 23:09:37 -05:00
|
|
|
return errdefs.NotFound(err)
|
2017-09-22 09:52:41 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return err
|
|
|
|
}
|