Infraestrutura LIT

Especificações Técnicas da Infraestrutura do LIT para desenvolvimento

• Versão 1.3
• Última revisão 17/05/2016
• Editor Matheus Silva Santos
• PDF Arquivo:Especificações Técnicas da Infraestrutura do LIT para desenvolvimento (1.2).pdf

Resumo

Após consideração das opções disponíveis no mercado, estáveis e com bom suporte, ficaram definidas as ferramentas listadas abaixo como partes da infraestrutura padrão disponível para desenvolvimento no LIT.

• IDE: Editor de texto de preferência do desenvolvedor
• Interpretador: CPython 3.4
• Framework web: Django 1.9 e Flask 0.10
• SGBD: PostgreSQL 9.4
• Versionamento: Git, hospedado no Bitbucket
• Servidor HTTP: “Apache” 2.4 + Gunicorn 19.4
• SO: CentOS 7 virtualizado, rodando containers Docker
• Integração contínua: Jenkins 1.651, se for necessário

Justificativas

A metodologia utilizada para a escolha das ferramentas leva em conta (na ordem): relevância, licença, performance, preferência do desenvolvedor (se aplicável). A versão de cada uma leva em conta a estabilidade e suporte.

IDE

Não há muitas opções viáveis de IDE para a linguagem Python, em comparação com Java, por exemplo. E as que existem, ou são ferramentas pagas: PyCharm, Komodo IDE, Wing IDE; ou são instáveis e experimentais: Netbeans com plugin nbPython, Eclipse com plugin PyDev. Algumas das ferramentas pagas (notavelmente o PyCharm) são gratuitas caso o projeto desenvolvido seja de código aberto ou puramente educacional; isto é, nenhum projeto desenvolvido nela poderia ter fins lucrativos. A maioria dos desenvolvedores Python prefere utilizar um simples editor de texto, mas poderoso o suficiente para algumas tarefas automatizadas. Emacs, vi, nano, gedit, Atom, Notepad++, são gratuitos para qualquer fim e suficientes para desenvolvimento.

Interpretador

Python é uma linguagem originalmente interpretada. Com o aumento de sua popularidade, foram criados interpretadores e compiladores alternativos para a linguagem, focando em uma ou outra característica a ser melhorada. Como o interpretador oficial (CPython) é muito estável, presente na maioria das plataformas e suficientemente otimizado, ele será utilizado. A versão 2 será descontinuada em breve, logo a adoção do Python 3 é obrigatória. Fora escolhida a minor version 3.4 por ser a mais popular entre as distribuições.

Framework web

Curiosamente se fez necessário a opção por duas ferramentas invés de uma. Dentre tantos e excelentes frameworks web para Python, o Django e o Flask se destacam por suas vantagens. O Django possui tudo que é necessário para construir uma aplicação web robusta, com uma API fácil de persistência de dados. Por esses motivos também, ele pode ser um exagero ao se considerar tarefas simples, onde pode ser substituído pelo Flask. O Django está em versão estável 1.9 e o Flask na 0.10 com boa maturidade.

SGBD

A escolha do Postgres foi simples. A maioria da comunidade Python o prefere (da mesma forma que a comunidade PHP prefere o MySQL), logo, é fácil encontrar suporte para a utilização de frameworks Python com o Postgres. Pesa também na decisão o desempenho do Postgres vs. MySQL. A versão utilizada será a 9.4, que trouxe melhorias significativas de desempenho e é a mais popular entre as distribuições Linux.

Versionamento

Tendo duas opções claras para ferramentas de versionamento, Git e Subversion, a decisão de utilizar o Git foi instantânea. O Git está em ascensão e é, não só mais popular que o SVN, como o de melhor benefício atualmente. A questão real foi decidir a hospedagem do serviço do Git, entre Bitbucket, GitHub e hospedar nos próprios servidores do LIT. Apesar de ser viável e indiscutivelmente a mais barata das soluções, hospedar no LIT exigiria uma estrutura de backup e segurança que está fora de cogitação. O GitHub oferece gratuitamente apenas repositórios públicos, ou seja, apenas para projetos de código aberto. Por sua vez, o Bitbucket oferece ilimitados repositórios privados gratuitamente, contanto que sua equipe não passe de 5 pessoas.

Servidor HTTP

Para prover o serviço é necessário obviamente de um servidor web. Com as opções de uso do Apache HTTP e do Nginx, a escolha do Apache se deu pela popularidade e termos de licença, que são totalmente livres. A versão escolhida é a 2.4, pela sua maturidade. Contudo, um servidor web como o Apache não consegue se comunicar com as aplicações Python se estas estiverem em outros servidores ou dentro de máquinas virtuais diferentes. É preciso de um servidor HTTP intermediário interligado às aplicações, como o Gunicorn. Assim o Apache pode atuar como proxy reverso, redirecionando o tráfego para as aplicações. A última versão do Gunicorn até o momento é a 19.4.

Sistema Operacional

Tendo como opções cogitadas o Debian, Ubuntu Server, Fedora Server e CentOS, o CentOS foi escolhido por nenhuma razão especial que não seja a compatibilidade com o que já é adotado pela Algar Telecom. Todas as opções são baseadas no kernel Linux, têm as ferramentas necessárias, performam bem, tem versões muito estáveis e pelo histórico, as atualizações de segurança são rápidas. Obviamente foi escolhida a versão CentOS 7, a última estável com previsão de suporte longo. O SO rodará em virtualizado com auxílio do Proxmox.

Integração contínua

Não há outra opção com o mesmo nível de independência, estabilidade e suporte para CI com Python, se não o Jenkins. Há o Travis CI que funciona como SaaS, mas os planos são caros e impossibilitam seu uso no LIT. A versão do Jenkins a ser utilizada, se realmente for necessário, será a 1.651.

Referências

• https://blog.jetbrains.com/pycharm/2013/09/jetbrains-delights-the-python-community-with-a-free-edition-of-its-famous-ide-pycharm-3-0/
• http://blog.jetbrains.com/blog/2014/09/23/jetbrains-makes-its-products-free-for-students/
• http://legacy.python.org/dev/peps/pep-0373/
• https://www.wikivs.com/wiki/MySQL_vs_PostgreSQL
• https://bitbucket.org/product/pricing

Instalação dos softwares

Com o CentOS 7 rodando em uma máquina, seja virtual ou não, basta seguir esses passos para instalação desse ambiente. Todos os comandos devem ser executados como root: No LIT foi escolhido o uso de Docker para a instalação das ferramentas Python na VM, sendo mais mais fácil de manter pelos próprios desenvolvedores. Quanto ao Postgres, vale o que é descrito abaixo:

Interpretador e ferramentas Python

O CentOS 7 não vem com o Python 3.4 pré-instalado, sendo necessário o download e ativação:

   # Instalando Python 3.4
   yum install -y epel-release
   yum install -y python34 python34-devel
   curl -O https://bootstrap.pypa.io/get-pip.py 
   python3 get-pip.py

Para efeitos de compatibilidade, execute esse procedimento em todos os servidores onde pode haver interação de um usuário com o shell, sendo assim possível escrever scripts utilizando-se do Python.

PostgreSQL 9.4

Os repositórios do CentOS 7 estão com a versão 9.2 do Postgres disponível. Para instalar a 9.4 é preciso instalar de um repositório externo, oficial do projeto postgresql. Usar sistema rodando em locale pt_BR.

   # Instalando PostgreSQL 9.4
   yum localinstall -y https://download.postgresql.org/pub/repos/yum/9.4/redhat/rhel-7-x86_64/pgdg-centos94-9.4-2.noarch.rpm
   yum install -y postgresql94 postgresql94-server postgresql94-contrib postgresql94-devel gcc
   /usr/pgsql-9.4/bin/postgresql94-setup initdb 
   systemctl enable postgresql-9.4.service
   systemctl start postgresql-9.4.service
   echo "export PATH=$PATH:/usr/pgsql-9.4/bin" >> /etc/profile.d/paths.sh
   chmod 644 /etc/profile.d/paths.sh

Configure de acordo a documentação, criando os usuários, papeis e permissões. Aqui tem um bom tutorial sobre

Django, Flask, Gunicorn, psycopg (conector com postgres), virtualenv

   # Instalando Gunicorn, Django, psycopg2, flask, virtualenv
   pip3 install gunicorn~=19.4 django~=1.9 psycopg2~=2.6 flask~=0.10 virtualenv

Não execute este comando antes de instalar e configurar os pacotes `postgresql94-contrib postgresql94-devel gcc` que são necessários para a compilação do psycopg2. Observe que se você está instalando o servidor das aplicações em uma máquina diferente da de banco de dados, é preciso instalá-los manualmente, visto que a instalação sugerida acima, não interfere nesse ambiente.

Apache HTTP

   # Instalando Apache
   dnf install -y httpd

Para usar o Apache como proxy reverso, você deve seguir os passos descritos neste tutorial. Lembrando que o Apache deve ser configurado para servir os arquivos estáticos (uso tradicional) e redirecionar o tráfico (proxy reverso) para o Gunicorn que serve as aplicações Python. O Gunicorn não deve sob nenhum circunstância ser usado com interação direta com a Internet. Existem inúmeros tutoriais a respeito, inclusive nas documentações do Apache/Gunicorn.

Status atual da instalação

O servidor de aplicações ficou com o nome LIT-APP0 e é um PowerEdge R610, com 16 de RAM e um disco de 300GB. É o melhor computador que trouxemos da 236, apesar de um HD estar com defeito. Roda como SO base, Proxmox 4.2 e sobre ele, uma VM CentOS 7, que foi configurada com o Docker para containerização facilitada pois permite que o desenvolvedor mesmo faça ajustes.

O servidor de banco de dados tem nome LIT-BD0 e é um PowerEdge 2950, com 16GB de RAM e 4 discos de 146GB em RAID10 (soma-se o espaço de dois deles, e os outros dois servem de redundância). Além do LIT-APP0, é o servidor com mais barramentos de disco que trouxemos da 236. Roda como SO base, Proxmox 4.2 e sobre ele, uma VM CentOS 7, na qual foi instalada o Postgres 9.4.

Obs.: É necessário mudar as configurações de rede tanto nas instalações do Proxmox e das VMS, nos arquivos /etc/network/interfaces, /etc/hosts, /etc/resolv.conf quando os IPs estiverem fixos pelo CTI. Também é necessário settar as variáveis de ambiente http_proxy, https_proxy e ftp_proxy quando estiver atrás do proxy da UFU.