Software Público Brasileiro: Manual de Operação (dev)

Transcrição

1 Software Público Brasileiro: Manual de Operação (dev) Versão 3 Universidade de Brasília 21/05/2015

2

3 Sumário 1 Introdução 1 2 Arquitetura Servidores e serviços Gestão de configuração Implantação Preparação da estação de trabalho Obtendo o repositório de configuração Preparação dos servidores Configuração do ambiente alvo Configuração do DNS Verificando o ambiente Primeira instalação Manutenção Mantendo o sistema atualizado Modificando configurações Backup Procedimento de backup Procedimento de restauração Gestão do Firewall Firewall Interno Comunicação externa i

4 ii

5 CAPÍTULO 1 Introdução Bem-vindo a documentação do Portal do Software Público Brasileiro. O Portal do Software Público Brasileiro (SPB) é uma plataforma de compartilhamento e colaboração no desenvolvimento de softwares. O projeto de evolução deste portal está sendo desenvolvido pela Universidade de Brasília. O SPB é composto de um conjunto de ferramentas com funcionalidades complementares, que são desenvolvidas de forma independentes pelas suas respectivas comunidades. Estas ferramentas estão sendo integradas pela nossa equipe de forma a apresentar uma experiência de usuário consistente. O Colab é uma ferramenta especializada na integração de outras ferramentas. O Colab fornece um ponto central de autenticação de usuários para as demais ferramentas da plataforma, indexa informações das demais ferramentas para busca e gamificação, e fornece integração visual entre as diferentes ferramentas que compõem o SOB. O Colab é um software livre criado no Brasil, que teve sua origem no Programa Interlegis do Senado Federal. O Noosfero é uma plataforma para criação de redes sociais que conta com diversas funcionalidades de gestão de conteúdo como blogs, galeria de imagens e vídeos, entre outros. O Noosfero também é um software livre criado no Brasil, iniciado em 2007 pela COLIVRE e que hoje conta com uma comunidade de desenvolvimento que inclui o SERPRO, a Universidade de Brasília e o Fórum Brasileiro de Economia Solidária. O Gitlab é uma plataforma para desenvolvimento colaborativo. Projetos no gitlab são mantidos em repositorios git, com gestão de tarefas (issue tracker), merge requests, gestão de marcos (milestones), suporte a integração com plataformas de integração contínua e notificações. O GNU Mailman é uma gerenciador de listas de tradicionalmente usado por diversas organizações no Brasil e no mundo. O restando deste manual descreve a arquitetura do SPB bem como os procedimentos necessários para sua implantação, manutenção, backup e restauração e gestão de firewall. 1

6 Software Público Brasileiro: Manual de Operação (dev), Versão 3 2 Capítulo 1. Introdução

7 CAPÍTULO 2 Arquitetura A arquitetura do SPB consiste em 5 servidores, representados na figura a seguir. 2.1 Servidores e serviços Esta seção é um trabalho em andamento. Ela cobrirá: descrever arquitetura descrever papel de cada máquina descrever conexões 3

8 Software Público Brasileiro: Manual de Operação (dev), Versão Gestão de configuração Esta seção é um trabalho em andamento. Ela cobrirá: adicionar links com o repositório de gestão de configuração descrever repositório de gestão de configuração descrever como o chake funciona 4 Capítulo 2. Arquitetura

9 CAPÍTULO 3 Implantação 3.1 Preparação da estação de trabalho Para gerenciar o SPB, é necessária uma estação de trabalho GNU/Linux, que pode ser Debian 8 ou posterior, Ubuntu ou superior, ou CentOS 7 ou superior (e equivalentes como RHEL 7 ou superior, ou Fedora). O processo também pode ser feito em outros sistemas, desde que os pacotes equivalentes estejam instalados. As seguintes ferramentas serão necessárias: git: ferramenta de controle de versão. chake: ferramenta de gestão de configuração. Para instalar em Debian/Ubuntu: $ sudo apt-get install git ruby $ sudo gem install chake Para instalar em CentOS/RHEL/Fedora: $ sudo yum install git ruby $ sudo gem install chake Além dessas ferramentas, será necessário um emulador de terminal. O emulador de terminal padrão do seu ambiente de trabalho, ou qualquer outro, vai servir. 3.2 Obtendo o repositório de configuração Para iniciar, é necessário uma conta e usuário no SPB, com uma chave SSH configurada. Para obter o repositório de configuração, é necessário clonar o repositório com git: $ git clone git@beta.softwarepublico.gov.br:softwarepublico/softwarepublico.git A partir daqui, todos os passos serão executados de dentro do repositório, então se certifique que o seu shell está no diretório onde foi clonado o repositório: $ cd softwarepublico/ 5

10 Software Público Brasileiro: Manual de Operação (dev), Versão Preparação dos servidores Os servidores precisam estar acessíveis por SSH. Caso necessário, podem ser feitas configurações do SSH em config/dev/ssh_config para isso. O usuário que vai conectar via SSH nos servidores precisa: * ter acesso SSH configurado via chave SSH para evitar digitar senha. * ter permissão de usar sudo sem a necessidade de digitar senha. 3.4 Configuração do ambiente alvo O SPB tem o conceito de ambientes, que são diferentes instalações da mesma plataforma. Todas as informações específicas sobre um determinado ambiente estão centralizadas em arquivos dentro do diretório config/${ambiente}/. Por exemplo, o ambiente local, que se destina ao uso para desenvolvimento local com máquinas virtuais, possui o seguinte conteúdo: $ find config/local/ sort config/local/config.yaml config/local/ips.yaml config/local/ssh_config Estes arquivos possuem a seguinte finalidade: config.yaml: Parâmetros gerais de configuração ips.yaml: Tabela de IP s (na rede local) das máquinas que compõem o ambiente. ssh_config: Configuração necessária para o SSH. Pode ser um arquivo caso não seja necessária nenhuma configuração especial para acessar as máquinas (e.g. se você está na mesma rede local que elas. Vamos agora verificar o conteúdo de cada arquivo no ambiente dev. Primeiro, config.yaml: admins: - ["Paulo Meirelles", "paulo@softwarelivre.org"] external_hostname: dev.softwarepublico.gov.br external_ip: site_url: colab_from_address: '"Portal do Software Publico (dev)" <noreply@dev.softwarepublico.gov.br>' server_ '"Portal do Software Publico (dev)" <noreply@dev.softwarepublico.gov.br>' _subject_prefix: '[spb dev]' lists_hostname: listas.dev.softwarepublico.gov.br lists_admin: paulo@softwarelivre.org relay_hostname: relay.dev.softwarepublico.gov.br from_address: noreply@dev.softwarepublico.gov.br relay_hostname: relay.dev.softwarepublico.gov.br relay_ip: external_outgoing_mail_relay: Para nossa sorte, o significado de cada um dos campo acima deve ser autoexplicativo. O arquivo ips.yaml contém uma tabela com os endereços IP de cada servidor da plataforma na rede local. Exemplo: reverseproxy: database: social: integration: Já o arquivo ssh_config contém opções padrão de configuração do ssh para conexão às máquinas: 6 Capítulo 3. Implantação

11 Software Público Brasileiro: Manual de Operação (dev), Versão 3 Host * ForwardAgent yes Host reverseproxy Hostname User spb Host database Hostname User spb # connect via reverseproxy host ProxyCommand ssh spb@ nc %h %p Host social Hostname User spb # connect via reverseproxy host ProxyCommand ssh spb@ nc %h %p Host Hostname User spb # connect via reverseproxy host ProxyCommand ssh spb@ nc %h %p Host integration Hostname User spb # connect via reverseproxy host ProxyCommand ssh spb@ nc %h %p 3.5 Configuração do DNS A tabela a seguir foi gerada dinamicamente a partir da configuração do ambiente dev. As seguintes entradas precisam ser configuradas no DNS: Tipo Entrada Aponta para A dev.softwarepublico.gov.br A listas.dev.softwarepublico.gov.br A relay.dev.softwarepublico.gov.br Tipo Entrada Aponta para MX dev.softwarepublico.gov.br relay.dev.softwarepublico.gov.br. MX listas.dev.softwarepublico.gov.br relay.dev.softwarepublico.gov.br. Tipo Entrada Aponta para PTR dev.softwarepublico.gov.br. PTR relay.dev.softwarepublico.gov.br. 3.6 Verificando o ambiente Para listar as máquinas do ambiente: 3.5. Configuração do DNS 7

12 Software Público Brasileiro: Manual de Operação (dev), Versão 3 $ rake nodes SPB_ENV=dev O comando acima deve dar o seguinte resultado: integration social database reverseproxy ssh ssh ssh ssh ssh Note que todas as vezes que formos chamar rake, será preciso informar sobre qual ambiente desejamos operar (SPB_ENV=dev). Caso você for operar sobre apenas um ambiente, ou caso você queira evitar digitação, você pode criar um arquivo local.rake na raiz do repositório com o seguinte conteúdo: ENV['SPB_ENV'] = 'dev' Isto fará com que o valor e SPB_ENV seja sempre dev, a não ser que você informe na linha de comando. Daqui para frente, vamos sempre exibir o parâmetro SPB_ENV=dev, mas lembre-se que ele pode ser omitido se você tiver configurado o default em local.rake. Para testar a conectividade às máquinas, podemos executar um comando nelas: $ rake nodes SPB_ENV=dev $ <PROMPT PARA VOCÊ DIGITAR> No prompt, entre um comando simples como sudo date. O resultado deve ser parecido com o seguinte: $ rake run $ sudo date integration: $ sudo date integration: Qui Mai 14 18:59:19 BRT $ sudo date Qui Mai 14 18:59:22 BRT 2015 social: $ sudo date social: Qui Mai 14 18:59:24 BRT 2015 database: $ sudo date database: Qui Mai 14 18:59:27 BRT 2015 reverseproxy: $ sudo date reverseproxy: Qui Mai 14 18:59:28 BRT 2015 Se o resultado se parece com o exemplo acima, e você não precisou digitar a sua senha nehuma vez, significa que 1) você conseguiu conectar em todas as máquinas e 2) o sudo sem senha está configurado corretamente. Está tudo certo para começar! 3.7 Primeira instalação Uma vez configurados os parâmetros em config/dev/, podemos dar início à instalação. O primeiro passo é uma preconfiguração que precisamos fazer: $ rake preconfig SPB_ENV=dev Este comando vai fazer uma configuração inicial que é necessária para o resto do processo, e só é necessária fazer uma vez. Depois de completo o procedimento acima, para aplicar as configurações a todos os servidores basta executar: 8 Capítulo 3. Implantação

13 Software Público Brasileiro: Manual de Operação (dev), Versão 3 $ rake converge SPB_ENV=dev O comando converge na verdade é o default, então o seguinte é equivalente: $ rake SPB_ENV=dev Se você tiver configurado o ambiente dev no local.rake (ver instruções acima), então o comando seguinte, também equivalente, é muito mais simples: $ rake Todas as possibilidades de comandos serão listados se você executar rake -T. Consulte também a documentação do chake Primeira instalação 9

14 Software Público Brasileiro: Manual de Operação (dev), Versão 3 10 Capítulo 3. Implantação

15 CAPÍTULO 4 Manutenção 4.1 Mantendo o sistema atualizado Esta seção é um trabalho em andamento. 4.2 Modificando configurações Esta seção é um trabalho em andamento. 11

16 Software Público Brasileiro: Manual de Operação (dev), Versão 3 12 Capítulo 4. Manutenção

17 CAPÍTULO 5 Backup O SPB possui rotinas automatizadas para backup e restore dos dados de todos os seus componentes. As seções a seguir descrevem estas rotinas. Ambos os procedimentos devem ser realizados num shell onde o diretório atual é o repositório de controle de versão do SPB. 5.1 Procedimento de backup Suponha que estamos realizando um backup do ambiente de produção, chamado de prod; o comando para realizar um backup é o seguinte (note SPB_ENV=prod): $ rake backup SPB_ENV=prod Esta operação vai copiar arquivos e dumps dos bancos de dados do Noosfero, GitLab, Colab e Mailman, e copiá-los para um subdiretório chamado backups na sua estação de trabalho. 5.2 Procedimento de restauração Importante: o procedimento de restauração é suportado apenas para uma versão idêntica da plataforma, ou seja, não é suportado fazer um backup de uma versão mais antiga da plataforma e restaurar esse backup numa versão mais recente da plataforma, e nem vice-versa. O comando para restaurar um backup no ambiente dev é o seguinte: $ rake restore SPB_ENV=dev Esta operação vai restaurar o último backup realizado no ambiente chamado dev. Importante: a restauração do backup irá apagar os dados existes no ambiente dev. Confira duas vezes antes de iniciar o procedimento. 13

18 Software Público Brasileiro: Manual de Operação (dev), Versão 3 14 Capítulo 5. Backup

19 CAPÍTULO 6 Gestão do Firewall 6.1 Firewall Interno O Portal do Software Público atualmente é composto por diversos serviços funcionando em diferentes servidores. Para o seu correto funcionamento é esperado que estes serviços se comuniquem através de TCP/IP. Os scripts de instalação do Portal do Software Público também cuidam da manutenção das regras de firewall. Cada máquina possui um firewall (iptables) local que por padrão nega todos os tipos de conexão de entrada em todas as portas (INPUT rules) mas permite conexões de saída (OUTPUT rules). Todas as regras de firewall são definidas no cookbook firewall. Para definir regras de comunidacação entre hosts locais, válidas para todos os ambientes (local, produção, homologação, testes, etc) são utilizados templates que podem ser encontrados em cookbooks/firewall/templates/. Para regras de filtro utilize o arquivo iptables-filter.erb e para regras de NAT o arquivo iptables-nat.erb. Para adicionar regras específicas de cada ambiente (por exemplo, abrir uma porta diferente em homologação) utilize o arquivo config/dev/iptables-filter-rules. Este arquivo aceita apenas regras de filtro do tipo INPUT Comunicação Entre Serviços Os serviços que compõe o portal e suas portas de entrada são descritos na tabela a seguir: Destino Origem Serviço Porta database integration Redis 6379 database integration PostgreSQL 5432 database social PostgreSQL 5432 social reverseproxy Nginx 80 social reverseproxy Nginx 443 integration reverseproxy Nginx 80 integration reverseproxy Nginx 443 externa Postfix 25 reverseproxy externa Nginx 80 reverseproxy externa Nginx 443 reverseproxy externa OpenSSH (git) 22 15

20 Software Público Brasileiro: Manual de Operação (dev), Versão Comunicação externa Destino Serviço Porta Postfix 25 reverseproxy Nginx 80 reverseproxy Nginx 443 reverseproxy OpenSSH (git) 22 Outros firewalls da rede: Além do firewall local é importante que os serviços com origem externa tenham suas portas de INPUT abertas em todos os firewalls da rede. No caso do host a porta 25 também deve estar aberta para OUTPUT (alternativamente o Postfix pode ser configurado para enviar s utilizando um relay interno). 16 Capítulo 6. Gestão do Firewall