Sistema de impressão centralizado em Kubernetes

O desafio aqui foi criar um ambiente estável que substituísse mais de 1000 servidores de impressão CUPS espalhados pelo Brasil.

A antiga arquitetura desse ambiente, continha em cada filial da empresa, em seus servidores, um CUPS e uma aplicação chamada DocPath e diversos templates de impressão que eram distribuídos para todos esses servidores remotamente.

Este era o ambiente que realmente convertia o documento proveniente do Main Frame e realizava a impressão física, de notas, contratos e outros diversos, em papel.

O DocPath é um sistema de templates, que recebe variáveis e monta um documento de impressão para ser processado e impresso. Este conteúdo é provido através de aplicações oriundas do MainFrame. Após esse merge entre templates e dados variáveis o DocPath monta o documento e entrega para o CUPS, que se encarrega de imprimir.

A gestão deste ambiente, era altamente custosa, financeiramente e de manutenção, um grande time era responsável pela saúde deste ambiente.

Para resolver esse grande desafio, depois de algumas tentativas frustradas, com VMs e Balanceadores (F5 BigIP), balanceadores de nome, servidores em cluster com HA, um enorme aglomerado de “fios e hardware pesado”, decidimos ir para a nuvem e testar o comportamento de um ambiente que recebe uma alta demanda de arquivos, por vezes, de grande tamanho.

Escolhemos para essa solução, a nuvem da Microsoft, o Azure e AKS (Azure Kubernetes Service).

Após longos testes, praticamente em produção (Onde teríamos centenas de impressoras para testar???). Conseguimos “deployar” um ambiente estável, escalável e incrivelmente rápido, mesmo com diversos hops de roteamento.

Esta solução não existia em container, na versão que utilizávamos, depois de diversos testes, empacotei e criei uma versão customizada, coloquei somente o essencial, a aplicação do DocPath, Cups, diversas customizações do SO e dezenas de scripts, pronto! Tenho um pequeno container que faz o papel de vários servidores.

Depois de diversos testes de carga, consegui chegar em um número estável de PODs que operam as impressões, 21. Com este número, em cima de um Replicaset e HPA. O ambiente só escala mais PODs com demandas em datas especiais das lojas, o excedente do normal.

Sendo assim, retiramos mais de 1000 servidores físicos IBM, caros, queimadores de energia, pesados, que ocupavam espaço, que demandavam um mínimo de infraestrutura nas lojas (refrigeração, energia estabilizada, nobreaks, manutenção presencial), para simplesmente 21 PODs que suprem a necessidade de mais de (chutando baixo) 200 mil impressões por dia.

Agora um pouco de tecniquês…

Este ambiente é composto por uma divisão lógica que divide as impressoras de uma filial (unidade) em 1/3.

Cada 1/3 de impressoras de loja correspondem a um segmento de Deployment no K8S, separado, contendo em cada, 7 PODs que possuem as aplicações para o processamento das impressões. Esta divisão permite que, mesmo um conjunto de nodes se tornar indisponível, a loja continue operando por outros.

Um HPA (Horizontal POD Autoscaller) é responsável pela elasticidade horizontal do ambiente, caso houver demanda excessiva, mais 3 PODs são escalados no ambiente automaticamente para suprir a demanda.

Um Load Balance Ingress é resposável pelo Round Robin das conexões (Distribuição da carga entre um conjuto de deployment de 7 PODs cada). Esta distribuição garante que não haja sobrecarga nos PODs e funciona tão bem que apenas 21 PODs totais suprem uma demanda gigantesca, de todas as lojas.

Um Cronjob executa scripts que alimentam os PODs automaticamente com novas impressoras, fazem um clean de jobs antigos, executam scripts de monitoria e garantem abertura de novas filiais facilmente.

Um Storage armazena dados necessários para os PODs que são por melhores prática de um ambiente K8S, efêmeros, e são recriados uma vez ao dia para leitura de novos templates de impressão e consequentemente impressoras.