Container Image Specification

This document provides standardized conventions for well-behaved container images.

Publishing Images

Image releases should be published with the following format, based on the group, name, and version in the Apollo Product Spec manifest (see Manifest Specification):

{group}/{name}:{version}

Where:

group: Manifest product-group with the com.palantir prefix removed if it exists
product: Manifest product-name
version: Manifest product-version

For example: com.palantir.example:wordpress:13.1.4 would have "com.palantir.example" as the product-group, "wordpress" as the product-name, and "13.1.4" as the product-version.

The latest tag may be used in snapshot or sandbox repositories, but must never be used for releases.

Specifying Additional Images

Sometimes certain Apollo Product Spec entities may require more than the primary image to perform their operations. For example, this can occur when an entity is responsible for orchestrating its own containerized workloads. Such Apollo Product Spec entities must declare all images required for their operation via the artifacts manifest extension. This extension is a list of fully qualified image locators and can be used by all Apollo Product Spec product types.

Example Usage

Copied!1
2
3
4
extensions:
  artifacts:
    - type: oci
      uri: docker.io/bitnami/wordpress:5.9.2-debian-10-r9

Each listed artifact must provide the following fields:

type: the artifact's type. The only currently supported value is oci, used for artifacts that comply with the Open Container Initiative image specification.
uri: a fully qualified locator for the artifact.

Best practice: Base image reuse

Images should be as lean as reasonably possible. Image bloat is a concern both for storing images and running containers; to prevent image bloat, reuse base images and do not add unnecessary layers to your image. An example of a lightweight base image in use by many products is Alpine.