Publish sample plugin container images

[marquiz]

This is a minimal PR for enabling building and pushing container images for the sample plugins.

Contains two parts:

1. Add Dockerfile for building images
   Add a generic dockerfile for building container images of the sample plugins. The build command creates statically linked binaries and the resulting images are minimal, based on scratch base image.

2. Add github workflow for publishing container images
   Publish multiarch container images of the sample plugins at ghcr.io/containerd/nri/plugins/:.

   The tag is the git tag name for tagged versions and "unstable" for the main branch.

   The default-validator and wasm plugins are skipped in the config. The default-validator plugin is not runnable as an external plugin and the wasm plugin cannot be run from a container.

Refs #190

NOTE: workflow tested in my personal repo https://github.com/marquiz?tab=packages&repo_name=nri

[klihub]

@marquiz This looks pretty good.

For me the main remaining question is whether this is useful enough already as such, or if we should consider adding either a sample deployment file or a Helm chart for the built plugins. There are some extra bits from the host containerized plugins need to function, so it could be useful to provide a bit more sugar-coating for the sample plugins.

All plugins need access to the NRI socket from the host to be able to run containerized. Additionally some of the plugins need access to extra bits from the host to be able to function. For instance, the hook-injector plugin needs access at least to /etc/containers/oci/hooks.d for the hook manager to work. The v010-adapter needs access to at least to the original 0.1.0-specific /etc/nri/conf.json configuration file and /opt/nri/bin plugin binary directory.

[klihub]

@marquiz This looks pretty good.

For me the main remaining question is whether...
There are some extra bits from the host containerized plugins need to function, so it could be useful to provide a bit more sugar-coating for the sample plugins.
...

@marquiz But as we discussed offline, it is probably better to just handle image building with this PR and file a new one for anything else we come up with.

[pwhack]

I'm quite keen to follow the development of this effort because I'm affected by the containerd 2.0 reduced limits in GKE. Last night I attempted to deploy a DaemonSet using @marquiz container image for the ulimit-adjuster plugin but the pods just kept crashing with no log output so I'm clearly not providing it what it needs.

Thank you for working on publishing container images and making the discussion public so I can follow it. :-)

[chrishenzie]

@pwhack The reduced limits in GKE should be fixed, I believe starting in 1.33.2-gke.1043000. It looks like we need to update the docs to supply that version. I'll take a look.

[marquiz]

Reading the comments I split this into multiple PRs. Let's handle image building/publishing here and the other bits elsewhere for (hopefully) easier review:

1. The deployment files are in deployment: add minimal kustomize overlays for deploying plugins #197 (ready for review)
2. The documentation is in Add minimal documentation for plugin images #196 (essentially a placeholder for the time being)

@klihub's #192 is required to be merged before this one (or otherwise the image building fails)

[mikebrow]

#192 is merged..

[marquiz]

Rebased. s/reference plugin/sample plugin/ in PR description and commit messages.

[klihub]

I'm quite keen to follow the development of this effort because I'm affected by the containerd 2.0 reduced limits in GKE. Last night I attempted to deploy a DaemonSet using @marquiz container image for the ulimit-adjuster plugin but the pods just kept crashing with no log output so I'm clearly not providing it what it needs.

Thank you for working on publishing container images and making the discussion public so I can follow it. :-)

@pwhack The plugins need at least a bind-mounted NRI socket so they can register themselves to the runtime. Some, for instance the hook injector need a bit more. I tested yesterday with the test-built image from @marquiz fork and this was enough to get it up and running. For others, the socket mount alone should be enough.

apiVersion: v1
kind: Pod
metadata:
  name: oci-hook-injector
  #namespace: kube-system
spec:
  containers:
  - name: oci-hook-injector
    image: ghcr.io/marquiz/nri/plugins/hook-injector:unstable
    imagePullPolicy: IfNotPresent
    args:
      - -idx
      - "10"
    resources:
      requests:
        cpu: 250m
        memory: 100M
      limits:
        cpu: 250m
        memory: 100M
    volumeMounts:
    - name: nri-socket
      mountPath: /var/run/nri
    - name: oci-hooks-config
      mountPath: /etc/containers/oci/hooks.d
    - name: oci-hooks-binaries
      mountPath: /usr/local/sbin
  volumes:
  - name: nri-socket
    hostPath:
      path: /var/run/nri
      type: DirectoryOrCreate
  - name: oci-hooks-config
    hostPath:
      path: /etc/containers/oci/hooks.d
      type: DirectoryOrCreate
  - name: oci-hooks-binaries
    hostPath:
      path: /usr/local/sbin
      type: DirectoryOrCreate
  terminationGracePeriodSeconds: 1

We agreed with @marquiz that we'll add in further PRs something more to show how to get them up and running, for instance sample daemonset files for the plugins.

[marquiz]

Updated:

• Rebased
• Added .dockerignore
• Set ENV NRI_PLUGIN_NAME=${PLUGIN} in the image

[klihub]

LGTM

[marquiz]

Updated: added CI check to test build images on PRs

[mikebrow]

nvm looks like it's already requesting multi-arch

[mikebrow]

LGTM