RKT, à prononcer “rock-it”, est un container runtime créé par les équipes de CoreOS, fonctionant en couches avec le support de plusieurs moteurs d'exécution pour les containers.

Les différentes couches sont les suivantes:

• en stage0, RKT lui même, le binaire n'étant qu'une UX/API pour le moteur d'exécution du container
• en stage1 se trouve le moteur d'exécution du container. Comme évoqué précédemment, plusieurs sont disponibles. Par défaut, un container est lancé via systemd-nspawn. Le container peut aussi démarrer via un simple chroot, nommé fly par les développeurs de RKT. Enfin, l'isolation matérielle peut aussi être réalisée sur cette couche par l'intermédiaire de LKVM (une version allégée de KVM) ou en core Qemu
• le stage2 comprend la ou les applications qui doivent fonctionner dans le container lancé. La notion de Pod par RKT regroupe à la fois le moteur d'exécution et les applications containerisées, ce qui est au final démarré par le binaire rkt. Illustrée, cette composabilité interne peut être vue de la façon suivante:

Le fly stage1 est un stage1 alternatif qui exécute un ACI à application unique avec seulement une isolation par chroot.

La motivation de la fonctionnalité Fly est d'ajouter la possibilité d'exécuter des applications avec des privilèges complets sur l'hôte tout en bénéficiant de la gestion des images et de la découverte de rkt.

Par rapport au stage1 par défaut, aucun gestionnaire de processus n'est impliqué dans ce stage1. Il s'agit d'une illustration visuelle des différences dans l'arborescence de processus entre le stade par défaut et le stade fly1:

stage1-coreos.aci:

OS hôte
  └─ rkt
    └─ systemd-nspawn
      └─ systemd
        └─ chroot
          └─ user-app1

stage1-fly.aci:

OS hôte
  └─ rkt
    └─ chroot
      └─ user-app1

L'application rkt configure des montages de liaison pour /dev, /proc, /sys et les volumes fournis par l'utilisateur. En plus des montages de liaison, un montage tmpfs supplémentaire est effectué dans /tmp. Une fois les montages configurés, rkt chroote vers RootFS de l'application et exécute enfin l'application.

Les saveurs disponibles sont:

• coreos - il prend systemd et bash à partir d'une image CoreOS Container Linux PXE; utilise systemd-nspawn
• kvm - il prend systemd, bash et autres binaires d'une image Container Linux PXE; utilise lkvm ou qemu
• src - il construit systemd, prend bash de l'hôte au moment de la construction; utilise le systemd-nspawn intégré
• host - il prend systemd et bash de l'hôte au moment de l'exécution; utilise systemd-nspawn de l'hôte
• fly - approche chroot uniquement pour les conteneurs à isolation minimale à application unique; implémentation native de Go

La flavor host est probablement la saveur la mieux adaptée aux distributions qui ont des règles strictes sur les sources logicielles.

Les paramètres décrits ci-dessous affectent le traitement de l'image stage1 par défaut de rkt. rkt essaie d'abord de trouver l'image stage1 dans le magasin en utilisant le nom et la version par défaut de l'image stage1. Si cela échoue, rkt essaiera de récupérer l'image dans le magasin à partir de l'emplacement par défaut de l'image stage1.

Il existe deux façons mutuellement exclusives de spécifier un nom et une version d'image par défaut de stage1:

• configuration de flavor
• configuration détaillée

La configuration des flavors n'a qu'un seul paramètre. Ce type de configuration est plutôt un outil pratique pour la configuration détaillée.

La configuration détaillée a deux paramètres, les deux doivent être fournis. Ce type de configuration peut être utilisé pour faire de l'implémentation stage1 tierce l'image stage1 par défaut utilisée par rkt.

La saveur src fournit des paramètres pour spécifier certains détails spécifiques à git du référentiel systemd.

Les flavors coreos et kvm fournissent des paramètres liés à l'image CoreX Container Linux PXE.

Il n'y a qu'un seul indicateur pour les tests - pour activer les tests fonctionnels.

Ces indicateurs sont liés à la sécurité.

Linux 3.18+ (idéalement 4.3+ pour que la superposition sur superposition fonctionne), avec les options suivantes configurées:

CONFIG_CGROUPS
CONFIG_NAMESPACES
CONFIG_UTS_NS
CONFIG_IPC_NS
CONFIG_PID_NS
CONFIG_NET_NS
CONFIG_OVERLAY_FS (nice to have)

installation des dépendances

Dans cet exemple, ~ / Repos est un espace de travail personnel où tous les dépôts sont stockés

mkdir ~/Repos && cd ~/Repos
mkdir -p ~/.local/gopath/src/github.com/rkt
sudo apt-get install git
git -C ~/.local/gopath/src/github.com/rkt clone https://github.com/rkt/rkt.git
ln -s ~/.local/gopath/src/github.com/rkt/rkt rkt

cd ~/Downloads
wget https://storage.googleapis.com/golang/go1.6.1.linux-amd64.tar.gz
tar -xvf go1.6.1.linux-amd64.tar.gz
mv go ~/.local

Ajouter les variables GO au fichier .bashrc:

export PATH=~/.local/bin:~/.local/go/bin:$PATH
export GOPATH=~/.local/gopath
export GOROOT=~/.local/go

Exécuter l'autogen et configurer les commandes avec les arguments appropriés, par exemple (kvm comme flavor):

./configure --enable-tpm=no --with-stage1-flavors=kvm,fly --with-coreos-local-pxe-image-path=/src/rkt/common/pxe.img --with-coreos-local-pxe-image-systemd-version=v233

Maintenant, construire rkt avec:

make V=2 -j

./tests/build-and-run-tests.sh -f kvm

make functional-check

make functional-check GO_TEST_FUNC_ARGS='-run TEST_NAME_HERE'

sudo ./build-rkt-*/bin/rkt run --insecure-options=image --interactive docker://busybox
exit
sudo ./build-rkt-*/bin/rkt gc --grace-period=0

for link in $(ip link | grep rkt | cut -d':' -f2 | cut -d'@' -f1);
    sudo ip link del "${link}"
done