Ctr

Шпаргалка

Namespaces

Все происходит в namespace - контейнеры, образы, все. По-тому всегда нужно указывать namespace

ctr  ns  list
NAME           LABELS
com.docker.ucp
k8s.io
moby

Для примера: без указания namespace

ctr image ls
REF TYPE DIGEST SIZE PLATFORMS LABELS

С указанием namespace com.docker.ucp

ctr -n  com.docker.ucp  image ls
REF                                                   TYPE                                                 DIGEST                                                                  SIZE      PLATFORMS   LABELS
docker.io/mirantis/ucp-containerd-shim-process:3.7.17 application/vnd.docker.distribution.manifest.v2+json sha256:6bf941185fed1680ac0b62a690817490350301ac0b35fd35532c2b231366dc5f 18.1 MiB  linux/amd64 -
docker.io/mirantis/ucp-hyperkube:3.7.17               application/vnd.docker.distribution.manifest.v2+json sha256:0dcdec0617b4ddd212d87fdcace834ac81c644cb85e2c4958f07c7c01cd05a2a 695.1 MiB linux/amd64 -

1

One of the main differences between ctr and docker UX is that the former requires doing more things explicitly and doesn't allow you to take (many) shortcuts. For instance, with docker, you can run a container without explicitly pulling its image first. With ctr though, you'll have to pull the image (specifying its full name, including the registry and the tag parts) and only then invoke the ctr run command.

Compare the de-facto standard docker run nginx with the following ctr equivalent:

sudo ctr run docker.io/library/hello-world:latest hello1 Copy to clipboard

You may want to ctr image pull the image first 😉

sudo ctr image pull docker.io/library/hello-world:latest Copy to clipboard

Start playground to activate this check Notice that unlike user-friendly docker run that generates a unique ID for every container, with ctr, you must supply a container ID yourself (hello1 in the above example).

The ctr run command resembles the docker run command but it doesn't support all the flags you may be used to. For instance, you won't be able to publish container ports or do something like --restart=always. But it also can do things that docker run can't, can you find some? 😉

Back to basic container operations, you can list existing containers with:

sudo ctr container ls Copy to clipboard

You can also inspect a container with ctr container info <container-id>:

sudo ctr container info hello1 Copy to clipboard

Finally, you can remove a container with ctr container remove <container-id>. Let's remove the hello1 container we've created earlier:

sudo ctr container remove hello1 Copy to clipboard

Start playground to activate this check Note that you can remove only containers that aren't running.

2

Interesting that the ctr run command is actually a shortcut! It's a combination of ctr container create and ctr task start. Let's explore this behavior:

1. Don't forget to pull the image!

sudo ctr container create docker.io/library/nginx:alpine nginx1 Copy to clipboard

Start playground to activate this check If you list the containers ctr container ls, the output will be similar to the following:

CONTAINER IMAGE RUNTIME nginx1 docker.io/library/nginx:alpine io.containerd.runc.v2 Copy to clipboard

However, checking the running processes with pgrep nginx will return nothing:

pgrep nginx

1. <empty output>

Copy to clipboard

As you can see, the container is created but no process is running inside it yet.

To make the Nginx container actually run, you'll need to start a task:

sudo ctr task start --detach nginx1 Copy to clipboard

Start playground to activate this check If you list the tasks now:

sudo ctr task ls Copy to clipboard

...the output should be similar to the following:

TASK PID STATUS nginx1 39928 RUNNING Copy to clipboard

I like this separation of container and task subcommands because it reflects the often forgotten nature of OCI containers. Despite the common belief, containers aren't processes - containers are isolated and restricted execution environments for processes. So, in containerd, a container seems to be a configuration entity that describes the execution environment, while tasks represent the actual processes running inside of containers.

🤓 Note that at least with ctr it doesn't seem to be possible to have multiple tasks running for the same container simultaneously. You can always stop the running task and then start another one for the same container, but you can't have two tasks running at the same time. In particular, it means that the task management commands we'll see below accept container IDs as arguments, not task IDs.

3

The nginx1 task from the previous section runs in the background because the ctr task start command was used with the --detach flag. To see the stdout and stderr of a running task, you can attach to it with ctr task attach <container-id>. Let's try attaching to the nginx1 task:

sudo ctr task attach nginx1 Copy to clipboard

Start playground to activate this check The output should be similar to the following:

... 2023/05/06 18:48:22 [notice] 1#1: using the "epoll" event method 2023/05/06 18:48:22 [notice] 1#1: nginx/1.23.4 2023/05/06 18:48:22 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6) 2023/05/06 18:48:22 [notice] 1#1: OS: Linux 5.10.175 2023/05/06 18:48:22 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1024:1024 2023/05/06 18:48:22 [notice] 1#1: start worker processes 2023/05/06 18:48:22 [notice] 1#1: start worker process 29 2023/05/06 18:48:22 [notice] 1#1: start worker process 30 Copy to clipboard

But be careful, the ctr task attach command will also reconnect the stdin stream and start forwarding signals from the controlling terminal to the task processes, so hitting Ctrl+C might kill the task.

Start playground to activate this check Unfortunately, ctr doesn't support the Ctrl+P+Q shortcut to detach from a task - it's solely docker's feature. There is also no ctr task logs, so you can't see the stdout/stderr of a task without attaching to it. Neither can you easily see the logs of a stopped task. It's a lower-level tool, remember? 😉

4

Much like in Docker, you can execute a command in a running container. Let's revive the nginx1 task and execute a command inside the Nginx container:

sudo ctr task start --detach nginx1 Copy to clipboard

Start playground to activate this check Here's how you can get an interactive shell inside the nginx1 container using ctr task exec:

sudo ctr task exec -t --exec-id shell1 nginx1 sh Copy to clipboard

Start playground to activate this check When you're done exploring the inside of the container, you can exit the shell ending the shell1 exec session:

Start playground to activate this check You can also execute a single command inside the container without getting an interactive shell. For instance, here's how you can curl the Nginx container from the host:

sudo ctr task exec --exec-id curl1 nginx1 curl 127.0.0.1:80 Copy to clipboard

The output will be the standard Nginx welcome page:

<!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> ...

5

It's also possible to send signals to tasks, or rather to the processes running inside the tasks. For instance, here is how you can send a SIGTERM signal to the Nginx process, effectively terminating it:

sudo ctr task kill -s 9 nginx1 Copy to clipboard

Start playground to activate this check Interesting that when all container processes are terminated, the task may still exist:

sudo ctr task ls Copy to clipboard

TASK PID STATUS nginx1 2756 STOPPED Copy to clipboard

However, the ctr task ps nginx1 command will show that there are no processes running inside the task.

If your only goal for sending a signal is to terminate the task before removal, there might be a faster way to remove a running task - using the ctr task rm command with the --force flag. In any case, let's clean things up and remove the stopped nginx1 task:

sudo ctr task rm nginx1 Copy to clipboard

Start playground to activate this check

Список контейнеров

Без указания namespace

ctr containers ls

Без указания namespace

ctr -n k8s.io containers list

1

ctr images pull docker.io/library/nginx:1.21 $ ctr images pull docker.io/kennethreitz/httpbin:latest $ ctr images pull docker.io/kennethreitz/httpbin:latest $ ctr images pull quay.io/quay/redis:latest To list local images, one can use:

$ ctr images ls

$ docker build -t my-app . $ docker save -o my-app.tar my-app

$ ctr images import my-app.tar

$ mkdir /tmp/httpbin $ ctr images mount docker.io/kennethreitz/httpbin:latest /tmp/httpbin

$ ls -l /tmp/httpbin/ total 80 drwxr-xr-x 2 root root 4096 Oct 18 2018 bin drwxr-xr-x 2 root root 4096 Apr 24 2018 boot drwxr-xr-x 4 root root 4096 Oct 18 2018 dev drwxr-xr-x 1 root root 4096 Oct 24 2018 etc drwxr-xr-x 2 root root 4096 Apr 24 2018 home drwxr-xr-x 3 root root 4096 Oct 24 2018 httpbin ...

$ ctr images unmount /tmp/httpbin

ctr run --rm -t docker.io/library/debian:latest cont1

Ссылки

https://iximiuz.com/en/posts/containerd-command-line-clients/