As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Implemente AWS IoT Greengrass componentes em dispositivos
Você pode usar AWS IoT Greengrass para implantar componentes em dispositivos ou grupos de dispositivos. Você usa *implantações* para definir os componentes e as configurações que são enviados aos dispositivos. AWS IoT Greengrass é implantado em *alvos*, AWS IoT coisas ou grupos de coisas que representam os principais dispositivos do Greengrass. AWS IoT Greengrass usa [AWS IoT Core trabalhos](https://docs.aws.amazon.com/iot/latest/developerguide/iot-jobs.html) para implantar em seus dispositivos principais. É possível configurar como o trabalho é implementado em seus dispositivos.
## Implantações de dispositivos do Core
Cada dispositivo principal executa os componentes das implantações desse dispositivo. Uma nova implantação no mesmo destino substitui a implantação anterior no destino. Ao criar uma implantação, você define os componentes e as configurações a serem aplicados ao software existente do dispositivo principal.
Ao revisar uma implantação para um destino, você substitui os componentes da revisão anterior pelos componentes da nova revisão. Por exemplo, você implanta os componentes [Gerenciador de logs](log-manager-component.md) e [Gerenciador de segredos](secret-manager-component.md) no grupo de coisas `TestGroup`. Em seguida, você cria outra implantação para `TestGroup` que especifique somente o componente do gerenciador de segredos. Como resultado, os dispositivos principais desse grupo não executam mais o gerenciador de logs.
## Resolução de dependências de plataformas
Quando um dispositivo principal recebe uma implantação, ele verifica se os componentes são compatíveis com o dispositivo principal. Por exemplo, se você implantar o [Firehose](kinesis-firehose-component.md) em um destino do Windows, a implantação falhará.
## Resolução de dependências de componentes
Durante a implantação de um componente, o dispositivo principal verifica a compatibilidade das dependências e requisitos de versão de todos os componentes em um grupo de coisas. Essa verificação garante que as restrições de versão sejam satisfeitas para todos os componentes e suas dependências antes de prosseguir com a implantação.
O processo de resolução de dependências começa com a identificação dos componentes de destino que não tenham dependências em suas receitas. Em seguida, o sistema constrói uma árvore de dependências usando a pesquisa primeiro em largura (BFS), que explora sistematicamente cada nó de destino e encontra suas dependências primeiro antes de passar para o próximo nó. Cada nó inclui o componente de destino como chave e os requisitos da versão como valor.
Os requisitos de versão combinam três conjuntos de restrições:
+ Os requisitos de versão que já estão estabelecidos no grupo de coisas existente.
+ A versão do componente exigida pela implantação. É necessário selecionar uma versão do componente ao criar ou atualizar uma implantação.
+ Qualquer restrição de versão do componente definida na seção de dependências da receita.
### Resolução de dependências de componentes
Durante uma implantação, o Greengrass nucleus primeiro tenta encontrar o candidato local atualmente em execução no dispositivo que atenda aos requisitos. Se o componente em execução atender aos requisitos, o nucleus obtém o caminho da receita armazenada na pasta da receita e encontra a versão local mais recente no armazenamento local.
[Para Nuvem AWS implantações, o núcleo então chamará a ResolveComponentCandidates API.](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_ResolveComponentCandidates.html) Essa API começará com a versão mais recente disponível e verificará se ela satisfaz as dependências e os requisitos. Quando o nucleus recebe a resposta da API, ele seleciona a versão mais recente. Se não for encontrada nenhuma versão do Nuvem AWS que satisfaça os requisitos, a implantação falhará. Se o dispositivo estiver off-line, ele retornará ao candidato local original encontrado. Caso não seja encontrado nenhum candidato local que satisfaça os requisitos, a implantação falhará.
Para implantações locais, o núcleo usa exclusivamente candidatos locais, se eles existirem e se satisfizerem os requisitos sem negociação. Nuvem AWS Se não houver tal candidato, a implantação falhará.
**nota**
Todas as receitas resolvidas são armazenadas localmente para futura referência.
Para obter mais informações, consulte a seção de [resolução de dependências](https://github.com/aws-greengrass/aws-greengrass-nucleus/wiki/Deployment#dependency-resolution) em GitHub.
Se Greengrass nucleus for capaz de resolver com sucesso todos os componentes, o log do nucleus conterá a linha a seguir.
```
resolve-all-group-dependencies-finish. Finish resolving all groups dependencies.
```
**Example**
A seguir está um exemplo de como o nucleus resolverá os requisitos dos componentes.
+ Você implanta o ComponenteA, que depende das versões 1.0.0-1.9.0 do ComponenteC.
+ Você também implanta o ComponenteB, que depende das versões 1.4.0-1.9.5 do ComponentC.
Com a resolução da dependência do componente, o nucleus implantará a versão mais recente da versão do ComponenteC para satisfazer os requisitos do ComponenteA e do ComponenteB. Essa versão mais recente do ComponenteC é a 1.9.0.
#### Falhas comuns na resolução de dependências de componentes
A resolução da dependência de componentes pode falhar por dois motivos principais: conflito de requisitos de versão de destino ou conflito de requisitos de dependência de componentes.
##### Cenário 1: conflito de requisitos da versão de destino
+ Uma coisa existe em um grupo de coisas e você também quer adicionar essa coisa a um novo grupo de coisas. A implantação falhará se o novo grupo de coisas exigir uma versão diferente.
+ Uma implantação também pode falhar se uma coisa pertencer a um grupo de coisas e quiser atualizar a versão do componente por meio de uma implantação.
![\[Dependências de componentes que resultam em uma falha na implantação.\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/images/dependency-4.png)
*Exemplo de log de falhas:*
```
2025-04-11T06:16:03.315Z [ERROR] (pool-3-thread-27) com.aws.greengrass.componentmanager.ComponentManager: Failed to negotiate version with cloud and no local version to fall back to. {componentName=ComponentC, versionRequirement={thing/ABC==2.0.0, thinggroup/ThingGroupA==1.0.0}}
2025-04-11T06:16:03.316Z [ERROR] (pool-3-thread-26) com.aws.greengrass.deployment.DeploymentService: Error occurred while processing deployment. {deploymentId=fbac24de-4ef9-44b0-a685-fdc63b0f02b8, serviceName=DeploymentService, currentState=RUNNING}
java.util.concurrent.ExecutionException: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local or cloud component version satisfies the requirements Check whether the version constraints conflict and that the component exists in your AWS account with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component ComponentC version constraints: thing/ABC requires =2.0.0, thinggroup/ThingGroupA requires =1.0.0.
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:127)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:50)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local or cloud component version satisfies the requirements Check whether the version constraints conflict and that the component exists in your AWS account with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component ComponentC version constraints: thing/ABC requires =2.0.0, thinggroup/ThingGroupA requires =1.0.0.
at com.aws.greengrass.componentmanager.ComponentManager.negotiateVersionWithCloud(ComponentManager.java:232)
at com.aws.greengrass.componentmanager.ComponentManager.resolveComponentVersion(ComponentManager.java:167)
at com.aws.greengrass.componentmanager.DependencyResolver.lambda$resolveDependencies$0(DependencyResolver.java:134)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveComponentDependencies(DependencyResolver.java:231)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveDependencies(DependencyResolver.java:131)
at com.aws.greengrass.deployment.DefaultDeploymentTask.lambda$call$2(DefaultDeploymentTask.java:125)
... 4 more
```
Os logs indicam um erro de conflito de versão porque o nucleus não consegue encontrar uma versão do componente que atenda simultaneamente a dois requisitos conflitantes.
##### Como resolver o problema
+ Se você quiser manter o componente em cada grupo de coisas, selecione a mesma versão desse componente em cada grupo de coisas.
+ Selecione uma versão do componente que atenda aos requisitos de implantação.
+ Se você quiser usar uma versão do componente que não atenda aos dois requisitos do grupo de coisas, selecione a versão do componente que atenda ao requisito da versão do grupo de coisas e use esse componente somente nesse grupo de coisas.
##### Cenário 2: conflito de requisitos de versão de dependência de componentes
Se um componente for uma dependência de componentes diferentes e os componentes exigirem versões ou intervalos de versões diferentes desse componente, é possível que não haja versões disponíveis para satisfazer todos os requisitos de versão. Nesse cenário, a implantação falhará.
**Example**
Implantação do ComponenteA (v2.5.0), ComponenteB (v1.3.0) e ComponenteC (v1.0.0)
+ O ComponenteA requer a versão >=1.0.0 do ComponenteB.
```
---
...
ComponentName: ComponentA
ComponentVersion: "2.5.0"
ComponentDependencies:
ComponentB:
VersionRequirement: ">=1.0.0"
DependencyType: "HARD"
...
```
+ O ComponenteC requer a versão <2.0.0 do ComponenteA.
```
---
...
ComponentName: ComponentC
ComponentVersion: "1.0.0"
ComponentDependencies:
ComponentA:
VersionRequirement: "<2.0.0"
DependencyType: "HARD"
...
```
Há um conflito de versão entre dois requisitos do ComponenteA:
+ O ComponenteA requer a versão 2.5.0 nesta implantação
+ O ComponenteC requer versões do ComponenteA anteriores a 2.0.0.
Esses dois requisitos se contradizem, impossibilitando que o nucleus encontre uma versão do ComponenteA que satisfaça os dois requisitos. Portanto, a resolução da dependência falhará.
![\[Dependências de componentes que resultam em uma falha na implantação.\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/images/dependency-3.png)
*Exemplo de log de falhas:*
```
2025-04-11T06:07:18.291Z [ERROR] (pool-3-thread-25) com.aws.greengrass.componentmanager.ComponentManager: Failed to negotiate version with cloud and no local version to fall back to. {componentName=ComponentA, versionRequirement={ComponentC=<2.0.0, thinggroup/ThingGroupA==2.5.0}}
2025-04-11T06:07:18.292Z [ERROR] (pool-3-thread-24) com.aws.greengrass.deployment.DeploymentService: Error occurred while processing deployment. {deploymentId=2ffac4df-1ac9-405c-8c11-28494a1b4382, serviceName=DeploymentService, currentState=RUNNING}
java.util.concurrent.ExecutionException: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local or cloud component version satisfies the requirements Check whether the version constraints conflict and that the component exists in your AWS account with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component ComponentA version constraints: ComponentC requires <2.0.0, thinggroup/ThingGroupA requires =2.5.0.
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:127)
at com.aws.greengrass.deployment.DefaultDeploymentTask.call(DefaultDeploymentTask.java:50)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: com.aws.greengrass.componentmanager.exceptions.NoAvailableComponentVersionException: No local or cloud component version satisfies the requirements Check whether the version constraints conflict and that the component exists in your AWS account with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component ComponentA version constraints: ComponentC requires <2.0.0, thinggroup/ThingGroupA requires =2.5.0.
at com.aws.greengrass.componentmanager.ComponentManager.negotiateVersionWithCloud(ComponentManager.java:232)
at com.aws.greengrass.componentmanager.ComponentManager.resolveComponentVersion(ComponentManager.java:167)
at com.aws.greengrass.componentmanager.DependencyResolver.lambda$resolveDependencies$0(DependencyResolver.java:134)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveComponentDependencies(DependencyResolver.java:231)
at com.aws.greengrass.componentmanager.DependencyResolver.resolveDependencies(DependencyResolver.java:131)
at com.aws.greengrass.deployment.DefaultDeploymentTask.lambda$call$2(DefaultDeploymentTask.java:125)
... 4 more
```
Os logs indicam que o nucleus não consegue encontrar uma versão do ComponenteA que satisfaça os requisitos a seguir.
+ Os requisitos para que o ComponentA seja exatamente a versão 2.5.0 (de ThingGroup A).
+ O requisito de trabalhar com versões do ComponenteC anteriores a 2.0.0.
##### Como resolver o problema
+ Se você quiser manter o componente em cada grupo de coisas, selecione a mesma versão desse componente em cada grupo de coisas.
+ Selecione uma versão do componente que atenda aos requisitos de implantação.
+ Se você quiser usar uma versão do componente que não atenda aos dois requisitos do grupo de coisas, selecione a versão do componente que atenda ao requisito da versão do grupo de coisas e use esse componente somente nesse grupo de coisas.
**dica**
Se você ver esse erro em qualquer componente AWS fornecido, poderá resolvê-lo atualizando os componentes em conflito para a versão mais recente.
## Removendo um dispositivo de um grupo de coisas
Quando você remove um dispositivo principal de um grupo de coisas, o comportamento de implantação do componente depende da versão do [Greengrass nucleus](greengrass-nucleus-component.md) que o dispositivo principal executa.
------
#### [ 2.5.1 and later ]
Quando você remove um dispositivo principal de um grupo de coisas, o comportamento depende se a AWS IoT política concede a `greengrass:ListThingGroupsForCoreDevice` permissão. Para obter mais informações sobre essa permissão e AWS IoT políticas para dispositivos principais, consulte[Autenticação e autorização de dispositivos para AWS IoT Greengrass](device-auth.md).
+ **Se a AWS IoT política conceder essa permissão**
Quando você remove um dispositivo principal de um grupo de coisas, AWS IoT Greengrass remove os componentes do grupo de coisas na próxima vez que uma implantação for feita no dispositivo. Se um componente no dispositivo for incluído na próxima implantação, esse componente não será removido do dispositivo.
+ **Se a AWS IoT política não conceder essa permissão**
Quando você remove um dispositivo principal de um grupo de coisas, AWS IoT Greengrass não exclui os componentes desse grupo de coisas do dispositivo.
Para remover um componente de um dispositivo, use o comando [deployment create](gg-cli-deployment.md#deployment-create) da CLI do Greengrass. Especifique o componente a ser removido com o `--remove` argumento e especifique o grupo de coisas com o `--groupId` argumento.
------
#### [ 2.5.0 ]
Quando você remove um dispositivo principal de um grupo de coisas, AWS IoT Greengrass remove os componentes do grupo de coisas na próxima vez que uma implantação for feita no dispositivo. Se um componente no dispositivo for incluído na próxima implantação, esse componente não será removido do dispositivo.
Esse comportamento exige que a AWS IoT política do dispositivo principal conceda a `greengrass:ListThingGroupsForCoreDevice` permissão. Se um dispositivo principal não tiver essa permissão, o dispositivo principal não aplicará implantações. Para obter mais informações, consulte [Autenticação e autorização de dispositivos para AWS IoT Greengrass](device-auth.md).
------
#### [ 2.0.x - 2.4.x ]
Quando você remove um dispositivo principal de um grupo de coisas, AWS IoT Greengrass não exclui os componentes desse grupo de coisas do dispositivo.
Para remover um componente de um dispositivo, use o comando [deployment create](gg-cli-deployment.md#deployment-create) da CLI do Greengrass. Especifique o componente a ser removido com o `--remove` argumento e especifique o grupo de coisas com o `--groupId` argumento.
------
## Implantações
As implantações são contínuas. Quando você cria uma implantação, AWS IoT Greengrass implementa a implantação nos dispositivos de destino que estão on-line. Se um dispositivo de destino não estiver on-line, ele receberá a implantação na próxima vez em que se conectar AWS IoT Greengrass. Quando você adiciona um dispositivo principal a um grupo de itens de destino, AWS IoT Greengrass envia ao dispositivo a implantação mais recente desse grupo de itens.
Antes de um dispositivo principal implantar um componente, por padrão, ele notifica cada componente no dispositivo. Os componentes do Greengrass podem responder à notificação para adiar a implantação. Talvez você queira adiar a implantação se o dispositivo tiver um nível de bateria baixo ou estiver executando um processo que não pode ser interrompido. Para obter mais informações, consulte [Tutorial: Desenvolver um componente do Greengrass que adia as atualizações de componentes](defer-component-updates-tutorial.md). Ao criar uma implantação, você pode configurá-la para ser implantada sem notificar os componentes.
Cada item ou grupo de itens de destino pode ter uma implantação por vez. Isso significa que quando você cria uma implantação para um destino, AWS IoT Greengrass não implanta mais a revisão anterior da implantação desse alvo.
## Opções de implantação
As implantações oferecem várias opções que permitem controlar quais dispositivos recebem uma atualização e como a atualização é implantada. Ao criar uma implantação, é possível configurar as seguintes opções:
+ **AWS IoT Greengrass componentes**
Defina os componentes a serem instalados e executados nos dispositivos de destino. AWS IoT Greengrass componentes são módulos de software que você implanta e executa nos dispositivos principais do Greengrass. Os dispositivos recebem componentes somente se o componente suportar a plataforma do dispositivo. Isso permite que você implante em grupos de dispositivos, mesmo que os dispositivos de destino sejam executados em várias plataformas. Se um componente não for compatível com a plataforma do dispositivo, o componente não será implantado no dispositivo.
Você pode implantar componentes AWS personalizados e componentes fornecidos em seus dispositivos. Quando você implanta um componente, AWS IoT Greengrass identifica todas as dependências do componente e as implanta também. Para obter mais informações, consulte [Desenvolver componentes do AWS IoT Greengrass](develop-greengrass-components.md) e [Componentes fornecidos pela AWS](public-components.md).
Você define a versão e a atualização de configuração a serem implantadas em cada componente. A *atualização de configuração* especifica como modificar a configuração existente do componente no dispositivo principal ou a configuração padrão do componente se o componente não existir no dispositivo principal. É possível especificar quais valores de configuração serão redefinidos para os valores padrão e os novos valores de configuração a serem mesclados no dispositivo principal. Quando um dispositivo principal recebe implantações para destinos diferentes e cada implantação especifica versões de componentes compatíveis, o dispositivo principal aplica as atualizações de configuração em ordem com base no log de data e hora de quando você cria a implantação. Para obter mais informações, consulte [Atualizar configurações do componente](update-component-configurations.md).
**Importante**
Quando você implanta um componente, AWS IoT Greengrass instala as versões mais recentes suportadas de todas as dependências desse componente. Por esse motivo, novas versões AWS de patch dos componentes públicos fornecidos podem ser implantadas automaticamente em seus dispositivos principais se você adicionar novos dispositivos a um grupo de coisas ou atualizar a implantação que visa esses dispositivos. Algumas atualizações automáticas, como a atualização do núcleo, podem fazer com que seus dispositivos sejam reiniciados inesperadamente.
Para evitar atualizações não intencionais para um componente que está sendo executado no dispositivo, recomendamos que você inclua diretamente sua versão preferida desse componente ao [criar uma implantação](create-deployments.md). Para obter mais informações sobre o comportamento de atualização AWS IoT Greengrass do software Core, consulte[Atualizar o software de núcleo do AWS IoT Greengrass (OTA)](update-greengrass-core-v2.md).
+ **Políticas de implantação**
Defina o momento em que é seguro implantar uma configuração e o que deve ser feito caso a implantação apresente falhas. É possível especificar se deve ou não esperar que os componentes relatem que podem ser atualizados. Você também pode especificar se deseja ou não reverter os dispositivos para a configuração anterior se eles aplicarem uma implantação que falhe.
+ **Parar a configuração**
Defina o momento e a maneira em que uma interrupção da implantação ocorrerá. A implantação é interrompida e falha se os critérios definidos por você forem atendidos. Por exemplo, você pode configurar uma implantação para ser interrompida se uma porcentagem de dispositivos não conseguir aplicá-la após um número mínimo de dispositivos recebê-la.
+ **Configuração de distribuição**
Defina a taxa na qual uma implantação é implantada nos dispositivos de destino. É possível configurar um aumento exponencial da taxa com limites mínimos e máximos de taxa.
+ **Configuração de tempo limite**
Defina o tempo máximo que cada dispositivo tem para aplicar uma implantação. Se um dispositivo exceder a duração especificada, o dispositivo não conseguirá aplicar a implantação.
**Importante**
Componentes personalizados podem definir artefatos em buckets do S3. Quando o software AWS IoT Greengrass principal implanta um componente, ele baixa os artefatos do componente do. Nuvem AWS As funções principais do dispositivo não permitem acesso aos buckets do S3 por padrão. Para implantar componentes personalizados que definem artefatos em um bucket do S3, a função principal do dispositivo deve conceder permissões para baixar artefatos desse bucket. Para obter mais informações, consulte [Permitir acesso aos buckets do S3 para artefatos de componentes](device-service-role.md#device-service-role-access-s3-bucket).
**Topics**
+ [Implantações de dispositivos do Core](#core-device-deployments)
+ [Resolução de dependências de plataformas](#platform-dependency-resolution)
+ [Resolução de dependências de componentes](#component-dependency-resolution)
+ [Removendo um dispositivo de um grupo de coisas](#thing-group-removal-behavior)
+ [Implantações](#deployments)
+ [Opções de implantação](#deployment-options)
+ [Criar implantações](create-deployments.md)
+ [Criar subimplantações](create-subdeployments.md)
+ [Revisões das implantações](revise-deployments.md)
+ [Cancelar implantações](cancel-deployments.md)
+ [Verificar o status da implantação](check-deployment-status.md)
# Criar implantações
Você pode criar uma implantação que tenha como alvo um objeto ou um grupo de objetos.
Ao criar uma implantação, você configura os componentes de software a serem implantados e como o trabalho de implantação é implementado nos dispositivos de destino. É possível definir a implantação no arquivo JSON que você fornece à AWS CLI.
O destino de implantação determina os dispositivos nos quais você deseja executar os componentes. Para implantar em um dispositivo principal, especifique um objeto. Para implantar em vários dispositivos principais, especifique um grupo de objetos que inclua esses dispositivos. Para mais informações sobre como configurar grupos de objetos, consulte [Grupos de objetos estáticos](https://docs.aws.amazon.com/iot/latest/developerguide/thing-groups.html) e [Grupos de objetos dinâmicos](https://docs.aws.amazon.com/iot/latest/developerguide/dynamic-thing-groups.html) no *Guia do desenvolvedor da AWS IoT*.
Siga as etapas nesta seção para criar uma implantação em um destino. Para mais informações sobre como atualizar os componentes de software em um destino que tenha uma implantação, consulte [Revisões das implantações](revise-deployments.md).
**Atenção**
A operação [CreateDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_CreateDeployment.html) pode desinstalar componentes dos dispositivos principais. Se um componente estiver presente na implantação anterior e não na nova implantação, o dispositivo principal desinstalará esse componente. Para evitar a desinstalação de componentes, primeiro use a operação [ListDeployments](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_ListDeployments.html) para verificar se o destino da implantação já tem uma implantação existente. Em seguida, use a operação [GetDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_GetDeployment.html) para começar a partir dessa implantação existente ao criar uma nova implantação.
**Para criar uma implantação (AWS CLI)**
1. Crie um arquivo chamado `deployment.json` e copie o objeto JSON a seguir no arquivo. Substitua *targetArn* pelo ARN do objeto ou grupo de objetos da AWS IoT a ser direcionado para a implantação. Os ARNs de objetos e de grupos de objetos têm o seguinte formato:
+ Coisa: `arn:aws:iot:region:account-id:thing/thingName`
+ Grupo de coisas: `arn:aws:iot:region:account-id:thinggroup/thingGroupName`
```
{
"targetArn": "targetArn"
}
```
1. Verifique se o destino de implantação tem uma implantação existente que você deseja revisar. Faça o seguinte:
1. Execute o comando a seguir para listar as implantações para o destino de implantação. Substitua *targetArn* pelo ARN do objeto da AWS IoT de destino ou pelo grupo de objetos.
```
aws greengrassv2 list-deployments --target-arn targetArn
```
A resposta contém uma lista com a implantação mais recente do destino. Se a resposta está vazia, o destino não tem uma implantação existente e você pode pular para [Step 3](#create-deployment-define-name-step). Caso contrário, copie o `deploymentId` da resposta para usar na próxima etapa.
**nota**
Também é possível revisar uma implantação diferente da revisão mais recente do destino. Especifique o argumento `--history-filter ALL` para listar todas as implantações do destino. Em seguida, copie o ID da implantação que você quer revisar.
1. Execute o comando a seguir para obter os detalhes da implantação. Esses detalhes incluem metadados, componentes e configuração do trabalho. Substitua *deploymentId* pelo ID da etapa anterior.
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
A resposta tem os detalhes da implantação.
1. Copie qualquer um dos seguintes pares de valores-chave da resposta do comando anterior para `deployment.json`. Você pode alterar esses valores para a nova implantação.
+ `deploymentName`: o nome da implantação.
+ `components`: os componentes da implantação. Para desinstalar um componente, remova-o desse objeto.
+ `deploymentPolicies`: as políticas da implantação.
+ `iotJobConfiguration`: a configuração do trabalho da implantação.
+ `tags`: as tags da implantação.
1. (Opcional) Defina um nome para a implantação. Substitua *deploymentName* pelo nome da implantação.
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName"
}
```
1. Adicione cada componente para implantar os dispositivos de destino. Para fazer isso, adicione pares de chave-valor ao objeto `components`, em que a chave é o nome do componente e o valor é um objeto que contém os detalhes desse componente. Especifique os seguintes detalhes para cada componente adicionado:
+ `version`: a versão do componente a ser implantada.
+ `configurationUpdate`: a [atualização de configuração](update-component-configurations.md) a ser implantada. A atualização é uma operação de patch que modifica a configuração existente do componente em cada dispositivo de destino ou a configuração padrão do componente se ela não existir no dispositivo de destino. Você pode especificar as seguintes atualizações de configuração:
+ Redefinir atualizações (`reset`): (opcional) uma lista de ponteiros JSON que definem os valores de configuração a serem redefinidos para seus valores padrão no dispositivo de destino. O software AWS IoT Greengrass Core aplica as atualizações de redefinição antes da aplicação das atualizações de mesclagem. Para obter mais informações, consulte [Atualizações de redefinição](update-component-configurations.md#reset-configuration-update).
+ Mesclar atualizações (`merge`): (opcional) um documento JSON que define os valores de configuração a serem mesclados no dispositivo de destino. Serialize o documento JSON como uma string. Para obter mais informações, consulte [Atualizações de mesclagem](update-component-configurations.md#merge-configuration-update).
+ `runWith`: (opcional) as opções de processo do sistema que o software AWS IoT Greengrass Core usa para executar os processos desse componente no dispositivo principal. Se você omitir um parâmetro no objeto `runWith`, o software AWS IoT Greengrass Core usará os valores padrão que você configurar no [componente do núcleo do Greengrass](greengrass-nucleus-component.md).
Você pode especificar qualquer uma das seguintes opções:
+ `posixUser`: o usuário do sistema POSIX e, como opção, o grupo a ser usado para executar este componente em dispositivos principais do Linux. O usuário e o grupo, se especificados, devem existir em cada dispositivo principal do Linux. Especifique o usuário e o grupo separando-os por dois pontos (`:`), no seguinte formato: `user:group`. O grupo é opcional. Caso um grupo não seja especificado, o software AWS IoT Greengrass Core usará o grupo primário para o usuário. Para obter mais informações, consulte [Configurar o usuário que executa os componentes](configure-greengrass-core-v2.md#configure-component-user).
+ `windowsUser`: o usuário do Windows a ser usado para executar esse componente nos dispositivos principais do Windows. O usuário deve existir em cada dispositivo principal do Windows e seu nome e senha devem estar armazenados na instância do gerenciador de credenciais da conta LocalSystem. Para obter mais informações, consulte [Configurar o usuário que executa os componentes](configure-greengrass-core-v2.md#configure-component-user).
Esse atributo está disponível para a versão 2.5.0 e posterior do [componente de núcleo do Greengrass](greengrass-nucleus-component.md).
+ `systemResourceLimits`: os limites de recursos do sistema a serem aplicados aos processos desse componente. Você pode aplicar limites de recursos do sistema a componentes Lambda genéricos e não conteinerizados. Para obter mais informações, consulte [Configurar limites de recursos do sistema para componentes](configure-greengrass-core-v2.md#configure-component-system-resource-limits).
Você pode especificar qualquer uma das seguintes opções:
+ `cpus`: a quantidade máxima de tempo de CPU que os processos deste componente podem usar no dispositivo principal. O tempo total da CPU de um dispositivo essencial é equivalente ao número de núcleos da CPU do dispositivo. Por exemplo, em um dispositivo principal com quatro núcleos da CPU, é possível definir esse valor como `2` a fim de limitar os processos do componente para 50% de uso em cada núcleo da CPU. Em um dispositivo com um núcleo da CPU, você pode definir esse valor como `0.25` a fim de limitar os processos do componente para 25% de uso da CPU. Caso o valor definido seja um número maior que o número de núcleos da CPU, o software AWS IoT Greengrass Core não limitará o uso da CPU do componente.
+ `memory`: a quantidade máxima de RAM, expressa em kilobytes, que esse processo de componente pode usar no dispositivo principal.
Esse atributo está disponível na versão 2.4.0 e posteriores do [componente do núcleo do Greengrass](greengrass-nucleus-component.md). Atualmente, o AWS IoT Greengrass não é compatível com esse atributo nos dispositivos principais do Windows.
**Example Exemplo de atualização de configuração básica**
O seguinte objeto `components` de exemplo especifica a implantação de um componente, `com.example.PythonRuntime`, que espera um parâmetro de configuração chamado `pythonVersion`.
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName",
"components": {
"com.example.PythonRuntime": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"merge": "{\"pythonVersion\":\"3.7\"}"
}
}
}
}
```
**Example Exemplo de atualização de configuração com atualizações de redefinição e mesclagem**
Considere um exemplo de componente de painel industrial, `com.example.IndustrialDashboard`, que tem a seguinte configuração padrão.
```
{
"name": null,
"mode": "REQUEST",
"network": {
"useHttps": true,
"port": {
"http": 80,
"https": 443
},
},
"tags": []
}
```
A atualização de configuração a seguir especifica as seguintes instruções:
1. Redefina a configuração HTTPS para o valor padrão (`true`).
1. Redefina a lista de etiquetas industriais para uma lista vazia.
1. Combine uma lista de etiquetas industriais que identificam fluxos de dados de temperatura e pressão para duas caldeiras.
```
{
"reset": [
"/network/useHttps",
"/tags"
],
"merge": {
"tags": [
"/boiler/1/temperature",
"/boiler/1/pressure",
"/boiler/2/temperature",
"/boiler/2/pressure"
]
}
}
```
O seguinte objeto `components` de exemplo especifica a implantação desse componente de painel industrial e a atualização de configuração.
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"reset": [
"/network/useHttps",
"/tags"
],
"merge": "{\"tags\":[\"/boiler/1/temperature\",\"/boiler/1/pressure\",\"/boiler/2/temperature\",\"/boiler/2/pressure\"]}"
}
}
}
}
```
1. (Opcional) Defina políticas para a implantação. Você pode configurar quando os dispositivos principais podem aplicar uma implantação com segurança ou o que fazer se um dispositivo principal não conseguir aplicar a implantação. Para isso, adicione um objeto `deploymentPolicies` ao `deployment.json` e, em seguida, faça o seguinte:
1. (Opcional) Especifique a política de atualização de componente (`componentUpdatePolicy`). Essa política define se a implantação permite ou não que os componentes adiem uma atualização até que estejam prontos para serem atualizados. Por exemplo, os componentes podem precisar limpar recursos ou concluir ações críticas antes de serem reiniciados para aplicar uma atualização. Essa política também define a quantidade de tempo que os componentes têm para responder a uma notificação de atualização.
Esta política é um objeto com os seguintes parâmetros:
+ `action`: (opcional) notifica, ou não, os componentes e aguarda que eles possam informar quando estiverem prontos para atualização. Escolha uma das seguintes opções:
+ `NOTIFY_COMPONENTS`: a implantação notifica cada componente antes que ele seja interrompido e atualiza esse componente. Os componentes podem usar a operação de IPC [SubscribeToComponentUpdates](ipc-component-lifecycle.md#ipc-operation-subscribetocomponentupdates) para receber essas notificações.
+ `SKIP_NOTIFY_COMPONENTS`: a implantação não notifica os componentes ou aguarda que eles possam ser atualizados com segurança.
O padrão é `NOTIFY_COMPONENTS`.
+ `timeoutInSeconds`: a quantidade de tempo, em segundos, que cada componente tem para responder a uma notificação de atualização com a operação de IPC [DeferComponentUpdate](ipc-component-lifecycle.md#ipc-operation-defercomponentupdate). Se o componente não responder dentro desse período, a implantação prosseguirá no dispositivo principal.
O padrão é 60 segundos.
1. (Opcional) Especifique a política de validação de configuração (`configurationValidationPolicy`). Esta política define quanto tempo cada componente tem para validar uma atualização de configuração de uma implantação. Os componentes podem usar a operação de IPC [SubscribeToValidateConfigurationUpdates](ipc-component-configuration.md#ipc-operation-subscribetovalidateconfigurationupdates) para assinar notificações para as próprias atualizações de configuração. Em seguida, os componentes podem usar a operação de IPC [SendConfigurationValidityReport](ipc-component-configuration.md#ipc-operation-sendconfigurationvalidityreport) para informar ao software AWS IoT Greengrass Core se a atualização de configuração é válida. Se a atualização de configuração não for válida, a implantação falhará.
Esta política é um objeto com o seguinte parâmetro:
+ `timeoutInSeconds` (Opcional) a quantidade de tempo em segundos que cada componente tem para validar uma atualização de configuração. Se o componente não responder dentro desse período, a implantação prosseguirá no dispositivo principal.
O padrão é 30 segundos.
1. (Opcional) Especifique a política de tratamento de falhas (`failureHandlingPolicy`). Essa política é uma sequência de caracteres que define se os dispositivos devem ser revertidos ou não se a implantação falhar. Escolha uma das seguintes opções:
+ `ROLLBACK`: se a implantação falhar em um dispositivo principal, o software AWS IoT Greengrass Core reverterá esse dispositivo principal para a configuração anterior.
+ `DO_NOTHING`: se a implantação falhar em um dispositivo principal, o software AWS IoT Greengrass Core manterá a nova configuração. Isso pode resultar em componentes com falha se a nova configuração não for válida.
O padrão é `ROLLBACK`.
Sua implantação em `deployment.json` pode ser semelhante ao exemplo a seguir:
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"reset": [
"/network/useHttps",
"/tags"
],
"merge": "{\"tags\":[\"/boiler/1/temperature\",\"/boiler/1/pressure\",\"/boiler/2/temperature\",\"/boiler/2/pressure\"]}"
}
}
},
"deploymentPolicies": {
"componentUpdatePolicy": {
"action": "NOTIFY_COMPONENTS",
"timeoutInSeconds": 30
},
"configurationValidationPolicy": {
"timeoutInSeconds": 60
},
"failureHandlingPolicy": "ROLLBACK"
}
}
```
1. (Opcional) Defina como a implantação é interrompida, implementada ou expira. O AWS IoT Greengrass usa trabalhos do AWS IoT Core para enviar implantações aos dispositivos principais, portanto, essas opções são idênticas às opções de configuração dos trabalhos do AWS IoT Core. Para mais informações, consulte [Configuração para implantar e anular trabalhos](https://docs.aws.amazon.com/iot/latest/developerguide/job-rollout-abort.html) no *Guia do desenvolvedor da AWS IoT*.
Para definir as opções de trabalho, adicione um objeto `iotJobConfiguration` ao `deployment.json`. Em seguida, defina as opções a serem configuradas.
Sua implantação em `deployment.json` pode ser semelhante ao exemplo a seguir:
```
{
"targetArn": "targetArn",
"deploymentName": "deploymentName",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"reset": [
"/network/useHttps",
"/tags"
],
"merge": "{\"tags\":[\"/boiler/1/temperature\",\"/boiler/1/pressure\",\"/boiler/2/temperature\",\"/boiler/2/pressure\"]}"
}
}
},
"deploymentPolicies": {
"componentUpdatePolicy": {
"action": "NOTIFY_COMPONENTS",
"timeoutInSeconds": 30
},
"configurationValidationPolicy": {
"timeoutInSeconds": 60
},
"failureHandlingPolicy": "ROLLBACK"
},
"iotJobConfiguration": {
"abortConfig": {
"criteriaList": [
{
"action": "CANCEL",
"failureType": "ALL",
"minNumberOfExecutedThings": 100,
"thresholdPercentage": 5
}
]
},
"jobExecutionsRolloutConfig": {
"exponentialRate": {
"baseRatePerMinute": 5,
"incrementFactor": 2,
"rateIncreaseCriteria": {
"numberOfNotifiedThings": 10,
"numberOfSucceededThings": 5
}
},
"maximumPerMinute": 50
},
"timeoutConfig": {
"inProgressTimeoutInMinutes": 5
}
}
}
```
1. (Opcional) Adicione tags (`tags`) à implantação. Para obter mais informações, consulte [Marque seus AWS IoT Greengrass Version 2 recursos](tag-resources.md).
1. Execute o seguinte comando para criar uma estratégia de implantação do `deployment.json`.
```
aws greengrassv2 create-deployment --cli-input-json file://deployment.json
```
A resposta inclui um `deploymentId` que identifica essa implantação. Você pode usar o ID de implantação para verificar o status dela. Para obter mais informações, consulte [Verificar o status da implantação](check-deployment-status.md#check-cloud-deployment-status).
# Atualizar configurações do componente
As configurações de componente são objetos JSON que definem os parâmetros de cada componente. A fórmula de cada componente define sua configuração padrão, que você modifica ao implantar componentes em dispositivos principais.
Ao criar uma implantação, você pode especificar a *atualização de configuração* que será aplicada a cada componente. As atualizações de configuração são operações de patch, ou seja, a atualização modifica a configuração do componente que existe no dispositivo principal. Se o dispositivo principal não tiver o componente, a atualização de configuração modificará e aplicará a configuração padrão a essa implantação.
A atualização de configuração define atualizações de *redefinição* e de *mesclagem*. As atualizações de redefinição determinam os valores de configuração que devem ser redefinidos aos padrões ou removidos. As atualizações de mesclagem determinam os novos valores de configuração que serão definidos no componente. Quando você implanta uma atualização de configuração, o software AWS IoT Greengrass Core executa a atualização de redefinição antes da atualização de mesclagem.
Os componentes podem validar as atualizações de configuração que você implanta. O componente faz a assinatura para receber uma notificação quando a implantação altera sua configuração e pode rejeitar uma configuração à qual não ofereça suporte. Para obter mais informações, consulte [Interagir com a configuração do componente](ipc-component-configuration.md).
**Topics**
+ [Atualizações de redefinição](#reset-configuration-update)
+ [Atualizações de mesclagem](#merge-configuration-update)
+ [Exemplos](#configuration-update-example)
## Atualizações de redefinição
As atualizações de redefinição determinam os valores que devem ser redefinidos aos padrões no dispositivo principal. Se um valor de configuração não tiver um padrão, a atualização de redefinição o removerá da configuração do componente. Isso pode ajudar você a corrigir um componente com falha por causa de uma configuração inválida.
Use uma lista de ponteiros JSON para determinar os valores de configuração que devem ser redefinidos. Os ponteiros JSON começam com uma barra `/`. Para identificar um valor em uma configuração de componente aninhado, use barras (`/`) para separar as chaves de cada nível na configuração. Para obter mais informações, consulte a [Especificação de ponteiros JSON](https://tools.ietf.org/html/rfc6901) (em inglês).
**nota**
Você pode redefinir somente uma lista inteira aos valores padrão. Você não pode usar as atualizações de redefinição para redefinir apenas um elemento de uma lista.
Para redefinir toda a configuração de um componente aos valores padrão, especifique uma única string vazia como a atualização de redefinição.
```
"reset": [""]
```
## Atualizações de mesclagem
As atualizações de mesclagem definem os valores de configuração que serão inseridos na configuração do componente no núcleo. A atualização de mesclagem é um objeto JSON que o software AWS IoT Greengrass Core mescla depois de redefinir os valores nos caminhos que você especifica na atualização de redefinição. Ao usar o AWS CLI ou AWS SDKs, você deve serializar esse objeto JSON como uma string.
Você pode mesclar um par de chave/valor que não existe na configuração padrão do componente. Você também pode mesclar um par de chave/valor que tenha um tipo diferente do valor com a mesma chave. O novo valor substitui o valor antigo. Isso significa que você pode alterar a estrutura do objeto de configuração.
Você pode mesclar valores nulos e strings, listas e objetos vazios.
**nota**
Você não pode usar atualizações de mesclagem com a finalidade de inserir ou anexar um elemento a uma lista. Você pode substituir uma lista inteira ou definir um objeto em que cada elemento tenha uma chave exclusiva.
AWS IoT Greengrass usa JSON para valores de configuração. O JSON especifica um tipo de número, mas não diferencia entre números inteiros e flutuantes. Como resultado, os valores de configuração podem ser convertidos em flutuantes no AWS IoT Greengrass. Para garantir que seu componente use o tipo de dados correto, recomendamos que você defina valores de configuração numéricos como strings. Em seguida, faça com que seu componente os analise como números inteiros ou flutuantes. Isso garante que seus valores de configuração tenham o mesmo tipo na configuração e no seu dispositivo principal.
### Usar variáveis de fórmula em atualizações de mesclagem
Esse recurso está disponível para a versão 2.6.0 e posterior do [componente de núcleo do Greengrass](greengrass-nucleus-component.md).
Se você definir a opção de [interpolateComponentConfiguration](greengrass-nucleus-component.md#greengrass-nucleus-component-configuration-interpolate-component-configuration)configuração do núcleo do Greengrass como`true`, poderá usar variáveis de receita, além da variável de `component_dependency_name:configuration:json_pointer` receita, em atualizações de mesclagem. Por exemplo, você pode usar a variável de `{iot:thingName}` receita em uma atualização de mesclagem para incluir o nome do item do AWS IoT dispositivo principal em um valor de configuração do componente, como uma política de autorização de [comunicação entre processos (IPC)](interprocess-communication.md#ipc-authorization-policies).
## Exemplos
O exemplo a seguir demonstra as atualizações de configuração para um componente do painel que tem a configuração padrão abaixo. Este componente de exemplo exibe informações sobre equipamentos industriais.
```
{
"name": null,
"mode": "REQUEST",
"network": {
"useHttps": true,
"port": {
"http": 80,
"https": 443
},
},
"tags": []
}
```
### Fórmula de componente do painel industrial
------
#### [ JSON ]
```
{
"RecipeFormatVersion": "2020-01-25",
"ComponentName": "com.example.IndustrialDashboard",
"ComponentVersion": "1.0.0",
"ComponentDescription": "Displays information about industrial equipment.",
"ComponentPublisher": "Amazon",
"ComponentConfiguration": {
"DefaultConfiguration": {
"name": null,
"mode": "REQUEST",
"network": {
"useHttps": true,
"port": {
"http": 80,
"https": 443
},
},
"tags": []
}
},
"Manifests": [
{
"Platform": {
"os": "linux"
},
"Lifecycle": {
"Run": "python3 -u {artifacts:path}/industrial_dashboard.py"
}
},
{
"Platform": {
"os": "windows"
},
"Lifecycle": {
"Run": "py -3 -u {artifacts:path}/industrial_dashboard.py"
}
}
]
}
```
------
#### [ YAML ]
```
---
RecipeFormatVersion: '2020-01-25'
ComponentName: com.example.IndustrialDashboard
ComponentVersion: '1.0.0'
ComponentDescription: Displays information about industrial equipment.
ComponentPublisher: Amazon
ComponentConfiguration:
DefaultConfiguration:
name: null
mode: REQUEST
network:
useHttps: true
port:
http: 80
https: 443
tags: []
Manifests:
- Platform:
os: linux
Lifecycle:
Run: |
python3 -u {artifacts:path}/industrial_dashboard.py
- Platform:
os: windows
Lifecycle:
Run: |
py -3 -u {artifacts:path}/industrial_dashboard.py
```
------
**Example Exemplo 1: atualização de mesclagem**
Você cria uma implantação que aplica a atualização de configuração a seguir, que especifica uma atualização de mesclagem, mas não uma atualização de redefinição. Essa atualização de configuração instrui o componente a exibir o painel na porta HTTP 8080 com os dados de duas caldeiras.
**Configuração a ser mesclada**
```
{
"name": "Factory 2A",
"network": {
"useHttps": false,
"port": {
"http": 8080
}
},
"tags": [
"/boiler/1/temperature",
"/boiler/1/pressure",
"/boiler/2/temperature",
"/boiler/2/pressure"
]
}
```
O comando a seguir cria uma implantação em um dispositivo principal.
```
aws greengrassv2 create-deployment --cli-input-json file://dashboard-deployment.json
```
O arquivo `dashboard-deployment.json` contém o documento JSON a seguir.
```
{
"targetArn": "arn:aws:iot:us-west-2:123456789012:thing/MyGreengrassCore",
"deploymentName": "Deployment for MyGreengrassCore",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"merge": "{\"name\":\"Factory 2A\",\"network\":{\"useHttps\":false,\"port\":{\"http\":8080}},\"tags\":[\"/boiler/1/temperature\",\"/boiler/1/pressure\",\"/boiler/2/temperature\",\"/boiler/2/pressure\"]}"
}
}
}
}
```
O comando da [CLI do Greengrass](greengrass-cli-component.md) a seguir cria uma implantação local em um dispositivo principal.
```
sudo greengrass-cli deployment create \
--recipeDir recipes \
--artifactDir artifacts \
--merge "com.example.IndustrialDashboard=1.0.0" \
--update-config dashboard-configuration.json
```
O arquivo `dashboard-configuration.json` contém o documento JSON a seguir.
```
{
"com.example.IndustrialDashboard": {
"MERGE": {
"name": "Factory 2A",
"network": {
"useHttps": false,
"port": {
"http": 8080
}
},
"tags": [
"/boiler/1/temperature",
"/boiler/1/pressure",
"/boiler/2/temperature",
"/boiler/2/pressure"
]
}
}
}
```
Após essa atualização, o componente do painel terá a configuração abaixo.
```
{
"name": "Factory 2A",
"mode": "REQUEST",
"network": {
"useHttps": false,
"port": {
"http": 8080,
"https": 443
}
},
"tags": [
"/boiler/1/temperature",
"/boiler/1/pressure",
"/boiler/2/temperature",
"/boiler/2/pressure"
]
}
```
**Example Exemplo 2: redefinir e mesclar atualizações**
Em seguida, você cria uma implantação que aplica a atualização de configuração a seguir, que especifica uma atualização de redefinição e uma de mesclagem. Essas atualizações especificam a exibição do painel na porta HTTPS padrão com os dados das caldeiras diferentes. Essas atualizações modificam a configuração resultante das atualizações de configuração no exemplo anterior.
**Caminhos de redefinição**
```
[
"/network/useHttps",
"/tags"
]
```
**Configuração a ser mesclada**
```
{
"tags": [
"/boiler/3/temperature",
"/boiler/3/pressure",
"/boiler/4/temperature",
"/boiler/4/pressure"
]
}
```
O comando a seguir cria uma implantação em um dispositivo principal.
```
aws greengrassv2 create-deployment --cli-input-json file://dashboard-deployment2.json
```
O arquivo `dashboard-deployment2.json` contém o documento JSON a seguir.
```
{
"targetArn": "arn:aws:iot:us-west-2:123456789012:thing/MyGreengrassCore",
"deploymentName": "Deployment for MyGreengrassCore",
"components": {
"com.example.IndustrialDashboard": {
"componentVersion": "1.0.0",
"configurationUpdate": {
"reset": [
"/network/useHttps",
"/tags"
],
"merge": "{\"tags\":[\"/boiler/3/temperature\",\"/boiler/3/pressure\",\"/boiler/4/temperature\",\"/boiler/4/pressure\"]}"
}
}
}
}
```
O comando da [CLI do Greengrass](greengrass-cli-component.md) a seguir cria uma implantação local em um dispositivo principal.
```
sudo greengrass-cli deployment create \
--recipeDir recipes \
--artifactDir artifacts \
--merge "com.example.IndustrialDashboard=1.0.0" \
--update-config dashboard-configuration2.json
```
O arquivo `dashboard-configuration2.json` contém o documento JSON a seguir.
```
{
"com.example.IndustrialDashboard": {
"RESET": [
"/network/useHttps",
"/tags"
],
"MERGE": {
"tags": [
"/boiler/3/temperature",
"/boiler/3/pressure",
"/boiler/4/temperature",
"/boiler/4/pressure"
]
}
}
}
```
Após essa atualização, o componente do painel terá a configuração abaixo.
```
{
"name": "Factory 2A",
"mode": "REQUEST",
"network": {
"useHttps": true,
"port": {
"http": 8080,
"https": 443
}
},
"tags": [
"/boiler/3/temperature",
"/boiler/3/pressure",
"/boiler/4/temperature",
"/boiler/4/pressure",
]
}
```
# Criar subimplantações
**nota**
O atributo de subimplantação está disponível no núcleo do Greengrass versão 2.9.0 e posteriores. Não é possível implantar uma configuração em uma subimplantação com versões anteriores de componentes do núcleo do Greengrass.
Uma subimplantação é uma implantação que tem como alvo um subconjunto menor de dispositivos em uma implantação principal. Você pode usar subimplantações para implantar uma configuração em um subconjunto menor de dispositivos. Você também pode criar subimplantações para tentar novamente uma implantação principal malsucedida quando um ou mais dispositivos nela falharem. Com esse atributo, você pode selecionar dispositivos que falharam nessa implantação principal e criar uma subimplantação para testar as configurações até que ela seja bem-sucedida. Depois que a subimplantação for bem-sucedida, será possível reimplantar essa configuração na implantação principal.
Siga as etapas nesta seção para criar uma subimplantação e verificar o status. Para obter mais informações sobre como criar implantações, consulte [Criar implantações](https://docs.aws.amazon.com/greengrass/v2/developerguide/create-deployments.html).
**Para criar uma subimplantação (AWS CLI)**
1. Execute o comando a seguir para recuperar as implantações mais recentes de um grupo de objetos. Substitua o ARN no comando pelo ARN do grupo de objetos a ser consultado. Defina `--history-filter` como **LATEST\$1ONLY** para ver a implantação mais recente desse grupo de objetos.
```
aws greengrassv2 list-deployments --target-arn arn:aws:iot:region:account-id:thinggroup/thingGroupName --history-filter LATEST_ONLY
```
1. Copie o `deploymentId` da resposta para o comando **list-deployments** usar na próxima etapa.
1. Execute o seguinte comando para recuperar o status de uma implantação. Substitua `deploymentId` pelo ID da implantação a ser consultada.
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
1. Copie o `iotJobId` da resposta para o comando **get-deployment** usar na etapa seguinte.
1. Execute o comando a seguir para recuperar a lista de execuções do trabalho para o trabalho especificado. Substitua *jobID* pelo `iotJobId` da etapa anterior. Substitua *status* pelo status que você deseja filtrar. Você pode filtrar os resultados com os seguintes status:
+ `QUEUED`
+ `IN_PROGRESS`
+ `SUCCEEDED`
+ `FAILED`
+ `TIMED_OUT`
+ `REJECTED`
+ `REMOVED`
+ `CANCELED`
```
aws iot list-job-executions-for-job --job-id jobID --status status
```
1. Crie um novo grupo de objetos AWS IoT ou use um grupo de objetos existente para a subimplantação. Então, adicione um objeto AWS IoT a esse grupo. Use grupos de objetos para gerenciar frotas de dispositivos principais do Greengrass. Ao implantar componentes de software nos dispositivos, é possível segmentar dispositivos individuais ou grupos de dispositivos. Você pode adicionar um dispositivo a um grupo de objetos com uma implantação ativa do Greengrass. Depois de adicionado, é possível implantar os componentes de software desse grupo de objetos nesse dispositivo.
Para criar um grupo de objetos e adicionar seus dispositivos a ele, faça o seguinte:
1. Crie um grupo de objetos da AWS IoT. Substitua *MyGreengrassCoreGroup* pelo nome do novo grupo de objetos. Você não pode usar dois pontos (:) no nome de um grupo de objetos.
**nota**
Se um grupo de objetos para uma subimplantação for usado com um `parentTargetArn`, ele não poderá ser reutilizado com uma frota principal diferente. Se um grupo de objetos já tiver sido usado para criar uma subimplantação para outra frota, a API retornará um erro.
```
aws iot create-thing-group --thing-group-name MyGreengrassCoreGroup
```
Se a solicitação for bem-sucedida, a resposta será semelhante ao exemplo a seguir:.
```
{
"thingGroupName": "MyGreengrassCoreGroup",
"thingGroupArn": "arn:aws:iot:us-west-2:123456789012:thinggroup/MyGreengrassCoreGroup",
"thingGroupId": "4df721e1-ff9f-4f97-92dd-02db4e3f03aa"
}
```
1. Adicione um núcleo provisionado do Greengrass ao seu grupo de objetos. Execute o seguinte comando com estes parâmetros:
+ Substitua *MyGreengrassCore* pelo nome do seu núcleo provisionado do Greengrass.
+ Substitua *MyGreengrassCoreGroup* pelo nome do grupo de objetos.
```
aws iot add-thing-to-thing-group --thing-name MyGreengrassCore --thing-group-name MyGreengrassCoreGroup
```
O comando não terá nenhuma saída se a solicitação for bem-sucedida.
1. Crie um arquivo chamado `deployment.json` e copie o objeto JSON a seguir no arquivo. Substitua *targetArn* pelo ARN do grupo de objetos da AWS IoT para direcionar a subimplantação. Um alvo de subimplantação só pode ser um grupo de objetos. Os ARNs de grupos de objetos têm o seguinte formato:
+ **Grupo de objetos**: `arn:aws:iot:region:account-id:thinggroup/thingGroupName`
```
{
"targetArn": "targetArn"
}
```
1. Execute o comando a seguir novamente para obter os detalhes da implantação original. Esses detalhes incluem metadados, componentes e configuração do trabalho. Substitua *deploymentID* pelo ID de [Step 1](#create-subdeployments-step1). É possível usar essa configuração de implantação para configurar sua subimplantação e fazer alterações conforme necessário.
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
A resposta tem os detalhes da implantação. Copie qualquer um dos seguintes pares de valores-chave da resposta do comando **get-deployment** para `deployment.json`. Você pode alterar esses valores para a subimplantação. Para obter mais informações sobre os detalhes deste comando, consulte [GetDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_GetDeployment.html).
+ `components`: os componentes da implantação. Para desinstalar um componente, remova-o desse objeto.
+ `deploymentName`: o nome da implantação.
+ `deploymentPolicies`: as políticas da implantação.
+ `iotJobConfiguration`: a configuração do trabalho da implantação.
+ `parentTargetArn`: o alvo da implantação principal.
+ `tags`: as tags da implantação.
1. Execute o seguinte comando para criar uma estratégia de subimplantação do `deployment.json`. Substitua *subdeploymentName* por um nome para a subimplantação.
```
aws greengrassv2 create-deployment --deployment-name subdeploymentName --cli-input-json file://deployment.json
```
A resposta inclui um `deploymentId` que identifica essa subimplantação. Você pode usar o ID de implantação para verificar o status dela. Para obter mais informações, consulte [Verificar status da implantação](https://docs.aws.amazon.com/greengrass/v2/developerguide/check-deployment-status.html#check-cloud-deployment-status).
1. Se a subimplantação for bem-sucedida, você poderá usar a configuração dela para revisar a implantação principal. Copie `deployment.json` que você usou na etapa anterior. Substitua o `targetArn` no arquivo JSON pelo ARN da implantação principal e execute o comando a seguir para criar a implantação principal usando essa nova configuração.
**nota**
Se você criar uma nova revisão de implantação da frota principal, ela substituirá todas as revisões e subimplantações dessa implantação principal. Para obter mais informações, consulte [Revisar implantações](https://docs.aws.amazon.com/greengrass/v2/developerguide/revise-deployments.html).
```
aws greengrassv2 create-deployment --cli-input-json file://deployment.json
```
A resposta inclui um `deploymentId` que identifica essa implantação. Você pode usar o ID de implantação para verificar o status dela. Para obter mais informações, consulte [Verificar o status da implantação](check-deployment-status.md#check-cloud-deployment-status).
# Revisões das implantações
Cada item ou grupo de itens de destino pode ter uma implantação ativa por vez. Ao criar uma implantação para um destino que já tem uma implantação, os componentes de software na nova implantação substituem os da implantação anterior. Se a nova implantação não definir um componente definido pela implantação anterior, o software AWS IoT Greengrass Core removerá esse componente dos dispositivos principais de destino. Você pode revisar uma implantação existente para não remover os componentes executados nos dispositivos principais de uma implantação anterior em um destino.
Para revisar uma implantação, você cria uma implantação que começa com os mesmos componentes e configurações existentes em uma implantação anterior. [Você usa a operação [CreateDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_CreateDeployment.html), que é a mesma operação usada para criar implantações](create-deployments.md).
**Para revisar uma implantação (AWS CLI)**
1. Execute o comando a seguir para listar as implantações para o destino de implantação. Substitua *targetArn* pelo ARN do objeto da AWS IoT de destino ou pelo grupo de objetos.
```
aws greengrassv2 list-deployments --target-arn targetArn
```
A resposta contém uma lista com a implantação mais recente do destino. Copie o `deploymentId` da resposta para usar na próxima etapa.
**nota**
Você também pode revisar uma implantação diferente da revisão mais recente do destino. Especifique o argumento `--history-filter ALL` para listar todas as implantações do destino. Em seguida, copie o ID da implantação que você quer revisar.
1. Execute o comando a seguir para obter os detalhes da implantação. Esses detalhes incluem metadados, componentes e configuração do trabalho. Substitua *deploymentId* pelo ID da etapa anterior.
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
A resposta tem os detalhes da implantação.
1. Crie um arquivo chamado `deployment.json` e copie a resposta do comando anterior no arquivo.
1. Remova os seguintes pares de chave-valor do objeto JSON em `deployment.json`:
+ `deploymentId`
+ `revisionId`
+ `iotJobId`
+ `iotJobArn`
+ `creationTimestamp`
+ `isLatestForTarget`
+ `deploymentStatus`
A operação [CreateDeployment](https://docs.aws.amazon.com/greengrass/v2/APIReference/API_CreateDeployment.html) espera uma carga útil com a estrutura a seguir.
```
{
"targetArn": "String",
"components": Map of components,
"deploymentPolicies": DeploymentPolicies,
"iotJobConfiguration": DeploymentIoTJobConfiguration,
"tags": Map of tags
}
```
1. Em `deployment.json` proceda de uma das seguintes maneiras:
+ Altere o nome da implantação (`deploymentName`).
+ Altere os componentes da implantação (`components`).
+ Altere as políticas da implantação (`deploymentPolicies`).
+ Altere a configuração do trabalho da implantação (`iotJobConfiguration`).
+ Altere as tags da implantação (`tags`).
Para obter mais informações sobre como definir esses detalhes de implantação, consulte [Criar implantações](create-deployments.md).
1. Execute o seguinte comando para criar uma estratégia de implantação do `deployment.json`.
```
aws greengrassv2 create-deployment --cli-input-json file://deployment.json
```
A resposta inclui um `deploymentId` que identifica essa implantação. Você pode usar o ID de implantação para verificar o status dela. Para obter mais informações, consulte [Verificar o status da implantação](check-deployment-status.md#check-cloud-deployment-status).
# Cancelar implantações
É possível cancelar uma implantação ativa para impedir que seus componentes de software sejam instalados nos dispositivos principais do AWS IoT Greengrass. Se você cancelar uma implantação que tenha como alvo um grupo de coisas, os dispositivos principais que adicionar ao grupo não receberão essa implantação contínua. Se um dispositivo principal já executa a implantação, você não alterará os componentes desse dispositivo ao cancelar a implantação. Você deve [criar uma implantação](create-deployments.md) ou [revisar a implantação](revise-deployments.md) para modificar os componentes que são executados nos dispositivos principais que receberam a implantação cancelada.
**Cancelar uma implantação (AWS CLI)**
1. Execute o comando a seguir para descobrir o ID da revisão de implantação mais recente de um destino. A revisão mais recente é a única implantação que pode estar ativa para um destino, porque as implantações anteriores são canceladas quando você cria uma revisão. Substitua *targetArn* pelo ARN da coisa ou grupo de coisas do AWS IoT de destino.
```
aws greengrassv2 list-deployments --target-arn targetArn
```
A resposta contém uma lista com a implantação mais recente do destino. Copie o `deploymentId` da resposta para usar na próxima etapa.
1. Execute o comando a seguir para cancelar a implantação. Substitua *deploymentId* pelo ID da etapa anterior.
```
aws greengrassv2 cancel-deployment --deployment-id deploymentId
```
Se a operação ocorrer com sucesso, o status de implantação mudará para `CANCELED`.
# Verificar o status da implantação
É possível verificar o status de uma implantação que você criou no AWS IoT Greengrass. Também é possível verificar o status dos trabalhos do AWS IoT que executam a implantação em cada dispositivo principal. Enquanto uma implantação estiver ativa, o status do trabalho do AWS IoT é `IN_PROGRESS`. Depois de criar uma revisão de uma implantação, o status do trabalho do AWS IoT da revisão anterior muda para `CANCELLED`.
**Topics**
+ [Verificar o status da implantação](#check-cloud-deployment-status)
+ [Verificar o status da implantação do dispositivo](#check-device-deployment-status)
## Verificar o status da implantação
É possível verificar o status de uma implantação identificada pelo destino ou pelo ID.
**Como verificar o status da implantação por destino (AWS CLI)**
+ Execute o comando a seguir para recuperar o status da implantação mais recente de um destino. Substitua *targetArn* pelo nome do recurso da Amazon (ARN) da coisa ou grupo de coisas do AWS IoT que a implantação tem como destino.
```
aws greengrassv2 list-deployments --target-arn targetArn
```
A resposta contém uma lista com a implantação mais recente do destino. Esse objeto de implantação inclui o status da implantação.
**Como verificar o status da implantação por ID (AWS CLI)**
+ Execute o comando a seguir para recuperar o status de uma implantação. Substitua *deploymentId* pelo ID da implantação a ser consultada.
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
A resposta contém o status da implantação.
## Verificar o status da implantação do dispositivo
É possível verificar o status de um trabalho de implantação que se aplica a um dispositivo principal individual. Também é possível verificar o status de um trabalho de implantação para uma implantação de um grupo de coisas.
**Como verificar o status do trabalho de implantação de um dispositivo principal (AWS CLI)**
+ Execute o comando a seguir para recuperar o status de todos os trabalhos de implantação de um dispositivo principal. Substitua *coreDeviceName* pelo nome do dispositivo principal que será consultado.
```
aws greengrassv2 list-effective-deployments --core-device-thing-name coreDeviceName
```
A resposta contém a lista de trabalhos de implantação do dispositivo principal. É possível identificar o trabalho para uma implantação pelo `deploymentId` ou `targetArn` do trabalho. Cada trabalho de implantação contém o status do trabalho no dispositivo principal.
**Como verificar o status de implantação de um grupo de coisas (AWS CLI)**
1. Execute o comando a seguir para recuperar o ID de uma implantação existente. Substitua *targetArn* pelo ARN do grupo de coisas de destino.
```
aws greengrassv2 list-deployments --target-arn targetArn
```
A resposta contém uma lista com a implantação mais recente do destino. Copie o `deploymentId` da resposta para usar na próxima etapa.
**nota**
Também é possível listar uma implantação diferente da implantação mais recente do destino. Especifique o argumento `--history-filter ALL` para listar todas as implantações do destino. Em seguida, copie o ID da implantação cujo status você quer verificar.
1. Execute o comando a seguir para obter os detalhes da implantação. Substitua *deploymentID* pelo ID da etapa anterior.
```
aws greengrassv2 get-deployment --deployment-id deploymentId
```
A resposta contém informações sobre a implantação. Copie o `iotJobId` da resposta para usar na etapa a seguir.
1. Execute o comando a seguir para descrever a execução do trabalho de um dispositivo principal para a implantação. Substitua *iotJobId* e *coreDeviceThingName* pelo ID do trabalho da etapa anterior e pelo dispositivo principal do qual você deseja verificar o status.
```
aws iot describe-job-execution --job-id iotJobId --thing-name coreDeviceThingName
```
A resposta contém o status da execução do trabalho de implantação do dispositivo principal e detalhes sobre o status. O `detailsMap` contém as seguintes informações:
+ `detailed-deployment-status`: o status do resultado da implantação, que pode ter um dos seguintes valores:
+ `SUCCESSFUL`: a implantação foi bem-sucedida.
+ `FAILED_NO_STATE_CHANGE`: a implantação falhou enquanto o dispositivo principal se preparava para aplicar a implantação.
+ `FAILED_ROLLBACK_NOT_REQUESTED`: a implantação falhou e a implantação não especificou a reversão para uma configuração de trabalho anterior, portanto, o dispositivo principal pode não estar funcionando corretamente.
+ `FAILED_ROLLBACK_COMPLETE`: a implantação falhou e o dispositivo principal foi revertido com sucesso para uma configuração de trabalho anterior.
+ `FAILED_UNABLE_TO_ROLLBACK`: a implantação falhou e o dispositivo principal não conseguiu reverter para uma configuração de trabalho anterior, portanto, o dispositivo principal pode não estar funcionando corretamente.
Se a implantação falhar, verifique o valor `deployment-failure-cause` e os arquivos de log do dispositivo principal para identificar o problema. Para obter mais informações sobre como acessar os arquivos de log do dispositivo principal, consulte [Monitore AWS IoT Greengrass logs](monitor-logs.md).
+ `deployment-failure-cause`: uma mensagem de erro que fornece detalhes adicionais sobre o motivo da falha na execução do trabalho.
A resposta é semelhante ao exemplo a seguir.
```
{
"execution": {
"jobId": "2cc2698a-5175-48bb-adf2-1dd345606ebd",
"status": "FAILED",
"statusDetails": {
"detailsMap": {
"deployment-failure-cause": "No local or cloud component version satisfies the requirements. Check whether the version constraints conflict and that the component exists in your Conta da AWS with a version that matches the version constraints. If the version constraints conflict, revise deployments to resolve the conflict. Component com.example.HelloWorld version constraints: LOCAL_DEPLOYMENT requires =1.0.0, thinggroup/MyGreengrassCoreGroup requires =1.0.1.",
"detailed-deployment-status": "FAILED_NO_STATE_CHANGE"
}
},
"thingArn": "arn:aws:iot:us-west-2:123456789012:thing/MyGreengrassCore",
"queuedAt": "2022-02-15T14:45:53.098000-08:00",
"startedAt": "2022-02-15T14:46:05.670000-08:00",
"lastUpdatedAt": "2022-02-15T14:46:20.892000-08:00",
"executionNumber": 1,
"versionNumber": 3
}
}
```