Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
À compter du 26 août 2024, vous ne pouvez plus créer de nouveaux moniteurs à l'aide legacy runtimes sur des sites publics ou privés.
Le 22 octobre 2024, nous mettrons fin à la vie du minion privé conteneurisé (CPM) et des versions synthétiques d'exécution legacy qu'il prend en charge. Veuillez consulter nos étapes de migration recommandées pour éviter la dégradation de votre site privé monitorer.
Vous pouvez utiliser les minions privés conteneurisés (CPM) de New Relic. Il s'agit de minions privés basés sur des conteneurs Docker qui acceptent et exécutent des moniteurs synthétiques sur vos sites privés.
Les CPM peuvent fonctionner dans un environnement Docker conteneur système ou dans un environnement Kubernetes conteneur orchestration système. Le CPM détectera automatiquement son environnement pour sélectionner le mode de fonctionnement approprié.
Fonctionnalités générales de minion privé
Parce que les CPM fonctionnent comme un conteneur plutôt que comme une machine virtuelle, ils offrent de nombreuses fonctionnalités :
Sécurité et prise en charge améliorées pour l'exécution d'utilisateurs non root
Capacité à exploiter un conteneur Docker comme environnement sandbox
Délai d'expiration de vérification du moniteur personnalisable
Modules personnalisés fournis pour les types de moniteurs scriptés
Fonctionnalité spécifique Kubernetes
De plus, les CPM offrent la fonctionnalité suivante dans un environnement Kubernetes :
S'intègre à l'API Kubernetes pour déléguer la gestion du cycle de vie d'exécution à Kubernetes
Ne nécessite pas d'accès privilégié au socket Docker
Prend en charge les clusters Kuberneteshébergés et sur site
Prend en charge divers moteurs de conteneurs tels que Docker et Containerd
Déployable via des graphiques Helm ainsi que des fichiers YAML de configuration
Permet une allocation de ressources basée sur les tâches (vérifications ping ou non ping) pour une gestion optimale des ressources
observabilité offerte via cluster Kubernetes l'explorateur New Relic
exigence système et compatibilité
Pour accueillir des CPM, votre système doit répondre aux exigences minimales de l'environnement système choisi.
Prudence
Ne modifiez aucun fichier CPM. New Relic n'est pas responsable des modifications que vous apportez. Pour plus d'informations, contactez votre représentant de compte ou un représentant commercial technique New Relic.
Mesuré en monitoring le débit d'écriture pour https://newrelic.com sur une instance AWS EC2 m5.xlarge avec : AL2, classe de stockage gp2, volume racine de 50 Gio, une installation CPM Docker par défaut et 1 moniteur à la fois défini sur une fréquence de 1 minute. Des gains d’efficacité sont attendus avec l’exécution de plusieurs moniteurs. Ces valeurs peuvent être supérieures ou inférieures aux vôtres en fonction de nombreux facteurs.
La base de référence pour les Docker CPM est de 0,5 IOPS sans tâches du monitoring en cours d'exécution.
Le CPM Docker ne prennent pas en charge Docker Engine 26.0 ou supérieur en raison de modifications radicales. Les clients recherchant la prise en charge de Docker 26+ doivent migrer vers Synthetics Job Manager
Prudence
Les CPM Docker ne sont pas conçus pour être utilisés avec des orchestrateurs de conteneurs comme AWS ECS, Docker Swarm, Apache Mesos, Azure Container Instance, etc. L'exécution des Docker CPM dans un orchestrateur de conteneurs entraînera des problèmes inattendus car il s'agit lui-même d'un orchestrateur de conteneurs. Si vous utilisez l'orchestration de conteneurs, consultez nos exigences relatives aux CPM Kubernetes .
Compatibilité pour
Exigences
système d'exploitation
Linux kernel: 3.10 ou supérieur macOS: 10.11 ou supérieur
Les conteneurs Linux, y compris les miniona privés conteneurisés (CPM) , ne fonctionnent que sur les nœuds Linux K8.
Processeur
Un processeur multi-cœur moderne
Pod minion
CPU (vCPU/Core): 0,5 à 0,75 Memory: 800Mi jusqu'à 1600Mi
Les ressources allouées à un pod minion sont configurables par l'utilisateur.
podcoureur
CPU (vCPU/Core): 0,5 à 1 Memory: 1250Mi jusqu'à 3000Mi
Pour une vérification d'API scriptée, 1250Mi seront demandés avec une limite de 2500Mi.
Pour une vérification de navigateur simple ou de navigateur scripté, 2000Mi seront demandés avec une limite de 3000Mi.
Considérations supplémentaires :
Les ressources allouées à un pod runner ne sont pas configurables par l'utilisateur.
Le rapport limite/requête de ressources maximal pour le processeur et la mémoire est de 2.
Taille du disque
Root volume: Un minimum de 50 Gio (nœud + PV) Persistent volume (PV): Un minimum de 20 Gio
Si un PV ReadWriteOnce (RWO) est fourni au minion, une affinité de nœud implicite sera établie pour garantir que le minion et le conteneur runner sont planifiés sur le même nœud. Cela est nécessaire pour permettre au minion et aux coureurs associés d'accéder au PV, car un PV RWO n'est accessible que par un seul nœud du cluster.
Mesuré en monitoring le débit d'écriture pour https://newrelic.com sur un cluster AWS EKS 1.21 soutenu par un nœud EC2 m5.xlarge exécuté avec : classe de stockage gp2, volume racine de 50 Gio, PV/PVC de 20 Gio avec mode d'accès RWO, une installation Kubernetes CPM par défaut via Helm et 1 moniteur à la fois défini sur une fréquence de 1 minute. Des gains d’efficacité sont attendus avec l’exécution de plusieurs moniteurs. Ces valeurs peuvent être supérieures ou inférieures aux vôtres en fonction de nombreux facteurs.
La base de référence pour les CPM Kubernetes est de 3,0 IOPS sans tâches du monitoring en cours d'exécution.
Système de fichiers sur disque
NFSv4.1 ou supérieur (si vous utilisez NFS)
Version de Kubernetes
Nous vous recommandons que votre cluster Kubernetes prenne en charge Kubernetes v1.15.
Prudence
Pour Kubernetes v1.21 ou plus récent, utilisez la sortie du minion v3.0.61 ou plus récent.
Après août 2022, nous cesserons de prendre en charge plusieurs fonctionnalités, y compris notre URL de graphique Helm de minion privé d'origine.Pour plus de détails, notamment sur la manière dont vous pouvez facilement vous préparer à cette transition, consultez notre publication sur le forum d'assistance.
Pour afficher les versions, les dépendances, les valeurs par défaut du nombre de pods runners qui démarrent avec chaque minion, le mode d'accès au volume persistant, et plus encore, veuillez consulter Afficher l'aide et les exemples ci-dessous.
clé privée du site
Avant de lancer CPM, vous devez disposer d'une clé privée de site. Vos CPM utilisent la clé pour s'authentifier auprès de New Relic et exécuter le moniteur associé à ce site privé.
Dans l'index Private locations , recherchez le site privé auquel vous souhaitez que vos CPM soient attribués.
Notez la clé associée au site privé avec la clé icône.
Sandboxing et dépendance Docker
Sandboxing et Docker dépendance sont applicables aux CPM dans un environnement Docker conteneur système.
CPM fonctionne dans Docker et est capable d'exploiter Docker comme technologie sandbox. Cela garantit une isolation complète de l’exécution du moniteur, ce qui améliore la sécurité, la fiabilité et la répétabilité. Chaque fois qu'un script ou un moniteur de navigateur est exécuté, les CPM créent un tout nouveau conteneur Docker pour l'exécuter, appelé runner.
Le conteneur minion doit être configuré pour communiquer avec le moteur Docker afin de générer un conteneur runner supplémentaire. Chaque conteneur généré est ensuite dédié à l'exécution d'un contrôle associé au moniteur Synthétique exécuté sur le site privé auquel le conteneur minion est associé.
Il existe deux dépendances cruciales au lancement. Pour activer le sandboxing, assurez-vous que :
Votre répertoire inscriptible et exécutable est monté à /tmp. Le répertoire accessible en écriture peut être n'importe quel répertoire dans lequel vous souhaitez que les CPM écrivent, mais New Relic recommande le propre /tmp du système pour faciliter les choses.
Le nombre de cœurs sur l'hôte détermine le nombre de conteneurs de coureurs qui peuvent exécuter les CPM simultanément sur l'hôte. Étant donné que les besoins en mémoire sont adaptés au nombre attendu de conteneurs d'exécution, nous recommandons not running multiple CPMs on the same host pour éviter les conflits de ressources.
L'installation et la mise à jour de CPM utilisent la même commande pour extraire la dernière image Docker du référentiel Quay.io où l'image Docker CPM est hébergée. Allez sur quay.io/repository/newrelic/synthetics-minion pour une liste de toutes les sorties.
À moins que vous n'hébergiez les images dans un référentiel d'images local, les connexions à quay.io ou docker.io devront être autorisées via votre pare-feu pour que Docker puisse extraire les images synthetics-minion et synthetics-minion-runner. L'image « runner » est extraite automatiquement au démarrage du conteneur synthetics-minion.Consultez la configuration de l’environnement Docker et la configuration de l’environnement Kubernetes pour plus de détails sur la façon de définir un référentiel local et le point de terminaison du registre d’exécution.
Démarrer les CPM
Pour démarrer les CPM, suivez les instructions Docker ou Kubernetes applicables.
Exécutez le script approprié pour votre système. Adaptez les valeurs par défaut communes pour /tmp et /var/run/docker.sock dans les exemples suivants pour qu'elles correspondent à votre système.
Lorsqu'un message similaire à Synthetics Minion is ready and servicing location YOUR_PRIVATE_LOCATION_LABEL apparaît, vos CPM sont actifs et prêts à être exécutés par le moniteur affecté à cet emplacement.
AVIS DE FIN DE VIE
Après août 2022, nous cesserons de prendre en charge plusieurs fonctionnalités, y compris notre URL de graphique Helm de minion privé d'origine.Pour plus de détails, notamment sur la manière dont vous pouvez facilement vous préparer à cette transition, consultez notre publication sur le forum d'assistance.
Une fois que l'attribut status de chaque pod est affiché comme running, votre CPM est opérationnel et prêt à être exécuté par le moniteur attribué à votre site privé.
Arrêter ou supprimer le CPM
Dans un environnement système conteneur Docker , utilisez la procédure Docker stop pour arrêter l'exécution du CPM. Dans un environnement de système d'orchestration de conteneur Kubernetes , utilisez la procédure Kubernetes delete pour arrêter l'exécution du CPM
Supprimez l'espace de nommage mis en place pour le CPM dans votre cluster Kubernetes:
bash
$
kubectl delete namespace YOUR_NAMESPACE
Afficher l'aide et les exemples
Utilisez ces options selon le cas :
Pour obtenir une liste des options d’exécution les plus couramment utilisées directement dans l’interface de ligne de commande, exécutez la commande show help .
Pour afficher des exemples d'utilisation du CPM ainsi que la liste de toutes les options d'exécution disponibles, exécutez cette commande :
bash
$
docker run quay.io/newrelic/synthetics-minion:latest help
Pour un CPM dans l'environnement du système d'orchestration de conteneurs Kubernetes , les commandes Helm show suivantes peuvent être utilisées pour afficher respectivement le chart.yaml et le values.yaml:
bash
$
helm show chart YOUR_REPO_NAME/synthetics-minion
bash
$
helm show values YOUR_REPO_NAME/synthetics-minion
Afficher les informations de licence
Pour afficher les informations de licence du logiciel open source que nous utilisons dans le CPM, exécutez la commande LICENSE.
Exécutez cette commande pour afficher les informations de licence pour les versions 2.2.27 ou supérieures de CPM :
bash
$
docker run quay.io/newrelic/synthetics-minion:latest LICENSE
Certains de nos logiciels open source sont répertoriés sous plusieurs licences logicielles, et dans ce cas, nous avons répertorié la licence que nous avons choisi d'utiliser. Nos informations de licence sont également disponibles dans notre documentation de licences.
Configurer le CPM
Vous pouvez configurer le minion privé conteneurisé (CPM) avec des modules de nœuds personnalisés, conserver les données entre les lancements, utiliser des variables d'environnement, et bien plus encore. Pour plus d'informations, voir configuration de CPM.
Réseaux
Pour Docker et Kubernetes, le CPM et ses contenaires runners hériteront des paramètres réseau de l'hôte. Pour un exemple de ceci sur un environnement système de conteneur Docker , consultez le site Docker .
Un nouveau réseau de ponts est créé pour chaque conteneur de coureur. Cela signifie que les options de commande réseau telles que --network et --dns transmises au conteneur du CPM au lancement (comme via les commandes d'exécution Docker sur un environnement système de conteneur Docker ) ne sont pas héritées ou utilisées par le conteneur d'exécution.
Lorsque ces réseaux sont créés, ils proviennent du pool d’adresses IP par défaut configuré pour le daemon. Pour un exemple de ceci sur un environnement système de conteneur Docker , consultez le site Docker.
En règle générale, le réseau de coureurs est supprimé une fois la vérification terminée. Cependant, si un CPM se ferme alors qu'une vérification est toujours en cours, ou se ferme dans une autre circonstance inattendue, ces réseaux peuvent devenir orphelins. Cela peut potentiellement utiliser l’espace d’adresse IP disponible pour le daemon Docker.
Si cela se produit, vous pouvez voir des entrées INTERNAL ENGINE ERROR code: 31 dans votre logging du CPM lorsque vous essayez de créer un nouveau conteneur runner. Pour les nettoyer uniquement dans les environnements système de conteneur Docker , exécutez docker network prune.
Sécurité, sandboxing et exécution en tant que non-root
Par défaut, le logiciel exécuté à l'intérieur d'un CPM est exécuté avec les privilèges utilisateur root . Cela convient à la plupart des scénarios, car l’exécution est en sandbox.
Dans un environnement système de conteneur Docker : pour modifier le profil AppArmor par défaut utilisé par le conteneur que le CPM génèrent pour exécuter le moniteur, consultez la variable d'environnementMINION_RUNNER_APPARMOR (CPM version 3.0.3 ou supérieur) ou MINION_DOCKER_RUNNER_APPARMOR (version CPM jusqu'à v3.0.2).
Pour exécuter le CPM en tant qu'utilisateur non root, des étapes supplémentaires sont requises :
Si votre environnement nécessite que vous exécutiez le CPM en tant qu'utilisateur non root, suivez cette procédure. Dans l'exemple suivant, l'utilisateur non root est my_user.
Assurez-vous que my_user peut utiliser le moteur Docker sur l'hôte :
Vérifiez que my_userappartient au groupe système "docker". L'accès root limité au docker.sock est toujours nécessaire pour créer des réseaux de ponts.
Vérifiez que my_user dispose des autorisations de lecture/écriture sur tous les répertoires et volumes transmis à CPM. Pour définir ces autorisations, utilisez la commande chmod .
Obtenez le uid de my_user à utiliser dans la commande d'exécution : id -u my_user.
Une fois ces conditions remplies, utilisez l'option "-u <uid>:<gid>" lors du lancement de CPM :
bash
$
docker run ... -u1002...
OU
bash
$
docker run ... -u1002-eDOCKER_HOST=http://localhost:2375 ...
Référence d'image Docker
Une seule image Docker CPM sert à la fois l'environnement Docker conteneur système et l'environnement Kubernetes conteneur orchestration système. L'image Docker est hébergée sur quay.io. Pour vous assurer que votre image Docker est à jour, consultez le référentiel quay.io newrelic/synthetics-minion.
Considérations supplémentaires pour la connexion au CPM
Connexion
Description
CPMs sans accès Internet
Un CPM peut fonctionner sans accès à Internet, mais avec quelques exceptions. Le contrôle de santé de l'Internet public peut être désactivé à l'aide des variables d'environnement nommées MINION_NETWORK_HEALTHCHECK_DISABLED pour un environnement de système de conteneur Docker ou synthetics.minionNetworkHealthCheckDisabled pour un environnement de système d'orchestration de conteneur Kubernetes. Le CPM doivent pouvoir contacter le domaine "synthetics-horde.nr-data.net" . Cela est nécessaire pour qu'il puisse signaler les données à New Relic et recevoir le moniteur à exécuter. Demandez à votre administrateur réseau si cela constitue un problème et comment configurer des exceptions.
Communiquer avec les synthétiques via un proxy
Pour configurer la communication avec New Relic par proxy, utilisez les variables d'environnement nommées MINION_API_PROXY*.
Arguments avancés au lancement
Ceci s’applique uniquement à un environnement de conteneur Docker. Les arguments passés au conteneur CPM au lancement ne sont pas transmis au conteneur généré par le CPM. Docker n'a pas de concept d'« héritage » ou de « hiérarchie » de conteneur, et nous ne copions pas la configuration qui est transmise de CPM au conteneur exécutant le moniteur. La seule configuration partagée entre eux est celle définie au niveau du daemon Docker .