• Nenhum resultado encontrado

Conteinerização e gerenciamento de aplicações industriais de uma arquitetura orientada a microsserviços para a Indústria 4.0

N/A
N/A
Protected

Academic year: 2023

Share "Conteinerização e gerenciamento de aplicações industriais de uma arquitetura orientada a microsserviços para a Indústria 4.0"

Copied!
55
0
0

Texto

Tendo em vista o crescimento do segmento da Indústria 4.0, voltado principalmente para a automatização de processos industriais, surge a necessidade de desenvolver e aprimorar a Internet das Coisas Industrial (IIoT). Com a chegada da Indústria 4.0, máquinas inteligentes estão sendo utilizadas para tornar os processos mais produtivos, eficientes e seguros. Uma das principais tecnologias da Indústria 4.0 é a Internet das Coisas Industrial, que permite a interconexão digital de vários dispositivos.

Essa transformação é conhecida como Indústria 4.0, que tem como objetivo descrever a implementação de ferramentas inteligentes que possam se comunicar entre si para proporcionar maior automatização na cadeia produtiva. De forma geral, Bertolucci (2016) defende que o fundamento básico da Indústria 4.0 está na adoção da integração de máquinas, sistemas e ativos, o que permite a criação de redes inteligentes ao longo da cadeia de valor, que por sua vez possibilitarão o controle autônomo de módulos. Produção. Em sua dissertação, Chilanti (2022) aponta que a Indústria 4.0 possui cinco características mais marcantes: digitalização; adaptabilidade; conectividade; adaptabilidade e inteligência.

O autor acredita que a introdução da Indústria 4.0 nas empresas deve ocorrer de forma gradual e contínua, pois tais mudanças são em sua maioria de longo prazo, possuem alto valor e risco.

Microsserviços e arquiteturas

2020) entende que as arquiteturas de microsserviços diferem das demais porque afetam diretamente o desempenho e o desenvolvimento do perfil da equipe responsável pela construção e implementação dos sistemas. Outra vantagem é que o ponto de falha não é unificado, o que significa que quando alguns serviços falharem, o restante do aplicativo não sofrerá danos, apenas o produto afetado ficará indisponível. Juntos, Oliveira et al. 2017) aponta que a principal motivação para utilização de microsserviços é o isolamento de falhas por meio da integração do funcionamento da aplicação, mesmo com as falhas de serviços isolados, mesmo comparando com estruturas que utilizam uma arquitetura monolítica em que o sistema compartilha totalmente os recursos, resultando em um ciclo de vida dependente, que responde globalmente à falha, fazendo com que toda a aplicação falhe.

O conceito de arquitetura monolítica é entendido por Domingos et al. 2020) reunindo todos os componentes do servidor em apenas uma unidade. Uma desvantagem da arquitetura monolítica, segundo o autor, é que ela possui um único ponto de falha, ou seja, se uma funcionalidade apresentar algum tipo de problema, toda a aplicação será afetada, deixando o sistema inacessível e não permitindo o acesso a qualquer funcionalidade.

Docker

Outra maneira de interagir com o Docker é por meio do Docker Compose, uma ferramenta projetada para ajudar a definir e compartilhar sistemas com vários contêineres. A maior vantagem do Docker Compose é que ele define todos os contêineres usados ​​pelo sistema em um arquivo de configuração e disponibiliza toda a arquitetura do aplicativo instantaneamente por meio de um comando. 2017) diz que a criação de uma imagem Docker é feita através de Dockerfiles que são disponibilizados para a comunidade. Todas as imagens do Docker de repositórios públicos podem ser extraídas do hub do Docker para qualquer máquina local.

É uma arquitetura cliente-servidor onde o cliente se comunica com o Docker Daemon que gerencia e distribui os containers. Os autores argumentam que a orquestração de virtualização do Docker é necessária para permitir a implantação de sistemas distribuídos.

Portainer

Ele permite que o Portainer Server se comunique com a API do Docker e execute tarefas como criar e remover contêineres, serviços e volumes. Ele permite que o Portainer gerencie o host e execute tarefas como iniciar e parar contêineres, criar e excluir serviços e gerenciar volumes. O Portainer Edge Agent é um agente que permite ao Portainer gerenciar contêineres em hosts remotos e dispositivos IoT.

Ele se conecta ao Portainer Server e fornece uma maneira de gerenciar contêineres em hosts remotos e dispositivos IoT. O servidor Portainer se conecta diretamente ao Docker Engine, permitindo que você gerencie contêineres, imagens, redes e volumes no host. Já o segundo inconveniente é a necessidade de configurações: com esse tipo de conexão, é necessário configurar no servidor Portainer quais portas devem ser acessadas e abrir essas portas nos hosts.

A arquitetura que utiliza o agente é composta por dois elementos: Portainer Server e Portainer Agent, onde ambos rodam em containers. Um agente Portainer deve ser instalado em cada nó do cluster e cada agente deve se reportar a um contêiner Portainer Server onde pode aceitar conexões de vários agentes Portainer, o que requer persistência de dados. O Portainer Edge Agent é utilizado em configurações em ambientes remotos totalmente separados da rede onde o Portainer Server está hospedado.

Neste caso, é necessário alocar portas apenas na máquina do servidor Portainer, pois neste método o servidor Portainer receberá as conexões, portanto há um número menor de portas abertas e todas as medidas de segurança podem ser implementadas no mesmo local. . Devido à maior segurança oferecida e melhor configuração para ambientes remotos, o modelo escolhido para este trabalho foi o Portainer Edge Agent. O diagrama na Figura 1 descreve como conectar um ambiente Raspberry Pi ao servidor Portainer usando o Portainer Edge Agent.

Figura 1 - Diagrama de conexão entre Portainer Edge Agent e Portainer Server
Figura 1 - Diagrama de conexão entre Portainer Edge Agent e Portainer Server

MoleculerJS

Trabalhos relacionados

Proposta do trabalho

Visão geral

A Figura 3 mostra uma visão geral da proposta: A Figura 3 (a) descreve como funciona a comunicação entre o Raspberry Pis e o Potainer Server, e o diagrama da Figura 3 (b) mostra o ciclo de vida das imagens Docker dos serviços, desde criação até a disponibilização em um repositório remoto. Para facilitar o gerenciamento da planta, os serviços foram colocados em um container e foi implementada a Interface Gráfica de Usuário (GUI) Portainer, Figura 3 (a) para gerenciar esses containers e Figura 3 (b) para exibir as imagens da disponibilizando serviços que já foram utilizados nos containers. Foi necessário implementar um processo de criação e disponibilização de Docker Images e configuração da comunicação dos containers com a GUI, que será detalhado em seções posteriores.

Junto a isso, a arquitetura proposta é uma rede de containers orquestrada por um gerenciador de containers e um repositório remoto de serviços que torna a implantação e remoção de serviços performática e amigável.

Figura 3 - Configuração geral de comunicação entre placas Raspberry e processo de deploy  de um container
Figura 3 - Configuração geral de comunicação entre placas Raspberry e processo de deploy de um container

Conteinerização de serviços

A última etapa foi informar ao Docker o comando (L7) a ser usado ao executar a imagem do Docker descrita. O Dockerfile mostrado na Figura 4 foi criado para ser genérico o suficiente para ser usado na maioria dos aplicativos de fábrica. A Figura 5 enumera o ciclo de vida de um serviço, desde o repositório de código (GitHub) até a implantação do contêiner.

O arquivo Docker foi obtido do Github (1) e, em seguida, as imagens do Docker foram construídas via CLI usando o comando docker build -t gasiepgodoy/moleculer:api (2), o parâmetro -t nomeia a imagem com um identificador. A imagem é então carregada por meio do comando docker push gasiepgodoy/moleculer:api (3) para o repositório remoto; para exibir a imagem correta era necessário fornecer o código de identificação informado na etapa anterior. Qualquer máquina que tenha o Docker e tenha essa imagem do Docker poderá executá-la com o comando docker run (5).

Nesta parte, foram criadas imagens Docker para todos os serviços escritos em NodeJS, disponibilizando uma biblioteca de imagens onde qualquer Raspberry autorizado pode baixar e habilitar o serviço em um instante.

Figura 5 - Processo de deploy de um container.
Figura 5 - Processo de deploy de um container.

Gerenciamento de serviços

No modelo de configuração do Edge Agent, o Portainer Server se conecta a containers hospedados em outras máquinas. Para fazer esta conexão, é necessário configurar uma instância do Edge Agent em cada máquina que se deseja operar através da interface gráfica do Portainer. A Figura 7 mostra um diagrama de comunicação entre o Portainer Server e o Edge Agent, onde o Edge Agent se conecta ao Portainer Server através da porta 8000.

Uma vez estabelecida a conexão entre o Portainer Server e o Edge Agent, os dados podem ser solicitados e as ações comandadas por meio da GUI Portainer, que permite o monitoramento, implantação e remoção de serviços em todas as placas Raspberry conectadas pela mesma interface. Para preservar o histórico de configuração e aproveitar melhor as funcionalidades oferecidas pelo Docker, foi introduzido o Edge Agent por meio do Docker Compose. O Apêndice III mostra a configuração selecionada, vale comentar as configurações EDGE_ID e EDGE_KEY e como obtê-las, esses atributos funcionam como credenciais para verificar a conexão do Edge Agent com o servidor Portainer.

Essas credenciais são geradas ao criar um ambiente, ou seja, todo dispositivo conectado por meio de um Edge Agent possui um ambiente. A Figura 22 ilustra os ambientes utilizados pelos Raspberry Pi's de fábrica, eles foram criados através da aba Environment da GUI do Portainer. Também foi necessário comunicar o endereço IP da máquina host do Portainer Server para estabelecer um relacionamento com a conexão especificada anteriormente.

Uma vez criado o ambiente, é necessário informar os valores para as chaves EDGE_KEY e EDGE_ID, junto com isso, definir uma dica de instruções para instalar um container com o Edge Agent utilizando o Docker, conforme Figura 11. na aba Registros, é esta autorização que pode ser obtida selecionando o botão Adicionar registro mostrado na Figura 12. Com isso, ao estabelecer a comunicação entre o Edge Agent e o Portainer Server, uma ferramenta de gerenciamento remoto de contêineres foi implementada com sucesso, concluindo assim o desenvolvimento do Este trabalho.

Figura 7 - Diagrama de comunicação entre Raspberry e Portainer Server
Figura 7 - Diagrama de comunicação entre Raspberry e Portainer Server

Network e Segurança

Existem serviços que utilizam dispositivos externos, por exemplo o DAQ depende de um circuito interintegrado (I²C). Essa configuração foi realizada pelo atributo devices no arquivo de instruções do Docker Compose mostrado na Figura 14. Nessa arquitetura implantada, o Docker Hub atua como um Marketplace de serviços, permitindo fácil implantação por meio do Portainer Server, que utiliza sua funcionalidade para instanciar containers que carregam imagens diretamente de um repositório remoto.

A Figura 15 mostra o processo de autenticação com o repositório de imagens usando o comando docker login -u username -p password. Observando a primeira linha da Figura 17, uma atribuição de porta foi declarada por meio do parâmetro -p e um arquivo de variáveis ​​de ambiente foi carregado por meio do comando --env-file. A Figura 18 mostra uma requisição HTTP no serviço DAQ através do aplicativo Postman, a figura também mostra a resposta da requisição que retorna as informações solicitadas.

Como exemplo, o comando docker-container prune é executado para remover contêineres inativos e liberar espaço na memória. A Figura 21 mostra esse processo. Como mencionado anteriormente, a implantação de vários contêineres por meio do cliente Docker é trabalhosa e ineficiente, portanto, optou-se por usar o arquivo de instruções do Docker Compose anexado no Apêndice IV para implantar os 5 serviços de controle. A Figura 28 mostra uma solicitação no contêiner recém-implantado pelo Portainer, essa solicitação foi feita no serviço DAQ solicitando uma ação riin.

As baterias de teste consistiram em acionar o serviço DAQ através do serviço API para medir o tempo de resposta da usina. É freqüentemente usado para descrever a posição relativa de um indivíduo ou grupo de indivíduos dentro de uma população maior. Em seguida, você determina o percentil para um valor específico comparando-o com os outros valores no conjunto de dados.

Quando comparamos os resultados apresentados nas Tabelas 1 e 2, nota-se que o tempo de resposta ao rodar o serviço através do NodeJS é um pouco menor e, portanto, mais performático. O principal objetivo foi alcançado com o gerenciamento remoto de contêineres através do Portainer, possibilitando implantar ou desligar serviços, monitorar a integridade dos contêineres e o consumo de hardware, tudo agrupado em uma mesma interface de usuário.

Figura 14 - Arquivo de instrução Docker Compose concedendo acesso a dispositivos externos
Figura 14 - Arquivo de instrução Docker Compose concedendo acesso a dispositivos externos

Docker Compose para implementação do Portainer Server

Configuração para container do Portainer Edge Agent

Docker Compose para implantação de múltiplos serviços simultaneamente

Arquivo .env contendo as variáveis de ambiente do serviço control

Imagem

Figura 1 - Diagrama de conexão entre Portainer Edge Agent e Portainer Server
Figura 2 - Planta-piloto utilizada neste estudo
Figura 3 - Configuração geral de comunicação entre placas Raspberry e processo de deploy  de um container
Figura 5 - Processo de deploy de um container.
+7

Referências

Documentos relacionados

1 Botomé (1996) considera o ensino, a pesquisa e a extensão como atividades-meio da universidade, pois é por meio destas que a universidade persegue e realiza suas