Continuous Delivery (CD)

Continuous Delivery é uma metodologia de desenvolvimento e entrega de software onde se mantém o produto, durante todo processo de desenvolvimento, num estado permanente de lançamento para produção. Por outras palavras, isto significa que quando os programadores realizam alterações ao código este vai ser integrado no servidor de integração e depois de passar os testes de integração o código é submetido a uma pipeline com testes mais avançados. Esta pipeline recria um ambiente de estágio muito parecido com o ambiente de produção, fornecendo em todas as fases feedback às equipas de desenvolvimento, de maneira a realizarem correções e otimizações. Como os testes realizados, logo após a integração, têm um ambiente muito idêntico ao de produção, faz com que o software se encontre sempre pronto para lançamento [48].

Como se pode ver pela Figura2.6, um dos componentes chaves deste método é a existência de uma plataforma que permita criar pipelines de testes. O tipo e o número de etapas que compõe a pipeline pode diferir consoante o software que as equipas estão a desenvolver. Na Figura 2.7 é possível ver um exemplo genérico de uma pipeline de Continuous Delivery em que inclui os

18 Capítulo 2. Fundamentos

Figura 2.6: Ciclo do método Continuous Delivery (Figura extraída de [43])

vários testes que vão atestar se as alterações ao software estão aptas a entrar em produção.

Figura 2.7: Exemplo de uma pipeline de Continuous Delivery (Figura extraída de [48]) SegundoChen [48] as pipelines deCD são normalmente compostas pelos seguintes estágios:

Code Commit

Normalmente este é o estágio inicial da pipeline e é iniciado automaticamente quando o programador envia o código para o repositório central. Neste estágio o código submetido vai ser compilado e são realizados testes unitários. Caso seja detetado algum erro, o programador é informado de maneira a que possa corrigir o erro e enviar novamente o código corrigido para a pipeline. Se não existir nenhum erro, o código passa automaticamente para o próximo estágio, que é o Build.

Build

Nesta fase o código é integrado e são realizados os testes de integração, de maneira a verificar se existe ou não alguma incompatibilidade. Caso exista algum problema o software não avança na pipeline para que os programadores possam corrigir o erro. Também é nesta fase que as diferentes partes do código e as suas dependências são integradas e transformadas num género

de artefacto ou objeto (por exemplo RPM ou imagem de um contentor), ao qual as próximas

etapas, da pipeline, vão empregar esse objeto criado. Tal como no estágio anterior se não for detetado nenhum problema o software avança para a próxima fase da pipeline.

2.5. Práticas de Desenvolvimento de Software 19

Acceptance Test

Esta é uma parte crucial que determina o sucesso do método CD, pois vai assegurar que o software produzido contém todas as especificações e requisitos exigidos pelos clientes. Normalmente, estes testes tem um conceito de caixa negra pois são fornecidos um conjunto de inputs ao sistema (de acordo com cenários reais) e consoante esses inputs são devolvidos outputs. Estes outputs são analisados de maneira a verificar se estão de acordo com aquilo que era esperado. Caso todos os testes sejam positivos passamos automaticamente à próxima fase da pipeline.

Performance Test

Nesta fase da pipeline vamos testar como ficou a performance do software, depois do programador ter realizado as alterações ou melhorias ao código. Ou seja, os programadores após um commit ficam a saber instantaneamente as alterações que provocaram no software, ao nível da performance. Com isto, mais facilmente poderão realizar alterações de maneira a corrigir a performance global do produto.

Manual Test

Esta é a fase antes do software ser lançado para produção. É nesta fase que são realizados todos os testes manuais ao produto.

Production

Esta é a ultima fase da pipeline de CDe é nesta fase que o software passa de um possível produto a produto, ou seja, é nesta fase que se encontra o utilizador final (cliente).

2.5.5 Continuous Deployment

Esta prática de produção de software é muito semelhante à prática de Continuous Delivery. A diferença aqui está no nível de automatização, pois todo o software produzido pelas equipas de desenvolvimento entra automaticamente para produção depois de totalmente testado na pipeline. Ou seja, o último passo da pipeline do Continuous Delivery é realizado automaticamente e não

manualmente, como se pode ver na Figura 2.8.

Para que este método tenha sucesso a pipeline de realização de testes automáticos tem de ser bastante eficaz. Pois caso contrário, poderia chegar ao ambiente de produção software com erros e falhas, colocando em risco tanto a qualidade do produto, assim como o interesse do cliente por esse produto. Devido a isto, os testes automáticos devem cobrir toda as fases desde os testes unitários, testes de componentes e testes de aceitação [49].

20 Capítulo 2. Fundamentos

Capítulo 3

Estado da Arte

Este capítulo fornece uma visão das tecnologias e produtos de software, que são atualmente o estado da arte para implementar os objetivos que esta dissertação se propõe a concretizar. Para isso será divido em três secções, ao qual, cada uma destas secções vai reunir as tecnologias e ferramentas que são capazes de atingir cada uma das soluções a implementar, referidas anteriormente na secção 1.2.

Inicialmente vamos abordar o software utilizado para a criação de clouds privadas com o foco nos seus mecanismos de elasticidade para reunirmos conhecimento sobre este sistema de maneira a introduzir a elasticidade nos nós do cluster Kubernetes. Como a elasticidade que

será introduzida nos nós do cluster será manipulada por umaCLI, serão abordadas as CLIde

duas das clouds públicas mais populares e a CLI pcloud. Depois vamos abordar a plataforma de conteinerização Docker e por fim vamos abordar as plataformas que são capazes de realizar a gestão e deployment de contentores.

3.1

OpenStack

Os sistemas de controlo e operação em cloud são responsáveis por um grande número de tarefas o que faz com que estes sistemas sejam bastante complexos. As suas funções vão desde o fornecimento dos serviços da cloud ao controlo e coordenação do sistema. Estes sistemas normalmente tem uma estrutura modular, em que, a cada um dos módulos correspondem os sistemas de computação, de rede, de armazenamento, de gestão de imagens, de identidades e de segurança. Depois de instalados, estes sistemas fornecem a camada de IaaS e os utilizadores interagem com eles através de uma interface que pode ser gráfica (GUI), por uma linha de comandos (CLI), ou por umaAPI. Existem várias versões deste tipo de sistema, tanto comerciais como open-source, cada uma delas tem os seus objetivos e desafios. A utilização de cada uma destas opções, depende do ambiente, ou as necessidades das organizações intervenientes.

Como já foi referido anteriormente na secção1.2, esta dissertação está a ser elaborada na Altice Labs, na qual, já tinha uma plataforma deIaaS privada implementada através do software

22 Capítulo 3. Estado da Arte open-source OpenStack. Esta cloud privada será a infraestrutura subjacente ao cluster Kubernetes que para além disso vai permitir fornecer elasticidade horizontal aos nós desse cluster. Para isso será necessário perceber os sistemas internos que compõe o OpenStack para que se consiga interagir com estes para criar essa elasticidade.

De seguida vamos abordar a arquitetura do sistema OpenStack e a forma como os serviços são disponibilizados aos seus utilizadores.

3.1.1 Introdução

O OpenStack [14] é um sistema operativo para cloud, de código aberto, que permite gerir

e controlar vários recursos computacionais disponíveis num data center, mais propriamente computação, armazenamento e rede de forma virtual, criando um serviço de infraestrutura (IaaS) privada.

O projeto OpenStack começou em 2010 através do trabalho e colaboração entre a Rackspace Hosting e a NASA. Estas duas organizações decidiram juntar dois projetos desenvolvidos de forma independente. A Rackspace forneceu o CloudFiles que é uma plataforma de armazenamento para a cloud. Enquanto que a NASA disponibilizou o Nova, criado no projeto Nebula, em que as suas funções eram ao nível da computação na cloud. Desta forma nasce um projeto de código aberto apoiado e desenvolvido pela OpenStack Foundation que incentiva e organiza a participação de qualquer pessoa no projeto. Para além dos voluntários, ao redor do mundo, que desenvolvem e

aprimoram o OpenStack, este também conta com o apoio de mais de 200 companhias [50], no

qual estão presentes os gigantes desta indústria, como por exemplo IBM, Intel, Red Hat, SUSE, Canonical, Cisco, entre muitos outros. [51]

Todo o software do OpenStack está sob a licença Apache 2.0 e encontra-se neste momento num ciclo de lançamento de 6 meses, ao qual, a última versão é denominada de Ocata e foi lançada em Fevereiro de 2017.

3.1.2 Arquitetura

O OpenStack fornece uma solução de Infrastructure as a Service (IaaS) através de um design modular. Cada um destes módulos é chamados de Serviço ou Projeto OpenStack e apenas está presente consoante os serviços e funcionalidades que cada cloud fornece aos seus utilizadores. Cada um destes serviços tem o objetivo de gerir e manipular diferentes recursos da estrutura física da cloud, que são abstraídos e virtualizados para serem fornecidos ao utilizador. A organização e disposição destes componentes está relacionada com quatro conceitos fundamentais do projeto OpenStack, que são:

• Computação: Serviço Nova;

• Armazenamento: Serviço Swift e Serviço Cinder; • Rede: Serviço Neutron;

3.1. OpenStack 23 • Acesso:

– Identidades: Serviço Keystone; – Imagens: Serviço Glance;

Estes serviços são compostos por diferentes processos daemons, ao qual, estes comunicam entre si através de uma fila central e de um protocolo avançado de enfileiramento de mensagens (BrokerAMQP). A cada serviço está associado uma base de dados que tem a função de guardar os diferentes estados de alguns dos componentes da cloud, como por exemplo o estado das máquinas virtuais a correr no sistema. Para além disto, a cada um destes serviços inter-relacionados está associada umaAPI, ou noutros casos um proxy que serve de interface de comunicação entre os diferentes projetos do OpenStack. A fila central de mensagens, a base de dados e a API formam uma arquitetura genérica presente em todos os serviços do OpenStack, como pode ser visto pela Figura 3.1. Os utilizadores interagem com o OpenStack de várias formas, tais como, interface

gráfica (Dashbord Horizon), linha de comandos (CLI) e também através daAPI.

Para além dos serviços essenciais supracitados, também referidos como serviços core do OpenStack, é de salientar que existem outros que são conhecidos como serviços opcionais. Tendo identificado os principais serviços/projetos que compõem a arquitetura lógica do OpenStack, de seguida vamos abordar com mais detalhe cada um destes serviços que compõe o OpenStack e fazer algumas referências aos serviços opcionais que podem ser instalados também.

24 Capítulo 3. Estado da Arte Figura 3.1: Arquitetura mais com um do Op enStac k (Figura sob a licença Apac he 2. 0 extraída de [ 14 ])

3.1. OpenStack 25

3.1.3 Serviços Essenciais

De seguida vamos abordas os serviços essenciais e aqueles que são considerados mais importantes no OpenStack.

3.1.3.1 Nova (Compute)

O projeto Nova já está presente desde os inícios do projeto OpenStack e é o componente responsável pela gestão das instâncias (máquinas virtuais). Este é um sistema distribuído por múltiplos servidores, ao qual, é responsável por criar uma camada de abstração dos recursos de computação desses servidores. Este componente comunica diretamente com o hypervisor fazendo com que seja possível gerir o ciclo de vida de uma instância num qualquer número de nós físicos do data center. Desta forma, as principais funcionalidades deste componente passam por iniciar, redimensionar, suspender, parar e reiniciar máquinas virtuais.

As instâncias geridas pelo Nova tem os seus recursos distribuídos e catalogados em Flavors [52]. Um Flavor define a capacidade de CPU, memória e armazenamento alocado a uma máquina virtual.

3.1.3.2 Neutron (Networking)

O projeto Neutron disponibiliza um serviço de Networking-as-a-Service através da abordagem de Software-Defined Networking (SDN), ao qual, permite criar e gerir redes, subnets e portas pelos utilizadores do OpenStack.

Tal e qual como Nova, este segue uma abordagem modular, de tal forma, que pode ser colocado num servidor dedicado a este serviço e os seus agentes e extensões distribuídos pelos diferentes componentes de rede que compõem a infraestrutura da cloud. Desta forma, permite acomodar diferentes equipamentos e softwares de rede trazendo mais flexibilidade à cloud. O

serviço de rede no OpenStack fornece uma API que permite gerir e configurar uma grande

variedade de serviços/dispositivos de rede, tais como, switches, routers, firewalls, NAT, VPN, balanceamento de carga, entre outros.

3.1.3.3 Glance (Image)

Este é o serviço responsável por fornecer aos utilizadores as imagens externas dos sistemas operativos a correr nas máquinas virtuais. A maneira como o Glance disponibiliza as imagens é semelhante à de um sistema operativo contido num live CD.

As imagens fornecidas aos utilizadores são compostas por um sistema de ficheiros e um sistema operativo em que todos os meta-dados, específicos ao host, são removidos. Os elementos removidos podem ser, chaves SSH, endereços MAC, endereços IP estáticos, entre outros. Estas

26 Capítulo 3. Estado da Arte especificidades são eliminadas, porque caso contrário quando vários utilizadores colocassem estas imagens a correr iriam existir conflitos, por exemplo devidos às duplicações de endereços.

3.1.3.4 Swift (Object Storage)

Swift é o componente do OpenStack responsável por gerir o armazenamento de objetos. Estes objetos são considerados dados estáticos que são armazenados a longo prazo e podem ser atualizados ou recuperados a qualquer momento.

Este sistema de armazenamento de objetos utiliza uma arquitetura distribuída sem um ponto central de controlo, fornecendo desta forma, grande escalabilidade, redundância e permanência dos objetos armazenados. Os objetos são escritos e replicados pelo próprio serviço Swift por múltiplos nós de armazenamento, que compõe o cluster.

3.1.3.5 Cinder (Block Storage)

Cinder é outra forma de armazenamento do OpenStack, este é responsável por gerir e fornecer o acesso a dispositivos de armazenamento físico, em blocos, às instâncias.

Como as imagens disponíveis pelo serviço Glance não têm nenhuma forma de armazenamento persistente, no momento em que uma instância fosse desligada perder-se-ia toda a informação criada até esse momento. É este o problema que o Cinder vem resolver. Pois este componente é responsável por criar volumes lógicos que depois de anexados a uma instância fornece armazenamento persistente a essa instância.

Para além de fornecer armazenamento às instâncias, este também tem outras funcionalidades tais como [53]:

• Gestão de Snapshots: permite criar/eliminar snapshots de volumes. • Permite clonar volumes.

• Permite a criação de volumes tendo por base um snapshot de um outro volume. • Permite copiar imagens para volumes, ou vice-versa.

De maneira a melhorar a performance e a velocidade com que cada instância realiza operações de escrita/leitura, a maioria do hardware de armazenamento permite que as instâncias comuniquem diretamente com estes.

Os recursos básicos fornecidos pelo Cinder são:

• Volumes: armazenamento em blocos alocado de maneira a fornecer armazenamento secundário ou primário às instâncias para que possam ser iniciadas (boot).

• Snapshots: é uma cópia de um volume, num determinado momento de atividade desse volume. Mais tarde o snapshot pode ser convertido novamente num volume, tal e qual como quando foi criado o snapshot.

3.1. OpenStack 27 • Backups: são cópias de volumes que são armazenados como objetos no Swift.

3.1.3.6 Keystone (Identity)

Este é o serviço responsável pela gestão de identidades do OpenStack. Como todos os serviços do OpenStack exigem mecanismos de autenticação e de identidade, o Keystone é considerado o serviço que une todos os outros serviços. Este serviço agrega as funções de autenticação, listagem do catálogo de serviços disponíveis, políticas, regras e credenciais que permitem controlar os acessos dos diferentes utilizadores associados a cada projeto. Os pedidos realizados aos diferentes serviços do OpenStack através dasAPIs são processados pelo Keystone de forma assegurar que o utilizador certo pode utilizar o serviço requisitado.

O Keystone suporta vários plugins, backends e protocolos para auxiliar o processo de

autenticação e identificação de identidades como o LDAPe o PAM. Para além destes, utiliza

o mecanismo tradicional de utilizador/password de maneira a requisitar uma token e para os restantes pedidos utiliza uma Public Key Infrastructure (PKI), sendo este o método default de autenticação do OpenStack [53].