This change adds support for CDI devices to the ctr --device flag.
If a fully-qualified CDI device name is specified, this is injected
into the OCI specification before creating the container.
Note that the CDI specifications and the devices that they represent
are local and mirror the behaviour of linux devices in the ctr command.
Signed-off-by: Evan Lezar <elezar@nvidia.com>
This flag allows cpuset.mems to be specified when running a container. If
provided, the container will use only the defined memory nodes.
Signed-off-by: Peteris Rudzusiks <rye@stripe.com>
This flag allows cpuset.cpus to be specified when starting a container. If
provided, the container will use only the defined CPU cores.
Signed-off-by: Peteris Rudzusiks <rye@stripe.com>
If a mount destination is specified both in the default spec and in a
--mount option, remove the default mount before adding new mounts. This
allows overriding the default sysfs mount, for example.
Signed-off-by: Samuel Karp <samuelkarp@google.com>
From golangci-lint:
> SA1019: rand.Read has been deprecated since Go 1.20 because it
>shouldn't be used: For almost all use cases, crypto/rand.Read is more
>appropriate. (staticcheck)
> SA1019: rand.Seed has been deprecated since Go 1.20 and an alternative
>has been available since Go 1.0: Programs that call Seed and then expect
>a specific sequence of results from the global random source (using
>functions such as Int) can be broken when a dependency changes how
>much it consumes from the global random source. To avoid such breakages,
>programs that need a specific result sequence should use
>NewRand(NewSource(seed)) to obtain a random generator that other
>packages cannot access. (staticcheck)
See also:
- https://pkg.go.dev/math/rand@go1.20#Read
- https://pkg.go.dev/math/rand@go1.20#Seed
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
The `ctr image usage` can display the usage of snapshots with a given
image ref. It's easy for user to get chain snapshot IDs and unpack
usage. And according to the [discuss][1], this subcommand can be used to
ensure if snapshot's pagecache has been discarded in a unexpected
reboot.
How to use it:
```bash
$ bin/ctr image usage --snapshotter native docker.io/library/golang:1.19.3
ctr: image docker.io/library/golang:1.19.3 isn't unpacked in snapshotter native
$ bin/ctr image usage --snapshotter overlayfs docker.io/library/golang:1.19.3
KEY SIZE INODES
sha256:28114d8403bac6352c3e09cb23e37208138a0cd9d309edf3df38e57be8075a1d 16.0 KiB 4
sha256:f162c02ce6b9b594757cd76eda1c1dd119b88e69e882cb645bf7ad528b54f0d2 476.2 MiB 13660
sha256:a5b9faceaa495819b9ba7011b7276c4ffaffe6c7b9de0889e11abc1113f7b5ca 225.5 MiB 3683
sha256:412b2615d27d6b0090558d25b201b60a7dff2a40892a7e7ca868b80bf5e5de41 159.8 MiB 6196
sha256:dbce1593502d39c344ce089f98187999f294de5182a7106dcb6c9d04ce0c7265 19.4 MiB 502
sha256:8953bf5d24149e9b2236abc76bd0aa14b73828f1b63e816cb4b457249f6125bc 12.2 MiB 958
sha256:ccba29d6937047c719a6c048a7038d3907590fbb8556418d119469b2ad4f95bc 134.7 MiB 7245
$ bin/ctr image usage --snapshotter overlayfs docker.io/library/golang:1.19
ctr: failed to ensure if image docker.io/library/golang:1.19 exists: image "docker.io/library/golang:1.19": not found
```
[1]: <https://github.com/containerd/containerd/issues/5854#issuecomment-1415915765>
Signed-off-by: Wei Fu <fuweid89@gmail.com>
- Add Target to mount.Mount.
- Add UnmountMounts to unmount a list of mounts in reverse order.
- Add UnmountRecursive to unmount deepest mount first for a given target, using
moby/sys/mountinfo.
Signed-off-by: Edgar Lee <edgarhinshunlee@gmail.com>
This adds in a simple flag to control what platform the spec it generates
is for. Useful to easily get a glance at whats the default across platforms.
Signed-off-by: Danny Canter <danny@dcantah.dev>
Moves the sandbox store plugin under the plugins packages and adds a
unique plugin type for other plugins to depend on it.
Updates the sandbox controller plugin to depend on the sandbox store
plugin.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Adds a service capable of streaming Any objects bi-directionally.
This can be used by services to send data, received data, or to
initiate requests from server to client.
Signed-off-by: Derek McGowan <derek@mcg.dev>
Add a common NRI 'service' plugin. It takes care of relaying
requests and respones to and from NRI (external NRI plugins)
and the high-level containerd namespace-independent logic of
applying NRI container adjustments and updates to actual CRI
and other containers.
The namespace-dependent details of the necessary container
manipulation operations are to be implemented by namespace-
specific adaptations. This NRI plugin defines the API which
such adaptations need to implement.
Signed-off-by: Krisztian Litkey <krisztian.litkey@intel.com>
Go 1.18 and up now provides a strings.Cut() which is better suited for
splitting key/value pairs (and similar constructs), and performs better:
```go
func BenchmarkSplit(b *testing.B) {
b.ReportAllocs()
data := []string{"12hello=world", "12hello=", "12=hello", "12hello"}
for i := 0; i < b.N; i++ {
for _, s := range data {
_ = strings.SplitN(s, "=", 2)[0]
}
}
}
func BenchmarkCut(b *testing.B) {
b.ReportAllocs()
data := []string{"12hello=world", "12hello=", "12=hello", "12hello"}
for i := 0; i < b.N; i++ {
for _, s := range data {
_, _, _ = strings.Cut(s, "=")
}
}
}
```
BenchmarkSplit
BenchmarkSplit-10 8244206 128.0 ns/op 128 B/op 4 allocs/op
BenchmarkCut
BenchmarkCut-10 54411998 21.80 ns/op 0 B/op 0 allocs/op
While looking at occurrences of `strings.Split()`, I also updated some for alternatives,
or added some constraints; for cases where an specific number of items is expected, I used `strings.SplitN()`
with a suitable limit. This prevents (theoretical) unlimited splits.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
golang.org/x/sys/windows now implements this, so we can use that
instead of a local implementation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
GOGC=75 golangci-lint run
services/server/server.go:320:27: G114: Use of net/http serve function that has no support for setting timeouts (gosec)
return trapClosedConnErr(http.Serve(l, m))
^
services/server/server.go:340:27: G114: Use of net/http serve function that has no support for setting timeouts (gosec)
return trapClosedConnErr(http.Serve(l, m))
^
cmd/containerd-stress/main.go:238:13: G114: Use of net/http serve function that has no support for setting timeouts (gosec)
if err := http.ListenAndServe(c.Metrics, metrics.Handler()); err != nil {
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `IsAnInteractiveSession` was deprecated, and `IsWindowsService` is marked
as the recommended replacement.
For details, see 280f808b4a
> CL 244958 includes isWindowsService function that determines if a
> process is running as a service. The code of the function is based on
> public .Net implementation.
>
> IsAnInteractiveSession function implements similar functionality, but
> is based on an old Stackoverflow post., which is not as authoritative
> as code written by Microsoft for their official product.
>
> This change copies CL 244958 isWindowsService function into svc package
> and makes it public. The intention is that future users will prefer
> IsWindowsService to IsAnInteractiveSession.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This makes diff archives to be reproducible.
The value is expected to be passed from CLI applications via the $SOUCE_DATE_EPOCH env var.
See https://reproducible-builds.org/docs/source-date-epoch/
for the $SOURCE_DATE_EPOCH specification.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
In Go 1.16 `net.ErrClosed` was exported, removing the need to check the
exact text of "use of closed network connection". The stdlib's net listeners
are all setup for this to be a reality, but on Windows containerd uses the
the go-winio projects named pipe implementation as the listener for services.
Before version 0.6.0 this project returned a different error named
`ErrPipeListenerClosed` for using a closed pipe, where this error was just
an `errors.New` with the same text as `net.ErrClosed`, so checking against
`net.ErrClosed` wasn't possible.
Starting in 0.6.0 go-winio has that error assigned to `net.ErrClosed` directly
so this *should* be alright to finally change.
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
Add a new ctr cli option, allowing the garbage collector to discard any
unpacked layers after importing an image. This new option is
incompatible with the no-unpack ctr import option.
Signed-off-by: James Jenkins <James.Jenkins@ibm.com>
For Kata Containers, starting a privileged container will fail
if passing all host devices to container due to the permission
issue, like the `privileged_without_host_devices` for CRI service,
add a `privileged-without-host-devices` to `ctr run` command will
disable passing all host devices to containers.
Signed-off-by: bin liu <liubin0329@gmail.com>
Previously we were reassigning os.Stderr to the panic.log file we create
when getting asked to run Containerd as a Windows service. The panic.log
file was used as a means to easily collect panic stacks as Windows
services don't have regular standard IO, and the usual recommendation
is to either write to the event log or just to a file in the case of
running as a service.
One place where this panic.log flow was biting us was with shim logging,
which is forwarded from the shim and copied to os.Stderr directly which was
causing shim logs to get forwarded to this panic.log file instead of just
panics. We expose an additional `--log-file` flag if you ask to run a
windows service which is the main way you'd get Containerd logs, and with
this change all of the shim logging which would today end up in panic.log
will now also go to this log file.
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
Added new runc shim binary in integration testing.
The shim is named by io.containerd.runc-fp.v1, which allows us to use
additional OCI annotation `io.containerd.runtime.v2.shim.failpoint.*` to
setup shim task API's failpoint. Since the shim can be shared with
multiple container, like what kubernetes pod does, the failpoint will be
initialized during setup the shim server. So, the following the
container's OCI failpoint's annotation will not work.
This commit also updates the ctr tool that we can use `--annotation` to
specify annotations when run container. For example:
```bash
➜ ctr run -d --runtime runc-fp.v1 \
--annotation "io.containerd.runtime.v2.shim.failpoint.Kill=1*error(sorry)" \
docker.io/library/alpine:latest testing sleep 1d
➜ ctr t ls
TASK PID STATUS
testing 147304 RUNNING
➜ ctr t kill -s SIGKILL testing
ctr: sorry: unknown
➜ ctr t kill -s SIGKILL testing
➜ sudo ctr t ls
TASK PID STATUS
testing 147304 STOPPED
```
The runc-fp.v1 shim is based on core runc.v2. We can use it to inject
failpoint during testing complicated or big transcation API, like
kubernetes PodRunPodsandbox.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Introduce a --cri flag, which will enable running container-stress using the CRI,
instead of containerd's task API.
In doing so, we introduce cri_worker, rename the existing worker to ctr_worker, and introduce
a worker interface that each of these implement.
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
"ctr s r" help suggests <pod-config.json> is taken as the first
parameter and the sandbox ID becomes next. However, only the latter
is read and used.
Add code that reads <pod-config.json> and passes it to Sanbox.
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Currently, ctr import will use loose matching as defined by
platforms.Only(), meaning in the case of platform linux/amd64 as in
issue#6441, importing will also match linux/386 platform on the
image-to-be-imported's index. However, that image-to-be-imported may not
have both the linux/amd64 and linux/386 platform contents, resulting in
a failure to unpack the image. This change makes that check strict such
that the requested platform to import for is the only platform content
imported. Both ctr pull and ctr export will treat the platform option as
strict, so this change makes ctr import consistent with those.
resolves#6441
Signed-off-by: Gavin Inglis <giinglis@amazon.com>
Schema 1 has been substantially deprecated since circa. 2017 in favor of Schema 2 introduced in Docker 1.10 (Feb 2016)
and its successor OCI Image Spec v1, but we have not officially deprecated Schema 1.
One of the reasons was that Quay did not support Schema 2 so far, but it is reported that Quay has been
supporting Schema 2 since Feb 2020 (moby/buildkit issue 409).
This PR deprecates pulling Schema 1 images but the feature will not be removed before containerd 2.0.
Pushing Schema 1 images was never implemented in containerd (and its consumers such as BuildKit).
Docker/Moby already disabled pushing Schema 1 images in Docker 20.10 (moby/moby PR 41295),
but Docker/Moby has not yet disabled pulling Schema 1 as containerd has not yet deprecated Schema 1.
(See the comments in moby/moby PR 42300.)
Docker/Moby is expected to disable pulling Schema 1 images in future after this deprecation.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
