Work in progress. Please contribute if you see an area that needs more detail.
rkt runs applications packaged according to the open-source App Container Image specification. ACIs consist of the root filesystem of the application container, a manifest, and an optional signature.
ACIs are named with a URL-like structure. This naming scheme allows for a decentralized discovery of ACIs, related signatures and public keys. rkt uses these hints to execute meta discovery.
rkt can execute ACIs identified by name, hash, local file path, or URL.
If an ACI hasn't been cached on disk, rkt will attempt to find and download it.
To use rkt's metadata service, enable registration with the
--mds-register flag when invoking it.
rkt provides subcommands to list, get status, and clean its pods.
rkt provides subcommands to list, inspect and export images in its local store.
The metadata service helps running apps introspect their execution environment and assert their pod identity.
The API service allows clients to list and inspect pods and images running under rkt.
In addition to the flags used by individual
rkt has a set of global options that are applicable to all commands.
||Prints out more debug information to
||A directory path||Path to the
||none||<ul><li>none: All security features are enabled</li><li>http: Allow HTTP connections. Be warned that this will send any credentials as clear text.</li><li>image: Disables verifying image signatures</li><li>tls: Accept any certificate from the server and any host name in that certificate</li><li>ondisk: Disables verifying the integrity of the on-disk, rendered image before running. This significantly speeds up start time.</li><li>all: Disables all security checks</li></ul>||Comma-separated list of security features to disable|
||``||A directory path||Path to the user configuration directory|
||A directory path||Path to the local configuration directory|
||A directory path||Path to the system configuration directory|
||Automatically trust gpg keys fetched from https|
By default, rkt will send logs directly to stdout/stderr, allowing them to be captured by the invoking process. On host systems running systemd, rkt will attempt to integrate with journald on the host. In this case, the logs can be accessed directly via journalctl.
To read the logs of a running pod, get the pod's machine name from
$ machinectl MACHINE CLASS SERVICE rkt-132f9d56-0e3f-4d1e-ba86-68efd488bb62 container nspawn 1 machines listed.
rkt list --full
# rkt list --full UUID APP IMAGE NAME IMAGE ID STATE NETWORKS 132f9d56-0e3f-4d1e-ba86-68efd488bb62 etcd coreos.com/etcd:v2.0.10 sha512-c03b055d02e5 running
The pod's machine name will be the pod's UUID prefixed with
Given this machine name, logs can be retrieved by
# journalctl -M rkt-132f9d56-0e3f-4d1e-ba86-68efd488bb62 [...]