SiGi

Fonte: Wikiversidade
Saltar para a navegação Saltar para a pesquisa

Documento criado por Fillipe Feitosa e Luciano Almeida

Introdução[editar | editar código-fonte]

Propósito[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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

Gerenciamento de Configuração de Software[editar | editar código-fonte]

Objetivos[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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[editar | editar código-fonte]

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.

 1 language: python 
 2 sudo: required
 3 
 4 python:
 5   - "2.7.6"
 6 
 7 services:
 8   - postgresql
 9 
10 addons:
11   postgresql: "9.3"
12 
13 before_install:
14   - 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:

16 install:
17   - sudo apt-get install npm nodejs
18   - npm install npm -g
19   - npm install -g bower
20   - sudo ln -s /usr/bin/node
21   - 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
22   - pip install -r requirements/dev-requirements.txt
23   - pip install --upgrade setuptools
24   - git clone https://github.com/marinho/geraldo.git
25   - cd geraldo/ 
26   - python setup.py install
27   - cp -Rfv reporting geraldo `python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"`
28   - cd ..
29   - rm -rf geraldo/

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

31 before_script:
32   - cp sigi/settings/dev.py sigi/settings/prod.py
33   - psql -c 'CREATE DATABASE sigi;' -U postgres
34   - psql -c 'CREATE DATABASE test_sigi;' -U postgres
35   - psql -c "CREATE USER sigi WITH CREATEUSER CREATEDB PASSWORD 'sigi';" -U postgres
36   - sed -i -e 's/getpass.getuser()/"postgres"/g' sigi/settings/test.py
37   - echo 'OSTICKET_API_KEY = ""' >> sigi/settings/prod.py
38   - echo 'OSTICKET_URL = ""' >> sigi/settings/prod.py
39   - sudo mkdir /var/log/sigi
40   - sudo chmod 777 /var/log/sigi
41   - sudo touch /var/log/sigi/application.log
42   - sudo chmod 777 /var/log/sigi/application.log
43   - pip show eav-django | grep "Location" | cut -d ' ' -f 2
44   - path_var=$(pip show eav-django | grep "Location" | cut -d ' ' -f 2)
45   - 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.

47 script:
48   - ./manage.py makemigrations
49   - ./manage.py migrate
50   - ./manage.py bower install
51   - py.test --tb=short --create-db

Configuração Vagrant/CoreOS/Docker[editar | editar código-fonte]

Vagrant && CoreOS[editar | editar código-fonte]

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
  • 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[editar | editar código-fonte]

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

Cronograma[editar | editar código-fonte]

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