Muitos processos relacionados ao registro de novos clientes, serviços ou fornecedores exigem a criação de infraestrutura. Essa infraestrutura costuma ser padrão, mas deve ser parametrizada de acordo com as linhas de negócios ou áreas de serviço que precisam delas.
Normalmente, estes pedidos são canalizados para a área de Infraestrutura, Plataformas ou Segurança, gerando atrasos para o cliente ou empresa e ainda sobrecarga operacional para os departamentos que os implementam. Foi o que evitamos tanto quanto possível na Pomelo – por isso decidimos nos antecipar para diminuir o tempo de registro de novos clientes.
Neste artigo, compartilhamos uma experiência sobre o Rundeck e o Catálogo de Serviços da AWS que teve como objetivo oferecer mais autonomia para quem precisa alcançar a infraestrutura necessária.
Além de explicar o que e como fizemos, com todos os detalhes, você encontrará os resultados que obtivemos no final do post do blog. Já antecipamos que eles são incríveis! 😎
Aproveite!
O que nos propusemos a fazer?
Nós buscamos formas de orquestrar esses procedimentos para que a infraestrutura necessária para prestar um serviço possa ser criada por quem precisa dela. No menor tempo possível, com a maior independência possível e sem exigir conhecimentos específicos sobre a infraestrutura criada. Tudo de forma segura, simples e padronizada, como tem que ser 🙌
Nosso procedimento teve que acelerar os tempos de criação, minimizar a intervenção do departamento de Infraestrutura, cumprir rigorosos padrões de segurança, minimizar possíveis riscos ou erros e ser ao mesmo tempo amigável e fácil de usar.
Da mesma forma, o tempo de desenvolvimento da solução completa teve de acompanhar a velocidade do negócio. Por isso optamos por utilizar um stack de soluções existentes, o que nos permitiria fornecer as funcionalidades necessárias em um tempo muito curto, sem ter que esperar pelos tempos necessários para o desenvolvimento de uma solução completa do zero.
Para isso, buscamos criar um stack de soluções, que, em sua combinação, cria a solução final desejada:
- Rundeck para orquestrar tarefas e determinar permissões do usuário;
- AWS IAM para gerenciamento de permissões de acesso;
- AWS Boto3 para gerenciar as várias funções;
- e Catálogo de Serviços AWS para a implementação de padrões de infraestrutura.
E o que são essas ferramentas?
Rundeck é uma ferramenta de automação de tarefas, que permite orquestrar séries de tarefas complexas e apresentá-las para uma execução simples, segura e de autoatendimento – com um manuseio muito intuitivo em sua interface de usuário.
Por outro lado, o Catálogo de Serviços é uma ferramenta AWS que permite agrupar a criação de recursos de infraestrutura em procedimentos-padrão, agrupando todos os processos necessários para a criação de todos os elementos de infraestrutura para um determinado serviço. Ambas as ferramentas usadas dentro do stack permitem dar a essa solução velocidade, estabilidade e escalabilidade.
Como fizemos isso?
Implementando o seguinte stack, que tem 3 níveis:
- O 1º nível corresponde ao Catálogo de Serviços para a criação direta de infraestrutura;
- O 2º nível corresponde a um conjunto de scripts em Python, que implementa a comunicação entre o nível do usuário e a AWS;
- E, finalmente, o terceiro nível, que consiste no conjunto de projetos e jobs da Rundeck, que servem para ser invocados pelos usuários finais ou via API.
Agora, vamos para cada um dos níveis.
Nível 1: Catálogo de Serviços
A camada de Catálogo de Serviços oferece produtos padronizados para criação de infraestrutura, garantindo que todos os recursos sejam criados com os critérios definidos, com os mesmos atributos e padrões. Ela também permite que esses recursos sejam auditados no Catálogo de Serviços e os stacks criados possam ser gerenciados. Tem a vantagem de que esses produtos podem ser genéricos e usados para todas as áreas do negócio. Isso minimiza a criação de produtos nos portfólios do Catálogo de Serviços e o trabalho de manutenção desse código.
O fato de os produtos do Catálogo de Serviços serem genéricos para cada família de recursos cria a necessidade de que eles sejam paramétricos e executados com uma camada de abstração superior. O conhecimento de infraestrutura é normalmente necessário para validar os dados necessários para parâmetros e acessar permissões a diferentes recursos AWS para obtê-los. No entanto, mesmo esses dados podem ser localizados seguindo padrões, de modo que essa camada de abstração é automatizada usando scripts em Python, que podem acessar as informações necessárias via Boto3.
Nesse cenário, as carteiras do Catálogo de Serviços não precisam ser acessadas diretamente pelos usuários que precisam criar a infraestrutura.
Nível 2: Camada de script baseada em Python e Boto3
Nesta camada, cria-se um conjunto de scripts que, usando Python e Boto3, são capazes de obter os dados necessários para gerar os parâmetros de execução dos produtos do Catálogo de Serviços. Essa camada de script pode consultar a API da AWS para dados, localizar produtos criados, concatenar execuções de vários produtos do Catálogo de Serviços ou verificar os resultados de uma execução sem exigir que um usuário relacione essas ações.
Esses scripts oferecem a flexibilidade necessária para comunicar as várias solicitações dos usuários com o conjunto disponível de produtos de infraestrutura. Da mesma forma, os scripts também podem servir como módulos para a criação de diferentes serviços de infraestrutura para vários projetos do Rundeck.
Além disso, dada a necessidade de modificar a infraestrutura criada, os scripts de Python fornecem funcionalidades de gerenciamento dos produtos do Catálogo de Serviços já criados, permitindo que o usuário modifique e gerencie os produtos já implantados.
A execução de produtos do Catálogo de Serviços de forma automatizada oferece uma camada extra de padronização, uma vez que os mesmos scripts são responsáveis pela criação dos nomes dos recursos, evitando erros humanos ou diferenças de critérios. Da mesma forma, os erros são minimizados ao obter todos os parâmetros possíveis com scripts, consultando a API da AWS e evitando que os usuários tenham de coletar informações por conta própria.
O acesso disponível aos diferentes serviços AWS é gerenciado através do IAM, controlando as permissões concedidas às funções assumidas pela instância do Rundeck nos diferentes ambientes.
Nível 3: Rundeck
Os jobs do Rundeck fornecem a camada mais alta de abstração, gerando a interface disponível para o usuário. O máximo de jobs necessários pode ser criado para fornecer acesso simples a cada unidade de negócio para cada produto, inserindo nas variáveis do job aquelas que forem necessárias para parametrizar scripts do Python. Essas variáveis podem ser transparentes para o usuário, que só é solicitado a inserir os campos mínimos necessários para a criação de infraestrutura – uma vez que o Rundeck suporta a possibilidade de definir parâmetros de execução obrigatórios ou ocultos do usuário.
É no nível dos jobs do Rundeck que se cria a principal camada de segurança, segmentando os usuários em projetos e jobs de acordo com as funcionalidades que eles querem habilitar. O acesso a esses projetos e jobs é definido no nível das ACLs do Rundeck para vários grupos de usuários – que, dependendo dos mecanismos de autenticação do Rundeck, podem atuar de várias formas. No caso da Pomelo, a autenticação é feita usando o módulo JAAS do LDAP, que se conecta ao serviço LDAP do Google.
Caso de uso: Transferência de arquivos de terceiros com base na AWS Transfer Family e no AWS Batch
Para as áreas de Integrações com Terceiros, a implantação de serviços de transferência de dados é fundamental para o negócio – criando a necessidade de ter mecanismos que forneçam rapidamente a infraestrutura necessária nos tempos exigidos pelo negócio. No entanto, essa criação de infraestrutura exige tempo e recursos para as áreas de Plataforma e Infraestrutura, que devem combinar os tempos do negócio com a criação de recursos de forma repetitiva.
O stack de Rundeck + Catálogo de Serviços assume este formulário para a implementação da solução. Os requisitos de negócios envolvem a criação e o gerenciamento de produtos de transferência de arquivos e processamentos em lotes (batches) que fornecem os dados a serem transferidos.
Para isso são implementados os produtos de catálogo de serviços gerados pelo usuário do SFTP são implementados no SFTP Transfer Server produtivo, além de um produto de Catálogo de Serviços que gera os jobs definitions necessários para gerar os processos de criação de dados para cada cliente, no batch produtivo que atende as diferentes linhas de negócio. Um produto que gere o cron também é necessário para executar os relatórios no batch, que é implementado usando um cron na AWS EventBridge.
Buscando minimizar a complexidade para o usuário, tentamos fazer com que apenas os jobs exijam aqueles parâmetros que não podem ser adquiridos via solicitação do Boto3 à API da AWS, detectando que só é necessário parametrizar os seguintes dados:
- Nome do cliente;
- Identificador da Pomelo;
- Tempo dos relatórios a serem executados;
- Unidade de negócios que implementa transferência de dados;
- A chave pública de SSH do cliente.
Com esses dados e uma interface limitada dos jobs, os usuários são capazes de gerenciar toda a infraestrutura complexa gerada pelas camadas subjacentes.
Visualização do usuário para criar um Job definition para criar um relatório.
Neste caso, os scripts de Python, além de iniciar a criação dos produtos do catálogo de serviços envolvidos, também fornecem uma interface de usuário para gerenciar a infraestrutura criada:
- Permitem listar, adicionar e excluir chaves públicas SFTP em usuários criados;
- Permitem listar e executar os jobs criados.
Essas funcionalidades são obtidas combinando ações diretas no AWS via Boto3 com atualizações para os produtos do Catálogo de Serviços que foram criados a partir deste stack.
O que ganhamos implementando esse stack?
Agora que detalhamos tudo o que fizemos, é hora de dizer o que obtivemos com a experiência. Direto ao ponto: ganhamos velocidade, segurança e confiabilidade para o negócio, para o usuário e para equipes de infraestrutura. Abaixo trazemos mais detalhes:
- Redução de 85% no tempo para criação de recursos
- Tempo gasto por infraestrutura para criar um batch direto a partir do Catálogo de Serviços: 1,5hs;
- Tempo gasto do Rundeck por um usuário final: 10 minutos;
- Manutenção de padrões de nomeação, com recursos nomeados por scripts de criação;
- Redução de erros humanos, uma vez que os parâmetros de entrada são reduzidos a um conjunto básico;
- Controle e monitoramento das execuções e modificações feitas em Rundeck;
- Independência do departamento de integração com terceiros, que podem responder imediatamente à necessidade do cliente.
Esperamos que você tenha gostado e que tenha sido útil para o seu produto ou negócio! Nós sempre testamos e criamos tecnologia na velocidade da Pomelo – e, claro, você vai poder ler tudo sobre o que realizamos e o que fazemos aqui no Pomelo Words! 😄