Preparar a implementação da solução IoT Edge em produção

  • Artigo

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

Importante

O IoT Edge 1.4 é a versão suportada. Se tiver uma versão anterior, consulte Atualizar IoT Edge.

Quando estiver pronto para levar sua solução IoT Edge do desenvolvimento para a produção, certifique-se de que ela esteja configurada para desempenho contínuo.

As informações fornecidas neste artigo não são todas iguais. Para ajudá-lo a priorizar, cada seção começa com listas que dividem o trabalho em duas seções: importante para concluir antes de ir para a produção ou útil para você saber.

Configuração do dispositivo

Os dispositivos IoT Edge podem ser qualquer coisa, desde um Raspberry Pi até um laptop ou uma máquina virtual em execução em um servidor. Você pode ter acesso ao dispositivo fisicamente ou através de uma conexão virtual, ou ele pode ser isolado por longos períodos de tempo. De qualquer forma, você quer ter certeza de que ele está configurado para funcionar adequadamente.

  • Importante

    • Instalar certificados de produção
    • Tenha um plano de gerenciamento de dispositivos
    • Use Moby como o motor de contêiner

  • Úteis

    • Escolha o protocolo upstream

Instalar certificados de produção

Cada dispositivo IoT Edge em produção precisa de um certificado de autoridade de certificação (CA) de dispositivo instalado nele. Esse certificado de autoridade de certificação é então declarado para o tempo de execução do IoT Edge no arquivo de configuração. Para cenários de desenvolvimento e teste, o tempo de execução do IoT Edge cria certificados temporários se nenhum certificado for declarado no arquivo de configuração. No entanto, esses certificados temporários expiram após três meses e não são seguros para cenários de produção. Para cenários de produção, você deve fornecer seu próprio certificado de CA de dispositivo, seja de uma autoridade de certificação autoassinada ou comprado de uma autoridade de certificação comercial.

Para entender a função do certificado de autoridade de certificação do dispositivo, consulte Como o Azure IoT Edge usa certificados.

Para obter mais informações sobre como instalar certificados em um dispositivo IoT Edge e fazer referência a eles a partir do arquivo de configuração, consulte Gerenciar certificado em um dispositivo IoT Edge.

Tenha um plano de gerenciamento de dispositivos

Antes de colocar qualquer dispositivo em produção, você deve saber como vai gerenciar atualizações futuras. Para um dispositivo IoT Edge, a lista de componentes a atualizar pode incluir:

  • Firmware do dispositivo
  • Bibliotecas do sistema operacional
  • Motor de contentores, como Moby
  • IoT Edge
  • Certificados da AC

A Atualização de Dispositivo para o Hub IoT é um serviço que permite implantar atualizações over-the-air (OTA) para seus dispositivos IoT Edge.

Métodos alternativos para atualizar o IoT Edge exigem acesso físico ou SSH ao dispositivo IoT Edge. Para obter mais informações, consulte Atualizar o tempo de execução do IoT Edge. Para atualizar vários dispositivos, considere adicionar as etapas de atualização a um script ou usar uma ferramenta de automação como o Ansible.

Use Moby como o motor de contêiner

Um mecanismo de contêiner é um pré-requisito para qualquer dispositivo IoT Edge. Apenas o motor moby é suportado na produção. Outros mecanismos de contêiner, como o Docker, funcionam com o IoT Edge e não há problema em usar esses mecanismos para desenvolvimento. O mecanismo moby pode ser redistribuído quando usado com o Azure IoT Edge e a Microsoft fornece serviços para esse mecanismo.

Escolha o protocolo upstream

Você pode configurar o protocolo (que determina a porta usada) para comunicação upstream com o Hub IoT para o agente IoT Edge e o hub IoT Edge. O protocolo padrão é AMQP, mas você pode querer alterar isso dependendo da configuração da rede.

Os dois módulos de tempo de execução têm uma variável de ambiente UpstreamProtocol . Os valores válidos para a variável são:

  • MQTT
  • AMQP
  • MQTTWS
  • AMQPWS

Configure a variável UpstreamProtocol para o agente do IoT Edge no arquivo de configuração no próprio dispositivo. Por exemplo, se o dispositivo IoT Edge estiver atrás de um servidor proxy que bloqueia portas AMQP, talvez seja necessário configurar o agente IoT Edge para usar AMQP sobre WebSocket (AMQPWS) para estabelecer a conexão inicial com o Hub IoT.

Depois que seu dispositivo IoT Edge se conectar, continue configurando a variável UpstreamProtocol para ambos os módulos de tempo de execução em implantações futuras. Um exemplo desse processo é fornecido em Configurar um dispositivo IoT Edge para se comunicar por meio de um servidor proxy.

Implementação

  • Úteis
    • Ser consistente com o protocolo upstream
    • Configurar o armazenamento do host para módulos do sistema
    • Reduzir o espaço de memória usado pelo hub IoT Edge
    • Usar imagens de módulo corretas em manifestos de implantação
    • Esteja atento aos limites de tamanho duplo ao usar módulos personalizados
    • Configurar como as atualizações aos módulos são aplicadas

Ser consistente com o protocolo upstream

Se você configurou o agente do IoT Edge em seu dispositivo IoT Edge para usar um protocolo diferente do AMQP padrão, deverá declarar o mesmo protocolo em todas as implantações futuras. Por exemplo, se o seu dispositivo IoT Edge estiver atrás de um servidor proxy que bloqueia portas AMQP, você provavelmente configurou o dispositivo para se conectar por AMQP sobre WebSocket (AMQPWS). Ao implantar módulos no dispositivo, configure o mesmo protocolo AMQPWS para o agente do IoT Edge e o hub do IoT Edge, ou então o AMQP padrão substituirá as configurações e impedirá que você se conecte novamente.

Você só precisa configurar a variável de ambiente UpstreamProtocol para o agente IoT Edge e os módulos de hub IoT Edge. Todos os módulos adicionais adotam qualquer protocolo definido nos módulos de tempo de execução.

Um exemplo desse processo é fornecido em Configurar um dispositivo IoT Edge para se comunicar por meio de um servidor proxy.

Configurar o armazenamento do host para módulos do sistema

O hub do IoT Edge e os módulos do agente usam armazenamento local para manter o estado e habilitar mensagens entre módulos, dispositivos e a nuvem. Para maior confiabilidade e desempenho, configure os módulos do sistema para usar o armazenamento no sistema de arquivos host.

Para obter mais informações, consulte Armazenamento de host para módulos do sistema.

Reduza o espaço de memória usado pelo hub IoT Edge

Se você estiver implantando dispositivos restritos com memória limitada disponível, poderá configurar o hub IoT Edge para ser executado em uma capacidade mais simplificada e usar menos espaço em disco. No entanto, essas configurações limitam o desempenho do hub IoT Edge, portanto, encontre o equilíbrio certo que funcione para sua solução.

Não otimize o desempenho em dispositivos restritos

O hub IoT Edge é otimizado para desempenho por padrão, por isso tenta alocar grandes blocos de memória. Essa configuração pode causar problemas de estabilidade em dispositivos menores, como o Raspberry Pi. Se você estiver implantando dispositivos com recursos restritos, convém definir a variável de ambiente OptimizeForPerformance como false no hub IoT Edge.

Quando OptimizeForPerformance é definido como true, o cabeçalho do protocolo MQTT usa o PooledByteBufferAllocator, que tem melhor desempenho, mas aloca mais memória. O alocador não funciona bem em sistemas operacionais de 32 bits ou em dispositivos com pouca memória. Além disso, quando otimizado para desempenho, o RocksDb aloca mais memória para sua função como provedor de armazenamento local.

Para obter mais informações, consulte Problemas de estabilidade em dispositivos menores.

Desativar protocolos não utilizados

Outra maneira de otimizar o desempenho do hub IoT Edge e reduzir seu uso de memória é desligar as cabeças de protocolo para quaisquer protocolos que você não esteja usando em sua solução.

Os cabeçalhos de protocolo são configurados definindo variáveis de ambiente booleano para o módulo hub IoT Edge em seus manifestos de implantação. As três variáveis são:

  • amqpSettings__enabled
  • mqttSettings__enabled
  • httpSettings__enabled

Todas as três variáveis têm dois sublinhados e podem ser definidas como verdadeiro ou falso.

Reduza o tempo de armazenamento das mensagens

O módulo de hub IoT Edge armazena mensagens temporariamente se elas não puderem ser entregues ao Hub IoT por qualquer motivo. Você pode configurar por quanto tempo o hub IoT Edge mantém as mensagens não entregues antes de deixá-las expirar. Se você tiver problemas de memória em seu dispositivo, poderá reduzir o valor timeToLiveSecs no módulo gêmeo do hub IoT Edge.

O valor padrão do parâmetro timeToLiveSecs é 7200 segundos, ou seja, duas horas.

Usar imagens de módulo corretas em manifestos de implantação

Se uma imagem de módulo vazia ou errada for usada, o agente de Borda tentará carregar a imagem novamente, o que fará com que tráfego extra seja gerado. Adicione as imagens corretas ao manifesto de implantação para evitar gerar tráfego desnecessário.

Não use versões de depuração de imagens de módulo

Ao mudar de cenários de teste para cenários de produção, lembre-se de remover as configurações de depuração dos manifestos de implantação. Verifique se nenhuma das imagens de módulo nos manifestos de implantação tem o sufixo .debug . Se você adicionou opções de criação para expor portas nos módulos para depuração, remova essas opções de criação também.

Esteja atento aos limites de tamanho duplo ao usar módulos personalizados

O manifesto de implantação que contém módulos personalizados faz parte do gêmeo EdgeAgent. Reveja a limitação do tamanho duplo do módulo.

Se você implantar um grande número de módulos, poderá esgotar esse limite de tamanho duplo. Considere algumas mitigações comuns a esse limite rígido:

  • Armazene qualquer configuração no módulo duplo personalizado, que tem seu próprio limite.
  • Armazene alguma configuração que aponte para um local sem espaço limitado (ou seja, para um repositório de blobs).

Configurar como as atualizações aos módulos são aplicadas

Quando uma implantação é atualizada, o Agente de Borda recebe a nova configuração como uma atualização dupla. Se a nova configuração tiver imagens de módulo novas ou atualizadas, por padrão, o Agente de Borda processará sequencialmente cada módulo:

  1. A imagem atualizada é baixada
  2. O módulo em execução é interrompido
  3. Uma nova instância do módulo é iniciada
  4. A próxima atualização do módulo é processada

Em alguns casos, por exemplo, quando existem dependências entre módulos, pode ser desejável primeiro baixar todas as imagens atualizadas do módulo antes de reiniciar qualquer módulo em execução. Esse comportamento de atualização de módulo pode ser configurado definindo uma variável ModuleUpdateMode de ambiente do IoT Edge Agent como valor WaitForAllPullsde cadeia de caracteres. Para obter mais informações, consulte Variáveis de ambiente do IoT Edge.

"modulesContent": {
    "$edgeAgent": {
        "properties.desired": {
            ...
            "systemModules": {
                "edgeAgent": {
                    "env": {
                        "ModuleUpdateMode": {
                            "value": "WaitForAllPulls"
                        }
                    ...

Gestão de contentores

  • Importante
    • Usar tags para gerenciar versões
    • Gerir volumes
  • Úteis
    • Armazenar os contentores de runtime no registo pessoal
    • Configurar a coleta de lixo de imagem

Usar tags para gerenciar versões

Uma tag é um conceito de docker que você pode usar para distinguir entre versões de contêineres docker. Tags são sufixos como 1.1 que vão no final de um repositório de contêiner. Por exemplo, mcr.microsoft.com/azureiotedge-agent:1.1. As tags são mutáveis e podem ser alteradas para apontar para outro contêiner a qualquer momento, então sua equipe deve concordar com uma convenção a ser seguida à medida que você atualiza as imagens do módulo no futuro.

As tags também ajudam você a impor atualizações em seus dispositivos IoT Edge. Quando você enviar uma versão atualizada de um módulo para o registro do contêiner, incremente a tag . Em seguida, envie uma nova implantação para seus dispositivos com a tag incrementada. O mecanismo de contêiner reconhecerá a tag incrementada como uma nova versão e puxará a versão mais recente do módulo para o seu dispositivo.

Tags para o tempo de execução do IoT Edge

As imagens do agente do IoT Edge e do hub do IoT Edge são marcadas com a versão do IoT Edge à qual estão associadas. Há duas maneiras diferentes de usar tags com as imagens de tempo de execução:

  • Etiquetas contínuas - Utilize apenas os dois primeiros valores do número da versão para obter a imagem mais recente que corresponda a esses dígitos. Por exemplo, o 1.1 é atualizado sempre que há uma nova versão para apontar para a versão 1.1.x mais recente. Se o tempo de execução do contêiner no dispositivo IoT Edge extrair a imagem novamente, os módulos de tempo de execução serão atualizados para a versão mais recente. Implantações do portal do Azure padrão para marcas contínuas. Esta abordagem é sugerida para fins de desenvolvimento.

  • Tags específicas - Use os três valores do número da versão para definir explicitamente a versão da imagem. Por exemplo, a versão 1.1.0 não será alterada após sua versão inicial. Você pode declarar um novo número de versão no manifesto de implantação quando estiver pronto para atualizar. Esta abordagem é sugerida para fins de produção.

Gerir volumes

O IoT Edge não remove os volumes anexados a contentores de módulos. Este comportamento é propositado, uma vez que permite dados persistentes em instâncias de contentor, tais como cenários de atualização. No entanto, se estes volumes não forem utilizados, poderá originar o esgotamento do espaço em disco e erros subsequentes do sistema. Se você usa volumes do docker em seu cenário, recomendamos que você use ferramentas do docker, como o docker volume prune e o docker volume rm para remover os volumes não utilizados, especialmente para cenários de produção.

Armazenar os contentores de runtime no registo pessoal

Você sabe como armazenar imagens de contêiner para módulos de código personalizados em seu registro privado do Azure, mas também pode usá-lo para armazenar imagens de contêiner público, como os módulos de tempo de execução edgeAgent e edgeHub . Isso pode ser necessário se você tiver restrições de firewall muito rígidas, pois esses contêineres de tempo de execução são armazenados no Microsoft Container Registry (MCR).

As etapas a seguir ilustram como extrair uma imagem do Docker de edgeAgent e edgeHub para sua máquina local, marcá-la novamente, enviá-la por push para seu registro privado e, em seguida, atualizar seu arquivo de configuração para que seus dispositivos saibam extrair a imagem do seu registro privado.

  1. Puxe a imagem do Docker edgeAgent do registro da Microsoft. Atualize o número da versão, se necessário.

    # Pull edgeAgent image
docker pull mcr.microsoft.com/azureiotedge-agent:1.4

# Pull edgeHub image
docker pull mcr.microsoft.com/azureiotedge-hub:1.4

  2. Liste todas as suas imagens do Docker, localize as imagens edgeAgent e edgeHub e copie seus IDs de imagem.

    docker images

  3. Remarque suas imagens edgeAgent e edgeHub . Substitua os valores entre parênteses pelos seus.

    # Retag your edgeAgent image
docker tag <my-image-id> <registry-name/server>/azureiotedge-agent:1.4

# Retag your edgeHub image
docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.4

  4. Envie suas imagens edgeAgent e edgeHub para seu registro privado. Substitua o valor entre parênteses pelo seu.

    # Push your edgeAgent image to your private registry
docker push <registry-name/server>/azureiotedge-agent:1.4

# Push your edgeHub image to your private registry
docker push <registry-name/server>/azureiotedge-hub:1.4

  5. Atualize as referências de imagem no arquivo deployment.template.json para os módulos do sistema edgeAgent e edgeHub, substituindo mcr.microsoft.com por seu próprio "nome do registro/servidor" para ambos os módulos.

  6. Abra um editor de texto em seu dispositivo IoT Edge para alterar o arquivo de configuração para que ele saiba sobre sua imagem de registro particular.

    sudo nano /etc/aziot/config.toml

  7. No editor de texto, altere os valores da imagem em [agent.config]. Substitua os valores entre parênteses pelos seus.

    [agent.config]
image = "<registry-name/server>/azureiotedge-agent:1.4"

  8. Se o seu registo privado exigir autenticação, defina os parâmetros de autenticação em [agent.config.auth].

    [agent.config.auth]
serveraddress = "<login-server>" # Almost always equivalent to <registry-name/server>
username = "<username>"
password = "<password>"

  9. Salve as alterações e saia do editor de texto.

  10. Aplique a alteração de configuração do IoT Edge.

    sudo iotedge config apply

    O tempo de execução do IoT Edge é reiniciado.

Para obter mais informações, consulte:

Configurar a coleta de lixo de imagem

A coleta de lixo de imagem é um recurso do IoT Edge v1.4 e posterior para limpar automaticamente imagens do Docker que não são mais usadas pelos módulos do IoT Edge. Ele exclui apenas imagens do Docker que foram extraídas pelo tempo de execução do IoT Edge como parte de uma implantação. A exclusão de imagens do Docker não utilizadas ajuda a economizar espaço em disco.

O recurso é implementado no componente de host do IoT Edge, o aziot-edged serviço e ativado por padrão. A limpeza é feita todos os dias à meia-noite (hora local do dispositivo) e remove imagens do Docker não utilizadas que foram usadas pela última vez há sete dias. Os parâmetros para controlar o comportamento de limpeza são definidos e explicados mais adiante config.toml nesta seção. Se os parâmetros não forem especificados no arquivo de configuração, os valores padrão serão aplicados.

Por exemplo, a seguir está a seção de coleta de lixo de config.toml imagem usando valores padrão:

[image_garbage_collection]
enabled = true
cleanup_recurrence = "1d"
image_age_cleanup_threshold = "7d" 
cleanup_time = "00:00"

A tabela a seguir descreve os parâmetros de coleta de lixo de imagem. Todos os parâmetros são opcionais e podem ser definidos individualmente para alterar as configurações padrão.

Parâmetro Descrição Obrigatório Default value
enabled Habilita a coleta de lixo de imagem. Você pode optar por desativar o recurso alterando essa configuração para false. Opcional verdadeiro
cleanup_recurrence Controla a frequência de recorrência da tarefa de limpeza. Deve ser especificado como um múltiplo de dias e não pode ser inferior a um dia.

Por exemplo: 1d, 2d, 6d, etc.		 Opcional 1º
image_age_cleanup_threshold Define o limite mínimo de idade das imagens não utilizadas antes de considerar a limpeza e deve ser especificado em dias. Você pode especificar como 0d para limpar as imagens assim que elas forem removidas da implantação.

As imagens são consideradas não utilizadas depois de terem sido removidas da implementação.		 Opcional 7 d
cleanup_time Hora do dia, na hora local do dispositivo, quando a tarefa de limpeza é executada. Deve estar no formato HH:MM de 24 horas. Opcional 00:00

Rede

  • Úteis
    • Rever a configuração de saída/entrada
    • Permitir conexões de dispositivos IoT Edge
    • Configurar a comunicação através de um proxy
    • Definir o servidor DNS nas configurações do mecanismo de contêiner

Rever a configuração de saída/entrada

Os canais de comunicação entre o Hub IoT do Azure e o IoT Edge estão sempre configurados para serem de saída. Para a maioria dos cenários do IoT Edge, apenas três conexões são necessárias. O mecanismo de contêiner precisa se conectar com o registro de contêiner (ou registros) que contém as imagens do módulo. O tempo de execução do IoT Edge precisa se conectar ao Hub IoT para recuperar informações de configuração do dispositivo e enviar mensagens e telemetria. E se você usar o provisionamento automático, o IoT Edge precisará se conectar ao Serviço de Provisionamento de Dispositivo. Para obter mais informações, consulte Regras de configuração de firewall e porta.

Permitir conexões de dispositivos IoT Edge

Se sua configuração de rede exigir que você permita explicitamente conexões feitas de dispositivos IoT Edge, examine a seguinte lista de componentes do IoT Edge:

  • O agente IoT Edge abre uma conexão AMQP/MQTT persistente com o Hub IoT, possivelmente por WebSockets.
  • O hub IoT Edge abre uma única conexão AMQP persistente ou várias conexões MQTT para o Hub IoT, possivelmente por WebSockets.
  • O serviço IoT Edge faz chamadas HTTPS intermitentes para o Hub IoT.

Em todos os três casos, o nome de domínio totalmente qualificado (FQDN) corresponderia ao padrão \*.azure-devices.net.

Registos de contentor

O mecanismo de contêiner faz chamadas para registros de contêiner por HTTPS. Para recuperar as imagens de contêiner de tempo de execução do IoT Edge, o FQDN é mcr.microsoft.com. O mecanismo de contêiner se conecta a outros registros conforme configurado na implantação.

Esta lista de verificação é um ponto de partida para as regras de firewall:

FQDN (* = curinga) Portas TCP de saída Utilização
mcr.microsoft.com 443 Registro de contêiner da Microsoft
*.data.mcr.microsoft.com 443 Ponto de extremidade de dados que fornece entrega de conteúdo
*.cdn.azcr.io 443 Implantar módulos do Marketplace em dispositivos
global.azure-devices-provisioning.net 443 Acesso ao Serviço de Provisionamento de Dispositivos (opcional)
*.azurecr.io 443 Registos de contentores pessoais e de terceiros
*.blob.core.windows.net 443 Baixar deltas de imagem do Registro de Contêiner do Azure do armazenamento de blob
*.azure-devices.net 5671, 8883, 4431 Acesso ao Hub IoT
*.docker.io 443 Acesso ao Docker Hub (opcional)

1 Abra a porta 8883 para MQTT seguro ou a porta 5671 para AMQP seguro. Se você só pode fazer conexões via porta 443, então qualquer um desses protocolos pode ser executado através de um túnel WebSocket.

Como o endereço IP de um hub IoT pode ser alterado sem aviso prévio, sempre use o FQDN para permitir a configuração da lista. Para saber mais, consulte Noções básicas sobre o endereço IP do seu Hub IoT.

Algumas dessas regras de firewall são herdadas do Registro de Contêiner do Azure. Para obter mais informações, consulte Configurar regras para acessar um registro de contêiner do Azure atrás de um firewall.

Você pode habilitar pontos de extremidade de dados dedicados em seu registro de Contêiner do Azure para evitar a lista de permissões curinga do FQDN *.blob.core.windows.net . Para obter mais informações, consulte Habilitar pontos de extremidade de dados dedicados.

Nota

Para fornecer um FQDN consistente entre o REST e os pontos de extremidade de dados, a partir de 15 de junho de 2020 , o ponto de extremidade de dados do Registro de Contêiner da Microsoft será alterado de *.cdn.mscr.io para *.data.mcr.microsoft.com
Para obter mais informações, consulte Configuração de regras de firewall do cliente Microsoft Container Registry

Se você não quiser configurar seu firewall para permitir o acesso a registros de contêiner públicos, poderá armazenar imagens em seu registro de contêiner privado, conforme descrito em Armazenar contêineres de tempo de execução em seu registro privado.

Azure IoT Identity Service

O Serviço de Identidade IoT fornece serviços de provisionamento e criptografia para dispositivos IoT do Azure. O serviço de identidade verifica se a versão instalada é a versão mais recente. A verificação usa os seguintes FQDNs para verificar a versão.

FQDN Portas TCP de saída Utilização
aka.ms 443 URL personalizado que fornece redirecionamento para o arquivo de versão
raw.githubusercontent.com 443 O arquivo de versão do serviço de identidade hospedado no GitHub

Configurar a comunicação através de um proxy

Se seus dispositivos forem implantados em uma rede que usa um servidor proxy, eles precisarão ser capazes de se comunicar por meio do proxy para alcançar o Hub IoT e os registros de contêiner. Para obter mais informações, consulte Configurar um dispositivo IoT Edge para se comunicar por meio de um servidor proxy.

Definir o servidor DNS nas configurações do mecanismo de contêiner

Especifique o servidor DNS para seu ambiente nas configurações do mecanismo de contêiner. A configuração do servidor DNS se aplica a todos os módulos de contêiner iniciados pelo mecanismo.

  1. No diretório do seu dispositivo, edite /etc/docker o daemon.json arquivo. Crie o arquivo se ele não existir.

  2. Adicione a chave dns e defina o endereço do servidor DNS para um serviço DNS acessível publicamente. Se o dispositivo de borda não puder acessar um servidor DNS público, use um endereço de servidor DNS acessível na rede. Por exemplo:

    {
    "dns": ["1.1.1.1"]
}

Gestão de soluções

  • Úteis
    • Configurar logs e diagnósticos
    • Configurar o driver de log padrão
    • Considere testes e pipelines de CI/CD

Configurar logs e diagnósticos

No Linux, o daemon IoT Edge usa diários como o driver de log padrão. Você pode usar a ferramenta journalctl de linha de comando para consultar os logs do daemon.

A partir da versão 1.2, o IoT Edge depende de vários daemons. Embora os logs de cada daemon possam ser consultados individualmente com journalctlo , os comandos fornecem uma maneira conveniente de consultar os iotedge system logs combinados.

  • Comando consolidado iotedge :

    sudo iotedge system logs

  • Comando equivalente journalctl :

    journalctl -u aziot-edge -u aziot-identityd -u aziot-keyd -u aziot-certd -u aziot-tpmd

Ao testar uma implantação do IoT Edge, você geralmente pode acessar seus dispositivos para recuperar logs e solucionar problemas. Em um cenário de implantação, talvez você não tenha essa opção. Considere como você vai coletar informações sobre seus dispositivos em produção. Uma opção é usar um módulo de registro que coleta informações dos outros módulos e as envia para a nuvem. Um exemplo de um módulo de registro é logspout-loganalytics, ou você pode projetar o seu próprio.

Configurar o driver de log padrão

Por predefinição, o motor do contentor Moby não define limites de tamanho para o registo de contentor. Ao longo do tempo, isto pode fazer com que o dispositivo seja preenchido com registos e fique sem espaço em disco. Configure seu mecanismo de contêiner para usar o driver de local log como seu mecanismo de registro. Local O driver de registro oferece um limite de tamanho de log padrão, executa a rotação de log por padrão e usa um formato de arquivo mais eficiente que ajuda a evitar o esgotamento do espaço em disco. Você também pode optar por usar diferentes drivers de registro e definir limites de tamanho diferentes com base em sua necessidade.

Opção: Configurar o driver de log padrão para todos os módulos de contêiner

Você pode configurar seu mecanismo de contêiner para usar um driver de log específico definindo o valor de para o nome do driver de log driver log no daemon.json. O exemplo a seguir define o driver de log padrão como o driver de local log (recomendado).

{
    "log-driver": "local"
}

Você também pode configurar suas log-opts chaves para usar valores apropriados no daemon.json arquivo. O exemplo a seguir define o driver de log como local e define as max-size opções e max-file .

{
    "log-driver": "local",
    "log-opts": {
        "max-size": "10m",
        "max-file": "3"
    }
}

Adicione (ou acrescente) essas informações a um arquivo chamado daemon.json e coloque-as no seguinte local:

  • /etc/docker/

O mecanismo do contêiner deve ser reiniciado para que as alterações entrem em vigor.

Opção: Ajustar as configurações de log para cada módulo de contêiner

Você pode fazer isso no createOptions de cada módulo. Por exemplo:

"createOptions": {
    "HostConfig": {
        "LogConfig": {
            "Type": "local",
            "Config": {
                "max-size": "10m",
                "max-file": "3"
            }
        }
    }
}

Opções adicionais em sistemas Linux

  • Configure o mecanismo de contêiner para enviar logs para o diário definindo journald como o systemddriver de log padrão.

  • Remova periodicamente os logs antigos do seu dispositivo instalando uma ferramenta logrotate. Use a seguinte especificação de arquivo:

    /var/lib/docker/containers/*/*-json.log{
     copytruncate
     daily
     rotate7
     delaycompress
     compress
     notifempty
     missingok
}

Considere testes e pipelines de CI/CD

Para obter o cenário de implantação mais eficiente do IoT Edge, considere integrar sua implantação de produção em seus pipelines de teste e CI/CD. O Azure IoT Edge suporta várias plataformas de CI/CD, incluindo o Azure DevOps. Para obter mais informações, consulte Integração contínua e implantação contínua no Azure IoT Edge.

Considerações de segurança

  • Importante
    • Gerenciar o acesso ao seu registro de contêiner
    • Limitar o acesso do contêiner aos recursos do host

Gerenciar o acesso ao seu registro de contêiner

Antes de implantar módulos em dispositivos IoT Edge de produção, certifique-se de controlar o acesso ao registro de contêiner para que pessoas externas não possam acessar ou fazer alterações em suas imagens de contêiner. Use um registro de contêiner privado para gerenciar imagens de contêiner.

Nos tutoriais e em outra documentação, instruímos você a usar as mesmas credenciais de registro de contêiner em seu dispositivo IoT Edge que você usa em sua máquina de desenvolvimento. Estas instruções destinam-se apenas a ajudá-lo a configurar ambientes de teste e desenvolvimento mais facilmente e não devem ser seguidas em um cenário de produção.

Para um acesso mais seguro ao seu registo, pode escolher entre as opções de autenticação. Uma autenticação popular e recomendada é usar uma entidade de serviço do Ative Directory que seja adequada para aplicativos ou serviços para extrair imagens de contêiner de maneira automatizada ou autônoma (sem cabeça), como fazem os dispositivos IoT Edge. Outra opção é usar tokens com escopo de repositório, que permitem criar identidades de longa ou curta duração que existem apenas no Registro de Contêiner do Azure em que foram criadas e acesso de escopo ao nível do repositório.

Para criar uma entidade de serviço, execute os dois scripts conforme descrito em Criar uma entidade de serviço. Esses scripts executam as seguintes tarefas:

  • O primeiro script cria a entidade de serviço. Ele gera a ID da entidade de serviço e a senha da entidade de serviço. Guarde estes valores de forma segura nos seus registos.

  • O segundo script cria atribuições de função para conceder à entidade de serviço, que podem ser executadas posteriormente, se necessário. Recomendamos aplicar a função de usuário acrPull para o role parâmetro. Para obter uma lista de funções, consulte Funções e permissões do Registro de Contêiner do Azure.

Para autenticar usando uma entidade de serviço, forneça a ID da entidade de serviço e a senha que você obteve do primeiro script. Especifique essas credenciais no manifesto de implantação.

  • Para o nome de usuário ou ID do cliente, especifique o ID da entidade de serviço.

  • Para a senha ou segredo do cliente, especifique a senha da entidade de serviço.


Para criar tokens com escopo de repositório, siga criar um token com escopo de repositório.

Para autenticar usando tokens com escopo de repositório, forneça o nome e a senha do token que você obteve depois de criar o token com escopo de repositório. Especifique essas credenciais no manifesto de implantação.

  • Para o nome de usuário, especifique o nome de usuário do token.

  • Para a senha, especifique uma das senhas do token.

Nota

Depois de implementar uma autenticação de segurança avançada, desative a configuração de usuário Admin para que o acesso padrão ao nome de usuário /senha não esteja mais disponível. No seu registo de contentor no portal do Azure, no menu do painel esquerdo em Definições, selecione Chaves de Acesso.

Limitar o acesso do contêiner aos recursos do host

Para equilibrar os recursos de anfitrião partilhados entre os módulos, recomendamos que defina limites para o consumo de recursos por módulo. Estes limites garantem que um módulo não pode consumir demasiada memória ou utilização da CPU e impedir a execução de outros processos no dispositivo. Por predefinição, a plataforma IoT Edge não limita os recursos por módulos, uma vez que saber qual a quantidade de recurso que um determinado módulo necessita para ser executado da melhor forma exige testes.

O Docker fornece algumas restrições que você pode usar para limitar recursos como o uso de memória e CPU. Para obter mais informações, consulte Opções de tempo de execução com memória, CPUs e GPUs.

Essas restrições podem ser aplicadas a módulos individuais usando opções de criação em manifestos de implantação. Para obter mais informações, consulte Como configurar opções de criação de contêiner para módulos do IoT Edge.

Próximos passos

  • Saiba mais sobre a implantação automática do IoT Edge.
  • Veja como o IoT Edge oferece suporte à integração contínua e à implantação contínua.