Te ofrecemos esta traducción automática para facilitar la lectura.
En caso de que haya discrepancias entre la versión en inglés y la versión traducida, se entiende que prevalece la versión en inglés. Visita esta página para obtener más información.
El administrador de trabajos puede operar en un entorno de sistema de contenedor docker o en un entorno de sistema de orquestación de contenedor de Kubernetes. El administrador de trabajos detectará automáticamente su entorno para seleccionar el modo de funcionamiento apropiado.
Característica del gestor de trabajo sintético
Debido a que el administrador de trabajos de Sintético opera como un contenedor en lugar de una máquina virtual, hemos simplificado la instalación, la introducción y la actualización de la administración y orquestación de trabajos. También viene con algunas funciones adicionales:
Seguridad mejorada y soporte para la ejecución de usuarios no root .
Capacidad de aprovechar un contenedor Docker como entorno sandbox .
Característica específica de Kubernetes
El administrador de trabajos introduce algunas funciones adicionales específicas de Kubernetes:
Utiliza recursos de Kubernetes CronJob para ejecutar un monitor sin ping
No requiere acceso privilegiado al socket de la docker
Soporta clúster de Kubernetes alojado y on-premise
Admite varios motores de contenedores como Docker y Containerd
Implementable a través de gráficos Helm y YAML de configuración
Permite la asignación de recursos basada en el tiempo de ejecución del trabajo configurable (ping, API y browser) para una gestión óptima de los recursos.
Observabilidad ofrecida a través del explorador New Relic clúster de Kubernetes
requisito del sistema y compatibilidad
Para alojar administradores de trabajos de Sintético, su sistema debe cumplir con los requisitos mínimos para el entorno del sistema elegido.
Advertencia
No modifique ningún archivo del administrador de trabajos de Sintético. New Relic no es responsable de las modificaciones que realice. Para obtener más información, comuníquese con su representante de cuenta o con un representante técnico de ventas de New Relic.
Compatibilidad para
Requisitos
Sistema operativo
Linux kernel: 3.10 o superior macOS: 10.11 o superior Windows: Windows 10 de 64 bits o superior
También debe configurar docker para ejecutar el contenedor de Linux para que los administradores de trabajos de Sintético funcionen en sistemas Windows.
El administrador de trabajos docker Sintético no está diseñado para usarse con orquestadores de contenedores como AWS ECS, docker Swarm, Apache Mesos, instancia de contenedor de Azure, etc. La ejecución del administrador de trabajos docker Sintético en un orquestador de contenedores generará problemas inesperados porque es en sí mismo un orquestador de contenedores. Si utiliza la orquestación de contenedores, consulte nuestros requisitos del administrador de trabajos de Kubernetes Sintético.
Compatibilidad para
Requisitos
Sistema operativo
Linux kernel: 3.10 o superior macOS: 10.11 o superior
El contenedor de Linux, incluido el administrador de trabajos, solo se ejecuta en nodos Linux K8.
Procesador
Una CPU moderna y multinúcleo
Podde gestión de trabajos Sintético
CPU (vCPU/Core): 0,5 hasta 0,75 Memory: 800Mi hasta 1600Mi
Los recursos asignados a un pod de administrador de trabajos de Sintético son configurables por el usuario.
Podde tiempo de ejecución de ping
CPU (vCPU/Core): 0,5 hasta 0,75 Memory: 500Mi hasta 1Gi
Consideraciones adicionales:
Los recursos asignados a un pod de tiempo de ejecución de ping son configurables por el usuario.
La relación máxima de recursos de solicitud de límite tanto para la CPU como para la memoria es 2.
Podde tiempo de ejecución de API de Node.js
CPU (vCPU/Core): 0,5 hasta 0,75 Memory: 1250Mi hasta 2500Mi
Consideraciones adicionales:
Los recursos asignados a un pod de tiempo de ejecución de API de Node.js son configurables por el usuario.
La relación máxima de recursos de solicitud de límite tanto para la CPU como para la memoria es 2.
Runtime de ejecución Node.js browser pod
CPU (vCPU/Core): 1,0 hasta 1,5 Memory: 2000Mi hasta 3000Mi
Consideraciones adicionales:
Los recursos asignados a un pod de tiempo de ejecución browser Node.js son configurables por el usuario.
La relación máxima de recursos de solicitud de límite tanto para la CPU como para la memoria es 2.
Para ver las versiones, dependencias, valores predeterminados de cuántos pods de tiempo de ejecución se inician con cada administrador de trabajos de Sintético y más, consulte Mostrar ayuda y ejemplos a continuación.
Clave de ubicación privada
Antes de lanzar los gestores de trabajos de Sintético, debes tener una clave de ubicación privada. Su administrador de trabajos de Sintético usa la clave para autenticarse en New Relic y ejecutar el monitor asociado con esa ubicación privada.
Para encontrar la clave de una ubicación privada existente:
En el índice Private locations , localice la ubicación privada a la que desea que se asigne su administrador de trabajos de Sintético.
Tenga en cuenta la clave asociada a la ubicación privada con la clave icono.
Instalar, actualizar y configurar el administrador de trabajos Sintético
Si está ejecutando más de un contenedor de ubicación privada Docker en el mismo host, tendrá conflictos de puertos. Para evitar esta contención de puertos, asegúrese de hacer lo siguiente cuando comience a configurar administradores de trabajos:
Ejecute administradores de trabajos y llamadas por minuto en diferentes hosts.
Ejecute cada administrador de trabajos en un host independiente.
Ejecute cada llamada por minuto en un host diferente.
A menos que aloje las imágenes en un repositorio de imágenes local, debe permitir conexiones a docker.io a través de su firewall para que docker pueda extraer el administrador de trabajos Sintético y el tiempo de ejecución de imágenes sintéticas. Cuando se inicia el administrador de trabajos de Sintético, las imágenes en tiempo de ejecución se extraen automáticamente. Consulte la configuración del entorno Docker y la configuración del entorno Kubernetes para obtener detalles sobre cómo configurar un repositorio local y el extremo del registro del corredor.
Ejecute el script apropiado para su sistema. Adapte el valor predeterminado común /var/run/docker.sock en los siguientes ejemplos para que coincida con su sistema.
Compruebe si el pod del administrador de trabajos de Sintético está en funcionamiento:
bash
$
kubectl get -n YOUR_NAMESPACE pods
Una vez que el atributo status de cada pod se muestra como running, su administrador de trabajos de Sintético estará activo y listo para ejecutar el monitor asignado a su ubicación privada.
Detener o eliminar el administrador de trabajos de Sintético
En un entorno de sistema de contenedor docker , utilice el procedimiento docker stop para detener la ejecución del administrador de trabajos Sintético. En un entorno de sistema de orquestación de contenedores Kubernetes, utilice el procedimiento Kubernetes delete para detener la ejecución del administrador de trabajos Sintético.
Elimina el namespace configurado para el administrador de trabajos de Sintético en tu clúster de Kubernetes:
bash
$
kubectl delete namespace YOUR_NAMESPACE
Sandboxing y dependencia Docker
El sandboxing y la dependencia docker son aplicables al administrador de trabajos Sintético en un entorno de sistema de contenedor docker .
El administrador de trabajos de Sintético se ejecuta en docker y puede aprovechar docker como tecnología de espacio aislado. Esto garantiza un aislamiento completo de la ejecución del monitor, lo que mejora la seguridad, la confiabilidad y la repetibilidad. Cada vez que se ejecuta un monitor browser o script, el administrador de trabajos de Sintético crea un nuevo contenedor docker para ejecutarlo utilizando el tiempo de ejecución correspondiente.
El contenedor del administrador de trabajos Sintético debe configurarse para comunicarse con el motor docker a fin de generar contenedores de tiempo de ejecución adicionales. Luego, cada contenedor generado se dedica a ejecutar una verificación asociada con el monitor Sintético que se ejecuta en la ubicación privada a la que está asociado el contenedor del administrador de trabajos Sintético.
Existe una dependencia crucial en el lanzamiento. Para habilitar el espacio aislado, asegúrese de que:
El recuento de núcleos en el host determina cuántos contenedores de tiempo de ejecución puede ejecutar el administrador de trabajos Sintético simultáneamente en el host. Dado que los requisitos de memoria se ajustan al recuento esperado del contenedor de tiempo de ejecución, recomendamos not running multiple synthetics job managers on the same host para evitar la contención de recursos.
Seguridad, espacio aislado y ejecución como no root
De forma predeterminada, el software que se ejecuta dentro de un administrador de trabajos de Sintético se ejecuta con root privilegios de usuario. Esto es adecuado para la mayoría de los escenarios, ya que la ejecución está protegida.
Para ejecutar el administrador de trabajos de Sintético como usuario no root, se requieren pasos adicionales:
Si su entorno requiere que ejecute el administrador de trabajos de Sintético como usuario no root, siga este procedimiento. En el siguiente ejemplo, el usuario no root es my_user.
Asegúrese de que my_user pueda utilizar el motor Docker en el host:
Verifique que my_user tenga permisos de lectura/escritura en todos los directorios y volúmenes pasados al administrador de trabajos de Sintético. Para establecer estos permisos, utilice el comando chmod .
Obtenga el uid de my_user para usarlo en el comando de ejecución: id -u my_user.
Una vez que se cumplan estas condiciones, utilice la opción "-u <uid>:<gid>" al iniciar el administrador de trabajos de Sintético:
bash
$
docker run ... -u1002...
O
bash
$
docker run ... -u1002-eDOCKER_HOST=http://localhost:2375 ...
Comprenda sus entornos docker o Kubernetes
A continuación se muestra información adicional sobre cómo mantener y comprender el entorno de contenedor del administrador de trabajos. Vea información de licencia, comprenda la configuración de red del administrador de trabajos y consulte el repositorio de imágenes docker .
Para un administrador de trabajos de Sintético en el entorno del sistema de orquestación de contenedores de Kubernetes, se pueden usar los siguientes comandos de Helm show para ver chart.yaml y values.yaml, respectivamente:
bash
$
helm show chart YOUR_REPO_NAME/synthetics-job-manager
bash
$
helm show values YOUR_REPO_NAME/synthetics-job-manager
Parte de nuestro software de código abierto aparece bajo varias licencias de software y, en ese caso, hemos enumerado la licencia que hemos elegido utilizar. La información de nuestra licencia también está disponible en la documentación de nuestras licencias.
Tanto para docker como para Kubernetes, el administrador de trabajos de Sintético y su contenedor de tiempo de ejecución heredarán la configuración de red del host. Para ver un ejemplo de esto en un entorno de sistema de contenedor docker , consulte el sitiodocker .
Se crea una red puente para la comunicación entre el administrador de trabajos de Sintético y el contenedor de tiempo de ejecución. Esto significa que las opciones de comando de red como --network y --dns que se pasan al contenedor del administrador de trabajos de Sintético en el momento del lanzamiento (como a través de comandos de ejecución docker en un entorno de sistema de contenedor docker ) no son heredadas ni utilizadas por los contenedores de tiempo de ejecución.
Cuando se crean estas redes, se extraen del grupo de direcciones IP predeterminado configurado para daemon. Para ver un ejemplo de esto en un entorno de sistema de contenedor Docker, consulte el sitio Docker .
Una única imagen docker del administrador de trabajos de Sintético sirve tanto al entorno del sistema de contenedor docker como al entorno del sistema de orquestación de contenedores de Kubernetes. La imagen docker está alojada en docker Hub. Para asegurarse de que la imagen de su docker acoplable esté actualizada, consulte el repositoriodocker Hub newrelic/Sintético-job-manager.
Consideraciones adicionales para la conexión del administrador de trabajos de Sintético
Conexión
Descripción
Gestores de empleo Sintético sin acceso a Internet
Un gestor de trabajos de Sintético puede operar sin acceso a Internet, pero con algunas excepciones. El gestor de trabajos de Sintético debe poder contactar con el dominio "synthetics-horde.nr-data.net" . Esto es necesario para que informe datos a New Relic y reciba un monitor para ejecutar. Pregunte a su administrador de red si esto representa un problema y cómo configurar excepciones.
Comunicarse con Sintético a través de un proxy
Para configurar la comunicación con New Relic mediante proxy, utilice las variables de entorno denominadas HORDE_API_PROXY*.
Argumentos aprobados en el lanzamiento
Esto se aplica únicamente a un entorno de contenedor docker . Los argumentos pasados al contenedor del administrador de trabajos de Sintético en el lanzamiento no se pasan a los contenedores de tiempo de ejecución generados por el administrador de trabajos de Sintético. docker no tiene ningún concepto de "herencia" o "jerarquía" de contenedor, y no copiamos la configuración que se pasa desde el administrador de trabajos de Sintético al contenedor de tiempo de ejecución. La única configuración compartida entre ellos es la establecida en el nivel del daemon Docker .