Exécution d’applications tierces dans des conteneurs

Pour déployer un conteneur Docker :

Les conteneurs Docker sont gérés via un flux de travail Docker Linux standard. Utilisez les docker pscommandes , ps ou top Linux pour afficher les conteneurs Docker en cours d’exécution, et utilisez les commandes Docker pour gérer les conteneurs. Pour plus d’informations sur les commandes Docker, consultez : https://docs.docker.com/engine/reference/commandline/cli/

Note:

Les fonctionnalités de haute disponibilité de Junos OS Evolved ne sont pas prises en charge pour les applications personnalisées dans les conteneurs Docker. Si une application dispose d’une fonctionnalité de haute disponibilité, vous devez exécuter l’application sur chaque RE pour vous assurer qu’elle peut se synchroniser. Une telle application devra avoir la logique métier requise pour se gérer et communiquer avec toutes les instances.

Vous devez fournir des arguments supplémentaires aux commandes Docker si votre conteneur nécessite des fonctionnalités supplémentaires telles que Netlink ou PacketIO. Vous devrez également activer nlsd le service pour activer la fonctionnalité Netlink sur certaines versions. L’exemple suivant montre comment activer les fonctionnalités Netlink ou PacketIO pour un conteneur en ajoutant des arguments à une commande Docker :

1. Créez un volume persistant de nom en lecture seule au démarrage des services Docker. Le montage du volume permet de monter les jnet bibliothèques nécessaires à la fonctionnalité PacketIO et Netlink sur les ports WAN/données :

2. Partagez l’espace de noms Network et IPC de l’hôte avec le conteneur. Les conteneurs nécessitant les fonctionnalités PacketIO et Netlink sur des ports WAN/de données devront se trouver dans l’espace de noms du réseau hôte et de l’IPC :

3. Démarrez automatiquement le conteneur au redémarrage du système :

4. Activez la fonctionnalité d’administration réseau, requise par les bibliothèques Netlink et PacketIO :

5. Activez les variables d’environnement requises pour Netlink et PacketIO sur les ports WAN/de données :

6. Montez le périphérique jtd0 de l’hôte au conteneur pour faciliter la gestion de PacketIO :

7. Montez le répertoire /dev/shm de l’hôte dans le conteneur pour Netlink et PacketIO sur les ports WAN/données :

8. Si la gestion des groupes multicast est requise par l’application de conteneur, montez le répertoire /dev/mcgrp de l’hôte vers le conteneur :

9. Après la version 24.1R1 de Junos OS Evolved, les conteneurs de l’espace de noms du réseau hôte qui souhaitent disposer d’une résolution DNS doivent transmettre l’option --dns ::1 à la docker run commande. Ceci n’est pas requis pour Junos OS Evolved version 23.4 et antérieure :

10. Si votre conteneur nécessite un traitement lié à Netlink, vous devez également activer le processus d’API asynchrone Netlink (nlsd) dans Junos OS Evolved avec la configuration CLI suivante :

Note:

Les applications natives Linux ou basées sur des conteneurs qui nécessitent les fonctionnalités PacketIO et Netlink doivent être liées dynamiquement. Nous vous recommandons d’utiliser des conteneurs Docker basés sur Ubuntu, car ce sont les seuls conteneurs officiellement qualifiés par Juniper Networks. Les conteneurs basés sur Ubuntu doivent utiliser le glibc compatible avec le système d’exploitation Junos Evolved de glibcbase .

Pour Junos OS Evolved versions 23.4R1 et antérieures, les conteneurs héritent du VRF (Virtual Routing and Forwarding) du processus Docker. Pour exécuter des conteneurs dans un VRF distinct, une instance de processus Docker doit être démarrée dans le VRF correspondant. L’instance docker@vrf.service permet de démarrer un processus dans le VRF correspondant. Si le VRF n’est pas spécifié, la valeur par défaut du VRF est vrf0.

Le docker.service s’exécute vrf:none par défaut.

Pour Junos OS Evolved versions 24.1R1 et ultérieures, nous vous recommandons de lier une tâche spécifique dans le conteneur à un VRF Linux spécifique à l’aide de la ip vrf exec task commande. Cela nécessite que le conteneur soit démarré avec l’option --privileged, et qu’une version compatible du iproute2 conteneur soit installée. Le conteneur doit également partager l’espace de noms du réseau avec l’hôte. Vous pouvez également utiliser l’option SO_BINDTODEVICE socket pour lier le socket d’une tâche ou d’une application spécifique dans le conteneur à un périphérique VRF Linux spécifique, auquel cas iproute2 ce n’est pas nécessaire.

La ip vrf show commande répertorie tous les VRF Linux disponibles. Si vous choisissez de lier les sockets d'une tâche dans le conteneur à un VRF à l'aide iproute2de , nous vous recommandons d'écraser certaines variables env à l'aide --env-file=/run/docker-vrf0/jnet.envde , afin libnli.so qu'il ne soit pas préchargé pour éviter qu'il n'interfère avec iproute2.

Vous pouvez lancer un conteneur et lier le socket associé à la tâche du conteneur au vrf vrf0 par défaut à l'aide des commandes suivantes :

Avec cette approche, différentes sockets associées à différentes tâches dans le conteneur peuvent être associées à différents VRF au lieu de toutes les sockets liées à un seul VRF.

Le processus Docker d’un VRF spécifique écoute sur la socket correspondante située dans /run/docker-vrf.sock.

Il s’agit du VRF tel qu’on le voit sur Linux et non du VRF Junos OS Evolved. L’utilitaire evo_vrf_name (disponible à partir de Junos OS Evolved version 24.1) peut être utilisé pour trouver le VRF Linux qui correspond à un VRF Junos OS Evolved.

Le client Docker est associé au processus Docker spécifique au VRF à l’aide des arguments suivants :

Par exemple, pour exécuter un conteneur dans vrf0 , entrez la commande Docker et les arguments suivants :

Note:

Un conteneur ne peut être associé qu’à un seul VRF.

Les limites de ressources par défaut pour les conteneurs sont contrôlées par le biais d’un fichier situé dans /etc/extensions/platform_attributes. Le texte suivant s’affiche à l’ouverture de ce fichier :

Pour modifier les limites de ressources pour les conteneurs, ajoutez des valeurs aux EXTENSIONS entrées au bas du fichier. Assurez-vous de le faire avant de démarrer le processus Docker.

• EXTENSIONS_FS_DEVICE_SIZE_MIB= Contrôle l’espace de stockage maximal que les conteneurs peuvent utiliser. Entrez la valeur en mégaoctets. La valeur par défaut est 8000 ou 30 % de la taille totale de /var, selon la valeur la plus petite. Assurez-vous d’ajouter cette entrée avant de démarrer le processus Docker pour la première fois. Si vous devez modifier cette valeur ultérieurement, vous devrez supprimer la partition existante, ce qui peut entraîner une perte de données sur cette partition. Si cette partition de stockage doit être modifiée après le démarrage du service Docker, le processus Docker doit d’abord être arrêté avec la systemctl stop docker commande, et la partition existante peut être supprimée à l’aide de la systemctl stop var-extensions.mount commande suivie de la rm /var/extensions_fs commande. Une fois cet attribut modifié, redémarrez le processus Docker et la nouvelle partition avec la taille spécifiée sera créée. Vous pouvez également redémarrer var-extensions.mount avec la systemctl restart var-extensions.mount commande pour obtenir le même résultat. Nous vous suggérons de faire une sauvegarde de la partition pour éviter de perdre des données importantes. Nous vous déconseillons d’augmenter cette valeur au-delà de 30 % de la partition /var , car cela pourrait affecter le fonctionnement normal de Junos OS Evolved.

• EXTENSIONS_CPU_QUOTA_PERCENTAGE= contrôle l’utilisation maximale de l’UC que les conteneurs peuvent utiliser. Entrez une valeur en pourcentage de l’utilisation du processeur. La valeur par défaut est de 20 %, mais peut varier en fonction de la plateforme.

• EXTENSIONS_MEMORY_MAX_MIB= Contrôle la quantité maximale de mémoire physique que les conteneurs peuvent utiliser. Entrez la valeur en mégaoctets. La valeur par défaut est 2000 mais elle peut varier en fonction de la plateforme. Si cela doit être modifié, la valeur EXTENSIONS_MEMORY_SWAP_MAX_MIB= d’échange doit également être spécifiée. Notez que Linux cgroup ne permet pas de définir des valeurs déraisonnables pour les limites de mémoire et de processeur. Si les valeurs définies ne sont pas reflétées dans le cgroup, la raison la plus probable est que les valeurs sont incorrectes (éventuellement très élevées ou très faibles).

• EXTENSIONS_MEMORY_SWAP_MAX_MIB= Contrôle la quantité maximale de mémoire d’échange que les conteneurs peuvent utiliser. Entrez la valeur en mégaoctets. La valeur par défaut est de 15 % de l’espace d’échange disponible, mais elle peut varier en fonction de la plateforme. Les deux et EXTENSION_MEMORY_MAX_MIB= EXTENSIONS_MEMORY_SWAP_MAX_MIB= doivent être définis si l’un ou l’autre est en cours de modification. La valeur recommandée pour le swap est de 15 % de EXTENSION_MEMORY_MAX_MIB=. La valeur réelle cgroup de swap serait EXTENSION_MEMORY_MAX_MIB + EXTENSIONS_MEMORY_SWAP_MAX_MIB.

Par défaut, celles-ci sont définies sur des valeurs spécifiques à la plate-forme, nous vous recommandons donc de définir les valeurs avant de démarrer les conteneurs.

PRUDENCE:

Avant de modifier les limites de ressources pour les conteneurs, renseignez-vous sur les exigences en matière de processeur et de mémoire pour la mise à l’échelle que vous devez prendre en charge dans votre configuration. Faites preuve de prudence lorsque vous augmentez les limites de ressources pour les conteneurs afin d’éviter qu’elles ne mettent votre système à rude épreuve.