Capítulo

2 Cluster de Alta Disponibilidade com Docker Swarm

Luciano de Aguiar Monteiro e Washington Henrique Carvalho Almeida

Abstract High availability of services and applications are essential requirements in computing environments, however it is a problem already dealt with several solutions on the market, usually using clusters with commercial solutions. The approach addressed in the chapter uses the concept of Docker, in which the operating system that was previously virtualized starts working as if it were another application of the native Operating System, consuming less hardware resources. This concept will be used in Docker native tool called Docker Swarm to implement Cluster in a fast, scalable and monitorable way. It will also present a web tool called Rancher that enables the management of both Docker and Cluster.

Resumo Alta disponibilidade de serviços e aplicações são requisitos essenciais em ambientes computacionais, todavia é um problema, já trabalho com diversas soluções do mercado, comumente utilizando clusters com soluções comerciais. A abordagem tratada no capítulo utiliza o conceito de Docker, no qual o sistema operacional que antes era virtualizado, passa a trabalhar como se fosse outra aplicação do Sistema Operacional nativo, consumindo menos recursos de hardware. Dentro deste conceito será utilizado uma ferramenta nativa do Docker chamada Docker Swarm para implementar Cluster de maneira rápida, escalável e monitorável. Será apresentado ainda uma ferramenta web chamada Rancher que possibilita o gerenciamento tanto do Docker como do Cluster.

2.1. Introdução O aumento de velocidades das redes de computadores bem como do acesso a web proporcionou uma mudança de paradigma em relação as aplicações. Os sistemas passaram a utilizar deste recurso para sair de uma aplicação local passando a trabalhar de maneira compartilhada em rede, onde é disponibilizado um servidor de aplicação para que os clientes possam acessar via ambiente de rede.

III Escola Regional de Informática do Piauí. Livro Anais - Artigos e Minicursos, v. 1, n. 1, p. 279-295, jun, 2017.www.eripi.com.br/2017 - ISBN: 978-85-7669-395-6

Diante desta conjuntura serviços que antes eram disponibilizados através de uma estrutura física passaram a utilizar a rede da internet como: Redes de Varejos, Órgãos Federais, Órgãos Estaduais, prestadores de serviços, entre outros. Esta realidade criou a necessidade de alta disponibilidade que segundo Nóbrega (2013) caracteriza-se quando um serviço responde na quase totalidade do tempo de forma precisa e imediata às requisições dos usuários. Para se implantar um ambiente altamente disponível se faz necessário o uso de redundâncias e monitoramento, redundâncias tanto de servidores e switches como de links de acesso. A figura 2.1 apresenta um exemplo de ambiente de um serviço de alta disponibilidade para uma rede local.

Figura 2.1 - Cluster de Alta Disponibilidade em Redes Locais

Nestes ambientes é necessário o monitoramento constante do servidor de produção onde no caso de sua indisponibilidade um servidor secundário entraria em ação, onde nestas situações para prover alta disponibilidade entra em ação o HeartBeat Nascimento (2010). Partindo deste conceito a função do Heartbeat instalado no servidor secundário é monitorar o servidor de produção e no caso de sua indisponibilidade realizar automaticamente medidas necessárias para prover o serviço de maneira imperceptível para o usuário do sistema. Todavia a solução de alta disponibilidade que será abordada neste capítulo tem como característica principal a redução de custo para prover este ambiente, um sistema totalmente proativo no caso de falhas e escalável, onde serão usados o Sistema Operacional CoreOS, a plataforma Docker em conjunto com Docker Swarm e ainda a ferramenta de administração de container e cluster Rancher.

2.2. Sistema Operacional CoreOS O Sistema Operacional CoreOS é uma distribuição Linux que vem sendo utilizado em larga escala para ambientes de container, Mocevicius (2015), descreve que: “CoreOS é 40% mais eficiente no uso de RAM que as demais distribuições Linux, por conta de não ter um gerenciador pacote”, caso o usuário necessite de alguma aplicação a mesma deverá

ser instaladas em container dentro do CoreOS. Makam (2016) ainda caracteriza esta distribuição como:

“Sistema Operacional Linux otimizado para uso de Container com o objetivo de implantar aplicações distribuídas em Cluster. Além de oferecer um sistema operacional seguro, o CoreOS fornece serviços como o etcd e a fleet que simplificam a implantação de aplicativos distribuídos pelo Container”. Makan (2016)

Uma peculiaridade bem interessante no CoreOS é a forma de sua atualização, durante a instalação são criadas duas partições uma do sistema operacional e outra para atualização, conforme figura 2.2 ao ser disponibilizado uma nova versão esta é baixada na partição B que não está em uso e na inicialização seguinte carrega a partir da partição que foi atualizada

Figura 2.2 – Atualização CoreOS (Mocevicius, 2015)

O CoreOS é composto pelos seguintes componentes:

• Etcd – Serviço de descoberta. • Systemd – Utilitário usado para iniciar, parar ou reiniciar qualquer processo do

Sistema Operacional. • Fleet – Orquestração de container. • Rkt/Docker – Gerenciamento de container.

A figura 2.3 apresenta os componentes citados dentro da estrutura de um cluster com diversos nós.

Figura 2.3 – Arquitetura CoreOS (Smiles e Agrawal, 2016)

Por padrão, o CoreOS foi projetado para funcionar em cluster, mas também funciona muito bem como um único host. É muito fácil controlar e executar aplicações em container através da ferramenta de orquestração fleet e usar o serviço etcd para conectá-los Mocevicius (2015). O etcd é usado para anunciar os serviços que estão rodando em um nó para todos os demais nós de um cluster, ele também tem como função eleger o nó mestre de um cluster. Todos os nós de um cluster publicam seus serviços e informações de configurações no etcd, nó máster, o qual prover as informações coletadas para os outros nós. 2.2.1. Instalação do CoreOS. O CoreOS pode ser instalado através do VirtualBox para um ambiente de teste, para este procedimento deve ser realizado o download do sistema operacional no link a seguir: https://stable.release.core-os.net/amd64-usr/current/coreos_production_iso_image.iso Ao iniciar o sistema selecione o menu Try Out, o CoreOS será carregado com as configurações básicas e sem acesso externo, para que se possa ter acesso remoto, senhas configuradas e serviços disponíveis deve ser criado um arquivo chamado cloud-config.yaml com os parâmetros citados anteriormente. Segue abaixo um exemplo do arquivo cloud-config.yaml: #cloud-config hostname: coreos users: - name: core passwd: $1$oQKvMn3H$Kqzc.9tTxeSfTUa4/cLVe. groups: - sudo - docker ssh_authorized_keys: - ssh-rsa chave pública gerada ssh-keygen coreos: etcd2: discovery: https://discovery.etcd.io/e3e277dc716d70186870459122bcf1ca advertise-client-urls: http://$private_ipv4:2379,http://$private_ipv4:4001

initial-advertise-peer-urls: http://$private_ipv4:2380 listen-client-urls: http://0.0.0.0:2379,http://0.0.0.0:400 listen-peer-urls: http://$private_ipv4:2380 units: - name: etcd2.service command: start - name: static.network content: | [Match] name=enp0s3 [Network]

Address=$private_ipv4/24 Gateway=192.168.1.1

Para que possa ter acesso via ssh do CoreOS é necessário gerar um par de chaves com o seguinte comando: ssh-keygen -t rsa –b 2043 Copie a chave pública para o arquivo cloud-config.yaml na tag authorized_keys, e a chave privada para o host que será utilizado para acessar remotamente o CoreOS. Concluindo este procedimento o script de instalação deve ser executado, onde será configurado o sistema operacional conforme parâmetros atribuídos no arquivo cloud-config.yaml, com o seguinte comando: core-os-install -d /dev/sda -C stable -c cloud-config.yaml

O disco rígido será particionado e instalado o sistema operacional CoreOS em seguida.

2.3. Docker Segundo Romero (2016) Docker é uma ferramenta desenvolvida para criar e manter containers. Uma característica básica do Docker é isolar recursos utilizando bibliotecas do kernel tendo como backend o Linux Container. Smiles e Agrawal (2016) explica que Linux Container (LXC) é um ambiente de virtualização leve fornecido pelo kernel do Linux para fornecer virtualização ao nível do sistema sem executar um hypervisor.

O Linux Container combina três componentes para o isolamento de recurso do sistema operacional:

• Cgroups – É usado pelo sistema operacional para limitar recursos de hardware • Namespaces – Responsável por criar grupos de processo do Sistema Operacional

de maneira que um grupo de processo não seja visualizado por outro. • Chroot – Operação suportada pelo Sistema Operacional Linux para alterar o

diretório raiz de um processo em execução. A figura 2.4 mostra a arquitetura do Linux Container explicada.

Figura 2.4 – Linux Containers (Smiles e Agrawal, 2016)

A biblioteca C lbvirt fornece um conjunto de ferramentas usadas para interagir com os recursos de virtualização fornecidos pelo kernel do Linux. O conceito de Container lembra muito sistemas operacionais virtualizados, todavia a virtualização exige um hypervisor responsável por fornecer um ambiente de hardware ao sistema operacional convidado, bem como controlar o acesso deste, já o docker utiliza somente um kernel compartilhado com diversos containers, proporcionando uma economia de recursos de hardware, conforme podemos observar na figura 2.5.

Figura 2.5 – Container versus Máquina Virtual (www.docker.com)

2.3.1. Definições Imagens são um template de um Sistema Operacional criado a partir de um snapshot de um container docker. Uma imagem pode conter uma distribuição Linux sem configurações, ou aplicações já instaladas e configuradas. As imagens são geradas a partir de uma distribuição Linux sem configurações ou a partir de imagens baixadas no docker hub. Docker Hub é um repositório público de containers Docker onde os usuários podem fazer downloads e também uploads de seus containers, podendo compartilhar em repositório público ou criando um privado, conforme podemos observar na figura 2.6.

Figura 2.6 – Repositório Docker Hub (hub.docker.com)

As imagens disponibilizadas no Docker Hub possuem um único identificador, por padrão os nomes das imagens oficiais contem somente o primeiro nome e as disponibilizadas a partir de containers docker personalizadas pelos usuários contem nome_do_usuario/nome_da_imagem, como por exemplo bitnami/apache. Containers são sistemas operacionais criados a partir de uma imagem docker. O container possui todos os pré-requisitos necessários para executar uma aplicação como arquivos dos usuários, shell válido e metadatos. Para expor uma aplicação o administrador do sistema operacional deve mapear uma porta do sistema operacional hospedeiro para o container. 2.3.2. Instalação Docker Um aspecto importante durante a instalação é que existem duas versões do docker para instalação o Docker CE e o Docker EE, todos eles são multiplataformas podendo ser instalados em Windows, Linux e MacOS. O site oficial do desenvolvedor explica que o Docker Community Edition é ideal para desenvolvedores e pequenas equipes que procuram começar a usar o Docker e experimentar aplicativos baseados em contêiner já o Docker Enterprise Edition é projetado para desenvolvimento de sistemas em produção e grandes equipes de TI que constroem, enviam e executam aplicações críticas. A figura 2.7 apresenta os tipos de licença.

Figura 2.7 – Assinaturas Docker (www.docker.com) A versão utilizada neste capítulo é a Community Edition, os aspectos de instalação não serão abordados, no Sistema Operacional CoreOS o docker já vem instalado, caso

deseje instalar em outra distribuição as informações referentes a este processo são encontradas no site oficial http://www.docker.com. 2.3.3. Comandos Básicos A criação e administração de um container docker pode ser realizada através de sua CLI, ou através de algumas ferramentas gráficas por exemplo o Kitematic, ou ferramentas web como a Racher que será tratada mais a frente. Ao longo deste tópico abordaremos os comandos via CLI. 2.3.3.1 Docker Search Conforme mencionado anteriormente as imagens do container docker ficam hospedadas no docker hub e para realizar uma pesquisa no repositório utilizamos o comando docker search. A figura 2.8 exibe parte do resultado do comando docker search ubuntu, onde é feito uma consulta ao docker hub de todas as imagens que tenham o nome ubuntu. É importante destacar que este comando só consulta o repositório não baixa a imagem.

Figura 2.8 – Comando Docker Search 2.3.3.2 Docker Pull O comando docker pull tem como objetivo baixar uma imagem do repositório, este comando não cria o container somente baixa a imagem, conforme podemos observar na figura 2.9.

Figura 2.9 – Comando Docker Pull 2.3.3.3 Docker Run Para criar um container é usado o comando docker run em conjunto com alguns parâmetros, caso a imagem repassada não exista será realizado o download dela no docker hub e em seguida criado o container, a figura 2.10 apresenta um exemplo deste comando.

Figura 2.10 – Comando Docker Run Segue abaixo uma descrição sobre todos os parâmetros utilizados no comando docker run da figura 2.10:

• Parâmetro –i ou --interactive é utilizado para deixar a entrada de dados ao container aberta, caso você não esteja conectado no container.

• Parâmetro -t é utilizado para alocar um pseudo-tty para o container. Desta forma é possível interagir com o interpretador de comando passando comandos para o /bin/bash.

• Parâmetro -d é utilizado não ficar conectado no container no momento de sua criação, posteriormente caso haja necessidade o administrador do sistema deverá usar o comando docker attach nome_do_container.

• Parâmetro --name é especificado o nome da imagem, ao executar o comando docker ps será exibido o nome repassado neste parâmetro para identificar o container.

• Parâmetro --hostname especifica o nome do container no ambiente de rede. A sequencia de números exibidos após a criação do container é o seu número de identificação. 2.3.3.4 Docker Attach Ao ser criado um container utilizado o parâmetro docker run –dit, o container é criado inicializado, contudo o terminal continua no sistema operacional hospedeiro, caso o administrador do sistema necessite acessar o container deve ser executado o comando docker attach passando como parâmetro o nome do container que necessite acessar, conforme observado na figura 2.11.

Figura 2.11 – Comando Docker Run

Convém destacar que para sair do terminal do container sem finaliza-lo deve ser usada a combinação de teclas CTRL^P + CTRL^Q, caso utilize CTRL^D ou exit, será finalizado a execução do container. 2.3.3.5 Docker Start ou Docker Stop Os comandos docker start ou docker stop são utilizado para iniciar ou parar a execução do container, devendo passar por parâmetros o nome do mesmo. 2.3.3.6 Docker images Caso o administrador do sistema necessite consultar as imagens que já foram baixadas no computador hospedeiro é necessário executar o comando docker images, conforme observado na figura 2.12.

Figura 2.12 – Comando Docker images Podemos observar que na máquina local existem 3 (três) imagens já disponíveis para criar container, a ubuntu, debian e nginx. 2.3.3.7 Docker rm

Quando não existe mais necessidade de um container criado o administrador do sistema finaliza o mesmo com o docker stop, todavia os arquivos ainda ficam residindo no sistema, para apagar este container deve ser usado o comando docker rm nome_do_container, o mesmo só será aceito se o container já estiver desligado. 2.3.3.8 Docker rmi O docker rmi é utilizado quando o administrador do container deseja remover as imagens baixadas no repositório local, na figura 2.13 apresenta o comando de remoção da imagem nginx.

Figura 2.13 – Comando Docker rmi 2.3.3.9 Docker ps Ao longo da administração de sistemas com docker se faz necessário visualizar os containers que estão em execução no momento, com este objetivo pode-se utilizar o comando docker ps, a figura 2.14 apresenta um ambiente em que estão executando dois containers com o nome debian e ubuntu.

Figura 2.14 – Comando Docker Run 2.3.3.10 Docker exec Em algumas situações particulares é necessário que o administrador de sistema execute comandos em diversos containers a partir do host hospedeiro, nesta situação é apropriado o docker exec, a sintaxe do comando é: docker exec nome_container comando_desejado, a figura 2.15 apresenta o resultado da consulta ao conteúdo do arquivo resolv.conf no diretório /etc do container ubuntu

Figura 2.15 – Comando Docker exec

2.3.3.11 Docker cp Quando o administrador do sistema necessita realizar a cópia de arquivos entre a máquina hospedeira e o container, o comando docker cp é capaz de realizar este procedimento, usando docker cp origem destino, considerando na cópia que referencia o container o seguinte parâmetro: nome_container:/diretorio/arquivo Como exemplo temos o comando descrito abaixo: core@coreos ~ $ docker cp readme ubuntu:/root Especificamente no exemplo está sendo realizado uma cópia do arquivo readme localizado no diretório atual para o container chamado ubuntu no diretório /root. 2.3.3.12 Docker commit

Ao criar um container o administrador do sistema pode instalar aplicações neste, e caso haja necessita salvar a imagens para reutilizar este container já preparado, para isso pode realizar o commit com o comando docker commit imagem_alterada nova_imagem, a figura 2.16 apresenta um exemplo, onde é criado uma nova imagem debian-eripi a partir do container debian, logo em seguida é exibido a lista de imagens do repositório local já com a nova criada.

Figura 2.16 – Comando Docker commit 2.3.4. Mapeamento de Portas Um container docker quando é criado, na maioria das situações, tem como objetivo disponibilização de serviços, como por exemplo um servidor web nginx que trabalha na porta 80, contudo para que este serviço seja acessado externamente ao container deve existir um mapeamento de portas no qual se atribui uma porta do host hospedeiro para o container, na figura 2.17 é criado um container a partir de uma imagem nginx e feito o mapeamento da porta 9200 para a porta 80, portanto um usuário que queira acessar externamente o servidor web deverá digitar no navegador o endereço do host hospedeiro e a porta 9200 (http://endereço_ip:9200), o serviço também deve ser iniciado no container.

Figura 2.17 – Mapeamento de Portas

2.4. Docker Swarm Smith (2017) explica que Docker Swarm é uma ferramenta de orquestraç ão de container nativa do Docker. Proporciona de maneira fácil e organizada a criação de cluster e disponibilização de serviços neste ambiente, o Docker Swarm foi disponibilizado de maneira integrada com o Docker a partir da Versão 1.12. Segundo o site oficial da ferramenta o Docker Swarm tem como características principais:

• Gerenciamento de cluster integrado com Docker Engine: Através do Docker CLI pode-se criar e administrar cluster onde são disponibilizados serviços, não necessitando de software adicional para orquestração de container.

• Adaptação de estado desejado para o Cluster: O Docker Swarm monitora constantemente o Cluster, mantendo o estado conforme configurado inicialmente pelo administrador. Se for criado um serviço para executar 10 (dez) réplicas e uma delas parar, o Docker Swarm automaticamente cria uma nova.

• Segurança: Utiliza o protocolo TLS para comunicação segura entre os nós. 2.4.1. Arquitetura Docker Swarm

A arquitetura de um ambiente de Cluster utilizando Docker Swarm é composto por nós que são caracterizados por um host executando o Docker e serviços que é definido como uma tarefa ou conjunto de tarefas executando em um nó, esta tarefa pode ser exemplificada como um serviço web (Apache), servidor de aplicação (Tomcat) ou um banco de dados (MySql). Na figura 2.18 podemos observar um cluster com 3 (três) nós, um master e 2 (dois) nós réplicas do master executando em cada um 5 (cinco) containers.

Figura 2.18 – Arquitetura Docker Swarm (Smith, 2017) 2.4.2. Configuração do Docker Swarm A configuração de um cluster é iniciada a partir do host que será o nó master, onde o administrador do sistema executará o comando docker swarm init, conforme observado na figura 2.19.

Figura 2.19 – Iniciando Nó Master O resultado da inicialização do nó master apresenta um token com uma chave que deve ser anotada para adicionar um novo nó no cluster. 2.4.2.1. Adicionando um Nó Em qualquer momento uma outra máquina com o docker instalado pode fazer parte do cluster, esta seria um novo nó, bastando para isso executar o comando docker swarm join

passando por parâmetro o token gerado na inicialização do nó master, a figura 2.20 é apresentado o host coreos-no1 ingressando no cluster:

Figura 2.20 – Ingressando um Nó no Cluster

2.4.2.3. Promovendo e Despromovendo um Nó Em ambiente de cluster com Docker Swarm pode existir necessidade de mudança do nó master, onde conforme Smith (2017) nós secundários podem ser promovidos a master, este procedimento pode ser útil para substituir rapidamente o nó master com falha. O comando a seguir promove o nó denominado coreos-no1, o mesmo deve ser executo em um nó que seja o master: $ docker node promote coreos-no1 O nó administrador também pode ser despromovido, tornando-se um nó secundário, este procedimento deve ser feito antes de um nó master ser desativado. O comando a seguir despromove o nó denominado coreos-master, transformando em um nó slave, sem gerenciamento: $ docker node demote coreos-master 2.4.2.4. Administrando Serviços Conforme mencionado anteriormente serviços são tarefas executadas pelos containers de um cluster, podendo, por exemplo, ser a disponibilização de um serviço de e-mail (Postfix). Um cluster implementado com Docker Swarm apresenta uma série de vantagens conforme destacados abaixo:

• Os serviços podem ser dimensionados de forma rápida e fácil; • O Docker Swarm pode executar atualização dos serviços do cluster; • Cria facilmente redes para conectar contêiner em execução.

Disponibilizar serviço com Docker Swarm é um pouco diferente de criar container com Docker com um único serviço, o comando para criar serviços é docker service create, a seguir são apresentados alguns comandos de criação de serviços. $ docker service create --name web nginx O comando especificado a cima disponibiliza o servidor nginx com o nome web. $ docker service create --name web –p 80 –p 443 nginx O comando anterior teve uma variação de parâmetros, foi acrescido o –p que fará um mapeamento de portas do container para a rede externa. Um serviço pode ser inicializado com múltiplos containers usando a opção --replicas, o valor repassado será o número de containers desejados, conforme podemos ver a seguir, onde o administrador disponibiliza o servidor web nginx com 2 (duas) réplicas:

$ docker service create --replicas 2 --name web –p 8000:80 nginx Caso o administrador do sistema deseje aumentar o número de replicas no mesmo cluster ele deve utilizar a opção update, conforme apresentado a seguir: $ docker service update --replicas 3 web Para visualizar um resumo dos serviços e o número de réplicas que estão sendo executadas no cluster podemos usar o comando docker service ls, conforme observado na figura 2.21.

Figura 2.21 – Serviços em Execução

Caso seja necessário visualizar os detalhes de um serviço, incluindo todas as tarefas que estão em execução, é necessário usar o comando docker service ps, conforme podemos observar na figura 2.22 a consulta do serviço web criado.

Figura 2.22 – Serviços em Execução Detalhado

Quando não existe mais a necessidade de um serviço o mesmo pode ser removido com o comando docker service rm, de maneira que todas as tarefas associadas ao serviço são paradas e os conteiners removidos, o comando a seguir remove o serviço web: $ docker service rm web Caso seja necessário parar um serviço por um determinado período e continuar sua execução posteriormente, o mesmo não deve ser interrompido, visto que o container será excluído tornando a operação irreversível, uma solução para isso seria atualizar o serviço atribuindo o zero para o número de réplicas conforme comando a seguir: $ docker service update --replicas 0 web

2.5. Ferramenta Web Rancher Racher é uma ferramenta web open source desenvolvida pela Racher Labs para criar e administrar container, tem suporte tanto para Docker Swarm como para Kubernetes, esta última é a ferramenta de orquestração de container desenvolvida pela Google. O presente capítulo não abordará assuntos referentes a instalação podendo ser encontrados todas as informações desta implementação no endereço descrito abaixo: http://docs.rancher.com/rancher/v1.5/en/quick-start-guide/ Durante a instalação do Rancher é feito o mapeamento da porta 8080 do host para a porta 8080 do container, o acesso a ferramenta via browser é realizado através do endereço: http:// ip_do_rancher:8080. A tela inicial do sistema figura 2.23 apresenta uma notificação sobre coleta de informações de maneira anônima, onde o usuário pode recusar.

Figura 2.23 – Tela Inicial Rancher

Uma configuração importante que deve ser realizada no Racher é escolher do método de autenticação figura 2.24, a ferramenta possui algumas opções no qual a mais simples é a autenticação local onde o administrador pode cadastrar os usuários diretamente na interface web.

Figura 2.24 – Controle de Acesso

Todas as configurações realizadas através de linhas de comando no Docker CLI, podem facilmente ser realizada através da interface web do Rancher como a criação de container figura 2.25.

Figura 2.25 – Criando Container

Os containers criados ficam todos listados em um dashboard figura 2.26, onde o administrado do sistema pode ver seus estados, informações básicas e ainda realizar operações de administração dos containers.

Figura 2.26 – Lista de Containers

Uma funcionalidade importante que também pode ser realizada no Rancher é a criação de serviços onde o administrador informa somente o nome da imagem, quantidade de réplicas e o nome do serviço, no qual podemos observar na figura 2.27.

Figura 2.27 – Criando Serviços

3.6. Conclusões

No presente capítulo foi elencado um conjunto de conceitos e funcionalidades que proporcionam um ambiente altamente estável para serviços de redes, no qual um administrador de sistemas poderá disponibilizar serviços como servidores web, de aplicação e banco de dados através de um cluster com redundância e monitoramento proativo.

Para criar este ambiente foi apresentado uma solução de alta disponibilidade de serviços utilizando o Sistema Operacional CoreOS com suporte a cluster com Docker, e ainda uma ferramenta de orquestração de container, Docker Swarm, que possui como uma de suas principais vantagens o monitoramento da saúde do Cluster, viabilizando uma solução escalável, estável e segura. Agregando ainda mais valor a este ambiente, a ferramenta Racher proporciona um sistema via web para o gerenciamento, administração e monitoramento do ambiente.

Referências Nascimento, Fracisco Abud (2010) “Alta Disponibilidade em Virtualização de

Servidores”, SEGET. Nóbrega, Paulo B. M. (2013) “Proposta de um Ambiente de Alta Disponibilidade para

Sistemas Java Web Usando Computação em Nuvem”. IFCE. Smiles, Kingston; Agrawal, Shantanu (2016) “Learning CoreOS”, Birmingham, Packt

Publishing. Movicius, Rimantas (2015) “CoreOS Essentials”, Birmingham, Packt Publishing. Makam, Sreenivas (2016) “Mastering CoreOS”, Birmingham, Packt Publishing. Silva, Wellington F. (2016) “Aprendendo Docker”, São Paulo, Novatec. Romero, Daniel (2016) “Containers com Docker”, Casa do Código. Mckendrick, Russ (2016) “Extending Docker”, Birmingham, Packt Publishing. Smith, Randall, (2017) “Docker Orchestration”, Birmingham, Packt Publishing. Soppelsa, Fabrizio; Kaewkasi, Chanwit (2016) “Native Docker Clustering with

Swarm”, Birmingham, Packt Publishing.