Você está na página 1de 48

JETHER BARBOZA DOS SANTOS

CONTAINERS DOCKER COMO


ESTRATÉGIA DE VIRTUALIZAÇÃO DE CLOUD

Monografia de Conclusão do Curso de


Especialização em Tecnologia da Informação
Bancária da Escola Politécnica da Universidade
de São Paulo.

Orientador: Professor Doutor Osvaldo Gogliano


Sobrinho

São Paulo
2016
RESUMO

Este trabalho tem como objetivo avaliar a utilização da tecnologia de Containers


Docker como parte da estratégia de virtualização da cloud privada baseada em
OpenStack do Itaú Unibanco. Trata-se de uma tecnologia disruptiva, baseada no
kernel do Linux, que permite a execução de múltiplas aplicações em processos
isolados e com consumo de recursos de processamento controlados, sem o
overhead de infraestrutura causado por um hypervisor, comum em grande parte das
soluções de cloud atuais. Enquanto cada máquina virtual instanciada por um
hypervisor carrega na memória uma imagem de sistema operacional completa, os
Containers Docker compartilham uma única imagem na memória do host. Isto faz
com que os Containers Docker sejam leves e possam ser inicializados em
segundos. Cada container executa uma imagem Docker, que empacota a aplicação,
todas as suas dependências e o ambiente de execução. Além de versionáveis, as
imagens Docker são facilmente portáveis entre os diferentes ambientes do ciclo de
desenvolvimento de sistemas, tornando o processo simples e seguro. Através da
pesquisa foi possível compreender os fundamentos, vantagens e desvantagens e,
sobretudo, as limitações de segurança dos Containers Docker em relação as
máquinas virtuais, o que permitiu direcionar os principais casos de uso para a cloud
privada do Itaú Unibanco. Aplicações de diferentes linhas de negócio devem ser
executadas em máquinas virtuais segregadas. Internamente na máquina virtual, as
aplicações de uma mesma linha de negócio devem ser publicadas em containers
diferentes, conferindo isolamento e controle do uso de recursos por aplicação, e ao
mesmo tempo reduzindo o overhead da infraestrutura pela diminuição do uso de
máquinas virtuais.

Palavras-chave: container, Docker, cloud, virtualização, OpenStack, IaaS, PaaS,


SaaS, hypervisor, namespaces, cgroup, Linux.
LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface


AWS Amazon Web Services
CD Continuous Delivery
cgroup control group
classid class identifier
DevOps Development and Operations
DMA Direct Memory Access
IaaS Infrastructure as a Service
ID Identifier
I/O Input and Output
PaaS Platform as a Service
Pod Pool of devices
PID Process Identifier
RC Replication Controller
REST Representational State Transfer
SaaS Software as a Service
seccomp secure computing mode
SLA Service Level Agreement
SO Sistema Operacional
SSD Solid-state drive
TC Traffic Controller
TI Tecnologia da Informação
TLS Transport Layer Security
UnionFS Union File System
VM Virtual machine
VMM Virtual Machine Manager
VMCS Virtual Machine Control Structure
VMX Virtual Machine Extensions
SUMÁRIO

1 INTRODUÇÃO.......................................................................................................................6
1.1 CONSIDERAÇÕES INICIAIS E MOTIVAÇÃO............................................................6
1.2 OBJETIVO........................................................................................................................7
1.3 CONTEÚDO E ORGANIZAÇÃO...................................................................................7
2 VIRTUALIZAÇÃO.................................................................................................................9
2.1 INTRODUÇÃO................................................................................................................9
2.2 MODELOS DE VIRTUALIZAÇÃO................................................................................9
2.2.1 VIRTUALIZAÇÃO COMPLETA POR TRADUÇÃO BINÁRIA................................9
2.2.2 PARAVIRTUALIZAÇÃO...........................................................................................10
2.2.3 VIRTUALIZAÇÃO NATIVA OU AUXILIADA POR HARDWARE........................11
2.2.4 VIRTUALIZAÇÃO POR SISTEMA OPERACIONAL.............................................13
3 CLOUD COMPUTING.........................................................................................................15
3.1 INTRODUÇÃO..............................................................................................................15
3.2 CARACTERÍSTICAS ESSENCIAIS.............................................................................15
3.3 MODELOS DE SERVIÇOS...........................................................................................16
3.4 MODELOS DE IMPLEMENTAÇÃO............................................................................16
4 INFRASTRUCTURE AS A SERVICE (IAAS).....................................................................18
4.1 INTRODUÇÃO..............................................................................................................18
4.2 CARACTERÍSTICAS....................................................................................................18
4.3 PROVEDORES E TECNOLOGIAS..............................................................................19
4.4 OPENSTACK.................................................................................................................20
5 PLATFORM AS A SERVICE (PAAS)...................................................................................23
5.1 INTRODUÇÃO..............................................................................................................23
5.2 CARACTERÍSTICAS....................................................................................................23
5.3 PROVEDORES E TECNOLOGIAS..............................................................................24
6 CONTAINERS DOCKER.....................................................................................................25
6.1 INTRODUÇÃO..............................................................................................................25
6.2 ARQUITETURA E COMPONENTES...........................................................................26
6.3 EXECUÇÃO DE CONTAINERS...................................................................................28
6.4 FUNDAMENTOS DA VIRTUALIZAÇÃO POR CONTAINERS................................29
6.5 SEGURANÇA................................................................................................................33
6.6 MODELOS DE OPERAÇÃO........................................................................................36
6.7 INDICAÇÕES DE USO DE CONTAINERS E MÁQUINAS VIRTUAIS...................38
6.8 ORQUESTRAÇÃO DE CONTAINERS........................................................................39
6.9 DOCKER COM OPENSTACK......................................................................................40
7 CONCLUSÃO.......................................................................................................................43
7.1 CONSIDERAÇÕES FINAIS..........................................................................................43
7.2 TRABALHOS FUTUROS E MELHORIAS..................................................................45
8 REFERÊNCIAS.....................................................................................................................46
6

1 INTRODUÇÃO
1.1 CONSIDERAÇÕES INICIAIS E MOTIVAÇÃO
Em áreas ou empresas de TI tradicionais a implantação de um novo sistema
em ambiente produtivo precisa ser planejada com antecedência. Por meio da
inspeção dos requisitos não funcionais (quantidade de acessos simultâneos,
tamanho do tráfego de dados das transações, tempo de resposta, disponibilidade,
escalabilidade, continuidade e segurança) a arquitetura da solução é desenhada e
uma estimativa de capacidade da infraestrutura é realizada.
De posse das definições de arquitetura e do planejamento de capacidade, a
infraestrutura é adquirida, instalada e configurada. Porém ao implantar o novo
sistema em produção, mesmo após uma análise de capacidade apurada, é comum a
constatação de que a infraestrutura provisionada está subutilizada. Em muitos casos
a análise da capacidade da infraestrutura leva em consideração o pico da utilização
dos recursos, quando estes podem ocorrer apenas raramente. Em outros casos, por
restrições de projeto, o aumento da utilização do sistema ocorre de forma gradativa,
mas a infraestrutura é provisionada desde o inicio para atender toda a carga
prevista.
Em busca de maior agilidade e eficiência, muitas empresas tem buscado por
soluções de cloud computing públicas e/ou privadas para o provisionamento da
infraestrutura (IaaS), publicação de aplicações (PaaS) ou utilização de software
(SaaS) contratadas como serviço. Na busca por padronização, algumas empresas
de tecnologia trabalham em conjunto para o desenvolvimento de soluções de cloud
(por exemplo, OpenStack). Outras empresas buscam sozinhas estabelecer padrões
(exemplos, OpenShift da Red Hat ou vCloud da VMware). Entretanto a base de
todas as soluções de cloud está na virtualização das camadas de processamento,
de rede e de armazenamento (ZANGH, CHENG & BOUTABA, 2010).
Em se tratando de virtualização, há diversos hypervisors disponíveis no
mercado tanto open source como de código proprietário. Através de um hypervisor é
possível ter em um computador físico (bare metal) diversas máquinas virtuais de
sistemas operacionais diferentes compartilhando o mesmo hardware. Antes mesmo
da explosão dos conceitos de cloud computing, a virtualização de servidores trouxe
para a TI muitos benefícios administrativos, de disponibilidade e de melhor uso da
capacidade ociosa dos recursos de processamento. A consolidação de servidores
7

físicos em servidores virtuais tem trazido excelentes resultados de redução de


custos para as empresas (NEMETH, SNYDER et al., 2011).
Contudo, uma nova tecnologia tem emergido com a promessa de benefícios
similares aos da virtualização de servidores orquestrada por uma solução de cloud,
porém sem o footprint de ter diversas cópias de sistemas operacionais executando
paralelamente em um mesmo servidor físico. Trata-se da tecnologia de Containers
Docker. Um Container Docker executa uma imagem de um servidor da aplicação em
processo e endereçamento de memória isolados, porém compartilhando com outros
containers e outros processos em execução um mesmo kernel de sistema
operacional (PAHL, 2015).
1.2 OBJETIVO
Este trabalho teve por objetivo avaliar a adoção da tecnologia de Containers
Docker como estratégia de virtualização para a cloud privada do Itaú Unibanco, que
será construída baseada na tecnologia OpenStack. Além de aprimorar o time-to-
market das entregas da TI e melhorar o processo de deployment das aplicações,
pretende-se fazer melhor uso dos recursos computacionais pela redução do
overhead causado pelo software hypervisor e pelas diversas cópias de um mesmo
sistema operacional executadas simultaneamente em um servidor físico.
1.3 CONTEÚDO E ORGANIZAÇÃO
O Capítulo 2 apresenta os conceitos de virtualização de computadores, as
características e diferenças entre os métodos de virtualização por software e as
contribuições da virtualização implementada no hardware.
O Capítulo 3 apresenta conceitos de cloud computing, suas principais
características, modelos de serviço e de implementação.
O Capítulo 4 apresenta o modelo de serviço IaaS, objetivos, características
conceituais e de implementação pelos principais provedores de cloud. Ao término do
Capítulo destaca-se a tecnologia OpenStack, que será adotada como solução de
IaaS no Itaú Unibanco.
O Capítulo 5 apresenta o modelo de serviço PaaS, objetivos, características,
provedores e a evolução das diferentes plataformas com o uso de containers.
O Capítulo 6 apresenta os benefícios da utilização de Containers Docker no
ciclo de desenvolvimento de sistemas, sua arquitetura, os componentes da solução
e o processo de execução de containers. Detalha as características do kernel Linux
8

e do sistema de arquivos que possibilitam a criação e a execução dos containers.


Descreve aspectos de segurança do servidor Docker e dos containers, os modelos
de operação em máquina virtual (VM) ou física (bare metal) e as indicações de uso
dos containers e das máquinas virtuais. O Capítulo é concluído com uma
apresentação da arquitetura OpenStack que suporta a execução dos Containers
Docker.
Finalmente, o Capítulo 7 apresenta as considerações finais deste trabalho,
destacando os principais casos de uso e benefícios na utilização das tecnologias de
máquinas virtuais e de Containers Docker, bem como trabalhos que poderiam ser
considerados em continuidade a este.
9

2 VIRTUALIZAÇÃO
2.1 INTRODUÇÃO
Antes do advento da virtualização de servidores as aplicações eram
comumente instaladas em servidores físicos dedicados (bare metal). Esta era uma
exigência comum dos fabricantes de software a fim de evitar problemas de
incompatibilidade entre aplicações distintas e a perda de suporte do fornecedor. A
crescente demanda dos negócios por soluções de software resultou em Data
Centers com grande capacidade de processamento, com servidores físicos
dedicados para cada aplicação, resultando com frequência em baixa eficiência no
uso dos recursos de infraestrutura (hardware, energia elétrica, espaço físico e
refrigeração) e ociosidade de processamento.
A virtualização possibilitou o compartilhamento dos recursos de um mesmo
servidor físico (processador, memória, disco e rede) entre diferentes aplicações
executadas em contextos de processamento isolados, pertencentes aos servidores
virtuais. Entre os principais benefícios alcançados estão a redução de custos e do
consumo de energia elétrica, a criação de processos simplificados de alta
disponibilidade e continuidade, a migração de servidores virtuais entre servidores
físicos sem causar indisponibilidade do serviço e a agilidade técnica para o
provisionamento de novos servidores (NEMETH, SNYDER et al., 2011).
2.2 MODELOS DE VIRTUALIZAÇÃO
2.2.1 VIRTUALIZAÇÃO COMPLETA POR TRADUÇÃO BINÁRIA
Neste modelo um software hypervisor (virtual machine manager) é
responsável por prover os ambientes virtuais de execução, emulando para os
sistemas operacionais das máquinas virtuais hóspedes (VMs) os dispositivos de
hardware físicos. Os sistemas operacionais das VMs “não sabem” que suas
instruções não são executadas diretamente no hardware físico. Antes da execução
as requisições de instruções privilegiadas são interceptadas e traduzidas pelo
hypervisor (NEMETH, SNYDER et al., 2011). Instruções não privilegiadas
(executadas no nível do usuário) são enviadas diretamente para processamento no
hardware físico (VMware White Paper. Understanding Full Virtualization,
Paravirtualization, and Hardware Assist, 2007).
10

Como é utilizado um software para a virtualização, as máquinas virtuais


podem executar em diferentes arquiteturas de processador, desde que o hypervisor
ofereça este suporte. No entanto, é imposto um certo nível de degradação de
desempenho, em razão da tradução das instruções efetuadas pelo hypervisor antes
da execução no processador físico (NEMETH, SNYDER et al., 2011). A figura 1
ilustra este modelo de virtualização.

Figura 1. Arquitetura de virtualização completa por tradução binária.

Fonte: Adaptada de (NEMETH, SNYDER et al., 2011).

2.2.2 PARAVIRTUALIZAÇÃO
Assim como o modelo completamente virtualizado por tradução binária, na
paravirtualização um software hypervisor (VMM) é responsável por prover os
ambientes virtuais de execução, emulando para os sistemas operacionais das
máquinas virtuais hóspedes (VMs) os dispositivos de hardware físicos. Porém, o
sistema operacional de cada VM é modificado para substituir as chamadas de
instruções privilegiadas do kernel por hypercalls (chamadas de hypervisor), o que
reduz a sobrecarga causada pela tradução de instruções do modelo de virtualização
completa por tradução binária, mas torna o sistema operacional das VMs fortemente
acoplado ao hypervisor (NEMETH, SNYDER et al., 2011). As instruções não
privilegiadas (executadas no nível de usuário) são enviadas diretamente para
11

processamento no hardware (VMware White Paper. Understanding Full


Virtualization, Paravirtualization, and Hardware Assist, 2007).
Neste modelo o primeiro servidor virtual definido possui acesso privilegiado ao
hardware e é responsável por gerenciar os outros servidores virtuais e os drivers
dos dispositivos do computador (NEMETH, SNYDER et al., 2011). A figura 2 ilustra
este modelo de virtualização.

Figura 2. Arquitetura de paravirtualização.

Fonte: Adaptada de (NEMETH, SNYDER et al., 2011).

2.2.3 VIRTUALIZAÇÃO NATIVA OU AUXILIADA POR HARDWARE


Os fabricantes Intel e AMD desenvolveram tecnologias de virtualização em
seus processadores que permitem a execução de múltiplos sistemas operacionais
paralelamente em um mesmo processador físico, sem precisar dos artifícios criados
nos modelos de virtualização completa por tradução binária ou de paravirtualização.
Tratam-se das tecnologias VT-x da Intel (arquiteturas IA-32 e Intel 64) e AMD-V da
AMD que criaram uma nova camada de abstração para controlar o acesso
privilegiado ao estado dos registradores do processador.
No caso da Intel foram criados no processador os modos de operação VMX
root operation e VMX non-root operation. Ambos modos de operação suportam os
12

quatro estados de execução do processador.1 Para controlar as transições entre os


modos de operação foi criada uma estrutura de memória chamada VMCS (virtual-
machine control structure) que preserva o contexto de execução de cada VM e VMM
(virtual machine manager) no hardware, durante as transições de estado ocorridas
entre cada máquina virtual e o hypervisor (NEIGER et al., 2006).
Neste modelo o kernel das VMs solicita a execução das instruções
privilegiadas para o processador de forma nativa sem nenhuma tradução pelo
hypervisor ou modificação prévia do sistema operacional para chamadas de
hypercalls (VMware White Paper. Understanding Full Virtualization,
Paravirtualization, and Hardware Assist, 2007).
Além dos recursos de virtualização do processador, os fabricantes de
hardware desenvolveram tecnologias de virtualização de I/O, para aumentar o
desempenho e a segurança das máquinas virtuais, reduzindo a sobrecarga dos
hypervisor em emular os dispositivos de I/O e dispensando o uso de
paravirtualização. No caso da Intel foi desenvolvida no chipset a tecnologia VT-d,
que possibilita ao VMM mapear e isolar no hardware DMA remapping as áreas de
memória de cada VM. Deste modo as máquinas virtuais fazem acesso aos
dispositivos de I/O, por meio do periférico de DMA (Direct Memory Access), sem a
intervenção do hypervisor. Esta tecnologia também pode ser operada diretamente
por um SO (Intel. Intel® Virtualization Technology for Directed I/O (VT-d): Enhancing
Intel platforms for efficient virtualization of I/O devices, 2012). A figura 3 ilustra este
modelo de virtualização.

1
. Os processadores de arquitetura x86 possuem quatro possíveis estados de execução. Na maioria dos sistemas
operacionais o estado 0 é utilizado para a execução de instruções privilegiadas do sistema operacional e o estado
3 para execução de instruções não privilegiadas. Os estados 1 e 2 não são normalmente utilizados (BOVET &
CESATI, 2005).
13

Figura 3. Arquitetura de virtualização nativa ou auxiliada por hardware.

Fonte: Adaptada de (NEMETH, SNYDER et al., 2011).

2.2.4 VIRTUALIZAÇÃO POR SISTEMA OPERACIONAL


Ao invés de criar ambientes com múltiplas máquinas virtuais em um servidor
físico, a virtualização por sistema operacional permite a criação de múltiplos
ambientes aplicacionais isolados, chamados containers, que referenciam um mesmo
kernel. Por fazerem parte do próprio sistema operacional não é possível instanciar
containers de outros sistemas operacionais no mesmo ambiente de execução
(NEMETH, SNYDER et al., 2011).
Neste modelo de virtualização o isolamento entre os containers é obtido por
meio de features do kernel conhecidas como namespaces e control groups
(cgroups) (OpenStack White Paper. Exploring Opportunities: Containers and
OpenStack, 2015). A figura 4 ilustra este modelo de virtualização.
14

Figura 4. Arquitetura de virtualização por SO.

Fonte: Adaptada de (NEMETH, SNYDER et al., 2011).


15

3 CLOUD COMPUTING
3.1 INTRODUÇÃO
Mell & Grance (2011) definiram Cloud Computing como um modelo de
computação sob demanda, capaz de provisionar recursos de rede, armazenamento,
processamento, aplicações e serviços rapidamente e com mínimo esforço de
gerenciamento ou de interação com o provedor do serviço. Este modelo é composto
por cinco características essenciais, três modelos de serviços e quatro modelos de
implementação.
3.2 CARACTERÍSTICAS ESSENCIAIS
 Auto serviço sob demanda: Um cliente da cloud pode provisionar
capacidades computacionais sob demanda, sem interação humana com o
provedor do serviço.
 Acesso amplo pela rede: Os recursos devem estar disponíveis através da
rede por meio de interfaces padronizadas, possibilitando acesso para
diferentes tipos de dispositivos tais como telefones celulares, tablets, laptops
e estações de trabalho.
 Pool de recursos: Os provedores de cloud agrupam recursos físicos e
virtuais de sua infraestrutura e os atribuem dinamicamente aos seus diversos
clientes sob demanda. Os clientes tem pouco controle sobre a infraestrutura
física onde as suas aplicações são executadas, exceto em alto nível de
abstração (por exemplo, país, estado ou Data Center onde o pool de recursos
do cliente foi alocado).
 Rápida elasticidade: As capacidades de infraestrutura podem ser
aumentadas ou diminuídas rapidamente sob demanda e possivelmente de
forma automática. Para os clientes é criada uma camada de abstração que
faz parecer que os recursos de infraestrutura são ilimitados e que podem ser
redimensionados em qualquer quantidade e a qualquer momento.
 Serviços mensuráveis: Sistemas de cloud monitoram e controlam
automaticamente o consumo de recursos em um nível de abstração
adequado ao tipo de serviço (para citar alguns exemplos: armazenamento,
capacidade de processamento, largura de banda e contas de usuários ativas).
Por meio de relatórios automáticos, tanto o provedor de cloud, quanto os seus
16

clientes obtêm informações sobre o consumo de recursos de forma


transparente (MELL & GRANCE, 2011).
3.3 MODELOS DE SERVIÇOS
 Software as a Service (SaaS): Neste modelo o provedor do serviço oferta
aos clientes aplicações provisionadas em uma infraestrutura de cloud. As
aplicações podem ser acessadas de diversos dispositivos client, como um
browser web ou interfaces da própria aplicação. O cliente não gerencia ou
controla a infraestrutura de servidores, armazenamento, sistemas
operacionais ou mesmo as capacidades funcionais das aplicações. A única
exceção é a possibilidade de configuração de parâmetros dos softwares
contratados.
 Platform as a Service (PaaS): É ofertada aos clientes a capacidade de
publicar suas próprias aplicações ou de terceiros em uma plataforma
padronizada (linguagens de programação, bibliotecas, serviços e ferramentas
disponibilizada e suportada pelo provedor de cloud). O cliente não controla ou
gerencia a infraestrutura da cloud, porém controla a publicação das
aplicações e parâmetros do ambiente de execução.
 Infrastructure as a Service (IaaS): O provedor de cloud provisiona
capacidade de processamento, armazenamento, rede e outros recursos
computacionais básicos, de modo que o cliente possa publicar e executar
qualquer software, o que inclui sistemas operacionais e aplicações. O cliente
não gerencia ou controla a infraestrutura da cloud, mas controla os sistemas
operacionais, a utilização dos recursos de storage, as aplicações publicadas
e possui limitado controle sobre os componentes de rede utilizados (MELL &
GRANCE, 2011).
3.4 MODELOS DE IMPLEMENTAÇÃO
 Cloud privada: A infraestrutura de cloud é provisionada para uso exclusivo de
uma organização que pode ser composta por múltiplos grupos de clientes
(por exemplo, diferentes unidades de negócio). Pode ser construída,
gerenciada e operada pela própria organização, por empresa terceira ou
alguma combinação entre elas. Pode ser implementada em Data Centers da
própria organização (on premises) ou em de terceiros (off premises).
17

 Cloud comunitária: A infraestrutura de cloud é provisionada para uso


exclusivo de um grupo de organizações com aspirações ou requisitos comuns
(alguns exemplos: missão, requisitos de segurança, políticas e normas de
compliance compartilhados). Pode ser construída, gerenciada e operada por
uma ou mais organizações do grupo, por empresa terceira, ou ainda por
alguma forma de combinação entre elas. Pode ser implantada em Data
Centers dos membros da comunidade (on premises) ou em de terceiros (off
premises).
 Cloud pública: A infraestrutura de cloud é aberta para uso do público em
geral e pode ser construída, gerenciada e operada por empresa privada,
entidade acadêmica, governamental ou alguma forma de combinação entre
elas. Sua instalação é realizada nos Data Centers do provedor da cloud.
 Cloud híbrida: A infraestrutura de cloud é composta de duas ou mais
infraestruturas de cloud distintas (privada, comunitária ou pública) que
permanecem como entidades separadas, porém interligadas por uma
tecnologia padronizada ou proprietária que permita a portabilidade de dados
e de aplicações entre elas (MELL & GRANCE, 2011).
18

4 INFRASTRUCTURE AS A SERVICE (IAAS)


4.1 INTRODUÇÃO
Muitas organizações buscam soluções de IaaS para maior agilidade no
provisionamento da infraestrutura de computadores e para a redução de custos
(espaço físico, energia elétrica, manutenção da infraestrutura, aquisição de
hardware, etc). No entanto para que uma estratégia de adoção de IaaS seja bem
sucedida é importante conhecer os objetivos e requisitos de implementação da
organização, as alternativas de provedores e de tecnologias, as melhores práticas e
limitações das soluções (SERRANO et al., 2014).
4.2 CARACTERÍSTICAS
Um dos principais benefícios do IaaS é adoção de uma arquitetura elástica,
cuja capacidade de processamento pode ser aumentada ou reduzida verticalmente
ou horizontalmente sob demanda, de forma automática ou manual. Quanto maior o
desacoplamento entre os componentes dos sistemas e das aplicações, maior será a
eficiência no uso deste modelo de serviço.
Nas arquiteturas de cloud as aplicações devem ser desenhadas para serem
tolerantes à falha e executarem com redundância de infraestrutura. Além de
estabelecer uma estratégia de continuidade de negócios, os sistemas devem estar
preparados para falhar e ser reiniciados a qualquer momento. Neste contexto o uso
de soluções automatizadas de detecção e isolamento de falhas é fundamental. São
exigidas também mudanças nos processos de publicação e configuração das
aplicações nos servidores, por meio da a adoção de ferramentas de automação, tais
como, Chef e Puppet (FELTER et al., 2014).
Para aplicações críticas é boa prática executá-las na cloud em clusters de
servidores pertencentes a diferentes zonas de disponibilidade (no mínimo em Data
Centers diferentes) e com balanceamento de carga entre elas. Assim em caso de
falhas da infraestrutura em uma das zonas de disponibilidade o serviço não é
interrompido.
Na cloud aplicações de diferentes organizações ou linhas de negócio
compartilham a mesma infraestrutura física e precisam ser isoladas logicamente
para que a privacidade dos dados não seja violada. Com IaaS aplicam-se as
mesmas práticas de segurança dos Data Centers tradicionais, como por exemplo,
19

segregação entre os ambientes de desenvolvimento, testes e produção, utilização


de firewall para isolamento dos acessos de rede, manter os serviços não
necessários dos servidores desabilitados e os softwares e sistemas operacionais
atualizados, e o uso de autenticação por chaves de acesso (FELTER et al., 2014).
4.3 PROVEDORES E TECNOLOGIAS
A maior parte dos provedores de cloud pública possui infraestrutura resiliente,
obtida por meio de Data Centers redundantes, clusters de máquinas virtuais com
mecanismos ágeis de detecção de falhas e restart automático em hardwares
diferentes. Em alguns casos consegue-se índices de disponibilidade de 99,999%.
Muitos destes provedores também oferecem soluções de cloud privada,
entregando ao cliente infraestrutura e ferramentas de gerenciamento de cloud
padronizadas, permitindo a migração de serviços entre as nuvens privada e pública,
de acordo com as necessidades do cliente.
A maioria dos provedores de IaaS públicas são orientados a atender as
necessidades das operações de TI tradicionais, com enfase no controle, governança
e segurança da infraestrutura, sem prover soluções que atendam as necessidades
específicas dos desenvolvedores de aplicações (SERRANO et al., 2014).
São comuns entre os provedores de IaaS a obtenção de índices de
disponibilidade mensais superiores a 99,95%, porém em casos de não cumprimento
dos SLAs a penalidade prevista para os provedores de cloud fica restrita a
descontos nos valores das mensalidades. Normalmente exclui-se dos SLAs as
indisponibilidades ocorridas durante as janelas de manutenção.
Poucos provedores de IaaS oferecem SLAs de desempenho da infraestrutura
de processamento ou de storage. O desempenho do storage pode variar
consideravelmente entre os provedores de cloud, pois nem todos disponibilizam
camadas de drive de estado sólido (SSD). SLAs de desempenho da rede são mais
comuns de serem encontrados.
Normalmente os clientes são responsáveis pela implementação das
estratégias de continuidade de negócios, podendo habilitar a réplica dos recursos
em zonas de disponibilidade distintas ou utilizar um serviço específico de
recuperação de desastres oferecido pelo provedor da cloud (SERRANO et al.,
2014).
20

Os provedores de cloud oferecem relatórios da utilização da infraestrutura,


cobrando mensalmente pelo tempo de utilização das máquinas virtuais ou pela
capacidade de recursos contratada (disco, processadores e/ou memória RAM).
A velocidade de provisionamento das máquinas virtuais varia entre os
provedores de cloud, especialmente quando é necessária a criação de diversas
máquinas simultaneamente. Este requisito é especialmente crítico durante a
ativação de planos de recuperação de desastres, onde normalmente é necessária a
criação de diversas máquinas virtuais em curto intervalo de tempo (SERRANO et
al., 2014).
O compartilhamento da infraestrutura da cloud por diversas aplicações pode
trazer limitações de desempenho. Por exemplo, o uso intensivo de recursos de
storage ou de rede por uma aplicação em uma VM em um servidor físico pode
degradar o desempenho de outras aplicações executadas em outras VMs no mesmo
servidor (SERRANO et al., 2014). Para diminuir o impacto deste problema alguns
provedores de cloud oferecem a possibilidade do cliente alocar suas VMs em
servidores físicos dedicados, sem a necessidade de pagar pelo uso da máquina
física inteira. De qualquer modo, VMs provisionadas nesta modalidade custam mais
caro do que VMs que usam recursos físicos compartilhados (LEONG, 2014).
Dentre os provedores de soluções de IaaS em cloud pública destacam-se a
AWS, Microsoft Azure, Rackspace, HP, Softlayer (IBM) e Google. Com exceção da
Rackspace todos os provedores citados utilizam soluções de cloud proprietárias.
Para a construção de cloud privadas e híbridas destacam-se as soluções
proprietárias da VMware e Microsoft e as soluções de código aberto OpenStack,
CloudStack e Eucalyptus (SERRANO et al., 2014).
4.4 OPENSTACK
OpenStack é uma solução open source de criação e gerenciamento de
infraestruturas de cloud. Desenvolvida originalmente pela NASA e a Rackspace
(CORRADI, 2012), hoje é mantida por uma fundação suportada por empresas como
AT&T, AMD, Cisco, Dell, HP, IBM, Intel, NEC, Red Hat, VMware, Yahoo, entre outras
(SERRANO et al., 2014).
O software OpenStack controla os recursos computacionais de
processamento, armazenamento e rede dos Data Centers através de APIs
21

OpenStack ou por interface gráfica. OpenStack inclui drivers para diversas


tecnologias open source e proprietárias, o que permite construir ambientes de cloud
sobre infraestruturas heterogêneas.
Sua tecnologia é composta por diversos componentes que disponibilizam
APIs acessadas por linha de comando ou interface web. Cada componente pertence
a um projeto open source específico. Abaixo segue uma descrição de alguns dos
projetos relacionados (OpenStack Software, 2016):
 Nova (Compute): Gerencia o ciclo de vida dos recursos computacionais no
ambiente OpenStack. É responsável pela alocação, desalocação e acesso
aos recursos computacionais. Os recursos são disponibilizados sob demanda
por meio de instâncias de processamento em máquinas físicas, virtuais ou
containers de sistema operacional.
 Neutron (Networking): Habilita conectividade de rede como um serviço para
outros serviços do OpenStack, como o Nova. Provê uma API para que os
usuários definam as configurações da rede. Sua arquitetura modular suporta
diversos fornecedores e tecnologias de rede.
 Swift (Object Storage): Responsável pelo armazenamento e recuperação de
objetos de dados não estruturados através de uma API REST. Sua arquitetura
é horizontalmente escalável e tolerante a falhas por meio de mecanismos de
replicação.
 Cinder (Block Storage): Provê estrutura de blocos de armazenamento
persistente para a utilização das instâncias de processamento. Sua
arquitetura modular facilita a criação e gerenciamento dos dispositivos de
armazenamento.
 Keystone (Identity): Provê serviços de autenticação e autorização para
outros serviços do OpenStack e um catálogo de acesso para as APIs de
todos os serviços.
 Glance (Image Service): Armazena e recupera imagens de servidores
virtuais para o provisionamento de novas instâncias para o OpenStack Nova.
 Magnum (Containers): Disponibiliza uma API para orquestração concorrente
de diversas tecnologias de containers, como Docker Swarm, Kubernetes e
Mesos em ambientes multi-tenant.
22

 Heat (Orchestration): Orquestra a composição de múltiplas aplicações de


cloud por meio de APIs.
Apesar do OpenStack ser uma tecnologia open source, as implementações
comerciais diferem bastante entre si, o que limita significativamente a portabilidade
de suporte de um fornecedor para outro (LEONG at al., 2014). Sua complexidade
pode ser uma barreira para a implementação por empresas não especializadas no
uso da tecnologia (SERRANO et al., 2014).
23

5 PLATFORM AS A SERVICE (PAAS)


5.1 INTRODUÇÃO
A adoção de soluções de PaaS (publicas e privadas) tem por objetivo
melhorar a produtividade dos times de desenvolvimento, reduzir o time-to-market
das entregas de TI para o negócio e reduzir o esforço operacional. Uma solução de
PaaS deve fornecer uma plataforma pronta para que os desenvolvedores possam
desenvolver, carregar o seu código e executá-lo (THOMAS, 2014).
5.2 CARACTERÍSTICAS
PaaS provê uma plataforma gerenciada para compilação, publicação e
execução das aplicações, retirando dos desenvolvedores preocupações com
aspectos relacionados a infraestrutura (máquinas virtuais, storage, rede, etc).
Oferece serviços e frameworks que suportam funções como autenticação, caching,
logging, medição, escalabilidade automática e integração, favorecendo a adoção de
boas práticas e forçando o uso de padrões de arquitetura, que possibilitem a entrega
das aplicações mais rapidamente.
Uma plataforma como serviço não é apenas software, pois tem impacto direto
no processos de desenvolvimento, versionamento e publicação das aplicações. Por
meio de um catálogo com templates pré definidos, o desenvolvedor pode
rapidamente configurar e provisionar suas aplicações através de um modelo de auto
serviço. Os usuários de PaaS devem ter capacidades de DevOps para maior
agilidade nas atividades de integração, publicação, versionamento e monitoração do
código durante todo o ciclo de vida das aplicações (THOMAS, 2014).
Os fornecedores de PaaS provêm ferramentas para análise estatística da
experiência dos usuários no uso das aplicações publicadas, como por exemplo, a
quantidade de vezes que a aplicação foi utilizada, quanto tempo elas despenderam
no uso, qual foi a utilização específica, como foi o desempenho e eventuais
problemas ocorridos durante a utilização.
As plataformas normalmente suportam desenvolvimento colaborativo e
linguagens de programação familiares aos desenvolvedores e permitem a
implementação de blocos de código via mecanismo drag-and-drop, reduzindo a
quantidade de esforço de codificação (LAWTON, 2008).
24

5.3 PROVEDORES E TECNOLOGIAS


Há diversas opções de PaaS disponíveis no mercado. Alguns exemplos são
Engine Yard, Red Hat OpenShift, Google App Engine, Salesforce Heroku, AppFog,
ActiveState Stackato, Cloud Foundry e BlueMix (IBM) (BERNSTEIN, 2014a). Muitas
plataformas de PaaS tem evoluído por meio da adoção de containers, tornando-as
mais interoperáveis. Abaixo segue um panorama desta evolução:
 A primeira geração de PaaS foi construída sobre plataformas proprietárias
como a Heroku e Azure.
 A segunda geração foi construída sobre soluções open source como
OpenShift e Cloud Foundry. Ambas permitem a publicação das aplicações em
cloud on premises ou em cloud pública e são baseadas em containers (a Red
Hat substituiu o seu modelo próprio de container usado no OpenShift pelo
Container Docker ao passo que o Cloud Foundry adotou um modelo de
container próprio chamado Diego).
 A terceira e atual geração inclui plataformas como Dawn, Deis, Flynn,
Octohost e Tsuru, que foram construídas baseadas em Docker desde o início
e suportam a publicação de aplicações em seus próprios servidores ou em
plataformas públicas de IaaS (PAHL, 2015).
25

6 CONTAINERS DOCKER
6.1 INTRODUÇÃO
Docker é uma plataforma open source baseada no kernel do Linux, que auto-
matiza o deployment de aplicações por meio de containers altamente portáveis e au-
tossuficientes, independente de hardware, linguagem e framework de desenvolvi-
mento. Apesar dos containers executarem em um host sobre um mesmo kernel de
sistema operacional, cada container pode executar diferentes versões de binários e
bibliotecas de SO, de acordo com os requisitos de cada aplicação. Através de uma
API de alto nível, Docker gerencia a criação de containers que executam as aplica-
ções de forma isolada (OpenStack. Docker).
Nos últimos anos, muitas mudanças em diferentes áreas de TI tem ocorrido
de forma simultânea. Na área de infraestrutura tem-se observado a evolução das
tecnologias disruptivas de containers, como o Docker. Ao mesmo tempo, na área da
arquitetura, as aplicações tem saído do modelo monolítico para o de micro serviços.
Em paralelo novas metodologias de processos como DevOps e continuous delivery
(CD) têm trazido conceitos de colaboração (entre as áreas de desenvolvimento e
operação), de que é normal falhar (desde que que a correção seja rápida), e que
feedbacks devem ser colhidos a cada publicação de código, entre outros. As evolu-
ções nestas três áreas de TI têm se realimentado e trazido avanços na habilidade de
entregar valor para o negócio de forma mais rápida.
Docker facilita a interação entre os times de desenvolvimento e de operação.
Enquanto no modelo tradicional são publicados entre os ambientes os binários da
aplicação, com o Docker a publicação é feita no nível do container. Em razão do
Docker encapsular a aplicação juntamente com o seu ambiente de execução (siste-
ma operacional e dependências, tais como, binários, bibliotecas, arquivos de confi -
guração, scripts, ambientes virtuais, jars, gems, tarballs e etc), ele provê dois impor-
tantes aspectos para o processo de entrega continua (CloudBees. Jenkins, Docker
and Devops: The Innovation Catalysts, 2015):
 Os desenvolvedores entregam Containers Docker e a operação de TI os pu-
blica. Deste modo garante-se que o mesmo pacote de binários será testado
em ambientes idênticos em todas as fases do processo de continuous deli-
26

very, sem que sejam inseridas falhas no ciclo de publicação entre os diferen-
tes ambientes;
 Os desenvolvedores recebem um ambiente de “sandbox” que pode ser facil-
mente reciclado sempre que necessário.
Através da plataforma as imagens com as aplicações podem ser alteradas e
versionadas, fazendo do Docker uma poderosa ferramenta no pipeline de desenvol-
vimento de sistemas ou como runtime em soluções de PaaS. Para que seja utilizada
no processo de desenvolvimento, Docker combina sua plataforma de containers com
workflows e ferramentas que auxiliam no gerenciamento e na publicação das aplica-
ções (Docker. Introduction to Container Security, 2015).
O uso de containers é bastante apropriado para a publicação de aplicações
construídas no estilo arquitetural de microservices. Com o uso desta abordagem as
funções de uma simples aplicação são decompostas em micro serviços
independentes e fracamente acoplados, que podem ser publicados na infraestrutura
em grupos de containers segregados. Cada micro serviço é executado em seu
próprio processo e comunica-se com outros micro serviços por mecanismos
assíncronos de comunicação. Estes serviços devem ser publicados de forma
independente por processos completamente automatizado. Em razão do
desacoplamento entre os serviços, alterações podem ser publicadas com grande
frequência e em momentos arbitrários, sem a necessidade de seguir janelas de
publicação ou de sincronizar a publicação das alterações juntamente com
modificações em outros serviços (PAHL, 2015).
6.2 ARQUITETURA E COMPONENTES
Docker foi desenhado em uma arquitetura cliente/servidor, onde o cliente
pode ser executado local ou remotamente ao servidor Docker (Docker Engine). A co-
municação entre o cliente e o servidor pode ser estabelecida por meio de sockets ou
RESTful APIs (APIs compatíveis com as restrições do estilo arquitetural REST).
Os Containers Docker utilizam file systems de atualização tipo copy-on-write,
que permitem o uso de uma imagem de file system como camada base para a exe-
cução de múltiplos containers. Alterações efetuadas em arquivos ou diretórios dentro
de um container são isoladas e não podem ser vistas fora dele (Docker. Introduction
to Container Security, 2015).
27

Docker foi escrito na linguagem “Go” e faz uso de funcionalidades nativas do


kernel Linux2 para a criação de containers de sistema operacional. Por esta razão os
servidores Docker precisam ser instalados, em máquinas virtuais ou físicas, em um
sistema operacional Linux3. A figura 5 ilustra a arquitetura da plataforma de Contai-
ners Docker. Abaixo segue uma breve descrição de seus componentes:
 Serviço Docker (daemon): Serviço executado no servidor Docker responsá-
vel por receber as conexões e comandos dos clientes para construir, empaco-
tar e executar os Containers Docker.
 Client Docker: Interface primária de interação do usuário com o daemon do
servidor Docker. É por meio do client Docker que os usuários executam os
comandos no servidor Docker.
 Imagens Docker: Cada imagem Docker é um template “somente leitura”
constituído por uma imagem de sistema operacional, bibliotecas e binários
das aplicações desejadas. Os usuários podem baixar imagens prontas, modi-
ficar configurações destas imagens, instalar novas aplicações e salvá-las
como novas imagens. Quando uma nova imagem é criada a partir de uma
imagem existente, uma nova camada de file system é adicionada ao sistema
de arquivos base para o armazenamento das alterações.
 Registros Docker: São repositórios de armazenamento das imagens Docker
que pode ser internos ou externos a organização. O Docker Hub é um serviço
de repositório SaaS acessível pela internet onde os fabricantes de software
disponibilizam suas imagens oficiais Docker para download. Os usuários po-
dem baixar, modificar as imagens padrão, criar as suas próprias imagens e
armazená-las de volta no Docker Hub ou em um repositório interno. No
Docker Hub é possível gravar imagens em áreas públicas ou privadas. Ima-
gens públicas são abertas para consultas e download para o público em ge-
ral. Imagens privadas são acessíveis apenas para usuários a quem foram
concedidas permissões de acesso.
 Containers Docker: Containers encapsulam todos os recursos necessários
para a execução das aplicações e são executados a partir do sistema opera-
2
. Atualmente Docker requer um kernel Linux de versão igual ou superior 3.1.0 (Docker. Check kernel
dependencies).
3
. Recentemente a Microsoft anunciou uma parecia com a Docker para estender as ferramentas e APIs Docker
para que ofereçam suporte a plataforma de containers da Microsoft que será lançada no Windows Server 2016
(Microsoft Azure. Containers: Docker, Windows e Trends, 2015).
28

cional do host que os hospedam. Podem ser iniciados, executados, parados,


movidos e apagados. Através dos containers as aplicações são executadas
em processos e área de memória isoladas.
 Docker files: São arquivos com instruções de como gerar uma nova imagem
Docker. As instruções descrevem um conjunto de passos para a criação da
nova imagem, o que inclui a execução de comandos, a inclusão de novos ar-
quivos ou diretórios, a criação de variáveis de ambiente e a definição de que
processos devem ser executados quando um novo container for iniciado por
meio da nova imagem criada (Docker. Understand the Architecture).

Figura 5. Arquitetura da plataforma de virtualização de Containers Docker.

Fonte: Adaptada de (Docker. Understand the Architecture).

6.3 EXECUÇÃO DE CONTAINERS


Para que um novo container seja criado um cliente envia um comando para o
daemon Docker do servidor informando como parâmetro o nome da imagem e o co-
mando a ser executado no container ao término de sua inicialização. Ao receber o
comando o servidor Docker passa a executar os procedimentos abaixo (Docker. Un-
derstand the Architecture):
 Baixa a imagem solicitada no servidor: caso a imagem não exista no servi-
dor ela é baixada do Docker Hub ou de um outro repositório configurado.
29

 Cria um novo container: Uma vez que o servidor Docker tenha a imagem,
ele a utiliza para criar o container.
 Aloca um sistema de arquivos e monta uma camada de “escrita e
leitura”: o container é criado no file system do servidor Docker e uma cama-
da de escrita e leitura é adicionada a imagem para uso das aplicações.
 Aloca uma interface de rede: cria uma interface de rede que permite a cone-
xão do container com o servidor Docker.
 Configura um endereço IP: Localiza um endereço IP disponível em um pool
e o configura no container.
 Executa um processo: executa uma aplicação especificada pelo usuário.
 Captura e gera arquivos de logs das aplicações: conecta e captura as
standards in, out e error do container para que o usuário possa verificar como
a suas aplicações estão rodando.
6.4 FUNDAMENTOS DA VIRTUALIZAÇÃO POR CONTAINERS
Assim como outras tecnologias de containers baseadas em Linux, Docker uti-
liza os mecanismos de namespaces e de control groups (cgroups) do kernel para,
respectivamente, isolar os processos entre os diferentes containers e monitorar/limi-
tar o uso dos recursos de infraestrutura. Adicionalmente, o sistema de arquivos dos
containers são do tipo Union File System, que implementam a montagem do sistema
de arquivos em múltiplas camadas (PAHL, 2015).
6.4.1 NAMESPACES
Segundo informação do man-pages do Linux (Linux Programmer's Manual.
NAMESPACES(7), 2014), um namespace encapsula um recurso global do sistema
em uma abstração, fazendo parecer aos processos pertencentes a este namespace,
que possuem sua própria instância de recurso global isolada.
Um container é um conjunto de namespaces criados por meio de uma interfa-
ce com o kernel. Constituem uma área de trabalho isolada para um grupo de proces-
sos. Cada processo é executado sobre determinado conjunto de namespaces, não
interagindo com recursos pertencentes a outros namespaces (Docker. Understand
the Architecture). Abaixo segue uma descrição dos namespaces providos pelo ker-
nel do Linux:
30

 IPC (Inter Process Communication): Isolam os objetos System V IPC (filas


de mensagens, semáforos e memória compartilhada) e filas de mensagem
POSIX. Cada namespace possui seu próprio conjunto de identificadores Sys-
tem V IPC e seu próprio file system de filas de mensagem POSIX. Objetos
criados em um namespace de IPC são visíveis para todos os outros proces-
sos membros deste namespace, porém não são visíveis para processos de
outros namespaces de IPC.
 Network: Provê isolamento dos recursos do sistema associados com a rede
(interfaces de rede, pilhas de protocolo IPv4 e IPv6, tabelas de roteamento, fi-
rewalls, diretórios /proc/net e /sys/class/net, sockets e etc). Uma interface de
rede física pode pertencer somente a um único namespace de rede. Um par
de dispositivos virtuais de rede (“veth”) provê uma abstração do tipo “pipe”
para a criação de túneis entre namespaces de rede e para criar uma bridge
com a interface física de rede pertencente a outro namespace.
 Mount: Isolam o conjunto de mount points dos file systems de maneira que
processos em diferentes namespaces de mount possam ter diferentes visões
da hierarquia dos file systems. Através dos arquivos /prod/[pid]/mount é possí-
vel visualizar os file systems montados no namespace de mount de cada pro-
cesso.
 PID (process ID): Isolam os números de PID, de maneira que processos em
diferentes namespaces de PID possam ter os mesmos números de proces-
sos. Isto permite, por exemplo, a migração de containers para um novo servi-
dor sem alterar os números dos processos dos containers.
 User: Isolam identificadores e atributos relacionados a segurança, em particu-
lar, IDs de usuários e grupos, diretório root, chaves e capacidades do kernel
relacionadas a permissão de acesso. Os IDs de usuário e de grupo de um
processo podem ser diferentes dentro e fora do namespace de user, de modo
que o processo tenha total privilégios para a realização de operações dentro
do namespace, mas nenhum privilégio fora dele (Linux Programmer's Manual.
NAMESPACES(7), 2014).
 UTS (Unix Timesharing System): Isola os identificadores de nome do host
(hostname) e nome de domínio (domainname) no sistema. No contexto dos
containers, este namespace permite com que cada container tenha hostname
31

e domain name próprios (LWN.net. Namespaces in operation, part 1: names-


paces overview, 2013).
6.4.2 CONTROL GROUPS (cgroups)
É um recurso do kernel Linux que permite alocar, priorizar, negar, gerenciar e
monitorar os recursos do sistema, tais como cpu, memória, disco e rede ou uma
combinação destes recursos entre grupos de tarefas (processos) executadas no sis-
tema. Abaixo seguem suas principais características:
 Cgroups são organizados em hierarquias, onde cada cgroup filho herda (em
um primeiro momento) as características do cgroup pai.
 Cada sistema Linux pode ter diversas hierarquias.
 Cada hierarquia pode anexar recursos de um ou mais subsistemas (ou con-
trolador de recursos) relacionados aos processadores, memória, rede e etc.
 Não é possível que um subsistema anexado a uma hierarquia possa ser ane-
xado a uma outra hierarquia que já possua um subsistema anexado.
 Não é permitido a um mesmo processo pertencer a mais de um control group
em uma mesma hierarquia, porém, um mesmo processo pode pertencer a
control groups de hierarquias diferentes.
 Novos processos criados herdam os cgroups aos quais os seus pais perten-
cem.
A figura 6 ilustra um sistema em que foram criadas duas hierarquias de con-
trol groups (cpu_mem_cg e net). Anexados a hierarquia cpu_mem_cg estão os sub-
sistemas “cpu” e “memory” e anexado a hierarquia net está o subsistema “net_cls”.
O processo httpd (PID 54656) pertence ao cgroup cg1 da hierarquia cpu_mem_cg e
ao cgroup cg3 da hierarquia net. O control group cg1 da hierarquia cpu_mem_cg
pode, por exemplo, restringir o tempo de consumo de cpu em 15% e o consumo de
memória a no máximo 512 MB para o processo httpd. Ao mesmo tempo, o control
group cg3 da hierarquia net pode estar configurado para permitir taxas de transmis-
são de até 50 MB/s, restringindo a largura de banda do processo httpd (Red Hat Re-
source Management Guide. Chapter 1. Introduction to Control Groups (Cgroups),
2015).
32

Figura 6. Sistema com duas hierarquias de control groups e respectivos subsistemas


anexos.

Fonte: Adaptada de (Red Hat Resource Management Guide. Chapter 1. Introduction


to Control Groups (Cgroups), 2015).

Abaixo segue uma breve descrição dos tipos de subsistemas disponibilizados


aos cgroups do Linux (Red Hat Resource Management Guide. Chapter 1. Introducti-
on to Control Groups (Cgroups), 2015):
 blkio: define limites de I/O para os dispositivos de armazenamento de bloco
(disco rígido, drive de estado sólido, usb, etc).
 cpu: divide o tempo de cpu entre os processos pertencentes aos cgroups.
 cpucct: gera relatórios automáticos de utilização de cpu de cada processo de
um cgroup.
 cpuset: atribui cpus individuais e nós de memória aos processos dentro de
um cgroup.
 devices: permite ou nega acesso aos dispositivos para os processos de um
cgroup.
 freezer: suspende ou retoma processos de um cgroup.
 memory: limita o uso de memória para os processos de um cgroup e gera re-
latórios automáticos de consumo de memória por estes processos.
 net_cls: inclui nos pacotes de rede “tags” de identificação de classe (classid)
que possibilitam ao Linux Traffic Controller (TC) identificar pacotes originados
33

de um determinado processo de um cgroup. O TC pode ser configurado para


atribuir diferentes prioridades para os pacotes de diferentes cgroups.
 net_prio: provê uma maneira de configurar a prioridade do tráfego de rede
por interface de forma dinâmica.
 ns: provê uma maneira de agrupar processos dentro de namespaces separa-
dos.
6.4.3 UNION FILE SYSTEMS (UnionFS)
São file systems que atuam na sobreposição de arquivos e diretórios das ima-
gens Docker pertencentes a diferentes file systems, em um sistema de arquivos úni-
co e coeso. Esta é uma das características que permitem que as imagens Docker
sejam leves e de fácil portabilidade. Docker pode utilizar diversas variações de Uni-
onFS, incluindo “AUFS”, “btrfs”, “vfs” e “DeviceMapper” (Docker. Understand the Ar-
chitecture).
6.4.4 INTERFACE COM O KERNEL
A partir da versão 0.9 o servidor Docker passou a utilizar o driver libcontainer,
escrito na linguagem “Go”, como padrão de acesso as APIs de containers do kernel.
A tradicional interface LXC (Linux Containers) continua sendo suportada, porém não
é necessária para o provisionamento de Containers Docker (Docker Blog. Docker
0.9: introducting execution drivers and libcontainer, 2014).
6.5 SEGURANÇA
6.5.1 SEGURANÇA DO SERVIDOR DOCKER
Para garantir a integridade e confidencialidade das informações, toda comuni-
cação entre o servidor Docker e os repositórios de registros deve ser efetuada por
meio de protocolo TLS e uso de chaves de criptografia.
Atualmente o daemon Docker requer privilégios de root para execução, o que
implica em problemas de segurança. Através do daemon Docker é possível compar-
tilhar um file system do host com um container, sem limitar os direitos de acesso do
container, sendo possível portanto, que processos do container modifiquem arquivos
do host. Por esta razão é fortemente recomendado que o acesso ao daemon Docker
seja restrito a usuários confiáveis.
34

O servidor Docker (Docker Engine) ainda não suporta namespaces do tipo


user4. Este namespace do kernel permite mapear os IDs de usuários dentro dos
containers para outros IDs fora deles. Isto possibilita, por exemplo, que um usuário
root dentro de um container tenha ID 0, mas no host tenha ID 2000. Deste modo o
usuário tem privilégios de root dentro dos container e privilégios de usuário comum
no host. O problema de compartilhamento de file systems entre o host e os contai-
ners será solucionado quando o Docker oferecer suporte ao namespace user, pois
deste modo o usuário root terá IDs diferentes no host e nos containers (Docker.
Docker Security).
Por não haver suporte para o namespace user, não deve-se permitir a execu-
ção de processos nos containers com o usuário root, pois este usuário terá totais pri-
vilégios de root sobre o host (MOAT, 2015).
Mecanismos de segurança tais como TOMOYO, AppArmor, SELinux e GR-
SEC são suportados. Docker recomenda executar o kernel Linux com GRSEC e
PAX para aumentar a proteção contra as técnicas comuns de ataque (Docker. Intro-
duction to Container Security, 2015).
6.5.2 SEGURANÇA DOS CONTAINERS
A tecnologia dos containers aumenta por padrão a segurança das aplicações
em razão da camada de isolamento aplicada entre as aplicações e entre as aplica-
ções e o servidor (host) e pelas restrições de acesso adicionadas. O modelo de con-
tainer força com que as aplicações sejam executadas em ambientes virtuais isola-
dos, por meio de namespaces separados para cada container executado. Processos
executados sob os mesmos namespaces tem visibilidade uns sobre os outros, po-
rém, executam isolados de outros processos. Os control groups do kernel permitem
o compartilhamento do hardware entre os processos dos containers de forma contro-
lada, possibilitando restringir e monitorar a utilização dos recursos de cada contai-
ner.
Para reduzir as possibilidades de escalação de privilégio que podem ser ex-
ploradas por vulnerabilidades das aplicações, os containers limitam por padrão a
quantidade das capabilities5 disponíveis para menos da metade do total das capaci-
4
. Apesar de não suportar namespaces do tipo user diretamente, é possível utilizá-lo nos containers através da
chamada de sistema clone ou do utilitário unshare sobre os kernels suportados.
5
. Linux capabilities ou capacidades são recursos que permitem especificar de forma granular os privilégios de
acesso aos recursos do sistema operacional. Exemplos: chown, sys_admin, sys_boot, entre outras (Linux
Programmer's Manual. CAPABILITIES(7)).
35

dades existentes no kernel Linux. Na maioria dos casos as aplicações executadas


nos containers não precisam de nível de privilégio de root, ficando estas permissões
restritas a tarefas do sistema operacional, que são executadas fora dos containers. A
execução dos containers com reduzidas capacidades de permissão melhora o nível
de segurança do sistema e torna a execução das aplicações mais segura. Mesmo
em caso de intrusão de um container, quando o invasor consegue escalação de pri-
vilégio para o nível de root, as restrições de capacidade do container tornam difícil
danificá-lo. Por padrão os containers não possuem acesso aos dispositivos físicos
do host. As permissões devem ser explicitamente concedidas através dos mecanis-
mos de control groups. Estas restrições protegem o kernel e o hardware do host do
uso indevido pelas aplicações executadas nos containers.
A gravação de novas imagens Docker a partir de modificações em containers
são logadas para fins de compliance/auditoria, auxiliando também no rápido retorno
das aplicações para versões anteriores, em caso de problemas ou detecção de vul-
nerabilidades.
São necessários acesso a poucos file systems do kernel para execução das
aplicações nos containers e a maioria dos arquivos mandatórios (por exemplo, os
encontrados em /sys ou /proc) são montados como “somente leitura”, o que limita a
capacidade de modificação dos arquivos do sistema operacional mesmo para pro-
cessos privilegiados dos containers.
Docker permite adicionar alguns controles em tempo de execução dos contai-
ners, como por exemplo, modificar as capabilities padrão do Docker (adicionar ou re-
mover capacidades de permissão), modificar permissões de leitura/escrita de file
systems ou ainda desabilitar determinadas chamadas de sistema (syscalls) dos pro-
cessos dos containers por meio do seccomp (secure computing mode).
A aplicação de patches nos containers pode ser efetuada sobre a imagem
base do sistema operacional do host. Uma vez que o patch é aplicado, uma nova
versão da imagem atualizada pode ser gerada. Deste modo os containers podem
ser recriados e testados para verificar possíveis impactos sobre as aplicações
(Docker. Introduction to Container Security, 2015).
36

6.6 MODELOS DE OPERAÇÃO


6.6.1 CONTAINERS EM MÁQUINAS FÍSICAS (BARE METAL)
Os containers adicionam uma camada de isolamento entre o host e suas apli-
cações, aumentando a segurança das aplicações em relação a não utilizar nenhuma
tecnologia de container ou de virtualização. Por compartilharem o mesmo sistema
operacional do host, os containers são muito leves, o que possibilita a execução de
uma alta densidade de containers em um mesmo servidor físico.
Porém, através dos containers não é possível tirar proveito do isolamento ob-
tido com as tecnologias de virtualização de hardware desenvolvidas pela Intel (VT-x)
e AMD (AMD-V) em seus processadores, pois estas foram desenvolvidas para se-
rem operadas por um hypervisor (Docker. Introduction to Container Security, 2015).
A figura 7 ilustra o modelo de aplicações encapsuladas em Containers Docker, exe-
cutados diretamente em um servidor físico.

Figura 7. Containers Docker em máquina física.

Fonte: Adaptada de (Docker. Introduction to Container Security, 2015).

6.6.2 CONTAINERS EM MÁQUINAS VIRTUAIS (VMs)


VMs e containers são utilizados para a execução de aplicações em ambientes
isolados em um host compartilhado, sob diferentes perspectivas técnicas, e podem
ser executados com sucesso juntos ou separados, dependendo das necessidades
de ambiente da aplicação.
37

Cada máquina virtual executa um sistema operacional completo, o que inclui


seu próprio gerenciamento de memória e drivers dos dispositivos virtuais. Diversas
máquinas virtuais de sistemas operacionais diferentes podem ser executadas juntas
em um mesmo host (Docker. Introduction to Container Security, 2015). Neste cenário
o isolamento das aplicações é obtido no nível da VM pelo hypervisor que pode ope-
rar em conjunto com os mecanismos de virtualização do hardware (NEIGER et al.,
2006).
Os Containers Docker são executados sobre um sistema operacional compar-
tilhado de um host, o que diminui o overhead de carregar diversos sistemas operaci-
onais em memória para a execução das aplicações. Esta caraterística faz com que
os containers sejam leves, rápidos e fáceis de escalar, permitindo a execução de
uma alta densidade de containers por host. O isolamento é obtido no nível das apli-
cações por meio do servidor Docker.
Executar um grupo de Containers Docker sobre uma máquina virtual aumenta
a segurança por prover duas camadas de isolamento para as aplicações. Com o
Docker obtém-se o isolamento por processos dentro da máquina virtual, o controle
do uso dos recursos de hardware pelas aplicações e todos os benefícios de segu-
rança, publicação e portabilidade das aplicações apresentados anteriormente. Com
o hypervisor obtém-se o isolamento por VM e todas as características de alta dispo-
nibilidade, continuidade e de migração “a quente” bastante maduras encontradas
nas diversas tecnologias de virtualização (Docker. Introduction to Container Security,
2015). A figura 8 ilustra o modelo de aplicações encapsuladas em Containers
Docker, executados em máquinas virtuais.
38

Figura 8. Containers Docker em máquinas virtuais.

Fonte: Adaptada de (Docker. Introduction to Container Security, 2015).

6.7 INDICAÇÕES DE USO DE CONTAINERS E MÁQUINAS VIRTUAIS


Grande parte das soluções comerciais de cloud utilizam hypervisors para a
disponibilização de máquinas virtuais para os seus clientes. Por exemplo, os prove-
dores de cloud Rackspace e AWS utilizam como base de sua cloud pública o XEN
Hypervisor, a HP e a AT&T utilizam o hypervisor KVM, enquanto a Microsoft utiliza o
seu hypervisor proprietário Hyper-V. Outras soluções de porte como a Google e a
Softlayer (IBM) são baseadas em containers e portanto não utilizam hypervisors
(BERNSTEIN, 2014b).
Do ponto de vista funcional as VMs e os containers apresentam para as apli-
cações interfaces de um sistema operacional por meio de diferentes técnicas de vir-
tualização (BERNSTEIN, 2014b). Porém para Pahl (2015), as técnicas utilizadas tem
por objetivo resolver problemas diferentes. Enquanto as máquinas virtuais tem por
objetivo o provisionamento do hardware e o gerenciamento da infraestrutura para as
aplicações (prerrogativas das soluções de IaaS), os containers tem por objetivo a
entrega de software de maneira padronizada e portável entre diferentes infraestrutu-
ras (prerrogativas das soluções de PaaS).
Com os hypervisors, cada máquina virtual executa uma imagem completa e
isolada de sistema operacional, o que permite a execução de múltiplas máquinas vir-
tuais com sistemas operacionais diferentes em uma mesma infraestrutura física
39

(BERNSTEIN, 2014b). Cada VM torna-se uma unidade independente, com um siste-


ma operacional, binários e bibliotecas necessárias para a execução das aplicações,
o que resulta em maior necessidade de memória e espaço em disco, consequente-
mente tornando lento o processo de inicialização (PAHL, 2015).
Com containers, cada aplicação compartilha um mesmo sistema operacional,
binários e bibliotecas, o que resulta em ambientes de execução menores do que o
das máquinas virtuais, possibilitando a execução de centenas de containers em uma
mesma máquina física. Por compartilharem o sistema operacional do host que os
hospeda, o tempo de inicialização de um container é muito inferior ao de uma VM,
pois não é necessário executar o processo de boot do sistema operacional.
Isolamento é um requisito fundamental quando aplicações de linhas de negó-
cio ou empresas diferentes compartilham um mesmo ambiente de cloud. Uma apli-
cação não pode afetar a execução ou ter acesso a dados de uma outra em razão de
compartilharem a mesma infraestrutura (FELTER et al., 2014). Neste aspecto a tec-
nologia de máquinas virtuais é superior a de containers (OpenStack White Paper.
Exploring Opportunities: Containers and OpenStack, 2015).
Portanto, para casos de uso em que não seja admissível que problemas em
uma aplicação possam causar impacto sobre outras, ou ainda para maior garantia
de confidencialidade dos dados entre estas aplicações, o uso de máquinas virtuais é
o mais indicado. Porém, como mostrado no subtópico “Modelos de Operação”, Con-
tainers Docker podem ser executados sobre máquinas virtuais. Assim é possível
executar aplicações de diferentes linhas de negócios em máquinas virtuais isoladas
e, internamente em cada VM, segregá-las em containers, conferindo às aplicações
maior isolamento na execução, maior agilidade e segurança no processo de deploy-
ment, e como consequência da redução do número de máquinas virtuais, menor
overhead da infraestrutura.
6.8 ORQUESTRAÇÃO DE CONTAINERS
Para que seja possível publicar e rastrear a execução de múltiplos containers
simultaneamente, diversas soluções de orquestrações vem sendo utilizadas no ge-
renciamento de Containers Docker. Abaixo segue uma breve descrição de algumas
destas soluções (Microsoft Azure. Containers: Docker, Windows e Trends, 2015):
40

 Docker Compose: é uma ferramenta para definir e executar aplicações em


múltiplos Containers Docker. Compose utiliza um arquivo de configuração
para definir os diversos serviços que compõe a aplicação. Através da execu-
ção de um comando todos os serviços definidos são executados em seus res-
pectivos containers (Docker. Compose).
 Docker Swarm: é a solução de cluster nativa do Docker. Ela agrupa um con-
junto de hosts Docker em um único host virtual. Em razão de utilizar as mes-
ma APIs do daemon Docker, qualquer ferramenta que já se comunique com o
servidor Docker pode utilizar Swarm para escalar a execução de seus contai-
ners sobre os hosts do cluster. Seguem algumas das ferramentas suportadas:
 Dokku
 Docker Compose
 Krane
 Jenkins
 Mesos (solução open source de cluster de nós computacionais).
 Client Docker (Docker. Swarm)
 Kubernetes: é uma plataforma open source construída pela Google que per-
mite a construção de Pods (pool of devices) de containers para execução em
múltiplos hosts (Google Kubernetes. Home).
6.9 DOCKER COM OPENSTACK
OpenStack implementa uma solução completa para gerenciamento de Data
Centers, o que inclui a execução de aplicações por meio de máquinas virtuais em
hypervisors e, mais recentemente, por Containers Docker. O gerenciamento de Con-
tainers Docker passou a ser suportado na versão Liberty do OpenStack, por meio do
projeto Magnum, lançada em Outubro de 2015 (OpenStack. Releases).
Magnum permite a utilização concorrente de múltiplas tecnologias de contai-
ners executadas sobre as Bays (instâncias de execução do Nova) e suporta a or-
questração de Containers Docker através de ferramentas como o Docker Swarm,
Kubernetes e Mesos. As instâncias Bay são criadas através do Heat (orquestrador
OpenStack), que executa uma imagem de sistema operacional que contenha o
Docker Swarm, Kubernetes ou Mesos em máquinas físicas ou virtuais, em uma con-
figuração de cluster.
41

Recursos criados através do Magnum podem ser visualizados e acessados


somente por usuários pertencentes ao tenant criado (segregação, que pode ser por
exemplo, por linha de negócio ou organização). Cada tenant é executado sobre sua
própria instância de sistema operacional, o que confere aos processos executados
em seus containers um alto grau de isolamento. Cada Bay pertence exclusivamente
a um único tenant (OpenStack White Paper. Exploring Opportunities: Containers and
OpenStack, 2015). Abaixo segue uma breve descrição dos diferentes tipos de obje-
tos do sistema Magnum:
 Bay: uma coleção de instâncias do Nova (instância de processamento do
OpenStack).
 BayModel: um objeto que armazena informação sobre templates para a cria-
ção de bays consistentes.
 Node: uma máquina física ou virtual onde os containers são executados.
 Pod: uma coleção de containers executados sobre uma máquina física ou vir-
tual.
 Service: uma abstração que define um conjunto lógico de Pods e uma política
para acessá-lo.
 Replication Controller (RC): uma abstração para gerenciar um grupo de
Pods e certificar que um número determinado de recursos estão em execu-
ção.
 Container: um Container Docker.
A figura 9 mostra os binários Magnum REST API e Magnum Conductor traba-
lhando em conjunto. Quando o Magnum Client envia uma solicitação para o Mag-
num Server, este a repassa por mensagem AMQP para o processo do Magnum Con-
ductor, que por sua vez conecta-se ao endpoint de APIs REST do Kubernetes ou do
Docker Swarm. Os endpoints de API REST do Kubernetes e do Docker são gerenci-
ados pelo objeto Bay.
Quando um serviço ou um Pod é criado, é possível conectar-se diretamente
ao Kubernetes por meio de sua API REST. Do mesmo modo, quando Containers
Docker são executados, também é possível acessá-los diretamente pela sua API
REST (OpenStack. Magnum's Developer Documentation).
42

Figura 9. Arquitetura de provisionamento de containers do OpenStack Magnum.

Fonte: Adaptada de (OpenStack White Paper. Exploring Opportunities: Containers


and OpenStack, 2015).
43

7 CONCLUSÃO
7.1 CONSIDERAÇÕES FINAIS
A adoção de uma tecnologia de IaaS como o OpenStack traz muitos recursos
de automação, que possibilitam o provisionamento automático de servidores, stora-
ge e rede de forma rápida e padronizada e agilizam a detecção e isolamento de fa-
lhas. Entre seus recursos está a possibilidade de escalabilidade da infraestrutura de
forma automática, baseada em parâmetros pré-configurados e em indicadores provi-
dos pela monitoração.
Do ponto de vista do negócio, espera-se minimamente de uma solução de
cloud a redução do time-to-market de entrega das aplicações, maior disponibilidade
e escalabilidade do ambiente de TI, maior controle sobre os SLAs e cobrança como
serviço baseada na simples utilização de recursos.
Do ponto de vista técnico, a base das soluções de cloud está na virtualização
da infraestrutura de execução das aplicações. O uso de máquinas virtuais (VM) é
comprovadamente um meio eficiente e seguro de compartilhar a infraestrutura de
hardware entre diferentes aplicações. Porém, cada VM tem o overhead de carregar
uma imagem de sistema operacional completa, que consome memória do servidor e
torna o processo de inicialização das aplicações lento (cerca de minutos), em decor-
rência da dependência do processo de boot do sistema operacional.
Por outro lado, o uso de containers como o Docker permite a execução de
aplicações em processos e áreas de memória isoladas, sobre um único sistema ope-
racional em máquina física ou virtual, e com a possibilidade de limitar o uso dos re-
cursos do hardware de cada container. Porém, como vimos, o isolamento consegui-
do com containers é inferior ao entregue pelos hypervisors. Vulnerabilidades novas
do kernel e de escalação de privilégios de usuário para root dentro de um container
podem comprometer a segurança do host e impactar a execução de todos os contai-
ners, além da falta de suporte no uso da virtualização de hardware dos processado-
res, que oferece um nível a mais de isolamento. Portanto, para casos de uso que
exijam maior garantia de isolamento entre as aplicações, o uso de máquinas virtuais
é mais adequado.
Porém, no caso de aplicações construídas com arquitetura de microservices é
bastante dispendioso executar uma grande quantidade de micro serviços (dezenas,
centenas ou milhares deles) sobre máquinas virtuais, pois conceitualmente cada mi-
44

cro serviço deverá ser executado sobre sua própria VM. Em situações como esta o
uso de containers é mais apropriado, permitindo a execução das aplicações isola-
das, com baixo overhead da infraestrutura e tempos de inicialização na casa de se-
gundos.
Os requisitos de negócio de maior controle sobre os SLAs e cobrança como
serviço são facilmente endereçáveis através dos relatórios da solução da IaaS. A re-
dução do time-to-market da entrega das aplicações, porém, não depende apenas do
provisionamento rápido da infraestrutura. Requer um processo de desenvolvimento
e de publicação de aplicações eficiente.
Muitas empresas tem optado por processos de continuous delivery, que em
essência combina processos e ferramentas que automatizam tarefas de compilação,
empacotamento, testes e publicação das aplicações (não necessariamente em pro-
dução), dando agilidade ao processo de desenvolvimento e maior flexibilidade e se-
gurança para a publicação e rollback de código (quando necessário) em produção. A
tecnologia de Containers Docker facilita o processo de desenvolvimento em razão
de publicar entre os diferentes ambientes não apenas os binários da aplicação, mas
todo o ambiente de execução, o que torna o processo efetivo e confiável. Por esta
razão muitas soluções de PaaS tem adotado o uso de Containers Docker como seu
runtime.
O uso de Containers Docker também favorece uma maior disponibilidade e
agilidade na escalabilidade dos serviços. Em caso de indisponibilidade da infraestru-
tura ou aumento da demanda no consumo dos serviços detectadas pela monitora -
ção, basta que a ferramenta de automação, por meio das APIs Docker, traga do re-
positório a imagem Docker com o atual release de produção e a execute como con-
tainer em um servidor físico ou virtual por meio do daemon Docker. Caso o host já
tenha uma imagem de releases anteriores, apenas os arquivos modificados no rele-
ase corrente são trazidos do repositório. Deste modo, em poucos segundos novas
instâncias da aplicação estarão em execução nos containers.
Portanto, como diretriz geral para o provisionamento de servidores, aplica-
ções de diferentes linhas de negócio devem ser executadas em máquinas virtuais
separadas. Porém dentro de um mesmo negócio, as aplicações podem ser divididas
em um menor número de máquinas virtuais, onde cada VM terá os seus serviços
45

executados isolados em Containers Docker. Esta modelo tira proveito do melhor dos
dois mundos:
 A utilização dos mecanismos nativos de alta disponibilidade, migração “a
quente” e isolamento entre as aplicações de diferentes linhas de negócio atra-
vés de máquinas virtuais.
 O isolamento e controle do uso de recursos entre as diferentes aplicações de
uma mesma linha de negócio, somada a agilidade e segurança na publicação
da aplicações por meio dos containers.
 A redução do overhead de infraestrutura em razão da redução do número de
máquinas virtuais em execução.
A tecnologia de containers está em constante evolução. Atualmente o uso de
Containers Docker é restrito para aplicações baseadas em Linux. A Microsoft anunci-
ou, porém, o desenvolvimento de sua plataforma de containers baseada no kernel
do Windows que será oficialmente lançada no Windows Server 2016. As APIs do
Docker estão sendo portadas para o Windows, de maneira que os clients Docker te-
nham interoperabilidade entre as plataformas e os usuários tenham a mesma experi-
ência de uso com Linux ou Windows.
Em razão da extensão das APIs Docker para o Windows, quando os contai-
ners Windows tornarem-se realidade, as mesmas ferramentas de automação do ci-
clo de desenvolvimento de sistemas poderão ser utilizadas para o provisionamento
de containers Linux ou Windows e funcionarão exatamente da mesma forma. Deste
modo os processos de desenvolvimento e de operação de TI serão simplificados,
agregando maior valor ao negócio.
7.2 TRABALHOS FUTUROS E MELHORIAS
Alguns assuntos importantes foram citados ou tratados apenas de maneira
superficial. Novos trabalhos de pesquisa, em continuidade a este, poderiam abordá-
los mais profundamente. Alguns deles são:
 Integração de ferramentas de automação de processos de continuous inte-
gration e continuous delivery (exemplo, Jenkins) com um orquestrador Docker
(exemplos, Docker Swarm e Docker Compose), integrados com a solução de
provisionamento de infraestrutura de containers do Magnum OpenStack.
 Estudo das funcionalidades e fundamentos da nova solução de containers ba-
seada no kernel Windows.
46

8 REFERÊNCIAS
BERNSTEIN, D. IEEE Cloud Compute Magazine. Cloud Foundry Aims to Become
the OpenStack of PaaS, v.1, Issue 2, p. 57-60, July 2014.

BERNSTEIN, D. IEEE Cloud Compute Magazine. Containers and Cloud: From


LXC to Docker to Kubernetes, v.1, Issue 3, p. 81-84, Sept. 2014.

BOVET, D. P. & CESATI, M.: Understanding the Linux Kernel, Third Edition.
Sebastopol: Oreilly, 2005. 19p.

CLOUDBEES. Jenkins, Docker and Devops: The Innovation Catalysts, 2015.


Disponível em: https://pages.cloudbees.com/rs/083-PKZ-512/images/Docker-
Jenkins-Continuous-Delivery.pdf. Acesso em: 12 Jan. 2016.

DOCKER Blog. Docker 0.9: introducting execution drivers and libcontainer, Mar.
2010. Disponível em:
https://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-
libcontainer/. Acesso em: 10 Jan. 2016

DOCKER. Check kernel dependencies. Disponível em:


https://docs.docker.com/engine/installation/binaries/. Acesso em: 9 Jan. 2016.

DOCKER. Compose. Disponível em:


https://docs.docker.com/compose/. Acesso em: 13 Jan. 2016.

DOCKER. Docker Security. Disponível em:


https://docs.docker.com/engine/articles/security/ Acesso em: 11 Jan. 2016.

DOCKER. Docker Swarm. Disponível em:


https://docs.docker.com/swarm/ Acesso em: 13 Jan. 2016.

DOCKER. Introduction to Container Securiy, 2015. Disponível em:


https://www.docker.com/sites/default/files/WP_Intro%20to%20container
%20security_03.20.2015%20%281%29.pdf. Acesso em: 2 Jan. 2016.

DOCKER. Understand the Architecture. Disponível em:


https://docs.docker.com/engine/introduction/understanding-docker/. Acesso em: 08
Jan. 2016.
47

FELTER, W. et al. Technology: An Updated Performance Comparison of Virtual


Machines and Linux Containers, IBM Research Division, 11501 Burnet Road,
Austin, TX, 2014.

GOOGLE Kubernetes. Home. Disponível em:


http://kubernetes.io/ Acesso em: 13 Jan. 2016.

INTEL. Intel® Virtualization Technology for Directed I/O (VT-d): Enhancing Intel
platforms for efficient virtualization of I/O devices, Mar. 2012. Disponível em:
https://software.intel.com/en-us/articles/intel-virtualization-technology-for-directed-io-
vt-d-enhancing-intel-platforms-for-efficient-virtualization-of-io-devices#_edn1. Acesso
em: 13 Jan. 2016.
LAWTON, G. Computer. Developing Software Online with Platform-as-a-Service
Technology, v. 41, Issue 6, p. 13-15, 2008. ISSN: 0018-9162.

Linux Programmer's Manual. CAPABILITIES(7). Disponível em:


http://man7.org/linux/man-pages/man7/capabilities.7.html, 2015. Acesso em: 10 Jan.
2016.

Linux Programmer's Manual. NAMESPACES(7). Disponível em:


http://man7.org/linux/man-pages/man7/namespaces.7.htm, 2014. Acesso em: 9 Jan.
2016.

LWN.net. Namespaces in operation, part 1: namespaces overview, 2013.


Disponível em: https://lwn.net/Articles/531114/. Acesso em: 10 Jan. 2016.

MELL, P. & GRANCE, T.: National Institute of Standards and Technology. The NIST
Definition of Cloud Computing, 2011.

MICROSOFT Azure. Containers: Docker, Windows e Trends, 2015. Disponível


em: https://azure.microsoft.com/pt-br/blog/containers-docker-windows-and-trends/?
cdn=disable. Acesso em: 13 Jan. 2016.

MOUAT, A.: Docker Security – Using Containers Safely in Production, First


Edition. Sebastopol: Oreilly, 2015. 6p.

NEIGER, G. et al. Intel® Virtualization Technology: Hardware Support for Efficient


Processor Virtualization. Intel Technology Journal, v. 10, Issue 3, p. 167-177, 2006.

NEMETH, E. & SNYDER, G. & HEIN, T. R. & WHALEY, B.: Unix and Linux System
Administration Handbook, Fourth Edition. Boston: Person Education, 2011. 983-
991p.

OPENSTACK. Docker.
Disponível em: https://wiki.openstack.org/wiki/Docker#Overview. Acesso em:
12/01/2016.
48

OPENSTACK. Magnum's Developer Documentation.


Disponível em: http://docs.openstack.org/developer/magnum/. Acesso em: 13 Jan.
2016.

OPENSTACK. OpenStack Software. Disponível em:


http://www.openstack.org/software. Acesso em: 2 Jan. 2016.

OPENSTACK. Releases. Disponível em: https://wiki.openstack.org/wiki/Releases.


Acesso em: 12 Jan. 2016.

OPENSTACK White Paper. Exploring Opportunities: Containers and OpenStack,


2015. Disponível em: https://www.openstack.org/assets/pdf-downloads/Containers-
and-OpenStack.pdf. Acesso em: 27 Dez. 2015.

PAHL, C. IEEE Cloud Compute Magazine. Containerisation and the PaaS Cloud,
v. 2, Issue 3, p. 24-31, 2015. ISSN: 2325-6095

RED HAT Resource Management Guide. Chapter 1. Introduction to Control


Groups (Cgroups), 2015. Disponível em:
https://access.redhat.com/documentation/en-
US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/ch01.html#sec
-How_Control_Groups_Are_Organized. Acesso em: 9 Jan. 2015

SERRANO, N. et al. IEEE Software Technology. Infrastructure as a Service and


Cloud Technologies, v. 32, Issue 2, p 30-36.

THOMAS, A. Support Digital Busines and Nexus of Forces With Application


Architecture Innovations. Gartner Group, 2014. Pesquisa ID G00266394.
Disponível em http://www.gartner.com. Acesso em: 28/08/2015.

VMWARE White Paper. Understanding Full Virtualization, Paravirtualization, and


Hardware Assist, Oct. 2007. Disponível em:
https://www.vmware.com/files/pdf/VMware_paravirtualization.pdf. Acesso em: 03
Jan. 2016.

ZHANG, Q. et al. Cloud computing: state-of-the-art and research challenges. Jornal


of Internet Services and Applications, v. 1, Issue 1, p. 7-18, 2010. ISSN: 1869-
0238.

Você também pode gostar