A arquitetura das soluções Smart é disponibilizada no conceito de contêineres 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.
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:
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.
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).
Para ambientes do eSocial, optamos em manter os bancos em ORACLE (Inclusive em DEV) devido a complexidade de migração dos mesmos para PostgreSQL. |
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.
Para ambientes do eSocial, não precisamos deste serviço, devido a característica da solução. |
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.
Cada namespace do cliente possui Serviços Público, Serviços Base, Serviços Gerenciados e o Proxy de conexão.
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.
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.
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.
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.
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:
