Esta tradução de máquina é fornecida para sua comodidade.
In the event of any inconsistency between the English version and the translated version, the English versionwill take priority. Please visit this page for more information.
O gerenciador de tarefas pode operar em um ambiente de sistema de contêiner Docker ou em um ambiente de sistema de orquestração de contêiner Kubernetes. O gerenciador de tarefas detectará automaticamente seu ambiente para selecionar o modo operacional apropriado.
Recurso sintético do gerenciador de tarefas
Como o gerenciador de tarefas Sintético opera como um contêiner em vez de uma máquina virtual, simplificamos a instalação, os primeiros passos e a atualização do gerenciamento e da orquestração de tarefas. Ele também vem com algumas funcionalidades adicionais:
Capacidade de aproveitar um contêiner Docker como ambiente sandbox .
Recurso específico do Kubernetes
O gerenciador de tarefas apresenta algumas funcionalidades adicionais específicas do Kubernetes:
Usa recursos CronJob do Kubernetes para executar o monitor sem ping
Não requer acesso privilegiado ao soquete Docker
Suporta cluster hospedado e local do Kubernetes
Suporta vários motores de contêiner, como Docker e Containerd
Implantável por meio de gráficos Helm, bem como YAMLs de configuração
Permite alocação de recursos baseada em tempo de execução de trabalho configurável (ping, API e browser) para gerenciamento ideal de recursos
Observabilidade oferecida através do cluster New Relic do Kubernetes Explorer
Requisito do sistema e compatibilidade
Para hospedar gerenciadores de tarefas Sintético, seu sistema deve atender aos requisitos mínimos para o ambiente de sistema escolhido.
Cuidado
Não modifique nenhum arquivo do gerenciador de tarefas Sintético. A New Relic não se responsabiliza por quaisquer modificações que você fizer. Para obter mais informações, entre em contato com seu representante de conta ou com um representante técnico de vendas da New Relic.
Compatibilidade para
Requisitos
Sistema operacional
Linux kernel: 3.10 ou superior macOS: 10.11 ou superior Windows: Windows 10 de 64 bits ou superior
Você também deve configurar Docker para executar o contêiner Linux para que os gerenciadores de tarefas Sintético funcionem em sistemas Windows.
O gerenciador de tarefas Docker Sintético não foi projetado para uso com orquestradores de contêineres como AWS ECS, Docker Swarm, Apache Mesos, Azure contêiner instância, etc. Executar o gerenciador de tarefas Docker Sintético em um orquestrador de contêiner resultará em problemas inesperados porque ele próprio é um orquestrador de contêiner. Se você estiver usando orquestração de contêineres, consulte nossos requisitos do gerenciador de tarefas Kubernetes Sintético.
Compatibilidade para
Requisitos
Sistema operacional
Linux kernel: 3.10 ou superior macOS: 10.11 ou superior
O contêiner Linux, incluindo o gerenciador de tarefas, é executado apenas em nós Linux K8s.
Processador
Uma CPU moderna e multi-core
Podde gerenciador de tarefas sintético
CPU (vCPU/Core): 0,5 até 0,75 Memory: 800 Mi até 1.600 Mi
Os recursos alocados para um pod do gerenciador de tarefas Sintético são configuráveis pelo usuário.
Podde tempo de execução de ping
CPU (vCPU/Core): 0,5 até 0,75 Memory: 500 Mi até 1 Gi
Considerações adicionais:
Os recursos alocados para um pod de tempo de execução de ping são configuráveis pelo usuário.
A proporção máxima de recursos de solicitação de limite para CPU e memória é 2.
Podtempo de execução da API Node.js
CPU (vCPU/Core): 0,5 até 0,75 Memory: 1.250 Mi até 2.500 Mi
Considerações adicionais:
Os recursos alocados para um pod de tempo de execução da API Node.js são configuráveis pelo usuário.
A proporção máxima de recursos de solicitação de limite para CPU e memória é 2.
Podde tempo de execução do browser Node.js
CPU (vCPU/Core): 1,0 até 1,5 Memory: 2.000 Mi até 3.000 Mi
Considerações adicionais:
Os recursos alocados para um pod de tempo de execução do browser Node.js são configuráveis pelo usuário.
A proporção máxima de recursos de solicitação de limite para CPU e memória é 2.
Para visualizar versões, dependência, valores padrão de quantos pods de tempo de execução iniciam com cada gerenciador de tarefas Sintético e muito mais, consulte Mostrar ajuda e exemplos abaixo.
Chave de localização privada
Antes de lançar os gerenciadores de empregos Sintético, você deve ter uma chave de localização privada. Seu gerenciador de tarefas Sintético usa a chave para autenticar no New Relic e executar o monitoramento associado a essa localização privada.
Para encontrar a chave da localização privada existente:
, localize a localização privada à qual você deseja que seu gerente de tarefas Sintético seja atribuído.
Observe a chave associada à localização privada com a chave
ícone.
Instalar, atualizar e configurar o gerenciador de tarefas Sintético
Se você estiver executando mais de um contêiner Docker localização privada no mesmo host, você terá conflitos de porta. Para evitar essa contenção de porta, certifique-se de fazer o seguinte ao iniciar a configuração dos gerenciadores de tarefas:
Execute gerenciadores de tarefas e chamadas por minuto em hosts diferentes.
Execute cada gerenciador de tarefas em um host separado.
Execute cada chamada por minuto em um host diferente.
A menos que hospede as imagens em um repositório de imagens local, você precisa permitir conexões com docker.io por meio de seu firewall para que docker possa extrair o gerenciador de tarefas Sintético e o tempo de execução das imagens Synthetics. Quando o gerenciador de tarefas Sintético é iniciado, as imagens de tempo de execução são extraídas automaticamente. Consulte Configuração do ambiente Docker e Configuração do ambiente Kubernetes para obter detalhes sobre como definir um repositório local e o endpoint de registro do executor.
Verifique se o pod do gerenciador de tarefas Sintético está instalado e funcionando:
kubectl get -n YOUR_NAMESPACE pods
Assim que o atributo status de cada pod for mostrado como running, seu gerenciador de tarefas Sintético estará ativo e pronto para executar o monitoramento atribuído à sua localização privada.
Pare ou exclua o gerenciador de tarefas Sintético
Em um ambiente de sistema de contêiner Docker , use o procedimento Docker stop para interromper a execução do gerenciador de tarefas Sintético. Em um ambiente de sistema de orquestração de contêiner Kubernetes, use o procedimento delete do Kubernetes para interromper a execução do gerenciador de tarefa Sintético.
Exclua o namespace configurado para o gerenciador de tarefas Sintético em seu cluster do Kubernetes:
kubectl delete namespace YOUR_NAMESPACE
Dependência de sandbox e Docker
Sandboxing e Docker dependência são aplicáveis ao gerenciador de tarefas Sintético em um ambiente de sistema de contêiner Docker .
O gerenciador de tarefas Sintético é executado em Docker e é capaz de aproveitar Docker como uma tecnologia de sandbox. Isso garante o isolamento completo da execução do monitor, o que melhora a segurança, a confiabilidade e a repetibilidade. Cada vez que um monitor de script ou browser é executado, o gerenciador de tarefas Sintético cria um novo contêiner Docker para executá-lo usando o tempo de execução correspondente.
O contêiner do gerenciador de tarefas Sintético precisa ser configurado para se comunicar com o mecanismo docker para gerar contêineres de tempo de execução adicionais. Cada contêiner gerado é então dedicado a executar uma verificação associada ao monitor Sintético em execução na localização privada à qual o contêiner do gerenciador de tarefas Sintético está associado.
Há uma dependência crucial no lançamento. Para ativar o sandbox, certifique-se de que:
Seu soquete UNIX docker gravável é montado na variável de ambiente/var/run/docker.sock ou DOCKER_HOST. Para obter mais informações, consulte Opção de soquete Daemon do Docker.
Cuidado
A contagem de núcleos no host determina quantos contêineres de tempo de execução o gerenciador de tarefas Sintético pode executar simultaneamente no host. Como os requisitos de memória são dimensionados para a contagem esperada do contêiner de tempo de execução, recomendamos not running multiple synthetics job managers on the same host para evitar contenção de recursos.
Por padrão, o software executado dentro de um gerenciador de tarefas Sintético é executado com root privilégios de usuário. Isso é adequado para a maioria dos cenários, pois a execução ocorre em área restrita.
Para executar o gerenciador de tarefas Sintético como um usuário não root, são necessárias etapas adicionais:
Se o seu ambiente exigir que você execute o gerenciador de tarefas Sintético como um usuário não-root, siga este procedimento. No exemplo a seguir, o usuário não root é my_user.
Certifique-se de que my_user possa usar o mecanismo Docker no host:
Verifique se my_user tem permissões de leitura/gravação para todos os diretórios e volumes passados para o gerenciador de tarefas Sintético. Para definir essas permissões, use o comando chmod .
Obtenha o uid de my_user para uso no comando de execução: id -u my_user.
Uma vez atendidas essas condições, use a opção "-u <uid>:<gid>" ao iniciar o gerenciador de tarefas Sintético:
docker run ... -u 1002 ...
OU
docker run ... -u 1002 -e DOCKER_HOST=http://localhost:2375 ...
Entenda seus ambientes docker ou Kubernetes
Abaixo estão informações adicionais sobre como manter e compreender o ambiente de contêiner do gerenciador de tarefas. Visualize informações de licença, entenda as configurações de rede do gerenciador de tarefas e confira o repositório de imagens docker .
Para um gerenciador de tarefas Sintético no ambiente do sistema de orquestração de contêineres Kubernetes, os seguintes comandos Helm show podem ser usados para visualizar o chart.yaml e o values.yaml, respectivamente:
helm show chart YOUR_REPO_NAME/synthetics-job-manager
helm show values YOUR_REPO_NAME/synthetics-job-manager
Alguns de nossos softwares de código aberto estão listados sob diversas licenças de software e, nesse caso, listamos a licença que escolhemos usar. Nossas informações de licença também estão disponíveis em nossa documentação de licenças.
Tanto para docker quanto para Kubernetes, o gerenciador de tarefas Sintético e seu contêiner de runtime herdarão as configurações de rede do host. Para obter um exemplo disso em um ambiente de sistema de contêiner docker , consulte o sitedocker .
Uma rede bridge é criada para comunicação entre o gerenciador de tarefas Sintético e o contêiner runtime. Isso significa que opções de comando de rede como --network e --dns passadas para o contêiner do gerenciador de tarefas Sintético no lançamento (como por meio de comandos docker run em um ambiente de sistema docker contêiner) não são herdadas ou usadas pelos contêineres de tempo de execução.
Quando essas redes são criadas, elas extraem do pool de endereços IP padrão configurado para o daemon. Para obter um exemplo disso em um ambiente de sistema de contêiner Docker , consulte o site Docker .
Uma única imagem docker do gerenciador de tarefas Sintético atende tanto o ambiente do sistema de contêineres docker quanto o ambiente do sistema de orquestração de contêineres Kubernetes. A imagem docker está hospedada no docker Hub. Para garantir que sua imagem docker esteja atualizada, consulte o repositóriodocker Hub newrelic/Sintético-job-manager.
Considerações adicionais para conexão do gerenciador de tarefas Sintético
Conexão
Descrição
Gestores de trabalho Sintético sem acesso à Internet
Um gestor de empregos Sintético pode operar sem acesso à internet, mas com algumas exceções. O gerenciador de tarefas do Sintético precisa poder entrar em contato com o domínio "synthetics-horde.nr-data.net" . Isso é necessário para que ele reporte dados ao New Relic e receba o monitor para execução. Pergunte à administração da rede se isso é um problema e como configurar exceções.
Comunique-se com o Sintético através de um proxy
Para configurar a comunicação com o New Relic por proxy, use as variáveis de ambiente denominadas HORDE_API_PROXY*.
Argumentos aprovados no lançamento
Isso se aplica apenas a um ambiente de contêiner docker . Os argumentos passados para o contêiner do gerenciador de tarefas Sintético no lançamento não são repassados para os contêineres de tempo de execução gerados pelo gerenciador de tarefas Sintético. docker não tem conceito de "herança" ou "hierarquia" de contêiner, e não copiamos a configuração que é passada do gerenciador de tarefas Sintético para o runtime contêiner. A única configuração compartilhada entre eles é aquela definida no nível do daemon do Docker .