Daniel Guimarães
Implementação nas Nuvens de aplicação web:
ambiente BlueMix
Trabalho de Conclusão de Curso
Tese apresenta...
Daniel Guimarães
Implementação nas Nuvens de aplicação web:
ambiente BlueMix
Tese apresentada como requisito parcial para ...
Todos os direitos reservados. É proibida a reprodução total
ou parcial do trabalho sem autorização da universidade, do
aut...
Agradecimentos
Resumo
Daniel Guimarães; Hermann, Edward; Rademaker, Alexandre.
Implementação nas Nuvens de aplicação web: ambiente
BlueMi...
Abstract
Daniel Guimarães; Hermann, Edward; Rademaker, Alexandre. A
Cloud implementation of an web app. Rio de Janeiro, 20...
Sumário
1 Introdução 10
2 Estado da Arte 13
2.1 Cloud Computing 13
2.1.1 Modelos de Serviço Cloud 13
2.2 Docker 15
2.3 Máq...
Lista de figuras
2.1 Arquitetura básica do Docker (cite-architecture-image) 16
2.2 Virtualização baseada em hipervisor (cit...
Lista de tabelas
1
Introdução
A Amazon, através do ’Amazon Web Services’ (AWS) oferece serviços de
’cloud computing’ oficialmente desde 2006...
Capítulo 1. Introdução 11
sem a necessidade de manter uma infraestrutura de hardware normalmente
associada com o seu desen...
Capítulo 1. Introdução 12
privacidade e considerações regulamentares em comum. Dessa forma, os
custos de uma community clo...
2
Estado da Arte
2.1
Cloud Computing
Ao buscar o significado de ’cloud computing’, torna-se necessário citar a
VMware Inc, ...
Capítulo 2. Estado da Arte 14
• Software as a Service (SaaS): É garantido ao consumidor usar as aplicações
do provedor, ro...
Capítulo 2. Estado da Arte 15
realizar o ’deploy’ do Cloud Foundry PaaS, mas também pode ser utilizado
para o ’deploy’ de ...
Capítulo 2. Estado da Arte 16
Figura 2.1: Arquitetura básica do Docker (cite-architecture-image)
• docker run roda um coma...
Capítulo 2. Estado da Arte 17
imagem local, o usuário pode construir um contêiner e executar um comando
sobre esse através...
Capítulo 2. Estado da Arte 18
Figura 2.2: Virtualização baseada em hipervisor (cite-hypervisorbased-image)
operacional hos...
Capítulo 2. Estado da Arte 19
Figura 2.3: Virtualização baseada em contêiner, Docker (cite-osbased-image)
3
Objetivos
Existem três objetivos sequenciais que podem ser enumerados:
1. Ajudar no desenvolvimento do editor de produçã...
Capítulo 3. Objetivos 21
deve disponibilizar a todos os outros pesquisadores a versão mais nova para
que esses possam real...
Capítulo 3. Objetivos 22
Diferentemente do foco dado a domínios particulares comum na litera-
tura de pesquisa acadêmica, ...
Capítulo 3. Objetivos 23
# Instala o java 1.7 necessário para instalar o elasticsearch
RUN yum -y install java-1.7.0-openj...
Capítulo 3. Objetivos 24
construidos para serem processados pelo RPM. O Elasticsearch permite sua
instalação através do RP...
4
Especificação do Sistema
4.1
Caso de uso Docker, ip-editor
Como um caso de uso da tecnologia Docker apresentada, será uti...
Capítulo 4. Especificação do Sistema 26
Another System Definition Facility (cite-asdf) é uma ferramenta para
especificar como...
Capítulo 4. Especificação do Sistema 27
• Drakma (cite-drakma): É um cliente HTTP que permite ’http/1.1 chunking’,
conexões...
Capítulo 4. Especificação do Sistema 28
• Log4CL (cite-Log4J): é um utilitário para a realização de logs, i.e. eventos
que ...
Capítulo 4. Especificação do Sistema 29
que são parte do Quicklisp, é possível carregar esse sistema, referido pelo link
si...
Capítulo 4. Especificação do Sistema 30
esse no servidor Hunchentoot. Através de sua declaração como um componente
na espec...
Capítulo 4. Especificação do Sistema 31
Na página de busca, a princípio, todos os resultados presentes na base de
dados era...
Capítulo 4. Especificação do Sistema 32
> curl ’http://localhost:9200/?pretty’
4) Rode a aplicação lisp
4.1) Inicialize o s...
Capítulo 4. Especificação do Sistema 33
# 2) Na pasta /home
WORKDIR /home
# Cria um script lisp que carrega o ASDF e carreg...
Capítulo 4. Especificação do Sistema 34
COPY resources/clesc/ /home/clesc/
COPY resources/asdf.lisp /home/quicklisp
5
Conclusão
5.1
Controvérsias
A definição de ’cloud computing’ não é única e bem definida em toda
a comunidade de computação...
Capítulo 5. Conclusão 36
realiza certas computações (e.g. modificar uma foto, traduzir texto para outra
linguagem, entre ou...
Capítulo 5. Conclusão 37
• Reprodutibilidade: A capacidade de integrar fontes, componentes de tercei-
ros, dados e externa...
Referências Bibliográficas
[cite-Log4J] MIKHANOSHA, M.. Common lisp logging framework, mo-
deled after log4j. https://githu...
Referências Bibliográficas 39
[cite-dom] W3SCHOOL. The html dom document object. http://www.
w3schools.com/jsref/dom_obj_do...
Referências Bibliográficas 40
[cite-run-bosh-vsphere] BUDNACK, J. R.. Running bosh-lite on vsphere
hypervisor free edition....
Próximos SlideShares
Carregando em…5
×

tcc

10 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
10
No SlideShare
0
A partir de incorporações
0
Número de incorporações
5
Ações
Compartilhamentos
0
Downloads
0
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

tcc

  1. 1. Daniel Guimarães Implementação nas Nuvens de aplicação web: ambiente BlueMix Trabalho de Conclusão de Curso Tese apresentada como requisito parcial para obtenção do título de Engenheiro pelo Programa de Graduação em Engenharia de Computação do Departamento de Departamento de Informártica da PUC-Rio. Orientador : Prof. Edward Hermann Coorientador: Dr. Alexandre Rademaker Rio de Janeiro Junho de 2016
  2. 2. Daniel Guimarães Implementação nas Nuvens de aplicação web: ambiente BlueMix Tese apresentada como requisito parcial para obtenção do título de Engenheiro pelo Programa de Graduação em Engenharia de Computação da PUC-Rio. Aprovada pela Comissão Examinadora abaixo assinada. Prof. Edward Hermann Orientador Departamento de Departamento de Informártica – PUC-Rio Dr. Alexandre Rademaker Coorientador International Business Machines – IBM Prof(a). Simone Barbosa Pontifícia Universidade Católica – PUC-Rio Prof. Bruno Lopes Vieira Universidade Federal Fluminense – UFF Rio de Janeiro, 12 de Junho de 2016
  3. 3. Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador. Daniel Guimarães A princípio, me inscrevi para o curso de Engenharia de Produção, no entanto, após dar monitoria para a Prof(a). Paula Lucena de Programação I (INF1005), fui convidado a trabalhar no TecGraf no projeto V3o2 liderado pelo Dr. Pedro Mário Silva, no qual estagiei durante 10 meses e consegui aperfeiçoar meu código em C. Devido a experiência positiva como programador, mudei para Engenharia de Computação e recebi uma proposta para aplicar para trabalhar na FGV num projeto da EMAp (Escola de Matemática aplicada) na implementação do VIVO. Por fim, estagiei no laboratório de pesquisa da IBM - Brasil durante 9 meses período no qual trabalhei nesse projeto de final de curso. Ficha Catalográfica Daniel Guimarães Implementação nas Nuvens de aplicação web: ambiente BlueMix / Daniel Guimarães; orientador: Edward Hermann; co-orientador: Alexandre Rademaker. – Rio de Janeiro : PUC- Rio, Departamento de Departamento de Informártica, 2016. v., 40 f: il. ; 29,7 cm 1. Tese (graduação) - Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Departamento de Informár- tica. Inclui referências bibliográficas. 1. Departamento de Informártica – Tese. 2. Elasticsearch;. 3. Hunchentoot;. 4. Closure Template;. 5. Common Lisp;. 6. Docker;. 7. Cloud Computing;. 8. Web Development.. I. Hermann, Edward. II. Rademaker, Alexandre. III. Pontifícia Universidade Católica do Rio de Janeiro. Departamento de Departamento de Informártica. IV. Título. CDD:
  4. 4. Agradecimentos
  5. 5. Resumo Daniel Guimarães; Hermann, Edward; Rademaker, Alexandre. Implementação nas Nuvens de aplicação web: ambiente BlueMix. Rio de Janeiro, 2016. 40p. TCC – Departamento de De- partamento de Informártica, Pontifícia Universidade Católica do Rio de Janeiro. Nesse trabalho será será apresentada minha contribuição no desenvolvi- mento de uma aplicação web, assim como a integração dessa, através do contêiner Docker, ao serviço ’cloud’ IBM Bluemix. Dessa forma, será decor- rido as contribuições feitas para essa aplicação assim como sua arquitetura, além do estudo das ferramentas disponíveis no mercado atualmente. Palavras-chave Elasticsearch;. Hunchentoot;. Closure Template;. Common Lisp;. Docker;. Cloud Computing;. Web Development..
  6. 6. Abstract Daniel Guimarães; Hermann, Edward; Rademaker, Alexandre. A Cloud implementation of an web app. Rio de Janeiro, 2016. 40p. TCC – Department of Departamento de Informártica, Pontif- ícia Universidade Católica do Rio de Janeiro. This work presents a contribution on the development of a web application and its integration, via Docker, to the Bluemix cloud service. It will be listed and described each contribution and the aplication‘s architecture, as well as the tools recently available in this work‘s scope. Keywords Elasticsearch;. Hunchentoot;. Closure Template;. Common Lisp;. Docker;. Cloud Computing;. Web Development..
  7. 7. Sumário 1 Introdução 10 2 Estado da Arte 13 2.1 Cloud Computing 13 2.1.1 Modelos de Serviço Cloud 13 2.2 Docker 15 2.3 Máquina virtual baseada em hipervisor x Contêiner 17 3 Objetivos 20 3.1 Motivação 20 3.2 Dockerfile 21 3.3 Deploy Bluemix 24 4 Especificação do Sistema 25 4.1 Caso de uso Docker, ip-editor 25 4.1.1 Arquitetura da Aplicação ip-editor 25 4.1.2 Contribuições Realizadas 30 4.1.3 Utilizando o Dockerfile 31 4.1.4 Dockerfile 32 5 Conclusão 35 5.1 Controvérsias 35 5.2 Trabalhos Futuros 36 Referências Bibliográficas 38
  8. 8. Lista de figuras 2.1 Arquitetura básica do Docker (cite-architecture-image) 16 2.2 Virtualização baseada em hipervisor (cite-hypervisorbased-image) 18 2.3 Virtualização baseada em contêiner, Docker (cite-osbased-image) 19 4.1 Workflow básico da aplicação 29
  9. 9. Lista de tabelas
  10. 10. 1 Introdução A Amazon, através do ’Amazon Web Services’ (AWS) oferece serviços de ’cloud computing’ oficialmente desde 2006, apesar do primeiro serviço, ’Simple Queue Service’, ter sido disponibilizado ao público em 2004. Informado pela Reuters, a Cisco Systems decidiu, também em 2004, investir um bilhão de dólares até 2006 para entrar no mercado de ’cloud computing’ (cite-reuters). O Google, em abril de 2008, liberou o ’Google App Engine’, sua versão do ’platform as a service’ (PaaS) como oferecido pelos seus concorrentes descri- tos acima. Com o rápido desenvolvimento dos processadores e dispositivos de armazenamento, recursos computacionais tem se tornado mais baratos e dispo- níveis, esse avanço permite que um novo paradigma de computação se popula- rize. Apesar da recente notoriedade, a ideia por trás de ’cloud computing’ não é tão nova quanto parece, em 1961 John McCarthy foi o primeiro a sugerir em público, que tecnologias de computação por ’time-sharing’ guiariam o futuro, no qual poder computacional e aplicações específicas seriam vendidas por um modelo de serviço utilitário, como os serviços de água ou eletricidade. Para iniciar esse estudo, é necessário distinguir dois provedores no modelo ’cloud’, os provedores de infraestrutura que gerenciam a plataforma ’cloud’ e alugam seus recursos computacionais baseado em um modelo de pagamento proporcio- nal a utilização do recurso; e os provedores de serviço que alugam recursos dos provedores de infraestrutura para servir seus usuários finais. Nesses termos, a recente corrida das companhias provedoras de infraestrutura é pautada por qual é capaz de prover os serviços computacionais mais potentes, confiáveis e eficientes em custo para tornar seus modelos de negócio mais rentável. Através do Bluemix, a IBM se insere nessa corrida e provê times de desenvolvimento que oferecem suporte aos usuários para escalar o poder de computação, cola- borar com código-fonte e APIs, gerenciar a performance do aplicativo, logs e custos a partir de um painel provido pela interface web Bluemix. O objetivo desse projeto é mostrar como aplicações web podem ser hospedadas em serviços ’cloud’ como os oferecidos pelo Bluemix. O IBM Bluemix é uma plataforma ’cloud’ que implementa o serviço ’platform as a service’ (PaaS) que oferece serviços de computação ’cloud’ que garantem aos usuários desenvolver, executar e gerenciar aplicações, através de uma interface,
  11. 11. Capítulo 1. Introdução 11 sem a necessidade de manter uma infraestrutura de hardware normalmente associada com o seu desenvolvimento. Nesse trabalho, será discutido sobre as maneiras de realizar o ’deploy’ ou despacho de aplicações web genéricas. Considerando uma aplicação web operacional, há quatro modelos de despacho ou ’deployment models’ (cite-NIST-definition) que se adaptam a diferentes necessidades de serviços para diferentes organizações e demandas dos provedores de serviço. Segue a definição desses quatro modelos baseado em uma discussão formalizada por Sumit Goyal (citeart-deploymodels): • Public cloud: Provedores de serviço oferecem seus recursos para o público. Em public clouds, recursos são oferecidos como serviço, via conexão a internet pelos provedores de infraestrutura. Nesse modelo, os recursos oferecidos como serviços são cobrados de acordo com o uso, não há a necessidade de compra de hardware nem a manuntenção dessa infraes- trutura. No entanto, não é possível nesse modelo determinar a localização do dado armazenado pelo provedor de infraestrutura, que muitas vezes compartilham recursos de infraestrutura com outros provedores de infra- estrutura. Além disso, usuários não autorizados podem obter acesso aos dados e outras informações relevantes da computação realizada. Dessa forma, nas formas mais padronizadas de ofertas de public cloud não é garantido ao provedor do serviço a confibilidade necessária para sua or- ganização, o que implica em um estudo para determinar o contexto no qual o provedor de serviço opera e quais os possíveis riscos da exposição de informações sensíveis a terceiros. • Private cloud: Recursos do provedor de infraestrutura são reservados para o uso exclusivo de um provedor de serviço ou organização. A infraestrutura ’cloud’ é operada somente pelos membros de uma organização ou/e terceiros autorizados pela organização contratante. O propósito desse modelo não é oferecer serviço de cloud para o público em geral, mas para o uso dentro de organizações uma vez que oferece maior controle sobre a performance, confiabilidade e segurança. A private cloud necessariamente provê maior segurança do que public clouds, apesar do custo elevado quando comparado a public cloud; o custo de compra de equipamento, software e pessoal são maiores quando se deseja o serviço de uma private cloud. • Community cloud: Entre a private cloud e public cloud, esse modelo pode ser idealizado como uma private cloud mas a infraestrutura e recursos com- putacionais são exclusivos a duas ou mais organizações ou provedores de serviço. Esse conjunto de organizações possuem requisitos de segurança,
  12. 12. Capítulo 1. Introdução 12 privacidade e considerações regulamentares em comum. Dessa forma, os custos de uma community cloud são mais baratos que uma private cloud uma vez que esses custos são divididos entre as organizações. No entanto, recursos como a largura de banda e capacidade de armazenamento é com- partilhada entre as organizações. • Hybrid Cloud: Esse modelo é mais complexo que os descritos acima pois en- volve a composição de dois ou mais modelos de despacho. Cada membro dessa ’cloud’, modelos descritos acima, permanece uma entidade única mas conectado a outros membros através de tecnologias padronizadas que permite a portabilidade de aplicações e dados entre esses. A cloud híbrida é a composição de pelo menos uma private cloud e pelo menos uma public cloud. Nesse modelo parte do serviço é executado em uma private cloud e a parte restante na public cloud, de forma a garantir mais flexibilidade que esses modelos isolados. Idealmente, uma abordagem hí- brida permite aos provedores de serviço a vantagem da escalabilidade e o baixo custo que uma public cloud oferece, sem expor aplicações críticas e dados à vulnerabilidades.
  13. 13. 2 Estado da Arte 2.1 Cloud Computing Ao buscar o significado de ’cloud computing’, torna-se necessário citar a VMware Inc, uma companhia americana fundada em 1998 que provê software e serviço de virtualização e afirma ser a primeira virtualizar com sucesso a arqui- tetura x86. De acordo com essa, a virtualização é a tecnologia básica por trás de ’cloud computing’. Através de sua própria definição (cite-vmware-definition): ’cloud computing’ é uma abordagem à computação que se constrói na efici- ente concentração de recursos (garantidos pela virtualização) para criar uma infraestrutura ’on-demand’, elástica e auto gerenciável que pode ser alocada dinamicamente como um serviço. A virtualização desassocia aplicações e in- formação da complexidade da infraestrutura necessária de hardware. Pensando nesses termos, o banco de dados não precisa ser instalado no servidor dedicado configurado por um desenvolvedor web uma vez que o armazenamento, por exemplo, pode ser independente da camada física do hardware daquele servidor; com um hipervisor instalado, esse armazenamento pode ser abstraído e entendido como um serviço ’cloud’ que está rodando em um outro servidor em algum outro lugar desconhecido no mundo. Nesse sentido, virtualização é o software que manipula o hardware enquanto ’cloud computing’ é o serviço que resulta dessa manipulação. O National Institute of Standards and Technology (NIST) provê uma ou- tra definição: o modelo que permite acesso ubíquo, conveniente e ’on-demand’ a um conjunto compartilhado de recursos computacionais configuráveis que podem ser rapidamente provisionados e liberados com o mínimo esforço de gerenciamento ou interação com o provedor do serviço. 2.1.1 Modelos de Serviço Cloud Existem três modelos de serviço que são conhecidos no mercado, que os provedores costumam oferecer e são descritos pelo NIST (cite-NIST-definition):
  14. 14. Capítulo 2. Estado da Arte 14 • Software as a Service (SaaS): É garantido ao consumidor usar as aplicações do provedor, rodando infraestrutura ’cloud’ do provedor de serviço. As aplicações são acessíveis aos vários dispositivos do consumidor, através de um leve cliente (interface). O consumidor não gerencia ou controla a infraestrutura ’cloud’ incluindo a rede, os servidores, sistemas operaci- onais ou armazenamento, com a possível limitação de especificações do usuário por ajustes de configurações. • Platform as a Service (PaaS): É garantido ao consumidor o ’deploy’ (des- pachar um software), para a infraestrutura ’cloud’, de aplicações criadas pelo próprio consumidor usando linguagens de programação, bibliote- cas e serviços suportados pelo provedor. O consumidor não gerencia ou controla a infraestrutura ’cloud’, incluindo a rede, servidores, sistemas operacionais ou armazenamento, mas tem controle sobre a aplicação que sofreu o ’deploy’ e possivelmente o ajuste de configurações do ambiente da aplicação. • Infrastructure as a Service (IaaS): É garantido ao consumidor a provisionar o processamento, armazenamento, rede e outros recursos de computa- ção fundamentais no qual o consumidor é capaz de realizar o ’deploy’ e executar softwares arbitrários, incluindo sistemas operacionais e aplica- ções. O consumidor não gerencia ou controla a infraestrutura ’cloud’ mas tem controle sobre os sistemas operacionais, armazenamento e aplicações que sofreram ’deploy’; mas possivemente controle limitado da seleção de componentes de rede (e.g. firewalls). Um ótimo exemplo de IaaS é o OpenStack, um sistema operacional ’cloud’, ’open-source’ normalmente oferecendo infraestrutura computacional como um serviço (e.g. máquina virtual). OpenStack consiste em componentes interrelacionados que controlam aglomerados de hardware de recursos compu- tacionais, de armazenamento e de rede em um ’datacenter’. Usuários podem controlá-lo através de um painel web, linha de comando ou RESTful API. O OpenStack é a tecnologia fundamental por trás do serviço de IaaS do Bluemix. Cloud Foundry é uma plataforma ’open-source’ como serviço (PaaS), cri- ado para ser configurada, despachada, gerenciada, escalada e atualizada sobre qualquer provedor IaaS. Cloud Foundry alcança esse objetivo alavancando o projeto BOSH (cite-whatis-bosh?), uma ferramenta ’open-source’ que une ’re- lease engineering’, ’deployment’ e gerenciamento de ciclo-de-vida de pequenos e grandes softwares ’cloud’. BOSH pode provisionar e despachar centenas de máquinas virtuais, além de executar o monitoramento, recuperação de falhas e atualização de software com o mínimo overhead. BOSH foi desenvolvido para
  15. 15. Capítulo 2. Estado da Arte 15 realizar o ’deploy’ do Cloud Foundry PaaS, mas também pode ser utilizado para o ’deploy’ de qualquer outro software. Cloud Foundry é a base para o PaaS oferecido pelo IBM Bluemix (cite-cfoundry@ibm). 2.2 Docker Docker é uma plataforma livre usada para execução e entrega de aplica- ções que permite executar uma aplicação seguramente isolada em um contêiner. Um contêiner é similar a um diretório; nele é guardado tudo que é necessá- rio para uma aplicação rodar. Há um conjunto de ferramentas no entorno dos contêineres as quais ajudam o usuário em atividades como colocar uma apli- cação em um contêiner, realizar o ’deploy’ para o ambiente de produção e a distribuição e entrega desses contêineres para outros grupos prosseguirem com o desenvolvimento e teste. Criado a partir de uma imagem, contêineres podem ser executados, iniciados, parados, movidos e deletados. Cada contêiner é uma aplicação-plataforma segura e isolada, esse isolamento permite rodar múltiplos contêineres simultaneamente no sistema hospedeiro. No Docker, é possível gerar uma imagem Docker, um ’read-only’ tem- plate, construído a partir de um Dockerfile e um ’docker build’. Um Dockerfile é um documento de texto que contém todos os comandos necessários (chama- dos na linha de comando) para montar uma imagem. A partir da especificação de um sistema operacional, deve-se realizar o download de todos os compila- dores e programas utilitários (e.g. o wget que baixa conteúdo a partir de uma URL) necessários para rodar a aplicação junto a todos os componentes que compõem a aplicação (descritos no capítulo 4). O Docker (cite-docker-architecture) usa uma arquitetura cliente-servidor no qual o cliente conversa com o ’daemon’ (servidor). Tanto o cliente quanto o ’daemon’ podem rodar em um mesmo sistema mas não necessariamente, o cliente e o ’daemon’ podem ficar em máquinas distintas pois é possível conectar um cliente a um ’daemon’ remoto através de sockets ou através de uma RESTful API. Docker daemon é um processo persistente que gerencia contêineres. Docker usa diferentes binários para o daemon e o cliente. O daemon faz o trabalho pesado de construir, executar e distribuir contêineres Docker, através das funções ’build’, ’run’, ’push’ e ’pull’: • docker build é o comando que constrói uma imagem Docker a partir de um Dockerfile e um contexto. Um contexto são os arquivos localizados em um ’path’ ou uma ’url’. Um processo de construção pode se referir a qualquer um dos arquivos do contexto.
  16. 16. Capítulo 2. Estado da Arte 16 Figura 2.1: Arquitetura básica do Docker (cite-architecture-image) • docker run roda um comando em um contêiner. O comando primeiramente cria uma camada contêiner sobre uma imagem específica, e então inicia esse contêiner usando o comando especificado, com esse comando é possível iniciar uma ’Unix shell’ a partir de uma imagem criada. • docker push envia uma imagem para o Docker Hub, uma plataforma SaaS para compartilhar e gerenciar contêineres. Docker Hub é serviço ’cloud’ de registros que permite a construção de imagens assim como o teste dessas, assim como o armazenamento dessas as quais são servidas pelo Docker Cloud. • docker pull baixa uma imagem ou um repositório dos registros Docker Hub qual possui imagens pré-construidas, sem a necessidade dos usuários do Docker redefinirem as imagens que já existem nos registros. • docker rmi remove uma imagem da lista de imagens a partir da especificação do parâmetro ’image id’, um identificador de uma imagem, ou do ’TAG’, dado para a imagem em sua construção via docker build. A lista de imagens, é exibida sob o útil comando docker images que lista todas as imagens construidas pelo docker. Utilizando as funções descritas e a imagem ’Arquitetura básica do Docker’ referenciada acima, é comum o cliente realizar um ’docker pull’ de uma imagem genérica X. Ao ser interpretado pelo ’daemon’, um HTTP request é enviado para a base de registros do Docker Hub solicitando a imagem X. Caso essa exista na base, ela é baixada para o sistema local do cliente. Ao obter essa
  17. 17. Capítulo 2. Estado da Arte 17 imagem local, o usuário pode construir um contêiner e executar um comando sobre esse através do ’docker run’. 2.3 Máquina virtual baseada em hipervisor x Contêiner A popularidade que Docker tem ganhado entre desenvolvedores tem cres- cido significantemente nos últimos anos, que o procuram para tornar sua apli- cação ubíqua e portátil. No entanto, é importante mencionar outras tecno- logias que endereçam o mesmo problema: hipervisor ou monitor de máquina virtual, VMM (cite-oscontainerXappconteiner). Antes de definir o hipervisor, dois conceitos requerem explicação: sistema operacional hospedeiro é o sistema que detém os recursos de hardware e sistema operacional cliente é o sistema que requer recursos de hardware do sistema operacional hospedeiro. O hiper- visor é uma camada de software entre o hardware e o sistema operacional que é responsável por fornecer uma abstração ao sistema operacional cliente. Essa tecnologia mais antiga, realiza principalmente a emulação do hardware, con- trolando o acesso de sistemas operacionais clientes aos recursos de hardware, de modo que seja possível rodar qualquer sistema operacional sobre qualquer outro (e.g. rodar Linux sobre Windows). Nessa abordagem, tanto o sistema operacional cliente quanto o hospedeiro rodam suas próprias kernels e sua co- municação é feita a partir de uma camada hipervisora abstrata. Os sistemas operacionais modernos, normalmente, segregam sua memória virtual em dois espaços: o espaço kernel e o espaço do usuário, essa separação, garante proteção da memória e a prevenção de falhas (e.g. falha de segmenta- ção) uma vez que o espaço kernel é estritamente reservado para rodar o kernel do sistema operacional e a maioria dos drivers de dispositivos, enquanto o es- paço do usuário é a área de memória onde rodam as aplicações de software. A virtualização baseada em hipervisor, gera um overhead na performance devido a emulação do hardware. Para reduzir esse overhead, outra forma de virtu- alização é provida pelo software Docker: a virtualização no nível do sistema operacional ou container que permite rodar múltiplas instâncias de espaço do usuário em uma mesma kernel. Contêineres são frutos da virtualização de sistemas operacionais, no entanto, diferentemente de uma máquina virtual, esses garantem um ambiente leve que agrupa e isola conjunto de processos e recursos como memória do sistema operacional hospedeiro de qualquer outro contêiner. Assim, é garantido que qualquer processo dentro de um contêiner não tenha acesso a qualquer processo de que execute fora desse contêiner. A diferença básica dos contêineres propostos pelo Docker, é que esses compartilham a mesma kernel do sistema
  18. 18. Capítulo 2. Estado da Arte 18 Figura 2.2: Virtualização baseada em hipervisor (cite-hypervisorbased-image) operacional hospedeiro, o que implica uma melhor utilização dos recursos computacionais e uma agilidade quando comparado com uma máquina virtual tradicional. Apesar da vantagem na performance, os tipos de contêineres que rodam no sistema operacional hospedeiro é limitado justamente devido ao compartilhamento da kernel, não é possível, por exemplo, rodar um contêiner com a imagem do Windows em um sistema operacional hospedeiro Linux.
  19. 19. Capítulo 2. Estado da Arte 19 Figura 2.3: Virtualização baseada em contêiner, Docker (cite-osbased-image)
  20. 20. 3 Objetivos Existem três objetivos sequenciais que podem ser enumerados: 1. Ajudar no desenvolvimento do editor de produção intelectual (ip-editor). 2. Criar um Dockerfile que construa o ambiente necessário para essa apli- cação se hospedar. 3. Fazer o deploy desse Dockerfile para o serviço de ’cloud’ Bluemix. 3.1 Motivação É comum a manutenção de uma relação de produções intelectuais em um laboratório de pesquisa pelos pesquisadores que o compõem, existem várias maneiras de gerenciar essas produções, uma lista em documento formato texto é uma solução para esse problema. De fato, os pesquisadores poderiam compartilhar no laboratório um arquivo possuindo a listagem dos artigos, publicações, palestras (entre outros tipo de produção) para que o gerente tenha uma visão geral do progresso de seu laboratório no tempo. No entanto, um arquivo texto nem sempre garante uma boa visibilidade ao gerente, uma vez que existem vários pesquisadores e vários tipos de produção, uma consulta torna-se mais desgastante que o necessário. Não seria absurdo considerar, o uso por laboratórios de uma planilha (conjunto de tabelas) em formato ’xslx’ (utilizada pelo programa Microsoft Excel) a qual organiza em formato tabular produções, reservando uma tabela para cada tipo de produção, na qual as colunas especificam algum aspecto da produção (e.g. autor, ano) e as linhas listam as diversas produções do laboratório. A demanda por essa planilha foi gerada por um laboratório de pesquisa, como uma forma de armazenar e organizar todo tipo de produção intelectual produzida. Dessa forma, existe um conjunto de tabelas as quais um grupo de pesquisadores são responsáveis por manter e atualizar, contendo o total de produções intelectuais geradas pelos pesquisadores desse laboratório. A manutenção de uma planilha compartilhada é custosa, uma vez que é necessário a cada pesquisador responsável por atualizar a planilha, escrever sobre a versão mais atualizada. Após a edição realizada ao documento, o pesquisador editor
  21. 21. Capítulo 3. Objetivos 21 deve disponibilizar a todos os outros pesquisadores a versão mais nova para que esses possam realizar o mesmo custoso procedimento. Imagine que dois pesquisadores queiram simultaneamente compartilhar suas contribuições com a comunidade, qual será a versão mais atualizada? Supondo que ambos, os quais escreveram sobre uma mesma versão prévia e mais antiga, decidam em um mesmo instante de tempo compartilhar suas versões, qual delas deve ser repassada aos outros pesquisadores? Nesse caso, não há a versão mais atualizada, mas exige o esforço de um terceiro concatenar as duas contribuições em um mesmo documento e depois disponibilizar a comunidade. A aplicação desenvolvida, o sistema de edição de produção intelectual (ip-editor, será exibida sua arquitetura no capítulo 4), é um sistema que implementa as funcionalidades necessárias que eram antes fornecidas pelo software Microsoft Excel. No entanto, existe um esforço nesse sistema em separar apresentação do dado, essa distinção pode ser observada tanto pelo usuário final quanto no diretório do projeto. Dessa forma, o usuário não tem controle sobre a forma de apresentação, diferentemente do Excel, o qual o usuário tinha, por exemplo, acesso a uma série de ferramentas de formatação de texto. A vantagem de esconder do usuário final essas ferramentas é uma questão de foco, uma vez que agora é provido a esse somente as ferramentas que serão utilizadas recorrentemente por ele; os detalhes de apresentação são atribuídas aos mantenedores da aplicação enquanto o usuário deve se preocupar com a gestão e corretude do dado. 3.2 Dockerfile Dockerfile é um arquivo que contém um conjunto de instruções que per- mitem o Docker construir uma imagem nova a partir da especificação de um sistema operacional existente. Listando dependências e variáveis de ambiente, o Dockerfile garante um sumário do código necessário para rodar uma aplicação oferecendo uma solução para o problema de gestão de dependências. Dockerfile provê um simples script, similar a um Makefile (cite-software-make), que define exatamente como construir uma imagem, de acordo com a abordagem natural a DevOps (citeart-docker). DevOps pode ser entendido como uma combinação de filosofias culturais, práticas e ferramentas que melhoram a capacidade de uma organização de entregar aplicações e serviços com rapidez, evoluindo e melhorando produtos em passos mais velozes que organizações utilizando de- senvolvimento de software tradicional e processos de gerenciamento de infra- estrutura. A velocidade alcançada por essa metodologia, permite organizações servir melhor seus clientes e se tornar mais competitivas no mercado.
  22. 22. Capítulo 3. Objetivos 22 Diferentemente do foco dado a domínios particulares comum na litera- tura de pesquisa acadêmica, a abordagem dos desenvolvedores se caracteriza mais pela escrita de scripts que documentação, uma descrição das dependên- cias necessárias para um software rodar partindo do sistema operacional. Carl Boettiger desenvolve uma comparação interessante, ’An introduction to docker for reproducible research, with examples from the R enviroment’, entre a cul- tura de documentação e scripts, partindo da definição da metodologia DevOps de desenvolvimento de software que explora a comunicação, colaboração e in- tegração entre desenvolvedores de software, segue a tradução de dois trechos de seu artigo: "Documentação para ambientes complexos de software é freada por duas demandas opostas. Para tornar simples para novos usuários, a documentação deve explicar detalhes relevantes como especificidades de sistemas operacional. Por outro lado, desenvolvedores preferem abstrair esses detalhes para poupar tempo escrevendo e atualizando documentação." Então define a abordagem DevOps: "Na abordagem DevOps a ’documentação’ de uma aplicação deve se basear em breves descrições de vários caminhos de instalação acompanhados de scripts ou ’receitas’ que automatizam configurações." Dessa forma, Dockerfile atua como um registro transparente das depen- dências necessárias além de informar como instalá-las. Esse formato é compa- tível com a metodologia de desenvolvimento de software presente na cultura dos desenvolvedores que, com alguma familiaridade em scripts shell e o ambi- ente da distribuição Linux em qual se trabalha, permite uma fácil introdução a escrita de Dockerfiles. Além do Docker se utilizar do conhecimento já disse- minado do shell scrtipts, ele garante uma sintaxe simples aos desenvolvedores: INSTRUÇÃO declaração Segue um exemplo de instalação do Elasticsearch em uma distribuição CentOS do Linux: # O sistema operacional que vai ser usado pode ser # especificado a partir da instrução ’FROM’ FROM centos:centos7 # Nomeie o mantenedor desse Dockerfile MAINTAINER Daniel Guimaraes <dcguim@example.br> # Instala, a partir do gerenciador de pacotes yum, nativo do centos7, # o epel que disponibiliza um conjunto extra de pacotes. RUN yum -y install epel-release
  23. 23. Capítulo 3. Objetivos 23 # Instala o java 1.7 necessário para instalar o elasticsearch RUN yum -y install java-1.7.0-openjdk-devel # Configura o repositório do elasticsearch no sistema operacional RUN rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch RUN echo -e "[elasticsearch-2.x]n name:Elasticsearch repository for 2.x packagesn baseurl=https://packages.elastic.co/elasticsearch/2.x/centosngpgcheck=1n gpgkey=https://packages.elastic.co/GPG-KEY-elasticsearchnenabled=1" > elasticsearch.repo # Instala o banco de dados no centos COPY ./elasticsearch.repo /etc/yum.repos.d/ RUN yum -y install elasticsearch O Dockerfile precisa ser escrito usando algumas instruções específicas como por exemplo ’FROM’ e ’RUN’ que são as instruções mais fundamentais em seu uso. Como o próprio nome já sugere, ’FROM’ especifica de qual sistema operacional que se parte e ’RUN’ executa uma instrução nesse sistema. Também é provido instruções auxliares, por exemplo, ’ADD’ e ’COPY’ que copia arquivos locais para o contêiner criado através do Dockerfile. É notável na construção do Dockerfile, a importância da identificação do gerenciador de pacotes mais adequado para o sistema operacional que se escolhe no início do Dockerfile. Um gerenciador de pacotes é uma coleção de ferramentas de software que facilita os processos de instalação, atualização, configuração e remoção de programas de computador para um sistema operacional de maneira consistente. Um gerenciador de pacote deve tratar pacotes, distribuição de software e dados em ’archive file’ que pode ser entendido como a composição de um conjunto de arquivos e metadados, um sistema de arquivos, em um arquivo particular, para tornar mais portátil esse sistema, e.g. anexar um diretório em um email. No exemplo acima, os comandos iniciados por yum, são chamadas ao gerenciador de pacotes nativo do CentOS para a instalação, atualização, configuração e remoção de pacotes como mencionado. EPEL ou ’Extra Packages for Enterprise Linux’ é um grupo associado a distribuição Linux Fedora que cria, mantém e gerencia um conjunto de pacotes de alta qualidade para algumas distribuições do Linux, incluindo o CentOS. EPEL garante que pacotes nunca conflitam ou substituam pacotes na distribuição base Linux, esse permite acesso a um conjunto de pacotes, inclusive o RPM, outro gerenciador de pacotes que funciona somente com pacotes
  24. 24. Capítulo 3. Objetivos 24 construidos para serem processados pelo RPM. O Elasticsearch permite sua instalação através do RPM, Red Hat Package Manager, esse gerenciador de pacotes torna fácil instalar, desinstalar e atualizar um conjunto de pacotes das distribuições Red Hat, incluindo o CentOS. Com essa ferramenta, é possível escrever um Dockerfile que instala o banco de dados Elasticsearch, utilizado no sistema que foi contribuido. 3.3 Deploy Bluemix Uma vez entendido o princípio do Docker, é possível entender como o ’deploy’ para o IBM Bluemix procede: 1. Escrever o Dockerfile baseado nos componentes da aplicação, vide caso de uso no capítulo 4. 2. Construir a imagem Docker, a partir do Dockerfile, através do comando ’docker build’. 3. Efetuar o login por meio do cliente Cloud Foundry na plataforma Bluemix. 4. Efetuar o login no serviço IBM Containers, o qual oferece suporte ao contêiner Docker. 5. Construir um IBM Container a partir da imagem Docker construida com o comando ’cf ic build’.
  25. 25. 4 Especificação do Sistema 4.1 Caso de uso Docker, ip-editor Como um caso de uso da tecnologia Docker apresentada, será utilizado o editor de produção intelectual (ip-editor). Nesse estudo, será apresentado a arquitetura da aplicação e em seguida o Dockerfile desenvolvido necessário para o ’deploy’ da aplicação na plataforma ’cloud’ Bluemix. 4.1.1 Arquitetura da Aplicação ip-editor A aplicação desenvolvida será operada pelos pesquisadores de um labora- tório de pesquisa, os quais irão operar a plataforma preenchendo os metadados referentes a seus próprios artigos, palestras e quaisquer tipo de produção inte- lectual que seja interessante ser registrado para no laboratório de pesquisa. O sistema desenvolvido deve garantir a corretude dos dados armazenados na base de dados, de forma que, o real histórico das produções geradas no laboratório de pesquisa no decorrer do tempo seja reflexo dos metadados armazenados no banco de dados. Na construção dessa aplicação, foi utilizado uma técnica de gerência de projeto conhecida como ’milestone’, essa técnica permite o teste da funcionalidade de um novo produto ao longo do projeto marcando pontos relevantes na linha do tempo de um projeto. O ’milestone’ deve sinalizar mo- mentos cruciais do projeto como o seu início, fim, uma necessidade de revisão ou um planejamento do orçamento. O sistema editor foi escrito com o auxílio da linguagem de programação Common Lisp e todo o código do servidor web foi escrito nessa linguagem. Apesar dessa escolha não ser uma condição para o trabalho com o Bluemix ou Dockers, i.e. outras linguagens de programação poderiam ter sido usadas para o desenvolvimento do servidor e poderiam ainda ser integradas ao Bluemix através do Dockerfile, o uso de Common Lisp implica no uso de outras tecno- logias satélites. Antes da apresentação de cada componente separadamente, é fundamental entender o funcionamento da ferramenta de definição de sistemas em Common Lisp, ’ASDF’.
  26. 26. Capítulo 4. Especificação do Sistema 26 Another System Definition Facility (cite-asdf) é uma ferramenta para especificar como sistemas em Common Lisp são construidos pela determinação de seus componentes, subsistemas e arquivos, e como operar esses componentes na order certa de forma que eles possam ser compilados, carregados e testados. O ASDF apresenta três faces: uma aos usuários de software Common Lisp que querem reusar código de outras pessoas, um para os escritores de código Common Lisp que querem especificar como construir seus sistemas e um para os escritores de extensões em Common Lisp que querem extender o sistema de construção. O ASDF garante várias opções para definir um sistema, o :defsystem-depends-on permite ao programador definir outros sistemas ASDF ou conjuntos de sistemas os quais são dependencias carregadas antes que a definição do sistema proposto seja carregado. As dependências Common Lisp carregadas por essa opção, as quais foram escolhidas a partir da decisão de trabalhar com a linguagem Common Lisp, garantem uma série de funcões e variáveis utilitárias as quais foram usadas na implementação da aplicação. :depends-on (#:hunchentoot #:drakma #:clesc #:cl-fad #:closure-template #:split-sequence #:local-time #:log4cl #:alexandria) • Hunchentoot (cite-hunchentoot): Uma vez que foi decidido utilizar Common Lisp para desenvolver o código servidor da aplicação, Hunchentoot ofe- rece um servidor web e ao mesmo tempo que fornece ferramentas para a construção de websites dinâmicos. Como um servidor web independente, Hunchentoot é capaz de ’http/1.1 chunking’ que é um mecanismo de trasmissão de dado no qual o tamanho do pacote não é determinado no header (primeiros dados de um pacote enviados), uma vez que permite o servidor manter uma conexão persistente HTTP. A conexão persis- tente, ’keep-alive’, permite em uma mesma conexão TCP a realização de múltiplos HTTP ’response/request’ e SSL (cite-ssl). Secure Socket Layer é capaz estabelecer link encriptado entre um servidor web e um nave- gador. Com esse servidor web, foram implementadas funções ’handlers’ que recebem recebem ’requests HTTP’ do navegador cliente e retornam páginas web compostas de HTML, Javascript e JSON.
  27. 27. Capítulo 4. Especificação do Sistema 27 • Drakma (cite-drakma): É um cliente HTTP que permite ’http/1.1 chunking’, conexões persistentes e SSL como descritos no Hunchentoot. ’HTTP request’ é o coração do Drakma, esse é usado para enviar requests para servidores web e retorna ou o corpo da mensagem resposta do servidor ou, se o usuário preferir, uma ’stream’. O Drakma foi utilizado para realizar a autenticação dos pesquisadores no sistema editor, uma vez que esses precisam se identificar para realizar uma edição no sistema. • Clesc (cite-clesc): Common Lisp Elasticsearch client é um conjunto de funções que facilitam a construção de queries para o banco de dados Elasticsearch em código Common Lisp. Esse cliente foi largamente usado na aplicação, tanto para retornar documentos armazenados no banco de dados a partir de uma query quanto para atualizar um campo em um documento no banco de dados. • CL-FAD (cite-cl-fad): é uma fina camada sobre as padronizadas funções de pahtname Common Lisp. Essa camada tem o objetivo de prover unificação entre as atuais implementações Common Lisp no Windows, OS X, Linux e Unix. Essa biblioteca serve para compilar os arquivos tmpl, referentes aos closure templates utilizados para gerar as páginas HTML. • Closure Template (cite-closure-template): Um sistema de template que im- plementa tanto o cliente como o servidor, fornecendo suporte a constru- ção de páginas HTML reusáveis e elementos de interface. Esse sistema, implementado também em Common Lisp (cl-closure-template), garante uma maneira simples para construir pedaços de HTML para uma apli- cação web no qual a lógica é separada da exibição. • Split Sequence (cite-split-sequence): é um utilitário Common Lisp, que divide uma sequência em uma lista de subsequências delimitadas por objetos que satisfazem um dado teste. Essa função foi utilizada no auxílio à realização de buscas ao banco de dados Elasticsearch, juntas ao cliente Clesc. • Local Time (cite-local-time): uma biblioteca construida para a manipulação de tempo e data, essa foi baseada em um paper de Erik Naggum (citeart-local-time). As funções providas por essa biblioteca foram usadas para captar os ’timestamps’ das buscas, sendo esses uma sequência de caracteres que identificam quando um evento ocorreu, normalmente retornando a data e o tempo no dia.
  28. 28. Capítulo 4. Especificação do Sistema 28 • Log4CL (cite-Log4J): é um utilitário para a realização de logs, i.e. eventos que ocorreram no sistema os quais são concentrados em um arquivo. Dessa forma, uma vez que um erro ocorre, é interessante ao desenvolvedor indicar, ao entrar em uma função por exemplo, que tal evento ocorreu permitindo um futuro relatório do caminho de execução, possibilitando a identificação do erro ocorrido. • Alexandria (cite-alexandria): um projeto e biblioteca que possui como ob- jetivo remover a duplicação de esforço e melhorar a portabilidade de código Common Lisp de acordo com sua própria idosincrasia. Essa bibli- oteca foi utilizada por exemplo, para reconhecer os arquivos templates usados para contruir o HTML da aplicação. Para realizar a interface gráfica, foi utilizado JavaScript e uma série de bibliotecas utilitárias: selectize, sifter, jquery, moment, microplugin e boots- trap. No entanto, não será dado ênfase em cada uma dessas bibliotecas pois a interface gráfica está longe de ser uma prioridade nesse trabalho, uma vez que o carregamento dos componentes é trivial a partir do Bower (cite-bower). Bower é um gerenciador de pacotes Javascript, que gerencia componentes que contém HTML, CSS, JavaScript, fontes e até imagens. Bower instala as versões certas dos pacotes necessários e dependências para executar código JavaScript organizadamente. Elasticsearch (cite-elastic-guide) é um mecanismo ’open-source’ de busca ’real-time’ i.e. demora entre indexação de um documento e a sua visualização no mecanismo de busca é muito baixo, e permite a realização de buscas ’full- text’. Contrastando com a busca por metadados, a busca ’full-text’ opera sobre conteúdos de arquivos singulares armazenados no computador. É possível também realizar buscas estruturadas, no qual todo campo é indexado e passível de ser procurado. Além de operar como um banco de dados, o Elasticsearch provê ferramentas de análise desses dados. Elasticsearch foi a ferramenta utilizada para armazenar os dados referentes as produções intelectuais, e toda a interação entre o sistema desenvolvido e esse banco de dados foi feito via Clesc, como descrito anteriormente. Uma vez que é possível definir o sistema, é preciso carregá-lo para que seja possível usar as funções definidas, inclusive a que inicializa o servidor. Quicklisp é um gerenciador de bibliotecas Common Lisp, usado para baixar, instalar e carregar mais de 1200 bibliotecas a partir de comandos simples. Quicklisp pode ser usado não somente para bibliotecas parte do QuickLisp mas por sistemas definidos a partir do ASDF. Uma vez que há um link simbólico de um sistema ASDF no diretório " /quicklisp/local-projects/", o qual contém componentes
  29. 29. Capítulo 4. Especificação do Sistema 29 que são parte do Quicklisp, é possível carregar esse sistema, referido pelo link simbólico, com um comando ql:quickload. Segue abaixo a arquitetura do sistema proposto: Figura 4.1: Workflow básico da aplicação Um exemplo de página web, a construção do formulário de edição, facilita o entendimento da interação entre esses componentes. Com a permissão necessária, um usuário é capaz atualizar um index do banco de dados. A primeira página apresentada do ip-editor lista todas as produções em sua base de dados, ao clicar no botão ’e’ ao lado da produção intelectual e realizar um ’submit’ de alguma edição feita nos formulários providos o sistema atualiza o banco de dados. Quando um usuário clica no botão ’e’ ao lado de uma produção específica, um hyperlink composto pelo pathname ’/edit’ e os parâmetros necessários, encaminha um ’request’ ao handler de edição. O Hunchentoot handler de edição, chama um template closure que gera o formulário, com os campos necessários para aquele tipo de produção intelectual, a partir dos dados retornados de uma chamada clesc (cite-clesc) es/get. Uma vez que o usuário modificou o formulário e clicou em ’submit’ um outro handler "edit- document"se encarrega de realizar um clesc es/add ao banco de dados da ’hash- table’ doc retornada pelo navegador cliente. Dessa forma, é atualizado um index no banco de dados a partir do formulário de edição exibido ao navegador web cliente. Como o projeto final I foi implementado em Common Lisp, com o auxílio do livro escrito por Peter Seibel (cite-practical-cl), já existia algum conhecimento na linguagem, mas foi preciso aprender a integrar o Lisp ao Closure Template (cite-closure-template) e entender minimamente como rodar
  30. 30. Capítulo 4. Especificação do Sistema 30 esse no servidor Hunchentoot. Através de sua declaração como um componente na especificação do sistema ip-editor, Another System Definition Facility , o componente templates é carregado ,e compilado se necessário, pelo asdf, enquanto no lado do servidor é necessário realizar um push da dispatch function formada a partir dos componentes especificados para o parâmetro hunchentoot:*dipatch-table* (cite-hunchentoot). Dada a crescente demanda por funcionalidades e correções prioritárias e o prazo para o término dessas, não havia tempo para a realização de testes em larga escala. Durante um milestone, no qual existe um conjunto de melhorias as quais devem ser incrementalmente resolvidas até o prazo estipulado, não foi definido nenhum procedimento comum a ser verificado ou executado no final de cada implementação incremental. Os testes foram realizados na própria interface gráfica, ao trabalhar no problema do botão de edição da produção que é apresentada ao usuário com permissão necessária, de modo que uma nova página de edição de produção intelectual seja gerada a partir de um template closure de edição. O procedimento adotado foi de fato: manualmente gerar todos os tipos de produção intelectual e, em seguida, editar cada uma dessas produções separadamente; por último, as novas produções criadas eram verificadas e em seguida deletadas. Dessa forma, todos os tipos formulários foram testados, o que não implica que nesse método manual, se tem a garantia de que todos os formulários gerados serão adequadamente criados. 4.1.2 Contribuições Realizadas • Criação do formulário de uma nova entrada de produção intelectual. • Paginação das produções na página inicial do editor. Foi implementado a página de criação de uma nova entrada de produ- ção intelectual, nessa implementação, ao clicar no botão ’New’, uma página intermediária é apresentada ao usuário para escolher o tipo de produção que deseja gerar. Após selecionar o tipo, o handler ’new-doc’ invoca um template ’add-document’, especificando que esse deve conter somente os campos reque- ridos informados na constante *es-mapping* (lista de listas na qual o primeiro elemento é o tipo de produção e o resto da lista contém todos os campos que aquele tipo de produção venha a ter, e.g., em uma publicação deve ser es- pecificado qual capítulo foi escrito). Dessa forma, cria-se um novo formulário adequado a produção com todos seus campos em branco. De seguida ao pre- enchimento do formulário, as informações escritas são validadas de forma a garantir a coerência dos dados que entram na base de dados.
  31. 31. Capítulo 4. Especificação do Sistema 31 Na página de busca, a princípio, todos os resultados presentes na base de dados eram apresentados, e foi requerido realizar a paginação desses resultados, de forma que sejam apresentados em pequenos grupos de produções, assim, o usuário pode navegar incrementalmente em conjuntos de ’$size’ resultados e usufruir de uma interface mais limpa. Como mencionado anteriormente, existem duas variáveis que são mantidas no closure-templates, ’$size’ e ’$start’, a primeira é uma constante que armazena o número de resultados que devem ser exibidos na página de busca, a segunda, o índice da paginação, i.e. um número, múltiplo de ’$size’, que representa as páginas que já foram visualizadas pelo usuário. Logo, o ’Previous’ visualiza os ’$size’ resultados anteriores, caso o ’$start’ seja maior que o ’$size’ através de uma chamada de função Javascript ’jump’ que atua ’onlclick’. De forma similar, o total de resultados é armazenados em uma variável ’$results.hits.total’, se essa for maior que o ’$size’, então existem ainda resultados que não foram visualizados e, a mesma função ’jump’ utilizada pelo ’Previous’, é chamada ’onclick’, e os ’$size’ resultados posteriores são apresentados ao usuário. A função Javascript ’jump’ se utiliza do HTML DOM Document Object (cite-dom) e retorna o formulário de busca, desse, extrai o ’$start’ e ’$size’ e os ajusta de acordo com o tipo de jump (’Previous’ ou ’Next’), os atualiza no objeto DOM e por fim submete o formulário, que atualiza o conjunto de páginas exibidas. 4.1.3 Utilizando o Dockerfile # Instruções sobre como ’Dockerizar’ a aplicação ip-editor # author: Daniel Guimaraes, <dcguim@example.com> 1) O primeiro passo é realizar o deploy para o Bluemix como descrito na seção objetivos 2) Dentro do contêiner, instale o quicklisp: > sbcl --script inst-ql.lisp 3) O proximo passo é rodar o elasticsearch 3.1) Volte para o dir /home > cd .. 3.2) Rode o makefile (vide 5.1 Dockerfile) > make 3.3) Verifique se o ES está de fato rodando:
  32. 32. Capítulo 4. Especificação do Sistema 32 > curl ’http://localhost:9200/?pretty’ 4) Rode a aplicação lisp 4.1) Inicialize o sistema > sbcl * (load "/home/sys-init.lisp") * (sys-init) 4.2) Inicialize o servidor * (load "/home/set-serv.lisp") * (set-serv) 4.1.4 Dockerfile FROM ubuntu:14.04 MAINTAINER Daniel Guimaraes <dcguim@example.br> # 0) Atualizada o gerenciador de pacotes apt # Instala o nodejs que será responsável pela interface da aplicação # Instala o java e o wget necessários para a instalação do elasticsearch # Instala o compilador sbcl RUN apt-get update && apt-get -y install curl && curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash - && apt-get -y install nodejs && apt-get -y install openjdk-7-jdk && apt-get -y install wget && apt-get -y install sbcl # 1) Na pasta elasticsearch WORKDIR /home/elasticsearch # Instala o elasticsearch e descompacta RUN apt-get install apt-transport-https ca-certificates RUN apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D RUN wget https://download.elastic.co/elasticsearch/ elasticsearch/elasticsearch-2.3.0.deb RUN dpkg -i elasticsearch-2.3.0.deb
  33. 33. Capítulo 4. Especificação do Sistema 33 # 2) Na pasta /home WORKDIR /home # Cria um script lisp que carrega o ASDF e carrega o ip-editor RUN echo "(defun sys-init () (progn (load "/home/quicklisp/asdf.lisp") (ql:quickload :ip-editor)(in-package :ip-editor)))" > sys-init.lisp # Cria um script lisp que configura o servidor na porta 8000 RUN echo "(defun set-serv () (progn (setf *prefix-url* "") (setq hunchentoot:*show-lisp-errors-p* t)(defparameter *auto-refresh-templates* t) (start-server 8000)))" > set-serv.lisp # 3) Na pasta quicklisp WORKDIR /home/quicklisp # Cria o script que instala o quicklisp RUN echo "(load "quicklisp.lisp")(quicklisp-quickstart:install) (ql:system-apropos "vecto")(ql:quickload "vecto")(ql:add-to-init-file) (quit)" > inst-ql.lisp # 4) Baixa o quicklisp RUN curl -O https://beta.quicklisp.org/quicklisp.lisp RUN curl -O https://beta.quicklisp.org/quicklisp.lisp.asc # 5) Na pasta /home WORKDIR /home # Cria o diretório que contém os pacotes quicklisp locais que serão # carregados pelo quickload RUN mkdir /home/quicklisp/local-projects/ # 5.1) Cria um makefile que: #1) cria os links simbólicos do clesc e ip-editor para o quicklisp/local-projects #2) inicia o elasticsearch e carrega os dados #3) instala as dependências bower RUN printf "all:nt/bin/ln -s /home/clesc /home/quicklisp/local-projects/clesc; /bin/ln -s /home/ip-editor/webapp /home/quicklisp/local-projects/ip-editor; /etc/init.d/elasticsearch start; /home/ip-editor/webapp/static/bower install; sh /home/ip-editor/knowledge-bases/planilha/brl.sh; sh /home/ip-editor/knowledge-bases/planilha/brl-log.sh" > makefile # 6) Copia o código da pasta recurso para o conteiner COPY resources/ip-editor/ /home/ip-editor/
  34. 34. Capítulo 4. Especificação do Sistema 34 COPY resources/clesc/ /home/clesc/ COPY resources/asdf.lisp /home/quicklisp
  35. 35. 5 Conclusão 5.1 Controvérsias A definição de ’cloud computing’ não é única e bem definida em toda a comunidade de computação, alguns duvidam não só do termo, mas do be- nefício provido aos consumidores com o aumento de seu emprego atualmente. Richard Stallman, fundador do movimento software livre, do projeto GNU, e da Free Software Foundation, o qual escreveu a primeira versão do Emacs, assim como em 1987 escreveu o GNU Compiler Collection; acredita que ’cloud computing’ é um dos termos que devem ser evitados. Em um artigo publicado na ’https://www.gnu.org/philosophy/’ (cite-gnu-avoid), listou ’cloud compu- ting’ como um termo que merece uma diferenciação da definição utilizada usualmente pelo mercado, de acordo com o GNU, ’cloud computing’ é uma ’buzzword’ criado pelo marketing que não garante nenhum sentido coerente, esse é usado por uma gama de atividades diferentes sendo a única caracterís- tica comum, a utilização da internet para algo além da transmissão de arquivos e por esse motivo, o termo promove confusão. Um dos sentidos de ’cloud com- puting’ é armazenar dado do usuário em serviços online, o qual em muitos cenários, é contrastante com os interesses do consumidor, devido a exposição de seus dados à vigilância do provedor da plataforma. A problemática é ainda desenvolvida na definição de SaaS, de acordo com o GNU (cite-gnu-server), o termo é comumente usado para a instalação de software em um servidor ao invés de oferecer cópias aos usuários, e a princípio acreditava-se que essa descrevia com precisão os casos que esse tipo de problema ocorre. No entanto, o termo ’Software as a Service’ (SaaS) não explica o porque essa prática é prejudicial pois se refere a uma série de práticas e não especifica o serviço provido, o termo SaaS é periodicamente usado para serviços de comunicação, atividades as quais essa problemática não se aplica. Por isso, foi cunhado o termo ’Software as a Service Substitute’ (SaaSS), que define a prática prejudicial do SaaS e aponta o que é prejudicial sobre ela. SaaSS refere a prática de usar um serviço, ao invés de rodar uma cópia de um programa. Concretamente, significa que alguém configura um servidor que
  36. 36. Capítulo 5. Conclusão 36 realiza certas computações (e.g. modificar uma foto, traduzir texto para outra linguagem, entre outros) e convida usuários para realizar computações via esse servidor. Nesse modelo, o usuário envia seus dados para o servidor o qual realiza sua computação com os dados providos e então envia o resultado de volta para o usuário. 5.2 Trabalhos Futuros VMware vSphere Hypervisor (ESXi) é um software destinado a datacen- tros, esse permite a virtualização dos servidores, ajudando a gerência de infra- estrutura de maneira a reduzir o número de servidores necessários para rodar aplicações, termo conheçido como ’consolidação de servidor’. vSphere ajuda na redução de recursos como hardware, energia e refrigeramento. O vSphere client provisiona VMs além de permitir uma sobrecarga dos recursos de hard- ware, otimizando o uso de memória. Quanto a manuntenção, vSphere oferece suporte a migração de VMs entre servidores vCenter além de APIs específicas para backups. Cloud Foundry oferece uma plataforma como serviço (PaaS), elaborada para ser configurada, despachada, gerenciada, escalada e atualizada sobre qualquer provedor de infraestrutura como serviço (IaaS), como por exemplo o vSphere, descrito acima como um exemplo de IaaS. Para realizar o ’deploy’ do Cloud Foundry é necessário usar BOSH (BOSH outer shell), essa ferramenta, também ’open-source’, permite desenvolvedores e times o fácil versionamento, empacotamento e ’deploy’ de software de uma maneira reprodutível. Qualquer software, independente da sua complexidade, precisa ser atu- alizado e reempacotado em algum momento. Esse software atualizado preci- sará ser despachado para algum cluster, ou empacotado para usuários finais despacharem para seus próprios servidores. Versionar, empacotar e despachar software de maneira reprodutível são problemas que o BOSH, assim como o Docker pretendem resolver. Nesse contexto, é preciso definir um lançamento ou ’release’ como uma coleção de propriedades de configuração, templates de configuração, scripts de inicialização, código fonte, binários e qualquer outro arquivo necessário para construir e despachar software de uma maneira re- produtível. Há quatro princípios de ’Release Engineering’ que o BOSH foi desenvolvido para resolver: • Identificabilidade: A capacidade de identificar todos as fontes, ferramentas, ambientes e outros componentes que compõem um lançamento particu- lar.
  37. 37. Capítulo 5. Conclusão 37 • Reprodutibilidade: A capacidade de integrar fontes, componentes de tercei- ros, dados e externalidades de despacho de um sistema de software de maneira a garantir establidade de operação. • Consistência: A missão de provêr um ’framework’ estável para o desenvolvi- mento, despacho, auditoria e confiabilidade de componentes de software. • Agilidade: pesquisa recente sobre as repercussões das praticas modernas de engenharia de software na produtividade do ciclo de software, i.e. integração contínua. Dessa forma, Docker não é a única ferramenta que resolve os problemas de ’Release Engineering’, o BOSH também atua nessa área e deve ser investigado para que as duas tecnologias sofram comparações pautadas nesses princípios de ’Release Engineering’. Não é preciso realizar a assinatura de serviços como o Bluemix, é possível virtualizar uma aplicação através do Cloud Foundry e manter esse ambiente estável e transparente rodando no hardware do desenvolvedor. Como trabalho futuro, seria interessante rodar o bosh-lite (cite-bosh-lite) sobre vSphere Hypervisor (ESXi). Dessa forma, será possível utilizar a interface do Cloud Foundry como no IBM Bluemix sem pagar pela sua assinatura (cite-run-bosh-vsphere).
  38. 38. Referências Bibliográficas [cite-Log4J] MIKHANOSHA, M.. Common lisp logging framework, mo- deled after log4j. https://github.com/7max/log4cl. [cite-NIST-definition] GRANCE, P. M. . T.. The nist definition of cloud computing. http://dx.doi.org/10.6028/NIST.SP.800. [cite-alexandria] MARCO BARINGER, ATTILA LENDVAI, N. S. R. S.. Com- mon lisp logging framework, modeled after log4j. https:// common-lisp.net/project/alexandria/. [cite-architecture-image] INC, D.. Architecture. https://docs.docker. com/v1.11/engine/article-img/architecture.svg. [Online; accessed August 12, 2016]. [cite-asdf] BARLOW, D.. ASDF Manual, 3 edition. [cite-bosh-lite] FOUNDATION, C. F.. Bosh lite. https://github.com/ cloudfoundry/bosh-lite. [cite-bower] TWITTER, I.. Bower - a package manager for the web. https://bower.io/. [cite-cfoundry@ibm] SINGH, A.. Cloud foundry on opens- tack at ibm. http://www.altoros.com/blog/ cloud-foundry-on-openstack-at-ibm/. [cite-cl-fad] WEITZ, E.. Cl-fad - a portable pathname library for com- mon lisp. [cite-clesc] CHALUB, F.. Clesc - common lisp elasticsearch client. https: //github.com/own-pt/clesc. [cite-closure-template] MOSKVITIN, A.. cl-closure-template. https:// github.com/archimag/cl-closure-template. [cite-docker-architecture] INC, D.. Understand the architecture. https: //docs.docker.com/v1.11/engine/understanding-docker/.
  39. 39. Referências Bibliográficas 39 [cite-dom] W3SCHOOL. The html dom document object. http://www. w3schools.com/jsref/dom_obj_document.asp. [cite-drakma] WEITZ, E.. Drakma - a common lisp http client. http: //weitz.de/drakma/#abstract. [cite-elastic-guide] BV, E.. You know, for search... https://www.elastic. co/guide/en/elasticsearch/guide/current/intro.html. [cite-gnu-avoid] STALLMAN, R.. Words to avoid (or use with care) because they are loaded or confusing. https://www.gnu.org/ philosophy/words-to-avoid.html. [cite-gnu-server] STALLMAN, R.. Who does that server serve? https: //www.gnu.org/philosophy/who-does-that-server-really-serve. html.en. [cite-hunchentoot] WEITZ, E.. Hunchentoot - the common lisp web server formely known as tbnl. http://weitz.de/hunchentoot/ #abstract. [cite-hypervisorbased-image] KARLE, A.. Hypervisor based virtuali- zation. https://risingstack-blog.s3-eu-west-1.amazonaws.com/ 2015/05/hypervisor-based-virtualization.jpg. [Online; accessed August 12, 2016]. [cite-local-time] NAGGUM, E.. Local-time. https://common-lisp.net/ project/local-time/. [cite-osbased-image] KARLE, A.. Os virtualization. https: //risingstack-blog.s3-eu-west-1.amazonaws.com/2015/05/ os-virtualization.jpg. [Online; accessed August 12, 2016]. [cite-oscontainerXappconteiner] KARLE, A.. Operating system contai- ners vs. application containers. https://blog.risingstack.com/ operating-system-containers-vs-application-containers/. [cite-practical-cl] SEIBEL, P.. Practical Common Lisp. Apress, 2005. [cite-reuters] KURANE, A. S. . S.. Cisco joins cloud computing race with 1 billion plan. http://www.reuters.com/article/ us-cisco-systems-cloudcomputing-idUSBREA2N09T20140324.
  40. 40. Referências Bibliográficas 40 [cite-run-bosh-vsphere] BUDNACK, J. R.. Running bosh-lite on vsphere hypervisor free edition. http://www.starkandwayne.com/blog/ running-bosh-lite-on-vsphere-hypervisor-free-edition/. [cite-software-make] FOUNDATION, F. S.. Gnu make. https://www.gnu. org/software/make/. [cite-split-sequence] IONESCU, S.. Split-sequence. https://github.com/ sharplispers/split-sequence. [cite-ssl] CORP, S.. What is ssl? info.ssl.com/article.aspx?id=10241. [cite-vmware-definition] VMWARE. Vmware vsphere and virtualizing the it infrastructure. https://pubs.vmware.com/vsphere-50/ index.jsp?topic=%2Fcom.vmware.vsphere.introduction.doc_50% 2FGUID-D1F38E4C-9B06-4688-9FE3-D466B07A22A0.html. [cite-whatis-bosh?] BOSH, C.. What is bosh? https://bosh.io/docs/ about.html. [citeart-deploymodels] GOYAL, S.. Public vs private vs hybrid vs commu- nity - cloud computing: A review. 2014. [citeart-docker] BOETTIGER, C.. An introduction to docker for reprodu- cible research, with examples from the r enviroment. 1(2):3–4, 10 2014. [citeart-local-time] NAGGUM, E.. The long, painful history of time. 1999.

×