App Container basics

App Container (appc) is an open specification that defines several aspects of how to run applications in containers: an image format, runtime environment, and discovery protocol.

rkt's native image format and runtime environment are those defined by the specification.


The image format defined by appc and used in rkt is the Application Container Image, or ACI. An ACI is a simple tarball bundle of a rootfs (containing all the files needed to execute an application) and an Image Manifest, which defines things like default execution parameters and default resource constraints. ACIs can be built with tools like acbuild, actool, or goaci. Docker images can be converted to ACI using docker2aci, although rkt will do this automatically.

Most parameters defined in an image can be overridden at runtime by rkt. For example, the rkt run command allows users to supply custom exec arguments to an image.


appc defines the pod as the basic unit of execution. A pod is a grouping of one or more app images (ACIs), with some additional metadata optionally applied to the pod as a whole - for example, a resource constraint can be applied at the pod level and then forms an "outer bound" for all the applications in the pod. The images in a pod execute with a shared context, including networking.

A pod in rkt is conceptually identical to a pod as defined in Kubernetes.

Validating rkt as an appc implementation

rkt implements the two runtime components of the appc specification: the Application Container Executor (ACE) and the Metadata Service. It also uses schema and code from the upstream appc/spec repo to manipulate ACIs, work with image and pod manifests, and perform image discovery.

To validate that rkt successfully implements the ACE part of the spec, use the App Container validation ACIs:

# rkt metadata-service &  # Make sure metadata service is running
# rkt --insecure-options=image run \
    --mds-register \
    --volume=database,kind=host,source=/tmp \ \