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

Aplica-se a: IoT Edge 1.1

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 o Moby como o motor de contêiner

• 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 de dispositivo (CA) 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, você deve fornecer seu próprio certificado de autoridade de certificação de dispositivo, seja de uma autoridade de certificação autoassinada ou adquirida de uma autoridade de certificação comercial.

Para entender a função do certificado de AC do dispositivo, confira como o Azure IoT Edge 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 Autoridade Certificadora

A Atualização de Dispositivo para Hub IoT (Versão Prévia) é um serviço que permite implantar atualizações ao ar (OTA) para seus dispositivos do 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 IoT Edge runtime. Para atualizar vários dispositivos, considere adicionar as etapas de atualização a um script ou use uma ferramenta de automação como Ansible.

Utilize o Moby como motor de contêineres

Um mecanismo de contêiner é um pré-requisito para qualquer dispositivo IoT Edge. Apenas o Moby-Engine é 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 suporte 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 IoT Edge no arquivo de configuração 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
  • Configurar o armazenamento do 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 descrições 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 anterior.

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 utilizando AMQP sobre WebSocket (AMQPWS). Quando você implantar módulos no dispositivo, configure o mesmo protocolo AMQPWS tanto para o agente do Azure IoT Edge quanto para o hub do IoT Edge, pois, caso contrário, o protocolo padrão AMQP substituirá essas configurações e poderá impedir que você se conecte novamente.

Você só precisa configurar a variável de ambiente UpstreamProtocol para o agente do IoT Edge e o módulo 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.

Configurar o armazenamento do 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 armazenamento do host para módulos do sistema.

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 retém mensagens não entregues antes de elas expirarem. Se você tiver problemas de memória no seu dispositivo, poderá diminuir o valor de timeToLiveSecs no gêmeo do módulo de hub do IoT Edge.

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

Utilize imagens corretas de módulos em manifestos de implementação

Se uma imagem de módulo vazia ou incorreta for usada, o agente do Edge tentará carregar a imagem, o que gera tráfego extra. Adicione as imagens corretas ao manifesto de implantação para evitar a geração de tráfego desnecessário.

Não utilize 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 manifests de implantação. Verifique se nenhuma das imagens do módulo nos manifestos de implantação possui 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.

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).

Gerenciamento de contêiner

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

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 etiquetas são sufixos como 1.1 que são adicionadas ao final de um repositório de contêineres. 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, 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 do contêiner reconhecerá a tag incrementada como uma nova versão e baixará a versão mais recente do módulo para o seu dispositivo.

Etiquetas para 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 tags com as imagens de runtime:

• Tags contínuas – 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.1 é atualizado sempre que há uma nova versão para apontar para a versão 1.1.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 no portal do Azure têm como padrão etiquetas contínuas. 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, 1.1.0 não mudará 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, recomendamos usar ferramentas para Docker, como docker volume prune e docker volume rm para remover os volumes não utilizados, especialmente em cenários de produção.

Armazenar contêineres de runtime em seu registro privado

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 de firewall muito rígidas, pois esses contêineres de runtime são armazenados no MCR (Registro de Contêiner da Microsoft).

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

1. Baixe a imagem 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.1
   
   # Pull edgeHub image
   docker pull mcr.microsoft.com/azureiotedge-hub:1.1
   

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.1
   
   # Retag your edgeHub image
   docker tag <my-image-id> <registry-name/server>/azureiotedge-hub:1.1
   

4. Envie suas imagens do edgeAgent e do edgeHub para o seu 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.1
   
   # Push your edgeHub image to your private registry
   docker push <registry-name/server>/azureiotedge-hub:1.1
   

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.1"
   

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 obter mais informações, consulte:

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

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

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.

Além disso, 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:

¹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, sempre use o FQDN para configurar a lista de permitidos. 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 Azure Container Registry para evitar o uso de curinga na listagem permitida do FQDN *.blob.core.windows.net. Para obter mais informações, consulte Habilitar pontos de extremidade de dados dedicados.

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.

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.

Gerenciamento de soluções

• Utilidade
  • Configuração de logs e diagnósticos
  • Configurar o driver de log padrão
  • Considere testes e pipelines de CI/CD

Configurar registros 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.

No Windows, o daemon IoT Edge usa diagnósticos do PowerShell. Use o comando Get-IoTEdgeLog para consultar logs do daemon. Os módulos do IoT Edge usam o driver JSON para registro em log como padrão.

. {Invoke-WebRequest -useb aka.ms/iotedge-win} | Invoke-Expression; Get-IoTEdgeLog

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. 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 log é logspout-loganalytics, ou você pode projetar um próprio.

Configurar o driver de log padrão

Por padrão, o mecanismo de contêiner Moby não aplica limites ao tamanho dos logs dos contêineres. Com o tempo, isso pode levar o dispositivo a ficar cheio de logs e sem espaço em disco. Configure seu mecanismo de contêiner para usar o driver de registro em log local como seu mecanismo de registro em log. Local O driver de log 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 log e definir limites de tamanho diferentes de acordo com sua necessidade.

Opção: Configurar o driver de 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 no daemon.json. O exemplo a seguir define o driver de 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:

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 systemddiá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 mais eficiente de implantação do IoT Edge, considere integrar sua implantação de produção aos 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 do Active Directory que seja adequada para aplicativos ou serviços extrair imagens de contêiner de maneira automatizada ou sem intervenção (sem interface gráfica), assim como dispositivos IoT Edge fazem. Outra opção é usar tokens com escopo de repositório para criar identidades de duração longa ou curta que existam apenas no Registro de Contêiner do Azure em que foram criadas e limitar o acesso 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 o principal de serviço. Isso exibe o ID do principal de serviço e a senha do principal de serviço. Armazene esses valores com segurança em seus registros.

• O segundo script cria atribuições de função para conceder ao principal de serviço, que pode ser executado posteriormente, 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 a criação de um token com escopo de repositório.

Você pode se autenticar usando tokens com escopo de repositório fornecendo o nome do token e a senha que você obteve depois de criar o seu 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.

• Especifique uma das senhas do token.

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.