1

2 VIRTUALIZAO: ALTERNATIVA BASEADA EM LINUX

3 CONTAINER
4
5 RESUMO: Podemos encontrar na virtualizao de sistemas computacionais uma soluo para
6 a criao de vrios servidores/desktop virtuais em apenas um servidor/desktop fsico.
7 Conseguimos assim otimizar as atividades em Tecnologia da Informao (TI) e aplicar o uso de
8 uma soluo sustentvel. Porm, novas opes ao uso da virtualizao vm surgindo no
9 contexto tecnolgico. Este estudo prope a implantao de Linux Container com Docker, como
10 alternativa aos modelos de virtualizao tradicionais. Todos os softwares utilizados na pesquisa
11 so Open Source e livres de licenas de uso. Realizou-se a instalao do Docker ligado
12 plataforma Linux, bem como descrio do seu funcionamento e suas caractersticas tcnicas.
13 Foram coletados dados sobre o comportamento da mquina durante a execuo do Docker,
14 como resultado do benchmarking no cenrio avaliado, conclumos que este modelo de
15 virtualizao pode ser uma alternativa vivel mesmo em computadores com recursos de
16 hardware reduzidos.
17 Palavraschave: software livre, mquina virtual, docker, LXC
18
19 Virtualization: linux container based alternative
20
21 ABSTRACT: We can find in virtualization of computer systems a solution for creating
22 multiple servers / virtual desktop on only one server / physical desktop. We got so optimize the
23 activities in Information Technology (IT) and implement the use of a sustainable solution.
24 However, new options to the use of virtualization are emerging in the technological context.
25 This study proposes the implementation of Linux Containers with Docker, as an alternative to
26 traditional virtualization models. All software used in the research are Open Source and use of
27 license free. the Docker installation on the Linux platform, as well as a description of its
28 operation and its technical characteristics was held. Data were collected on the machine
29 behavior during the execution of the Docker, as a result of benchmarking in the assessed
30 scenario, we concluded that this virtualization model can be a viable alternative even on
31 computers with limited hardware resourcesem ingls.
32 KEYWORDS: free softwares, virtual machine, docker, LXC
33
34 INTRODUO
35 O crescimento das tecnologias de virtualizao vem cada dia mais permitindo que sistemas
36 computacionais possam ser divididos em unidades isoladas e independentes umas das outras.
37 possvel notar que existe uma necessidade de encontrar tecnologias cada vez mais sustentveis
38 e que melhorem o desempenho dos sistemas computacionais (BUI, 2015).
39 Podemos perceber que as aplicaes e softwares esto sujeitos a dois grandes grupos de
40 tcnicas: a virtualizao por Mquina Virtual (VM Virtual Machine) e as tcnicas de

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 1

41 conteinerizao. Este estudo pretende apresentar o Docker como uma ferramenta que utiliza
42 contineres para execuo de aplicaes em um ambiente virtual. O estudo foi dividido em trs
43 partes principais: fundamentao terica, onde se buscou fazer o levantamento do que j existe
44 na literatura acadmica sobre o assunto; as ferramentas e mtodos utilizados para a coleta dos
45 dados, bem como a sua anlise e aplicaes prticas.
46 Este artigo objetiva ainda elucidar o funcionamento da plataforma, seus componentes,
47 termos tcnicos usados na literatura, sistemas operacionais que podem ser utilizados em
48 conjunto com o Docker e em quais campos ele pode ser aplicado.
49 Alm disso, com base no lanamento das novas verses da plataforma estudada, foram
50 propostos temas futuros que podero esclarecer as novas funcionalidades e como elas podem
51 ser aplicadas tanto para a rea acadmica como para o desenvolvimento de softwares.
52 Mquina virtual
53 Umas das principais caractersticas da mquina virtual o controle dos Sistemas
54 Operacionais (SOs) realizado pelo hypervisor. Esse elemento age como mediador entre o
55 hardware do host e os sistemas instalados. Entre demais funes podemos citar o controle de
56 memria, controle de processos que cada mquina requisita, uso de disco, entre outros recursos
57 compartilhados. O hypervisor manipula o hardware dando a entender que existe uma mquina
58 fsica funcionando, quando na verdade, so sistemas operacionais convidados (SEO et al,
59 2015).
60 Na camada acima do hypervisor encontramos os chamados SO convidados. Cada mquina
61 virtual possui um sistema operacional prprio emulado via software. Em cima desses SOs
62 funcionam as aplicaes junto com as suas dll e bibliotecas de cdigos. Quanto mais mquinas
63 virtuais forem criadas, maior ser o trabalho do hypervisor em distribuir os recursos
64 requisitados por elas. Acima das bibliotecas temos o funcionamento dos aplicativos.
65 Os aplicativos instalados em uma mquina virtual so isolados das demais, ou seja, eles no
66 possuem relao com os aplicativos instalados em outras VM, mesmo que estejam no mesmo
67 host fsico. Alm disso, mesmo que vrios SO possam ser emulados, todo o funcionamento das
68 VM est atrelado ao sistema operacional base da mquina hospedeira.
69 Docker
70 O Docker surge como uma alternativa a anteriormente mencionada virtualizao baseada em
71 um hypervisor. O Docker avaliado como uma tecnologia de conteinerizao de cdigo aberto,

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 2

72 alternativa ao mtodo tradicional de virtualizao (https://docker.com/whatisdocker/. Acessado
73 em 15 de Novembro 2014). O seu conceito bsico a utilizao de contineres como ambientes
74 virtuais que podem interagir diretamente com o kernel, ncleo do Sistema Operacional (SO). O
75 fato desse mtodo se relacionar com o ncleo central do SO local, permite que ele opere a nvel
76 de sistema e que as aplicaes executem seus cdigos a partir do kernel local.
77 Embora o presente artigo apresente o Docker, importante salientar que a ideia de utilizar
78 contineres computacionais mais antiga. Essa tecnologia chamada de Linux Container
79 (LXC), sendo desenvolvida especificamente para o ambiente Linux. Podemos dizer assim, que
80 o Docker foi construdo com base nos conceitos do LXC (Sandoval, 2015).
81 Uma das grandes vantagens da utilizao da plataforma mencionada a dispensa de um
82 hypervisor, ou seja, um software que coordena vrios SOs em um servidor mecnico.
83

84
85 Figura 2: Esquema demonstrativo do funcionamento de uma mquina via Docker, com
86 destaque para a camada Docker Engine e ausncia dos SOs convidados.
87
88 Vantagens do uso do Docker
89 Ao restaurar uma imagem em um novo continer, ela permanece intacta em relao
90 imagem de origem. Isso torna os dados de cada continer confiveis. Como a imagem da
91 aplicao pode ser exportada, o Docker permite o fcil compartilhamento das atividades
92 desenvolvidas. O gerenciador dos contineres executa apenas aqueles que foram requisitados.
93 A grande comunidade de usurios que utilizam essa ferramenta permite que problemas, nas
94 mais diversas situaes, possam ser resolvidos (Kacamarga et al, 2015).

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 3

 95 Como o Docker dispensa o uso de um sistema operacional convidado e do hypervisor, o
96 tamanho e o custo do espao de armazenamento so reduzidos (Ou e Chen, 2015). Os
97 desenvolvedores do Docker defendem a ideia de que a plataforma fornece ferramentas chave
98 para melhorar o desenvolvimento das aplicaes.
99 Conforme Vase, 2015, a plataforma possui entrega rpida das aplicaes executadas, ajuda a
100 diminui o desperdcio de recursos do SO, alm da possibilidade de adaptao s diversas
101 distribuies operacionais.
102 Desvantagens do uso do Docker
103 Como dito anteriormente, os contineres se comunicam diretamente com o kernel do SO.
104 Para alguns autores, isso contribui para que os contineres no tenham um nvel de isolamento
105 to alto quanto uma mquina virtual. Alm disso, alguns defendem que essa comunicao com
106 o ncleo do sistema operacional arriscada, pois um software malicioso teria fcil acesso ao
107 kernel do sistema operacional (Bui, 2015).
108 Segundo a IBM, outra possvel desvantagem da conteinerizao seria a impossibilidade de
109 trabalhar com clusters, ou seja, trabalhar em conjunto com outras mquinas. Alm disso, por se
110 tratar de uma tecnologia inicialmente direcionada para Linux, o uso da ferramenta pode exigir
111 certo grau de conhecimento tcnico com relao a comandos usados na administrao do
112 sistema operacional.
113
114 MATERIAL E MTODOS
115 Primeiramente, instalamos um sistema operacional Linux com a distribuio CentOS verso
116 7. Aps a devida instalao e configurao do sistema operacional, foi realizada a instalao do
117 Docker Engine. Seguiram-se os padres de instalao de softwares nas distribuies Linux,
118 utilizando o terminal ou linha de comando. Adicionalmente foi utilizado o gerenciador de
119 pacotes Yellowdog Updater Modified (YUM) para instalao das dependncias do software.
120 Foi realizado o download da ferramenta Cockpit, desenvolvida pela Project Atomic. A
121 ferramenta auxiliou, em conjunto com monitor de sistema do SO, na coleta dos seguintes dados:
122 espao em disco, uso de memria e consumo de processamento, antes e durante a execuo dos
123 contineres. Para que esses processos fossem efetivados, fez-se necessrio o download de
124 imagens dos softwares obtidas do repositrio Docker Hub. Como amostragem, foram
125 selecionadas as seguintes imagens: Apache HTTPD Server, ownCloud e Tomcat.

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 4

126 A coleta de dados ocorreu da seguinte forma: utilizando o software Cockpit, bem como o
127 monitor de sistema, foram aferidos os parmetros mencionados anteriormente. O pesquisador
128 demarcou um intervalo de tempo entre zero minuto (tomado como instante inicial da medio)
129 e dez minutos. Durante esse intervalo de tempo existiam sub marcaes alocadas de dois em
130 dois minutos. Dessa forma, os resultados foram coletados em intervalos regulares,
131 uniformizando a coleta. tambm importante salientar que executou-se um continer por vez.
132 A medio do espao em disco resultou do eguinte processo: aferio do espao ocupado
133 anterior aos downloads das imagens e instalao dos contineres e aferio do espao ocupado
134 posteriormente.
135 Como teste complementar, o pesquisador selecionou o continer do Apache HTTPD Server
136 para aferir o stress da Central Processing Unit (CPU) e da memria RAM, desta feita sob stress
137 de conexes simuladas via software. O objetivo deste teste consistiu em verificar como o
138 continer se comporta quando recebe conexes externas. Para realizar esse teste utilizou-se o
139 Cockpit em conjunto com uma ferramenta de linha de comando prpria para o Apache,
140 chamada AB - Apache HTTP server benchmarking tool. De maneira geral, esse software utiliza
141 parmetros para determinar de que maneira seria realizada a conexo com o servidor web.
142 A figura 3 mostra o comando usado para disparar as conexes, onde ab resume-se ao
143 utilitrio de linha de comando, -n 24000 o nmero de conexes disparadas para o teste, -c 100 o
144 nmero de requisies concorrentes e http://localhost:80/ o endereo do servidor web.

145
146 Figura 3. Comando para teste de conexes.
147 Os testes com o AB seguiro os mesmos padres da coleta do monitor de sistema. Porm, as
148 submarcaes de medio sero alteradas para intervalos de 10 segundos. Em um terminal o
149 pesquisador executar o comando j descrito; de forma imediata a ferramenta disparar as
150 conexes pedidas para o continer do Apache HTTPD e a partir de ento o Cockpit iniciar a
151 exibio do consumo de memria e CPU. A medio considerar como ponto inicial o
152 momento em que o continer estiver totalmente estvel, ou seja, quando a carga de inicializao

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 5

153 for completada. Dessa forma, espera-se que o nico consumo que ser observado no momento
154 inicial da medio seja o da memria RAM, necessria para a carga inicial do continer.
155 Tambm interessante salientar que a medio da memria RAM realizada pelo monitor de
156 sistema exibir o resultado em megabyte. J o Cockpit demonstrar seus resultados em megabit.
157 O pesquisador optar por trabalhar com a unidades apresentadas pelos softwares para trazer um
158 ambiente mais fiel s aplicaes.
159 importante salientar que o Apache foi selecionado pelo fato de possuir uma ferramenta de
160 rpida manipulao, permitindo que sejam simuladas as quantidades de requisies desejadas,
161 exigindo apenas o uso da linha de comando. Alm disso, o software trar informaes
162 adicionais que podero ser relevantes como o tempo total para a execuo de todas as
163 requisies, o tempo entre uma requisio e a seguinte, se houve perda de algum pacote,
164 quantidade de dados baixados/recebidos pelo servidor web entre outras informaes
165 pertinentes.
166
167 RESULTADOS E DISCUSSO
168 Conseguimos perceber, na figura 4, como o Docker afetou o espao em disco da mquina.
169 Por mais que seja feito o download das imagens e instalao dos contineres, visualizamos que
170 no houve alterao significativa em relao ao armazenamento anterior. Uma vez que o
171 continer monta a aplicao de forma reduzida, dispensando a instalao de dependncias
172 adicionais, ele no ocupa tanto espao na mquina. O espao total disponibilizado de 50 GB
173 mostrou-se suficiente para uso da plataforma Docker, deixando aproximadamente 97,5% livres
174 para trabalhar o contedo das aplicaes, bem como a utilizao de novas imagens e
175 contineres.

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 6

176
177 Figura 4. Resultados da medio do espao em disco tomado pelas imagens e seus
178 contineres.
179 A maior mudana notada no comportamento dos contineres durante o monitoramento foi
180 entre o momento de repouso, ou seja, quando os contineres estavam inativos e o momento em
181 que eles so ativados. Como podemos verificar no grfico, em mdia o trabalho da CPU
182 duplicou em relao ao momento inicial. Mesmo assim o desempenho das aplicaes nos
183 contentores foi estvel e sem travamentos. perceptvel na figura 5, que todos os contineres
184 exerceram uma carga semelhante na CPU. Com exceo do momento inicial, o uso no
185 ultrapassou a marca de 51%.
186 Adicionalmente, foi realizada a conexo ao continer do ownCloud por uma mquina na
187 rede, sendo necessrio autenticar o domnio em que os contineres estavam alocados. Quando
188 esse processo foi realizado, o contentor passou a ser acessado e a sincronizar os arquivos em
189 tempo real. Obviamente vrios fatores influenciaram no tempo de acesso como estrutura da
190 rede, recursos de hardware do host, quantidade de mquinas na rede, entre outros. Entretanto de
191 modo geral, o continer foi acessado de maneira uniforme no sendo constatados prejuzos no
192 acesso, upload e download dos dados.

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 7

193
194 Figura 5. Dados coletados quanto porcentagem de processamento atingida pelo
195 processador (CPU).
196 Para o uso de memria RAM podemos constatar que, embora o stress dos contineres tenha
197 sido maior do que o uso de CPU, a porcentagem de uso foi bastante estvel. O Apache
198 demonstrou que foi o continer mais uniforme, pois se mostrou regular entre o momento de
199 repouso e de uso da aplicao. Os demais softwares sofreram uma maior variao, porm de
200 forma a geral isso no se constituiu uma barreira para o uso dos mesmos.

201
202 Figura 6. Resultados obtidos a partir da medio do consumo de memria RAM.
203 Podemos perceber na figura 6 que o ownCloud e o Tomcat causam uma elevao no
204 consumo geral de memria pelo SO no momento em que esses contineres so ativados. Logo
205 aps a ativao o consumo torna-se estvel at que o continer novamente desligado.
206 Na figura 7 temos o demonstrativo do stress sofrido pelo processo ao passo que as conexes
207 so feitas pelo software de teste AB. Quando o continer foi inicializado o uso da CPU foi
208 alterado por um perodo de cinco a seis segundos. Esse processo caracterizado pela carga

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 8

209 inicial do continer, ou seja, a atividade exercida para que ele esteja carregado e pronto para ser
210 usado. A partir desse momento, quando a carga inicial foi estabilizada, o uso da CPU volta a
211 zero dentro do continer possibilitando o incio das medies.

212
213 Figura 7. Stress provocado na CPU pelas conexes simuladas.
214 No tocante aos processos de desenvolvimento e programao dos softwares, podemos
215 destacar que o Docker anda lado a lado com os mtodos tradicionais. O programador tem a sua
216 disposio os compiladores, depuradores, ambientes de desenvolvimento integrado entre outras
217 ferramentas. Um dos grandes diferenciais da plataforma possibilitar ao programador instalar
218 suas ferramentas de maneira rpida e escalvel, garantindo a segurana das suas informaes.
219 Uma caracterstica que pode ser incorporada ao continer a persistncia do contedo. Se esse
220 fator no for levado em considerao no momento de criao do contentor, em uma eventual
221 remoo do mesmo, todo o contedo ser perdido. Com a persistncia aplicada, por mais que o
222 continer seja removido, os dados podero ser restabelecidos em um novo continer j que eles
223 ficam armazenados no repositrio do programa.
224 O Docker possibilita a edio em tempo real do cdigo contido no continer. Ento caso o
225 desenvolvedor queira alterar alguma estrutura da aplicao, ele pode verificar o resultado
226 imediatamente. Por exemplo, alterar a estrutura em CSS de uma pgina WEB armazenada no
227 localhost. Basta saber quem o host na rede, a porta de comunicao com o continer e
228 direcionar os cdigos e sua aplicao para ele. O processo ocorre de forma to natural que o uso
229 do contentor pode passar despercebido, dando a impresso de que o programador est
230 conectado a uma mquina seja real ou virtual.
231
232 CONCLUSES

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 9

233 Embora a plataforma Docker seja recente, coloca-se como uma nova forma trabalhar a
234 infraestrutura associada a criao, tratamento e manipulao de softwares. Essa ferramenta
235 permite ao desenvolvedor de softwares escalar suas aplicaes como servios e simplificar sua
236 infraestrutura aliadas segurana da conteinerizao. Alm disso, a tecnologia dispensa o uso
237 de mquina virtuais completas, otimizando as atividades de desenvolvimento.
238 Entretanto, por se tratar de uma tecnologia relativamente nova, existe muitos campos que
239 precisam ser estudados. Como trabalhos futuros podemos citar a anlise do comportamento da
240 plataforma em comparao uma mquina virtual pura. Paralelamente, poderia se investigar o
241 uso do Docker aplicado a novos sistemas computacionais como o Raspberry Pi. Com o
242 lanamento da verso 1.12, surgem novas possibilidades ao uso do Docker. Aparece assim a
243 implementao do conceito de servio escalvel, do Swarm e do Bundle.
244 Estudos futuros podem ser aplicados a respeito dessas novas funcionalidades e como podem
245 ser utilizadas pelos desenvolvedores de softwares. Alm disso, a soluo pode ser testada com
246 outros servios e outros programas disponveis no Docker Hub ampliando a game de testes.
247
248 REFERNCIAS
249 BUI, Thanh. Analysis of docker security. arXiv preprint arXiv:1501.02967, 2015.
250 CHAMBERLAIN, Ryan; INVENSHURE, L.; SCHOMMER, Jennifer. Using Docker to
251 support reproducible research. Technical report, Technical Report 1101910, figshare, 2014.
252 http://dx. doi. org/10.6084/m9. figshare. 1101910, 2014.
253 MAZZONI, E. et al. Docker experience at INFN-Pisa Grid Data Center. In: Journal of Physics:
254 Conference Series. IOP Publishing, 2015. p. 022029.
255 SANDOVAL, Robert. A case study in enabling DevOps using Docker. 2015. Tese de
256 Doutorado.
257 SCHEEPERS, Mathijs Jeroen. Virtualization and containerization of application
258 infrastructure: A comparison. University of Twente, Enschede, 2014.
259 SEO, K.T.; Hwang, H.S.; Moon, I.Y.; Kwon, O.Y.; Kim, B.J.;Performance comparison
260 analysis of linux container and virtual machine for building cloud. Advanced Science and
261 Technology Letters, v. 66, p. 105-111, 2014.
262 VASE, Tuomas. Advantages of Docker. 2015.
263

XI Congresso Norte Nordeste de Pesquisa e Inovao, 2016 Pgina 10