nomad driver containerd
Version 0.9.4
Nous recherchons activement des contributeurs et des agents pour ce projet. Si vous avez de l'expérience dans les internes à conteneurs, par exemple les groupes de noms, les espaces de noms ou que vous avez contribué à tous les projets open source autour des conteneurs, par exemple docker , containerd , nerdctl , podman , etc. ou de construire des outils qui impliquent de traiter avec les internes de conteneurs et sont intéressés à contribuer à ce projet, j'aimerais vous parler! L'expérience de Golang est préférée mais pas requise.
Veuillez me contacter @_shishir_m ou ouvrir un problème dans ce référentiel avec vos coordonnées, si vous souhaitez contribuer à ce projet.
Pilote de tâche NOMAD pour lancer des conteneurs à l'aide de Containerd.
Containerd (containerd.io) est un démon de conteneur léger pour fonctionner et gérer le cycle de vie des conteneurs.
Docker Daemon utilise également Containerd.
dockerd (docker daemon) --> containerd --> containerd-shim --> runc
NOMAD-DRIVER-CONTAINERD Permet au client NOMAD de lancer des conteneurs directement à l'aide de Containerd, sans Docker!
Docker Daemon n'est pas requis sur le système hôte.
Assurez-vous que votre $ GOPATH est correctement configuré.
$ mkdir -p $GOPATH/src/github.com/Roblox
$ cd $GOPATH/src/github.com/Roblox
$ git clone [email protected]:Roblox/nomad-driver-containerd.git
$ cd nomad-driver-containerd
$ make build (This will build your containerd-driver binary)
Si vous souhaitez compiler pour arm64 , vous pouvez courir:
make -f Makefile.arm64
$ vagrant up
ou vagrant provision si la machine virtuelle Vagrant est déjà en cours d'exécution.
Une fois que la configuration ( vagrant up ou vagrant provision ) est terminée et que le serveur NOMAD est opérationnel, vous pouvez vérifier les pilotes de tâches enregistrés (qui affichera également containerd-driver ) en utilisant:
$ nomad node status (Note down the <node_id>)
$ nomad node status <node_id> | grep containerd-driver
Remarque: setup.sh fait partie de la configuration Vagrant et ne doit pas être exécuté directement.
Il y a peu d'exemples d'emplois dans l' example de répertoire.
$ nomad job run <job_name.nomad>
lancera le travail.
Des instructions plus détaillées sont dans l' example README.md
Pour interagir directement avec images et containers , vous pouvez utiliser nerdctl qui est un CLI compatible Docker pour containerd . nerdctl est déjà installé dans la machine virtuelle Vagrant à /usr/local/bin .
Configuration du pilote
| Option | Taper | Requis | Défaut | Description |
|---|---|---|---|---|
| activé | bool | Non | vrai | Activer / désactiver le pilote de tâche. |
| contenerd_runtime | chaîne | Oui | N / A | Runtime pour Containerd EG io.containerd.runc.v1 ou io.containerd.runc.v2 . |
| stats_interval | chaîne | Non | 1 | Intervalle pour collecter TaskStats . |
| Autorce_Priviled | bool | Non | vrai | S'il est réglé sur false , le conducteur refusera des travaux privilégiés en cours d'exécution. |
| authentification | bloc | Non | N / A | Fournir une authentification pour un registre privé. Voir l'authentification pour plus de détails. |
Configuration de la tâche
| Option | Taper | Requis | Description |
|---|---|---|---|
| image | chaîne | Oui | Image OCI (Docker est également compatible OCI) pour votre conteneur. |
| image_pull_timeout | chaîne | Non | Une durée de temps qui contrôle la durée containerd-driver avant d'annuler une traction en cours de l'image OCI comme spécifié dans image . Par défaut "5m" . |
| commande | chaîne | Non | Commande pour remplacer la commande définie dans l'image. |
| args | []chaîne | Non | Arguments à la commande. |
| point d'entrée | []chaîne | Non | Une liste de chaînes dépassant le point d'entrée de l'image. |
| CWD | chaîne | Non | Spécifiez le répertoire de travail actuel pour votre processus de conteneur. Si le répertoire n'existe pas, on sera créé pour vous. |
| privilégié | bool | Non | Exécutez le conteneur en mode privilégié. Votre conteneur aura toutes les capacités Linux lors de l'exécution en mode privilégié. |
| pids_limit | int64 | Non | Une valeur entière qui spécifie la limite PID pour le conteneur. Par défaut est illimité. |
| pid_mode | chaîne | Non | host ou non défini (par défaut). Défini pour host pour partager l'espace de noms PID avec l'hôte. |
| nom d'hôte | chaîne | Non | Le nom d'hôte à affecter au conteneur. Lors du lancement de plus d'un d'une tâche (en utilisant count ) avec cet ensemble d'options, chaque conteneur démarre la tâche aura le même nom d'hôte. |
| host_dns | bool | Non | Par défaut ( true ). Par défaut, un conteneur lancé à l'aide de containerd-driver utilisera host /etc/resolv.conf . Ceci est similaire au docker behavior . Cependant, si vous ne souhaitez pas utiliser Host DNS, vous pouvez désactiver cet indicateur en définissant host_dns=false . |
| seccompente | bool | Non | Activer le profil SecComp par défaut. Liste des allowed syscalls . |
| seccomp_profile | chaîne | Non | Chemin vers le profil SecComp personnalisé. seccomp doit être défini sur true afin d'utiliser seccomp_profile . Le profil docker SecComp par défaut trouvé here peut être utilisé comme référence et modifié pour créer un profil SecComp personnalisé. |
| shm_size | chaîne | Non | Taille de / dev / shm par exemple "128m" si vous voulez 128 Mo de / dev / shm. |
| sysctl | Map [String] String | Non | Une carte de valeur clé des configurations SYSCTL à définir sur les conteneurs au démarrage. |
| readonly_rootfs | bool | Non | Le système de fichiers racine du conteneur sera en lecture seule. |
| host_network | bool | Non | Activer le réseau hôte. Cela équivaut à --net=host dans docker. |
| extra_hosts | []chaîne | Non | Une liste d'hôtes, donnée en tant qu'hôte: IP, à ajouter à / etc / hôtes. |
| cap_add | []chaîne | Non | Ajouter des capacités individuelles. |
| cap_drop | []chaîne | Non | Déposez les capacités de l'invitation. |
| dispositifs | []chaîne | Non | Une liste d'appareils à exposer au conteneur. |
| authentification | bloc | Non | Fournir une authentification pour un registre privé. Voir l'authentification pour plus de détails. |
| montures | []bloc | Non | Une liste de montures à monter dans le conteneur. Les supports de type Volume, Bind et TMPFS sont pris en charge. mount options de style FSTAB sont prises en charge. |
Bloc de montage
{
- Type (String) (Facultatif): Les valeurs prises en charge sont volume , bind ou tmpfs . Par défaut: volume.
- cible (chaîne) (requis): chemin cible dans le conteneur.
- Source (String) (Facultatif): chemin source sur l'hôte.
- Options ([] String) (Facultatif): mount options de style FSTAB. Remarque : Pour les supports de liaison, au moins rbind et ro sont nécessaires.
}
Exemple de montage de liaison
mounts = [
{
type = "bind"
target = "/target/t1"
source = "/src/s1"
options = ["rbind", "ro"]
}
]
Task Config mounts volume_mount stanza
Voir example job pour volume_mount .
Exemple de profil SecComp personnalisé
Le profil docker SecComp par défaut trouvé here peut être téléchargé et modifié (en supprimant / ajoutant des systèmes) pour créer un profil SecComp personnalisé.
Le profil SecComp personnalisé peut ensuite être enregistré sous /opt/seccomp/seccomp.json sur les nœuds du client nomad.
Un travail NOMAD peut être lancé à l'aide de ce profil SecComp personnalisé.
config {
seccomp = true
seccomp_profile = "/opt/seccomp/seccomp.json"
}
Exemple sysctl
config {
sysctl = {
"net.core.somaxconn" = "16384"
"net.ipv4.ip_forward" = "1"
}
}
auth Stanza vous permet de définir des informations d'identification pour votre registre privé, par exemple si vous souhaitez extraire une image d'un référentiel privé dans Docker Hub.
auth Stanza peut être définie soit dans Driver Config ou Task Config soit les deux.
S'il est défini aux deux endroits, Task Config Auth aura la priorité sur Driver Config Auth.
Remarque : Dans l'exemple ci-dessous, user et pass ne sont que des valeurs d'espace réservé qui doivent être remplacées par username et password réels, lors de la spécification des informations d'identification. Ci-dessous, la strophe auth peut être utilisée à la fois pour Driver Config et Task Config .
auth {
username = "user"
password = "pass"
}
nomad-driver-containerd prend en charge les réseaux d'hôte et de ponts .
Remarque: host et bridge sont des options mutuellement exclusives, et une seule d'entre elles doit être utilisée à la fois.
Le réseau hôte peut être activé en définissant host_network sur true dans la configuration de la tâche de la spécification du travail (voir sous Supported options ).
Le réseau de ponts peut être activé en définissant la strophe network dans la section du groupe de travail de la spécification du travail.
network {
mode = "bridge"
}
Vous devez installer des plugins CNI sur les nœuds clients nomades sous /opt/cni/bin avant de pouvoir utiliser les réseaux bridge .
Instructions pour installer des plugins CNI.
$ curl -L -o cni-plugins.tgz https://github.com/containernetworking/plugins/releases/download/v0.8.6/cni-plugins-linux-amd64-v0.8.6.tgz
$ sudo mkdir -p /opt/cni/bin
$ sudo tar -C /opt/cni/bin -xzf cni-plugins.tgz
Assurez-vous également que la distribution de votre système d'exploitation Linux a été configurée pour permettre le trafic sur le réseau de ponts via iptables. Ces tunables peuvent être définis comme suit:
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-arptables
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
$ echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
Pour préserver ces paramètres au démarrage d'un nœud client nomade, ajoutez un fichier comprenant les suivants à /etc/sysctl.d/ ou supprimez le fichier que votre distribution Linux met dans ce répertoire.
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
NOMAD prend en charge la cartographie des ports statique et dynamique .
La cartographie de port statique peut être ajoutée dans la strophe network .
network {
mode = "bridge"
port "lb" {
static = 8889
to = 8889
}
}
Ici, le port host 8889 est mappé au port container 8889 .
Remarque : les ports statiques ne sont généralement pas recommandés, sauf pour system ou les emplois spécialisés comme les équilibreurs de charge.
La cartographie des ports dynamique est également activée dans la strophe network .
network {
mode = "bridge"
port "http" {
to = 8080
}
}
Ici, Nomad allouera un port dynamique sur l' host et ce port sera mappé à 8080 dans le conteneur.
Vous pouvez également en savoir plus sur network stanza dans la nomad official documentation
NOMAD planifie les charges de travail de différents types à travers un groupe d'hôtes génériques. Pour cette raison, le placement n'est pas connu à l'avance et vous devrez utiliser la découverte de services pour connecter des tâches aux autres services déployés dans votre cluster. NOMAD s'intègre au consul pour fournir la découverte et la surveillance des services.
Une strophe service peut être ajoutée à vos spécifications pour activer la découverte de service.
La strophe de service demande à Nomad d'enregistrer un service auprès du consul.
Si vous exécutez les tests localement, utilisez la vagrant VM fournie dans le référentiel.
$ vagrant up
$ vagrant ssh containerd-linux
$ sudo make test
Remarque : Ce sont des tests destructeurs et peuvent laisser le système dans un état modifié.
Il est fortement recommandé d'exécuter ces tests, soit dans le cadre d'un système CI / CD, par exemple, soit sur une infrastructure immuable, par exemple des machines virtuelles vagues.
Vous pouvez également exécuter un test individuel en spécifiant le nom du test. par exemple
$ cd tests
$ sudo ./run_tests.sh 001-test-redis.sh
make clean
Cela supprimera votre binaire: containerd-driver
vagrant destroy
Cela détruira votre VM vagabond.
Ubuntu (> = 16.04)
Copyright 2020 Roblox Corporation
Licencié sous la licence Apache, version 2.0 (la "licence"). Pour plus d'informations, lisez la licence.
