Reconhecer o runtime do Azure IoT Edge e sua arquitetura

Aplica-se a:IoT Edge 1.4 checkmark IoT Edge 1.4

Importante

A versão com suporte é a IoT Edge 1.4. Se você estiver em uma versão anterior, confira Atualizar o IoT Edge.

O runtime do IoT Edge é uma coleção de programas que transforma um dispositivo em um dispositivo IoT Edge. Coletivamente, os componentes do runtime do IoT Edge permitem que dispositivos IoT Edge recebam o código para executar na borda e informem os resultados.

O runtime do IoT Edge é responsável pelas seguintes funções em dispositivos IoT Edge:

  • Instala e atualiza as cargas de trabalho no dispositivo.

  • Mantém os padrões de segurança do Azure IoT Edge no dispositivo.

  • Garante que os módulos do IoT Edge sempre estejam em execução.

  • Relata a integridade do módulo à nuvem para monitoramento remoto.

  • Gerencie a comunicação entre:

    • Dispositivos downstream e dispositivos IoT Edge
    • Módulos em um dispositivo IoT Edge
    • Um dispositivo IoT Edge e a nuvem
    • Dispositivos IoT Edge

Screenshot of how runtime communicates insights and module health to I o T Hub.

As responsabilidades do runtime do IoT Edge se enquadram em duas categorias: gerenciamento de comunicação e de módulo. Essas duas funções são executadas por dois componentes que fazem parte do runtime do IoT Edge. O agente do IoT Edge gerencia a implantação e o monitoramento de módulos, enquanto o hub do IoT Edge é responsável pela comunicação.

Tanto o agente do IoT Edge quanto o hub do IoT Edge são módulos, assim como qualquer outro módulo em execução em um dispositivo IoT Edge. Às vezes, eles são chamados de módulos de runtime.

Agente do IoT Edge

O agente do IoT Edge é um dos dois módulos que compõem o runtime do Azure IoT Edge. Ele é responsável por instanciar módulos, fazendo com que continuem a funcionar, e indicar o status dos módulos para o Hub IoT. Esses dados de configuração são gravados como uma propriedade do módulo gêmeo do agente do IoT Edge.

O daemon de segurança do IoT Edge inicia o agente do IoT Edge na inicialização do dispositivo. O agente recupera seu módulo gêmeo do Hub IoT e inspeciona o manifesto de implantação. O manifesto de implantação é um arquivo JSON que declara os módulos que precisam ser iniciados.

Cada item no manifesto de implantação contém informações específicas sobre um módulo e é usado pelo agente do IoT Edge para controlar o ciclo de vida do módulo. Para obter mais informações sobre todas as propriedades usadas pelo agente do IoT Edge para controlar módulos, leia sobre as Propriedades do agente do IoT Edge e dos gêmeos de módulo do hub do IoT Edge.

O agente do IoT Edge envia a resposta de runtime para o Hub IoT. Veja abaixo uma lista das possíveis respostas:

  • 200 - OK
  • 400 - A configuração de implantação está malformada ou inválida.
  • 417 – O dispositivo não tem uma configuração de implantação definida.
  • 412 - A versão do esquema na configuração de implantação é inválida.
  • 406 – o dispositivo do IoT Edge está offline ou não está enviando relatórios de status.
  • 500 – ocorreu um erro no runtime do IoT Edge.

Para obter mais informações sobre a criação de manifestos de implantação, confira Saiba como implantar módulos e estabelecer rotas no IoT Edge.

Segurança

O agente do IoT Edge desempenha um papel fundamental na segurança de um dispositivo IoT Edge. Por exemplo, ele executa ações como verificar a imagem de um módulo antes de iniciá-lo.

Para obter mais informações sobre a estrutura de segurança do Azure IoT Edge, leia sobre o Gerenciador de segurança do IoT Edge.

Hub do IoT Edge

O hub do IoT Edge é o outro módulo que compõe o runtime do Azure IoT Edge. Ele atua como um proxy local para o Hub IoT expondo os mesmos pontos de extremidade de protocolo que o Hub IoT. Essa consistência significa que os clientes podem se conectar no runtime do IoT Edge da mesma forma que fariam com o Hub IoT.

O hub do IoT Edge não é uma versão completa do Hub IoT executado localmente. O hub do IoT Edge delega silenciosamente algumas tarefas ao Hub IoT. Por exemplo, o hub do IoT Edge baixa automaticamente as informações de autorização do Hub IoT na primeira conexão para permitir que um dispositivo se conecte. Depois que a primeira conexão é estabelecida, as informações de autorização são armazenadas em cache localmente pelo hub do IoT Edge. As conexões futuras desse dispositivo são autorizadas sem a necessidade de baixar as informações de autorização da nuvem novamente.

Comunicação na nuvem

Para reduzir a largura de banda que a solução IoT Edge usa, o hub do IoT Edge otimiza quantas conexões reais são feitas com a nuvem. O hub do IoT Edge usa conexões lógicas de módulos ou dispositivos downstream e as combina em uma única conexão física com a nuvem. Os detalhes desse processo são transparentes para o restante da solução. Os clientes pensam que têm sua própria conexão para a nuvem, mesmo que estejam todos sendo enviados pela mesma conexão. O hub do IoT Edge pode usar o protocolo AMQP ou MQTT para se comunicar upstream com a nuvem, independentemente dos protocolos usados por dispositivos downstream. No entanto, o hub do IoT Edge atualmente só dá suporte à combinação de conexões lógicas em uma única conexão física usando AMQP como o protocolo upstream e seus recursos de multiplexação. AMQP é o protocolo padrão de upstream.

Screenshot showing relationships to I o T Edge hub as a gateway between physical devices and I o T Hub.

O hub do IoT Edge pode determinar se ele está conectado ao Hub IoT. Se a conexão for perdida, o hub do IoT Edge salvará mensagens ou as atualizações duplicadas localmente. Depois que uma conexão é restabelecida, ela sincroniza todos os dados. A localização usada para esse cache temporário é determinada por uma propriedade do módulo gêmeo do hub do IoT Edge. O tamanho do cache não tem limite e aumentará até atingir toda a capacidade de armazenamento do dispositivo. Para obter mais informações, confira Funcionalidades offline.

Comunicação local

O hub do IoT Edge facilita a comunicação local. Ele habilita as comunicações de dispositivo para módulo e de módulo para módulo com mensagens de agente para manter os dispositivos e módulos independentes uns dos outros. O hub IoT Edge dá suporte aos recursos de roteamento de mensagens compatíveis com o Hub IoT.

Uso do roteamento

O mecanismo de agente usa os mesmos recursos de roteamento que o Hub IoT para especificar como as mensagens são passadas entre dispositivos ou módulos. Os primeiros dispositivos ou módulos especificam as entradas nas quais aceitam mensagens e as saídas nas quais as gravam. Em seguida, um desenvolvedor de soluções pode rotear mensagens entre uma fonte (por exemplo, saídas) e um destino (por exemplo, entradas) com filtros potenciais.

Screenshot showing how routes between modules go through I o T Edge hub.

O roteamento pode ser usado por dispositivos ou módulos criados com os SDKs do Dispositivo IoT do Azure usando o protocolo AMQP. Há suporte para todos os primitivos do Hub IoT do sistema de mensagens (por exemplo, telemetria), métodos diretos, C2D e gêmeos, mas não há suporte para a comunicação em tópicos definidos pelo usuário.

Para obter mais informações sobre rotas, confira Saiba como implantar módulos e estabelecer rotas no IoT Edge.

Recursos do mecanismo de agente disponíveis:

Recursos Roteamento
Telemetria D2C
Telemetria local
DirectMethods
Gêmeo
C2D para dispositivos
Ordenando
Filtragem
Tópicos definidos pelo usuário
Dispositivo para dispositivo
Transmissão local

Conectar ao hub do IoT Edge

O hub do IoT Edge aceita conexões de clientes de dispositivos ou módulos, por meio do protocolo MQTT ou AMQP.

Observação

O hub do IoT Edge dá suporte a clientes que se conectam usando MQTT ou AMQP. Ele não oferece suporte a clientes que usam HTTP.

Quando um cliente se conecta ao hub do IoT Edge, acontece o seguinte:

  1. Se o protocolo TLS (Transport Layer Security) for usado (recomendado), um canal TLS será criado para estabelecer uma comunicação criptografada entre o cliente e o hub do IoT Edge.
  2. As informações de autenticação são enviadas do cliente para o hub do IoT Edge para se identificarem.
  3. O hub do IoT Edge autoriza ou rejeita a conexão com base em sua política de autorização.

Conexões seguras (TLS)

Por padrão, o hub do IoT Edge só aceita conexões protegidas com TLS (Transport Layer Security), por exemplo, conexões criptografadas que não podem ser descriptografadas por terceiros.

Se um cliente se conectar na porta 8883 (MQTTS) ou 5671 (AMQPS) ao hub do IoT Edge, um canal TLS deverá ser criado. Durante o handshake TLS, o hub do IoT Edge envia sua cadeia de certificados que o cliente precisa validar. Para validar a cadeia de certificados, o certificado raiz do hub do IoT Edge deve ser instalado como um certificado confiável no cliente. Se o certificado raiz não for confiável, a biblioteca de clientes será rejeitada pelo hub do IoT Edge com um erro de verificação de certificado.

As etapas a serem seguidas para instalar este certificado raiz do agente em clientes de dispositivo são descritas no gateway transparente e na documentação Preparar um dispositivo downstream. Os módulos podem usar o mesmo certificado raiz que o hub do IoT Edge, usando a API daemon do IoT Edge.

Autenticação

O Hub de Borda da IoT só aceita conexões de dispositivos ou módulos que tenham uma identidade do Hub IoT. Por exemplo, aqueles que foram registrados no Hub IoT e têm um dos três métodos de autenticação de cliente suportados pelo hub IoT para provar sua identidade: autenticação de chaves simétricas, autenticação autoassinada X.509, autenticação assinada pela autoridade de certificação X.509. Essas identidades do Hub IoT podem ser verificadas localmente pelo hub do IoT Edge para que as conexões ainda possam ser feitas offline.

Atualmente, os módulos do IoT Edge dão suporte apenas à autenticação de chave simétrica.

Autorização

Verificando se um cliente pertence a seu conjunto de clientes confiáveis definido no Hub IoT. O conjunto de clientes confiáveis é especificado pela configuração de relações pai/filho ou dispositivo/módulo no Hub IoT. Quando um módulo é criado no IoT Edge, uma relação de confiança é automaticamente estabelecida entre esse módulo e seu dispositivo de IoT Edge. Esse é o único modelo de autorização com suporte pelo mecanismo de agente de roteamento.

Configuração remota

O hub do IoT Edge é totalmente controlado pela nuvem. Ele obtém sua configuração do Hub IoT por meio de seu módulo gêmeo. O gêmeo contém uma propriedade desejada chamada rotas que declara como as mensagens são passadas dentro de uma implantação. Para obter mais informações sobre rotas, confira Declarar rotas.

Além disso, várias configurações podem ser feitas definindo variáveis de ambiente no hub do IoT Edge.

Telemetria de qualidade de runtime

O IoT Edge coleta telemetria anônima do runtime do host e dos módulos do sistema para melhorar a qualidade do produto. Essas informações são chamadas de telemetria de qualidade de runtime. A telemetria coletada é enviada periodicamente como mensagens do dispositivo para a nuvem para o Hub IoT do agente de IoT Edge. Essas mensagens não aparecem na telemetria regular do cliente e não consomem nenhuma cota de mensagens.

O hub e o agente IoT Edge geram métricas que você pode coletar para entender o desempenho do dispositivo. Um subconjunto dessas métricas é coletado pelo Agente IoT Edge como parte da telemetria de qualidade do runtime. As métricas coletadas para telemetria de qualidade de runtime são rotuladas com a marca ms_telemetry. Para obter informações sobre todas as métricas disponíveis, confira Acessar métricas internas.

Quaisquer informações de identificação pessoal ou organizacional, como nomes de dispositivos e módulos, são removidas antes do upload para garantir a natureza anônima da telemetria de qualidade do runtime.

O agente IoT Edge coleta a telemetria a cada hora e envia uma mensagem ao Hub IoT a cada 24 horas.

Se você quiser recusar o envio de telemetria de runtime de seus dispositivos, há duas maneiras de fazer isso:

  • Defina a variável de ambiente SendRuntimeQualityTelemetry para false para edgeAgent ou
  • Desmarque a opção no portal do Azure durante a implantação.

Próximas etapas