Histórico da Página
A arquitetura do das soluções Smart ERP é disponibilizada no conceito de deploy em contêineres , orquestrada e orquestrados via Kubernetes. O Kubernetes permite orquestrar contêineres em múltiplos hosts, em clouds públicas, privadas ou híbridas, além disto permite otimizar o uso do hardware, maximizando a disponibilidade de recursos para execução dos aplicativos e uma maior agilidade para escalar aplicativos em contêineres e recursos relacionados.draw.io Diagram
...
| id | 01 |
|---|
...
| id | 1 |
|---|---|
| label | Componentes dentro da arquitetura |
...
Cada cliente possui um código único TOTVS (TCODE), cujo nele conseguimos saber quais serviços/licenças foram adquiridas por ele. Quando um cliente contrata o TOTVS Intera, temos a opção interna de criar uma topologia no modelo TRADICIONAL (Por VM) ou no modelo SMART (Contêiner). Caso a TOTVS opte em lançar o cliente no modelo em contêiner, o time de SRE realiza o provisionamento de dois Namespaces ao cliente (Prod e DEV). Com isto, temos a seguinte estrutura no momento do lançamento:
| draw.io Diagram | |||
|---|---|---|---|
|
...
|
...
|
...
- License Server
- DbAccess
- LockServer
- AppServer
- Execução do ERP
- Execução do Configurador
- Execução do Portal
- Execução do REST
- Execução do WebService
- FileSystem (protheus_data)
- Banco de dados
- Serviço de customização
Cada componente listado acima, reflete em uma imagem (docker) que fica armazenada dentro do gcr.io da conta da engenharia (https://gcr.io/eng-protheus).
...
| id | imagens |
|---|---|
| label | Imagens |
Utilizamos os componentes que ficam armazenados no endereço: https://arte.engpro.totvs.com.br/engenharia/bundles/SmartERP/base/imagem/componentes/.
Neste endereço temos todos os componentes abertos para que o time de engenharia do Smart ERP realize a atualização dos componentes sempre que houver a solicitação pelos times de TEC, FRAME e Produto.
Dentro das pastas temos uma subdivisão entre os tipos de ambientes (produção, sistêmico e tecnologia).
Para cada um deles, temos a separação dos componentes para que um não interfira nos testes de outros ambientes. Ex. Estamos atuando em uma feature no ambiente de TEC com binários pré-release e no ambiente do Sistêmico estamos utilizando o binário oficial para a homologação.
Em cada folder, existe um arquivo chamado VERSION. Neste arquivo informamos a versão do componente a ser gerado.
IMPORTANTE: Para a geração do RPO que utilizamos nos ambientes do SMART (Produção), copiamos o artefato na pasta https://arte.engpro.totvs.com.br/engenharia/bundles/smarterp/base/topologia/rpo_smarterp/ e para o sistemico utilizamos a pasta https://arte.engpro.totvs.com.br/engenharia/bundles/smarterp/base/topologia/rpo_sistemico/
A montagem base do RPO do sistêmico é o D-1 da versão 12.1.2210 e compilado os artefatos utilizados pelo SMARTERP.
Após termos os componentes atualizados, compactamos os componentes no formato tar.gz e disponibilizamos no bucket no Arte. Para saber os nomes corretos dos artefatos, recomendo entrar no folder https://arte.engpro.totvs.com.br/engenharia/bundles/smarterp/espelho/ do componente a ser atualizado, copiar o nome exato de lá. Lembrando que o subfolder do componente é a versão que utilizamos para o componente. É uma forma simples de versionamento de componentes.
Conforme mencionado acima, o versionamento dos componentes são realizados através de folders dentro do folder no Arte, após copiado o artefato para um novo FOLDER, coletamos o nome do FOLDER e "linkamos" este componente com a versão da imagem a ser gerada.
As imagens estão dispostas em repositórios dentro do GITEA (https://code.engpro.totvs.com.br/smarterp/), separados por componentes/imagens a serem utilizados. Cada repositório possui um artefato chamado component-versions.mk e dentro dele informamos/linkamos o componente que disponibilizamos no Arte. Com a atualização do arquivo, geramos uma BRANCH de versão com a finalidade de gerarmos a versão de uma nova imagem.
O processo é realizado de forma automática, com a finalização do PUSH da branch, através Jenkins (https://james.engpro.totvs.com.br/view/all/job/smarterp/). (Sugiro que realizem o acompanhamento da build no jenkins até a finalização).
Importante: Utilizamos o processo de GITFLOW para todos os repositórios do SmartERP, ou seja, devemos sempre utilizar a branch develop para iniciar o processo de inovação/fix e gerar uma nova branch com os commits gerados. Ao término do processo de construção e homologação dos componentes do repositório, abrimos uma PR para a branch develop e após aprovação de pelo menos um dos responsáveis pelo repositório é que deverá ser realizado o merge com a develop. Com a conclusão e homologação em develop, deverá ser aberto um PR para mergear com a MASTER. Este processo é para garantirmos que não iremos subir coisas não testadas na imagem e também para aglutinarmos várias correções antes de subirmos para a master. A pessoa que abriu o PR é que deverá realizar o MERGE.
|
Cabe salientar que os clientes Smart eSocial fazem a contratação do serviço diretamente via ERP, com isto, o provisionamento dentro do Cluster é realizado de forma automática. Hoje, devido a regras comerciais, a contratação do produto está desligada nos ERPs, porem mantemos o serviço ativo caso haja a necessidade.
Banco de Dados
Este processo é executado todo via código (bash) e o provisionamento do banco irá depender do provedor onde será alocado o cliente.
Atualmente temos homologados dois bancos de dados: o PostgreSQL e o Oracle. O PostgreSQL está homologado tanto para máquina física, VM ou contêiner e Oracle somente para uso em máquina física e VM. Devido a flexibilidade e custos, optamos em utilizar o PostgreSQL como DB dos ambientes Smart (Gerenciado em Produção e Contêiner em Dev).
| Aviso |
|---|
Para ambientes do eSocial, optamos em manter os bancos em ORACLE (Inclusive em DEV) devido a complexidade de migração dos mesmos para PostgreSQL. |
File Server
Utilizamos um serviço de armazenamento estendido para as aplicações Protheus. Este se faz necessário pois alguns artefatos do produto ainda exigem DISCO para funcionar. Este serviço é um serviço genérico de armazenamento e temos homologados os provedores AWS, GCP e TOTVS para uso.
| Aviso |
|---|
Para ambientes do eSocial, não precisamos deste serviço, devido a característica da solução. |
Custom Services
Disponível somente para ambiente ERP, o serviço de customização realiza o armazenamento e compilação dos fontes customizados do cliente. Para tal, disponibilizamos aos clientes um GIT (AWS) para que os clientes possam guardar seus códigos customizados nele e para que possamos realizar a verificação do código e a compilação dos fontes.
O fluxo de trabalho segue o seguinte modelo:
Ao término do processo de gravação dos fontes no GIT do cliente, executamos algumas LAMBDAS para execução do SONARCUBE e COMPILAÇÃO de fontes. Concluído esta etapa, guardamos o RPO Custom em um BUCKET para posterior atualização no ambiente.
Namespaces - Componentes
Cada namespace do cliente possui Serviços Público, Serviços Base, Serviços Gerenciados e o Proxy de conexão.
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Serviços Públicos
Os serviços públicos são aqueles cujo o cliente utiliza para acessar a aplicação. Estes serviços executam o Application Server PROTHEUS em Linux e foram Dockerizados (Atualmente usamos como base o OracleLinux 8.6 com EPEL instalado e outros utilitários para troubleshoot.) para distribuição dentro dos NS. Além disto, todos os serviços executam a mesma imagem ou docker, mudando somente os parâmetros e configuração de appserver.ini dentro deles.
Todos estes serviços estão ligados a um SERVICES do Kubernetes e possuem um INGRESS (DNS) para acesso via Internet.
Por se tratarem de Applications Servers, precisamos cumprir algumas regras para uso desta aplicação e para isto, seguimos o modelo de instalação dos componentes, bibliotecas, repositórios de fontes (RPO) e serviços de impressão que a TOTVS TEC e Framework homologaram.
Serviços Base
Os serviços base são aqueles que são essenciais para execução do ERP. Dentre eles temos o LicenseServer, o LockServer e o DbAccess. Todos estes componentes, são disponibilizados pela TOTVS TEC e foram homologados para execução em OracleLinux. O ambiente estará disponível ao cliente, somente se os componentes base estiverem no ar.
| Informações |
|---|
O LicenseServer necessita que o cliente possua um contrato válido na TOTVS e que tenha licenças distribuídas e replicadas entre os ambientes. Caso contrário, não é possível subir o ambiente devido as regras de predecessão dos componentes. |
A instalação e uso destes componentes, também segue o modelo de instalação dos componentes, bibliotecas, repositórios de fontes (RPO) e serviços de impressão que a TOTVS TEC e Framework homologaram.
Serviços Gerenciados.
São os serviços que não são geridos pelo time de SRE Protheus. Estes são geridos exclusivamente pela Nuvem onde está alocado o Ambiente.
Proxy de Conexão (Hypnus)
O Hypnus é um proxy "scale to zero" para aplicativos de locatário único em execução no Kubernetes. Ele também oferece uma lógica de aquecimento que ativa os componentes do aplicativo com base no histórico de uso.
Sua arquitetura trabalha diretamente com as APIs do Kubernetes e é manutenido pelo time TKS e SRE Protheus.
Modelo de trabalho:
...
| id | charts |
|---|---|
| label | Charts |
Para realizarmos o processo de atualização e/ou disponibilização de componentes em nosso cluster, utilizamos um “orquestrador” chamado HELM. O Helm (https://helm.sh/) faz o empacotamento dos templates a serem utilizados no cluster e usa um formato de empacotamento chamado CHART . Um único chart pode ser usado para implantar algo simples, como um pod, ou algo complexo, como uma pilha completa de aplicativos como o PROTHEUS e assim por diante.
Os templates irão definir quais os componentes queremos instalar no Kubernetes e como eles devem ser configurados. É com base neles que o Helm identifica o que deve ser criado, atualizado ou excluído.
Para a montagem dos templates, utilizamos o repositório https://github.com/cloud104/smarterp
que terá as versões de componentes e imagens a serem utilizadas dentro do cluster. Este repositório está restrito ao time de Arquitetura do Cloud e ao SRE.
Para informarmos os componentes dentro do chart, devemos realizar a alteração de dois arquivos:
https://github.com/cloud104/smarterp/blob/master/charts/smarterp/values.yaml e https://github.com/cloud104/smarterp/blob/master/VERSION
O primeiro arquivo é onde informamos as imagens geradas no Protheus:
E o segundo é onde informamos a versão do chart.
...
Visão Geral
Import HTML Content
Conteúdo das Ferramentas
Tarefas