Prepare-se para implantar sua solução IoT Edge em produção

Aplica-se a: IoT Edge 1.5 IoT Edge 1.4

Importante

O IoT Edge 1.5 LTS e o IoT Edge 1.4 LTS são versões com suporte. O IoT Edge 1.4 LTS chegará ao fim da vida útil em 12 de novembro de 2024. Se você estiver em uma versão anterior, confira Atualizar o IoT Edge.

Quando você estiver pronto para levar sua solução IoT Edge do desenvolvimento para a produção, verifique se ela está 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 ser concluído antes da produção ou útil para você saber.

Configuração do dispositivo

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

• Importante

  • Instalar certificados de produção
  • Tenha um plano de gerenciamento de dispositivos
  • Use Moby como o mecanismo de contêiner. Se você estiver usando snaps do Ubuntu Core, o snap do Docker será atendido pela Canonical e terá suporte para cenários de produção.

• Utilidade

  • 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) do dispositivo instalado. Esse certificado de CA é então declarado para o runtime do IoT Edge no arquivo config. Para o desenvolvimento e os cenários de teste, o runtime do IoT Edge cria certificados temporários se nenhum certificado for declarado no arquivo config. 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, forneça seu próprio certificado de assinatura do Edge, seja de uma autoridade de certificação autoassinada ou adquirida de uma autoridade de certificação comercial.

Para reconhecer a função do certificado de assinatura do Edge, consulte Como o IoT Edge do Azure usa certificados.

Para obter mais informações sobre como instalar certificados em um dispositivo IoT Edge e referenciá-los no arquivo config, 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 gerenciar futuras atualizações. Para um dispositivo IoT Edge, a lista de componentes a atualizar pode incluir:

• Firmware do dispositivo
• Bibliotecas do sistema operacional
• Mecanismo de contêiner, como Moby
• IoT Edge
• Certificados de AC

A Atualização de Dispositivo para Hub IoT é um serviço que permite que você implante as atualizações OTA (por satélite) nos dispositivos IoT Edge.

Os 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 de IOT Edge. Para atualizar vários dispositivos, considere adicionar as etapas de atualização a um script ou use uma ferramenta de automação como Ansible.

Mecanismo de contêiner

Um mecanismo de contêiner é um pré-requisito para qualquer dispositivo IoT Edge. O mecanismo Moby é suportado na produção. Se você estiver usando snaps do Ubuntu Core, o snap do Docker será atendido pela Canonical e terá suporte para cenários de 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 de 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 de IoT Edge e o Hub de IoT Edge. O protocolo padrão é AMQP, mas você pode querer mudar isso dependendo da sua configuração de rede.

Os dois módulos de runtime possuem 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 Edge no arquivo config no próprio dispositivo. Por exemplo, se o seu dispositivo IoT Edge estiver atrás de um servidor proxy que bloqueia as portas AMQP, pode ser 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 o dispositivo IoT Edge se conectar, certifique-se de continuar configurando a variável UpstreamProtocol para os dois módulos de runtime em implantações futuras. Um exemplo desse processo é fornecido em Configurar um dispositivo IoT Edge para se comunicar por meio de um servidor proxy.

Implantação

• Utilidade
  • Seja consistente com o protocolo upstream
  • Configure o host para módulos do sistema
  • Reduza o espaço de memória usado pelo hub IoT Edge
  • Usar imagens de módulo corretas em manifestos de implantação
  • Lembre-se dos limites de tamanho de gêmeo ao usar módulos personalizados
  • Configurar como as atualizações nos módulos são aplicadas

Seja consistente com o protocolo upstream

Se você configurou o agente de IoT Edge em seu dispositivo IoT Edge para usar um protocolo diferente do padrão AMQP, deverá declarar o mesmo protocolo em todas as implantações subsequentes. 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 conectar-se 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, em seguida, o AMQP padrão substitui as configurações e impede que você se conecte novamente.

Você só precisa configurar a variável de ambiente UpstreamProtocol para o agente do IoT Edge agent e o móddulo do hub IoT Edge. Quaisquer módulos adicionais adotam qualquer protocolo que esteja configurado nos módulos de runtime.

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

Configure o host para módulos do sistema

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

Para obter mais informações, consulte host Storage for System modules.

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

Se você estiver implantando dispositivos restritos com memória limitada disponível, poderá configurar o hub do 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 do IoT Edge, portanto, encontre o equilíbrio correto que funcione para sua solução.

Não otimize o desempenho em dispositivos restritos

O hub do IoT Edge é otimizado para desempenho por padrão, por isso ele 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, poderá definir a variável de ambiente OptimizeForPerformance como false no hub do IoT Edge.

Quando OptimizeForPerformance é definido como true, o MQTT Protocol Head 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 o provedor de armazenamento local.

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

Desabilitar protocolos não utilizados

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

Cabeçalhos de protocolo são configurados definindo variáveis de ambiente booleano para o módulo de hub do 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 possuem dois sublinhados e podem ser configuradas como verdadeiras ou falsas.

Reduza o tempo de armazenamento de mensagens

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

O valor padrão do parâmetro timeToLiveSecs é de 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 incorreta for usada, o agente do Edge tentará carregar a imagem, o que faz com que o tráfego extra seja gerado. Adicione as imagens corretas ao manifesto de implantação para evitar a geração de tráfego desnecessário.

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

Ao passar 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 do módulo nos manifestos de implantação possui o sufixo .debug. Se você adicionou criar opções para expor portas nos módulos para depuração, remova essas opções de criação também.

Lembre-se dos limites de tamanho de gêmeo ao usar módulos personalizados

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

Ao implantar um grande número de módulos, é possível exceder esse limite de tamanho de gêmeo. Considere algumas mitigações comuns para esse limite rígido:

• Armazene qualquer configuração no módulo gêmeo personalizado, que tem o próprio limite.
• Armazene algumas configurações que apontam para um local não limitado por espaço (ou seja, para um armazenamento de blobs).

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

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

1. A imagem atualizada é baixada
2. O módulo em execução é interrompido
3. Uma nova instância de 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, talvez seja melhor baixar todas as imagens de módulo atualizadas antes de reiniciar os módulos em execução. Esse comportamento de atualização de módulo pode ser configurado definindo uma variável de ambiente ModuleUpdateMode do agente do IoT Edge para o valor da cadeia de caracteres WaitForAllPulls. Para obter mais informações, confira Variáveis de ambiente do IoT Edge.

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

Gerenciamento de contêiner

• Importante
  • Use tags para gerenciar versões
  • Gerenciar volumes
• Utilidade
  • Armazenar contêineres de tempo de execução em seu registro particular
  • Configurar a coleta de lixo de imagem

Use tags para gerenciar versões

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

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

Sinalizar o runtime do IoT Edge

O agente do IoT Edge e as imagens de hub do IoT Edge são marcadas com a versão do IoT Edge a que estão associados. Há duas maneiras diferentes de usar marcas com as imagens de runtime:

• Marcas sem interrupção – use os dois primeiros valores do número de versão para obter a imagem mais recente que corresponde a esses dígitos. Por exemplo, 1.5 é atualizado sempre que há uma nova versão para apontar para a versão 1.5.x mais recente. Se o runtime do contêiner em seu dispositivo IoT Edge extrair a imagem novamente, os módulos de runtime serão atualizados para a versão mais recente. Implantações do portal do Azure usam como padrão marcas sem interrupção. Essa abordagem é sugerida para fins de desenvolvimento.

• Marcas específicas – use todos os três valores do número de versão para definir explicitamente a versão da imagem. Por exemplo, a versão 1.5.0 não será alterada após seu lançamento inicial. Você pode declarar um novo número de versão no manifesto de implantação quando estiver pronto para atualizar. Essa abordagem é sugerida para fins de produção.

Gerenciar volumes

O IoT Edge não remove volumes anexados a contêineres de módulo. Esse comportamento é intencional, pois permite persistir os dados em instâncias de contêiner, como cenários de atualização. No entanto, se esses volumes forem deixados sem uso, isso poderá levar ao esgotamento do espaço em disco e a erros subsequentes do sistema. Se você usa volumes de Docker no seu cenário, procure usar ferramentas para Docker, como docker volume prune e docker volume rm para remover os volumes não utilizados, especialmente dos cenários de produção.

Armazenar contêineres de tempo de execução em seu registro particular

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

As etapas a seguir ilustram como efetuar pull de uma imagem do Docker de edgeAgent e edgeHub para seu computador local, remarcá-la, enviá-la por push para o registro privado e atualizar o arquivo de configuração para que seus dispositivos saibam efetuar pull da imagem do registro privado.

1. Efetue pull da imagem edgeAgent Docker 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.5
   
   # Pull edgeHub image
   docker pull mcr.microsoft.com/azureiotedge-hub:1.5
   

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

   docker images
   

3. Remarque suas imagens edgeAgent e edgeHub. Substitua os valores entre colchetes por valores fornecidos por você.

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

4. Envie suas imagens do edgeAgent e do edgeHub para o registro privado. Substitua o valor entre colchetes por um valor fornecido por você.

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

5. Atualize as referências de imagem no arquivo deployment.template.json para os módulos do sistema do edgeAgent e do edgeHub, substituindo mcr.microsoft.com por seu "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 privada do registro.

   sudo nano /etc/aziot/config.toml
   

7. No editor de texto, altere os valores de imagem em [agent.config]. Substitua os valores entre colchetes por valores fornecidos por você.

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

8. Se o registro 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 o arquivo e saia do editor de texto.

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

    sudo iotedge config apply
    

    O runtime do IoT Edge é reiniciado.

Para saber mais, veja:

• Configurar o agente do IoT Edge
• Azure IoT Edge Agent
• Hub do Azure IoT Edge

Configurar a coleta de lixo de imagem

A coleta de lixo de imagem é um recurso no IoT Edge v1.4 e posterior para limpar automaticamente as imagens do Docker que não são mais usadas por módulos do IoT Edge. Ela só exclui imagens do Docker que foram puxadas pelo runtime do IoT Edge como parte de uma implantação. Excluir imagens não utilizadas do Docker ajuda a conservar o espaço em disco.

O recurso é implementado no componente de host do IoT Edge, o serviço aziot-edged, e habilitado por padrão. A limpeza é feita todos os dias à meia-noite (hora local do dispositivo) e remove imagens não utilizadas do Docker que foram usadas pela última vez há sete dias. Os parâmetros para controlar o comportamento de limpeza são definidos em config.toml e explicados posteriormente 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, apresentamos abaixo a seção de coleta de lixo de imagem config.toml 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	Valor padrão
enabled	Habilita a coleta de lixo de imagem. Você pode optar por desabilitar o recurso alterando essa configuração para false.	Opcional	true
cleanup_recurrence	Controla a frequência de recorrência da tarefa de limpeza. Deve ser especificada como um múltiplo de dias e não pode ser inferior a um dia. Por exemplo: 1d, 2d, 6d etc.	Opcional	1d
image_age_cleanup_threshold	Define o limite de idade mínima de imagens não usadas antes de considerar a limpeza e deve ser especificada 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 serem removidas da implantação.	Opcional	7d
cleanup_time	Hora do dia, na hora local do dispositivo, quando a tarefa de limpeza é executada. Deve estar no formato HH:MM 24 horas.	Opcional	00h

Rede

• Utilidade
  • Revisar configuração de entrada/saída
  • Permitir as conexões em dispositivos de IoT Edge
  • Configurar a comunicação por meio de um proxy
  • Definir o servidor DNS em configurações do mecanismo de contêiner

Revisar configuração de entrada/saída

Os canais de comunicação entre o Hub IoT e o IoT Edge são sempre configurados para serem enviados. 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 ao registro do contêiner (ou registros) que contém as imagens do módulo. O runtime 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 dispositivos. Para obter mais informações, consulte Regras de configuração de firewall e porta.

Permitir as conexões em dispositivos de IoT Edge

Se a sua configuração de rede exigir uma permissão explícita de conexões feitas a partir de dispositivos IoT Edge, analise a seguinte lista de componentes do IoT Edge:

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

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

Registros de contêiner

O mecanismo de contêiner faz chamadas para registros de contêiner por HTTPS. Para recuperar as imagens de contêiner do runtime 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 regras de firewall:

FQDN (* = curinga)	Portas TCP de Saída	Uso
mcr.microsoft.com	443	Registro de Contêiner da Microsoft
*.data.mcr.microsoft.com	443	Ponto de extremidade de dados que fornece distribuição 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	Registros de contêiner pessoal 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 do Hub IoT
*.docker.io	443	Opções de acesso do Docker Hub (opcional)

¹Abra a porta 8883 para MQTT seguro ou a porta 5671 para AMQP seguro. Se você só puder fazer conexões por meio da porta 443, qualquer um desses protocolos pode ser executado por meio de um túnel WebSocket.

Como o endereço IP de um hub IoT pode mudar sem aviso prévio, sempre use o FQDN para incluir na lista de permitidos a configuração. Para saber mais, consulte Entendendo o endereço IP do seu Hub IoT.

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

Você pode habilitar pontos de extremidade de dados dedicados no registro de contêiner do Azure para evitar a inclusão na lista de permitidos curinga do FQDN *.blob.core.windows.net. Para obter mais informações, consulte Habilitar pontos de extremidade de dados dedicados.

Observação

Para fornecer um FQDN consistente entre os pontos de extremidade REST e data, a partir de 15 de junho de 2020, o ponto de extremidades 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 de cliente do registro de contêiner da Microsoft

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

Serviço de identidade de Internet das Coisas do Azure

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

FQDN	Portas TCP de Saída	Uso
aka.ms	443	Vanity URL 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 por meio de um proxy

Se os dispositivos forem implantados em uma rede que usa um servidor proxy, eles precisarão se comunicar por meio do proxy para acessar 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 em 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 /etc/docker em seu dispositivo, edite o arquivo daemon.json. Crie o arquivo se ele ainda 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 em sua rede. Por exemplo:

   {
       "dns": ["1.1.1.1"]
   }
   

Gerenciamento de soluções

• Utilidade
  • 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 do IoT Edge usa o journals como o driver de registro padrão. Você pode usar a ferramenta de linha de comando journalctl para consultar os logs do daemon.

A partir da versão 1,2, IoT Edge se baseia em vários daemons. Embora os logs de cada daemon possam ser consultados individualmente journalctl, os iotedge system comandos fornecem uma maneira conveniente de consultar os logs combinados.

• Comando consolidado iotedge:

  sudo iotedge system logs
  

• Comando journalctlequivalente:

  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. Pense em como você coletará informações sobre seus dispositivos em produção. Considere como você 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 é log-logan-analytics, ou você pode criar o seu próprio.

Configurar o driver de log padrão

Por padrão, o mecanismo de contêiner Moby não define limites de tamanho de log de contêiner. Com o tempo, isso pode levar ao dispositivo que está se enchendo com os logs e ficando sem espaço em disco. Configure seu mecanismo de contêiner para usar o driver de registro em log de local como seu mecanismo de log. O driver de registro em log de Local 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 driver de registro em log diferentes e definir limites de tamanho diferentes com base em sua necessidade.

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

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

{
    "log-driver": "local"
}

Você também pode configurar suas chaves log-opts para usar valores apropriados no arquivo daemon.json. O exemplo a seguir define o driver de log como local e define as opções max-size 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 de 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 em createrOptions 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 ao systemd diário, definindo journald como o driver de log padrão.

• Periodicamente, remova logs antigos do seu dispositivo instalando uma ferramenta de 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 o cenário de implantação do IoT Edge mais eficiente, considere a integração de 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 DevOps do Azure. 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 a recursos de host

Gerenciar o acesso ao seu registro de contêiner

Antes de implantar módulos nos dispositivos de produção do IoT Edge, assegure-se de controlar o acesso ao seu registro de contêiner para que pessoas de fora 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 no dispositivo IoT Edge que você usa na sua máquina de desenvolvimento. Essas 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 obter um acesso mais seguro ao registro, você tem uma opção de Opções de autenticação. Uma autenticação popular e recomendada é usar uma entidade de serviço Active Directory que seja adequada para aplicativos ou serviços para extrair imagens de contêiner de maneira automatizada ou não assistida (sem interrupções), como IoT Edge dispositivos. Outra opção é usar tokens com escopo definido para repositório a fim de criar identidades de duração longa ou curta que existam apenas no Registro de Contêiner do Azure em que foram criadas e a fim de definir o escopo do acesso para o 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. Isso libera o ID da entidade de serviço e a senha da entidade de serviço. Armazene esses valores com segurança em seus registros.

• O segundo script cria atribuições de função para conceder à entidade de serviço, que pode ser executada subsequentemente, se necessário. É recomendável aplicar a função de usuário acrPull para o role parâmetro. Para obter uma lista de funções, confira 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 a ID do cliente, especifique a ID da entidade de serviço.

• Para a senha ou o 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.

Você pode se autenticar usando tokens com escopo definido para repositório fornecendo o nome do token e a senha obtida depois da criação dele. Especifique essas credenciais no manifesto de implantação.

• Especifique o nome de usuário do token como o nome de usuário.

• Especifique uma das senhas do token como a senha.

Observação

Depois de implementar uma autenticação de segurança avançada, desabilite a configuração de usuário administrador para que o acesso de nome de usuário/senha padrão não esteja mais disponível. No registro de contêiner no portal do Azure, no menu do painel esquerdo em configurações, selecione chaves de acesso.

Limitar o acesso do contêiner a recursos de host

Para equilibrar os recursos de host compartilhados entre módulos, é recomendável colocar limites no consumo de recursos por módulo. Esses limites garantem que um módulo não consuma muita memória ou uso da CPU e evitam que outros processos sejam executados no dispositivo. A plataforma IoT Edge não limita os recursos para módulos por padrão, já que saber quanto recurso um determinado módulo precisa executar de modo ideal requer testes.

O Docker tem algumas restrições que você pode usar para limitar recursos como memória e uso de CPU. Para saber mais, confira Opções de runtime 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, confira Como configurar opções de criação de contêiner para módulos de IoT Edge.

Próximas etapas

• Saiba mais sobre implantação automática do IoT Edge.
• Veja como o IoT Edge suporta Integração contínua e implantação contínua.