|
| 1 | +# CVMFS Containerd Snapshotter |
| 2 | + |
| 3 | +**It requires containerd >= 1.4.0-beta.1** |
| 4 | + |
| 5 | +This repository contains a containerd snapshotter that exploits the CernVM-FS to provide the filesystem for the containers. |
| 6 | + |
| 7 | +## Background |
| 8 | + |
| 9 | +From version 1.4.0, containerd introduce the concept of remote snapshotter. |
| 10 | +It allows starting containers in which the filesystem is provided externally from the containerd machinery. |
| 11 | +Without the need to download all the layers for each image. And getting rid of the pulling time. |
| 12 | + |
| 13 | +We exploit this new capability to mount OCI layers directly from a filesystem on the local machine. |
| 14 | +We focus on layers provided by CernVM-FS, but with minor changes is possible to mount layers from any filesystem, like NFS. |
| 15 | + |
| 16 | +Overall this new mechanism should bring down the time to start-up a new container image. |
| 17 | + |
| 18 | +If the layers are not in the local filesystem, `containerd` simply follow the standard path and download the tarball. |
| 19 | + |
| 20 | +## Configuration |
| 21 | + |
| 22 | +This remote snapshotter communicates with `containerd` via gRPC over linux socket. |
| 23 | +The default socket is `/run/containerd-cvmfs-grpc/containerd-cvmfs-grpc.sock`. |
| 24 | +The socket is created automatically by the snapshotter if it does not exists. |
| 25 | + |
| 26 | +It is necessary to configure containerd to use this new remote snapshotter. |
| 27 | +A basic configuration would look like: |
| 28 | + |
| 29 | +``` |
| 30 | +# tell containerd to use this particular snapshotter |
| 31 | +[plugins."io.containerd.grpc.v1.cri".containerd] |
| 32 | + snapshotter = "cvmfs-snapshotter" |
| 33 | +
|
| 34 | +# tell containerd how to communicate with this snapshotter |
| 35 | +[proxy_plugins] |
| 36 | + [proxy_plugins.cvmfs-snapshotter] |
| 37 | + type = "snapshot" |
| 38 | + address = "/run/containerd-cvmfs-grpc/containerd-cvmfs-grpc.sock" |
| 39 | +``` |
| 40 | + |
| 41 | +## Work in progress |
| 42 | + |
| 43 | +This snapshotter is still a work in progress. |
| 44 | + |
| 45 | +Feel free to fill issues and pull requests. |
| 46 | + |
| 47 | +## Testing |
| 48 | + |
| 49 | +This plugin is tested using `kind`. |
| 50 | + |
| 51 | +``` |
| 52 | +$ docker build -t cvmfs-kind-node https://github.com/cvmfs/containerd-remote-snapshotter.git |
| 53 | +$ cat kind-mount-cvmfs.yaml |
| 54 | +kind: Cluster |
| 55 | +apiVersion: kind.x-k8s.io/v1alpha4 |
| 56 | +nodes: |
| 57 | +- role: control-plane |
| 58 | + extraMounts: |
| 59 | + - hostPath: /cvmfs/unpacked.cern.ch |
| 60 | + containerPath: /cvmfs/unpacked.cern.ch |
| 61 | +
|
| 62 | +$ kind create cluster --config kind-mount-cvmfs.yaml --image cvmfs-kind-node |
| 63 | +``` |
| 64 | + |
| 65 | +At this point, it is possible to use `kubectl` to start containers. |
| 66 | +If the filesystem of the container is available on the local filesystem used by the plugin, it won't download the tarball, but just mount the local filesystem. |
| 67 | + |
| 68 | +### Many thanks |
| 69 | + |
| 70 | +Thanks to @ktock and the containerd community for the work on a similar plugin and API. |
| 71 | + |
| 72 | +[https://github.com/containerd/stargz-snapshotter/](https://github.com/containerd/stargz-snapshotter/) |
0 commit comments