Centro de Informática
Trabalho de Graduação
Recife
09 de julho de 2018
ii
Recife
09 de julho de 2018
Universidade Federal de Pernambuco
Centro de Informática
Banca examinadora:
Orientador:
Vinícius Cardoso Garcia
Examinador:
Kiev Santos da Gama
Recife
09 de julho de 2018
Resumo
Diante das recentes popularizações e crescente demanda no mercado acerca de DevOps e Chat-
Bots, uma nova maneira de criar ferramentas nasceu, o ChatOps. Fruto do entusiasmo da
empresa GitHub, que criou o conceito onde ChatBots auxiliam times de desenvolvimento/o-
perações a realizar suas atividades de modo colaborativo, transparente e uniforme através de
conversas naturais. Automatizando builds e trazendo transparência nos processos. Com isso
esse trabalho tem o intuito de estudar e propor uma plataforma ChatOps de monitoramento e
automação de tarefas em servidores em uma maneira serverless. Tendo seu objetivo auxiliar
qualquer membro de uma equipe de desenvolvimento ou operações.
v
Abstract
In the face of recent popularization and growing market demand for DevOps and ChatBots,
a new way to create tools was born, ChatOps. The result of the enthusiasm of the company
GitHub, which created the concept where ChatBots help development/operational teams to
peform their activities, in a collaborative, transparent and uniform way, through natural con-
versations. Automating builds and bringing transparency into processes. This work intends
to study and propose a ChatOps platform for monitoring and automating tasks in servers in a
serverless manner. Its purpose is to assist any member of a development/operational team.
vii
Sumário
1 Introdução 1
1.1 Motivação 1
1.2 Objetivos 2
1.2.1 Gerais 2
1.2.2 Específicos 2
1.3 Estrutura do trabalho 2
2 Contexto 3
2.1 Microservices 3
2.2 DevOps 4
2.2.1 Continuous Integration 4
2.2.2 Continuous Delivery 4
2.3 ChatBots 4
2.3.1 ChatOps 5
2.3.1.1 Origem 5
2.4 Sumário 5
3 Mori’s Lab 7
3.1 Introdução a arquitetura 8
3.1.1 Características 8
3.1.2 Motivação 8
3.1.3 Comunicação 8
3.2 Dashboard - O laboratório parte 1 8
3.2.1 Tecnologias 8
3.2.2 Servidores 9
3.2.2.1 Listagem 9
3.2.2.2 Cadastro 9
3.2.3 Actions 10
3.2.3.1 Listagem 10
3.2.3.2 Cadastro 10
3.2.4 Autenticação de Chats 12
3.2.4.1 Listagem 12
3.2.4.2 Conectar 12
3.3 API - O laboratório parte 2 14
3.3.1 Tecnologias 14
ix
x SUMÁRIO
3.3.1.1 Express 14
3.3.2 Heart Beat 15
3.3.3 Rotas 16
3.3.4 Arquitetura 17
3.3.4.1 Controladores 17
3.3.4.2 Services 18
3.3.4.3 Models 18
3.3.4.4 Data access objects 20
3.3.4.5 Criptografia 20
3.4 Heart 20
3.4.1 Tecnologias 21
3.4.2 Mind Middleware 21
3.4.2.1 Autenticidade 21
3.4.2.2 Rotas 22
3.5 Server Manager 22
3.5.1 Tecnologias 22
3.5.2 Arquitetura 22
3.5.3 Executando ações 22
3.6 Mori (ChatBot) 23
3.6.1 Arquitetura 24
3.6.1.1 Event Handling - Tratameto de Eventos 24
3.6.1.2 Services 24
3.6.2 Eventos 24
3.6.3 Sumário 25
4 Mori em ação 27
4.1 Monitoramento via stream de log 27
4.2 Movendo banco de dados entre servidores 30
4.3 Sumário 32
5 Conclusão 33
5.1 Trabalhos Futuros 33
Lista de Figuras
xi
Lista de Tabelas
xiii
C APÍTULO 1
Introdução
1.1 Motivação
1
2 CAPÍTULO 1 INTRODUÇÃO
capaz de configurar e gerenciar ações a serem executadas por meio de ChatBots em servidores
remotos, sem a obrigação de programar para criação de tais configurações.
1.2 Objetivos
1.2.1 Gerais
Objetivo desse trabalho é implementar uma plataforma ChatOps onde seja possível através de
um Dashboard comunicando-se com uma API REST automatizar um ChatBot para executar
ações em servidores em tempo real que sejam capazes de trazer transparência, resiliência e alta
disponibilidade para seus serviços.
1.2.2 Específicos
• Desenvolvimento de um ChatBot como interface capaz de interpretar ações para execu-
ção de comandos remotos
• Desenvolvimento de uma API REST para orquestração de ações e dados entre os Micro-
services
Contexto
2.1 Microservices
Aplicações monolíticas funcionam bem quando são pequenas e de médio porte. Uma vez que
seus processos de desenvolvimento, teste e implantação são simples e com poucos passos. No
entanto, no momento que se tem grandes aplicações, muitas coisas passam a estar contidas em
apenas um lugar, e dificulta a manutenção, atualização e adoção de novas tecnologias. Por esses
tipos de problemas que os Microservices apareceram. O termo nasceu em 2012 como evolu-
ção do SOA e é definido por James Lewis, consultor principal de tecnologia da Thoughtworks
como "Uma pequena aplicação que pode ser implantada/escalada/testada de modo indepen-
dente e que tenha responsabilidade única (uma única razão para mudar, uma única razão
para ser substituída e única capacidade)". Resumindo, Microservices é uma abordagem para
desenvolver uma única aplicação como uma suíte de serviços1 .
• Benefícios
1 https://martinfowler.com/articles/microservices.html
3
4 CAPÍTULO 2 CONTEXTO
2.2 DevOps
DevOps é uma cultura onde se junta diversas práticas integradas e vem sido usada e inves-
tida por grandes empresas, para agilizarem seus processos e aumentar sua produtividade. Isso
acaba sendo muito atrativo para empresas menores e incentivando a propagação da cultura no
mercado. Ela é um grande aliada da arquitetura Microservices, já que suas práticas ajudam os
Microservices a alcançarem maior potencial[3], automatizando builds, testes[16] e entregas de
diversos serviços simultaneamente.
Essas práticas são baseadas em melhorar a comunicação e interatividade entre desenvolvi-
mento e operações [12], junto da automatização de atividades [18].
É definido pela pesquisadora científica Dusica Marijan do centro de pesquisa norueguês Certus
como "Continuous Integration é uma prática de desenvolvimento de software de integração e
teste de código-fonte para detectar defeitos em estágios iniciais de desenvolvimento", ou seja
é usado junto ao desenvolvimento para garantir que novas funcionalidades sejam entregues
de modo que esteja garantida suas eficácias, já que é prática de Continuous Integration visa
detectar tais falhas e deixa-las transparente para que não seja possível passa-las a frente sem
devidas correções.
2.3 ChatBots
O primeiro ChatBot foi criado em 1966 e foi desenvolvido para simular um psicoterapeuta, e
apesar de ser rudimentar, para sua época foi um grande avanço e abriu novos horizontes para
tal tecnologia. ChatBots são softwares que podem interagir ou "conversar"com um usuário
humano por meio de linguagem natural [9]. Diferentemente de outros tipos de softwares, eles
não necessitam de instalação e estão prontos para uso e interação [17], às vezes dependendo
apenas de simples configurações.
2 https://pt.wikipedia.org/wiki/Build
3 https://en.wikipedia.org/wiki/Software eployment
d
2.4 SUMÁRIO 5
2.3.1 ChatOps
Diferente do primeiro BOT que simulava um terapeuta, de modo mais físico e humano, BOTS
ChatOps servem como softwares assistentes, onde através de conversas naturais conseguem
executar operações técnicas dentro de um projeto, geralmente ligadas a Continuous Integration
e Continuous Delivery, fazendo builds e tests via chat. Definido por Sam Fell [4] "ChatOps é
um modelo de desenvolvimento baseado em colaboração e conversação que enfatiza o fluxo de
trabalho transparente e colaborativo.", tendo como objetivo tornar mais simples o acesso de
times a esses tipos de ferramentas e práticas introduzidas pelo DevOps.
2.3.1.1 Origem
A origem da prática veio do entusiasmo da empresa de software GitHub com a construção
do framework opensource para criação de BOTS chamado Hubot. O que tornou possível à
implementação de Continuous Integration e Continuous Delivery via ChatBots, automatizando
tais fluxos de entrega e integração. Além de disponibilizar uma personalização de comandos e
integrações exclusivamente via scripts4 .
2.4 Sumário
Nesse capítulo foi apresentando as definições dos conceitos básicos necessários para enten-
der a implementação e objetivo do projeto proposto. No próximo capítulo será introduzido a
plataforma, sua definição, arquitetura e detalhes de execução.
4 https://en.wikipedia.org/wiki/Scripting anguage
l
C APÍTULO 3
Mori’s Lab
Moris’s Lab, no português, Laboratório da Mori, possui um titulo lúdico devido a analogia
criada referente á personagem Mori e seu laboratório elaborados originalmente para o projeto.
O laboratório é toda a parte onde as ações e dados são gerenciados (API, Dashboard e Mi-
croservices). A Mori representa o BOT, a interface de comunicação para acessar as ações e
dados.
O projeto foi desenvolvido como uma plataforma ChatOps para automação de ações em ser-
vidores. Essas ações são configuradas no Dashboard através de actions que funcionam como
pipelines de comandos. Essa escolha foi feita levando em consideração que as personalizações
do Hubot feitas via script obrigam o usuário a programar. Assim, trazendo o beneficio de abs-
tração, onde não é obrigatório o uso de programação. Nesse capitulo irei mostrar os diferentes
módulos e serviços que compõem a plataforma, junto com suas respectivas arquiteturas e tec-
nologias envolvidas. A figura 3.1 ilustra a arquitetura de mais alto nível da plataforma. Suas
partes serão detalhadas nas seções seguintes.
7
8 CAPÍTULO 3 MORI’S LAB
3.1.1 Características
Foi adotado uma arquitetura baseada em Microservices, onde a plataforma é composta por 5
componentes destintos ilustrados na figura 3.1, sendo eles:
• ChatBot
• API REST
• Serviço de Autenticação
• Dashboard
3.1.2 Motivação
O projeto tem como objetivo ser uma plataforma com visão de crescimento, e visando isso
foi escolhida uma arquitetura baseada em Microservices. Essa escolha foi feita pela questão
da escalabilidade, pois como será citado na seção de trabalhos futuros, o ChatBot não neces-
sariamente será o único meio de interface de execução de comandos. Além de tornar futuras
refatorações de código mais fáceis, devido a sua independência entre serviços.
3.1.3 Comunicação
A API serve como ponto intermediário para a comunicação de todos os serviços, enquanto
todas as interações com o usuário ocorrem ou pelo Dashboard ou pelo ChatBot, que em sua
parte chamam a API e que então irão usar os serviços necessários para processar e gerar uma
resposta adequada para a requisição.
O Dashboard é a parte do laboratório da Mori que esta visível para o usuário, onde o cadastro
de servidores, ações e credencias é feito, além da autenticação de novos chats, para que possam
se comunicar com o BOT(Mori).
3.2.1 Tecnologias
O Dashboard foi construído fazendo uso do framework open-source Angular1 em sua versão
4.4.4. Angular é uma framework JavaScript abrangente que é frequentemente usado por desen-
volvedores de todo o mundo para criar aplicativos Web, desktop e móveis. Ele foi criado e é
1 https://angular.io/
3.2 DASHBOARD - O LABORATÓRIO PARTE 1 9
mantido pelo Google. Plataformas Web como Google Adwords2 , Google Fiber3 , e Adsense4
usam o Angular como framework de suas interfaces gráficas [15].
3.2.2 Servidores
Na seção de servidores do Dashboard é possível listar, deletar e cadastrar novos servidores. Os
servidores são cadastrados apenas pelo Dashboard por questões de segurança, principalmente
para evitar a digitação de credencias visíveis via chat. Na seção 3.3.5 será descrito o processo
de criptografia utilizado nas senhas e dados dos servidores armazenados.
3.2.2.1 Listagem
Na tela de listagem ilustrada na figura 3.2 é possível ver o status do servidor, seu ip e método
de conexão que é utilizada pelo Server Manager para se comunicar com o servidor, isso será
melhor abordado na seção 3.4.1. Além de disponibilizar a opção de deletar o servidor e de ir
para tela de cadastrar um novo servidor.
3.2.2.2 Cadastro
Na tela de cadastro de servidor como ilustra a figura 3.3 é possível escolher o nome do servidor,
o ip, porta, nome de usuário e senha para que a conexão SSH seja possível de ser realizada pelo
Server Manager.
2 https://adwords.google.com/home/
3 https://fiber.google.com/about/
4 https://www.google.com/adsense/start//?modal ctive = none
a
10 CAPÍTULO 3 MORI’S LAB
3.2.3 Actions
Actions foram criadas como conjuntos de comandos a serem executados pelo Server Manager
em um servidor, elas são configuráveis para que o BOT seja capaz de fazer perguntas e preen-
cher esses comandos com entradas dos usuários, e isso é possível através dos steps cadastrados
na tela de cadastro de uma nova action. Composição de uma action:
• Steps: são unidades de comando dentro de uma action, eles representam um comando
bash e podem conter n inputs para sua construção.
• Inputs: são perguntas que serão interpretadas pelo BOT, que por usa vez retornará as
respostas dos usuários capturadas, que então serão substituídas dentro dos steps para a
construção do comando
3.2.3.1 Listagem
Na seção de listagem de actions é possível visualizar a quantidade de steps que cada action
possui, em que servidor ela foi cadastrada e sua descrição. Além da opção de deletar a action e
de ir para a pagina de criação de uma nova action.
3.2.3.2 Cadastro
Na tela de cadastro de uma action é possível adicionar n steps, que possuem um comando e
podem possuir n inputs, os inputs ao serem adicionados automaticamente terão suas respectivas
variáveis inseridas na caixa de dialogo.
3.2 DASHBOARD - O LABORATÓRIO PARTE 1 11
3.2.4.1 Listagem
A listagem mostra o status desse chat, o provedor (inicialmente disponível apenas para tele-
gram), o nome do usuário, quando foi utilizada pela ultima vez, a opção de deletar o chat e
opção de conectar um novo chat.
3.2.4.2 Conectar
Essa tela possui apenas o QRCode em si, que poderá ser enviado para o BOT, tanto como uma
foto a partir de um dispositivo móvel, como a partir de copiar e colar dentro do telegram web.
3.2 DASHBOARD - O LABORATÓRIO PARTE 1 13
A API é a parte do laboratório que processa todas as requisições dos usuários sem eles neces-
sariamente verem, é ela que executa grande parte das escritas no banco, além de gerenciar as
chamadas de serviços e retornar suas respostas corretamente para o usuário.
3.3.1 Tecnologias
Na criação da API foi adotado a tecnologia Node.js5 junto com o framework Express6 , em
termos simples, Node.js é uma multiplataforma javascript gratuita de código-fonte aberto para
programação server side [19], enquanto o Express é um web app framework minimalista, open
source e flexível, construído para desenvolver websites, web apps e API’s de maneira fácil com
Node.js [19]. Para entendermos melhor a arquitetura do projeto iremos entender a arquitetura
do Express que será descrita na seção 3.3.1.1.
3.3.1.1 Express
A arquitetura do framework é baseada em middlewares, porém na nomeologia do Express,
middlewares possuem um significado diferente7 do tradicional, eles funcionam como manipu-
5 https://nodejs.org/en/
6 https://expressjs.com/
7 https://medium.com/@agoiabeladeyemi/a-simple-explanation-of-express-middleware-c68ea839f498
3.3 API - O LABORATÓRIO PARTE 2 15
ladores de requisições [7]. Cada middleware tem acesso ao objeto da request, objeto de resposta
e um objeto chamado "next", que é a função que chama o próximo middleware. Dessa maneira
podem ser adotadas diversas estratégias para construir a arquitetura da aplicação, o qual irei
abordar na seção 3.3.4. Todas as referências a middlewares nesse documento são relacionados
aos middlewares definidos pelo Express.
No bloco de código abaixo é representado uma simples aplicação construída com Node.js
e Express, onde possui dois middlewares, o primeiro middleware na linha 7 ira exibir a men-
sagem dizendo qual método e qual rota foi chamada para aplicação, logo depois na linha 8, o
próximo middleware será chamado, respondendo com a mensagem "Welcome!"para o usuário.
1 const express = require ( " express " ) ;
2 const http = require ( " http " ) ;
3 c o n s t app = e x p r e s s ( ) ;
4
5 / / Logging middleware
6 app . u s e ( f u n c t i o n ( r e q u e s t , r e s p o n s e , n e x t ) {
7 c o n s o l e . l o g ( " Method : " + r e q u e s t . method + " t o U r l : " + r e q u e s t . u r l ) ;
8 next ( ) ;
9 }) ;
10
11 / / Logging middleware 2
12 app . u s e ( f u n c t i o n ( r e q u e s t , r e s p o n s e , n e x t ) {
13 r e s . end ( " Welcome ! " ) ;
14 }) ;
15
16 h t t p . c r e a t e S e r v e r ( app ) . l i s t e n ( 1 3 3 7 ) ;
17
O middleware Heart Beat foi elaborado para facilitar a conexão entre a API e o Microservice
Heart de autenticação, com apenas uma linha de código dentro do projeto da API é possível
ativar sua autenticação fazendo uso do middleware, que automaticamente configurara suas rotas
e usuário ativo na sessão, se existir. O modelo de autenticação especificado será discutido em
detalhes na Seção 3.4 onde a proposta do Microservice será melhor descrita.
1 const express = require ( " express " ) ;
2 const http = require ( " http " ) ;
3 const heartBeat = r e q u i r e ( ’ . / middlewares / heartBeat ’ ) ;
4 const app = e x p r e s s ( ) ;
5
6 app . u s e ( h e a r t B e a t . p u l s e ) ;
7
8 h t t p . c r e a t e S e r v e r ( app ) . l i s t e n ( 1 3 3 7 ) ;
9
3.3.3 Rotas
Toda as atividades dentro da plataforma são feitas através da API. As rotas foram construídas
de modo versionado, e o modelo de versionamento seguido foi o versionamento por URL8 ,
onde a versão da API deve aparecer explicitamente na URL. Uma rota de exemplo seria:
"http://server.com/v1/actions", onde a versão e representada pelo "v1". Nessa seção será des-
crita a primeira versão da API.
Todas as rotas descritas abaixo com exceção das de autenticação são acessíveis apenas se no
cabeçalho da requisição estiver presente um token de identidade valido, devendo estar presente
na chave "x-access-token". O token pode ser obtido através da rota login descrita abaixo.
• Chats
8 https://restfulapi.net/versioning/
3.3 API - O LABORATÓRIO PARTE 2 17
• Ações
• Servers
3.3.4 Arquitetura
Na aplicação, foi adotado o modelo arquitetural MVC9 junto dos padrões Service Layer10 e
Data Access Object11 . A view do MVC é representada pelo Dashboard descrito no seção 3.2.
3.3.4.1 Controladores
Logo após a aplicação identificar a rota chamada, a requisição será direcionada para o con-
trolador especifico dessa rota. Como no Express tudo são middlewares, os controladores não
são exceções, tendo assim disponíveis os mesmos objetos de requisição, resposta e "next"como
descrito na seção 3.3.1.1.
No bloco de código abaixo é exemplificado a função de executar ações do controlador de
ações da API, que mostra a execução através de um observador que escreve em uma stream
que transmite o retorno dos servidores. Os retornos dos servidores são recebidos do service de
ações, que por sua vez escuta o Server Manager, melhor descrito na seção 3.5.
9 https://en.wikipedia.org/wiki/Model–view–controller
10 https://en.wikipedia.org/wiki/Service ayer attern
l p
11 https://en.wikipedia.org/wiki/Data ccess b ject
a o
18 CAPÍTULO 3 MORI’S LAB
3.3.4.2 Services
Os services representam a camada logica de tratamento da requisição, o caminho intermediário
entre a chamada e a persistência, onde ocorre qualquer tratamento dos dados quanto validações
que possam gerar erros.
No exemplo abaixo é mostrado a ação sendo requisitada para o actionDAO, para logo depois
ser enviada para o Server Manager executa-la.
3.3.4.3 Models
O componente Models corresponde a toda a lógica relacionada a dados com a qual o usuário
trabalha. Isso pode representar os dados que estão sendo transferidos entre os componentes
View e Controller ou qualquer outro dado relacionado à lógica de negócios [11].
No bloco de código abaixo, é exemplificado o Model das actions da plataforma, fazendo o
uso da biblioteca Mongoose Js12 , que funciona como um wrapper da biblioteca original13 do
MongoDB14 para Node.js.
12 http://mongoosejs.com/
13 https://github.com/mongodb/node-mongodb-native
14 https://www.mongodb.com/
3.3 API - O LABORATÓRIO PARTE 2 19
1 new Schema ( {
2 name : {
3 type : String ,
4 required : true
5 },
6 description : {
7 type : String
8 },
9 server : {
10 t y p e : Schema . Types . O b j e c t I d ,
11 ref : ’ Server ’ ,
12 required : true
13 },
14 steps : [
15 {
16 stepNumber : {
17 t y p e : Number ,
18 required : true
19 },
20 command : {
21 text : {
22 type : String ,
23 required : true
24 },
25 inputs : [{
26 question : {
27 type : String
28 },
29 answer : {
30 type : String
31 },
32 varName : {
33 type : String
34 },
35 server : {
36 t y p e : Schema . Types . O b j e c t I d ,
37 ref : ’ Server ’
38 }
39 }]
40 }
41 }
42 ],
43 userId : {
44 t y p e : Schema . Types . O b j e c t I d ,
45 required : true
46 }
47 } , { timestamps : t r u e }) ;
48
3.3.4.5 Criptografia
A criptografia dos dados de servidor é feita através de uma biblioteca que funciona por cima do
modulo crypto15 do Node.js, a criptografia é feita usando AES-256-CBC16 , um cipher muito
usado na internet por SSL/TLS17 , ele é usado com um vetor de inicialização exclusivo e aleató-
rio para cada operação, servindo como secret. A autenticação para leitura dos dados é realizada
usando o HMAC-SHA-51218 , uma função hash de codificação baseada no secret.
3.4 Heart
O Microservice foi inicialmente proposto para facilitar o uso de autenticação e garantia de iden-
tidade, para melhor organização do código e modularidade do projeto, e se tornou uma parte
essencial para a plataforma, assim como possivelmente será para trabalhos futuros, facilitando
bastante a escalabilidade da plataforma.
Heart foi desenvolvido como um Microservice para autenticação, podendo ser usado in-
dependentemente por qualquer aplicação através de sua API REST, porém é necessário uma
chave de API para ser possível sua utilização, isso para ter rastreabilidade das aplicações e seus
usuários.
15 https://nodejs.org/api/crypto.html
16 https://en.wikipedia.org/wiki/Advanced ncryption tandard
E S
17 https://en.wikipedia.org/wiki/Transport ayer ecurity
L S
18 https://en.wikipedia.org/wiki/HMAC
3.4 HEART 21
3.4.1 Tecnologias
Seguindo o padrão da API, o Microservice também foi desenvolvido fazendo uso das tecno-
logias Node.js e o framework Express, e com a mesma arquitetura, descritos na seção 3.3.1,
porém seu código é bastante simples, já que por sua vez trata-se de um Microservice.
3.4.2.1 Autenticidade
A autenticidade é feita a partir de Json Web Token(JWT)19 , que é um padrão RFC-751920 de
mercado que define como transmitir e armazenar objetos JSON de forma compacta e segura
entre diferentes aplicações [13].
19 https://en.wikipedia.org/wiki/JSON eb oken
W T
20 https://tools.ietf.org/html/rfc7519
22 CAPÍTULO 3 MORI’S LAB
Fazendo uso do JWT e da chave de API o Microservice recupera os dados do usuário para
configurar a requisição com os dados de conta e aplicação para serem utilizados pela aplicação
que chamou o Microservice.
3.4.2.2 Rotas
O Microservice é composto por apenas três rotas, sendo uma para login, que retorna um novo
token, uma para autenticação e outra para verificar se o token passado é valido, retornando o
objeto do usuário.
Foi construído com a proposta de controlar todos os acessos a servidores dos usuários, de
maneira simples e direta;
3.5.1 Tecnologias
Apesar do Server Manager ser construído com as mesmas tecnologias que a API (seção 3.3.1) e
Microservice Heart (seção 3.4.1), seus padrões de projeto e arquitetura são diferentes e bastante
mais simples. pois possui funcionalidade única, essa sendo executar commandos em servidores
e manter stream de dados entre servidores e API das respostas obtidas.
3.5.2 Arquitetura
Sua arquitetura não faz uso de middlewares personalizados como nos outros projetos, pos-
suindo um controller único e serviço único, que fazem todo o controle das conexões e stream
de dados.
Mori, a ChatBot é o módulo da plataforma que conversa com o usuário, servindo de inter-
face para que as ações sejam executadas, trazendo visibilidade das execuções em tempo real e
controle de seus dados.
O ChatBot foi desenvolvido inicialmente apenas para o telegram21 , uma plataforma de men-
sagens open source, sendo um dos grandes concorrentes do aplicativo de mensagens whatsapp.
O telegram foi escolhido pois disponibiliza uma plataforma, API e bibliotecas muito completas
21 https://telegram.org/
24 CAPÍTULO 3 MORI’S LAB
3.6.1 Arquitetura
A aplicação foi construída utilizando Node.js e fazendo uso da biblioteca framework para cri-
ação de BOTS para telegram, Telegraf22 , que funciona sobre a API do próprio telegram.
3.6.1.2 Services
A camada de services é a camada que faz comunicação entre o BOT e o Laboratório (API), tra-
zendo assim informações e gerando dados, assim como executando ações e mantendo streams
ativas ao chat.
3.6.2 Eventos
• /start - inicia a conversa com a Mori, ela a partir disso mandará instruções básicas sobre
como conversar com ela, baseado se o usuário esta autenticado ou não.
22 https://telegraf.js.org/
3.6 MORI (CHATBOT) 25
• Ao mandar foto - A Mori ao receber uma foto vai tentar achar padrões de QRCode na
foto, para assim poder fazer a autenticação da sua conta ao chat, essa função é exclusiva
para autenticação.
• actions - Ira fazer a Mori listar as suas ações disponíveis, e a qual servidor elas estão
ligadas.
• execute nomeDaAção - Ira mandar a Mori executar uma ação no servidor, ela a partir
disso ira te fazer perguntas, caso a ação tenha inputs, para que sejam completados. Uma
vez que todas as perguntas estiverem respondidas, ela ira se comunicar com o Labora-
torio(API) através do services para mandar executar a ação, com isso, será iniciado uma
stream com seu servidor, mostrando o log em tempo real da execução dos comandos.
• cancel - Ira pedir para cancelar a ação atual, cancelando a stream e fazendo a Mori voltar
a seu estado inicial.
3.6.3 Sumário
Nesse capítulo foi abordado a definição do projeto e as arquiteturas e tecnologias dos diversos
componentes que o compõem, junto com suas regras de execução, segurança e detalhes. Tendo
assim uma noção de suas funcionalidades e de como funcionam em conjunto.
O próximo capítulo mostra como a plataforma entrega seu valor usando seus componentes
em casos de uso reais para demonstrar os benefícios alcançados.
C APÍTULO 4
Mori em ação
Neste capítulo é demonstrado casos de uso em servidores reais que mostram de modo prático
em que tipo de situações a Mori pode ser utilizada, mostrando seu passo a passo de execução e
analise de resultados.
Para esse teste, uma simples ação para stream de log foi configurada, capaz de trazer transpa-
rência com apenas um step e um input, sendo o cadastro demonstrado na figura 4.1.
Ao ser executado o BOT ira fazer a pergunta do input para o step como mostra a figura 4.2.
27
28 CAPÍTULO 4 MORI EM AÇÃO
Apos responder o nome do arquivo, todas os inputs já estarão preenchidos, sendo assim
iniciada a execução remota. Com isso, ela ira mandar parte do arquivo, e iniciara a stream de
dados para novas entradas como mostra a figura 4.3.
Nesse exemplo vamos monitorar novas sessões em um servidor. Pedimos para Mori moni-
torar o arquivo "/var/log/syslog", que é o arquivo de log do sistema operacional Ubuntu1 que
registra as sessões dos usuários, ou seja, sempre que um usuário iniciar uma sessão, isso sera
registrado nesse arquivo. Com a stream ativa, iniciei uma conexão ssh no mesmo servidor que a
Mori está observando o syslog, como demonstra a figura 4.4, assim que a conexão foi iniciada
1 https://www.ubuntu.com/
4.1 MONITORAMENTO VIA STREAM DE LOG 29
a Mori nos envia o nova entrada no log figura 4.5. Esse monitoramento registrou resultados
com delay em média de menos de um segundo.
Nesse teste irei mover entre servidores a base de dados de exemplo disponibilizada pele equipe
do mysql chamada sakila, essa ação necessita de apenas 3 steps e 3 inputs demonstrados na
figura 4.6.
Após isso, será perguntado para qual servidor o dump devera ser enviado figura 4.8.
4.2 MOVENDO BANCO DE DADOS ENTRE SERVIDORES 31
Com o fim dos inputs, a Mori ira fazer o processamento das respostas e enviar a ação
preenchida para a API executá-la, ativando assim a stream de execução em tempo real dos
comandos como mostra a figura 4.10 e 4.11.
4.3 Sumário
Nesse capitulo foi demonstrado alguns exemplos práticos possíveis da utilização da plataforma,
trazendo benefícios como transparência de dados e resiliência. Uma vez que é possível observar
em tempo real entrada de dados e automatizar backup/envio de dados entre servidores.
C APÍTULO 5
Conclusão
O GitHub deu um passo muito importante para a área de DevOps e ChatBots com seu en-
tusiasmo e introdução do conceito de ChatOps, trazendo um grande valor levando em conta
que a adoção de ferramentas de Continuous Integration e Continuos Delivery vem se tornando
bastante popular tanto em grandes empresas como novas startups. Trazendo benefícios de agi-
lidade e maior transparência de todo o processo de uma aplicação.
Com o desenvolvimento desse trabalho, a plataforma, seus serviços e modelos, foi possível
provar de maneira pratica e simples a automação via chat de tarefas simples e bastante distin-
tas. Tendo seu objetivo principal concluído, que era do desenvolvimento da plataforma, que
encontrasse em produção e disponível para uso1 . Também foi possível alcançar transparência,
resiliência e alta disponibilidade nos servidores, uma vez que é possível configurar ações ca-
pazes de gerar streams em tempo real de dados, fazerem backups, atuar para recuperações de
desastres transferindo dados e comunicação entre inúmeras instâncias.
Com os testes feitos foi possível ilustrar sua capacidade de executar ações em casos reais,
trazendo mais agilidade aos times, mesmo o projeto se limitando em comandos que não en-
volvem respostas interativas (que respondem perguntas do próprio sistema). Além de que a
comunicação entre servidores encontrasse em um estado simples inicial, onde é necessário o
uso de senhas inline. Outra Limitação é que as actions não são testadas automaticamente no
momento de criação, deixando sob responsabilidade do autor sua eficácia.
• Tipos de Conexões: Sera estudado outras maneiras além de SSH de garantir a conexão
com servidores.
• SSH Por par de chaves: Sera adicionada a opção de autenticação de servidor via chaves,
evitando o uso de senhas e trazendo mais segurança.
• Suporte a VPN: Por questões de segurança, diversas empresas não abririam seus servi-
dores para internet, por isso que tal suporte sera extremamente essencial.
1 http://morislab.com
33
34 CAPÍTULO 5 CONCLUSÃO
• Novas interfaces de execução: Sera estudado novos provedores de ChatBots para serem
adotados, assim como possível desenvolvimento de aplicativo.
Referências Bibliográficas
[2] E VERYKING , M AC T ED , R EDW OLF . Data access object — Wikipedia, the free encyclo-
pedia, 2004. [Online; accessed 22-July-2018].
[4] FELL, S. Are you talking to me? chatops and the rise of conversation-driven devops.
[5] F URDA , A., F IDGE , C., Z IMMERMANN , O., K ELLY, W., AND BARROS , A. Migrating
enterprise legacy source code to microservices: On multitenancy, statefulness, and data
consistency. IEEE Software 35, 3 (May 2018), 63–72.
[10] K ERSTEN , M. A cambrian explosion of devops tools. IEEE Software 35, 2 (March 2018),
14–17.
[12] M ARIJAN , D., L IAAEN , M., AND S EN , S. Devops improvements for reduced cycle times
with integrated test optimizations for continuous integration. In 2018 IEEE 42nd Annual
Computer Software and Applications Conference (COMPSAC) (July 2018), pp. 22–27.
35
36 REFERÊNCIAS BIBLIOGRÁFICAS
[17] R AHMAN , A. M., M AMUN , A. A., AND I SLAM , A. Programming challenges of chat-
bot: Current and future prospective. In 2017 IEEE Region 10 Humanitarian Technology
Conference (R10-HTC) (Dec 2017), pp. 75–78.
[18] S HAHIN , M., BABAR , M. A., Z AHEDI , M., AND Z HU , L. Beyond continuous delivery:
An empirical investigation of continuous deployment challenges. In 2017 ACM/IEEE
International Symposium on Empirical Software Engineering and Measurement (ESEM)
(Nov 2017), pp. 111–120.
[20] TAIBI , D., L ENARDUZZI , V., AND PAHL , C. Processes, motivations, and issues for
migrating to microservices architectures: An empirical investigation. IEEE Cloud Com-
puting 4 (2017), 22–32.
[21] V IVAH , L. The beginner’s guide: Understanding node.js & express.js fundamentals.