SiGi

Documento criado por Fillipe Feitosa e Luciano Almeida

Introdução

Propósito

Esse documento descreverá como será feita a Gerência da Configuração e Mudança do projeto Sistema de Informações Gerenciais do Interlegis (SiGi). Atualmente no Interlegis existe um software de criação de tickets de suporte à informação, mas este não está sendo mantido e está ficando obsoleto, pois são pouco usados. O SiGi irá absorver a maioria dos sistemas legados do Interlegis, incluindo o SAUE, trabalhado também por esta equipe de projeto.

Escopo

O plano descrito neste documento será aplicado no SiGi e tem como objetivo elaborar uma proposta de implementação e utilização da integração contínua para a equipe técnica responsável. A necessidade de criação de um ambiente de desenvolvimento também se faz necessária para minimizar problemas de dependências, testes e pequenos bugs de ambiente.

Atualmente o projeto utiliza o git como controle de versão e está hospedado no site github.com.

Definições, Abreviações e Acrônimos

Termo	Significado
SiGi	Sistema de Informações Gerenciais do Interlegis
Build	Versão Estável de Software
Commit	Contribuição atômica num projeto de software

Links importantes

Link do projeto - https://github.com/interlegis/sigi

Gerenciamento de Configuração de Software

Objetivos

Com o intuito de facilitar a vida e o trabalho da equipe técnica responsável pelo SiGi, a equipe deste projeto estabeleceu três atividades principais como escopo para a disciplina de Gerência de Configuração de Software:

Integração Contínua - TravisCI

A primeira abordagem do grupo será implementar uma rotina de integração contínua para a criação de builds automatizadas. O objetivo principal desta atividade é reduzir o risco de disponibilizar uma versão de software com problemas de integração para o usuário final. Em termos técnicos, cada commit será verificado quando à consistência de suas dependências, bibliotecas e possivelmente testes.

Gerência de Configuração do Ambiente de Desenvolvimento - Vagrant/CoreOs/Docker

Para diminuir o impacto dos problemas de configuração nas máquinas para a equipe técnica, tanto de novos quanto de antigos membros, será criado um ambiente de gerência de configuração do ambiente de desenvolvimento e do sistema operacional, com o objetivo de consolidar as ferramentas de trabalho e estabelecer um processo de desenvolvimento mais estável.

Papeis e Responsabilidades

Responsáveis pelo Plano de Gerência e Configuração e sua aplicação:

• Fillipe Feitosa - Configuração do ambiente de desenvolvimento.
• Luciano Almeida - Configuração dos serviços de integração contínua.

Ferramentas e Ambiente

Ferramenta	Descrição
CoreOS	Sistema Operacional Baseado em Containers
Vagrant	Ferramenta para configurar ambiente de trabalho virtual
Travis CI	Ferramenta para integração contínua
pytest	Ferramenta criação de testes em linguagem python
Docker	Gerenciador de Containers

Configuração Travis CI

Para começar a configurar o Travis CI, o arquivo .travis.yml foi criado na raíz do aplicativo. Nele foram definidos inicialmente: Linguagem do software e sua versão; sudo obrigatório para instalação de dependências e demais operações que necessitam de super usuário; e o processo do banco de dados, juntamente com sua versão.

language: python 
sudo: required

python:
  - "2.7.6"

services:
  - postgresql

addons:
  postgresql: "9.3"

before_install:
  - sudo apt-get clean

A instalação das dependências vem em seguida. Neste ponto muitos detalhes tiveram que ser tomados. Para se instalar o Bower corretamente, deve-se instalar o NodeJS e o npm, além de criar um link simbólico da pasta /usr/bin/node dentro do diretório do projeto.

O SiGi utiliza também a dependência Geraldo, que é uma aplicação para Python e Django para gerar relatórios. No caso do SiGi, é preciso clonar o repositório, instalar usando o python e em seguida copiar alguns diretórios e arquivos. Após a cópia, o repositório do Geraldo pode se removido.

A seguir temos o código das instalações das dependências:

install:
  - sudo apt-get install npm nodejs
  - npm install npm -g
  - npm install -g bower
  - sudo ln -s /usr/bin/node
  - sudo apt-get install python-dev libldap2-dev libssl-dev libsasl2-dev libz-dev libxft-dev libjpeg62 libjpeg-dev libfreetype6-dev libxml2-dev libxslt1-dev git nginx python3-dev libpq-dev graphviz-dev graphviz pkg-config pgadmin3 python-psycopg2 software-properties-common build-essential libffi-dev python3-setuptools curl
  - pip install -r requirements/dev-requirements.txt
  - pip install --upgrade setuptools
  - git clone https://github.com/marinho/geraldo.git
  - cd geraldo/ 
  - python setup.py install
  - cp -Rfv reporting geraldo `python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"`
  - cd ..
  - rm -rf geraldo/

Para a execução dos testes no banco de dados, foi necessário utilizar o seguinte código:

before_script:
  - cp sigi/settings/dev.py sigi/settings/prod.py
  - psql -c 'CREATE DATABASE sigi;' -U postgres
  - psql -c 'CREATE DATABASE test_sigi;' -U postgres
  - psql -c "CREATE USER sigi WITH CREATEUSER CREATEDB PASSWORD 'sigi';" -U postgres
  - sed -i -e 's/getpass.getuser()/"postgres"/g' sigi/settings/test.py
  - echo 'OSTICKET_API_KEY = ""' >> sigi/settings/prod.py
  - echo 'OSTICKET_URL = ""' >> sigi/settings/prod.py
  - sudo mkdir /var/log/sigi
  - sudo chmod 777 /var/log/sigi
  - sudo touch /var/log/sigi/application.log
  - sudo chmod 777 /var/log/sigi/application.log
  - pip show eav-django | grep "Location" | cut -d ' ' -f 2
  - path_var=$(pip show eav-django | grep "Location" | cut -d ' ' -f 2)
  - cp scripts/eav_models.py $path_var/eav/models.py

Este código utiliza alguns comandos SQL do PostgreSQL pra criar os bancos de dados e o usuário 'sigi' que é o administrador. O comando da linha 36 está definindo as variáveis configuração do banco de dados que serão utilizadas, que no caso se encontram no arquivo test.py.

Para que o SiGi possa ser executado é necessário criar o arquivo prod.py, neste caso ele está sendo uma cópia do arquivo dev.py que possui o mínimo de configurações necessárias pra poder rodar o SiGi.

Para gerar os relatórios de log, faz-se necessário criar um arquivo chamado application.log no caminho /var/log/sigi e dar as devidas permissões.

Outro ponto importante também no código acima é a dependência chamada eav-django. A versão que foi usada no início do projeto do SiGi utilizava o import GenericForeignKey do módulo django.contrib.contenttype.generic. Porém, para fazer a integração com o Sistema de Atendimento, foi necessário atualizar o o Django para a versão 1.9, que mudou a localização desse import. Para solucionar esse problema, a alteração foi feita diretamente no código e este foi copiado para a localização onde está instalado.

Em seguida, os scripts de migração e de teste são executados.

script:
  - ./manage.py makemigrations
  - ./manage.py migrate
  - ./manage.py bower install
  - py.test --tb=short --create-db

Configuração Vagrant/CoreOS/Docker

Vagrant && CoreOS

Para instalar e configurar o Vagrant siga os passos a seguir.

• Garanta que você possui o dpkg e o virtualbox:

sudo apt-get install dpkg-dev virtualbox-dkms

• Faça o download da última versão do Vagrant no site oficial

sudo dpkg -i vagrant_<versão>.deb

• Para criar snapshots com o vagrant:
  • vagrant plugin install vagrant-vbox-snapshot

• Clone o projeto
  • git clone https://github.com/LucianoAlmeida/sigi.git
• Entre na pasta do projeto
• Faça o clone do CoreOs em [pasta_do_projeto]/vm/coreos/vagrant/
  • git clone https://github.com/coreos/coreos-vagrant.git vm/coreos/vagrant ./vm/coreos/vagrant/
• Obs.: Foi necessário instalar o nfs-kernel-server no host para compartilhar pastas

• sudo apt-get update
  sudo apt-get install nfs-kernel-server
  

• (opcional) Instalar o docker-composer:
  • curl -L https://git.io/vrBuA | sudo sh
• Entre na pasta do Vagrant renomeio o arquivo user-data.sample para user-data, com o conteúdo:

• #cloud-config
  
  ---
  coreos:
    etcd2:
      discovery: https://discovery.etcd.io/225dda7b31570dfc6f8da70ea78db53c
      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:4001
      listen-peer-urls: http://$private_ipv4:2380
    fleet:
      public-ip: "$public_ipv4"
    units:
    - name: etcd2.service
      command: start
    - name: fleet.service
      command: start
  

• Faça a mesma coisa para o arquivo config.rb.sample, salvando-o como config.rb:

• # Size of the CoreOS cluster created by Vagrant
  $num_instances=1
  
  # Used to fetch a new discovery token for a cluster of size $num_instances
  $new_discovery_url="https://discovery.etcd.io/new?size=#{$num_instances}"
  
  # Automatically replace the discovery token on 'vagrant up'
  
  if File.exists?('user-data') && ARGV[0].eql?('up')
    require 'open-uri'
    require 'yaml'
  
    token = open($new_discovery_url).read
  
    data = YAML.load(IO.readlines('user-data')[1..-1].join)
  
    if data.key? 'coreos' and data['coreos'].key? 'etcd'
      data['coreos']['etcd']['discovery'] = token
    end
  
    if data.key? 'coreos' and data['coreos'].key? 'etcd2'
      data['coreos']['etcd2']['discovery'] = token
    end
  
    # Fix for YAML.load() converting reboot-strategy from 'off' to `false`
    if data.key? 'coreos' and data['coreos'].key? 'update' and data['coreos']['update'].key? 'reboot-strategy'
      if data['coreos']['update']['reboot-strategy'] == false
        data['coreos']['update']['reboot-strategy'] = 'off'
      end
    end
  
    yaml = YAML.dump(data)
    File.open('user-data', 'w') { |file| file.write("#cloud-config\n\n#{yaml}") }
  end
  
  #
  # coreos-vagrant is configured through a series of configuration
  # options (global ruby variables) which are detailed below. To modify
  # these options, first copy this file to "config.rb". Then simply
  # uncomment the necessary lines, leaving the $, and replace everything
  # after the equals sign..
  
  # Change basename of the VM
  # The default value is "core", which results in VMs named starting with
  # "core-01" through to "core-${num_instances}".
  #$instance_name_prefix="core"
  
  # Change the version of CoreOS to be installed
  # To deploy a specific version, simply set $image_version accordingly.
  # For example, to deploy version 709.0.0, set $image_version="709.0.0".
  # The default value is "current", which points to the current version
  # of the selected channel
  #$image_version = "current"
  
  # Official CoreOS channel from which updates should be downloaded
  $update_channel='stable'
  
  # Log the serial consoles of CoreOS VMs to log/
  # Enable by setting value to true, disable with false
  # WARNING: Serial logging is known to result in extremely high CPU usage with
  # VirtualBox, so should only be used in debugging situations
  #$enable_serial_logging=false
  
  # Enable port forwarding of Docker TCP socket
  # Set to the TCP port you want exposed on the *host* machine, default is 2375
  # If 2375 is used, Vagrant will auto-increment (e.g. in the case of $num_instances > 1)
  # You can then use the docker tool locally by setting the following env var:
  #   export DOCKER_HOST='tcp://127.0.0.1:2375'
  #$expose_docker_tcp=2375
  
  # Enable NFS sharing of your home directory ($HOME) to CoreOS
  # It will be mounted at the same path in the VM as on the host.
  # Example: /Users/foobar -> /Users/foobar
  #$share_home=false
  
  # Customize VMs
  $vm_gui = false
  $vm_memory = 1024
  $vm_cpus = 1
  #$vb_cpuexecutioncap = 100
  
  # Share additional folders to the CoreOS VMs
  # For example,
  # $shared_folders = {'/path/on/host' => '/path/on/guest', '/home/foo/app' => '/app'}
  # or, to map host folders to guest folders of the same name,
  # $shared_folders = Hash[*['/home/foo/app1', '/home/foo/app2'].map{|d| [d, d]}.flatten]
  #$shared_folders = {}
  
  # Enable port forwarding from guest(s) to host machine, syntax is: { 80 => 8080 }, auto correction is enabled by default.
  #$forwarded_ports = {}
  

• Rode o comando vagrant up na pasta do clone CoreOs e vá tomar um café :D

vagrant up

Docker

• Crie as seguintes pastas na pasta puppet do HOST
  • files
  • manifests
  • modules

Cronograma

Data	Atividade
29/06	Início da Elaboração do Projeto - Plano de GCS
30/06	Definição da Abordagem, tencologias
09/06	Configuração das ferramentas
11/06	Finalização do Travis - CI - Vagrant/CoreOS/Docker
15/07	Finalização do Postgres no Docker
16/07	Atualização final da Wiki