Implantar um host de conector local

Conheça as etapas técnicas para implantar, configurar e manter os Hosts de Conector Local (OPCH) para suas integrações com o Tulip.

Este artigo é um guia de referência técnica para pessoas responsáveis pela implantação física e pelo gerenciamento do ciclo de vida do OPCH. O Connector Host é um serviço usado para facilitar conexões de

serviços web externos, bancos de dados e servidores OPC UA. Todas as instâncias do Tulip possuem um Host de Conector na Nuvem por padrão.

Há várias considerações a serem feitas ao determinar se um Host de Conector Local é a arquitetura adequada.

Pré-requisitos

Antes de continuar, certifique-se de ter aprendido os conceitos básicos sobre os Hosts de Conector do Tulip:* Hosts de conector* Hosts de conector locais

Rede

A justificativa mais comum para implantar um Host de Conector Local são as vantagens que ele oferece ao se conectar a sistemas hospedados em uma rede local. Com a oferta local, todas as conexões do Tulip para sistemas externos partem de dentro da sua rede local. Todas as conexões da sua rede são de saída para o Tulip por meio de um WebSocket seguro.

Isso contrasta com os hosts de conector na nuvem, que exigem acesso de entrada aos serviços. Normalmente, essa é uma decisão da equipe de TI para permitir conexões WebSocket seguras de entrada da nuvem do Tulip para o serviço, muitas vezes utilizando regras de redirecionamento de porta no roteador/firewall da WAN.

Implantar um Host de Conector Local

Padrões técnicos

Quando se decide implantar uma solução local, o Tulip recomenda uma abordagem de autoatendimento utilizando uma imagem Docker distribuída. A maneira mais fácil de fazer isso seria usar uma máquina virtual com uma distribuição Linux.

A Tulip também recomenda hospedar apenas um host de conector local por máquina virtual para evitar um ponto único de falha nos sites.

Requisitos da máquina virtual:

• RAM - 4 GB
• ROM – disco com 8 a 16 GB
• CPU – 2 núcleos
• Versão do Docker — 20.10 ou superior

Quanto aos requisitos de rede, o Host do Conector Local possui o seguinte:

• Um endereço IP
• Resolução de DNS para
• Acesso de saída na porta 443 para o Tulip (IPs listados aqui)
• Acesso de saída ao repositório do Docker aqui
• Acesso de saída a todos os sistemas externos relevantes com as respectivas portas

Consulte a lista completa de requisitos de rede aqui

Implantação

A seção a seguir descreve como implantar um Host de Conector Local em diversos ambientes. Tanto a AWS quanto o Azure oferecem serviços de contêineres capazes de executar a imagem do Docker.

AWS

Use a interface de usuário da Web e este conjunto de instruções: https://aws.amazon.com/getting-started/hands-on/deploy-docker-containers/

Azure (Bash): LTS16+ OPCH

az container create `-g <NOME DO GRUPO DE RECURSOS NO AZURE> `--name <NOME DO CONTÊINER> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:<TAG>--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<SEU SITE>.tulip.co' `TULIP_MACHINE_SECRET='<SEGREDO>' `TULIP_DEVICE_TYPE='onprem' `TULIP_LOGGING_TO_TULIP=true`TULIP_TELEMETRY_TO_TULIP=true`TULIP_CONNECTORS_HTTP_PROXY='' `TULIP_CONNECTORS_HTTPS_PROXY=''

Azure (Bash): OPCH pré-LTS16

az container create `-g <NOME DO GRUPO DE RECURSOS NO AZURE> `--name <NOME DO CONTÊINER> `--cpu 2 `--memory 3 `--restart-policy Always `--public.ecr.aws/tulip/connector-host:`--os-type Linux `-e TULIP_UUID='<UUID>' `TULIP_FACTORY='https://<SEU SITE>.tulip.co' `TULIP_MACHINE_SECRET='<SEGREDO>' `TULIP_DEVICE_TYPE='onprem' `CONNECTORS_HTTP_PROXY='' `CONNECTORS_HTTPS_PROXY=''

VM Linux: LTS16+ OPCH

docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e TULIP_LOGGING_TO_TULIP=true \ -e TULIP_TELEMETRY_TO_TULIP=true \ -e TULIP_CONNECTORS_HTTP_PROXY='' \ -e TULIP_CONNECTORS_HTTPS_PROXY='' \ --restart=always \ --net=host \ public.ecr.aws/tulip/connector-host:<TAG>

VM Linux: pré-LTS16 OPCH

 --name tulip-connector-host \  
 -e TULIP\_FACTORY='https://.tulip.co' \  
 -e TULIP\_UUID='' \  
 -e TULIP\_MACHINE\_SECRET='' \  
 -e TULIP\_DEVICE\_TYPE='onprem' \  
 -e CONNECTORS\_HTTP\_PROXY='' \  
 -e CONNECTORS\_HTTPS\_PROXY='' \  
 -e EXIT\_ON\_DISCONNECT=true \ --restart=always \  
 --net=host \  
 --mount type=volume,source=tuliplog,target=/log \  
 public.ecr.aws/tulip/connector-host:

Windows (PowerShell): LTS16+ OPCH

docker run -d --name tulip-connector-host -e TULIP_FACTORY='https://<FACTORY>.tulip.co' -e TULIP_UUID='<UUID>' -e TULIP_MACHINE_SECRET='<SECRET>' -e TULIP_DEVICE_TYPE='onprem' -e TULIP_LOGGING_TO_TULIP=true -e TULIP_TELEMETRY_TO_TULIP=true -e TULIP_CONNECTORS_HTTP_PROXY='' -e TULIP_CONNECTORS_HTTPS_PROXY='' --restart=always --net=host public.ecr.aws/tulip/connector-host:<TAG>

Windows (PowerShell): OPCH pré-LTS16

docker run -d --name tulip-connector-host -e TULIP_FACTORY='https://<FACTORY>.tulip.co' -e TULIP_UUID='<UUID>' -e TULIP_MACHINE_SECRET='<SECRET>' -e TULIP_DEVICE_TYPE='onprem' -e HTTP_PROXY='' -e HTTPS_PROXY='' -e EXIT_ON_DISCONNECT=true --restart=always --net=host --mount type=volume,source=tuliplog,target=/log public.ecr.aws/tulip/connector-host:<TAG>

Solução de problemas com erros de certificado

Se o OPCH não iniciar devido a erros do tipo “certificado autoassinado na cadeia de certificados”, a causa principal pode ser que o proxy/firewall corporativo com certificados personalizados esteja impedindo conexões seguras com o Tulip Cloud.

Sintomas: - O OPCH exibe o status “Nunca visto” - O processo é encerrado durante a inicialização - Erros na cadeia de certificados SSL nos logs

Para resolver isso, use autoridades de certificação adicionais que possam ser referenciadas durante a inicialização do OPCH com a seguinte variável de ambiente, conforme mostrado abaixo. Observe que o arquivo deve estar presente no contêiner do Docker.

Para OPCH anterior à versão LTS16: -e CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

Para OPCH LTS16+: -e TULIP_CONNECTORS_EXTRA_TRUSTED_CAS_FROM_FILES='["/etc/tulipCa/ca.pem"]'

Atualize um host de conector local

:::(Aviso) (Seu Edge IO também pode precisar de uma atualização)
O OPCH pode ser executado em dispositivos Edge IO. Se o seu dispositivo não tiver a atualização automática ativada, ele deverá ser atualizado manualmente.

Se este banner de aviso ainda aparecer após você ter concluído todas as atualizações do OPCH, certifique-se de que seu Edge IO também tenha sido atualizado.
:::

A Tulip lança atualizações para o On-Premise Connector Host de acordo com nosso cronograma de lançamentos de suporte de longo prazo (LTS). Para atualizar o serviço, siga as instruções abaixo:

O processo de atualização de um OPCH resultará em tempo de inatividade enquanto o pod estiver parado e for recriado.

1. Obtenha a versão mais recente da imagem Docker do On-Premise Connector Host.

   docker pull public.ecr.aws/tulip/connector-host:<TAG>2. Execute o comando abaixo para obter o ID do contêiner Docker.

   docker ps3. Se você tiver acesso a TULIP_FACTORY, TULIP_UUID e TULIP_MACHINE_SECRET, vá para a etapa 4. Caso contrário, execute o comando a seguir e armazene a saída desse comando em um local seguro.

   docker exec <container-id> env4. Interrompa o contêiner do Docker existente.

   docker stop <id-do-contêiner>5. Remova o contêiner Docker existente.

   docker rm <id-do-contêiner>6. Execute o comando padrão docker run utilizando o conjunto de credenciais armazenadas.

Para OPCH LTS16+: docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e TULIP_LOGGING_TO_TULIP=true \ -e TULIP_TELEMETRY_TO_TULIP=true \ -e TULIP_CONNECTORS_HTTP_PROXY='' \ -e TULIP_CONNECTORS_HTTPS_PROXY='' \ --restart=always \ --net=host \ public.ecr.aws/tulip/connector-host:<TAG>Para OPCH anterior à versão LTS16: docker run -d \ --name tulip-connector-host \ -e TULIP_FACTORY='https://<FACTORY>.tulip.co' \ -e TULIP_UUID='<UUID>' \ -e TULIP_MACHINE_SECRET='<SECRET>' \ -e TULIP_DEVICE_TYPE='onprem' \ -e CONNECTORS_HTTP_PROXY='' \ -e CONNECTORS_HTTPS_PROXY='' \ -e EXIT_ON_DISCONNECT=true \ --restart=always \ --net=host \ --mount type=volume,source=tuliplog,target=/log \ public.ecr.aws/tulip/connector-host:<TAG>

1. Confirme se o novo contêiner do Docker está ativo.

   docker ps

Use os ambientes dos conectores para testar sua atualização

Cada conector possui três ambientes diferentes (produção, pré-produção e desenvolvimento) e cada um desses ambientes pode ter seu próprio host de conector, podendo ser de versões diferentes. Dependendo do estado do aplicativo (versão em desenvolvimento, aguardando aprovação, publicada), um ambiente diferente pode ser utilizado.O processo esperado para realizar a validação do host do conector deve ser: 1. Atualize seu OPCH de desenvolvimento 2. Atualize o host do conector de validação (o ambiente de pré-produção aponta para o de desenvolvimento neste caso) 1. Teste seu conector na página de conectores ou no modo de desenvolvimento da sua aplicação 3. Quando os testes de validação estiverem concluídos, atualize o host do conector de produção

Consulte Ambientes de conectores para obter mais informações.

Como alternativa, você pode atualizar seu OPCH na instância de desenvolvimento e, em seguida, atualizar com segurança o ambiente de produção.

Registro em ferramentas externas de gerenciamento de logs

Você pode encaminhar os logs do host do conector local para ferramentas de terceiros para monitoramento centralizado e solução de problemas. O OPCH oferece suporte ao Datadog, Grafana Loki e Splunk por meio de variáveis de ambiente. Os tipos de logs disponíveis estão relacionados à integridade do seu OPCH (especialmente no que diz respeito à sua conexão com a fábrica), à execução de chamadas do conector e aos logs de assinatura. Como parte do fluxo de inicialização do OPCH, os usuários podem definir a configuração da ferramenta de registro externa para a qual desejam que os logs sejam encaminhados. Se forem adicionadas credenciais para vários serviços, os logs serão enviados a todos os serviços

1. Escolha seu destino
2. Datadog: endpoint global; é necessária apenas uma chave de API.
3. Grafana Loki: Loki hospedado pelo cliente; a URL pode incluir autenticação básica.
4. Splunk (HEC): múltiplas instâncias; requer URL e token.
5. Adicione variáveis de ambiente. Adicione as variáveis abaixo ao ambiente do host do conector. Use apenas aquelas correspondentes ao destino escolhido.

Datadog

• TULIP_LOGGING_DATADOG_API_KEY=<sua_chave_API_do_Datadog>

Grafana Loki

• TULIP_LOGGING_LOKI_URL=https://<usuário>:<senha>@loki.seu-domínio.com/loki/api/v1/push
  (A autenticação básica é suportada pela inclusão de usuário:senha na URL — opcional.)

Splunk (HEC)

• TULIP_LOGGING_SPLUNK_URL=https://splunk.your-domain.com:8088/services/collector
• TULIP_LOGGING_SPLUNK_TOKEN=<seu_token_splunk_hec>

1. Reinicie o host do conector

Reinicie o serviço para que as novas variáveis de ambiente entrem em vigor.

1. Verifique a entrega

Gere atividade (por exemplo, execute uma função do conector) e confirme se os logs aparecem no seu destino:

• Datadog: Verifique os logs recentes para o nome do seu host/serviço.
• Loki: Faça uma consulta por rótulo do host ou por uma subseqüência conhecida da mensagem no Grafana Explore.
• Splunk: Pesquise eventos recentes do seu host (por exemplo, index=<seu_índice> source="tulip-connector-host").
• Alterar ou desativar o registro de logs
• Para trocar de destino, atualize as variáveis para o novo provedor (e remova as antigas).
• Para desativar, remova as variáveis de registro e reinicie o serviço.

Informações adicionais

Implementação baseada nos exportadores do Grafana Alloy:

Exportador do Datadog:https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.datadog/

Exportador Splunk HEC: https://grafana.com/docs/alloy/next/reference/components/otelcol/otelcol.exporter.splunkhec/

Carga de chamadas de entrada e saída

Esta seção explica quantas solicitações HTTP o OPCH envia para o Tulip Cloud. Essas solicitações podem ser agrupadas em solicitações de taxa fixa (sempre em execução) e solicitações de taxa variável (dependentes da sua configuração e atividade).

Solicitações de taxa fixa

Essas solicitações ocorrem em uma taxa constante e previsível:

Solicitações com frequência variável

Essas solicitações dependem da sua configuração e da atividade.
Quanto mais alterações ou eventos ocorrerem, maior será a taxa de solicitações.

Exemplo de cálculo

Considere uma configuração com: - 1 fonte de dados da máquina - 500 atributos da máquina, cada um reportando dados a 1 Hz (uma vez por segundo)

Taxa de solicitações no pior caso:`Taxa (pior caso) = (6 + 1 + 20) + 40 + 60 + 240 = 367 solicitações/minuto

Referências adicionais

Ativar rotação de logs para o Docker

Para instâncias locais do Connector Hosts que não estejam utilizando a rotação de logs do Docker, siga as instruções documentadas aqui para garantir que o espaço em disco seja mantido adequadamente.

Verifique a integridade do seu OPCH

Para integrar o OPCH ao seu orquestrador de serviços baseado no Azure ou no Kubernetes, você pode usar a seguinte configuração:

Para OPCH LTS16+:

Para integrar o OPCH ao seu orquestrador de serviços baseado em Azure ou Kubernetes, você pode usar a seguinte configuração: O endpoint de verificação de integridade é atribuído aleatoriamente a uma porta e exposto no caminho raiz /health-check. Opcionalmente, a porta atribuída pode ser substituída definindo TULIP_HEALTH_HTTP_PORT como a porta especificada. Por exemplo: TULIP_HEALTH_HTTP_PORT = 80. Uma resposta bem-sucedida retornará um código de status HTTP 204, indicando que o serviço OPCH está em bom estado e operacional.

Para OPCH anterior à versão LTS16:

Para integrar o OPCH ao seu orquestrador de serviços baseado no Azure ou no Kubernetes, você pode usar a seguinte configuração: O endpoint de verificação de integridade precisa ser habilitado definindo a variável de ambiente CONNECTORS_HEALTHZ_SERVER_ENABLED como true.O endpoint está disponível na porta 9223 e exposto no caminho raiz /. Opcionalmente, a porta padrão 9223 pode ser substituída definindo CONNECTORS_PORT como a porta especificada. Por exemplo: CONNECTORS_PORT = 80

Uma resposta bem-sucedida retornará um código de status HTTP 200 (OK), indicando que o serviço OPCH está em bom estado e operacional.
Opcionalmente, a porta padrão 9223 pode ser substituída definindo CONNECTORS_PORT como a porta especificada. Por exemplo: CONNECTORS_PORT = 80

Uma resposta bem-sucedida retornará um código de status HTTP 200 (OK), indicando que o serviço OPCH está em bom estado e operacional.

{{snippet.Você encontrou o que estava procurando?}}