Processo de Entrega de Soluções

{{>toc}}

h1. 3.3 - Conteinerização das aplicações

De maneira geral, containers podem ser comparados com pequenas VMs que permitem que códigos e aplicações rodem isoladamente de outros containers de forma muito rápida, compartilhando os mesmos recursos de hardware de forma segura e sem um hypervisor. Conteinerização das aplicações é um padrão de container, que pode ser usado em todas as distribuições Linux. Como um Linux Container Engine, utiliza Linux Containers (lxc) ao invés de métodos de virtualização tradicionais. O lxc utiliza o mesmo kernel do servidor host, tornando tudo muito rápido. Um container é um processo isolado através de namespaces + chroot. 

h2. 3.3.1 - Docker

Docker é um projeto de código aberto que automatiza a implantação de aplicativos dentro de recipientes de software, fornecendo uma camada adicional de abstração e automação de virtualização de sistema de nível operacional em Linux, Mac OS e Windows.

h3. 3.3.1.1 - Repositório de imagens docker privado

Para armazenar as imagens docker customizadas das aplicações, o Ministério do Planejamento possui um repositório de imagens docker privado que possui integração com o repositório de código-fonte Git permitindo visualizar de forma amigável no git as imagens docker criadas para cada aplicação.

h2. 3.3.2  Docker-compose

O Docker-compose é uma ferramenta de Orquestração de conteiners docker que permite de forma sucinta, explicar como os vários serviços devem conversar entre si, através do arquivo docker-compose é possível explicar as relações de dependências de um serviço com o outro, explicar arquivos que são importantes aos serviços, a relação dos serviços de rede, etc...

<pre>

services:

  mpog-banco-exemplo:

    build: postgresql

   # O comando 'ports' abaixo, explica que por exemplo, a porta tcp 5432 precisa/estará acessível externamente, neste caso, será possível acessar o banco de dados por esta porta

    ports:

      - "5432:5432"

   # O comando 'volumes' abaixo, demonstra que a pasta /var/lib/postgresql/data é importante e deve ser persistida pois possui como no exemplo abaixo, os dados do banco da aplicação

    volumes:

      - ./data:/var/lib/postgresql/data

  mpog-backend-exemplo:

    image: registry.planejamento.gov.br/mp/mpog-backend-exemplo

   # O comando 'links' abaixo, demonstra que o container de backend precisa ter acesso ao container de banco de dados

    links:

      - mpog-banco-exemplo

    volumes:

      - ./spring/config:/config

  mpog-frontend-exemplo:

    image: registry.planejamento.gov.br/mp/mpog-frontend-exemplo

    build: nginx

    links:

      - mpog-backend-exemplo

    ports:

      - "80:80"

</pre>

h3. Executando a orquestração

Para executar a orquestração basta digitar o seguinte comando na pasta `docker`:

    <pre>docker-compose up -d</pre>

Para parar os containeres basta executar:

    <pre>docker-compose stop</pre>

Para remover os containeres basta executar:

    <pre>docker-compose rm</pre>

Para visualizar logs dos containeres basta executar:

    <pre>docker-compose logs -f</pre>

h2. 3.3.3 - Regras gerais para conteinerização das aplicações

No contexto utilizado pelo Ministério do Planejamento para a geração das imagens docker das aplicações, algumas das premissas utilizadas são que:

# As receitas Dockerfile devem estar organizadas dentro da pasta "docker" do respectivo projeto no Git.

# O build destas imagens deve ser obrigatoriamente gerado por meio de rotina automatizada (Job) na ferramenta de integração contínua (Jenkins em nosso caso), gravando esta imagem em nosso repositório privado de imagens Docker.

# A premissa anterior garante que seja possível rastrear e fazer a engenharia reversa, conseguindo verificar como aquela imagem foi criada e quais scripts/comandos foram necessários para completar o processo de build da imagem;

# É importante disponibilizar um arquivo docker-compose.yml como o do exemplo acima dentro da pasta docker do projeto Git para que seja utilizado como referência para a criação de ambientes dessa aplicação

Abaixo citamos _%{color:red}algumas falhas%_ muito comuns que podem ocorrer ao implementar a Arquitetura e Configuração da aplicação:

* Parâmetros importantes como variáveis que definem credenciais de acesso a bases de dados, endereços de integração com serviços externos como Provedores de Autenticação, WebServices, ficarem fixos dentro do código fonte da aplicação sem a devida preparação para que sejam alterados de acordo com o ambiente;

* Mapear o código-fonte da aplicação em volumes, desta forma para implantar novas versões, além de atualizar a imagem docker seria necessário acessar a máquina hospedeira e copiar manualmente os novos arquivos de código do sistema;

* O endereços de dns aonde a aplicação deve rodar ficar fixo também sem a possibilidade de fácil alteração ao criar novo ambiente;

* A criação e subida do banco de dados da aplicação não estar automatizado por completo utilizando um versionador de base de dados, conforme [[2.4.3 - Scripts de Banco de Dados]], necessitando de intervenções manuais não documentadas;

A leitura do [[3.1 - Pipeline de Entrega]] é complementar ao assunto.