UM MODELO PARA DISPONIBILIZAÇÃO DE PESQUISAS ...‡… · Catalogação na fonte Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217 C331m Carvalho, Sandro Marques de

Pós-Graduação em Ciência da Computação

SANDRO MARQUES DE CARVALHO

UM MODELO PARA DISPONIBILIZAÇÃO DE

PESQUISAS COMPUTACIONAIS E SEUS

ARTEFATOS EM CONTÊINERES DE SOFTWARE

EM NUVEM

Universidade Federal de Pernambuco [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE 2017

Sandro Marques de Carvalho

Um Modelo para Disponibilização de Pesquisas Computacionais e seus Artefatos em Contêineres de Software em Nuvem

ORIENTADOR(A): Prof. Fernando da Fonseca de Souza

RECIFE 2017

Este trabalho foi apresentado à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre Profissional em Ciência da Computação.

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

C331m Carvalho, Sandro Marques de

Um modelo para disponibilização de pesquisas computacionais e seus artefatos em contêineres de software em nuvem / Sandro Marques de Carvalho. – 2017.

101 f.: il., fig., tab. Orientador: Fernando da Fonseca de Souza. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,

Ciência da Computação, Recife, 2017. Inclui referências.

1. Engenharia de software. 2. Computação em nuvem. I. Souza, Fernando da Fonseca (orientador). II. Título. 005.1 CDD (23. ed.) UFPE- MEI 2018-035

Sandro Marques de Carvalho

Um Modelo para Disponibilização de Pesquisas Computacionais e seus Artefatos em Contêineres de Software em Nuvem

Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal de Pernambuco, como requisito parcial para a obtenção do título de Mestre Profissional em 20 de dezembro de 2017.

Aprovado em: 20/12/2017.

BANCA EXAMINADORA

______________________________________________ Prof.Fernando da Fonseca de Souza

Centro de Informática / UFPE (Orientador)

__________________________________________ Prof. Rodrigo Lins Rodrigues

Universidade Federal Rural de Pernambuco

__________________________________________ Prof. José Gilson de Almeida Teixeira Filho

Centro de Ciências Sociais Aplicadas / UFPE

Este trabalho é dedicado aos meus pais José e Audenora, meus irmãos Fábio e

Sinesio, minha esposa Anne Kelly, meu filho Ícaro e meu sobrinho Victor.

A minha "voinha" Maria (in memorian). Viveu seus dias como exemplo de

simplicidade. Hoje é carinhosamente lembrada por todos os familiares e amigos.

A minha professora Aline Andrade (in memorian). Pela dedicação, por ter sido

exemplo de vida e por todo o legado deixado. Hoje é saudosa e eternamente

lembrada por todos os ex-alunos, professores, amigos e familiares.

AGRADECIMENTOS

Este é um momento muito especial na minha vida e gostaria de agradecer

a todos que seguiram ao meu lado.

A Deus, em primeiro lugar, por permitir mais esta conquista, me dando

força, coragem, paciência e saúde.

À minha esposa, Anne Kelly, pela paciência de esperar o meu tempo

durante esta batalha, pelo companheirismo, pelo amor e por sempre estar ao

meu lado, me apoiando em meus projetos de vida.

Ao meu filho, Ícaro, que da maneira dele entendeu um pouco da minha

ausência durante estes anos. Todo este sacrifício foi pensando sempre num

futuro melhor para ele, pois quero deixar o meu legado e exemplo de pai.

Aos meus pais, José e Audenora, por serem meus maiores incentivadores

e por nunca terem medido esforços para me oferecer sempre o melhor. A vocês

devo tudo o que sou hoje.

Aos meus irmãos, Fábio e Sinesio, por todo apoio e força que me dão e por

torcerem sempre por mim.

Ao Professor Fernando, muito obrigado pela paciência, compreensão,

orientação, ideias, conversas e confiança compartilhadas ao longo destes anos.

Aos membros da banca, Prof. Gilson e Prof. Rodrigo, pelo aceite e

disponibilidade de tempo nesta época tão atribulada.

Aos colegas do MPROF2014Sistemas, por dividir as lutas, frustrações e

alegrias desses últimos anos.

Ao IF SERTÃO-PE e aos amigos e colegas de trabalho desta instituição, os

quais incentivaram e colaboraram para que esta conquista pudesse acontecer.

Enfim, a todas as pessoas, colegas, amigos e familiares, que direta ou

indiretamente, contribuíram para esta conquista, o meu MUITO OBRIGADO!

RESUMO

No geral, reproduzir resultados de pesquisas científicas é uma tarefa árdua,

especialmente percebida por estudantes de pós-graduação. Em um contexto

educacional, de formação para a pesquisa, as dificuldades e os problemas

enfrentados pelos estudantes e pesquisadores para reproduzir os resultados

gerados por pesquisas científicas estão relacionados, principalmente, à falta de

subsídios necessários para a reprodução dos resultados obtidos a partir dos

artigos científicos. Na mitigação disso, a Pesquisa Reprodutível é uma técnica

que sistematiza boas práticas na pesquisa científica em computação. Diante do

exposto, este trabalho apresenta um modelo de arquitetura para disponibilização

de pesquisas computacionais e seus artefatos em contêineres de software em

nuvem, de modo a permitir a reprodutibilidade de pesquisas na área de Ciência

da Computação, o qual se utiliza do conhecimento do pesquisador sobre a sua

pesquisa para definir quais artefatos necessitam ou não de publicação e

compartilhamento. O objetivo é disponibilizá-lo para acesso público. Foram

utilizadas as tecnologias de contêineres Docker e a computação em nuvem como

plataformas-base para a concepção da abordagem. Um protótipo foi

desenvolvido com a finalidade de avaliar por meio de um estudo de caso o

modelo de arquitetura criado. Como resultado, verificou-se que o modelo de

arquitetura aqui proposto se diferencia dos demais, a princípio pelo fato de

impactar minimamente no modo de trabalho do pesquisador, poupando-lhe

esforços para tornar pública a sua pesquisa. E também por estar mais próximo

ao padrão desejado na escala de avaliação quando comparado às outras

abordagens.

Palavras-chave: Pesquisa Reprodutível. Artefatos de Pesquisa. Contêineres de

Software. Docker. Computação em Nuvem.

ABSTRACT

Replicating scientific research results is very often an arduous task,

especially as far as graduate students are concerned. In an educational context,

considering research training, difficulties and problems faced by students and

researchers to reproduce the results generated by scientific research are mainly

related to the lack of necessary subsidies for the reproduction of the results

obtained from scientific articles. In order to mitigate this, Reproducible Research

is a technique that systematizes good practices in scientific research in

computation. Bearing in mind the above, this work presents a architecture model

for the provision of computational research and its artifacts in software containers

in the cloud, in order to allow the reproducibility of researches in the area of

Computer Science. This proposed solution uses the researchers knowledge to

define which artifacts need publication and sharing. The goal is to make it

available for public access. Docker container technologies and cloud computing

were used as the basis platforms for designing the approach. A prototype was

developed with the purpose of evaluating by means of a case study the

architecture model created. As a result, it was verified that the architecture model

proposed here differs from others, initially because it minimally impacts the

researcher's way of working, saving him efforts to make his research public.

Furthermore, it is closer to the desired standard in the evaluation scale when

compared to the other approaches.

Keywords: Reproducible Research. Research Artifacts. Software Containers.

Docker. Cloud Computing.

LISTA DE FIGURAS

Figura 1.1 - Fluxo de Atividades Executado para Realização da Pesquisa. ............. 19

Figura 2.1 - Espectro da Reprodutibilidade. .............................................................. 22

Figura 2.2 - Proposta de Mapa Conceitual para a Pesquisa Reprodutível. ............... 28

Figura 2.3 - Características Essenciais da Computação em Nuvem. ........................ 32

Figura 2.4 - Modelos de Serviço da Computação em Nuvem. .................................. 35

Figura 2.5 - Modelos de Implantação da Computação em Nuvem. ........................... 37

Figura 3.1 - Processo de Criação de um Pacote Reprozip. ...................................... 45

Figura 3.2 - Proposta de Arquitetura de Reprodução de Experimentos do AMOS.... 49

Figura 4.1 - Elementos Envolvidos numa Pesquisa Reprodutível. ............................ 54

Figura 4.2 - Arquitetura do Modelo Proposto............................................................. 56

Figura 4.3 - Etapas e Ambientes Envolvidos na Arquitetura do Modelo Proposto. ... 58

Figura 4.4 - Processo de Criação de uma Nova Imagem Docker. ............................ 61

Figura 4.5 - Estrutura Recomendada para o Diretório da Pesquisa. ......................... 62

Figura 4.6 - Conteúdo do Arquivo Dockerfile............................................................. 63

Figura 4.7 - Conteúdo do Arquivo docker-compose.yml. .......................................... 63

Figura 4.8 - Arquivo com Exemplo de Credenciais de Acesso ao Serviço da AWS. . 66

Figura 4.9 - Diagrama de Casos de Uso - Ator: Pesquisador.................................... 68

Figura 5.1 - Fluxo de Processo do Modelo de Arquitetura Proposto. ........................ 73

Figura 5.2 - Total de Conexões Criadas no Dropbox. ............................................... 75

Figura 5.3 - Documento Final e Artefatos da Pesquisa no Dropbox. ......................... 76

Figura 5.4 - Tela de Compartilhamento da Pesquisa no Dropbox. ............................ 77

Figura 5.5 - Dados Estatísticos Apresentados pelo GitHub. ..................................... 78

Figura 5.6 - Tela de Cadastro da Pesquisa no GitHub. ............................................. 78

Figura 5.7 - Tela de Inclusão dos Artefatos e Documento da Pesquisa no GitHub. .. 79

Figura 5.8 - Tela de Acesso à Pesquisa Completa no GitHub. ................................. 80

Figura 5.9 - Dados Estatísticos Apresentados pelo Docker. ..................................... 81

Figura 5.10 - Ambiente em Execução via Interface de Linha de Comando. .............. 82

Figura 5.11 - Ambiente em Execução via Interface Gráfica. ..................................... 83

Figura 5.12 - Imagens Docker com a Pesquisa Completa Encapsulada. .................. 84

Figura 5.13 - Espectro da Reprodutibilidade em Escala. .......................................... 86

LISTA DE QUADROS

Quadro 2.1 - Comparativo entre os Modelos de Implantação de Nuvem. ................. 37

Quadro 3.1 - Comparativo entre os Trabalhos Relacionados. .................................. 50

Quadro 5.1- Quadro Demonstrativo da Análise das Questões do Estudo. ............... 85

SUMÁRIO

1. INTRODUÇÃO ............................................................................................... 12

1.1. Motivação ...................................................................................................... 14

1.2. Justificativa ................................................................................................... 15

1.3. Pergunta de Pesquisa .................................................................................. 17

1.4. Objetivos ....................................................................................................... 17

1.4.1. Geral ............................................................................................................... 17

1.4.2. Específicos ..................................................................................................... 17

1.5. Contribuições Esperadas ............................................................................. 17

1.6. Metodologia ................................................................................................... 18

1.7. Organização do Trabalho ............................................................................. 20

2. FUNDAMENTAÇÃO TEÓRICA ..................................................................... 21

2.1. Pesquisa Reprodutível em Computação .................................................... 21

2.1.1. Vantagens ....................................................................................................... 25

2.1.2. Desvantagens ................................................................................................. 26

2.1.3. Licenciamento ................................................................................................. 28

2.2. Computação em Nuvem ............................................................................... 31

2.2.1. Características Essenciais .............................................................................. 32

2.2.2. Modelos de Serviço ........................................................................................ 34

2.2.3. Modelos de Implantação ................................................................................. 35

2.2.4. Service Level Agreements (SLA) .................................................................... 38

2.2.5. Pesquisa Reprodutível com a Infraestrutura em Nuvem................................. 39

2.3. Considerações Finais do Capítulo .............................................................. 43

3. TRABALHOS RELACIONADOS ................................................................... 44


4. A ABORDAGEM PROPOSTA ....................................................................... 51

4.1. Definição Geral da Abordagem ................................................................... 52

4.2. Arquitetura .................................................................................................... 56

4.3. Preparação do Ambiente .............................................................................. 60

4.3.1. Diferença entre Imagem e Contêiner .............................................................. 61

4.3.2. Estrutura de Diretórios e Arquivos de Configuração ....................................... 62

4.3.3. Contêiner Web ................................................................................................ 64

4.3.4. Contêiner de Banco de Dados ........................................................................ 65

4.3.5. Contêiner de Aplicação ................................................................................... 65

4.4. Execução do Ambiente na Nuvem .............................................................. 66

4.5. Principais Atividades.................................................................................... 67


5. UM ESTUDO DE CASO PARA AVALIAÇÃO DA ABORDAGEM ................. 70

5.1. Introdução ..................................................................................................... 70

5.2. Planejamento ................................................................................................ 71

5.2.1. Objetivos ......................................................................................................... 71

5.2.2. Questões do Estudo ....................................................................................... 71

5.2.3. Contexto de Aplicação .................................................................................... 72

5.2.4. Protocolo e Instrumentos ................................................................................ 72

5.3. Desenvolvimento do Estudo de Caso ......................................................... 74

5.3.1. Execução no Dropbox..................................................................................... 75

5.3.2. Execução no GitHub ....................................................................................... 77

5.3.3. Execução no Modelo de Arquitetura Proposto ................................................ 80

5.4. Análise e Resultados .................................................................................... 85


6. CONCLUSÕES .............................................................................................. 89

6.1. Principais Contribuições .............................................................................. 90

6.2. Limitações ..................................................................................................... 91

6.3. Trabalhos Futuros ........................................................................................ 92

6.4. Produção Bibliográfica ................................................................................. 93

REFERÊNCIAS .............................................................................................. 94

12

1. INTRODUÇÃO

A reprodutibilidade dos resultados é considerada um fator primordial na ciência.

O sucesso e a credibilidade de uma pesquisa estão ancorados na vontade dos

cientistas de expor suas ideias e resultados a testes independentes e replicação

por outros cientistas. Isso requer uma completa abertura dos dados,

procedimentos e materiais (FOMEL e CLAERBOUT, 2009).

Os dados e informações sobre o desenvolvimento de uma Pesquisa

Reprodutível (Reproducible Research - RR) ajudam a descrever os resultados e

o protocolo científico, auxiliando na repetição e reprodução de um experimento

(MESIROV, 2010). Goble (2012) enfatiza a importância da pesquisa reprodutível

definindo que a reprodução é o princípio do método científico, que auxilia no

processo de comparação e revisão de métodos empregados e resultados

alcançados, verificando se estes estão corretos, e se o método é convincente e

repetível. Além disso, para que um experimento seja válido sob o ponto de vista

científico, o seu resultado deve ser passível de reprodução por terceiros.

A capacidade de reprodução dos experimentos científicos envolve todos os

artefatos e elementos usados para a derivação dos resultados. Porém, para

permitir a reprodução é necessário ainda prover ao cientista o acesso ao

conjunto de dados, infraestrutura, plataforma de software, parâmetros de

configuração necessários para a execução de um experimento de forma simples

e conveniente, com mínimo esforço possível e com poder computacional

necessário (KLINGINSMITH et al., 2011).

Diversas conferências e periódicos de prestígio internacional têm atribuído

mais relevância à pesquisa reprodutível, tanto que suas políticas para publicação

de artigos estão sendo revistas com a intenção de exigir cada vez mais a

disponibilização de artefatos que auxiliem a reprodução das pesquisas.

Concomitantemente, nos últimos anos, uma área de estudo da Tecnologia

da Informação tem se destacado: a computação em nuvem. Segundo a definição

do National Institute of Standards and Technology (NIST), a computação em

nuvem é um modelo que permite o acesso onipresente, conveniente e sob

13

demanda a um conjunto de recursos computacionais configuráveis por meio de

uma rede de computadores, permitindo que tais recursos possam ser

rapidamente fornecidos e liberados com o mínimo esforço de gerenciamento e

interação com o fornecedor do serviço (MELL e GRANCE, 2011).

Esse modelo foi concebido para fornecer recursos de forma flexível,

altamente escalável e sob demanda. Nele, o provedor é o detentor do recurso e o

concede conforme a necessidade do usuário. Ademais, o pagamento é realizado

de acordo com a quantidade de recursos alocados, a qual é medida de acordo

com o tipo de serviço oferecido (data center, hardware e software).

A computação em nuvem é fundamentada em quatro tecnologias

(ARMBRUST et al., 2010; VAQUERO et al., 2009): grade computacional,

computação de utilidade, virtualização de recursos e arquitetura orientada a

serviços. Em especial, a virtualização do ambiente permite que vários recursos

de hardware e software sejam gerenciados na forma de um pool de recursos. Na

virtualização, um computador físico pode acomodar diversos computadores

lógicos, denominados máquinas virtuais (SMITH e NAIR, 2005).

De acordo com Yu (2007), a virtualização no nível de sistema operacional é

definida como a existência de múltiplas instâncias isoladas de espaços de

usuário (ao invés de apenas uma), que são gerenciadas pelo kernel desse

sistema. Estas instâncias, chamadas de contêineres de software (ou

simplesmente contêineres), representam todo um ambiente de execução: uma

aplicação, juntamente com as suas dependências, bibliotecas e arquivos de

configuração, agrupados em um único "pacote". Ao criar um contêiner de uma

determinada aplicação e suas dependências, a diversidade de sistemas

operacionais e infraestruturas subjacentes são abstraídas.

Segundo Romero (2015), Docker é uma ferramenta para criar e manter

contêineres, ou seja, ela é responsável por armazenar vários serviços de forma

isolada do Sistema Operacional (SO) host, como: web server, banco de dados,

aplicação, memcached, entre outros. O seu back-end é baseado em LXC (LinuX

Containers) (MERKEL, 2014).

14

Ainda conforme Romero (2015), LXC funciona isolando processos do SO

host. É uma espécie de virtualização bastante leve, pois não faz uso de

emulação ou suporte a hardware, apenas proporciona a execução de vários

sistemas Linux de forma isolada, daí vem a palavra contêiner. Além disso, ele

utiliza o mesmo Linux Kernel do servidor host, o que torna tudo muito rápido.

Em outras palavras, o Docker é uma alternativa para virtualização completa

e leve se comparada a Máquinas Virtuais (Virtual Machines - VM). No entanto,

conforme Rubens (2015), contêineres e VM podem ser vistas entre si como

tecnologias complementares ao invés de competitivas. Isso se deve ao fato de

ser possível executar vários contêineres em uma VM.

Diante disso, a seção seguinte apresenta a motivação para o

desenvolvimento do presente trabalho.

1.1. Motivação

Na pesquisa em Computação é bastante comum encontrar artigos que, em

suma, transformam dados brutos em resultados computacionais a serem

publicados. Para isso, os pesquisadores fazem uso de software, que em muitos

casos é desenvolvido apenas para solucionar o problema desejado. Em uma

análise apurada, percebem-se diversos problemas no código fonte do software.

Dentre os principais problemas: falta de documentação, poucos ou nenhum

comentário, nomes de métodos, funções e variáveis inadequados e problemas

de identação (Barnes, 2010).

Programas escritos por pesquisadores podem ser desde pequenos scripts,

desenvolvidos para automatizar tarefas, plotar gráficos e tabelas, realizar

processamento matemático e estatístico e dar suporte a diversos tipos de

simulações, até grandes rotinas para processar e filtrar dados das mais

complexas formas.

Com frequência, essas soluções são desenvolvidas de forma tão obscura,

que após a publicação dos resultados, elas são simplesmente esquecidas ou

deletadas, fato esse que justifica a não divulgação do código fonte do software

15

por parte dos pesquisadores (Barnes, 2010). Mesmo quando se consideram

pesquisadores com familiaridade em ferramentas e técnicas de desenvolvimento

de software, a situação se mantém. Erros em software são bastante comuns

(valores nulos, erros de conversão de dados), mas que sua detecção e correção

são prejudicadas pela falta de acesso ao código fonte (Morin et al., 2012).

Assim, uma abordagem baseada na hipótese de que é possível fazer a

portabilidade de pesquisas computacionais e seus artefatos para a infraestrutura

da nuvem, utilizando a tecnologia de contêineres Docker, destaca-se como

possibilidade de gerar promissores resultados para a pesquisa em Ciência da

Computação e áreas afins.

Tal abordagem possibilita um maior nível de acesso e compartilhamento

dos artefatos usados na produção dos resultados para o público em geral. Para

tanto, as pesquisas computacionais poderiam ser transformadas em imagens

Docker para serem publicadas e compartilhadas em um provedor de nuvem

pública, permitindo aos interessados explorar e reproduzir as pesquisas na

infraestrutura da nuvem.

A referida infraestrutura traz a possibilidade de acesso a recursos

especiais, tais como: ambiente de computação de alto desempenho e ambiente

de armazenamento das imagens e de execução dos contêineres Docker,

tratando-os como unidades de compartilhamento das pesquisas. O

armazenamento da infraestrutura na nuvem permite ainda manter o repositório

de pesquisas, eliminando a necessidade de tarefas de manutenção de um centro

de dados, pois os acordos de serviços englobam fatores de qualidade de serviço

(Quality of Service - QoS), tais como disponibilidade, controle de falhas da

estrutura e serviços de backup.

A próxima seção apresenta a justificativa para a concepção deste trabalho.

1.2. Justificativa

Em um contexto educacional, de formação para a pesquisa, as dificuldades e os

problemas enfrentados pelos estudantes e pesquisadores para reproduzir os

16

resultados gerados por pesquisas científicas estão relacionados, principalmente,

à falta de subsídios necessários para a reprodução dos resultados obtidos a

partir dos artigos científicos. Segundo Donoho (2010), tais resultados são

apresentados de forma pouco convincente em periódicos, conferências e livros,

devido na maioria das vezes às limitações impostas pelo formato dessas mídias.

Na pesquisa reprodutível, o produto final de uma publicação não é apenas

o artigo científico, mas todos os objetos necessários para a sua produção. Em

geral, uma pesquisa reprodutível é composta pelo conjunto de dados de entrada,

software, bibliotecas, parâmetros de configuração, workflow científico, Sistemas

de Gerência de Workflow Científico (SGWfC), hardware e infraestrutura em geral

utilizados para a execução de um experimento. O esforço necessário para limpar

e documentar os objetos de pesquisa para prepará-los para a reutilização é uma

das maiores barreiras para o compartilhamento de uma pesquisa

(VANDEWALLE, 2012; LEVEQUE, 2009).

Mediante essas afirmações, mostra-se latente a necessidade de investigar

e explorar novas opções para publicação e compartilhamento de uma pesquisa,

cuja adoção impacte minimamente no modo de trabalho do pesquisador.

Partindo do princípio de que a ciência é universal, ou seja, deve ser

acessível de forma livre a todos, esse mesmo princípio foi aplicado na

concepção deste trabalho, incentivando a prática da pesquisa computacional e

contribuindo com a educação no contexto da formação de pesquisadores. Para

tanto, este trabalho foi desenvolvido para tratar as questões relacionadas à

disponibilização de pesquisas computacionais e seus artefatos em contêineres

Docker na infraestrutura de computação em nuvem.

Desta forma, será apresentada, na seção seguinte, a pergunta de pesquisa

do presente trabalho, que trata exatamente do problema da escassez de

trabalhos científicos publicados juntamente com seus artefatos.

17

1.3. Pergunta de Pesquisa

Diante do exposto anteriormente, a seguinte pergunta de pesquisa foi formulada:

Como disponibilizar pesquisas computacionais e seus artefatos em

contêineres de software em nuvem a fim de permitir o acesso público?

1.4. Objetivos

Para responder à pergunta de pesquisa, foram definidos os seguintes objetivos,

divididos em geral e específicos:

1.4.1. Geral

Propor um modelo de arquitetura para disponibilização de pesquisas

computacionais em contêineres de software na infraestrutura de computação em

nuvem, no qual o pesquisador possa tomar decisões sobre quais artefatos

publicar e compartilhar.

1.4.2. Específicos

Definir um modelo de arquitetura apropriado ao contexto de nuvem

pública para suporte à Pesquisa Reprodutível;

Desenvolver um protótipo com um mecanismo que implemente o

modelo;

Avaliar o mecanismo por meio de um estudo de caso; e

Disponibilizar o modelo proposto e avaliado para acesso público.

1.5. Contribuições Esperadas

Espera-se, ao final deste trabalho, alcançar as seguintes contribuições:

Apresentação de um estudo abrangente dos temas: Pesquisa

Reprodutível, Computação em Nuvem e Contêineres de Software

18

(Docker), de modo a facilitar o desenvolvimento de futuros trabalhos

envolvendo esses tópicos;

Desenvolvimento de um modelo de arquitetura que explore os

diferentes níveis de publicação e compartilhamento de trabalhos

científicos juntos aos seus artefatos, conforme crítica de Donoho

(2010); e

Apoio a laboratórios, grupos de pesquisa, estudantes e

pesquisadores interessados em realizar Pesquisa Computacional

Reprodutível.

1.6. Metodologia

A pesquisa, no contexto científico, pode ser classificada de acordo com

diferentes critérios. Entre eles, é possível diferenciar tipos de pesquisa de acordo

com sua natureza, objetivos ou procedimentos técnicos. Nem sempre um

trabalho de pesquisa limita-se a um único tipo. Além disso, alguns tipos de

pesquisa podem ser a base para outros (WAZLAWICK, 2014). Para isso,

apresenta-se, a seguir, a classificação desta pesquisa.

Esta pesquisa pode ser classificada como exploratória e aplicada. A

pesquisa exploratória visa conhecer inicialmente o tema de estudo. Pois,

segundo Pinheiro (2010), a pesquisa exploratória visa proporcionar maior

familiaridade com o problema com vistas a torná-lo explícito ou a construir

hipóteses. Neste trabalho, foi realizada por meio da revisão da literatura.

A pesquisa aplicada, por sua vez, é a pesquisa de finalidade prática

(KAHLMEYER-MERTENS et al., 2007). Este trabalho engloba a definição de um

modelo de arquitetura, o desenvolvimento de um protótipo e sua respectiva

avaliação para solucionar um problema real.

Portanto, para produzir o referencial teórico desta pesquisa foram

realizadas consultas em livros conceituados relacionados aos temas em

19

discussão, a saber: Pesquisa Reprodutível, Computação em Nuvem e

Contêineres de Software (Docker). Adicionalmente, foram consultados artigos

disponíveis em bibliotecas científicas, tais como Association for Computing

Machinery (ACM)1, Institute of Electrical and Electronic Engineers (IEEE Xplore)2

e Scientific Eletronic Library Online (SciELO)3, explorando, especialmente, artigos

publicados nos últimos cinco anos.

Juntamente à revisão de literatura, foi realizado um estudo a fim de analisar

trabalhos a este relacionados. A revisão de literatura somada a esse estudo

permitiu conhecer mais profundamente os temas em questão, possibilitando a

compreensão de seus conceitos e da sua atual conjuntura.

De posse desses conhecimentos, foram levantadas as funcionalidades do

modelo de arquitetura proposto, levando em consideração os objetivos acima

descritos, para concepção do protótipo e implementação da proposta. Por fim, o

protótipo foi testado por meio de um estudo de caso e as suas capacidades

verificadas.

O fluxo de atividades pode ser resumido de acordo com a Figura 1.1:

Figura 1.1 - Fluxo de Atividades Executado para Realização da Pesquisa.

Fonte: Elaborada pelo Autor (2017).

1 http://dl.acm.org

2 http://ieeexplore.ieee.org

3 http://www.scielo.org

Produzir a Fundamentação

Teórica

Analisar os Trabalhos

Relacionados

Levantar as Funcionalidades

do Modelo de Arquitetura Proposto

Implementar o Protótipo que

Execute o Modelo de Arquitetura

Avaliar o Protótipo por meio de um

Estudo de Caso

20

1.7. Organização do Trabalho

Neste capítulo, foi realizada uma breve introdução aos temas deste trabalho:

Pesquisa Reprodutível, Computação em Nuvem e Contêineres de Software

(Docker). Além disso, foram apresentadas a motivação e justificativa para a sua

realização. Ainda neste capítulo, a pergunta de pesquisa foi apresentada, bem

como os objetivos geral e específicos para responder à pergunta de pesquisa,

foram destacadas as contribuições esperadas e foi descrita a metodologia

utilizada.

O restante do trabalho está organizado da seguinte forma:

Capítulo 2 - Fundamentação Teórica: Expõe o referencial teórico e

aborda de forma mais abrangente os temas: Pesquisa Reprodutível,

Computação em Nuvem e Contêineres de Software (Docker);

Capítulo 3 - Trabalhos relacionados: Discorre e compara os

trabalhos relacionados a este;

Capítulo 4 - Abordagem Proposta: Apresenta a proposta deste

trabalho, discutindo as etapas envolvidas na sua concepção e

descreve os detalhes de implementação do protótipo;

Capítulo 5 - Um Estudo de Caso para Avaliação da Abordagem:

Descreve a avaliação realizada na abordagem por meio de um

estudo de caso, bem como a análise dos resultados;

Capítulo 6 - Conclusões: Expõe as considerações finais sobre esta

pesquisa, destacando as contribuições, comentando as limitações e

sugerindo direcionamentos para trabalhos futuros; e

Por fim, são destacadas as referências utilizadas na composição da

revisão de literatura e na pesquisa.

21

2. FUNDAMENTAÇÃO TEÓRICA

A seguir, serão abordados, com apoio da literatura pesquisada, os principais

temas que formam a base teórica deste trabalho: Pesquisa Reprodutível em

Computação, Computação em Nuvem e Contêineres de Software (Docker).

2.1. Pesquisa Reprodutível em Computação

Como a ciência está se tornando cada vez mais digital, o uso da tecnologia tem

acelerado o seu desenvolvimento, aumentando a eficiência e a eficácia no

processo de produção e análise de dados. Entretanto, esse desenvolvimento

vem acompanhado de uma produção massiva de dados gerados por um conjunto

crescente de experimentos computacionais. Ao mesmo tempo aumentam os

desafios para o desenvolvimento de abordagens que permitam a

reprodutibilidade das pesquisas.

A busca pela pesquisa reprodutível em computação teve início na década

de 90 (noventa) com a exigência de que artigos de geofísica, publicados na

Stanford Exploration Project4, fossem acompanhados de todos os arquivos de

construção de código (SCHWAB et al., 2000) por meio de arquivos makefiles

(STALLMAN e MCGRATH, 2002).

A ISO/DTS 21748:20175 apresenta os conceitos de repetição e

reprodução. Fomel e Claerbout (2009) também conceituam e definem como duas

classes distintas, a repetição e a reprodução. A repetição usa os mesmos

processos, dados e demais artefatos de forma equivalente ao experimento

original publicado, sem qualquer modificação dos elementos. A reprodução

repete o experimento, porém, possibilitando variações no valor ou uso de um ou

mais artefatos. A diferença básica entre os dois conceitos está relacionada com

as condições experimentais.

4 http://sepwww.stanford.edu

5 https://www.iso.org/standard/71615.html

A repetição é sensível a variações no ambiente experimental, e a

reprodução é robusta a essas variações (CASADEVALL e FANG, 2010).

A capacidade de reprodução de uma pesquisa científica juntamente com o

rigor, transparência e verificação formam um fator decisivo para avaliar a

qualidade de um trabalho científico. Uma pesquisa reprodutível é aquela

todas as informações relevantes do trabalho, incluindo, mas não limitado ao

texto, dados e código, são

independente possa reproduzir os resultados

disso, a reprodutibilidade é o meio que permite que o conhecimento publicado

torne-se realmente disponível para o público

De acordo com Peng (2011), u

preencher a lacuna no processo de geração de evidências científicas entre a

não-replicação de um estudo e

extremos, há um espectro de possibi

menos reprodutível do que outro, dependendo

dados foram disponibilizad

Figura

Segundo Pinheiro

tornar uma publicação reprodutível

computacionais como apoio.

Um relatório gerado por

das pesquisas reprodutíveis baseada




parência e verificação formam um fator decisivo para avaliar a

qualidade de um trabalho científico. Uma pesquisa reprodutível é aquela


texto, dados e código, são disponibilizadas para que um pesquisador

independente possa reproduzir os resultados (VANDEWALLE et al., 2007)


se realmente disponível para o público em geral (DONOHO,

De acordo com Peng (2011), um dos objetivos da reprodutibilidade é


replicação de um estudo e a replicação completa. Entre esses dois

á um espectro de possibilidades e um estudo pode ser mais ou

menos reprodutível do que outro, dependendo da forma como

foram disponibilizados, conforme mostra a Figura 2.1.

Figura 2.1 - Espectro da Reprodutibilidade.

Fonte: Pinheiro (2013).

Pinheiro (2013), a proposta apresenta o árduo caminho para

tornar uma publicação reprodutível e a necessidade de utilização das plataformas

como apoio.

gerado por Stodden et al. (2013) sugeriu uma classificação

pesquisas reprodutíveis baseada no nível de acesso aos documentos e

22




parência e verificação formam um fator decisivo para avaliar a

qualidade de um trabalho científico. Uma pesquisa reprodutível é aquela na qual


s para que um pesquisador

ANDEWALLE et al., 2007). Além


2010).

reprodutibilidade é


completa. Entre esses dois

e um estudo pode ser mais ou

da forma como o código e os

o árduo caminho para

e a necessidade de utilização das plataformas

ugeriu uma classificação

no nível de acesso aos documentos e

23

materiais usados para a construção do experimento, disponibilização dos dados

e códigos fonte de programas, em regras e restrições de licenciamento, direitos

autorais, direito de cópia e distribuição dos materiais relacionados com a

pesquisa. Esse relatório apresenta cinco classes:

Pesquisa revisável - Permite que as descrições dos métodos de

pesquisa tenham acesso aberto para que os resultados possam ser

julgados quanto a sua credibilidade;

Pesquisa replicável - Permite a duplicação dos resultados, por

exemplo, por meio da execução de um código fonte e produção dos

gráficos mostrados na publicação;

Pesquisa confirmável - Permite que os resultados possam ser

alcançados de forma independente por meio de uma descrição

completa do algoritmo e da metodologia, sem a necessidade de usar

o software fornecido pelo autor;

Pesquisa auditável - Os registros dos materiais usados são

arquivados para que a pesquisa possa ser defendida

posteriormente. Os materiais podem ser privados e podem ser

apresentados a um revisor requisitado para uma publicação; e

Pesquisa reprodutível - É abertamente disponível, bem

documentada e com o código e dados disponíveis ao público. Ela

permite auditoria, replicação e reprodução dos resultados de forma

independente e ainda permite a ampliação e aplicação do método

em novos problemas.

Dentre as classes apresentadas, a última foi selecionada como objeto de

estudo deste trabalho, mais especificamente a pesquisa reprodutível em

computação. A qual acompanha os objetos de pesquisa (artefatos) utilizados

para a sua concepção.

24

Um artefato é uma abstração que modela um conjunto de dados de

interesse para o domínio do experimento. Artefatos são consumidos e gerados

durante a execução de um experimento e representam desde dados temporários

até o próprio resultado objetivo do experimento (KNOP, 2016).

Para Belhajjame (2012), os artefatos são como uma abstração usada para

a comunicação, compartilhamento e reuso dos resultados de uma pesquisa.

Artefatos são recursos que podem compreender, por exemplo, vídeos, imagens,

hipertextos, apresentações em slides, ou seja, qualquer artefato digital que possa

ser usado, reutilizado e referenciado (DIAS et al., 2009).

O compartilhamento dos artefatos facilita o desenvolvimento da ciência.

Para tornar uma pesquisa mais consistente e confiável é necessário criar uma

abordagem que torne a reprodução mais conveniente, por meio de uma

combinação de melhores práticas com um conjunto de ferramentas

automatizadas (DAVIDSON e FREIRE, 2008), provendo acesso aos objetos

necessários para sua execução, com o mínimo esforço e o poder computacional

necessário (KLINGINSMITH et al., 2011).

Para verificar os resultados computacionais de uma pesquisa é preciso

recriar as condições nas quais o experimento foi realizado a partir do zero

(SCHWAB et al., 2000). Esse contexto motivou a proposta deste trabalho, o qual

propõe a disponibilização das publicações eletrônicas junto aos seus artefatos,

permitindo que outros pesquisadores possam interagir e explorar as pesquisas,

deixando de lado o paradigma "a partir do zero".

Essas características são responsáveis por diversos benefícios da

pesquisa reprodutível. Adicionalmente, tais aspectos podem trazer algumas

dificuldades, as quais serão discutidas nas seções seguintes, apresentando as

vantagens, desvantagens e outros pontos relevantes da pesquisa reprodutível

em computação, de modo que tal base teórica facilite a compreensão da

aplicação prática deste trabalho.

25

2.1.1. Vantagens

A pesquisa reprodutível permite a avaliação de diferentes aspectos dos

experimentos, tais como as ferramentas, os materiais e métodos empregados.

Freire et al. (2012) listam quatro grandes benefícios:

Programas reprodutíveis podem ser comparados em termos de

desempenho e qualidade dos resultados gerados, a partir de

conjuntos de dados de entrada em comum;

Software e resultados são documentados permitindo aos usuários

entender como usar e modificar o software, bem como os conjuntos

de dados usados por ele;

Software reprodutível é portável, ele pode ser transferido de um

ambiente computacional para ser usado em outro; e

Os experimentos reprodutíveis são citados, pois permitem que

terceiros validem os resultados, aumentando o nível de confiança.

De acordo com Matthews (2004), a pesquisa reprodutível estabelece que

um experimento relatado e de fato reprodutível mostra os acertos e também os

caminhos que não produzem bons resultados, e, portanto, torna-se um

importante passo para a transferência de conhecimento e tecnologia. Além disso,

diminui a quantidade de tempo e esforço demandado para preparar o ambiente

operacional para a reprodução dos resultados (SCHWAB et al., 2000).

Para Oliveira (2015), cada ensaio experimental torna-se um teste após o

experimento ser concluído, pois, quando o experimento for repetido no futuro, já

existirá uma definição de valor esperado, um índice de referência. Ou melhor, os

acessos e testes contínuos realizados por outros pesquisadores mantêm as

pesquisas reprodutíveis e o conhecimento associado continuará a crescer.

O compartilhamento dos materiais de uma pesquisa reprodutível beneficia

a comunidade científica nos mais variados aspectos. Ele incentiva a análise de

múltiplas perspectivas sob cada um dos elementos usados, auxilia na

identificação de erros nos métodos, materiais e procedimentos, torna-se uma

ferramenta útil para a formação de novos pesquisadores e permite o uso eficiente

de recursos e financiamento, pois evita o retrabalho (HEATHER, 2007).

26

Heather (2007) afirma ainda que a quantidade de citações é uma métrica

frequentemente usada por agências no processo de decisão de financiamento

para projetos de pesquisa, estimulando a produção de trabalhos com essas

características. Ou seja, a adoção de pesquisa reprodutível pode ainda beneficiar

os pesquisadores por meio do aumento da quantidade de citações que

referenciam o seu trabalho.

Considerando-se que a reprodução científica é um modelo de investigação

bem respeitado, as barreiras tecnológicas antes existentes durante a

transferência da pesquisa de um ambiente de origem para outro de destino,

devido à variedade de infraestruturas de hardware e software, podem ser

superadas com a combinação de contêineres de software executando em um

ambiente de computação em nuvem.

2.1.2. Desvantagens

A Computação faz parte do terceiro vértice do triângulo da Ciência, ao lado da

teoria e experimentação em grau de importância, porém, ela ainda não atingiu o

mesmo grau de maturidade em termos de reprodução (LEVEQUE, 2009).

Concomitantemente, as discussões sobre uma crise de credibilidade na

computação têm aumentado, pois, atualmente é impossível verificar a maioria

dos resultados computacionais apresentados e submetidos em conferências

(FOMEL e HENNENFENT, 2007; DONOHO, 2010; LEVEQUE et al., 2012).

A iniciativa de reprodução é uma maneira de plataformas on-line facilitarem

a comprovação rápida e independente de resultados publicados. Porém, ainda

são necessárias importantes melhorias nos processos de reprodução.

De acordo com Goble (2012), uma pesquisa científica é considerada de

boa procedência quando ela é documentada com detalhes suficientes para

permitir a sua reprodução. Entretanto, segundo Fomel (2015), reprodução não é

o objetivo, o importante na realidade é tornar a pesquisa mais fácil de ser

verificada e aplicada.

27

Conforme Pinheiro (2013), para implantar pesquisa reprodutível, uma carga

extra de trabalho é exigida para todos os envolvidos. Essa carga é causada pelo

esforço em atender de forma satisfatória as demandas de RR, tais como:

construção e manutenção de um sítio web, versionamento de todos os artefatos

relevantes da pesquisa e a geração de manuais, descritores e documentação.

Esse paradigma acarreta mudanças no modo de trabalho do pesquisador, pois,

com frequência, essas atividades não fazem parte da sua rotina.

O esforço necessário para limpar e documentar os códigos e dados, e

prepará-los para a reutilização é uma das maiores barreiras para o

compartilhamento dos objetos de pesquisa (VANDEWALLE, 2012; LEVEQUE,

2009). É necessário desenvolver abordagens que reduzam essas barreiras,

criando mecanismos que facilitem o compartilhamento dos artefatos da pesquisa.

Além disso, não existe um benefício claro e objetivo que motive os

pesquisadores a demandar esforços na produção desse material complementar.

Reprodutibilidade também requer manutenção e esta requer uma

comunidade, pois a falta de manutenção faz com que a pesquisa reprodutível

perca sua finalidade, consequentemente perdendo a sua utilidade e credibilidade.

Diversas soluções inovadoras de software têm sido apresentadas para o

problema da reprodução. Porém, grande parte fracassa devido a diversos

fatores, tais como: proteção de formatos de arquivos proprietários, falta de

recompensa pela academia e agências de financiamento, dificuldade na

concepção de soluções genéricas e a exigência da rápida publicação dos

resultados se opõem ao processo de desenvolvimento baseado em padrões de

projeto de software (DUDLEY e BUTTE, 2010).

A publicação e o compartilhamento dos objetos de pesquisas científicas

devem considerar desafios quanto a questões de licença e direitos de autoria. A

lei de direito autoral é uma estrutura legal inadequada para trabalhos científicos,

pois as normas científicas guiam para a reprodução e construção de novas

soluções sob a pesquisa de outros, contrariando o padrão da referida lei

(STODDEN, 2009). Portanto, é preciso vincular licenças específicas segundo as

características de cada tipo de objeto de pesquisa permitindo a reprodutibilidade.

28

Mais detalhes sobre essas questões estão na próxima seção, a qual

aborda a subcategoria Licenciamento, parte integrante do Mapa Conceitual,

mostrado na Figura 2.2, o qual foi proposto por Oliveira (2015):

Figura 2.2 - Proposta de Mapa Conceitual para a Pesquisa Reprodutível.

Fonte: Oliveira (2015).

Segundo o autor, um cientista ao consultar esse mapa conceitual pode

considerar apenas as características que atendam a sua necessidade, e

dependendo da pesquisa científica, essas necessidades variam.

2.1.3. Licenciamento

Conforme Oliveira (2015), a licença para acesso ou uso dos objetos de pesquisa

pode ser definida de três formas distintas:

29

Pública - O artigo, juntamente com os objetos de pesquisa são

amplamente acessíveis ao público em geral, ou seja, qualquer

pessoa pode obter os objetos usados na pesquisa e reproduzi-la;

Privada - O artigo científico e os objetos de pesquisa têm o acesso

controlado a um público específico, mediante uma regra de controle

de acesso e distribuição dos objetos de pesquisa; e

Mista - Possui políticas de concessão e restrição de acesso para

cada um dos objetos de pesquisa, que pode ser pública ou privada,

segundo diversas formas de licenciamento adotadas.

O Reproducible Research Standard (RRS) sugere a adoção de licenças

públicas consolidadas mundialmente para os diferentes aspectos dos artefatos

da pesquisa (STODDEN, 2009).

A licença Creative Commons (CC), a qual permite o uso das obras, desde

que seja especificada a atribuição do proprietário (LIN et al., 2006; GARCELON,

2009), pode ser associada aos artigos, tabelas, figuras, gráficos, equações e

demais mídias.

A licença BSD (Berkeley Software Distribution) permite a utilização e cópia

de códigos fonte, modificados e não modificados, desde que a licença esteja

acompanhada do(s) nome(s) do(s) autor(es) e da denominação: Copyright(c)

<ANO>, <PROPRIETÁRIO> All rights reserved. Nesse caso, a redistribuição e

uso do código fonte e arquivo binário, com e sem modificações, podem ser feitos

quando (STODDEN, 2009):

Redistribuições mantenham o aviso de direitos autorais;

A redistribuição dos binários deve manter o aviso dos direitos

autorais, com a exclusão da responsabilidade sob a documentação

e demais materiais derivados; e

Os nomes da organização e colaboradores podem ser usados para

endossar ou promover produtos derivados, desde que se tenha uma

autorização por escrito.

30

As licenças GNU GPL (General Public License) incentivam a publicação do

software juntamente com o código fonte (VALIMAKI, 2005), consoante os

seguintes componentes:

Todo software sujeito a essa licença deverá ter o seu código fonte

liberado; e

Uma vez que a licença está ligada ao código, ela também será

atribuída a qualquer instituição que utilize o código original.

Além dessas, pode ser adotada a licença LGPL (Lesser General Public

License) para códigos de bibliotecas, permitindo o uso em pacotes de software

proprietário, desde que os produtos derivados informem a existência dessas

licenças (GPL e LGPL) (STODDEN, 2009).

Já para o caso dos dados contidos em bases, conforme o Protocolo de

Dados Públicos Abertos para a Ciência (Science Commons Open Data

Protocol)6, os fatos descritos por um determinado dado são considerados

componentes significantes e são de domínio público. Entretanto, segundo

Stodden (2009), os produtos originais relacionados com esses fatos possuem

direitos autorais. Ou seja, os fatos expostos em um trabalho são de domínio

público, mas a seleção e o arranjo desses dados possuem direitos autorais.

Diante do exposto em relação ao tema licenciamento, este trabalho propõe

que o pesquisador possa tomar decisões sobre quais tipos de licenças associar

aos artefatos da pesquisa, assegurando o acesso público, bem como protegendo

os direitos do autor da pesquisa original, garantido por exemplo, a citação.

A seguir, serão abordados os conceitos relacionados à computação em

nuvem, descrevendo-se as principais características, os modelos de serviço e de

implantação, assim como a relevância da computação em nuvem para a

pesquisa reprodutível e consequentemente para este trabalho.

6 http://sciencecommons.org/projects/publishing/open-access-data-protocol

31

2.2. Computação em Nuvem

Segundo Armbrust et al. (2010), a computação em nuvem se refere tanto aos

aplicativos disponíveis como serviço na Internet, quanto ao hardware e a

infraestrutura de software básico nos data centers que oferecem esse serviço.

Para Mell e Grance (2011), do NIST, a computação em nuvem é um modelo que

permite acesso ubíquo, conveniente e sob demanda, por meio da rede, a um

conjunto compartilhado de recursos computacionais configuráveis (por exemplo:

redes, servidores, armazenamento, aplicações e serviços), que podem ser

rapidamente provisionados e disponibilizados com o mínimo de esforço de

gerenciamento ou de interação com o provedor de serviços.

Além das duas definições citadas para a computação em nuvem, existem

outras, o que mostra que o termo ainda não está totalmente estabelecido. Alguns

autores têm se esforçado para relatar o estado da arte da computação em nuvem

até então, visando não só encontrar algum ponto em comum nas definições

existentes, mas também estabelecer algum critério comparativo, dentre eles

Vaquero (2009) e Zhang (2010). Diante das várias definições, pode-se afirmar

que aquela apresentada pelo NIST (2011) é a mais bem aceita pela academia.

Motivo pelo qual foi utilizada para o estudo da computação em nuvem no

decorrer deste trabalho.

A computação em nuvem tem recebido a atenção tanto da academia

quanto de grandes empresas, como é o caso da Amazon7, do Google8 e da

Microsoft9. Segundo Hsieh et al. (2011), o tamanho dos conjuntos de dados

armazenados em nuvem tem crescido rapidamente.

Serão explanados, nas seções seguintes deste capítulo, as características

essenciais, os modelos de serviço, os modelos de implantação e a relevância da

computação em nuvem para a pesquisa reprodutível.

7 https://aws.amazon.com

8 https://cloud.google.com

9 https://azure.microsoft.com

2.2.1. Características Essenciais

De acordo com Mell e Grance (2011

características essenciais

característica a seguir.

Figura 2.3 - Características Essenciais da Computação em Nuvem

Autoatendimento sob demanda

obter recursos de forma automática, sem intervenção humana, por

meio de uma interface que apresente um catálogo de recursos e os

serviços relacionados. Os provedores de nuvem disponibilizam uma

interface que permite a

Amplo acesso à

recursos da nuvem

diferentes plataformas operacionais,

tablets, laptops

permite que os recursos da nuvem

partir de qualquer loc

Amplo acesso à rede

Características Essenciais

e acordo com Mell e Grance (2011), a computação em nuvem possui cinco

características essenciais, como mostram a Figura 2.3 e as descrições

Características Essenciais da Computação em Nuvem


atendimento sob demanda (on-demand self-service




interface que permite a exposição e a requisição de tais recursos;

mplo acesso à rede (broad network access) - Possibilita

recursos da nuvem sejam acessados remotamente, a partir de

diferentes plataformas operacionais, tais como:

laptops e estações de trabalho. Esse acesso geralmente

que os recursos da nuvem sejam amplamente acessado

partir de qualquer local e dispositivo que tenham suporte à

Computação

em

Nuvem

Autoatendi-mento sob demanda

Agrupamen-to de

recursos

Medição de serviço

Elasticidade rápida

Amplo acesso à rede

32

computação em nuvem possui cinco

e as descrições de cada

Características Essenciais da Computação em Nuvem.

service) - Permite




requisição de tais recursos;

Possibilita que os

acessados remotamente, a partir de

smartphones,

e acesso geralmente

amplamente acessados a

al e dispositivo que tenham suporte à Internet;

33

Agrupamento de recursos (resource pooling) - Permite encontrar

um grande número de opções de recursos de forma flexível para

que o cliente possa selecionar os que ele precisa, aumentando o

atendimento aos requisitos do negócio e reduzindo os custos

financeiros para as aquisições. Geralmente, os recursos são

formados pelos componentes de computação (CPU e memória),

armazenamento em massa (discos) e rede de computadores. O

agrupamento de recursos é possível por meio de técnicas de

virtualização de hardware (VM, discos e redes locais virtualizadas);

Elasticidade rápida (rapid elasticity) - Habilidade de se expandir

e/ou reduzir a alocação dos recursos de Tecnologia da Informação

(TI) de forma eficiente, ou seja, escalar para obtenção de mais

recursos (scale up) ou escalar para redução de recursos (scale

down) dinamicamente. A alocação e a liberação dos recursos podem

ser feitas de maneira manual, pelo próprio cliente ou de forma

automática, mediante restrições e critérios previamente definidos e

explicitados por meio dos Acordos de Nível de Serviço (Service

Level Agreements - SLA); e

Medição de serviço (measured service) - Monitoramento, controle e

otimização automática do uso de recursos alocados, tais como: o

tempo de CPU, largura de banda e capacidade de armazenamento

em relação à quantidade de tempo em que o recurso foi usado. Os

modelos de fornecimento e de medição caracterizam o custo

operacional na forma "pay-as-you-go", ou seja, o cliente paga pelos

recursos alocados com base na forma como ele utiliza, tornando o

processo transparente para ambas as partes, provedor e cliente.

É necessário que o serviço provido dê garantias aos usuários, de que, além

de segurança, pode oferecer qualidade do serviço, tempo de resposta,

disponibilidade, entre outras, conforme os SLA.

34

Mais detalhes sobre o tema SLA estão na Seção 2.2.4. A próxima seção

aborda os modelos de serviço.

2.2.2. Modelos de Serviço

Um provedor de nuvem pode fornecer três modelos de serviço aos usuários

(VAQUERO et al., 2009; ZHAO et al., 2011). Esses modelos oferecem diferentes

níveis de abstração. Os principais modelos, segundo Mell e Grance (2011), são:

Software como um Serviço (Software as a Service - SaaS) - Nesse

modelo os aplicativos e demais software são hospedados

remotamente, permitindo que os usuários acessem e manipulem os

aplicativos via Internet. Esse modelo elimina a necessidade de

instalação e configuração do software no computador do usuário;

Plataforma como um Serviço (Plataform as a Service - PaaS) -

Modelo no qual os fornecedores podem oferecer na nuvem um nível

de abstração adicional. Em vez de fornecer uma infraestrutura

virtualizada, eles podem fornecer a plataforma de software na qual

os sistemas possam executar (VAQUERO et al., 2009). Com isso, o

dimensionamento dos recursos de hardware exigidos pela execução

dos serviços é feito de forma transparente; e

Infraestrutura como um Serviço (Infrastructure as a Service -

IaaS) - Ocorre no nível de recursos de computação, armazenamento

e redes de computadores. Trata-se da camada base da pilha de

fornecimento de recursos na nuvem. Esse tipo de fornecimento é

possível devido à tecnologia de virtualização, a qual permite dividir e

alocar os recursos dinamicamente de acordo com a demanda. O

modelo IaaS permite aos usuários implantar e executar suas

aplicações e sistemas operacionais em VM.

Os principais modelos de serviço da computação em nuvem são

apresentados na Figura 2.4:

35

Figura 2.4 - Modelos de Serviço da Computação em Nuvem.


Alguns autores como Wang et al. (2010) incluem um quarto modelo de

serviço, denominado Dados como um Serviço (Data as a Service - DaaS).

Nesse modelo, os dados de vários formatos e múltiplas origens podem ser

acessados por meio de serviços fornecidos na rede de computadores, para que

os usuários possam manipulá-los remotamente como se estivessem com os

dados em seu disco local (WANG et al., 2010).

A seção seguinte trata dos modelos de implantação de nuvem.

2.2.3. Modelos de Implantação

A computação em nuvem pode ser implantada e utilizada de diferentes maneiras,

dependendo das necessidades de uso e negócio. Considerando os modelos de

implantação, existem quatro categorias distintas, de acordo com o NIST (2011) e

o Cloud Security Alliance (CSA)10:

Nuvem privada (private cloud) - Disponível para uso exclusivo por uma

única organização. Sua utilização, gerenciamento e operação podem ser

10 https://cloudsecurityalliance.org

Computação

em Nuvem

SaaS

IaaSPaaS

36

feitos pela própria organização, terceiros, ou por uma combinação dos

dois, e pode estar localizada em suas dependências ou fora delas. No

entanto, o cliente terá controle sobre sua localização geográfica, o que a

faz tornar atrativa para dados ou sistemas com restrições de acesso ou

que sejam de missão crítica;

Nuvem pública (public cloud) - Disponível para uso aberto ao público em

geral e que fica nas instalações do provedor. A sua propriedade,

gerenciamento e operação podem ser de uma empresa, uma instituição

acadêmica, uma organização do governo ou de uma combinação desses;

Nuvem híbrida (hybrid cloud) - Composição de duas ou mais

infraestruturas de nuvem (privada, comunitária ou pública), interligadas por

tecnologias padronizadas ou proprietárias, as quais permitem

portabilidade de dados e aplicações entre as nuvens; e

Nuvem comunitária (community cloud) - Disponível para uso exclusivo de

uma comunidade específica, formada por organizações que possuem

interesses e preocupações em comum (por exemplo: requisitos de

segurança e conformidade). Pode estar localizada nas dependências de

uma ou mais dessas organizações ou fora delas. Sua utilização,

gerenciamento e operação podem ser feitos por uma ou várias das

organizações pertencentes à comunidade, por terceiros ou por uma

combinação deles.

Os conceitos de nuvem privada, pública, híbrida e comunitária podem ter

variações em outros modelos de implantação de nuvem. Contudo, os modelos

são frequentemente apresentados em escalas que variam desde nuvem privada

em um extremo à nuvem pública no outro.

A Figura 2.5 ilustra os modelos de implantação da computação em nuvem.

Portanto, diante do exposto, o modelo de nuvem pública está mais

intrinsecamente relacionado ao escopo deste trabalho, o qual preza pelo acesso

e compartilhamento público de dados.

37

Figura 2.5 - Modelos de Implantação da Computação em Nuvem.


Dentro dessas variações, vale a pena abordar o conceito de nuvem privada

virtual. Segundo o Gartner11, quando um provedor de serviços utiliza recursos de

nuvem pública para criar e fornecer nuvens privadas, o resultado é uma nuvem

privada virtual, ou seja, uma nuvem pública sem compartilhamento de recursos,

na qual tais recursos são acessados por uma conexão de rede privada.

Há muitas dúvidas em torno da delimitação entre um termo e outro, e sua

divisão não tem sido absoluta nem consensual. No entanto, o Quadro 2.1,

baseado no quadro Cloud Computing Models do CSA (2009), define algumas

características que auxiliam a diferenciar os modelos de implantação de nuvem.

Quadro 2.1 - Comparativo entre os Modelos de Implantação de Nuvem.

Modelo de implantação

Gerenciada por

Propriedade da infraestrutura

Localização da infraestrutura

Forma de acesso e consumo

Pública Terceiros Terceiros Fora das dependências

Compartilhado

Virtual privada Organização ou terceiros

Organização ou terceiros

Fora das dependências

Dedicado

Privada Organização ou terceiros

Organização ou terceiros

Dentro das dependências

Dedicado

Híbrida Tanto organização como terceiros

Tanto organização como terceiros

Tanto dentro como fora das dependências

Tanto dedicado como compartilhado

Fonte: Adaptado de CSA (2009).

11 http://www.gartner.com

38

A próxima seção aborda os Acordos de Nível de Serviço, do inglês Service

Level Agreements (SLA) em computação em nuvem.

2.2.4. Service Level Agreements (SLA)

Segundo Sakr e Liu (2012), os SLA representam o contrato que capta as

garantias acordadas entre os clientes e um provedor de serviços. Os SLA são o

único documento legal entre cliente e provedor (WEIS e ALVES-FOSS, 2011).

O contrato é a alternativa para que o cliente tenha garantias de qualidade

do serviço adquirido, uma vez que certas configurações de baixo nível somente

podem ser realizadas pelo servidor.

Suleiman et al. (2012) dividem os SLA em duas categorias: SLA de

Infraestrutura de Nuvem e SLA de Aplicações Baseadas em Nuvem.

A primeira categoria diz respeito ao acordo entre o provedor de serviços e

seus clientes, os quais hospedam serviços em nuvem. Englobam especificações

como desempenho do servidor, velocidade da rede, disponibilidade de recursos e

capacidade de armazenamento, entre outras.

Já a segunda se refere ao relacionamento entre clientes da nuvem e os

usuários finais das aplicações, uma vez que os clientes também devem garantir a

qualidade dos seus serviços. Envolve questões como tempo de resposta,

disponibilidade, segurança e tempo médio de espera, entre outras.

Ademais, é preciso que estejam claras ao cliente quais as medidas que

deverão ser tomadas pelo provedor do serviço com relação à recuperação de

desastres, à destruição de dados, ao acesso de usuários privilegiados, entre

outras dificuldades que possam vir a ocorrer durante a prestação do serviço

(WEIS e ALVES-FOSS, 2011).

Por fim, caso o serviço não atinja os níveis acordados, são definidas

penalidades para os provedores. Tal punição pode ser, por exemplo, redução no

preço pago pelo serviço.

39

Atualmente, os SLA disponíveis não atendem às necessidades dos

usuários. Muitos provedores garantem, em contrato, apenas a disponibilidade de

seus serviços (SAKR e LIU, 2012), ignorando outras competências relevantes

para dar segurança ao cliente na contratação do serviço.

A especificação detalhada do contrato de nível de serviço pode ser um

incentivo à adoção da nuvem por parte das empresas, particularmente aquelas

cujos serviços são críticos e precisam de garantias. Desse modo, o avanço desse

tema deve ser amplamente estimulado.

A seguir é descrito o potencial da computação em nuvem no âmbito da

Pesquisa Reprodutível, objeto de estudo deste trabalho.

2.2.5. Pesquisa Reprodutível com a Infraestrutura em Nuvem

A computação em nuvem pode trazer diversas vantagens nos mais variados

cenários para a comunidade científica.

Atualmente, os governos, institutos de pesquisa e líderes das indústrias

estão adotando a computação em nuvem com o propósito de resolver os seus

crescentes problemas de demanda de computação e armazenamento de dados

(HIDEN et al., 2013). Como a nuvem fornece recursos de computação de forma

escalável e elástica, ela torna-se uma solução atraente para os experimentos de

pesquisa (KLINGINSMITH et al., 2011).

Para Juve e Deelman (2010), a nuvem oferece oportunidade para os

pesquisadores testarem suas ideias e códigos antes de investirem recursos

financeiros mais significativos em infraestrutura, em uma escala potencialmente

maior. Em geral, os objetivos envolvem minimizar o tempo total de conclusão de

um processamento com uma restrição orçamentária ou minimizar o

processamento sob uma restrição de tempo.

A computação em nuvem pode auxiliar a reprodutibilidade de pesquisas de

diversas maneiras (DUDLEY e BUTTE, 2010):

40

Na camada de dados - A nuvem permite que os conjuntos de dados

sejam facilmente armazenados e compartilhados virtualmente, sem

necessariamente copiá-los para outro computador;

Na camada do sistema - Snapshots de sistemas de computador

completos podem ser trocados entre cientistas. Cópias de

computadores armazenados e compartilhados em uma VM ou

imagem Docker na nuvem podem fazer as análises computacionais

se tornarem mais reprodutíveis; e

Na camada de serviço - Os serviços computacionais são expostos

a aplicações externas por meio de alguma forma de programação de

interface.

Alguns autores discutem os benefícios e as vantagens de migrar o

ambiente de testes experimental das estações de trabalho, clusters e grades

para o ambiente de nuvem computacional. As características e os recursos dos

provedores de nuvem podem aumentar a capacidade de reprodutibilidade

científica. Howe (2012) apresenta um conjunto de características da nuvem que

justificam essa afirmativa:

Maior captura de variáveis - É possível compartilhar todo o

ambiente de trabalho (dados, códigos, logs, históricos de uso,

resultados intermediários, figuras, anotações, experimentos

fracassados, detalhes de configuração do sistema operacional e

demais informações) por meio de VM;

Portabilidade - A VM torna-se a unidade de compartilhamento da

pesquisa. Esse nível de abstração elimina grande parte dos

problemas de portabilidade nos processos de instalação,

configuração e execução de software de terceiros;

Menos restrições sobre os métodos de pesquisa - Experimentos

executados em um computador local também podem ser executados

41

em uma VM na nuvem, exceto em casos com hardware

especializado. Em geral, não é necessário alterar a metodologia de

trabalho para usar uma VM, pois é possível usar outros sistemas

operacionais, linguagens, bibliotecas, ferramentas, convenções e

práticas, tendo apenas o custo de estabelecer um ambiente virtual

no qual irá trabalhar;

Backups - Snapshots das VM armazenados em intervalos regulares

fornecem um dicionário de ações e processos no laboratório. Para

obter um estado anterior do processo basta identificar a VM do

período desejado e instanciá-la;

VM como publicações - VM hospedadas nos provedores de nuvem

são associadas a um identificador único e podem ser referenciadas

por artigos científicos;

Códigos, dados, ambiente e recursos - Uma VM empacota os

códigos, dados e ambiente operacional devidamente instalados e

configurados. Além disso, a infraestrutura da nuvem fornece um

ambiente de computação para a reprodução equivalente ao que foi

usado para a execução do experimento. Também é possível fazer o

download da VM para o ambiente de trabalho local;

Queda no preço - O preço das unidades de computação e

armazenamento tem diminuído na maioria dos cenários de ofertas

dos provedores de nuvem, em muitos casos devido à queda do

preço do hardware;

Reprodutibilidade de arquiteturas complexas - Experimentos

computacionais estão usando cada vez mais arquiteturas

complexas, tais como servidores de banco de dados e arquivos,

técnicas de computação de alto desempenho, programação para

unidades de processamento gráfico, entre outros. A nuvem oferece

42

recursos e ferramentas para experimentos aplicados a esses

cenários;

Experimentos colaborativos sem restrição - Uma instância de VM

compartilhada na nuvem permite que dois ou mais pesquisadores

possam trabalhar colaborativamente em um experimento, cada um

utilizando a sua conta;

Compartilhamento de grandes conjuntos de dados - A ciência

tem se tornado intensiva de dados nos mais variados campos do

conhecimento. Nesse cenário, a obtenção ou troca de grandes

conjuntos de dados de uma estação de trabalho local para outra

pode ser inviabilizada devido ao volume desses dados chegar a

escalas muito grandes. Portanto, é mais interessante hospedar os

dados nos provedores de nuvem e migrar a computação para o local

onde estão os dados;

Compartilhamento de custos - A reprodução envolve questões de

custos, na qual os autores arcam com os custos de armazenamento

da VM, e os experimentadores e aqueles que desejam reproduzir

arcam com os custos de reexecução; e

Compatibilidade com outras abordagens - A definição dos

experimentos encapsulados em VM é compatível com outras

abordagens de reprodução. Se os pesquisadores padronizarem as

linguagens de programação, SGWfC e formatos de arquivos de

metadados, essas técnicas podem ser usadas em uma VM da

mesma forma que poderiam ser usadas em um computador físico.

As características do paradigma de nuvem permitem atender à premissa de

que para fazer a reprodução dos experimentos é necessário ter acesso a toda

infraestrutura de hardware e software configurados de forma equivalente ao

experimento original, bem como ter acesso ao conjunto de dados originalmente

utilizados (KLINGINSMITH et al., 2011). Este que é um dos principais objetivos

43

deste trabalho, visto que se utiliza de contêineres Docker executando em uma

VM, buscando otimizá-la.

Com vistas a fundamentar o modelo de arquitetura proposto no presente

trabalho, os conceitos e mais detalhes relacionados aos contêineres de software

em nuvem, especialmente o Docker, serão abordados mais adiante.

2.3. Considerações Finais do Capítulo

Este capítulo apresentou uma revisão da literatura a fim de fundamentar o

presente trabalho. Foram abordados os temas Pesquisa Reprodutível em

Computação (incluindo sua conceituação, vantagens, desvantagens e aspectos

de licenciamento), Computação em Nuvem (abordando características

essenciais, modelos de serviço, modelos de implantação, entre outros aspectos)

e Contêineres de Software, em especial o Docker.

A revisão de literatura mostrou a importância dos temas e o modo como

eles têm sido abordados sob a ótica de diferentes autores, bem como a

necessidade de estudar métodos com vistas a disponibilizar pesquisas

computacionais na infraestrutura de computação em nuvem, permitindo que o

pesquisador possa tomar decisões sobre quais artefatos publicar e compartilhar.

O próximo capítulo aborda os trabalhos relacionados a este.

44

3. TRABALHOS RELACIONADOS

Neste capítulo, serão abordados os trabalhos relacionados a este, isto é,

métodos, técnicas ou processos para disponibilização de artefatos e pesquisas

computacionais, os quais serviram de inspiração para o seu desenvolvimento.

No que se refere à disponibilização de pesquisas computacionais em

contêineres de software, o tema tem sido abordado discretamente na literatura

científica. Apesar disso, é possível elencar diferentes trabalhos que tratam

técnicas e modelos do referido tema, como mostrado a seguir.

Um trabalho bem citado sobre o tema é o An introduction to Docker for

reproducible research, de Boetigger (2015). Como os ambientes computacionais

possuem naturalmente uma evolução rápida, a repetição e extensão de

experimentos diversos tornam-se um grande desafio. Segundo o autor, Docker

tem o potencial para resolver as deficiências de certas abordagens existentes

para os desafios da pesquisa reprodutível que decorrem de recriar ambientes

computacionais complexos.

Verifica-se, no entanto, que o Docker apesar de facilitar o desenvolvimento

de novas pesquisas por aumentar a reprodutibilidade de experiências, não foi

desenvolvido para ser utilizado em workflows científicos.

Outra abordagem relevante nesse contexto é a de Chirigati et al. (2013;

2016), denominada Reprozip, uma ferramenta para o empacotamento dos

elementos necessários para reproduzir os resultados obtidos em uma pesquisa

científica orientada pelos dados de proveniência. O principal objetivo é o

compartilhamento do experimento com os revisores e leitores para que os

mesmos possam descompactá-lo e reproduzi-lo sem a necessidade de

instalação adicional de software.

O Reprozip combina o Code, Data and Environment - CDE (GUO, 2012)

com o uso de VM para gerar snapshots do computador. Ele encapsula somente

os elementos que foram usados na execução do experimento. Trata-se de uma

abordagem proposta em conjunto com o SGWfC Vistrails (KOOP et al., 2011)

45

aplicado ao ambiente científico para tornar os workflows portáveis e reprodutíveis

na infraestrutura de terceiros.

Em sua arquitetura, o Reprozip executa dois estágios principais, o

empacotamento do ambiente e o posterior desempacotamento em um

computador de destino. A Figura 3.1 mostra os passos de empacotamento

composto por três atividades: (1) captura de dados de proveniência, (2) análise

da proveniência e (3) geração de pacotes.

Figura 3.1 - Processo de Criação de um Pacote Reprozip.

Fonte: Chirigati et al. (2013).

Na captura, o Reprozip usa o System Trap para obter a proveniência. Ele

instrumenta e captura a trilha de execução das chamadas de sistema dos

processos envolvidos na execução. A proveniência é armazenada em uma base

de dados gerenciada por um SGBD Mongo DB12.

Em seguida, na análise, é criada uma árvore da proveniência do

experimento. Cada nó dessa árvore representa um dado processo do sistema

operacional e as arestas representam a ligação entre processo pai e os

processos filho, permitindo identificar as dependências de recursos com

programas executáveis, arquivos de entrada e saída. Ao final, é criado um pacote

com o workflow, software e os arquivos de entrada e saída usados na derivação

dos resultados.

12 https://www.mongodb.com

46

No processo de desempacotamento extrai o pacote do experimento em um

determinado diretório e faz a configuração dos programas, conjuntos de dados,

parâmetros de configuração e variáveis de ambiente do workflow.

Como o Reprozip utiliza a abordagem CDE para prover o empacotamento

dos códigos, dados e ambiente, consequentemente, ele herda todas as

limitações da abordagem. Apesar de trabalhar com workflows científicos, dados

de proveniência e o uso opcional de contêineres Docker, a abordagem não prevê

as questões e peculiaridades de experimentos que usam ambientes especiais

como clusters ou nuvem computacional.

Outro trabalho nesse contexto é o ResearchCompedia.org (STODDEN;

MIGUEZ; SEILER, 2015), uma infraestrutura que permite a pesquisadores

publicar seus artigos, dados e software necessários para reproduzir os resultados

de seus experimentos. É necessário que uma equipe conduza uma execução do

código para realizar a certificação do experimento junto ao artigo. Apesar dos

autores proporem a execução por meio de virtualização na nuvem, o enfoque é

mais na repetição dos experimentos.

A Pesquisa Reprodutível na Nuvem é um tema bastante recorrente,

fazendo-se presente em diversos autores (HOWE, 2012; ARMBRUST et al.,

2010; KLINGINSMITH et al., 2011; DEELMAN, 2008), entre outros, os quais

discutem as vantagens de migrar o ambiente dos experimentos das estações de

trabalho, clusters e grades para a nuvem. As características e recursos da nuvem

podem aumentar a capacidade de reprodução, motivando o desenvolvimento de

abordagens baseadas neste paradigma de fornecimento de recursos. As

abordagens Whole System Snapshot Exchange - WSSE (DUDLEY e BUTTE,

2010), Chef (KLINGINSMITH et al., 2011) e AMOS (STRIJKERS, 2011) são as

principais representantes dessa classe de mecanismos de reprodução e serão

discutidos em seguida.

A abordagem WSSE, de Dudley e Butte (2010), propõe gerar snapshots

digitais de dados e código fonte para serem produzidos e distribuídos dentro de

um provedor de computação em nuvem. A Troca Instantânea de Sistema é uma

47

formulação de conceito para tratar as dificuldades de reprodução relacionadas à

infraestrutura de computação e armazenamento de objetos de pesquisa.

A proposta do WSSE é utilizar as vantagens da implantação de

experimentos científicos na nuvem com o suporte a reprodução por meio da

definição de três camadas: dados, sistemas e serviços.

Nas camadas de dados e sistemas, respectivamente, os dados e sistemas

vinculados aos experimentos científicos podem ser armazenados em Imagens de

Máquinas Virtuais (Virtual Machine Images - VMI) na nuvem, preservando o

ambiente usado na execução do experimento original. Já a camada de serviço

permite que as computações implantadas na nuvem possam ser acessadas por

aplicações externas, gerando uma solução de reprodução orientada a serviços.

Foram identificados alguns desafios durante o projeto, principalmente em

relação a questões de licença e distribuição de software, pois em geral, a licença

é restrita a um computador. Além disso, devem ser consideradas questões

relacionadas à coleta de dados de proveniência em nível de sistemas, pois a

nuvem abstrai detalhes de infraestrutura, limitando as informações das camadas

acima do nível de VM e sistema operacional. O WSSE ainda é um conceito,

portanto, não existe uma implementação que aponte as características

operacionais para o seu funcionamento.

Klinginsmith et al. (2011) propõem uma abordagem denominada Chef para

a construção de ambientes de clusters virtuais implantados sob infraestruturas de

nuvem. Na abordagem, os recursos computacionais são divididos em duas

camadas: (1) infraestrutura e (2) software. A primeira gerencia a infraestrutura em

nuvens IaaS, comunicando com a API do provedor de nuvem para instanciar a

VM, configurar a rede e alocar espaço de armazenamento. A segunda gerencia o

software responsável pela execução dos comandos na VM.

As duas camadas são gerenciadas pela ferramenta de gerenciamento de

configuração Chef. O Chef é usado para automatizar a configuração dos clusters

virtuais e para a instalação do software necessário para a reexecução dos

experimentos, possibilitando a reprodução do ambiente.

48

Na abordagem Chef é necessário instanciar, configurar e registrar as VMI

manualmente, e ainda, instalar um cliente do Chef para auxiliar no processo de

configuração do software nas VMI. O resultado final é a possibilidade de

replicação dos clusters virtuais em diferentes provedores de nuvem utilizando

uma camada de software em comum (KLINGINSMITH et al., 2011).

Segundo os autores, a arquitetura do Chef é formada por seis

componentes:

Livro de Receitas (Cookbook) - agrupa artefatos Chef (ex: receitas)

relacionado uns com os outros;

Receitas (Recipes) - unidade básica de configuração do Chef. Uma

receita pode interagir com outras receitas e demais artefatos;

Recursos (Resources) - são usados pela receita para a execução de

alguma ação;

Servidor Chef (Chef Server) - local que armazena todos os artefatos

do Chef;

Cliente Chef (Chef Client) - máquinas clientes que o servidor Chef

administra as receitas para instalar e configurar o software; e

Faca (knife) - ferramenta de linha de comando de uso administrativo

do Chef.

O sistema AMOS, abordagem proposta por Strijkers et al. (2011), usa o

conceito de um template mínimo de VM contendo um conjunto de ferramentas de

grades computacionais previamente instaladas para implementar um mecanismo

que inicializa e configura a VM sob demanda.

O objetivo é que templates de VM possam ser recriadas ou clonadas para

a execução e reexecução de um workflow. Com isso os pesquisadores podem

criar diversos templates e armazená-los em uma base de dados de artigos

executáveis. Os processos de gerenciamento dos dados e da execução da

aplicação das VM são instrumentados por um SGWfC.

O AMOS é incluído na arquitetura com três elementos: proveniência,

gerenciador de infraestrutura virtual e Uniform Resource Locator (URL). A

proveniência obtém as informações da execução do workflow. O gerenciador de

49

infraestrutura usa os recursos dos provedores de nuvem para criar o ambiente de

execução dos componentes do workflow, baseado nos templates armazenados

na base de artigos executáveis. E os conjuntos de dados usados na execução

podem ser referenciados por meio de URL. A Figura 3.2 apresenta uma proposta

de arquitetura para a representação e reprodução de experimentos.

Figura 3.2 - Proposta de Arquitetura de Reprodução de Experimentos do AMOS.

Fonte: Strijkers et al. (2011).

O AMOS apresenta a possibilidade de preservação de código e dados em

VM para a preservação da compatibilidade do ambiente experimental, porém,

destacam que essa compatibilidade é dependente do software de virtualização.

Os autores enfatizam que os problemas relativos a artigos executáveis não estão

relacionados apenas com as características técnicas, mas envolve ainda a

manutenção dos objetos de pesquisa usados no experimento. Os autores

destacam ainda que não existe solução eficaz baseada em metadados e dados

de proveniência que aumente a capacidade dos artigos executáveis, portanto, a

chave seria a infraestrutura de virtualização.

O Quadro 3.1, sumariza as características dos trabalhos apresentados

acima quanto a, respectivamente, quais os formatos de reprodução que

apresentam, os tipos de licenciamentos que possuem e se estão disponíveis em

um ambiente de computação em nuvem, máquina virtual e/ou contêiner de

software. Existem os casos no quadro em que as informações sobre um dado

50

fator de uma abordagem não são mencionadas na bibliografia, portanto, foi

assinalada com o símbolo "-" significando "desconhecido".

Quadro 3.1 - Comparativo entre os Trabalhos Relacionados.

Abordagem Ano Reprodutibilidade

/ Repetibilidade Licenciamento Nuvem VM Contêiner

An introduction to Docker for reproducible research

2015 Descritiva / Conceitual

Público Não Não Proposta

Reprozip 2013 Sim Público Não Sim Não

2016 Sim Público Não Sim Opcional

ResearchCompedia.org 2015 Descritiva / Assistida

Público Sim Não Não

WSSE 2010 Descritiva / Conceitual

- Sim Sim Não

Chef 2011 Sim - Sim Sim Não AMOS 2011 Sim - Sim Sim Não

Fonte: Elaborado pelo Autor (2017).

Os trabalhos relacionados mostram que o tema Pesquisa Reprodutível em

Computação tem sido recorrente na academia. Ademais, serviram de inspiração

para o modelo de arquitetura proposto no presente trabalho, em especial no que

se refere à interferência do pesquisador na definição de quais artefatos publicar e

compartilhar de uma pesquisa.


Este capítulo apresentou uma análise de trabalhos relacionados a este, a fim de

fundamentar o presente trabalho e propor uma nova abordagem.

O próximo capítulo apresenta um modelo de arquitetura para


de software em nuvem, descrevendo seus componentes, arquitetura e

funcionamento.

51

4. A ABORDAGEM PROPOSTA

Neste capítulo será apresentada a principal contribuição deste trabalho: um

modelo de arquitetura para disponibilização de pesquisas computacionais e seus

artefatos em contêineres de software em nuvem a fim de permitir acesso público.

O modelo parte do pressuposto de que uma pesquisa científica pode abrigar

artefatos que necessitam ser publicados e compartilhados e outros que não

necessitam.

Esse conjunto de artefatos varia entre tipos primitivos de dados, como

números inteiros, números reais, valores lógicos a arquivos binários e multimídia.

Cadeias de caracteres também podem ser vistas como artefatos, assim como

arquivos de texto puro contendo dados em algum formato próprio das

ferramentas utilizadas ou em formatos padronizados, como os estruturados XML

(eXtensible Markup Language)13 e JSON (JavaScript Object Notation)14.

Segundo Knop (2016), artefatos podem ser persistidos de duas formas

diferentes: como arquivos armazenados no sistema de arquivos da instância do

ambiente, organizados em pastas próprias para o projeto em que são definidos,

ou guardados no banco de dados interno da implementação do ambiente e

manipulados durante a execução do experimento.

No caso do modelo de arquitetura proposto neste trabalho, os tipos

primitivos de dados e os arquivos binários são persistidos em contêineres de

dados e volumes de dados, respectivamente.

Para definir o modo de tratamento dos artefatos, utiliza-se o conhecimento

do pesquisador sobre sua pesquisa: o próprio pesquisador define quais artefatos

devem ser publicados e compartilhados, de acordo com o(s) tipo(s) de licença(s)

mais apropriado(s) (ver Seção 2.1.3).

Com base na revisão de literatura realizada no Capítulo 2 deste trabalho, a

interferência do pesquisador foi uma das estratégias aqui adotadas. Desse modo,

esta estratégia de escolha dos artefatos que necessitam ou não de publicação e

13

https://www.w3.org/XML 14 https://www.json.org

52

compartilhamento é determinante para a composição das imagens Docker e por

privilegiar o conhecimento e autonomia do pesquisador sobre a sua pesquisa.

As seções seguintes deste capítulo apresentam uma definição geral do

modelo de arquitetura proposto, abordando suas características, arquitetura e a

preparação do ambiente para execução de um cenário prático na nuvem.

4.1. Definição Geral da Abordagem

A partir dos estudos realizados e mediante investigação dos pontos fortes e

fracos das outras abordagens, o modelo de arquitetura aqui proposto foi

desenvolvido.

O referido modelo de arquitetura é uma abordagem de software que

automatiza a preparação de uma pesquisa computacional reprodutível junto aos

seus artefatos, de forma que seja possível publicar e compartilhar em provedores

de nuvem. Essas e outras características do modelo de arquitetura serão

discutidas nesta seção.

O modelo de arquitetura usa três tecnologias base para prover a sua

infraestrutura de reprodutibilidade:

A utilização de contêineres (conteinerização);

A computação em nuvem; e

A virtualização de recursos.

A conteinerização na computação em nuvem é o principal diferencial desta

pesquisa em relação às outras abordagens de reprodutibilidade. Com a

conteinerização é possível especificar a quantidade de memória, espaço em

disco e CPU a serem utilizados por um contêiner em uma instância. Além disso,

os contêineres permitem controlar as versões da pesquisa e de suas

dependências (bibliotecas), além de possibilitarem a portabilidade do ambiente.

O modelo de arquitetura aqui proposto trabalha com o contexto de

aplicações e microsserviços distribuídos. Por tal motivo, está previsto que cada

53

componente de uma mesma pesquisa pode ser dividido em diferentes imagens

Docker, executando em contêineres diferentes. Os pesquisadores podem

atualizar independentemente cada pesquisa, pois não há conflitos de bibliotecas.

Por meio da computação em nuvem é possível que o pesquisador publique

a(s) sua(s) pesquisa(s) junto com os artefatos encapsulados em uma ou várias

imagens Docker, possibilitando que outros pesquisadores possam acessar e

obter os recursos de computação necessários para fazer a reprodução.

Conforme abordado na Seção 2.2, a computação em nuvem possui

diferentes níveis de ofertas de recursos, distribuídos sob a forma de serviços.

Estes recursos podem ser obtidos por um usuário mediante um SLA (ver Seção

2.2.4). Nesse contexto, são obtidos serviços de infraestrutura de data center nos

fornecedores de nuvem que usam o modelo de serviço IaaS. Este nível de

serviço tem como principal característica o fornecimento de recursos de sistemas

de computação na forma de VM, contêineres e recursos de armazenamento.

Portanto, para obter uma infraestrutura de reprodução de um experimento

na nuvem é necessário acessar o provedor, analisar o conjunto de ofertas de

recursos de computação com seus respectivos valores, selecionar a oferta que

mais atenda à demanda, e ao final, implantar as imagens Docker que serão

executadas em forma de contêineres e que possuem todos os dados necessários

para reprodução do(s) experimento(s), inclusive dependências e bibliotecas.

É importante destacar que os custos relacionados ao uso da infraestrutura

da nuvem são de responsabilidade do autor da pesquisa reprodutível. O qual

precisa manter os contêineres ativos, para permitir o acesso dos leitores e

revisores aos objetos de pesquisa usados e produzidos durante a execução dos

experimentos.

A tecnologia de virtualização de recursos é usada para armazenar os

elementos operacionais utilizados em um experimento computacional. Os

principais objetivos da virtualização são a preservação e a portabilidade do

ambiente operacional usado na produção dos resultados. Isto permite a

publicação, o compartilhamento e a transferência de uma pesquisa do seu

ambiente de origem para um ambiente computacional de destino.

54

A virtualização de recursos dá maior flexibilidade para a reimplantação da

pesquisa, pois permite que outros usuários possam recuperar e reproduzir uma

pesquisa apenas instanciando a(s) imagem(s) Docker e executando o(s)

contêiner(es) nos quais a pesquisa foi encapsulada, agregando maior robustez

no compartilhamento e transferência dos dados.

Os elementos que formam um experimento científico apoiado por

computador são compostos, em geral, por um conjunto de ferramentas de

hardware, software, documentação (digital e física), parâmetros de configurações

e anotações. O resultado e conclusões obtidos com a execução desse

experimento são apreciados em conferências e/ou periódicos especializados.

A Figura 4.1 apresenta a composição desses elementos sob a ótica do

modelo de arquitetura proposto no presente trabalho.

Figura 4.1 - Elementos Envolvidos numa Pesquisa Reprodutível.


O cenário de apoio à reprodução de pesquisas computacionais é composto

por três atores: (i) o pesquisador (autor), o qual é responsável pela publicação e

compartilhamento da pesquisa; (ii) os revisores (periódicos e conferências), os

quais fazem a avaliação dos métodos, artefatos e resultados; e (iii) os leitores

(público em geral), os quais acessam a pesquisa e os artefatos publicados.

Ressalta-se que o fluxo que contempla todas as fases de concepção de

uma pesquisa científica, desde a fase de submissão até as fases de aprovação e

publicação, não será exposto porque já faz parte do cotidiano do pesquisador.

55

Em uma visão geral, o modelo de arquitetura funciona da seguinte maneira:

Um cientista (autor) publica os resultados da sua pesquisa em um artigo científico

que pode ser apresentado nas versões física (papel) e/ou digital aberta (arquivo

*.odt, *.tex, *.html, markdown, entre outros).

Independente da forma de publicação, os resultados são construídos por

meio da combinação de um conjunto de elementos (artefatos), formados em

geral pelas ferramentas de software, aplicativos, bibliotecas, scripts, o conjunto

de dados de entrada e saída e a infraestrutura computacional que representam o

ambiente no qual os experimentos foram conduzidos.

O modelo de arquitetura está dividido em dois ambientes: o ambiente de

produção que pode ser representado por uma estação de trabalho (computador

desktop ou portátil), no qual um experimento foi originalmente criado. E o

ambiente de destino que pode ser representado pela infraestrutura de um

provedor de nuvem.

Um experimento científico consolida-se em um tempo. Essa consolidação

determina que naquele momento, os resultados gerados a partir de um conjunto

de dados de entrada, foram avaliados por revisores, aprovados e posteriormente

publicados e compartilhados por conferências e/ou periódicos especializados

para o público em geral. A partir disso, o procedimento de reprodução do

experimento pode ser realizado.

Diante desse contexto, o modelo de arquitetura proposto agrega os

componentes que implementam cada uma das três tecnologias em sua

arquitetura: a virtualização de recursos, a utilização de contêineres e a

computação em nuvem. O objetivo da abordagem é a disponibilização de

pesquisas computacionais em contêineres de software na infraestrutura de um

provedor de nuvem que possui as tecnologias necessárias para a reprodução de

um experimento, no qual o pesquisador possa tomar decisões sobre quais

artefatos publicar e compartilhar.

As seções seguintes têm por objetivo expor o desenvolvimento do protótipo

que implementa o modelo de arquitetura, a fim de que o mesmo realize as

56

tarefas descritas no capítulo anterior. A próxima seção, por sua vez, descreve os

detalhes da arquitetura e o seu funcionamento.

4.2. Arquitetura

O modelo de arquitetura proposto faz a interação com dois componentes

externos: orquestrador de contêineres Docker e o provedor de computação em

nuvem. Este conjunto de tecnologias é utilizado para auxiliar na criação de

pacotes portáveis dos artefatos das pesquisas por meio de imagens Docker;

autenticar, implantar e compartilhar os contêineres na nuvem; verificar a

reprodução; e ainda, referenciar os artigos publicados em periódicos e/ou

conferências por meio de URL. O objetivo é entregar um ambiente preparado

para a reprodução de uma publicação científica utilizando os recursos de uma

nuvem pública.

A arquitetura proposta juntamente com a sua interação com os ambientes

operacionais são mostradas na Figura 4.2.

Figura 4.2 - Arquitetura do Modelo Proposto.


57

Os ambientes externos ao componente são representados pelos sistemas

de computadores e unidades de armazenamento. O ambiente na nuvem é

representado por uma VM com o Docker em execução. Já o ambiente de origem

pode ser representado tanto por uma infraestrutura de computação física como

uma virtualizada, ambos os casos com o Docker também em execução.

O modelo de arquitetura proposto fica encapsulado em dois ambientes

computacionais diferentes. Em um primeiro momento, ele fica implantado na

estação de trabalho do pesquisador. Em seguida, ele é implantado num provedor

de computação em nuvem. O modelo de arquitetura pode ser acionado por meio

de um browser (navegador web).

O mecanismo de consulta é composto por métodos usados para recuperar

os objetos de pesquisa armazenados nos contêineres de dados e volumes de

dados. Ele recebe a identificação e retorna o objeto de pesquisa associado.

O contêiner de dados armazena os dados e metadados do experimento,

assim como as referências para os conjuntos de arquivos usados como entradas

de dados. Optou-se pelo armazenamento dos arquivos no volume de dados, ou

seja, no próprio sistema de arquivos, guardando no contêiner de dados apenas

as referências, devido ao tamanho dos arquivos de dados.

O volume de dados do modelo de arquitetura usa o diretório de trabalho do

pesquisador para armazenar todos os arquivos relacionados ao experimento. Os

arquivos (objetos de pesquisa) selecionados pelo pesquisador são encapsulados

em uma ou várias imagens Docker para que seja feita a devida transferência

para a nuvem. Em muitos casos, o tamanho dos pacotes com os arquivos pode

ter grandes volumes de dados, no entanto, é necessário fazer a transferência

para fins de compartilhamento dos elementos relacionados com a pesquisa

reprodutível publicada.

O servidor web do modelo de arquitetura, o qual é outro contêiner Docker,

aguarda as requisições para a consulta aos objetos de pesquisa (artefatos)

usados na produção dos resultados. As consultas recuperam os objetos de

pesquisa citados em um documento de código aberto e os apresenta em um

browser, formando uma documentação da pesquisa reprodutível.

As requisições de reprodução aguardam as requisições para a implantação

e reprodução do experimento na conta de usuário interessado na reprodução.

Esse tipo de requisição deve ser acompanhado

provedor de nuvem.

Essas requisições são atendidas pelo

formando por dois componentes: (1) gerenciador de autenticação

navegador de pesquisa reprodutível. O gerenciador de autenticação recebe as

credenciais dos usuários que desejam reproduzir o experimento na nuvem

validando-as no provedor. As credenciais s

contêineres e montar os volumes para armazenamento

para que a partir desse ponto ele possa reproduzir o experimento. O navegador é

responsável pelas atividades relacionadas à consulta e

artefatos e, ainda, permite comandar a reprodução.

A abordagem exige a definição de cada elemento que forma o experimento

e utiliza-se de três ambientes operacionais bem definidos para construir (estação

de trabalho), compartilhar (fornecedores de nuvem) e referenciar

os elementos que compõem o experimento. Cada uma das etapas e ambientes

envolvidos no mecanismo de reprodução está

Figura 4.3 - Etapas e Ambientes Envolvidos n

A abordagem utiliza

reprodução. Essas etapas envolvem a preparação do ambiente na estação de

trabalho do cientista, o armazenamento, publicação e compartilhamento no


produção do experimento na conta de usuário interessado na reprodução.

requisição deve ser acompanhado das credenciais de acesso ao

Essas requisições são atendidas pelo contêiner de aplicação

componentes: (1) gerenciador de autenticação


credenciais dos usuários que desejam reproduzir o experimento na nuvem

no provedor. As credenciais são usadas para

os volumes para armazenamento na conta do requisitante


responsável pelas atividades relacionadas à consulta e à apresentação dos

ainda, permite comandar a reprodução.


se de três ambientes operacionais bem definidos para construir (estação

de trabalho), compartilhar (fornecedores de nuvem) e referenciar


envolvidos no mecanismo de reprodução está representado na Figura

e Ambientes Envolvidos na Arquitetura do Modelo Proposto


A abordagem utiliza-se de três etapas gerais bem distintas para o apoio à



58


produção do experimento na conta de usuário interessado na reprodução.

das credenciais de acesso ao

contêiner de aplicação web. Ele é

componentes: (1) gerenciador de autenticação; e (2)


credenciais dos usuários que desejam reproduzir o experimento na nuvem,

o usadas para executar os

na conta do requisitante


apresentação dos


se de três ambientes operacionais bem definidos para construir (estação

de trabalho), compartilhar (fornecedores de nuvem) e referenciar (servidor web)


na Figura 4.3.

Modelo Proposto.

etapas gerais bem distintas para o apoio à



59

provedor de computação em nuvem e a construção da referência da pesquisa

junto aos seus artefatos via contêiner de aplicação web.

Portanto, os mecanismos usados para a reprodução transitam por

diferentes ambientes operacionais que se comunicam pela Internet. Na primeira

fase, as imagens Docker são enviadas da estação de trabalho do cientista, seja

ela local ou remota, para a nuvem como um espelho do experimento e, em

seguida, o contêiner web aguarda as requisições de referência para acionar os

demais contêineres e executar a reprodução do experimento na nuvem.

Na segunda fase, essas imagens Docker serão usadas no provedor de

nuvem como moldes nos quais outros usuários vão instanciar e implantar as

suas imagens em forma de contêineres, e uma vez implantados, esses

contêineres podem reexecutar a pesquisa consolidada e compartilhada pelo

cientista, ou vão criar novas variações a partir desse modelo. Essas variações

são relacionadas a mudanças nos conjuntos de dados de entrada e parâmetros

de configuração.

Se esses outros usuários, que estão reproduzindo a pesquisa, decidirem

fazer novos testes de parâmetros ou melhorias no experimento, essas

modificações não irão afetar o experimento originalmente compartilhado na

nuvem, mas irão criar uma nova derivação do modelo.

A garantia da integridade do experimento original é feita por meio da

associação de um valor de hash de uma imagem Docker disponibilizada na

nuvem do experimento que irá diferenciar o que foi publicado daquele que foi

reproduzido. Esse valor de hash ajuda a controlar a segurança, pois garante que

os elementos compartilhados foram aqueles usados no experimento, e ainda

permite avaliar o conteúdo dos arquivos de dados reproduzidos, comparando-os

em relação ao conjunto de arquivos da execução original.

Conforme visto nesta seção, o modelo de arquitetura proposto utiliza um

conjunto de tecnologias independentes, tais como Docker e bibliotecas de

fornecedores de nuvem. Diante disso é necessário fazer toda uma preparação do

ambiente antes da sua execução. Essa preparação envolve a instalação do

Docker, limpeza de elementos redundantes no volume de dados que será

60

empacotado (selecionando arquivos e aplicativos que não serão usados no

experimento), obtenção das credenciais de acesso junto ao provedor de nuvem,

dentre outros.

A próxima seção trata os detalhes relacionados à preparação do ambiente.

4.3. Preparação do Ambiente

Esta seção tem por objetivo descrever o protótipo que implementa o modelo de

arquitetura proposto, desenvolvido na linguagem Hypertext Preprocessor

(PHP15), com o sistema de banco de dados MySQL16 e utilizando contêineres

Docker como plataforma-base da sua arquitetura, destacando o ambiente, as

tecnologias e as estratégias utilizadas para o seu desenvolvimento.

A abordagem proposta atua em uma solução projetada e consolidada por

um pesquisador, ou seja, o ambiente de execução já deve ser previamente

preparado para executar a pesquisa completa. A preparação do ambiente é

responsabilidade do pesquisador, o qual detém autonomia e total conhecimento

sobre a sua pesquisa. Desse modo, fez-se necessário apenas o Docker em

pleno funcionamento para que a abordagem pudesse funcionar.

Para definição do ambiente de múltiplos contêineres utilizou-se o Docker

Compose17. Este foi imprescindível para facilitar e simplificar o processo de

configuração e gerenciamento do ambiente, o qual é composto por três

contêineres: um servidor web Apache com PHP, um servidor de banco de dados

MySQL e uma aplicação PHP. Optou-se por utilizar um sistema de banco de

dados relacional, mas o modelo de arquitetura proposto possibilita também a

utilização de outros sistemas, a exemplo do NoSQL.

Nas seções seguintes, serão abordados a diferença entre imagem e

contêiner, os detalhes dos arquivos de configuração do ambiente e a

15

http://php.net 16

https://dev.mysql.com 17 https://docs.docker.com/compose

comunicação entre os contêineres

compreensão da aplicação prática deste trabalho.

4.3.1. Diferença entre Imagem e Contêiner

Fazendo uma analogia

representa uma classe e o

da infraestrutura em um estado

instanciado. Todo cont

conclui-se que nunca se

O Docker mantém e disponibiliza em sua nuvem imagens oficiais e não

oficiais. O objetivo das imagens oficiais é prover um ambiente básico (

Debian, Ubuntu, Ruby, P

partida para a criação de imagens pelos usuários.

mantidas pelos usuários que as criaram

O processo de criação de uma nova im

arquivo Dockerfile (ver Figura 4.5)

determinada imagem, aqui

deseja criar. Dessa forma é

imagem base e registrar

Figura 4.4 mostra as etapas envolvidas no processo.

Figura 4.4 -

comunicação entre os contêineres, de modo que tal base conceitual

compreensão da aplicação prática deste trabalho.

Diferença entre Imagem e Contêiner

com o conceito de orientação a objetos (OO)

uma classe e o contêiner um objeto, ou seja, a imagem é a abstração

da infraestrutura em um estado somente leitura de onde o contê

contêiner é iniciado a partir de uma imagem, dessa forma

se terá uma imagem em execução, mas sim um contêiner


O objetivo das imagens oficiais é prover um ambiente básico (

Ubuntu, Ruby, Python, MariaDB, dentre outros) que serve de ponto de

criação de imagens pelos usuários. As imagens não oficiais são

mantidas pelos usuários que as criaram e enviaram para a nuvem do Docker

O processo de criação de uma nova imagem foi realizado por meio de um

(ver Figura 4.5), o qual representa a diferença exata

determinada imagem, aqui denominada imagem base, e a nova imagem que se

Dessa forma é possível ter noção exata das mudanças

e registrar as modificações no sistema de controle de versão

mostra as etapas envolvidas no processo.

- Processo de Criação de uma Nova Imagem Docker


61

conceitual facilite a

s (OO), a imagem

objeto, ou seja, a imagem é a abstração

somente leitura de onde o contêiner será

uma imagem, dessa forma

, mas sim um contêiner.


O objetivo das imagens oficiais é prover um ambiente básico (Ex:

) que serve de ponto de

As imagens não oficiais são

a nuvem do Docker.

agem foi realizado por meio de um

exata entre uma

imagem que se

das mudanças efetuadas na

modificações no sistema de controle de versão. A

Processo de Criação de uma Nova Imagem Docker.

62

Quando se utiliza um arquivo Dockerfile para gerar uma nova imagem,

basicamente é apresentada uma lista de instruções que serão aplicadas em uma

determinada imagem para que outra seja gerada com base nessas instruções.

Caso haja dependência entre alguma instrução, essa dependência deve

estar mais acima no arquivo Dockerfile. Pois este é sempre lido como abordagem

top-down, ou seja, de cima para baixo e cada linha é executada por vez. Mais

detalhes serão vistos na próxima seção, a qual trata dos arquivos de

configuração do ambiente.

4.3.2. Estrutura de Diretórios e Arquivos de Configuração

Primeiramente, para que o ambiente possa funcionar corretamente é necessário

que seja criado um diretório raiz, aqui denominado diretório da pesquisa. A

Figura 4.5 apresenta um esquema básico da estrutura recomendada.

Figura 4.5 - Estrutura Recomendada para o Diretório da Pesquisa.


Na raiz da estrutura deve conter dois subdiretórios: um para armazenar os

arquivos do banco de dados da pesquisa e o outro subdiretório para

armazenamento dos arquivos da aplicação e também dos arquivos e

subdiretórios usados e gerados durante a execução da pesquisa.

Além disso, dois arquivos de configuração devem ser criados na raiz do

diretório da pesquisa para a composição deste ambiente. O conteúdo de ambos

arquivos é mostrado nas figuras 4.6 e 4.7, respectivamente.

63

Figura 4.6 - Conteúdo do Arquivo Dockerfile.


O conteúdo do próximo arquivo, apresentado na Figura 4.7, é do tipo

YAML, ou seja, é usado para serialização de dados de forma similar a arquivos

JSON ou XML, sendo que assim como em Python ou Haml18, a identação do

arquivo indica a hierarquia.

Figura 4.7 - Conteúdo do Arquivo docker-compose.yml.


Percebe-se nas figuras 4.6 e 4.7 que o arquivo Dockerfile possui quatro

linhas, contendo uma instrução em cada e que o arquivo docker-compose.yml

18 http://haml.info

64

possui vinte e cinco linhas. O detalhamento sobre estes dois arquivos estão nas

próximas seções, as quais apresentam cada contêiner individualmente.

4.3.3. Contêiner Web

O contêiner web, como o próprio nome indica, é o responsável por disponibilizar

um servidor web para hospedagem da pesquisa completa. Todas as linhas do

arquivo Dockerfile, representado pela Figura 4.6, estão relacionadas à criação

deste contêiner, onde:

Na linha 1 - O FROM informa qual imagem foi utilizada como base;

Na linha 2 - O RUN executa um comando para instalar e ativar a

extensão mysqli no PHP; e

Nas linhas 3 e 4 - O COPY copia os arquivos de configuração do

ambiente para dentro da nova imagem criada.

O arquivo docker-compose.yml, representado pela Figura 4.7, também está

relacionado à criação do contêiner web. De acordo com suas linhas 1 a 4:

A linha 1 - Representa o nome do contêiner;

A linha 2 - Executa as instruções do arquivo Dockerfile para criar

uma nova imagem; e

As linhas 3 e 4 - Definem o mapeamento de portas. A porta 80 do

host foi mapeada para a porta 80 do contêiner. Se a referida porta já

estivesse sendo utilizada por algum serviço no host, outra porta

disponível poderia ser usada.

Adicionalmente, as linhas 5 e 6 fazem o mapeamento de um volume de

dados para o contêiner, ou seja, o subdiretório ./www da estrutura foi mapeado

para o diretório /var/www/html do contêiner. Neste volume de dados foram

armazenados: o documento final, os artefatos e a aplicação de gerenciamento da

pesquisa (ver Seção 5.3.3).

65

4.3.4. Contêiner de Banco de Dados

Este contêiner possui a atribuição de disponibilizar um servidor para

armazenamento do banco de dados da pesquisa. As linhas 9 a 17 do arquivo

docker-compose.yml são para criação deste contêiner, onde:


A linha 10 - Informa qual a imagem que foi utilizada;

As linhas 11 e 12 - Definem o mapeamento de portas. A porta 3306

do host foi mapeada para a porta 3306 do contêiner;

As linhas 13 e 14 - Fazem o mapeamento de um volume de dados,

ou seja, o subdiretório ./data da estrutura foi mapeado para o

diretório /var/lib/mysql possibilitando a persistência dos dados entre

contêineres; e

As linhas 15 a 17 - Atribuem uma senha para o administrador e um

nome para o banco de dados da pesquisa.

Logo que o ambiente da pesquisa estiver em execução, o script de criação

das tabelas do banco de dados, o qual se encontra no diretório da pesquisa,

pode ser executado por meio da aplicação apresentada na próxima seção.

4.3.5. Contêiner de Aplicação

A função deste contêiner é disponibilizar uma aplicação para facilitar o

gerenciamento do banco de dados da pesquisa. As linhas 18 a 23 do arquivo

docker-compose.yml estão relacionadas à criação deste contêiner, onde:


A linha 19 - Informa qual imagem foi utilizada;

As linhas 20 e 21 - Definem o mapeamento de portas. Neste caso a

porta 81 do host foi mapeada para a porta 80 do contêiner; e

As linhas 22 e 23 - Configuram as variáveis de ambiente.

Percebe-se que o referido arquivo possui ainda as linhas 7 a 8 e 24 a 25

com o mesmo conteúdo. As instruções dessas linhas servem para conectar os

66

contêineres web e app (aplicação), respectivamente, ao contêiner db (banco de

dados). Com isso, as aplicações podem se conectar no banco de dados, realizar

toda a configuração inicial e viabilizar o ambiente completo.

A seção seguinte explana os detalhes de execução do ambiente na nuvem.

4.4. Execução do Ambiente na Nuvem

Foram selecionados quatro provedores de nuvem: Amazon Web Services

(AWS)19, Google Cloud Plataform20, Microsoft Azure21 e Docker Cloud22 para

testar a abordagem, a qual está apta a operar em qualquer uma dessas

plataformas. Ademais, para detalhar este cenário prático foi escolhido o driver23

da nuvem mais popular, ou seja, da AWS.

De início foi criada uma conta de usuário na AWS, em seguida criou-se o

arquivo ~/.aws/credentials na raiz do diretório de usuário do pesquisador, no seu

ambiente local de trabalho, para armazenamento das credenciais de acesso

(AWS Access Key Id e AWS Secret Access Key) ao serviço Amazon EC2. O

conteúdo do arquivo credentials é mostrado na Figura 4.8:

Figura 4.8 - Arquivo com Exemplo de Credenciais de Acesso ao Serviço da AWS.


Segundo a AWS, a interface de configuração do serviço Amazon EC2 é

simples e intuitiva. Pois, oferece controle completo dos recursos e reduz o tempo

exigido para obter e inicializar novas instâncias do servidor, permitindo o rápido

escalonamento da capacidade para mais e para menos, à medida que os

recursos são alterados. Além disso, o serviço fornece ferramentas para criar 19

https://aws.amazon.com/pt/ec2 20

https://cloud.google.com/container-engine 21

https://azure.microsoft.com/pt-br/services/container-service 22

https://cloud.docker.com 23 https://docs.docker.com/machine/drivers/aws

67

aplicações resistentes e isoladas de cenários comuns de falhas, além de permitir

que se pague apenas pelos recursos excedentes utilizados.

Portanto, após o ambiente estar com todos os requisitos previamente

atendidos, contendo as credenciais e os arquivos de permissão para integração

com os provedores de nuvem, ele ficou pronto para iniciar a sua execução.

Uma instância do ambiente da pesquisa foi criada na nuvem por meio da

execução do comando docker-machine create --driver amazonec2 cloud_web no

terminal do Docker. Após a execução do referido comando, todo o software

necessário foi automaticamente instalado no novo ambiente, o qual foi acessado

por meio do comando eval $(docker-machine env cloud_web).

Depois das etapas de preparação do ambiente na nuvem, o próximo passo

foi navegar até a raiz do diretório da pesquisa, local onde estão armazenados os

arquivos de configuração do ambiente, e executar o comando docker-compose

up -d para colocar todos os contêineres do ambiente em execução: web,

aplicação e dados. As características de armazenamento dos dados seguiram

algumas propostas de Junqueira (2015) e as recomendações de boas práticas

para publicação de dados na web, de Lóscio et al. (2016).

Com este ambiente inicializado e em execução, as informações da

pesquisa foram cadastradas, assim como o documento final e os artefatos foram

anexados, publicados e compartilhados publicamente. Mais detalhes sobre cada

uma destas etapas serão abordados no Capítulo 5.

Na próxima seção, as principais atividades do modelo de arquitetura serão

explanadas.

4.5. Principais Atividades

Nesta seção, as principais atividades realizadas pela abordagem são descritas.

Na Figura 4.9, apresenta-se o diagrama de Casos de Uso modelado por meio da

68

Unified Modeling Language (UML)24, para ajudar a descrever as principais

funcionalidades do protótipo e a interação do usuário com o ambiente.

Figura 4.9 - Diagrama de Casos de Uso - Ator: Pesquisador.


Cadastrar Pesquisa: Permite o cadastro das principais informações

relacionadas à catalogação da pesquisa (título, autor, resumo,

palavras-chave e Digital Object Identifier - DOI25);

Anexar Documento: Possibilita que o documento final da pesquisa

(aprovado após as correções) seja anexado;

Anexar Artefatos: Funcionalidade que contempla a indexação dos

artefatos associados ao documento final da pesquisa;

Publicar Pesquisa: Recurso que disponibiliza a pesquisa completa

junto aos artefatos na nuvem de modo a permitir acesso público; e

Executar Pesquisa: Fornece a possibilidade de execução do

ambiente da pesquisa completa na nuvem.

24

http://www.uml.org 25 https://www.doi.org

69


Este capítulo apresentou a abordagem proposta por meio do protótipo que

implementou o modelo de arquitetura para disponibilização de pesquisas

computacionais e seus artefatos em contêineres de software em nuvem. Foram

explanadas as etapas necessárias para a concepção do protótipo, destacando-se

os aspectos técnicos em detalhes, desde o processo de criação do ambiente de

origem da pesquisa até o seu ambiente de destino na nuvem.

O próximo capítulo apresenta a análise realizada por meio de um estudo de

caso com o modelo de arquitetura proposto, objetivando avaliar o protótipo

desenvolvido, bem como apresentar os resultados da avaliação.

70

5. UM ESTUDO DE CASO PARA AVALIAÇÃO DA ABORDAGEM

Este capítulo implementa um estudo de caso por meio da utilização de

plataformas de publicações existentes e do modelo de arquitetura proposto. Para

tanto, foi utilizado o domínio de uma aplicação para publicação de uma pesquisa

científica completa, fundamentada na possibilidade de utilização pelo próprio

pesquisador, ou seja, sem a necessidade de interferência de terceiros.

5.1. Introdução

A realização de um estudo de caso não é uma tarefa fácil, exige tempo e

dedicação do pesquisador e, frequentemente, os trabalhos estão sujeitos a

críticas em função de limitações metodológicas na escolha do(s) caso(s), análise

dos dados e geração de conclusões apoiadas pelas evidências (MIGUEL, 2007).

De acordo com Wohlin et al. (2012), uma das formas de realizar um estudo

de caso é comparando projetos similares. Nesse caso, o estudo é aplicado em

projetos semelhantes, sendo que um deles utiliza tecnologia ou método novo

proposto, enquanto os outros utilizam tecnologias ou métodos já conhecidos.

As etapas utilizadas na implementação deste estudo de caso foram: 1)

Planejamento (definição dos objetivos, questões do estudo, contexto de

aplicação e definições do protocolo e instrumentos para o seu desenvolvimento);

2) Desenvolvimento (execução do estudo de caso a partir dos procedimentos

definidos na etapa de planejamento); e 3) Análise e Resultados, nos quais se

discorre a respeito da avaliação e análise do estudo, identificando os principais

pontos relacionados às questões definidas também na etapa de planejamento.

Como domínio de aplicação para o estudo de caso em questão, foram

utilizados os requisitos de uma aplicação para publicação de uma pesquisa

científica completa, ou seja, contendo a versão final do documento da pesquisa,

aprovado após correções, mais os artefatos relevantes associados a ela. A

seleção dos artefatos relevantes da pesquisa, bem como a utilização da

aplicação para a realização das publicações ficaram a cargo do pesquisador, o

qual detém total conhecimento e responsabilidade sobre a sua pesquisa.

71

5.2. Planejamento

Esta seção aborda o planejamento deste estudo, incluindo seus objetivos,

questões do estudo, contexto de aplicação e, por fim, são detalhados os

instrumentos e o protocolo utilizados na sua operacionalização.

5.2.1. Objetivos

O principal objetivo deste estudo de caso foi realizar a comparação de

plataformas de publicações existentes com o modelo de arquitetura proposto

neste trabalho. Esta comparação investigou a viabilidade do modelo de

arquitetura proposto no auxílio a pesquisadores para disponibilizar pesquisas

computacionais e seus artefatos em contêineres de software em nuvem.

Além disso, o modelo de arquitetura permitiu ao pesquisador tomar

decisões sobre quais artefatos publicar e compartilhar. Assim como também foi

possível verificar, dentre outras, as funcionalidades de portabilidade e execução

da pesquisa.

5.2.2. Questões do Estudo

Para uma efetiva condução deste estudo, as seguintes questões foram definidas:

Questão 1: Quais plataformas analisadas permitiram o cadastro das

informações relacionadas à pesquisa?

Questão 2: Quais plataformas analisadas permitiram que o

documento final da pesquisa fosse anexado?

Questão 3: Quais plataformas analisadas permitiram que os

artefatos relevantes da pesquisa fossem anexados?

Questão 4: Quais plataformas analisadas permitiram a

disponibilização da pesquisa completa na nuvem?

Questão 5: Quais plataformas analisadas permitiram a execução do

ambiente da pesquisa na nuvem?

72

A seguir, será apresentado o contexto do domínio da aplicação.

5.2.3. Contexto de Aplicação

O contexto de aplicação deste estudo de caso partiu da premissa de que todo

pesquisador deve ser capaz de produzir e divulgar a sua pesquisa.

Uma pesquisa científica consolida-se em algum tempo. Essa consolidação

determina que naquele momento, os resultados gerados foram avaliados por

revisores, e quando aprovados, posteriormente publicados em conferências e/ou

periódicos especializados.

Nesse contexto buscou-se manter o pesquisador na sua zona de conforto,

o mais próximo possível da sua realidade, ao permitir a utilização do seu próprio

ambiente de trabalho para a concepção do cenário de origem da pesquisa. À

exceção do ambiente de destino, o qual permitiu a portabilidade e a execução da

pesquisa na nuvem, culminando em uma transição planejada e com resultados

de impactos positivos.

A próxima seção descreve o protocolo e os instrumentos necessários para

a operacionalização do estudo.

5.2.4. Protocolo e Instrumentos

O protocolo de um estudo de caso serve como um guia e descreve a lista de

procedimentos a serem aplicados para realizar o estudo. Para tanto, a utilização

de um protocolo é essencial para garantir a confiabilidade da pesquisa e serve de

orientação ao pesquisador na coleta de dados (YIN, 2005).

O protocolo também serve como um checklist, um roteiro que o

pesquisador deve seguir a fim de levantar todos os aspectos propostos na

pesquisa (VOSS; TSIKRIKTSIS; FROHLICH, 2002). O estudo de caso descrito

neste trabalho objetivou investigar a viabilidade da abordagem proposta para

73


de software em nuvem.

A seleção das plataformas utilizadas foi baseada em consultas por

ferramentas gratuitas voltadas para a comunidade científica e fundamentadas na

possibilidade de utilização pelo próprio pesquisador, sem a necessidade da

interferência de terceiros. Para tanto, foram selecionados o GitHub26, Dropbox27 e

a abordagem proposta neste trabalho para o desenvolvimento deste estudo

conforme seu contexto de aplicação, o qual foi descrito na seção anterior.

Vale citar uma quarta plataforma, denominada Sistema para Construção de

Repositórios Institucionais Digitais (DSpace)28 que também seria uma potencial

plataforma de estudo, mas fugiu do escopo deste trabalho, o qual visou e buscou

ferramentas que pudessem ser de fato utilizadas pelo próprio pesquisador.

Depois da seleção das plataformas que foram utilizadas, analisou-se o

Espectro de Reprodutibilidade, proposto inicialmente por Peng (2011) e em

seguida foi traduzido/adaptado por Pinheiro (2013) e concluiu-se que o modelo

de arquitetura deveria contemplar o fluxo de processo, a ser executado em cada

uma das plataformas do estudo, conforme expõe a Figura 5.1.

Figura 5.1 - Fluxo de Processo do Modelo de Arquitetura Proposto.


26

https://github.com 27

https://www.dropbox.com 28 http://www.ibict.br/dspace

74

Quanto aos instrumentos e software necessários para a execução deste

estudo de caso, foram utilizados:

Computador portátil com os seguintes recursos: Processador

Intel(R) Core(TM) i7 CPU 5500U de 2.40 GHz, 8 GB de memória

RAM, 500 GB de HD, executando o sistema operacional Windows 7

na versão 64 bits;

Ambiente Docker Toolbox na versão 17.07.0-ce para Windows. Esse

ambiente foi necessário para a execução da abordagem proposta

neste trabalho;

Três imagens/contêineres Docker: php:5.6-apache, mysql:5.7 e

phpmyadmin/phpmyadmin:latest, disponíveis no repositório oficial:

https://hub.docker.com. A escolha destas tecnologias foi motivada

pela popularidade e facilidade de uso;

Dropbox (interfaces web e desktop) para a realização das etapas

propostas no fluxo;

GitHub (interfaces web e de linha de comando) para a execução das

etapas propostas no fluxo; e

Abordagem proposta (interfaces de linha de comando, desktop e

web) para a execução e gerenciamento de cada uma das etapas

propostas no fluxo.

Na seção seguinte, serão explanadas em detalhes as tarefas executadas

para a realização do desenvolvimento do estudo de caso.

5.3. Desenvolvimento do Estudo de Caso

O desenvolvimento deste estudo ocorreu conforme os procedimentos previstos

no protocolo, ou seja, efetuando a execução das etapas propostas, verificando se

a execução foi completa, parcial ou a não-execução.

Foram selecionadas três plataformas de publicação, cujos estudos

obtiveram os resultados descritos a seguir.

75

5.3.1. Execução no Dropbox

O Dropbox é um serviço de armazenamento pessoal em nuvem (Personal Cloud

Storage) que está cada dia mais popular, tanto entre usuários domésticos quanto

corporativos, e também têm atraído a atenção de pesquisadores.

É um serviço que oferece algumas vantagens a seus usuários, os quais

podem eliminar praticamente toda a sua infraestrutura de armazenamento,

confiando somente em servidores remotos. Além disso, a migração para esse

tipo de serviço não requer grandes investimentos. Usuários passam a contar com

replicação (backup) e compartilhamento de dados via Internet de forma

transparente e flexível.

Na plataforma há mais de 3 bilhões de conexões, conforme mostra a

Figura 5.2, que são criadas por meio de pastas e links compartilhados.

Figura 5.2 - Total de Conexões Criadas no Dropbox.

Fonte: Dropbox Business (https://www.dropbox.com/business/customers)

O Dropbox está disponível para acesso em: https://www.dropbox.com. As

principais funcionalidades da referida plataforma são:

Possibilita o armazenamento e o compartilhamento de arquivos e

diretórios na nuvem;

Realiza a sincronização de arquivos e diretórios; e

Permite a consulta a informações de arquivos e diretórios.

Aplicou-se o fluxo do processo proposto na Seção 5.2.4, que condiz com o

domínio de aplicação aqui utilizado e registrou-se o comportamento da

plataforma descrito a seguir.

76

A plataforma contemplou a realização completada da Etapa 1, pois

possibilitou o cadastro das informações relacionadas à produção científica do

pesquisador, concedendo-lhe autonomia e responsabilidade sobre a veracidade

das informações inseridas no arquivo de texto, o qual foi criado e armazenado no

diretório da pesquisa.

No que se refere às funcionalidades das etapas 2 e 3, realizou-se o envio

do documento final junto aos arquivos (artefatos) pela interface web do Dropbox

(ver Figura 5.3). Ambas as etapas também puderam ser realizadas pela

aplicação desktop. Na execução dessas funcionalidades, verificou-se que o

Dropbox também conseguiu realizar a demanda sem apresentar erros.

Figura 5.3 - Documento Final e Artefatos da Pesquisa no Dropbox.


Dando sequência aos procedimentos do protocolo (Seção 5.2.4), verificou-

se que a plataforma também contemplou a Etapa 4, no sentido de possibilitar ao

pesquisador publicar e compartilhar a sua pesquisa completa na nuvem. A Figura

5.4 apresenta a tela de compartilhamento da pesquisa.

77

Figura 5.4 - Tela de Compartilhamento da Pesquisa no Dropbox.


A etapa 5 não foi contemplada pelo Dropbox, pois apesar de possibilitar o

compartilhamento do diretório da pesquisa, não permitiu a execução do ambiente

da pesquisa na nuvem.

Por fim, no que condiz ao pleno funcionamento da plataforma, verificou-se

que ela não apresentou erros que prejudicassem a sua utilização.

5.3.2. Execução no GitHub

O GitHub é uma plataforma de hospedagem de código-fonte de projetos. Ele

permite que programadores ou qualquer usuário cadastrado na plataforma criem

e contribuam com projetos de qualquer lugar do mundo. É amplamente utilizado

por programadores que divulgam e compartilham seus trabalhos para que outras

pessoas possam contribuir.

No GitHub tem mais de 25 milhões de usuários ativos do mundo inteiro,

contribuindo em projetos pessoais ou comercias. Além de abrigar mais de 70

milhões de repositórios (projetos) mundialmente, como mostra a Figura 5.5.

78

Figura 5.5 - Dados Estatísticos Apresentados pelo GitHub.

Fonte: Github (https://github.com).

O uso do GitHub foi iniciado com o cadastro das informações básicas

relacionadas ao repositório (pesquisa). Nesse sentido, apesar da plataforma não

possuir campos específicos para essa finalidade, conseguiu atender ao propósito

da Etapa 1, possibilitando a realização da tarefa de forma ágil e prática, como

mostra a Figura 5.6.

Figura 5.6 - Tela de Cadastro da Pesquisa no GitHub.


79

No que se refere às funcionalidades das etapas 2 e 3, realizou-se o envio

do documento final junto aos arquivos (artefatos) pela interface gráfica da

plataforma (ver Figura 5.7). Ambas as etapas também puderam ser realizadas

pela interface de linha de comando, por meio da execução de comandos git29. Na

execução dessas funcionalidades, verificou-se que o GitHub também conseguiu

realizar a demanda sem apresentar erros.

Figura 5.7 - Tela de Inclusão dos Artefatos e Documento da Pesquisa no GitHub.


Dando sequência aos procedimentos do protocolo (Seção 5.2.4), verificou-

se que a plataforma também contemplou a Etapa 4, no sentido de possibilitar ao

pesquisador publicar e compartilhar a sua pesquisa completa na nuvem. Em

relação à pesquisa, a plataforma permitiu acessar pelo navegador de Internet,

clonar (copiar) por meio do comando git clone nomedorepositorio e fazer o

download de um pacote compactado em formato zip, como mostra a Figura 5.8.

29 https://git-scm.com

80

Figura 5.8 - Tela de Acesso à Pesquisa Completa no GitHub.


O estudo com a plataforma GitHub foi finalizado quando investigou-se a

possibilidade do pesquisador colocar o ambiente da pesquisa em execução na

nuvem, para fins de realização de experimentos.

Apesar de a plataforma oferecer gratuitamente o GitHub Pages30 que é um

serviço de hospedagem de sites estáticos (html, css, js e imagens), ele não dá

suporte a aplicações que executam códigos server-side, ou seja, do lado do

servidor, como é o caso do PHP, Ruby ou Python, por exemplo. Além disso, o

serviço não dá suporte à persistência de dados e possui algumas limitações de

armazenamento, tráfego de dados, dentre outras. Motivos pelos quais se

constatou que a plataforma não contemplou a funcionalidade da Etapa 5.

Por fim, durante a execução dos procedimentos deste estudo, não foi

encontrado qualquer erro no GitHub que comprometesse a sua plena utilização.

5.3.3. Execução no Modelo de Arquitetura Proposto

Conforme apresentado nos capítulos 3 e 4 deste trabalho, o modelo de

arquitetura aqui proposto utiliza a computação em nuvem e os contêineres

Docker como plataformas-base na sua arquitetura de funcionamento. O Docker

30 https://pages.github.com

81

possui mais de 500 mil aplicações em contêineres (ver Figura 5.9), dentre as

quais foram selecionadas algumas para a composição, adaptação e concepção

do modelo de arquitetura proposto.

Figura 5.9 - Dados Estatísticos Apresentados pelo Docker.

Fonte: Docker (https://www.docker.com).

Além disso, um fluxo básico de processo foi definido (ver Figura 5.1 e

utilizado como referência. Este fluxo é composto de cinco etapas, as quais foram

executadas pelo próprio pesquisador, de acordo com o planejamento deste

estudo de caso. São elas:

O pesquisador cadastra as informações relacionadas à pesquisa

(titulo, autor(es), resumo, palavras chaves e DOI);

O pesquisador anexa o documento final (aprovado após correções);

O pesquisador anexa os artefatos da pesquisa (selecionados como

relevantes);

O pesquisador disponibiliza a pesquisa completa na nuvem (público

em geral acessa e/ou compartilha); e

O pesquisador executa o ambiente da pesquisa (execução da

pesquisa na nuvem).

O procedimento para a realização das etapas 2 e 3 foi praticamente o

mesmo para as duas etapas, no qual criou-se um novo diretório (pasta) dentro do

perfil de usuário do pesquisador. Este novo diretório, denominado diretório da

pesquisa foi criado para organizar e abrigar o documento final da pesquisa junto

aos artefatos que a compõem. A princípio o documento final foi copiado para o

diretório da pesquisa, contemplando satisfatoriamente a Etapa 2.

82

Como já citado anteriormente, para a consolidação completa da Etapa 3 foi

imprescindível que o pesquisador utilizasse do seu conhecimento para fazer a

seleção dos artefatos mais relevantes da sua pesquisa. Após o processo de

triagem dos artefatos, estes também foram copiados para o diretório da

pesquisa, consolidando também de forma satisfatória a Etapa 3.

Percebe-se que até então as tarefas realizadas para criação do diretório da

pesquisa e cópia dos arquivos mencionados são nativas e inerentes a qualquer

sistema operacional, dispensando inclusive a representação gráfica. Entretanto,

para as próximas etapas, as funcionalidades do modelo de arquitetura aqui

proposto foram de fato utilizadas e exploradas.

A Etapa 5 propôs ao pesquisador colocar o seu ambiente de pesquisa em

execução na nuvem. Para essa tarefa foi realizada a assinatura de um serviço de

nuvem. Mesmo que uma pesquisa científica tenha sido definida em um provedor

de nuvem é possível migrar para outros que possuem suporte ao Docker.

Ainda nessa etapa, o modelo de arquitetura proposto utilizou, no contêiner

de aplicação, arquivos com código da linguagem PHP, a qual por padrão tem sua

execução do lado do servidor.

A Figura 5.10 mostra o ambiente da pesquisa que foi colocado em

execução por meio do comando docker-compose up -d no terminal do Docker.

Apesar de não ser uma interface muito amigável, ela permitiu a execução de

vários comandos de gerenciamento.

Figura 5.10 - Ambiente em Execução via Interface de Linha de Comando.


83

Analogamente, a Figura 5.11 apresenta o mesmo ambiente em execução,

porém numa interface gráfica mais intuitiva, a qual possibilitou ao pesquisador

um gerenciamento mais confortável do seu ambiente de pesquisa.

Figura 5.11 - Ambiente em Execução via Interface Gráfica.


Com a pesquisa em execução na nuvem (Etapa 5), a abordagem proposta

foi avaliada para a realização da Etapa 1, a qual foi inteiramente contemplada de

maneira prática, ágil e intuitiva, pois possibilitou a inserção dos dados

relacionados à produção científica do pesquisador. A tela de cadastro dos dados

da pesquisa foi exibida automaticamente para preenchimento das informações

necessárias, conforme mostra a Figura 5.11.

Além dos campos principais, a tela de cadastro da pesquisa apresenta um

campo adicional de preenchimento obrigatório que permite, por exemplo, a

referência para o Currículo Lattes31 do pesquisador e outro não obrigatório, como

o campo para referência aos grupos de pesquisa que ele participa. O Currículo

31 http://lattes.cnpq.br

84

Lattes se tornou um padrão nacional para o registro da vida acadêmica e

profissional de estudantes e pesquisadores. Ele é adotado pela maioria das

instituições de fomento, universidades e institutos de pesquisa do País.

Depois do preenchimento do formulário com as informações da pesquisa,

todos os artefatos relacionados a ela foram exibidos, inclusive o documento final.

Seguiu-se para a Etapa 4, na qual foi analisada a possibilidade da

abordagem proposta permitir ao pesquisador publicar e compartilhar a sua

pesquisa completa na nuvem (documento final junto aos artefatos relevantes) e

conceder acesso ao público em geral.

Essa etapa também foi realizada de maneira satisfatória, pois permitiu a

disponibilização da pesquisa na nuvem com acesso por meio do navegador de

Internet, seguindo as recomendações de boas práticas para publicação de dados

na Web, de Lóscio et al. (2016) e algumas propostas de Junqueira (2015).

Além disso, foi possível baixar a pesquisa completa encapsulada em 4

imagens Docker (ver Figura 5.12). Isso garantiu a portabilidade de todo o

ambiente da pesquisa. Este ambiente poderia ter sido encapsulado em apenas

uma imagem Docker, mas para fins didáticos, optou-se por utilizar mais de uma.

Figura 5.12 - Imagens Docker com a Pesquisa Completa Encapsulada.


85

Por conseguinte, como complemento ao estudo de caso, realizou-se a

persistência de dados fictícios de uma pesquisa no contêiner de dados. Foram

inseridos registros em cada uma das tabelas que compõem a abordagem

proposta e em seguida, executou-se uma consulta com o termo "docker" na

tabela pesquisas do banco de dados do modelo de arquitetura. Logo após, na

interface de linha de comando, foi executado o comando grep -rin "docker"

diretoriodapesquisa, utilizando o mesmo termo de busca "docker", mas ao invés

de buscar no banco de dados, buscou-se dentro dos arquivos (artefatos) da

pesquisa.

Para a realização de todas as etapas propostas, o modelo de arquitetura

mostrou-se robusto e não apresentou falhas ou erros que comprometessem a

sua utilização.

5.4. Análise e Resultados

Os resultados gerados pelo estudo de caso descrito neste trabalho foram

analisados de acordo com as 5 questões norteadoras (Seção 5.2.2) definidas na

fase de planejamento. O Quadro 5.1 mostra cada questão e compara a sua

viabilidade para cada caso aplicado.

Quadro 5.1- Quadro Demonstrativo da Análise das Questões do Estudo.

Questões Dropbox GitHub Abordagem proposta

1) Permitiu o cadastrodas informações relacionadas à pesquisa?

Sim Sim Sim

2) Permitiu que o documento final da pesquisa fosse anexado?

Sim Sim Sim

3) Permitiu que os artefatos relevantes da pesquisafossem anexados?

Sim Sim Sim

4) Permitiu a disponibilizaçãoda pesquisa completa na nuvem?

Sim Sim Sim

5) Permitiu a execução do ambiente da pesquisa na nuvem?

Não Não Sim

Fonte: Elaborado pelo Autor (2017).

Verifica-se no Quadro 5.1 que em relação à possibilidade de cadastro das

informações da pesquisa, todas as plataformas analisadas forneceram esse

suporte. No tocante à segunda questão, que analisou a possibilidade de

publicação do documento final da pesquisa, observou

plataformas contemplaram

Comportamento parecido foi percebido durante a realização da

das Questões 3 e 4, a

publicação dos artefatos da pesquisa

pesquisa completa (documento final e artefatos relevantes) na nuvem, quando

constatou-se mais uma vez que

Ademais, apesar do

questões de 1 a 4 em paralelo à abordagem proposta neste trabalho, na Questão

5, foi avaliada a possibilidade de execução do ambiente da pesquisa na nuvem e

concluiu-se que a abordagem aqui proposta foi a única que possibilitou es

suporte, o que a diferencia das

Para uma melhor compreensão d

plataformas em estudo, a Figura 2.1

origem à Figura 5.13, a qual demonstra

cada plataforma está próxima ou distante do padrão desejado.

Figura 5

De uma maneira geral,

compartilhamento e sincronização de arquivos e diretórios

por sua vez, foca nos artefatos de uma forma

publicação do documento final da pesquisa, observou-se também

contemplaram essa funcionalidade.

Comportamento parecido foi percebido durante a realização da

, as quais verificaram, respectivamente, a possibilidade de

publicação dos artefatos da pesquisa, e a possibilidade de disponibilização da

isa completa (documento final e artefatos relevantes) na nuvem, quando

se mais uma vez que todas as plataformas ofereceram esse suporte.

Ademais, apesar do Dropbox e do GitHub terem dado suporte completo às



se que a abordagem aqui proposta foi a única que possibilitou es

suporte, o que a diferencia das demais.

uma melhor compreensão da análise comparativa entre as

lataformas em estudo, a Figura 2.1 de Pinheiro (2013) foi adap

, a qual demonstra numa escala de zero a cem,

a plataforma está próxima ou distante do padrão desejado.

5.13 - Espectro da Reprodutibilidade em Escala.

Fonte: Adaptada de Pinheiro (2013).

De uma maneira geral, o Dropbox possui foco no armazenamento

e sincronização de arquivos e diretórios na nuvem

por sua vez, foca nos artefatos de uma forma mais abrangente, e o modelo

86

também que as três

Comportamento parecido foi percebido durante a realização das propostas

possibilidade de

a possibilidade de disponibilização da

isa completa (documento final e artefatos relevantes) na nuvem, quando

esse suporte.

dado suporte completo às



se que a abordagem aqui proposta foi a única que possibilitou esse

comparativa entre as

de Pinheiro (2013) foi adaptada, dando

numa escala de zero a cem, o quanto

armazenamento,

na nuvem; o GitHub,

mais abrangente, e o modelo de

87

arquitetura proposto, na publicação e compartilhamento da pesquisa completa

junto aos seu artefatos e no ambiente de execução da pesquisa.

Tendo em vista que as tecnologias existentes, representadas nesse estudo

pelas plataformas Dropbox e Github, não fornecem o suporte completo

necessário que auxilie o pesquisadora tornar pública a sua pesquisa, de acordo

com as necessidades atuais, as quais envolvem aplicações com diversos

modelos e tipos de dados, esta abordagem, por ser também orientada a dados,

englobou todas as categorias de dados classificados no mapa conceitual

proposto por Oliveira (2015) (ver Seção 2.1.2).


Este capítulo apresentou um estudo de caso que promoveu a construção de uma

análise comparativa entre as plataformas Dropbox, GitHub e o modelo de

arquitetura proposto neste trabalho. Verificou-se que o modelo de arquitetura

aqui proposto se diferencia dos demais, a princípio pelo fato de impactar

minimamente no modo de trabalho do pesquisador, poupando-lhe esforços para

tornar pública a sua pesquisa.

Além disso, a abordagem proposta foi concebida para atender a um

conjunto de variáveis relacionadas com a portabilidade da pesquisa, do ambiente

de trabalho do pesquisador para o ambiente de nuvem, tendo como meta um

maior nível de compartilhamento dos artefatos usados para a produção dos

resultados ao público em geral.

O fator de licenciamento na abordagem proposta possui um controle

explícito que restringe o acesso aos artefatos da pesquisa baseado nos tipos de

licença. É levado em conta que ao publicar uma dada pesquisa, o autor tem o

conhecimento que todos os elementos ficarão públicos a outros usuários. Existe

a possibilidade de informar que tipo de licença está relacionado ao artefato,

porém, o controle explícito não foi implementado.

A adoção da nuvem não permitiu apenas a reprodução do ambiente em

termos de objetos de pesquisa, mas também garantiu recursos equivalentes

88

necessários para a portabilidade da pesquisa original. Na verdade, os recursos

dos provedores de nuvem são absolutamente superiores e podem ser utilizados

para atender sob demanda cada tipo específico de necessidade.

A funcionalidade de execução da pesquisa em contêineres de software na

nuvem pode ser considerada como o principal diferencial deste trabalho em

relação às outras abordagens avaliadas. Isso demonstra seu avanço em relação

aos demais e garante benefícios a estudantes e pesquisadores.

89

6. CONCLUSÕES

Este trabalho apresentou um modelo de arquitetura para disponibilização de

pesquisas computacionais e seus artefatos em contêineres de software em

nuvem. Este capítulo, por sua vez, tem por objetivo apresentar as considerações

finais sobre o referido trabalho, enfatizando suas principais contribuições, as

limitações do modelo de arquitetura, as indicações de trabalhos futuros e a

apresentação de uma produção bibliográfica.

A Ciência da Computação pode prover a capacidade necessária para

tornar-se uma ciência mais reprodutível, apoiando o trabalho de produção dos

cientistas, a evolução e a concepção de novas descobertas.

Um dos grandes desafios concentrava-se nas barreiras técnicas de

portabilidade do ambiente da pesquisa para uma infraestrutura computacional

diferente daquela que deu origem à pesquisa. No entanto, o modelo de

arquitetura proposto superou tais desafios aplicando a conteinerização na

computação em nuvem para preservar o ambiente de origem, permitindo o

acesso aos recursos necessários para a execução da pesquisa no novo

ambiente de destino, ou seja, na nuvem.

Os resultados do estudo de caso confirmaram a viabilidade da sua

realização. O modelo de arquitetura adotou a definição de diretório da pesquisa,

contendo apenas os artefatos relevantes armazenados em um diretório

específico para a concentração dos elementos gerados. A seleção dos artefatos

relevantes ficou a cargo do pesquisador, o qual detém total conhecimento sobre

a sua pesquisa.

Portanto, o modelo de arquitetura apresentou uma proposta para simplificar

o processo de publicação, compartilhamento e execução de uma pesquisa

computacional reprodutível. Além disso, a adoção dos contêineres Docker e da

computação em nuvem possibilitaram também um ambiente para publicação e

compartilhamento dos artefatos da pesquisa para o público em geral.

90

Por fim, conclui-se que o objetivo estabelecido no início do

desenvolvimento do trabalho foi cumprido. A próxima seção apresenta as

principais contribuições deste trabalho.

6.1. Principais Contribuições

A principal contribuição deste trabalho é o modelo de arquitetura desenvolvido

possibilitar a disponibilização de pesquisas computacionais e seus artefatos em

contêineres de software em nuvem. Ademais, tal modelo valoriza o conhecimento

do pesquisador sobre a sua pesquisa, permitindo que ele escolha quais artefatos

necessitam ou não de publicação e compartilhamento.

Desse modo, é possível explorar os diferentes níveis de publicação e

compartilhamento de trabalhos científicos juntos aos seus artefatos, conforme

crítica de Donoho (2010), permitindo a construção de abordagens de pesquisa

reprodutível em computação e áreas afins.

A migração da computação local para onde os dados estão armazenados,

ou seja, na nuvem, é outro ponto forte deste trabalho, uma vez que alguns

provedores de computação em nuvem, como a Amazon Web Services32 estão

optando pelo armazenamento de grandes bases de dados científicas. Além

disso, a adoção da nuvem pode dar a capacidade de testar e interagir com

pesquisas na escala de supercomputadores.

Ao possibilitar a reconstrução do ambiente computacional a partir de um

ambiente de origem, tal como a estação de trabalho do pesquisador, para um

ambiente de destino, utilizando os recursos dos provedores de computação em

nuvem, o modelo de arquitetura permite a portabilidade, publicação,

compartilhamento e posterior execução e atualização da pesquisa por terceiros.

Portanto, com a disponibilização do modelo de arquitetura para acesso

público, espera-se contribuir para auxiliar instituições, laboratórios, grupos de

32 https://aws.amazon.com/pt/datasets

91

pesquisa, estudantes e pesquisadores interessados em realizar pesquisa

computacional reprodutível.

A próxima seção apresenta as limitações existentes no desenvolvimento do

presente trabalho.

6.2. Limitações

Uma das principais limitações deste trabalho é o fato de que para publicar a

pesquisa reprodutível junto aos seus artefatos é necessário transferir todo o

ambiente da pesquisa para o provedor de nuvem selecionado. Portanto, a

viabilidade da movimentação e alocação dos dados para o provedor de nuvem

pode ser dificultada devido ao tamanho dos conjuntos de dados da pesquisa.

Além disso, a característica de gerenciamento e compartilhamento de

grandes volumes de dados limita a capacidade de tamanho suportado pelas

imagens e contêineres Docker. Este sempre deverá estar corretamente instalado

e funcionando no ambiente de trabalho do pesquisador, pois o Docker foi a

plataforma-base escolhida para a concepção do modelo de arquitetura proposto.

Outros pontos a serem observados são: a ausência de um caminho de

retorno para os usuários comunicarem ao autor da pesquisa as possíveis

reproduções e melhoramentos, e que com a ausência de workflows científicos e

dados de proveniência, a abordagem não prevê as questões e peculiaridades de

pesquisas que usam ambientes especiais como clusters, ambientes de

computação paralela e distribuída. Estes pontos, no entanto, não pertenciam ao

escopo inicial deste trabalho, apesar de serem recomendados.

O custo de uso da nuvem pode dificultar a adoção do modelo de

arquitetura proposto, o qual não possui barreiras de utilização, mas se restringe

por área de conhecimento. Neste caso o modelo de arquitetura foi desenvolvido

com foco na área de Ciência da Computação, mas também pode ser utilizado por

outras áreas de pesquisas que trabalham com dados e informações digitais.

92

Verifica-se a ausência de uma camada de abstração da complexidade de

configuração da arquitetura proposta, algo que pudesse facilitar o uso da solução

proposta neste trabalho pelos pesquisadores, mesmo que sejam da área de

Computação.

Apesar da existência dessas limitações, elas foram estudadas e tratadas a

fim de minimizar seu impacto sobre o resultado final deste trabalho.

Na seção seguinte, apresentam-se as sugestões de trabalhos futuros.

6.3. Trabalhos Futuros

Como proposta de trabalhos futuros, recomenda-se a padronização na

nomenclatura dos artefatos da pesquisa de acordo com os diferentes tipos de

dados, pois como o pesquisador possui total autonomia, controle e liberdade

sobre tais artefatos, isso apesar de ajudar, ao mesmo tempo dificulta a criação

de um modelo genérico de padronização de nomes.

Para minimizar este problema, as recomendações de boas práticas para

publicação de dados na web, de Lóscio et al. (2016) foram seguidas para

amenizar os desafios enfrentados pelos publicadores e consumidores de dados.

Atualmente, as publicações científicas possuem um identificador de

objetos do tipo documentos, denominado Document Object Identifier (DOI), que

faz referência única a uma publicação na Internet. Portanto, é necessário criar

uma estrutura similar de identificação única para cada artefato de uma pesquisa

associado a uma publicação científica, de forma que seja adotada e reconhecida

pela comunidade científica como um todo.

Ademais, conforme outras abordagens já utilizaram, recomenda-se a

publicação do workflow juntamente com os dados de proveniência, incorporados

às produções científicas. A implementação dessa funcionalidade poderá afetar

positivamente, permitindo o aumento da produtividade dos pesquisadores.

Recomenda-se, também, a realização de testes com usuários

(pesquisadores) em relação ao uso do modelo de arquitetura proposto, assim

93

como a criação de um processo automatizado de configuração da abordagem e

um canal de feedback ao(s) autor(es).

Por fim, recomenda-se, principalmente, a criação de um quinto modelo de

serviço para a computação em nuvem: Contêiner como um Serviço (Container as

a Service - CaaS) a ser utilizado como uma estrutura base para a construção de

abordagens de pesquisa reprodutível em computação, culminando na criação de

uma nuvem pública científica.

Na próxima seção será apresentada a produção bibliográfica gerada por

este trabalho.

6.4. Produção Bibliográfica

Este trabalho resultou na publicação de um artigo nos anais do XXVII Simpósio

Brasileiro de Informática na Educação (SBIE 2016) intitulado Ambiente

Computacional em Nuvem Utilizando Docker para Suporte a Reproducible

Research em Computação33, de autoria de Sandro M. de Carvalho, Fernando da

F. de Souza, Ricardo J. R. Amorim e Dinani G. Amorim.

33 http://www.br-ie.org/pub/index.php/sbie/article/view/6823

94

REFERÊNCIAS

BARNES, N. Publish your computer code: it is good enough. Nature 467,

753, 2010.

ARMBRUST, M.; FOX, A.; GRIFFITH, R.; JOSEPH, A. D.; KATZ, R.;

KONWINSKI, A.; LEE, G.; PATTERSON, D.; RABKIN, A.; STOICA, I.; ZAHARIA,

M. A View of Cloud Computing, Commun. ACM, v. 53, n. 4, pp. 50-58, abr.

2010.

BELHAJJAME, K.; ROURE, D. D.; GOBLE, C. A. Research Object

Management: Opportunities and Challenges. February 2012.

BOETTIGER, C. An introduction to Docker for reproducible research. In:

ACM SIGOPS Operating Systems Review, v. 49, n. 1, p. 71-79, 2015.

CASADEVALL, A.; FANG, F. C. Reproducible Science, Infection and Immunity,

v. 12, n. 78, pp. 4972-4975, December 2010.

CHIRIGATI, F.; RAMPIN, R.; SHASHA, D.; FREIRE, J. ReproZip:

Computational Reproducibility With Ease. In: Proceedings of the 2016

International Conference on Management of Data, SIGMOD '16. pp. 2085-2088,

New York, NY, USA, 2016.

CHIRIGATI, F.; SHASHA, D.; FREIRE, J. Packing Experiments for Sharing

and Publication. In: Proceedings of the 2013 ACM SIGMOD International

Conference on Management of Data, SIGMOD '13, pp. 977-980, New York, NY,

USA, 2013.

CLOUD SECURITY ALLIANCE. Security Guidance for Critical Areas of

Focus in Cloud Computing V2.1. December 2009. Disponível em:

<https://cloudsecurityalliance.org/csaguide.pdf>.

DAVIDSON, S. B.; FREIRE, J. Provenance and Scientific Workflows:

Challenges and Opportunities. In: Proceedings of the 2008 ACM SIGMOD

International Conference on Management of Data, SIGMOD '08, pp. 1345-1350,

New York, NY, USA, 2008.

95

DEELMAN, E.; SINGH, G.; LIVNY, M.; BERRIMAN, B.; GOOD, J. The Cost of

Doing Science on the Cloud: The Montage Example. In: Proceedings of the

2008 ACM/IEEE Conference on Supercomputing, SC '08, pp. 50:1-50:12,

Piscataway, NJ, USA, 2008.

DIAS, Carla. C. L.; KEMCZINSKI, A.; SÁ, S. V.; FERLIN, J.; HOUNSELL, M. S.

Padrões abertos: aplicabilidade em Objetos de Aprendizagem (OAs). In:

Anais do XX Simpósio Brasileiro de Informática na Educação, SBIE, 2009.

DONOHO, D. L. An invitation to reproducible computational research,

Biostatistics, v. 3, n. 11, pp. 376-388, 2010.

DUDLEY, J. T.; BUTTE, A. J. In silico research in the era of cloud computing,

Nature Biotechnology, v. 28, n. 11, pp. 1181-1185, 2010.

FOMEL, S.; CLAERBOUT, J. F. Reproducible Research, Computing in Science

& Engineering, pp. 5-7, January/February 2009.

FOMEL, S.; HENNENFENT, G. Reproducible Computational Experiments

Using SCONS. In: Proceedings of the IEEE International Conference on

Acoustics, Speech, and Signal Processing (ICASSP 2007), v. 4, pp. IV-1257-IV-

1260, April 2007.

FOMEL, S. Reproducible Research as a Community Effort: Lessons from

the Madagascar Project, Computing in Science & Engineering, pp. 20-26,

January/February 2015.

FREIRE, J.; BONNET, P.; SHASHA, D. Computational Reproducibility: State-

of-the-art, Challenges, and Database Research Opportunities. In:

Proceedings of the 2012 ACM SIGMOD International Conference on

Management of Data, SIGMOD '12, pp. 593-596, New York, NY, USA, 2012.

GARCELON, M. An information commons? Creative Commons and public

access to cultural creations. New Media & Society, v. 8, n. 11, pp. 1307-1326,

2009.

96

GOBLE, C. The Reality of Reproducibility in Computational Science:

reproduce? repeat? rerun? and does it matter. Keynotes and Panels, 8th

IEEE International Conference on eScience, v. 327, n. 5964, pp. 415-416,

October 2012.

GUO, P. CDE: A Tool for Creating Portable Experimental Software

Packages, Computing in Science and Engg., v. 14, n. 4, pp. 32-35, jul. 2012.

HEATHER, A.; PIWOWAR, R. S. D.; FRIDSMA, D. B. Sharing Detailed

Research Data Is Associated with Increased Citation Rate Heather, mar.

2007.

HIDEN, H.; WOODMAN, S.; WATSON, P.; CALA, J. Developing cloud

applications using the e-Science Central platform, Philosophical Transactions

of the Royal Society A: Mathematical, Physical and Engineering Sciences, v.

371, n. 1983, jan. 2013.

HOWE, B. Virtual Appliances, Cloud Computing, and Reproducible

Research, Computing in Science and Engineering, v. 14, n. 4, pp. 36-41, 2012.

HSIEH, Meng-Ju; CHANG, Chao-Rui; HO, Li-Yung; WU, Jan-Jan; LIU,

Pangfeng. SQLMR: A Scalable Database Management System for Cloud

Computing. In: International Conference on Parallel Processing (ICPP), pp.315-

324. Taipei, Taiwan: 13-16 Sept. 2011.

JUNQUEIRA, R. de P. RECOBA: um ambiente para publicação e

compartilhamento de objetos de aprendizagem em formato aberto e

fragmentado. Dissertação de Mestrado em Ciência da Computação. CIn/UFPE.

Recife, 2015.

JUVE, G.; DEELMAN, E. Scientific Workflows and Clouds, Crossroads, v. 16,

n. 3, pp. 14-18, mar. 2010.

KAHLMEYER-MERTENS, R. S.; FUMANGA, M.; TOFFANO, C. B.; SIQUEIRA,

F. Como elaborar projetos de pesquisa: Linguagem e método. Rio de

Janeiro, Editora FGV, 2007.

97

KLINGINSMITH, J.; MAHOUI, M.; WU, Y. Towards Reproducible eScience in

the Cloud. In: Cloud Computing Technology and Science (CloudCom), 2011

IEEE Third International Conference on, pp. 582-586, Nov 2011.

KNOP, I. de O. Abordagem para guiar a reprodução de experimentos

computacionais: Aplicações em biologia computacional. Tese de Doutorado

em Modelagem Computacional. UFJF. Juiz de Fora, 2016.

KOOP, D.; SANTOS, E.; MATES, P.; VO, H. T.; BONNET, P.; BAUER, B.;

SURER, B.; TROYER, M.; WILLIAMS, D. N.; TOHLINE, J. E.; FREIRE, J.;

SILVA, C. T. A Provenance-Based Infrastructure to Support the Life Cycle of

Executable Papers, Procedia Computer Science, v. 4, n. 0, pp. 648 - 657, 2011.

LEVEQUE, R. J.; MITCHELL, I. M.; STODDEN, V. Reproducible research for

scientific computing: Tools and strategies for changing the culture,

Computing in Science and Engineering, v. 14, n. 4, pp. 13-17, 2012.

LEVEQUE, R. J. Python Tools for Reproducible Research on Hyperbolic

Problems, Computing in Science Engineering, v. 11, n. 1, pp. 19-27, Jan 2009.

LIN, Y.-H., KO, T.-M., CHUANG, T.-R., LIN, K.-J. Open Source Licenses and

the Creative Commons Framework: License Selection and Comparison,

Journal of Information Science and Engineering, v. 22, n. 1, pp. 1-17, 2006.

LÓSCIO, B. F.; GUIMARÃES, C. B. dos S.; CALEGARI, N. Boas Práticas para

Dados na WEB: Desafios e Benefícios. Revista Principia - Divulgação

Científica e Tecnológica do IFPB, [S.l.], n. 32, p. 9-18, dez. 2016.

MATTHEWS, J. N. The Case for Repeated Research in Operating Systems,

SIGOPS Oper. Syst. Rev., v. 38, n. 2, pp. 5-7, abr. 2004.

MELL, P. M.; GRANCE, T. SP 800-145.The NIST Definition of Cloud

Computing. Relatório técnico, Gaithersburg, MD, United States, 2011.

MERKEL, D. Docker: lightweight linux containers for consistent

development and deployment. Linux Journal, v. 2014, n. 239, p. 2, 2014.

98

MESIROV, J. P. Accessible Reproducible Research, Science, v. 327, n. 5964,

pp. 415-416, 2010.

MIGUEL, P. A. C. Estudo de caso na administração: estruturação e

recomendações para sua condução. Produção, v. 17, n. 1, p.216-229, jan./abr.

2007.

MORIN, A.; URBAN, J.; ADAMS, P. D.; FOSTER, I.; BAKER, D.; SLIZ, P.

Shining Light in Black Boxes. Science 336, 159-160. 2012.

OLIVEIRA, A. H. M. Reprodução de Experimentos Computacionais na

Infraestrutura de Computação em Nuvem. Tese de Doutorado em Engenharia

de Sistemas e Computação. UFRJ/COPPE. Rio de Janeiro, Setembro 2015.

PENG, R. D. Reproducible Research in Computational Science. Science,

334, 1226–1227, (New York, N.y.), Dec 2011.

PINHEIRO, J. M. S. Da Iniciação Científica ao TCC: Uma Abordagem para os

Cursos de Tecnologia. 1ª edição. Ciência Moderna, 2010.

PINHEIRO, R. Ambiente computacional para suporte a "Reproducible

Research". Dissertação de Mestrado em Modelagem Computacional de

Conhecimento. UFAL. Maceió, Julho 2013.

ROMERO, D. Containers com Docker: Do desenvolvimento à produção. São

Paulo, Casa do Código, 2015.

RUBENS, P. What are containers and why do you need them? 2015.

Disponível em: <http://www.cio.com/article/2924995/enterprisesoftware/what-are-

containers-and-why-do-you-need-them.html>.

SAKR, S.; LIU, A.SLA-Based and Consumer-Centric Dynamic Provisioning

for Cloud Databases. In: IEEE Fifth International Conference on Cloud

Computing (CLOUD), pp.360–367. Honolulu: 24-29 June 2012.

SCHWAB, M.; KARRENBACH, M.; CLAERBOUT, J. Making scientific

computations reproducible. Computing in Science & Engineering, AIP

Publishing, v. 2, n. 6, p. 61-67, 2000.

99

SMITH, J.; NAIR, R. Virtual Machines: Versatile Platforms for Systems and

Processes (The Morgan Kaufmann Series in Computer Architecture and

Design). San Francisco, CA, USA, Morgan Kaufmann Publishers Inc., 2005.

STALLMAN, R. M.; MCGRATH, R. GNU Make: A Program for Directed

Recompilation, Version 3. 79. 1. [S.l.]: Free Software Foundation, 2002.

STODDEN, V.; BAILEY, D. H.; BORWEIN, J.; LEVEQUE, R. J.; RIDER, W.;

STEIN, W. Setting the Default to Reproducible: Reproducibility in

Computational and Experimental Mathematics. Relatório técnico, ICERM

Workshop Reproducibility in computational and Experimental Mathematics,2013.

STODDEN, V.; MIGUEZ, S.; SEILER, J. ResearchCompendia.Org: Cyber

infrastructure for reproducibility and collaboration in computational

science. Computing in Science & Engineering, AIP Publishing, v. 17, n. 1, p. 12-

19, 2015. 23, 45, 114.

STODDEN, V. The Legal Framework for Reproducible Scientific Research:

Licensing and Copyright, Computing in Science & Engineering, v. 11,n. 1,

pp. 35-40, jan. 2009.

STRIJKERS, R.; CUSHING, R.; VASYUNIN, D.; DE LAAT, C.; BELLOUM, A. S.

Z.; MEIJER, R. Toward Executable Scientfic Publications, Procedia Computer

Science, v. 4, pp. 707-715, 2011.

SULEIMAN, B.; SAKR, S.; JEFFERY, R.; LIU, A. On understanding the

economics and elasticity challenges of deploying business applications on

public cloud infrastructure. In: Journal of Internet Services and Applications,

vol.3, no.2, pp. 173-193. September 2012.

VANDEWALLE, P.; BARRENETXEA, G.; JOVANOVIC, I.; RIDOLFI, A.;

VETTERLI, M. Experiences with Reproducible Research in Various Facets

of Signal Processing Research. In: Acoustics, Speech and Signal Processing,

2007. ICASSP 2007. IEEE International Conference on, v. 4, pp. IV-1253-IV-

1256, April 2007.

100

VANDEWALLE, P. Code Sharing Is Associated with Research Impact in

Image Processing, Computing in Science & Engineering, pp. 42-47, July/August

2012.

VALIMAKI, M. GNU General Public License and the Distribution of

Derivative Works, Journal of Information, Law and Technology, v. 2005, n. 1,

2005.

VAQUERO, L. M.; RODERO-MERINO, L.; CÁCERES, J.; LINDNER, M.A Break

in the Clouds: Towards a Cloud Definition, ACM SIGCOMM Computer

Communication Review, v. 39, n. 1, pp. 32-35, January 2009.

VOSS, C.; TSIKRIKTSIS, N.; FROHLICH, M. Case research in operations

management. International Journal Of Operations & Production Management, v.

22, n. 2, p. 195-219, 2002.

WANG, L.; VON LASZEWSKI, G.; YOUNGE, A.; HE, X.; KUNZE, M.; TAO, J.;

FU, C. Cloud Computing: a Perspective Study, New Generation Computing, v.

28, n. 2, pp. 137-146, 2010.

WAZLAWICK, R. Metodologia de Pesquisa para Ciência da Computação. 2ª

edição. Elsevier Brasil, 2014.

WEIS, J.; ALVES-FOSS, J. Securing Database as a Service: Issues and

Compromises. IEEE Security &Privacy, vol. 9, no. 6, pp. 49-55, Nov-Dec. 2011.

WOHLIN, C. et al. Experimentation in Software Engineering. [S.l.]: Springer,

2012.

YIN. R. K. Estudo de caso: planejamento e métodos. 3 ed. Porto Alegre:

Bookman, 2005.

YU, Y. OS-level Virtualization and Its Applications. Tese (Doutorado) - Stony

Brook University, 2007.

ZHANG, Q.; CHENG, L.; BOUTABA, R. Cloud computing: state-of-the-art and

research challenges. In: Journal of internet services and applications, v. 1, n. 1,

p. 7-18, 2010.

101

ZHAO, Y.; FEI, X.; RAICU, I.; LU, S. Opportunities and Challenges in Running

Scientific Workflows on the Cloud. In: CyberC, pp. 455-462. IEEE, 2011.

Documents

UM MODELO PARA DISPONIBILIZAÇÃO DE PESQUISAS ...‡… · Catalogação na fonte Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217 C331m Carvalho, Sandro Marques de