cloud-native-toolkit / planning

The is the planning repo to manage the cross project Epics and Issues. Tasks and Bugs
3 stars 1 forks source link

Image identification #730

Open bwoolf1 opened 3 years ago

bwoolf1 commented 3 years ago

Red Hat Container Certification requires that the container image must include the following metadata:

The Dockerfile should add these as LABELs.

bwoolf1 commented 3 years ago

Currently, IBM/template-node-typescript produces an image with this ContainerConfig.Labels:

        "Labels": {
            "architecture": "x86_64",
            "build-date": "2020-07-23T05:54:39.075680",
            "com.redhat.build-host": "cpt-1004.osbs.prod.upshift.rdu2.redhat.com",
            "com.redhat.component": "nodejs-12-container",
            "com.redhat.deployments-dir": "/opt/app-root/src",
            "com.redhat.dev-mode": "DEV_MODE:false",
            "com.redhat.dev-mode.port": "DEBUG_PORT:5858",
            "com.redhat.license_terms": "https://www.redhat.com/en/about/red-hat-end-user-license-agreements#UBI",
            "description": "Node.js 12 available as container is a base platform for building and running various Node.js 12 applications and frameworks. Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.",
            "distribution-scope": "public",
            "help": "For more information visit https://github.com/sclorg/s2i-nodejs-container",
            "io.k8s.description": "Node.js 12 available as container is a base platform for building and running various Node.js 12 applications and frameworks. Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.",
            "io.k8s.display-name": "Node.js 12",
            "io.openshift.expose-services": "8080:http",
            "io.openshift.s2i.scripts-url": "image:///usr/libexec/s2i",
            "io.openshift.tags": "builder,nodejs,nodejs12",
            "io.s2i.scripts-url": "image:///usr/libexec/s2i",
            "maintainer": "SoftwareCollections.org \u003csclorg@redhat.com\u003e",
            "name": "ubi8/nodejs-12",
            "release": "52",
            "summary": "Platform for building and running Node.js 12 applications",
            "url": "https://access.redhat.com/containers/#/registry.access.redhat.com/ubi8/nodejs-12/images/1-52",
            "usage": "s2i build \u003cSOURCE-REPOSITORY\u003e ubi8/nodejs-12:latest \u003cAPP-NAME\u003e",
            "vcs-ref": "a6b3970d86fb885d9c20445676a2f31aa9bedf0b",
            "vcs-type": "git",
            "vendor": "Red Hat, Inc.",
            "version": "1"
        }

The required labels are set by the UBI, with values for a generic Node v12 app:

seansund commented 3 years ago

This is a duplicate of ibm-garage-cloud/planning#675 . @bwoolf1 I'm not sure if you are saying what is provided currently is sufficient or not... The point of ibm-garage-cloud/planning#675 is that we want the values of those labels to be specific to the image that is being created (e.g. name=inventory-svc, version=1.0.5)

bwoolf1 commented 3 years ago

To view the labels on an image in the ICCR:

$ ibmcloud login -a https://cloud.ibm.com
$ ibmcloud cr region-set us-south
$ ic cr image-inspect <image URL and tag> (such as: us.icr.io/isv-scenarios/stockbffnode-bw:0.0.1)
bwoolf1 commented 3 years ago

As Sean noted, some of those labels need to be set programmatically, and he shows how using buildah in issue #675.

The other labels (name, vendor, summary, description) should be read from a separate file, some sort of json/xml/properties file named something like image-id in the same directory as the Dockerfile. Better to hardcode these values in that separate file so that one doesn't need to edit the Dockerfile.

seansund commented 3 years ago

Need to investigate "release" as building new image with label layer instead of skopeo copy

bwoolf1 commented 3 years ago

Here's what we've got so far for an implementation:

## Requirement 6: Image Identification
ARG NAME
ARG VENDOR
ARG VERSION
ARG RESEASE
ARG SUMMARY
ARG DESCRIPTION

LABEL name=${NAME} \
      vendor=${VENDOR} \
      version=${VERSION} \
      release=${RESEASE} \
      summary=${SUMMARY} \
      description=${DESCRIPTION}